Título original: Informe de la llamada de consenso n.° 107 de todos los desarrolladores principales de Ethereum

Autor original: Christine Kim (compilado con eliminaciones)

El 20 de abril de 2023, los desarrolladores de Ethereum se reunieron para celebrar la 107ª conferencia telefónica de consenso de desarrolladores principales (ACDC). ACDC es una serie de conferencias quincenales organizada por el investigador de la Fundación Ethereum, Danny Ryan. En esta reunión, los desarrolladores de Ethereum discuten modificaciones a la Capa de Consenso de Ethereum (CL), actualizan el progreso en torno a Deneb y discuten, además de Ethereum EIP-4844, qué otros. Las propuestas se incluirán en la próxima mejora de Cancún.

Deneb Devnet #5

Desde la exitosa activación en Shanghai el 12 de abril, los desarrolladores de Ethereum inmediatamente centraron su atención en los preparativos para Cancún. Cancún es el nombre de la próxima actualización de la capa de ejecución (EL) de Ethereum, mientras que Deneb es el nombre de la actualización CL correspondiente. Durante la llamada de ACDE, los desarrolladores discutieron el alcance final de la actualización de Cancún/Deneb, que se centrará en EIP 4844, la implementación del tipo de transacción blob y los preparativos para Deneb, comenzando con el lanzamiento de devnet #5.

Los desarrolladores han lanzado redes de prueba multicliente, también conocidas como devnets, para EIP 4844 desde octubre del año pasado. Tim Beiko, presidente de la llamada ACDE, dijo que la quinta red de desarrollo para EIP 4844 se lanzará en algún momento de la próxima semana. Paritosh Jayanthi, ingeniero de DevOps en la Fundación Ethereum, dijo que está realizando pruebas para clientes como Ethereum JS (EL) y Lodestar (CL) en preparación para el lanzamiento de devnet la próxima semana.

Entre ellos, hay un pequeño cambio en la API del motor, fusionando las llamadas "getPayloadV3" y "getBlobsBundleV1" en una. Beiko enfatizó que este cambio aún no se ha fusionado con la especificación EIP 4844 en GitHub, pero se hará en los próximos días para que el cambio pueda probarse en devnet #5, y Beiko instó a los equipos de clientes a revisar este cambio lo antes posible.

Luego, los desarrolladores discutieron la cuestión de cómo reinsertar transacciones de blobs en bloques en caso de reorganización de la cadena. Esta pregunta fue planteada por el desarrollador de Geth (EL), Péter Szilágyi, durante su presentación en ETHTokyo (se puede encontrar más información en las diapositivas de Szilágyi). Ryan dijo que debido a la separación de las transacciones de blobs de las transacciones regulares, los blobs reorganizados solo pueden obtenerse a partir de transacciones en el pool de memoria público. Dado que hay muchas transacciones que pasan por alto el mempool, es decir, transacciones MEV y paquetes, una forma de garantizar que se puedan reconstruir todos los blobs (incluso para las transacciones que pasan por alto el mempool) es hacer que el CL pase los datos del blob de cada bloque al EL, que luego puede almacenarlos en caché hasta que se finalice el bloque. Como alternativa, la red podría requerir que los usuarios que enviaron transacciones que saltaron el mempool vuelvan a enviar sus transacciones en caso de una reorganización de la cadena.

Szilagyi dijo que prefiere la primera opción, es decir, transferir los datos del blob a EL para que las transacciones puedan reinsertarse en caso de una reorganización, incluso las transacciones que pasan por alto el mempool. En opinión de Szilágyi, esto no supone una gran carga adicional para EL, y si el proceso se vuelve demasiado complicado para que los nodos lo soporten, los desarrolladores pueden ajustar los mensajes entre EL y CL para reducir la carga. “La solución más simple es proporcionar el blob al cliente de ejecución cada vez que el cliente de consenso envía una nueva carga útil”, dijo Szilagyi. Ryan respondió que si bien la solución propuesta es simple, rompería aún más la abstracción entre las capas EL y CL. Además, esta solución reforzará el supuesto de que los nodos almacenan datos completos, un supuesto que puede romperse en futuras implementaciones de actualizaciones de muestreo de disponibilidad de datos (DAS).

Respecto de la implementación de DAS, Szilagyi dijo que habrá otras expectativas en torno a la disponibilidad de datos que deberán cambiar con esta actualización, y aconsejó a los desarrolladores "intentar resolver las cosas entonces". Ryan estuvo de acuerdo con él y preguntó a otros desarrolladores qué pensaban sobre la situación de reorganización de la cadena y reinserción de transacciones de blobs. Gajinder Singh, desarrollador del cliente Lodestar (CL), dijo que dado que las transacciones MEV son el tipo más común de eludir el grupo de memoria pública, y las transacciones MEV dependen en gran medida de un estado de cadena específico para su ejecución, no importa si se eliminan después de una reorganización de la cadena porque el estado de la cadena ha cambiado y es posible que sea necesario volver a ejecutar las transacciones MEV.

Debido a la falta de participación del grupo de clientes de EL, este tema se planteó nuevamente en la siguiente conferencia telefónica de ACDE.

Complementos de Deneb

Además de EIP-4844, la actualización de Deneb también considera otras actualizaciones de código.

1. El primero es EIP-4788, que puede exponer el estado de CL Beacon Chain en EL. Esto permitirá que los contratos inteligentes que se ejecutan en EL tengan acceso de confianza minimizada a CL, que está relacionado con grupos de staking, protocolos de re-staking, MEV, etc. Alex Stokes, investigador de la Fundación Ethereum y uno de los autores del EIP, dijo que la característica es un cambio "ligero" a CL. Nadie en la llamada se opuso a incluir EIP 4788 en Deneb. Buscaremos las opiniones del equipo de clientes de EL en apoyo de este EIP en la próxima conferencia telefónica de ACDE.

2. EIP-6914, que permite reutilizar las claves de validación que han salido completamente de la red y han estado inactivas durante un período de tiempo. Este EIP ayudará a reducir el crecimiento ilimitado de la lista de validadores a medida que los validadores salen y nuevos validadores se unen a la red. Stokes dijo que EIP 6914 es relativamente complejo y que los cambios de código deberían posponerse hasta la próxima bifurcación dura después de Deneb. Después de una discusión sobre la complejidad de EIP-6914, los desarrolladores acordaron continuar perfeccionando los detalles de la actualización del código, pero dejar la implementación final hasta después de Deneb.

3. Ryan propuso un posible cambio de código que implica rellenar los datos del bloque de génesis de Beacon Chain y crear nuevo contenido de “resumen histórico”. Los detalles sobre este cambio de código aún no se han especificado en el EIP. Ryan aceptó contactar al proponente de este cambio, Jacek Sieka (Jefe de Investigación y Desarrollo en Status, quien está desarrollando el cliente Nimbus (CL)), para obtener más detalles.

PR 3175, que evitará que los validadores sancionados propongan bloques cuando salgan de la cola. Si más del 50% de los validadores son castigados por comportamiento malicioso, serán expulsados ​​​​por la fuerza de la red aunque aún podrán proponer bloques. Ryan dijo que cambiar esta lógica es un cambio de capa CL relativamente menor que brinda protección contra “modos de falla altos”.

5. EIP-6493, esta propuesta abordará cómo los nodos deben manejar los tipos de transacciones de blobs que están formateados en formato SSZ en CL pero codificados de manera diferente en EL. Este EIP es parte de un esfuerzo para actualizar el formato de serialización de Ethereum para permitir la consistencia entre capas. Puede encontrar más información sobre el formato de serialización de Ethereum en esta publicación anterior del desarrollador.

En las discusiones en todo Deneb, los desarrolladores se inclinan por incluir EIP-4788, EIP-3175 y EIP-4844 en la próxima actualización.