Dentro de las actualizaciones de Ethereum: Hegotá

Lo que Ethlabs está priorizando para Hegotá y por qué.

La dirección de Ethereum es importante para todos los que construyen sobre ella, la usan, tienen ETH, o simplemente creen en lo que puede llegar a ser. Si bien ese futuro lo determinarán en última instancia las personas, aplicaciones y comunidades que construyen sobre Ethereum a diario, las actualizaciones de la red son una de las principales formas en que el protocolo evoluciona para satisfacer sus necesidades. Hegotá es la próxima actualización de red de Ethereum planificada después de Glamsterdam, y este documento comparte la visión de Ethlabs sobre lo que creemos que Ethereum debería priorizar para ella, y por qué.

Ethlabs es un laboratorio de I+D sin fines de lucro para Ethereum y ETH de 8 semanas de antigüedad, y nuestra misión es convertir a Ethereum en la capa de liquidación de la economía global. Nos situamos entre el uso real de Ethereum y el desarrollo del protocolo, y dedicamos nuestro tiempo a escuchar a usuarios, billeteras, aplicaciones, rollups, instituciones, tenedores de ETH, investigadores y equipos de clientes. A veces incluso construimos en cadena, ¡porque no se puede construir una arena sin participar en ella! Creemos que una buena ingeniería de protocolo debería hacer posibles grandes productos, y los grandes productos deberían ayudar a informar hacia dónde se dirige el protocolo a continuación.

El alcance de Hegotá actualmente se encuentra en las primeras etapas de definición a través del proceso técnico abierto de Ethereum, y las propuestas a continuación reflejan el trabajo de muchos individuos y equipos de investigación y clientes. Este documento es un relato transparente de lo que recomendamos priorizar y dónde nuestras opiniones aún se están formando. Estas son posiciones que nos encantaría que otros evaluaran, cuestionaran y ayudaran a mejorar, e iteraremos sobre ellas a medida que discutamos y aprendamos más en los próximos días y semanas.

Para la actualización de Hegotá, considerando todos los EIP propuestos, estas son las áreas que vemos como de mayor prioridad para Ethereum:

1. Resistencia a la censura más fuerte: Cualquiera debería poder incluir una transacción, sin importar quién sea o para qué use Ethereum.
2. Ethereum más rápido: Bloques más rápidos significan confirmaciones más rápidas, precios en cadena más actualizados y finalidad más rápida.
3. Abstracción de cuenta nativa: Las cuentas deberían admitir passkeys, transacciones patrocinadas, pago de gas en tokens, procesamiento por lotes y una privacidad más sólida, con un camino hacia claves post-cuánticas.
4. Escalado continuo de L1: Las aplicaciones necesitan capacidad que se mantenga asequible y predecible, también cuando la demanda se dispara.

Trabajar de forma abierta es un objetivo central para Ethlabs, por lo que escribimos actualizaciones semanales y, en ocasiones como esta, publicamos piezas técnicas muy extensas para compartir nuestro pensamiento 😅. También publicaremos contenido más breve en las próximas semanas para aquellos que solo quieran lo más destacado. Esta siguiente parte será larga y técnica. Para aquellos que lo lean todo, ¡buena suerte!

Lo primero es lo primero: ¿cómo funciona siquiera el proceso de EIP?

Antes de sumergirnos en las propuestas en sí, un punto importante: la segunda fase del proceso de definición del alcance de Hegotá acaba de comenzar. La primera fase seleccionó a FOCIL como el titular de Hegotá. El 6 de agosto hubo una fecha límite para proponer EIP que no fueran titulares, y el proceso ACD ahora se moverá para evaluar la actualización de Hegotá en su totalidad.

Todos los EIP a continuación se encuentran actualmente en la etapa PFI (Propuesto para Inclusión), con la excepción de los EIP que pasaron por el proceso de titular. Proponer un EIP para su inclusión no requiere permiso, y la mayoría nunca llega a la actualización final.

Específicamente, a medida que avanza el trabajo de implementación, las propuestas avanzan a través de etapas progresivamente más sólidas de revisión y confianza de que finalmente se enviarán:

• PFI (Propuesto para Inclusión): se ha propuesto una idea para la actualización. Esta etapa no requiere permiso y no implica soporte del cliente o inclusión eventual.
• CFI (Considerado para Inclusión): los equipos de clientes han revisado la propuesta y tienen la intención de crear un prototipo y probarla.
• SFI (Programado para Inclusión): existe una intención general de incluirlo, asumiendo que la implementación y las pruebas continúen yendo bien.

Para obtener más información sobre cómo funciona este proceso, recomendamos ver el breve resumen de Tim Beiko aquí.

Instrucciones: cómo navegar este artículo

Seguimos la clasificación por niveles de Forkcast para expresar nuestra opinión sobre la priorización de EIP para Hegotá. Para minimizar la decisión, asignamos todos los EIP revisados en cuatro niveles con las siguientes interpretaciones:

• [Nivel S] recomendamos firmemente la inclusión.
• [Nivel A] recomendamos la inclusión si se resuelven los bloqueadores restantes, como la complejidad de implementación, el análisis de impacto o la adopción.
• [Nivel B] vale la pena, pero es un esfuerzo para esta actualización.
• [Nivel D] no recomendamos la inclusión en Hegotá en su forma actual.
• [formando opinión] todavía estamos formando nuestra opinión sobre este EIP.

Tenga en cuenta que estas son recomendaciones de Ethlabs. Evaluamos cada propuesta principalmente en términos de propósito, especificación y nuestra comprensión de la complejidad de implementación plausible, excepto cuando tenemos más certeza o participación directa (por ejemplo, Frames y Quick Slots), y actualizaremos nuestra opinión en función de las evaluaciones de ethPandaOps, los equipos de prueba y los clientes a medida que avanzamos en el proceso.

[CL] significa que un EIP afecta a los clientes de la capa de consenso y [EL] significa que afecta a los clientes de la capa de ejecución.

Tenga en cuenta que somos coautores y participamos en varios EIP (incluyendo FOCIL, Frame Transactions y Quick Slots). Si bien nos esforzamos por evaluar todos los EIP de forma independiente a nuestra participación o no, tenga esto en cuenta al evaluar nuestra posición.

Resumen

Clasificación CL

Puede iterar sobre esta clasificación [CL] específica en Forkcaster aquí.

Clasificación EL

Puede iterar sobre esta clasificación [EL] específica en Forkcaster aquí.

Ahora, sin más preámbulos, aquí están nuestras opiniones sobre la actualización de Hegotá tal como están hoy, en su totalidad:

Temas para Hegotá

0. FOCIL: fortalecer la resistencia a la censura

EIP-7805: FOCIL ya está SFI'd y confirmado como el titular de Hegotá. Tres miembros del equipo de Ethlabs (Francesco, Barnabé y Julian) se encuentran entre sus coautores, y apoyamos firmemente su inclusión. Dado que la decisión ya está tomada, lo mantenemos breve. Solo una cadena que sea neutral para todos puede convertirse en la raíz de confianza para todos. Esto es lo que permite que Ethereum escale para convertirse en la verdadera capa de liquidación para la economía global, y para cada persona dentro de ella.

1. Quick Slots: Ethereum más rápido

La ranura de 12 segundos de Ethereum es un costo de latencia que degrada el valor para el usuario. Por lo tanto, recomendamos firmemente incluir [CL] EIP-8198: Quick Slots [Nivel S] en Hegotá, por cuatro razones:

1. UX mejorada en L1 con confirmación de transacción más rápida.
2. Los mercados en cadena en L1 operan con precios más actualizados, mejorando los diferenciales y la economía de los proveedores de liquidez.
3. La finalidad y la regla de confirmación rápida heredan el tiempo de ranura, por lo que ambos se vuelven más rápidos con bloques más rápidos, mejorando la interoperabilidad con Ethereum.
4. Más proponentes de bloques por segundo significa una mayor resistencia a la censura, incluida la resistencia a la censura económica: la cantidad que necesita pagar para mantener los bloques vacíos durante algún período de tiempo.

Ir más rápido mientras se preserva la descentralización única de Ethereum hace que el espacio de bloques de Ethereum sea más valioso, y ese valor se acumula para la red y para ETH. Cada disminución es más valor entregado inmediatamente a nuestros usuarios. Finalmente, los bloques más rápidos se encuentran entre los cambios más solicitados por los desarrolladores de aplicaciones.

El argumento para comenzar ahora es que la reducción del tiempo de ranura nunca será un cambio único y definitivo. Al igual que con el escalado, las reducciones entregadas brindan a las aplicaciones más certeza que los compromisos de la hoja de ruta. El camino hacia ranuras de menos de 6 segundos comienza haciendo que el tiempo de ranura sea modificable, y luego cambiándolo de forma iterativa. EIP-8198 divide el trabajo en dos:

• Una refactorización única que facilita la actualización del tiempo de ranura en las especificaciones y el código del cliente.
• Una primera disminución en Hegotá, seguida de más disminuciones en bifurcaciones posteriores, a medida que avanza la hoja de ruta y se obtiene evidencia empírica de seguridad.

Hegotá es la bifurcación adecuada para pagar el costo único. ePBS en Glamsterdam ya reestructura la ranura. Hegotá es entonces una bifurcación comparativamente ligera para la capa de consenso, una ventana que se cierra con el consenso desacoplado en I*, por lo que el ancho de banda de CL para la refactorización única está disponible ahora de una manera que no lo estará nuevamente durante varias bifurcaciones.

Significado: O nos comprometemos a permanecer en 12 segundos durante al menos los próximos dos años, o logramos 10 segundos en aproximadamente un año en Hegotá, y posiblemente menos de 10 segundos para el año siguiente. Estas dos disminuciones no son mejoras teóricas. Obtienen directamente un mayor valor para el usuario y una mejor economía de red. Creemos que es hora de empezar.

Las objeciones más comunes

Discutimos aquí 4 puntos importantes que surgieron durante las discusiones preliminares con los desarrolladores de clientes y el Protocolo EF:

1. Complejidad de implementación: La sincronización de ranuras con precisión de milisegundos ya está fusionada en las especificaciones de consenso a través del trabajo de ePBS, y existen borradores de especificaciones CL y EL para EIP-8198, con la tarifa base, el límite de gas y el programa de blobs reescalados para preservar el comportamiento por segundo. El costo restante es una cola de casos extremos en clientes y herramientas que asumen un tiempo de ranura fijo, más las pruebas. La refactorización única adelanta exactamente este trabajo. Posteriormente, cada disminución es un cambio de parámetro.

2. Demostración de zkEVM: Los dos problemas principales son el tiempo de demostración relativo y la sobrecarga de demostración constante.

2.1 El tiempo de demostración relativo mide la proporción del tiempo de ranura dedicado a la demostración, y cómo cambia esta proporción cuando cambia el tiempo de ranura. Aquí hay una breve descripción de los momentos relevantes en la ranura. Los constructores actuales observan la liberación de la carga útil anterior y pueden comenzar a construir inmediatamente. El bloque de baliza actual se compromete entonces con la carga útil de la ranura actual. Esta carga útil debe demostrarse antes de la liberación del bloque del siguiente proponente de baliza.

Para la demostración, el tiempo relativo mínimo es una ranura completa, menos la latencia de la liberación de un bloque de baliza. La latencia de la liberación del bloque de baliza es incompresible, pero es corta por construcción, por lo tanto, no nos limita fundamentalmente en esta etapa. También existe la posibilidad de que los constructores optimizados co-demuestren la carga útil mientras se está construyendo, lo que les permite comenzar a demostrar antes de que el proponente del bloque de baliza se comprometa con la carga útil ganadora.

2.2 La demostración de zkEVM se escala principalmente de forma lineal con el tamaño del bloque, excepto por alguna sobrecarga fija. Las ranuras más rápidas significan que la sobrecarga fija se paga con más frecuencia, lo que agrega más latencia para la misma cantidad de rendimiento. Dado un presupuesto fijo de latencia, uno debe asegurarse de que aún se pueda obtener un buen rendimiento. Aquí vemos dos oportunidades: Primero, el progreso de la ingeniería continuará reduciendo la latencia de estas operaciones fijas. Segundo, retrasar el cálculo de la raíz de estado, como se describe en EIP-7862, mueve más de la demostración fuera de la ruta crítica, lo que significa que podemos aumentar nuestro presupuesto de latencia para operaciones incompresibles. La convergencia de estas dos oportunidades nos dice que las ranuras más rápidas no obstaculizarán amplios aumentos de rendimiento en el futuro.

3. Transición post-cuántica: El enfoque de consenso desacoplado ha obtenido suficiente apoyo para ser considerado estable en lo que respecta a la arquitectura de consenso futura. Desacoplar significa mover la votación de finalidad fuera de la ruta crítica de la producción de bloques. En particular, la agregación a gran escala de firmas PQ, y toda la maquinaria STARK recursiva relacionada, estará fuera de la ruta crítica. Lo que queda para producir bloques y obtener una regla de elección de bifurcación para rastrear la cabeza de la cadena resultante es un subcomité que actualmente se espera que comprenda 512 validadores, y posiblemente 256. Los tamaños de las firmas post-cuánticas son más grandes, pero son cómodos de propagar dentro del tiempo de ranura propuesto de 10 segundos y probablemente menos en el futuro.

4. Contratos inteligentes e infraestructura: La dependencia del tiempo de ranura en contratos inteligentes e infraestructura se está evaluando actualmente. Para contratos inteligentes, nos hemos asociado con Sourcify para ejecutar análisis en todos los contratos verificados. Estamos estudiando los impactos de una actualización del tiempo de ranura en las raíces de bloques de baliza históricas, según lo almacenado de acuerdo con EIP-4788: Raíz de bloque de baliza en la EVM. Con respecto a la infraestructura, como anécdota, Etherscan mencionó que un cambio en el tiempo de ranura probablemente conduciría a una mayor carga, pero que la infraestructura se había construido en la época de los tiempos de ranura variables en Prueba de Trabajo, por lo tanto, no requería muchos cambios.

2. Abstracción de Cuenta: mejorar UX, seguridad y privacidad

Ethereum y su ecosistema más amplio tienen una deuda pendiente con la AA nativa, que traerá beneficios de UX como billeteras con passkey, transacciones patrocinadas, pagos de gas con ERC20, procesamiento por lotes de transacciones y más.

Sin embargo, el camino hacia la AA nativa ha sido particularmente accidentado porque la AA toca todas las partes de la pila de Ethereum, incluidos clientes, L2, billeteras, RPC, herramientas de desarrollo, etc., por lo que requiere la aceptación de una gran variedad de partes interesadas. Esto dificulta que cualquier EIP de AA avance a través del proceso de desarrollo impulsado por consenso de Ethereum, pero también lograr una adopción práctica después de que se envíe el EIP.

Por lo tanto, colocamos la propuesta de AA nativa de Hegotá, Frame Transactions, en el nivel A, no porque no sea lo suficientemente buena para S técnicamente hablando, sino porque queremos tener en cuenta los riesgos de adopción práctica que requerirán una cantidad masiva de coordinación para resolver. Dados los antecedentes de nuestro equipo en AA, Ethlabs tiene la intención de desempeñar un papel importante en llevar Frame Transactions al mercado, trabajando con partes interesadas como L2 y billeteras para lograr una implementación exitosa de la AA nativa.

Ahora pasamos a las propuestas de AA específicas para Hegotá.

[EL] EIP-8141: Frame Transactions [Nivel A]

Creemos que EIP-8141: Frame Transactions es el mejor candidato para el sistema de AA nativo de Ethereum. En comparación con otras propuestas de AA nativas, Frames tiene una serie de propiedades deseables que lo hacen excepcionalmente alineado con el mandato CROPS de Ethereum:

• Innovación de cuentas sin permisos: la lógica de validación es manejada por el código EVM, por lo que los desarrolladores son libres de desarrollar cualquier lógica de validación que deseen, a diferencia de otros enfoques de AA que exigen una lista blanca de lógica de validación.
• Soporte de primera clase para protocolos de privacidad: como corolario del primer punto, un protocolo de privacidad como Railgun puede manejar la lógica de validación de las transacciones de frame, lo que permite a los usuarios enviar transacciones privadas sin depender de ningún relé centralizado como lo hacen hoy. Esto hace que los protocolos de privacidad sean significativamente más privados e incensurables.
• Seguridad post-cuántica: las transacciones de frame se han desarrollado teniendo en cuenta la hoja de ruta PQ más amplia de Ethereum. Por ejemplo, las transacciones de frame están diseñadas explícitamente para que las firmas se puedan agregar, lo que permite a Ethereum eventualmente cobrar un gas bajo por las firmas PQ, aunque individualmente cada firma puede ser muy costosa de validar.

La principal debilidad de Frame Transactions también proviene de su mayor fortaleza: debido a que la validación es manejada por el código EVM, la validación ahora induce un costo dinámico en lugar de un costo fijo, lo que puede plantear desafíos para cadenas de alto TPS como las L2. Somos optimistas de que este problema se puede abordar a través de otros EIP o ERC además de las transacciones de frame, como EIP-7819, donde las transacciones pueden indicar estáticamente su lógica de validación para que los secuenciadores puedan "acortar" la validación con código nativo si es necesario. También tenemos la intención de trabajar con L2 y la EF para realizar evaluaciones comparativas sobre las transacciones de frame para que podamos identificar y abordar cualquier cuello de botella de rendimiento.

[CL][EL] Complementos de Frame Transactions

Hay varios EIP que pueden verse como una extensión de las transacciones Frame, basándose en sus capacidades.

[EL] EIP-8250: Nonces Clave para Frame Transactions [Nivel A]

• Consideramos que este EIP es conceptualmente parte de EIP-8141: Frame Transactions, y creemos que debería enviarse con él.
• Este EIP introduce nonces 2D para las transacciones Frame. Los nonces 2D permiten a las cuentas enviar transacciones paralelas al mempool, así como permitir que los protocolos de privacidad almacenen anuladores como nonces 2D. Esto es importante porque los nonces 2D son un almacenamiento especial que cuesta muy poco leer y almacenar, por lo que las transacciones de privacidad pueden ahorrar significativamente en gas en comparación con si almacenan anuladores en el almacenamiento dinámico regular como hoy. Esto es especialmente importante en el contexto del redimensionamiento de precios de almacenamiento de Glamsterdam (EIP-8037: Aumento del Costo de Gas para la Creación de Estado).

[EL] EIP-8272: Raíces Recientes para Frame Transactions [Nivel B]

• Este es otro EIP que mejora la experiencia del uso de protocolos de privacidad con transacciones Frame. Los protocolos de privacidad necesitan acceso a raíces de compromiso recientes durante la validación, que si se almacenan en el almacenamiento regular pueden ser no solo costosas sino también entrar en conflicto con las reglas del mempool público de Frames. EIP-8272 resuelve estos problemas exponiendo un contrato del sistema para almacenar estas raíces en un búfer circular que purga automáticamente las raíces antiguas.
• Lo colocamos en el nivel B porque este EIP agrega una complejidad significativa a los frames para un caso de uso específico, y no estamos seguros de si podría haber una forma más general/elegante de lograr el mismo objetivo.

[CL] EIP-8369: Perfiles VOPS para Elegibilidad de FOCIL [Nivel B]

• Este EIP aborda la interacción entre Frames y VOPS (falta de estado parcial solo de validez), que es una propuesta para permitir que los nodos del mempool almacenen suficiente estado para validar transacciones, de modo que incluso en un mundo de falta de estado (debido a zkEVM) el mempool pueda permanecer resistente a la censura.
• Lo colocamos en el nivel B porque este EIP está fuertemente vinculado a una visión particular de falta de estado en la que la comunidad aún no se ha alineado completamente.

[EL] EIP-7906: Afirmaciones de Transacción a través de Opcode de Diferencia de Estado [Nivel B]

• Este EIP mejora la auditabilidad estática de los resultados de las transacciones. Los usuarios ya pueden afirmar lo que debería suceder, pero no que no haya sucedido nada más. Probar la ausencia de cambios de estado requiere un nuevo opcode. La combinación de afirmaciones positivas (por ejemplo, el saldo de WETH aumentó en al menos 1.5) con una afirmación negativa (ningún otro estado cambió) permite a los usuarios acotar los efectos completos de una transacción por construcción, sin simulación, siendo las billeteras de hardware un claro beneficiario.
• Dada la complejidad, incluirlo en la bifurcación dura sería una elección muy comprometedora. Sugerimos hacer esto solo si (a) los equipos de clientes realmente entienden los matices y las implicaciones de este EIP específico, y (b) la superficie de prueba y las complejidades se entienden muy bien.

[EL] Migración de EOA [Nivel B]

[EL] EIP-7851: Delegación de EOA Controlada por Código [Nivel B] y [EL] EIP-8151: ecRecover Restringido por Código de Cuenta [Nivel B] se ven mejor como estándares emparejados que juntos presentan una historia de cómo las EOA pueden hacer la transición a cuentas inteligentes. En esta historia, una EOA primero delegaría a una cuenta inteligente a través de EIP-7702. Luego, el opcode que introduce EIP-7851 haría permanente la delegación 7702, deshabilitando la clave ECDSA raíz. Por otro lado, EIP-8151 haría que ecrecover fuera consciente de la desactivación, para que la clave antigua no pueda drenar fondos a través de flujos de tipo Permit.

Calificamos este par en el nivel B porque es solo uno de los muchos enfoques para migrar EOA a cuentas inteligentes, y este enfoque particular no ha recibido una amplia revisión o aceptación. En particular, nos preocupa que este enfoque no responda a la pregunta de múltiples cadenas: ¿cómo migra la misma EOA en L2? El usuario tendría que realizar la misma acción en TODAS las cadenas, incluidas las cadenas que aún no existen, lo que resultará en una mala UX. Sospechamos que puede haber un mejor enfoque donde las L2 puedan aprovechar la L1 como la "raíz de confianza" para la migración de EOA, por lo que reservamos los niveles A/S para enfoques que permitirían a los usuarios migrar una vez para todas las cadenas EVM.

[EL] Esquema de firma PQ [Nivel A]

Hegotá debería establecer un camino creíble hacia las firmas post-cuánticas, pero deberíamos confirmar el mecanismo correcto antes de comprometernos.

• EIP-8355: Agregar verificación ML-DSA precompila, haciendo que la seguridad de la cuenta post-cuántica sea concreta junto con Frame Transactions.
• Alternativa: Preregistrar el soporte PQ sin activarlo, o definir un formato de derivación que pueda acomodar claves PQ más adelante.

[EL] EIP-7819: Instrucción SETDELEGATE [Nivel A]

• Con la AA nativa probablemente llegando en Hegotá, es importante que el costo de implementar nuevas cuentas inteligentes sea bajo, pero implementar cuentas en realidad será más costoso en Glamsterdam debido a EIP-8037. Con EIP-7819, las nuevas cuentas usarían punteros de delegación simples en lugar de contratos proxy, lo que reduce en gran medida la cantidad de nuevo estado que necesita crearse, reduciendo así el costo de implementación.
• Colocamos este EIP en el nivel A porque creemos que un costo de implementación de cuenta más bajo reduciría significativamente la fricción para adoptar AA.

3. Ingeniería de rendimiento: escalado continuo de L1

Glamsterdam ha marcado un cambio en la forma en que Ethereum aborda la I+D, con el rendimiento tratado como una restricción de I+D de primera clase, tanto en el diseño del protocolo como en el trabajo del cliente. La ejecución retrasada, los redimensionamientos de precios de recursos y mucho trabajo de optimización del cliente permiten escalar de 30M a (al menos) 200M en los últimos dos años. En general, el trabajo de rendimiento nos da opcionalidad: el margen que ganamos se puede usar para escalar, para acortar las ranuras, para reducir los requisitos de los nodos, o todo lo anterior.

Hoy, todavía vemos el escalado continuo como una necesidad. Las aplicaciones deciden dónde construir basándose no solo en los precios actuales, sino en si Ethereum puede expandir la oferta de espacio de bloques de manera predecible a lo largo del tiempo. Entregar aumentos de manera consistente proporciona más certeza que los compromisos de la hoja de ruta por sí solos. La capacidad de la red principal también está todavía muy lejos de poder manejar picos de demanda: en el undécimo cumpleaños de Ethereum, la tarifa base mediana diaria era de solo ~0.1 gwei, sin embargo, una acuñación de NFT la elevó por encima de 10 gwei durante algún tiempo, con costos de transacción medios alcanzando aproximadamente $1 y el percentil 90 más de $5. Por lo tanto, el impulso de escalado de Glamsterdam debería continuar en Hegotá.

En conjunto, los siguientes EIP continúan el impulso de escalado de Glamsterdam al tiempo que refuerzan el principio más amplio detrás de él: el rendimiento debe seguir siendo una preocupación de primera clase tanto en el trabajo del cliente como en el diseño del protocolo.

[EL] EIP-8131 y EIP-8279 [Nivel S]: Paquete de redimensionamiento de precios de datos

Después de Glamsterdam, la siguiente restricción vinculante es la propagación de payload, en parte porque diferentes fuentes de bytes de payload se reflejan de manera inconsistente, o no se reflejan en absoluto, en la contabilidad de gas. EIP-8131: Piso de Contenido de Transacción Unificado extiende el piso de transacción existente al contenido conocido antes de la ejecución, mientras que EIP-8279: Piso de Bytes de Lista de Acceso de Bloque cubre los bytes de BAL creados dinámicamente durante la ejecución.

Esta medición dinámica hace que EIP-8279 sea claramente el más complejo de los dos. Sin embargo, sugerimos pensar en ellos como un paquete. Juntos, establecen una contabilidad consistente para los bytes asociados con una transacción, limitando el payload en el peor de los casos sin afectar a la mayoría de las transacciones ordinarias y no intensivas en datos. Esto soluciona la brecha en la contabilidad de recursos y allana el camino para futuros aumentos del límite de gas.

[CL][EL] EIP-8146: Sidecars de Lista de Acceso de Bloque [Nivel A]

EIP-8146 complementa los reajustes de precios al mejorar la ruta crítica en sí misma, propagando los BAL por separado del payload, lo que mejora la propagación y les da a los clientes de ejecución una ventaja inicial en la precarga de estado y el cálculo de la raíz de estado posterior. Vemos esto como el tipo de optimización de bajo costo que no deberíamos dejar pasar. El trabajo de implementación es principalmente el mecanismo de gossip familiar del CL, lo que convierte a este EIP en una propuesta de bajo esfuerzo y alto valor, especialmente en una bifurcación que se perfila como bastante pesada en EL.

Otros EIPs relacionados

[EL] Recalibración de CPSB [Nivel A]

• Cambios muy simples, recomendamos mantenerlos en el pipeline e incluir uno de los dos si se considera necesario según los aumentos planificados del límite de gas y el uso observado del gas de estado y ejecución.
• EIP-8368: Recalibración de CPSB para el Nuevo Límite de Gas: Seguimiento preplanificado de EIP-8037, que compensa el hecho de que el costo por byte de estado (CPSB) se ha vuelto estático en lugar de una función del límite de gas, puramente como una simplificación de implementación y prueba. La idea era reemplazar el ajuste bloque por bloque con ajustes únicos en las bifurcaciones, según sea necesario para mantener el crecimiento del estado en el objetivo a medida que aumenta el límite de gas. Dado que el CPSB actual se calibró con un límite de gas de 150M, es probable que se justifique un ajuste en Hegotá.
• EIP-8372: Límite de gas de estado normalizado: Sigue siendo un superconjunto bastante mínimo de EIP-8368, que permite un ajuste más granular que solo el CPSB, compensando ya sea el objetivo de crecimiento del estado o el objetivo de gas regular que no se alcanza debido a una fijación de precios relativa incorrecta.

[EL] EIP-7862: Raíz de Estado Retrasada [Nivel B]

• Simple de especificar, pero la complejidad de las implementaciones del cliente no se comprende muy bien hasta donde sabemos. La raíz de estado es omnipresente en las bases de código.
• Si bien existe cierto beneficio en reducir la barrera de acceso a la construcción competitiva (cálculo rápido de la raíz de estado), la ventaja más sustancial del EIP está en el futuro, en nuestra opinión (más tiempo para probar el cálculo de la raíz de estado).
• EL ya es el lado pesado de Hegotá.

[CL] EIP-8341: Compromisos de Payload de Ejecución Parcial [Nivel D]

• Recomendamos rechazar: beneficio pequeño (retrasar ligeramente el cálculo de la raíz de estado), no es urgente y es reemplazado por EIP-7862: Raíz de Estado Retrasada (que da mucho más tiempo para ello).

Otros EIPs

Ahora cubrimos el resto de los EIPs, agrupados libremente por temas. Sobre algunos EIPs todavía estamos formando nuestra opinión. Actualizaremos este documento a medida que aprendamos más de los equipos de clientes y los autores de los EIPs en los próximos días y semanas.

Dado que Hegotá se perfila como una bifurcación dura sesgada hacia EL, sugerimos mantener la disciplina y mantener un listón alto para que cualquier EIP del lado de EL lo supere. Creemos que mantener Hegotá relativamente ligero en CL más allá de FOCIL y Quick Slots es deseable: un alcance más limitado preserva el ancho de banda para darles a los equipos de clientes espacio para prepararse para la transición arquitectónica más grande.

[CL] Emisión

Intencionalmente no asignamos un nivel a EIP-8363: Quema de Emisión Reducida. Creemos que la emisión no es una decisión que los desarrolladores principales deban tomar solos, y una lista de niveles es una recomendación explícita para los desarrolladores principales. Para la mayoría de los EIPs, el proceso ACD funciona bien porque las decisiones son principalmente técnicas, y la comunidad los ha delegado efectivamente a los desarrolladores principales. La emisión es diferente en el sentido de que es una cuestión de política monetaria sobre la cual la propia comunidad debe alcanzar un consenso aproximado. Las opiniones de los desarrolladores principales importan, pero como aporte a esa discusión pública. Clasificar EIP-8363 junto con los otros EIPs lo trataría como una decisión ACD normal, lo que creemos que no debería ser.

Técnicamente, vemos mérito en cambiar la emisión en línea con EIP-8363. Los problemas que aborda son reales: la credibilidad del slashing se erosiona a medida que se apuesta más ETH, las altas tasas de participación significan que las recompensas compensan principalmente la dilución, y las economías de escala siguen ampliando la brecha entre los grandes operadores y los stakers individuales. Un cambio también conlleva riesgos, desde la incertidumbre de los efectos en la distribución de la participación hasta reiniciar el reloj de osificación de la política monetaria. El hilo de Ansgar expone ambos lados y refleja nuestra posición. Algunos de nosotros hemos argumentado a favor de cambios en la emisión en el pasado y seguimos teniendo convicción en ese camino.

Recomendamos tomar la decisión sobre la emisión después de todas las demás decisiones de alcance de Hegotá. Esto le da a la discusión comunitaria el tiempo que necesita y evita distraerse del proceso de definición del alcance en sí.

[CL] Funcionalidades de staking

Las mejoras en el staking pueden ser valiosas, pero los beneficios orientados al usuario deben tener prioridad sobre los cambios solo de infraestructura, a menos que sean estrictamente necesarios.

[CL] EIP-8015: Eliminar campos de depósito y eth1data [Nivel A]

• Limpieza muy simple de deuda técnica. Gracias a EIP-7688: Estructuras de datos de consenso compatibles con versiones anteriores, las pruebas Merkle de campos no relacionados no se ven afectadas, por lo que no hay impacto en los consumidores de la cadena.

[EL][CL] EIP-8237: Sincronización Independiente de CL/EL [Nivel B]

• Se basa en la separación del bloque beacon y el payload introducida por ePBS, para permitir que EL y CL se sincronicen de forma independiente. Creemos que esto tiene el potencial de simplificar una parte compleja de los clientes de Ethereum.

[CL] EIP-8205: Prerregistro de credenciales de retiro [Nivel D]

• Recomendamos rechazar. Si bien el EIP proporciona una solución dentro del protocolo para un problema real en el staking delegado, creemos que la solución de predepósito existente es adecuada y la complejidad de la maquinaria agregada no está justificada actualmente.

[CL] EIP-8148: Umbral de barrido personalizado para validadores [Nivel D]

• Recomendamos rechazar. Creemos que el EIP es demasiado complejo (nuevo contrato del sistema, nueva solicitud de ejecución, maquinaria CL) para sus beneficios, que vemos principalmente como fomentar una consolidación adicional marginal del grupo de operadores domésticos. No creemos que esto tenga mucho efecto en la consolidación general de validadores dada la distribución de la participación.

[CL] EIP-8375: Quema Obligatoria de Recompensas de Ejecución en ePBS [Nivel D]

• Recomendamos rechazar. Creemos que esto probablemente solo conducirá a más canales laterales. Además, años de discusiones sobre estrategias de quema de MEV no llevaron a ninguna propuesta que alcanzara un amplio consenso de investigación.

[CL] EIP-7716: Penalizaciones de atestación por anticorrelación [Nivel D]

• Recomendamos rechazar. No creemos que haya suficiente evidencia clara de que un cambio tan grande en los incentivos de staking esté justificado. Además, es probable que los incentivos de staking se reformulen como parte del consenso desacoplado.

[CL] EIP-8333: Alinear el Checkpoint con el Bloque de Límite de Época [Nivel D]

• Recomendamos rechazar. Si bien es una buena limpieza, creemos que vale la pena posponerlo para la próxima gran transición de consenso desacoplado.

[CL] EIP-8359: Campo de Reporte de Bloque Beacon [formando opinión]

[CL] Más preparación PQ

Estas propuestas reducen las dependencias BLS restantes antes de una futura transición post-cuántica.

[CL] EIP-8365: Retiro de credenciales de retiro BLS [Nivel A]

• Retira una credencial de retiro heredada, preparando el escenario para simplificaciones del protocolo y simplificando la futura transición PQ.
• Dado lo simple que es, creemos que vale la pena incluirlo ahora.

[CL] EIP-8367: Liquidación de saldo para validadores BLS retirados [Nivel D]

• Recomendamos rechazar. Creemos que es probable que la mayoría de los validadores 0x0 realicen un cambio de credencial (BLSToExecutionChange) antes o después de que se active EIP-8365: Retiro de credenciales de retiro BLS, ya sea para retirar sus fondos o para poder seguir haciendo staking. No creemos que haya una gran urgencia para introducir un mecanismo para manejar la participación 0x0 restante. Recomendamos incluir solo EIP-8365 y ver el resultado de eso antes de decidir los próximos pasos.

[CL] EIP-8321: RANDAO de Cadena Hash [Nivel D]

• Recomendamos rechazar. Hacer que RANDAO sea seguro post-cuántico de forma aislada proporciona poca seguridad a nivel de protocolo mientras las claves BLS del validador sigan siendo vulnerables, pero agrega aproximadamente 32 bytes por validador, nueva maquinaria de gestión de secretos y un mecanismo en gran medida de un solo propósito. El diseño de consenso PQ más amplio sigue sin resolverse. Apoyamos una transición iterativa, pero su primer paso debe seguir una hoja de ruta acordada en lugar de correr el riesgo de ser reemplazado por el diseño final.

[EL][CL] Preparación para zkEVM

La mayoría de la preparación para zkEVM ofrece beneficios a corto plazo limitados más allá de facilitar la operación de nodos completos para un conjunto reducido de usuarios, mientras consume ancho de banda de implementación y potencialmente hace que la EVM sea más costosa. Solo debemos incluir cambios cuyo valor a largo plazo justifique claramente esos costos inmediatos.

[CL] EIP-8025: Pruebas de Ejecución Opcionales [Nivel D]

• El EIP no requiere una bifurcación dura. La propuesta de incluirlo con Hegotá es puramente una expresión de priorización, y no estamos de acuerdo con esa elección. Creemos que se debe continuar trabajando en ello, pero Hegotá no debería verse bloqueada por esto.
• Antes de enviar pruebas opcionales, debemos trabajar para definir primero el estado final, luego acelerar hacia eso, en lugar de enviar pruebas opcionales antes de tener una visión clara del modelo de validador/estado a largo plazo.
• La pregunta abierta fundamental es qué papel deben tener los validadores con respecto al estado: si deben seguir sirviendo o manteniendo parte de él, en lugar de volverse completamente sin estado. Debido a que los validadores son un grupo central de nodos con valor real de hardware y red, los cambios que debilitan ese rol deben superar un listón más alto.

[EL] EIP-7666: Convertir la precopilación de identidad en EVM [Nivel A]

• Cambio útil y pequeño

[EL] EIP-8200: EVMificación [Nivel B]

• EIP-8200 reemplaza tres precopilaciones nativas con bytecode EVM equivalente. Dos tienen poco uso y parecen sencillas de migrar. La tercera se usa ampliamente en la verificación SNARK, por lo que nos gustaría una evaluación de impacto antes de apoyar su eliminación.
• Si el análisis de impacto encuentra bajos costos de migración para los usuarios afectados, o si la tercera precopilación se elimina del alcance, moveríamos EIP-8200 al [Nivel A].

[EL] EIP-7709: Leer BLOCKHASH del Almacenamiento y Actualizar el Costo [Nivel D]

• Bastante disruptivo debido al gran aumento en el costo de gas, no es urgente.
• Reducir el riesgo podría implicar un análisis de impacto, o hacerlo más tarde con alguna forma de calentamiento a nivel de bloque (o calentamiento ad-hoc de estos valores) para reducir el impacto.

[EL] EIP-8268: Raíces de Almacenamiento en Listas de Acceso de Bloque [Nivel B]

• Podría necesitar un análisis del impacto concreto en los tamaños de BAL y el impacto relacionado en los costos de transacción (EIP-8279 propone cobrar por los bytes de BAL), ya que la entrada de BAL para cada cuenta tocada obtiene una raíz de trie de almacenamiento adicional.

[EL] Funcionalidades de EVM

Hegotá aún requerirá algunas decisiones ad-hoc de EVM. Creemos que después de Hegotá, Ethereum debería trabajar hacia una hoja de ruta de EVM a largo plazo moldeada por el ecosistema EVM más amplio. Ethlabs contribuirá a eso.

[EL] EIP-5920: Opcode PAY [Nivel A]

• Muy simple, y creemos que es un buen primitivo para que la EVM lo tenga.
• Sería importante comprender mejor los casos de uso concretos.

[EL] EIP-8163: Reservar el opcode EXTENSION (0xae) [Nivel A]

• Muy útil para L2s, sin costo real para L1 (solo informativo).

[EL] Reutilización / deduplicación de código [Nivel B]

• EIP-8058: Descuento por Deduplicación de Bytecode de Contrato y EIP-8298: Instrucción de Reutilización de Código SETCODEFROM ambos intentan aprovechar el hecho de que el código del contrato se almacena por separado de la cuenta correspondiente en los clientes, con el hash del código como puntero entre ellos. Por lo tanto, el código compartido idéntico se puede almacenar deduplicado. Ambos EIPs permiten una forma de establecer económicamente el codehash de la cuenta al hash de un código existente en otro lugar.
• Consideramos que esta es una idea general atractiva, pero sería importante comprender las implicaciones y la compatibilidad futura con los árboles binarios. Sin preferencia por ahora entre los dos.

[EL] Reforma de precios de memoria [Nivel B]

• Necesitamos decidir si queremos o no hacer una reforma de memoria en Hegotá. No nos queda claro que actualmente tengamos una comprensión suficiente del espacio de diseño para hacer esta evaluación.

EIP-7686: Límites de memoria EVM lineales

• Cambio más pequeño, solo elimina el costo de expansión de memoria cuadrática.

EIP-7923: Costo de memoria lineal basado en páginas

• Refactorización más profunda y basada en principios, pero más compleja.

[EL] EIP-8219: Opcodes de Aritmética Verificada [Nivel B]

• En general, agregar matemáticas seguras a la EVM parece útil.
• Sería necesario confirmar los precios con puntos de referencia, ¿qué tan complejo es eso?
• Con puntos de referencia y un análisis de impacto (¿cuántas transacciones podrían beneficiarse, cuánto, qué compiladores agregarían soporte?) podría ser de Nivel A.

[EL] EIP-8360: Opcode TCREATE [Nivel B]

• El EIP introduce la capacidad de crear contratos temporales con alcance de transacción. Este es un buen primitivo para tener en general.
• El EIP agrega una complejidad significativa. Con una evaluación más exhaustiva de la complejidad de implementación y prueba, podría ser de Nivel A.

[EL] EIP-7645: Alias ORIGIN a SENDER [Nivel D]

• Recomendamos rechazar: Cambio disruptivo, uso inadecuado de ORIGIN.

[EL] EIP-8182: Transferencias Privadas de ETH y ERC-20 [Nivel D]

• Recomendamos rechazar: Cambio enorme, agrega dependencias zk. Si alguna vez se introduce, creemos que debería ser un titular.

[EL] EIP-2488: Desaprobar el opcode CALLCODE [formando opinión]

[EL] EIP-4758: Desactivar SELFDESTRUCT [formando opinión]

[EL] EIP-7979: Opcodes de Llamada y Retorno para la EVM [formando opinión]

[EL] EIP-8173: Fundamentos del Flujo de Control de la EVM [formando opinión]

[EL] EIP-8253: Aumentar el nonce de cuentas de almacenamiento con nonce cero [formando opinión]

[EL] EIP-8030: Soporte del algoritmo P256 [formando opinión]

[EL] Precios de EVM

Glamsterdam aumentó los precios de las operaciones infravaloradas que limitaban el rendimiento general. Las propuestas de precios de EVM de Hegotá abordan principalmente el otro lado: reducir los precios de las operaciones individuales cuyo costo actual limita su uso, pero no la escalabilidad de la red. Por lo tanto, son mejoras deseables pero no esenciales con un impacto menor por EIP. Estamos abiertos a reajustes de precios específicos, pero las propuestas que introduzcan nuevos mecanismos de medición solo deben incluirse si su diseño es sólido y está suficientemente desriesgado por un campeón comprometido.

[EL] EIP-8358: Medición Neta de Gas para Cambios de Cuenta [Nivel B]

• No estamos convencidos del impacto. En 900 bloques de mainnet muestreados, ~400k transacciones: el 2.07% de todas las transacciones ahorrarían gas y se ahorraría el 1.14% del gas del bloque.

[EL] EIP-7973: Medición de Escritura de Cuenta Caliente [formando opinión]

[EL] EIP-7609: Disminuir el costo base de TLOAD/TSTORE [formando opinión]

[EL] EIP-7971: Límites Estrictos para el Almacenamiento Transitorio [formando opinión]

[EL] EIP-3298: Eliminación de reembolsos [formando opinión]

[EL] EIP-8374: Persistir Conjuntos de Acceso Calientes a Través de Reversiones [formando opinión]

[EL] EIP-8115: Tarifas de prioridad por lote al final del bloque [formando opinión]

[EL] EIP-8188: Último Bloque Escrito para Cuentas y Slots [formando opinión]

[EL][CL] Datos de ejecución e indexación

[EL][CL] EIP-7668: Eliminar filtros bloom [formando opinión]

[EL][CL] EIP-7807: Bloques de ejecución SSZ [formando opinión]

[EL] EIP-8116: Reemplazar campos de recibo acumulativos [formando opinión]

[EL] EIP-8304: Índice de transacciones y logs sin confianza [formando opinión]

[EL][CL] Redes

La capa P2P de Ethereum tiene espacio para mejoras específicas, especialmente en cómo se propagan las transacciones, los blobs y las atestaciones a través de la red.

[CL] EIP-8371: RowDAS - Reconstrucción Distribuida de Blobs [Nivel A]

• Generalmente evita que la reconstrucción completa y el rendimiento del nodo de custodia completa sean un cuello de botella para escalar el número de blobs.
• Valioso, eventualmente alguna forma de reconstrucción distribuida definitivamente debería abrirse camino en el protocolo. Esto podría permitirnos eliminar la custodia del validador.
• Necesitamos comprender mejor la complejidad.

[CL] EIP-8142: Bloque en Blobs (BiB) [Nivel D]

• Prematuro, sin urgencia fuerte, bastante de último minuto, muchas preguntas pendientes (¿KZG o no? ¿Nuevos temas de gossip o no?).
• No queremos introducir KZG en la ruta crítica de la producción de bloques, las alternativas no están claras y agregarían más complejidad.

[CL] EIP-8243: Agrupación de Atestaciones en el Origen [Nivel D]

• No está claro si podemos confiar en esto para disminuir el tiempo hasta la finalidad, no pone un límite claro a la carga.
• La resistencia a DoS del mecanismo no está del todo clara.

[EL] EIP-8077: eth/XX - anunciar transacciones con nonce [formando opinión]

[EL] EIP-8094: eth/vhash - Mempool Consciente de Blobs [formando opinión]

[CL] EIP-8334: Propagación de Atestaciones Agrupadas [formando opinión]

Si de alguna manera todavía estás con nosotros, gracias por leer hasta el final. No dudes en responder con cualquier pregunta, ¡y haremos nuestro mejor esfuerzo para responderte! Si te saltaste y solo te desplazaste hasta aquí porque leer un muro de texto gigantesco no era cómo decidiste pasar tu domingo, te complacerá saber que esta siguiente parte es breve.

Unas (pocas) palabras más...

Las actualizaciones de Ethereum son complejas porque hay mucho en juego. Miles de nodos en todo el mundo cambian a nuevas reglas en la misma ranura, y la red no se detiene ni por un segundo mientras lo hacen. Ese rigor ha respaldado cada actualización que Ethereum ha lanzado, resultando en una red descentralizada que ha celebrado 11 años de 100% de tiempo de actividad.

Nuestras posiciones sobre Hegotá son nuestras mejores evaluaciones a día de hoy, pero actualizaremos nuestro pensamiento siempre que nueva evidencia de discusiones o trabajo de implementación cambie nuestra opinión.

Algunos de estos EIPs fueron escritos o impulsados por miembros de Ethlabs, otros provienen de la increíblemente vasta, talentosa y bien intencionada comunidad de investigadores, desarrolladores de clientes y colaboradores individuales en todo Ethereum. Sin embargo, todos ellos requerirán colaboración entre equipos de clientes, billeteras, aplicaciones, L2s, proveedores de infraestructura, instituciones, operadores de nodos y, en última instancia, usuarios para tener éxito. Ethereum es el proyecto compartido del mundo, y el progreso significativo de la red nunca es el trabajo de una sola organización.

Estamos agradecidos de ser una pequeña parte de este ecosistema, y esperamos ayudar a Ethereum a realizar su potencial.

– Ethlabs