Autor: Christine Kim, galaxia; Traducción: Huohuo/Vernacular Blockchain
El 31 de agosto, los desarrolladores de Ethereum se reunieron en Zoom para la conferencia telefónica de Core Developers (ACDE). Moderada por Tim Beiko de la Fundación Ethereum, la conferencia telefónica de ACDE es una serie quincenal en la que el equipo del cliente de Ethereum discute y coordina los cambios en la capa de ejecución (EL) de Ethereum. Esta semana, los desarrolladores discutieron el progreso del desarrollo y las pruebas en:
Actualización Cancún/Deneb (Dencun)
Conversión de Verkle Trie
Actualización de serialización SSZ
1. Actualización de Cancún
Devnet #8 se lanzó hace dos semanas, el 16 de agosto. Barnabas Busa, ingeniero de DevOps de la Fundación Ethereum, dijo que la red de prueba de actualización de Cancún centrada en desarrolladores parece estar funcionando bien. Busa mencionó que parecía haber algunos problemas con los nodos que ejecutaban el software cliente Nethermind (EL). Lukasz Rozmej, desarrollador del cliente Nethermind, explicó que la naturaleza del problema se debía a una mala configuración en la implementación del grupo de transacciones Blob. **(Nota del traductor: Devnet 8 es la primera red de prueba dedicada, que contiene todos los EIP finalizados de la actualización Cancún/Deneb)
Con respecto a EIP 4788**, los desarrolladores reconfirmaron brevemente la nueva estrategia de implementación para cambios de código**. Los contratos que exponen datos de la cadena de balizas en EL se implementarán como contratos inteligentes normales, que requieren que alguien financie la dirección del contrato antes de que se active la actualización. Devnet #9, la próxima red de prueba para la actualización de Cancún, adoptará este flujo de trabajo y garantizará que los desarrolladores estén familiarizados con él.
En lugar de retrasar la fecha de lanzamiento de Devnet #9, los desarrolladores acordaron continuar las pruebas en Devnet #8 hasta que se resuelvan todos los problemas con la implementación del cliente. "Prefiero tener confianza en Devnet #9 que decir que queremos que estas cosas funcionen... Prefiero solucionar los problemas que conocemos. De lo contrario, si tenemos un problema difícil en Devnet #9, definitivamente lo solucionaremos". tener Devnet #10 nuevamente, no estoy diciendo que no deberíamos tener Devnet #10. Deberíamos tener una cantidad significativa de devnets. Creo que ahora podemos intentar hacer que Devnet #9 sea realmente confiable". Ether Danny Ryan, miembro de la Fundación Square y presidente de la conferencia telefónica de ACDC.
*Otros participantes en la llamada, incluidos Tim Beiko, Marius Van Der Wijden y Justin Florentine, estaban a favor de dedicar más tiempo a probar Devnet #8 y luego probar los cambios en EIP 4788 en Devnet #9 *. Beiko sugirió un momento para que los desarrolladores vuelvan a convocar a Devnet #9 durante la próxima conferencia telefónica de ACDE. En cuanto a las estrategias de implementación de testnet, Beiko recomienda la siguiente secuencia:
Devnet #9: Otro Devnet cuya especificación Dencun ha sido congelada. Pruebe la red y asuma que los desarrolladores están contentos con ella, luego pase a una red de prueba pública. De lo contrario, inicie Devnet #10.
Holesky: bifurque la red de prueba Holeksy recién lanzada e implemente la actualización Dencun en ella.
Goerli: Luego despliega Dencun en Goerli. Como el penúltimo lanzamiento de la red de prueba antes de la red principal, las especificaciones de actualización en este momento deben ser definitivas y brindar a los usuarios y las aplicaciones tiempo suficiente para probar su software antes de que se active la actualización de la red principal. Es probable que Dencun sea la última bifurcación de Goerli antes de que Goerli quede obsoleto y reemplazado por Holesky. (Nota del traductor: la palabra Dencun es una palabra compuesta de Cancún (Cancún) y Deneb. Cancún es el nombre de esta actualización de la capa de ejecución de Ethereum y Deneb es el nombre de la actualización de la capa de protocolo. Por lo tanto, la actualización de Cancún se combina con la actualización Deneb se conoce como actualización Dencun.)
Sepolia: Finalmente, implementa Dencun en Sepolia para lograr buenos resultados.
Nadie se opuso a la propuesta de Beiko de lanzar una red de prueba después de Devnet #9. Beiko mencionó que la línea de tiempo antes mencionada se compartirá con la comunidad de Ethereum en general en una publicación de blog una vez que la red de prueba Holesky se lance oficialmente el 15 de septiembre. Además, Beiko dijo que también se está desarrollando una red de prueba llamada Ephemery. Ehemery es una red de prueba de Ethereum para operadores de validación que se restablece al estado de génesis después de una o dos semanas. Para obtener más información sobre la red Ephemery, lea la página de GitHub del proyecto aquí.
Antes de pasar a hablar de Verkle Tries, Busa destacó una solicitud de extracción (PR) abierta en GitHub para la red de prueba Holesky. A petición del equipo de Erigon (EL), el RP propone eliminar el tiempo de activación específico para la actualización de Dencun en Holesky. Posteriormente, el desarrollador establecerá un valor para la activación de Dencun en Holesky en lugar de sobrescribir el valor existente. Busa también preguntó acerca de probar el objetivo de blob de 3/6/máximo en lugar del límite de 2/4. ** Sobre este tema, Beiko sugirió volver a mencionarlo en la llamada de ACDC de la próxima semana, donde Ryan mencionó que los experimentos recientes con bloques de gran tamaño traerán nuevos conocimientos. **
2. Conversión de Verkle Trie
A continuación, los desarrolladores discutieron la propuesta de Vitalik Buterin de combinar las hojas de ruta de Verkle Trie y State Expiry para reducir la complejidad de la implementación de Verkle Trie y acelerar los beneficios de State Expiry en Ethereum. Como antecedente, **Verkle Trie o Verkle Tree es una estructura de datos que permite a los usuarios verificar fácilmente grandes cantidades de datos basándose en una única prueba criptográfica. **No son diferentes de Merkle Patricia Trie (MPT), que es una estructura de datos utilizada para almacenar el estado de Ethereum. Sin embargo, la eficiencia de prueba de los árboles Verkle es relativamente mayor que la de MPT, razón por la cual los desarrolladores han estado trabajando en la transición de MPT a Verkle.
**La Expiración del Estado es una iniciativa independiente diseñada para abordar la cuestión del crecimiento estatal ilimitado. **El objetivo de la caducidad del estado es eliminar partes del estado de Ethereum a las que los usuarios no han accedido durante un período de tiempo (por ejemplo, 365 días), reduciendo así el tamaño del estado de más de 100 GB a menos de 50 GB. Andrew Ashikhmin del equipo de cuentas de Erigon (EL) estuvo a favor de agrupar las dos actualizaciones, suponiendo que la conversión de Verkle Trie se simplificaría enormemente si se combinara con State Expiry. A Guillaume Ballet, del equipo de clientes de Geth (EL), que dirige el proyecto Verkle Trie, le preocupa que el acoplamiento retrase Verkle Tries, ya que en los últimos dos años se ha "abandonado" la caducidad estatal como tema de investigación.
Buterin intervino con más antecedentes sobre las motivaciones de su propuesta, diciendo: “Con [Verkle] El proceso de transición, el problema es básicamente convertir un Merkle Patricia Trie de más de 50 GB en un... Verkle Trie en una red en vivo, es bastante complicado. De hecho, esto es algo con lo que el equipo de investigación ha estado luchando durante más de un año. Recuerdo el año pasado en Devconnect, básicamente fue el tema de la actividad de investigación, básicamente tanto trabajo de I+D como el resto de la hoja de ruta de Verkle, cómo iba la última transición. En cierto modo, rivaliza con la fusión en complejidad. "
Buterin continuó diciendo cómo State Expiry reduce significativamente la complejidad de la transición a Verkle. Sin embargo, también menciona que la caducidad del estado tiene requisitos previos complejos, como la necesidad de agregar más espacio de direcciones para admitir un nuevo "período de dirección"****"por año. Por lo tanto, implementar Verkle sería menos complejo, pero los desarrolladores Todavía es necesario resolver problemas difíciles para hacer ambas cosas. Además, si Verkle Tries se implementa antes de State Expiry, State Expiry tendrá menos urgencia, por lo que los desarrolladores deberían considerar usar Verkle para la transición o esperar unos años antes de que se introduzca State Expiry. Más tarde, los desarrolladores no eran conscientes del valor agregado de agrupar las dos actualizaciones y acordaron continuar discutiendo el tema de forma asincrónica en Discord y la llamada de implementadores de Verkle Trie.
3. Serialización SSZ
Luego, Etan Kissling, desarrollador del cliente Nimbus (CL), presentó sus últimos avances en la actualización de las estructuras de datos de Ethereum al formato de serialización SSZ. Para obtener más información sobre este tema, lea la transcripción de una llamada anterior a un desarrollador de Ethereum aquí. Kissling destacó una nueva forma de actualizar la serialización de datos de Ethereum utilizando un formato basado en SSZ "PartialContainer". Kissling escribió en los comentarios bajo la agenda de la conferencia telefónica de esta semana, "Este [formato] combina esencialmente todas las ventajas del [formato anterior] y también se puede reutilizar para otros fines, eliminando los tipos opcionales SSZ Union y SSZ actualmente no utilizados. ." (Nota del traductor: La serialización simple (SSZ) es el método de serialización utilizado en la cadena de baliza. Este método reemplaza todos los aspectos de la capa de consenso excepto el protocolo de descubrimiento de pares. Serialización recursiva de prefijo de longitud utilizada en la capa de ejecución. Simple Los diseños de serialización son deterministas y también se pueden Merkleizar de manera eficiente).
Después de la actualización, Beiko se apresuró a elogiar la implementación de referencia recién creada de EL en Python (llamada EELS). En una publicación reciente del blog de la Fundación Ethereum, el editor de EIP e investigador de la Fundación Ethereum, Sam Wilson, escribió: "EELS es una implementación de referencia de Python de los componentes centrales del cliente de ejecución de Ethereum, centrada en la legibilidad y la claridad. EELS está diseñado para ser un sucesor espiritual de "El Libro Amarillo, más fácil de usar para los programadores y sincronizado con las bifurcaciones posteriores a la fusión, EELS puede completar y ejecutar pruebas de estado, adherirse a la red principal y es un excelente lugar para crear prototipos de nuevos EIP".
Algunos desarrolladores ya están utilizando EELS para reimplementar sus EIP, y la Fundación Ethereum está ofreciendo una subvención a cualquier persona interesada en actualizar el Libro Amarillo para incluir actualizaciones de redes prefusionadas que faltan, como Londres y París, para complementar EELS.
Ver originales
Esta página puede contener contenido de terceros, que se proporciona únicamente con fines informativos (sin garantías ni declaraciones) y no debe considerarse como un respaldo por parte de Gate a las opiniones expresadas ni como asesoramiento financiero o profesional. Consulte el Descargo de responsabilidad para obtener más detalles.
Resumen de la última reunión ejecutiva de desarrolladores principales de Ethereum
Autor: Christine Kim, galaxia; Traducción: Huohuo/Vernacular Blockchain
El 31 de agosto, los desarrolladores de Ethereum se reunieron en Zoom para la conferencia telefónica de Core Developers (ACDE). Moderada por Tim Beiko de la Fundación Ethereum, la conferencia telefónica de ACDE es una serie quincenal en la que el equipo del cliente de Ethereum discute y coordina los cambios en la capa de ejecución (EL) de Ethereum. Esta semana, los desarrolladores discutieron el progreso del desarrollo y las pruebas en:
Actualización Cancún/Deneb (Dencun)
Conversión de Verkle Trie
Actualización de serialización SSZ
1. Actualización de Cancún
Devnet #8 se lanzó hace dos semanas, el 16 de agosto. Barnabas Busa, ingeniero de DevOps de la Fundación Ethereum, dijo que la red de prueba de actualización de Cancún centrada en desarrolladores parece estar funcionando bien. Busa mencionó que parecía haber algunos problemas con los nodos que ejecutaban el software cliente Nethermind (EL). Lukasz Rozmej, desarrollador del cliente Nethermind, explicó que la naturaleza del problema se debía a una mala configuración en la implementación del grupo de transacciones Blob. **(Nota del traductor: Devnet 8 es la primera red de prueba dedicada, que contiene todos los EIP finalizados de la actualización Cancún/Deneb)
Con respecto a EIP 4788**, los desarrolladores reconfirmaron brevemente la nueva estrategia de implementación para cambios de código**. Los contratos que exponen datos de la cadena de balizas en EL se implementarán como contratos inteligentes normales, que requieren que alguien financie la dirección del contrato antes de que se active la actualización. Devnet #9, la próxima red de prueba para la actualización de Cancún, adoptará este flujo de trabajo y garantizará que los desarrolladores estén familiarizados con él.
En lugar de retrasar la fecha de lanzamiento de Devnet #9, los desarrolladores acordaron continuar las pruebas en Devnet #8 hasta que se resuelvan todos los problemas con la implementación del cliente. "Prefiero tener confianza en Devnet #9 que decir que queremos que estas cosas funcionen... Prefiero solucionar los problemas que conocemos. De lo contrario, si tenemos un problema difícil en Devnet #9, definitivamente lo solucionaremos". tener Devnet #10 nuevamente, no estoy diciendo que no deberíamos tener Devnet #10. Deberíamos tener una cantidad significativa de devnets. Creo que ahora podemos intentar hacer que Devnet #9 sea realmente confiable". Ether Danny Ryan, miembro de la Fundación Square y presidente de la conferencia telefónica de ACDC.
*Otros participantes en la llamada, incluidos Tim Beiko, Marius Van Der Wijden y Justin Florentine, estaban a favor de dedicar más tiempo a probar Devnet #8 y luego probar los cambios en EIP 4788 en Devnet #9 *. Beiko sugirió un momento para que los desarrolladores vuelvan a convocar a Devnet #9 durante la próxima conferencia telefónica de ACDE. En cuanto a las estrategias de implementación de testnet, Beiko recomienda la siguiente secuencia:
Devnet #9: Otro Devnet cuya especificación Dencun ha sido congelada. Pruebe la red y asuma que los desarrolladores están contentos con ella, luego pase a una red de prueba pública. De lo contrario, inicie Devnet #10.
Holesky: bifurque la red de prueba Holeksy recién lanzada e implemente la actualización Dencun en ella.
Goerli: Luego despliega Dencun en Goerli. Como el penúltimo lanzamiento de la red de prueba antes de la red principal, las especificaciones de actualización en este momento deben ser definitivas y brindar a los usuarios y las aplicaciones tiempo suficiente para probar su software antes de que se active la actualización de la red principal. Es probable que Dencun sea la última bifurcación de Goerli antes de que Goerli quede obsoleto y reemplazado por Holesky. (Nota del traductor: la palabra Dencun es una palabra compuesta de Cancún (Cancún) y Deneb. Cancún es el nombre de esta actualización de la capa de ejecución de Ethereum y Deneb es el nombre de la actualización de la capa de protocolo. Por lo tanto, la actualización de Cancún se combina con la actualización Deneb se conoce como actualización Dencun.)
Sepolia: Finalmente, implementa Dencun en Sepolia para lograr buenos resultados.
Nadie se opuso a la propuesta de Beiko de lanzar una red de prueba después de Devnet #9. Beiko mencionó que la línea de tiempo antes mencionada se compartirá con la comunidad de Ethereum en general en una publicación de blog una vez que la red de prueba Holesky se lance oficialmente el 15 de septiembre. Además, Beiko dijo que también se está desarrollando una red de prueba llamada Ephemery. Ehemery es una red de prueba de Ethereum para operadores de validación que se restablece al estado de génesis después de una o dos semanas. Para obtener más información sobre la red Ephemery, lea la página de GitHub del proyecto aquí.
Antes de pasar a hablar de Verkle Tries, Busa destacó una solicitud de extracción (PR) abierta en GitHub para la red de prueba Holesky. A petición del equipo de Erigon (EL), el RP propone eliminar el tiempo de activación específico para la actualización de Dencun en Holesky. Posteriormente, el desarrollador establecerá un valor para la activación de Dencun en Holesky en lugar de sobrescribir el valor existente. Busa también preguntó acerca de probar el objetivo de blob de 3/6/máximo en lugar del límite de 2/4. ** Sobre este tema, Beiko sugirió volver a mencionarlo en la llamada de ACDC de la próxima semana, donde Ryan mencionó que los experimentos recientes con bloques de gran tamaño traerán nuevos conocimientos. **
2. Conversión de Verkle Trie
A continuación, los desarrolladores discutieron la propuesta de Vitalik Buterin de combinar las hojas de ruta de Verkle Trie y State Expiry para reducir la complejidad de la implementación de Verkle Trie y acelerar los beneficios de State Expiry en Ethereum. Como antecedente, **Verkle Trie o Verkle Tree es una estructura de datos que permite a los usuarios verificar fácilmente grandes cantidades de datos basándose en una única prueba criptográfica. **No son diferentes de Merkle Patricia Trie (MPT), que es una estructura de datos utilizada para almacenar el estado de Ethereum. Sin embargo, la eficiencia de prueba de los árboles Verkle es relativamente mayor que la de MPT, razón por la cual los desarrolladores han estado trabajando en la transición de MPT a Verkle.
**La Expiración del Estado es una iniciativa independiente diseñada para abordar la cuestión del crecimiento estatal ilimitado. **El objetivo de la caducidad del estado es eliminar partes del estado de Ethereum a las que los usuarios no han accedido durante un período de tiempo (por ejemplo, 365 días), reduciendo así el tamaño del estado de más de 100 GB a menos de 50 GB. Andrew Ashikhmin del equipo de cuentas de Erigon (EL) estuvo a favor de agrupar las dos actualizaciones, suponiendo que la conversión de Verkle Trie se simplificaría enormemente si se combinara con State Expiry. A Guillaume Ballet, del equipo de clientes de Geth (EL), que dirige el proyecto Verkle Trie, le preocupa que el acoplamiento retrase Verkle Tries, ya que en los últimos dos años se ha "abandonado" la caducidad estatal como tema de investigación.
Buterin intervino con más antecedentes sobre las motivaciones de su propuesta, diciendo: “Con [Verkle] El proceso de transición, el problema es básicamente convertir un Merkle Patricia Trie de más de 50 GB en un... Verkle Trie en una red en vivo, es bastante complicado. De hecho, esto es algo con lo que el equipo de investigación ha estado luchando durante más de un año. Recuerdo el año pasado en Devconnect, básicamente fue el tema de la actividad de investigación, básicamente tanto trabajo de I+D como el resto de la hoja de ruta de Verkle, cómo iba la última transición. En cierto modo, rivaliza con la fusión en complejidad. "
Buterin continuó diciendo cómo State Expiry reduce significativamente la complejidad de la transición a Verkle. Sin embargo, también menciona que la caducidad del estado tiene requisitos previos complejos, como la necesidad de agregar más espacio de direcciones para admitir un nuevo "período de dirección"****"por año. Por lo tanto, implementar Verkle sería menos complejo, pero los desarrolladores Todavía es necesario resolver problemas difíciles para hacer ambas cosas. Además, si Verkle Tries se implementa antes de State Expiry, State Expiry tendrá menos urgencia, por lo que los desarrolladores deberían considerar usar Verkle para la transición o esperar unos años antes de que se introduzca State Expiry. Más tarde, los desarrolladores no eran conscientes del valor agregado de agrupar las dos actualizaciones y acordaron continuar discutiendo el tema de forma asincrónica en Discord y la llamada de implementadores de Verkle Trie.
3. Serialización SSZ
Luego, Etan Kissling, desarrollador del cliente Nimbus (CL), presentó sus últimos avances en la actualización de las estructuras de datos de Ethereum al formato de serialización SSZ. Para obtener más información sobre este tema, lea la transcripción de una llamada anterior a un desarrollador de Ethereum aquí. Kissling destacó una nueva forma de actualizar la serialización de datos de Ethereum utilizando un formato basado en SSZ "PartialContainer". Kissling escribió en los comentarios bajo la agenda de la conferencia telefónica de esta semana, "Este [formato] combina esencialmente todas las ventajas del [formato anterior] y también se puede reutilizar para otros fines, eliminando los tipos opcionales SSZ Union y SSZ actualmente no utilizados. ." (Nota del traductor: La serialización simple (SSZ) es el método de serialización utilizado en la cadena de baliza. Este método reemplaza todos los aspectos de la capa de consenso excepto el protocolo de descubrimiento de pares. Serialización recursiva de prefijo de longitud utilizada en la capa de ejecución. Simple Los diseños de serialización son deterministas y también se pueden Merkleizar de manera eficiente).
Después de la actualización, Beiko se apresuró a elogiar la implementación de referencia recién creada de EL en Python (llamada EELS). En una publicación reciente del blog de la Fundación Ethereum, el editor de EIP e investigador de la Fundación Ethereum, Sam Wilson, escribió: "EELS es una implementación de referencia de Python de los componentes centrales del cliente de ejecución de Ethereum, centrada en la legibilidad y la claridad. EELS está diseñado para ser un sucesor espiritual de "El Libro Amarillo, más fácil de usar para los programadores y sincronizado con las bifurcaciones posteriores a la fusión, EELS puede completar y ejecutar pruebas de estado, adherirse a la red principal y es un excelente lugar para crear prototipos de nuevos EIP".
Algunos desarrolladores ya están utilizando EELS para reimplementar sus EIP, y la Fundación Ethereum está ofreciendo una subvención a cualquier persona interesada en actualizar el Libro Amarillo para incluir actualizaciones de redes prefusionadas que faltan, como Londres y París, para complementar EELS.