Resumen de la 116.ª reunión ejecutiva de desarrolladores centrales de Ethereum: actualización de Cancún, conversión de Verkle Trie y serialización de SSZ
El 31 de agosto, los desarrolladores de Ethereum se reunieron en Zoom para la conferencia telefónica de Core Developers (ACDE). Organizada por Tim Beiko de la Fundación Ethereum, la convocatoria ACDE es una serie de reuniones quincenales en las que el equipo del cliente de Ethereum discute y coordina cambios en la capa de ejecución de Ethereum (EL). 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). El desarrollador del cliente Nethermind, Lukasz Rozmej, explicó que la esencia del problema se debía a una mala configuración en la implementación del grupo de transacciones de blobs. (Nota del traductor: Devnet 8 es la primera red de prueba dedicada que contiene todos los EIP finalizados para la actualización de Cancún/Deneb)
Con respecto a EIP 4788, los desarrolladores reafirmaron 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, lo que requerirá que alguien financie la dirección del contrato antes de que se active la actualización. Devnet #9, la próxima red de prueba de la actualización de Cancún, adoptará este flujo de trabajo y garantizará que los desarrolladores estén familiarizados con el proceso.
En lugar de retrasar la fecha de lanzamiento de Devnet #9, los desarrolladores acordaron continuar probando Devnet #8 hasta que se resuelvan todos los problemas con la implementación del cliente. "Prefiero tener confianza en Devnet #9 que decir que esperamos que estas cosas funcionen... Prefiero resolver problemas que conocemos. De lo contrario, si tenemos problemas difíciles en Devnet #9, entonces definitivamente 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 dijo Danny Ryan, compañero en la Fundación Fang y presidente de la conferencia telefónica de ACDC.
Otros 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ó que los desarrolladores se reúnan nuevamente para Devnet #9 durante la próxima conferencia telefónica de ACDE. En cuanto a la estrategia 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 quede obsoleto y reemplazado por Holesky. (Nota del traductor: la palabra Dencun es una palabra compuesta compuesta por 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 está relacionada con Deneb Las actualizaciones se denominan colectivamente actualizaciones Dencun).
Sepolia: Finalmente, Dencun se desplegó en Sepolia para lograr buenos resultados.
Nadie planteó objeciones a la propuesta de Beiko de lanzar una red de prueba después de Devnet #9. Beiko mencionó que la línea de tiempo anterior se compartirá con la comunidad 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 nodos de verificación que se restablecerá al estado de génesis después de una semana o dos. Para obtener más información sobre Ephemery Network, 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ó que la pregunta se plantee nuevamente 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, un 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 se diferencian 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 un programa separado diseñado para abordar el problema del crecimiento estatal ilimitado. El objetivo de la caducidad del estado es reducir el tamaño del estado de más de 100 GB a menos de 50 GB eliminando partes del estado de Ethereum a las que el usuario no ha accedido dentro de un cierto período de tiempo (por ejemplo, 365 días). Andrew Ashikhmin, del equipo de cuentas de Erigon (EL), estuvo a favor de agrupar las dos actualizaciones, suponiendo que las conversiones de Verkle Trie se simplificarían enormemente si se combinaran con State Expiry. A Guillaume Ballet, del equipo de clientes de Geth (EL), que ha estado liderando el proyecto Verkle Trie, le preocupa que el acoplamiento retrase Verkle Tries ya que la caducidad estatal como tema de investigación ha sido "abandonada" en los últimos dos años.
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 más de 50 GB de Merkle Patricia Trie a... 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, fue básicamente el tema de la actividad de investigación, básicamente tanto trabajo de I+D junto como el resto de la hoja de ruta de Verkle, cómo iba la última transición. En cierto modo, su complejidad es comparable a la de las fusiones. "
Buterin continuó cómo State Expiry redujo significativamente la complejidad de la transición a Verkle. Sin embargo, también mencionó 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 direcciones" cada año, por lo que, aunque la complejidad de implementar Verkle se reducirá, los desarrolladores aún necesitan Difícil de resolver 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 para introducir State Expiry después de Verkle. el valor agregado de agrupar las dos actualizaciones y acordó 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ó un nuevo enfoque para 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 puede reutilizarse para otros fines, dejando obsoletos el SSZ Union y el tipo opcional SSZ que actualmente no se utilizan". (Nota del traductor: la serialización simple (SSZ) es el método de serialización utilizado en Beacon Chain. Serialización recursiva con prefijo de longitud. El diseño de serialización simple es determinista y también se puede merkleizar de manera eficiente).
Después de la actualización, Beiko se apresuró a elogiar la implementación de referencia EL recién creada 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 la implementación de referencia de Python de los componentes centrales del cliente de ejecución de Ethereum, con un enfoque en la legibilidad y la claridad. EELS pretende ser un sucesor espiritual Según el Libro Amarillo, más amigable para los programadores y sincronizado con las bifurcaciones posteriores a la fusión, EELS puede completar y ejecutar pruebas estatales, seguir la red principal y es un excelente lugar para crear prototipos de nuevos EIP".
Algunos desarrolladores ya están utilizando EELS para volver a implementar sus EIP, y la Fundación Ethereum tiene una subvención para cualquier persona interesada en actualizar el documento 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 116.ª reunión ejecutiva de desarrolladores centrales de Ethereum: actualización de Cancún, conversión de Verkle Trie y serialización de SSZ
Autor: Christine Kim / Fuente:
Traducción: Huohuo/Blockchain vernácula
El 31 de agosto, los desarrolladores de Ethereum se reunieron en Zoom para la conferencia telefónica de Core Developers (ACDE). Organizada por Tim Beiko de la Fundación Ethereum, la convocatoria ACDE es una serie de reuniones quincenales en las que el equipo del cliente de Ethereum discute y coordina cambios en la capa de ejecución de Ethereum (EL). 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). El desarrollador del cliente Nethermind, Lukasz Rozmej, explicó que la esencia del problema se debía a una mala configuración en la implementación del grupo de transacciones de blobs. (Nota del traductor: Devnet 8 es la primera red de prueba dedicada que contiene todos los EIP finalizados para la actualización de Cancún/Deneb)
Con respecto a EIP 4788, los desarrolladores reafirmaron 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, lo que requerirá que alguien financie la dirección del contrato antes de que se active la actualización. Devnet #9, la próxima red de prueba de la actualización de Cancún, adoptará este flujo de trabajo y garantizará que los desarrolladores estén familiarizados con el proceso.
En lugar de retrasar la fecha de lanzamiento de Devnet #9, los desarrolladores acordaron continuar probando Devnet #8 hasta que se resuelvan todos los problemas con la implementación del cliente. "Prefiero tener confianza en Devnet #9 que decir que esperamos que estas cosas funcionen... Prefiero resolver problemas que conocemos. De lo contrario, si tenemos problemas difíciles en Devnet #9, entonces definitivamente 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 dijo Danny Ryan, compañero en la Fundación Fang y presidente de la conferencia telefónica de ACDC.
Otros 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ó que los desarrolladores se reúnan nuevamente para Devnet #9 durante la próxima conferencia telefónica de ACDE. En cuanto a la estrategia 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 quede obsoleto y reemplazado por Holesky. (Nota del traductor: la palabra Dencun es una palabra compuesta compuesta por 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 está relacionada con Deneb Las actualizaciones se denominan colectivamente actualizaciones Dencun).
Sepolia: Finalmente, Dencun se desplegó en Sepolia para lograr buenos resultados.
Nadie planteó objeciones a la propuesta de Beiko de lanzar una red de prueba después de Devnet #9. Beiko mencionó que la línea de tiempo anterior se compartirá con la comunidad 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 nodos de verificación que se restablecerá al estado de génesis después de una semana o dos. Para obtener más información sobre Ephemery Network, 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ó que la pregunta se plantee nuevamente 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, un 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 se diferencian 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 un programa separado diseñado para abordar el problema del crecimiento estatal ilimitado. El objetivo de la caducidad del estado es reducir el tamaño del estado de más de 100 GB a menos de 50 GB eliminando partes del estado de Ethereum a las que el usuario no ha accedido dentro de un cierto período de tiempo (por ejemplo, 365 días). Andrew Ashikhmin, del equipo de cuentas de Erigon (EL), estuvo a favor de agrupar las dos actualizaciones, suponiendo que las conversiones de Verkle Trie se simplificarían enormemente si se combinaran con State Expiry. A Guillaume Ballet, del equipo de clientes de Geth (EL), que ha estado liderando el proyecto Verkle Trie, le preocupa que el acoplamiento retrase Verkle Tries ya que la caducidad estatal como tema de investigación ha sido "abandonada" en los últimos dos años.
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 más de 50 GB de Merkle Patricia Trie a... 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, fue básicamente el tema de la actividad de investigación, básicamente tanto trabajo de I+D junto como el resto de la hoja de ruta de Verkle, cómo iba la última transición. En cierto modo, su complejidad es comparable a la de las fusiones. "
Buterin continuó cómo State Expiry redujo significativamente la complejidad de la transición a Verkle. Sin embargo, también mencionó 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 direcciones" cada año, por lo que, aunque la complejidad de implementar Verkle se reducirá, los desarrolladores aún necesitan Difícil de resolver 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 para introducir State Expiry después de Verkle. el valor agregado de agrupar las dos actualizaciones y acordó 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ó un nuevo enfoque para 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 puede reutilizarse para otros fines, dejando obsoletos el SSZ Union y el tipo opcional SSZ que actualmente no se utilizan". (Nota del traductor: la serialización simple (SSZ) es el método de serialización utilizado en Beacon Chain. Serialización recursiva con prefijo de longitud. El diseño de serialización simple es determinista y también se puede merkleizar de manera eficiente).
Después de la actualización, Beiko se apresuró a elogiar la implementación de referencia EL recién creada 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 la implementación de referencia de Python de los componentes centrales del cliente de ejecución de Ethereum, con un enfoque en la legibilidad y la claridad. EELS pretende ser un sucesor espiritual Según el Libro Amarillo, más amigable para los programadores y sincronizado con las bifurcaciones posteriores a la fusión, EELS puede completar y ejecutar pruebas estatales, seguir la red principal y es un excelente lugar para crear prototipos de nuevos EIP".
Algunos desarrolladores ya están utilizando EELS para volver a implementar sus EIP, y la Fundación Ethereum tiene una subvención para cualquier persona interesada en actualizar el documento amarillo para incluir actualizaciones de redes prefusionadas que faltan, como Londres y París, para complementar EELS.