Otra reunión de @ethereum #AllCoreDevs concluyó el 15 de septiembre: se discutieron actualizaciones de la red de desarrollo, adiciones a Dencun y una descripción general completa de Reth.
Agenda: Enlace en vivo:
A continuación se muestra un resumen de la reunión de @TimBeiko.
1. Actualización de estado de Devnet-8
Primero, una actualización de estado en devnet-8: la red está en desarrollo final y muchos clientes ya le han enviado nuevas actualizaciones. Mientras tanto, hemos comenzado a probar el proceso de construcción de bloques/MEV utilizando @KurtosisTech. @NethermindEth declaró que su grupo de transacciones de blobs ya está listo y, después de unos días de pruebas en un solo nodo, lo implementaron en todos los nodos de prueba de Dencun.
El grupo de transacciones de blobs de Geth también está casi completo. Besu está realizando amplias mejoras en su grupo de transacciones (limitando el tamaño total de las transacciones blob y no blob) que se espera que se publiquen en su próxima versión. Erigon continúa mejorando su grupo de transacciones y espera estar listo para devnet-9. Prysm también señala que hay cierta latencia en la recepción de sidecars de blobs, que, según dicen, normalmente llegan con un retraso de unos 500 milisegundos después del bloque (mientras que el bloque tarda unos 15 milisegundos en procesarse).
Están investigando este problema para determinar si puede deberse a una condición de carrera entre las importaciones de blobs y fragmentos. Con respecto a la cuestión de si se debe permitir el soporte para transacciones de blobs en el grupo de memoria antes del hard fork, el equipo acordó por unanimidad no hacerlo.
2、EIP-7514
A continuación, continuamos la discusión de la llamada ACDC de la semana pasada sobre si agregar un límite constante a la cola de activación del validador. Esta propuesta se formó formalmente como EIP-7514. En resumen, esto ralentizará el crecimiento porcentual de las apuestas de ETH en el peor de los casos. Dankrad expresó su apoyo a la propuesta durante la llamada, diciendo que nos daría tiempo para realizar cambios potencialmente más complejos en las recompensas de los validadores.
Todos los equipos de CL están a favor de este cambio, con la salvedad de que esto sólo se aplica a la cola de depósito y no a la cola de retiro. Después de más discusión decidimos establecer el límite en 8. Por lo tanto, ¡EIP-7514 será parte de la actualización de Dencun! Se espera que en los próximos días, el EIP y la especificación CL relacionada PR se actualicen para reflejar este cambio.
3. EVM y Blob
A continuación, discutimos otra propuesta provisional: agregar un código de operación a la máquina virtual Ethereum (EVM) para exponer las tarifas base de los blobs. Esta propuesta fue presentada por @PlasmaPower0 de Arbitrum, quien dijo en R&D Discord a principios de esta semana que sería útil para ellos (y otras soluciones de Capa 2). Ya tenemos un código de operación similar que expone BASEFEE en EIP-1559, que se introdujo al mismo tiempo que se activó EIP. Esto facilita que las soluciones de Capa 2 determinen el precio correcto del gas para cobrar a los usuarios en función de los costos de datos L1.
@protolambda de Optimism también asistió a la reunión y sugirió que esta no es la única forma de obtener la tarifa base del blob para L2, ya que pueden mirar el encabezado del bloque (que contiene los valores utilizados para calcular la tarifa base del blob) y proporcionar Merkle contra esos valores prueba. Aún así, está de acuerdo en que es una buena característica. Arbitrum actualmente no realiza análisis de encabezados de bloque, y confiar en esto podría ser problemático para soluciones inmutables de Capa 2, ya que esto podría causar problemas si el formato del encabezado de bloque termina cambiando.
Uno de los autores de EIP-4844, @adietrichs, mencionó que este código de operación no se incluyó en la especificación original porque existía el deseo de desarrollar una forma más general de acceder a la información del encabezado del bloque (en lugar de agregar un código de operación de un solo uso). Aún así, adoptar este cambio más ambicioso sería una tarea más ambiciosa que introducir este código de operación.
La información expuesta por este código de operación ya es lo que el cliente EL necesita calcular y, semánticamente, es casi idéntica al código de operación BASEFEE. El equipo del cliente acordó por unanimidad que deberíamos agregar este código de operación, aunque solo sea para ser coherente con BASEFEE. Si en el futuro se nos ocurre un mecanismo "más ingenioso", cualquier funcionalidad redundante en este nuevo código de operación también se convertirá en un problema para otros códigos de operación que utilizan información de encabezado de bloque. Además, vale la pena enfatizar que este es un cambio tan pequeño: @vdWijden lo implementó en Geth antes de que existiera EIP, y solo tomó unos 20 minutos, y el equipo de Reth comprometió un cambio al respecto durante la llamada de relaciones públicas de ACD.
4、EIP-4788
A continuación, analizamos algunas actualizaciones de EIP-4788, una propuesta para almacenar raíces de baliza en contratos en la cadena principal de Ethereum. Durante las últimas semanas, hemos realizado múltiples auditorías y pruebas preliminares del contrato, lo que resultó en algunos cambios menores descritos en este RP. Si bien no se han completado todas las auditorías y los informes aún no se han publicado, @lightclients brindó una descripción general de los cambios considerados hasta el momento. El primer cambio es manejar explícitamente 0 marcas de tiempo para que provoquen una reversión (al igual que otras marcas de tiempo no válidas) en lugar de devolver 0. El segundo cambio se refiere al tamaño del búfer. Suponiendo que el horario cambie, el contrato original resultará en un desperdicio de almacenamiento debido a la forma en que funciona la aritmética modular.
5. Optimización del gas
Finalmente, existe una optimización de gas que reduce la cantidad de veces que se carga CALLDATA. Los auditores revisarán estos cambios y esperamos tener su informe final antes de la próxima reunión de ACDE. Para seguir avanzando con el trabajo de implementación y pruebas fuzz, hemos acordado fusionar los cambios propuestos ahora.
@shemnon también mencionó que estos cambios deberían documentarse en el EIP real. ¡Estamos trabajando en eso! A continuación, analizamos cómo los clientes deberían manejar esto si la dirección del contrato del sistema es parte del estado pero está vacía al final de la ejecución. Si bien es poco probable que esto suceda en la red principal (¡según tengo entendido!), este es un caso extremo que ocurrió en las pruebas al establecer la dirección en el bloque de génesis.
Dado que este es un caso límite bastante especial y no existe un comportamiento canónico claro, acordamos dedicar más tiempo a pensar en este tema y continuar la discusión en la reunión de prueba de la próxima semana. ¡Eso es todo sobre los cambios de especificaciones! Está previsto incluir todo lo anterior en devnet-9. El equipo del cliente está de acuerdo en que todo debería implementarse y probarse antes del ACDC de la próxima semana. En esa llamada, acordaremos una fecha de lanzamiento para devnet-9.
La próxima ACDE está programada para el 28 de septiembre a las 14:00 hora UTC. Hasta entonces, siga a @terencechain para obtener un resumen de la reunión de prueba, a @benjaminion_xyz para obtener información sobre la reunión de ACDC y a @christine_dkim para una cobertura más detallada de todo el evento.
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.
EIP-7514 será parte de la actualización de Ethereum Dencun
Autor: @TimBeiko Traducción: Huohuo/Vernacular Blockchain
Otra reunión de @ethereum #AllCoreDevs concluyó el 15 de septiembre: se discutieron actualizaciones de la red de desarrollo, adiciones a Dencun y una descripción general completa de Reth.
Agenda: Enlace en vivo:
A continuación se muestra un resumen de la reunión de @TimBeiko.
1. Actualización de estado de Devnet-8
Primero, una actualización de estado en devnet-8: la red está en desarrollo final y muchos clientes ya le han enviado nuevas actualizaciones. Mientras tanto, hemos comenzado a probar el proceso de construcción de bloques/MEV utilizando @KurtosisTech. @NethermindEth declaró que su grupo de transacciones de blobs ya está listo y, después de unos días de pruebas en un solo nodo, lo implementaron en todos los nodos de prueba de Dencun.
El grupo de transacciones de blobs de Geth también está casi completo. Besu está realizando amplias mejoras en su grupo de transacciones (limitando el tamaño total de las transacciones blob y no blob) que se espera que se publiquen en su próxima versión. Erigon continúa mejorando su grupo de transacciones y espera estar listo para devnet-9. Prysm también señala que hay cierta latencia en la recepción de sidecars de blobs, que, según dicen, normalmente llegan con un retraso de unos 500 milisegundos después del bloque (mientras que el bloque tarda unos 15 milisegundos en procesarse).
Están investigando este problema para determinar si puede deberse a una condición de carrera entre las importaciones de blobs y fragmentos. Con respecto a la cuestión de si se debe permitir el soporte para transacciones de blobs en el grupo de memoria antes del hard fork, el equipo acordó por unanimidad no hacerlo.
2、EIP-7514
A continuación, continuamos la discusión de la llamada ACDC de la semana pasada sobre si agregar un límite constante a la cola de activación del validador. Esta propuesta se formó formalmente como EIP-7514. En resumen, esto ralentizará el crecimiento porcentual de las apuestas de ETH en el peor de los casos. Dankrad expresó su apoyo a la propuesta durante la llamada, diciendo que nos daría tiempo para realizar cambios potencialmente más complejos en las recompensas de los validadores.
Todos los equipos de CL están a favor de este cambio, con la salvedad de que esto sólo se aplica a la cola de depósito y no a la cola de retiro. Después de más discusión decidimos establecer el límite en 8. Por lo tanto, ¡EIP-7514 será parte de la actualización de Dencun! Se espera que en los próximos días, el EIP y la especificación CL relacionada PR se actualicen para reflejar este cambio.
3. EVM y Blob
A continuación, discutimos otra propuesta provisional: agregar un código de operación a la máquina virtual Ethereum (EVM) para exponer las tarifas base de los blobs. Esta propuesta fue presentada por @PlasmaPower0 de Arbitrum, quien dijo en R&D Discord a principios de esta semana que sería útil para ellos (y otras soluciones de Capa 2). Ya tenemos un código de operación similar que expone BASEFEE en EIP-1559, que se introdujo al mismo tiempo que se activó EIP. Esto facilita que las soluciones de Capa 2 determinen el precio correcto del gas para cobrar a los usuarios en función de los costos de datos L1.
@protolambda de Optimism también asistió a la reunión y sugirió que esta no es la única forma de obtener la tarifa base del blob para L2, ya que pueden mirar el encabezado del bloque (que contiene los valores utilizados para calcular la tarifa base del blob) y proporcionar Merkle contra esos valores prueba. Aún así, está de acuerdo en que es una buena característica. Arbitrum actualmente no realiza análisis de encabezados de bloque, y confiar en esto podría ser problemático para soluciones inmutables de Capa 2, ya que esto podría causar problemas si el formato del encabezado de bloque termina cambiando.
Uno de los autores de EIP-4844, @adietrichs, mencionó que este código de operación no se incluyó en la especificación original porque existía el deseo de desarrollar una forma más general de acceder a la información del encabezado del bloque (en lugar de agregar un código de operación de un solo uso). Aún así, adoptar este cambio más ambicioso sería una tarea más ambiciosa que introducir este código de operación.
La información expuesta por este código de operación ya es lo que el cliente EL necesita calcular y, semánticamente, es casi idéntica al código de operación BASEFEE. El equipo del cliente acordó por unanimidad que deberíamos agregar este código de operación, aunque solo sea para ser coherente con BASEFEE. Si en el futuro se nos ocurre un mecanismo "más ingenioso", cualquier funcionalidad redundante en este nuevo código de operación también se convertirá en un problema para otros códigos de operación que utilizan información de encabezado de bloque. Además, vale la pena enfatizar que este es un cambio tan pequeño: @vdWijden lo implementó en Geth antes de que existiera EIP, y solo tomó unos 20 minutos, y el equipo de Reth comprometió un cambio al respecto durante la llamada de relaciones públicas de ACD.
4、EIP-4788
A continuación, analizamos algunas actualizaciones de EIP-4788, una propuesta para almacenar raíces de baliza en contratos en la cadena principal de Ethereum. Durante las últimas semanas, hemos realizado múltiples auditorías y pruebas preliminares del contrato, lo que resultó en algunos cambios menores descritos en este RP. Si bien no se han completado todas las auditorías y los informes aún no se han publicado, @lightclients brindó una descripción general de los cambios considerados hasta el momento. El primer cambio es manejar explícitamente 0 marcas de tiempo para que provoquen una reversión (al igual que otras marcas de tiempo no válidas) en lugar de devolver 0. El segundo cambio se refiere al tamaño del búfer. Suponiendo que el horario cambie, el contrato original resultará en un desperdicio de almacenamiento debido a la forma en que funciona la aritmética modular.
5. Optimización del gas
Finalmente, existe una optimización de gas que reduce la cantidad de veces que se carga CALLDATA. Los auditores revisarán estos cambios y esperamos tener su informe final antes de la próxima reunión de ACDE. Para seguir avanzando con el trabajo de implementación y pruebas fuzz, hemos acordado fusionar los cambios propuestos ahora.
@shemnon también mencionó que estos cambios deberían documentarse en el EIP real. ¡Estamos trabajando en eso! A continuación, analizamos cómo los clientes deberían manejar esto si la dirección del contrato del sistema es parte del estado pero está vacía al final de la ejecución. Si bien es poco probable que esto suceda en la red principal (¡según tengo entendido!), este es un caso extremo que ocurrió en las pruebas al establecer la dirección en el bloque de génesis.
Dado que este es un caso límite bastante especial y no existe un comportamiento canónico claro, acordamos dedicar más tiempo a pensar en este tema y continuar la discusión en la reunión de prueba de la próxima semana. ¡Eso es todo sobre los cambios de especificaciones! Está previsto incluir todo lo anterior en devnet-9. El equipo del cliente está de acuerdo en que todo debería implementarse y probarse antes del ACDC de la próxima semana. En esa llamada, acordaremos una fecha de lanzamiento para devnet-9.
La próxima ACDE está programada para el 28 de septiembre a las 14:00 hora UTC. Hasta entonces, siga a @terencechain para obtener un resumen de la reunión de prueba, a @benjaminion_xyz para obtener información sobre la reunión de ACDC y a @christine_dkim para una cobertura más detallada de todo el evento.