Hegotá EIP: ¿Hacia dónde se dirige la próxima bifurcación dura de Ethereum?

Ethlabs detalla la lógica detrás de las decisiones sobre cada EIP.

Escrito por: Ethlabs

Compilado por: Chopper, Foresight News

La dirección del desarrollo de Ethereum es crucial para todos aquellos que construyen aplicaciones, utilizan la red, poseen ETH y creen en el potencial futuro de Ethereum. El rumbo a largo plazo de Ethereum será determinado por los participantes que diariamente construyen productos, operan aplicaciones y forman parte de la comunidad, pero las actualizaciones de la red son el medio central para la iteración del protocolo y la adaptación a las necesidades de los usuarios. Hegotá es la próxima actualización de la red planificada por Ethereum, después de Glamsterdam. Este artículo expondrá las direcciones y razones que Ethlabs considera prioritarias para avanzar en esta actualización.

Actualmente, el alcance de la actualización de Hegotá está siendo definido preliminarmente a través del proceso técnico público de Ethereum. Las propuestas mencionadas a continuación reúnen los esfuerzos de numerosos desarrolladores, equipos de investigación y equipos de clientes. Este artículo presenta claramente las direcciones que Ethlabs sugiere priorizar, así como las opiniones que aún no hemos concluido. Damos la bienvenida a la evaluación, cuestionamiento y mejora de estas propuestas por parte de todos los sectores de la industria; en los próximos días y semanas, a medida que continúen las discusiones y se actualice la información, también iremos iterando nuestras opiniones.

Para la actualización de Hegotá, considerando todas las EIP propuestas, creemos que las siguientes áreas son las prioridades de Ethereum:

• Mayor resistencia a la censura: Cualquiera, independientemente de su identidad o propósito, debe poder hacer que sus transacciones sean incluidas en un bloque;
• Ethereum más rápido: Un tiempo de bloque más corto significa confirmaciones de transacciones más rápidas, precios en tiempo real en la cadena y un tiempo de confirmación final más corto;
• Abstracción de cuentas nativa: Las cuentas deben soportar claves de acceso, patrocinio de transacciones, pago de Gas con tokens, transacciones en lote y una mayor protección de la privacidad, además de reservar un camino de actualización para claves post-cuánticas;
• Expansión continua de L1: Incluso en períodos de máxima demanda, las aplicaciones deben poder obtener capacidad de red estable y asequible.

Nota previa: ¿Cómo funciona el proceso de avance de EIP?

Antes de interpretar formalmente las propuestas, aclaremos el contexto clave: el alcance de la actualización de Hegotá ha comenzado a definirse en esta segunda fase. La primera fase ya ha determinado a FOCIL como la propuesta central de actualización de Hegotá. La fecha límite para las propuestas de EIP no centrales es el 6 de agosto, después de lo cual la reunión de ACD evaluará completamente el plan general de la actualización de Hegotá.

Todas las EIP mencionadas a continuación se encuentran actualmente en la fase PFI (Propuesta para Inclusión). No se requiere permiso para presentar EIPs a la propuesta de actualización, pero la gran mayoría de las propuestas finalmente no se incluirán en la actualización formal.

A medida que el desarrollo avanza, las propuestas pasarán por múltiples rondas de revisión, con fases que se elevan gradualmente y una certeza de implementación que aumenta continuamente:

PFI (Propuesta para Inclusión): La propuesta se presenta para esta actualización. Esta fase no tiene umbral de entrada, no representa el apoyo del cliente y no garantiza que se implemente finalmente;

CFI (Consideración para Inclusión): El equipo del cliente completa la revisión y planea desarrollar y probar un prototipo;

SFI (Confirmación para Inclusión): Las partes están generalmente de acuerdo en incluirla, siempre que el desarrollo y las pruebas avancen sin problemas.

Para entender el proceso completo, se recomienda ver el video explicativo de Tim Beiko. (https://www.youtube.com/watch?v=-S4blFZl28g)

Guía de lectura

Este artículo utiliza el estándar de clasificación de Forkcast para expresar el juicio de prioridad de Ethlabs sobre cada EIP de Hegotá. Para simplificar la toma de decisiones, todas las propuestas evaluadas se dividen en cinco categorías:

• 【S】 Fuertemente recomendado para inclusión
• 【A】 Recomendado para inclusión si se resuelven obstáculos como la dificultad de desarrollo, evaluación de impacto y aterrizaje ecológico
• 【B】 Tiene valor, pero la inclusión en esta actualización es difícil
• 【D】 En las condiciones actuales, no se recomienda incluir en Hegotá
• 【Opinión en formación】 Aún estamos evaluando esta EIP

⚠️ Nota: Lo anterior es solo una sugerencia de Ethlabs. Nuestra evaluación se basa principalmente en los objetivos de la propuesta, especificaciones técnicas y la complejidad estimada del desarrollo; para proyectos que participan profundamente (como Frames, Quick Slots), tenemos información más completa. En el futuro, combinaremos la retroalimentación de ethPandaOps, equipos de prueba y diversos clientes para actualizar continuamente nuestras opiniones. La etiqueta 【CL】 representa el impacto en el cliente de la capa de consenso; 【EL】 representa el impacto en el cliente de la capa de ejecución.

Además, Ethlabs ha participado en la redacción de varias EIP (incluyendo FOCIL, Frame Transactions, Quick Slots). Nos esforzamos por evaluar todas las propuestas de manera objetiva, sin que nuestra participación influya, pero los lectores pueden tener en cuenta este contexto al considerar nuestras opiniones.

Lista de prioridades CL

Lista de prioridades EL

Sin más preámbulos, aquí están las opiniones completas de Ethlabs sobre la actualización de Hegotá en esta etapa.

Cuatro direcciones clave de Hegotá

FOCIL: Fortalecimiento de la resistencia a la censura

EIP-7805 FOCIL ha entrado en la fase SFI, siendo formalmente confirmada como la propuesta central de Hegotá. Tres miembros de Ethlabs (Francesco, Barnabé, Julian) son coautores de esta propuesta, y apoyamos plenamente su implementación. Dado que el plan ya está definido, aquí solo se expone brevemente: solo una cadena de bloques que mantenga la neutralidad para todos puede convertirse en la base de confianza para todos. Esta es la piedra angular para la expansión de Ethereum y su crecimiento como la verdadera capa de liquidación de la economía global, sirviendo a cada participante.

Quick Slots: Un Ethereum más rápido

El actual intervalo de 12 segundos de Ethereum genera una alta latencia, perjudicando la experiencia del usuario. Por lo tanto, recomendamos encarecidamente incluir en Hegotá el 【CL】EIP-8198 Quick Slots【S】, por cuatro razones clave:

• Aumento de la velocidad de confirmación de transacciones para usuarios de L1, mejorando la experiencia;
• El mercado en la cadena de L1 obtiene datos de precios actualizados, mejorando el diferencial de compra-venta y los ingresos de los proveedores de liquidez;
• La certeza final y las reglas de confirmación rápida están vinculadas a la duración del intervalo, bloques más rápidos mejorarán la interoperabilidad entre cadenas de Ethereum;
• Aumento en el número de proponentes de bloques por segundo, mejorando la resistencia a la censura, incluyendo la resistencia económica a la censura: el costo de implementar censura mediante el vaciado continuo de bloques será más alto.

Reducir el intervalo de bloques manteniendo las características de descentralización de Ethereum puede aumentar el valor del espacio de bloques de Ethereum, y los beneficios regresarán a la red y a ETH mismo. Cada reducción de latencia crea valor directo para los usuarios. Además, la aceleración es una de las direcciones de mejora más solicitadas por los desarrolladores de aplicaciones.

Iniciar la transformación en este momento es razonable; el ajuste de la duración del intervalo no puede hacerse de una sola vez. Al igual que con la idea de expansión, la optimización iterativa basada en pruebas reales proporciona más certeza a los desarrolladores de aplicaciones que una simple promesa de hoja de ruta. Lograr intervalos de menos de 6 segundos es un objetivo a largo plazo, y el camino se divide en dos pasos:

• Reestructuración única: permitir que las especificaciones y el código del cliente soporten modificaciones flexibles en la duración del intervalo;
• Completar la primera reducción en Hegotá, y luego continuar reduciendo en futuras bifurcaciones duras, acumulando datos de operación segura.

Hegotá es el momento adecuado para asumir el costo de reestructuración única. La lógica relacionada con el intervalo ya ha sido reestructurada en la actualización de Glamsterdam; los cambios en la capa de consenso de esta actualización son relativamente controlables. Una vez que se abra la ventana de actualización de consenso desacoplada, los recursos de desarrollo de la capa de consenso estarán muy limitados, y será difícil tener otra ventana de este tipo en futuras bifurcaciones duras.

En resumen, o mantenemos un intervalo de 12 segundos durante al menos dos años, o logramos un intervalo de 10 segundos en la actualización de Hegotá dentro de un año, con la esperanza de reducirlo a menos de 10 segundos en la próxima ronda. Estas dos aceleraciones no son solo optimizaciones teóricas, pueden aumentar directamente el valor para los usuarios y optimizar el modelo económico de la red. Creemos que el momento es adecuado.

Respuesta a las principales controversias

Hemos recopilado cuatro preocupaciones principales que surgieron en las conversaciones preliminares con los equipos de desarrollo de clientes y el equipo de protocolo de la Fundación Ethereum:

• Complejidad de desarrollo. La lógica de temporización de milisegundos ya se ha integrado en las especificaciones de consenso a través de ePBS; las especificaciones de la capa de consenso y de ejecución de EIP-8198 se han completado, y se han realizado todos los cálculos para las tarifas base, el límite de Gas y la programación de Blob, asegurando la estabilidad del comportamiento de la red por segundo. El trabajo restante se centra en adaptar diversas herramientas de cliente y pruebas de escenarios límite bajo la suposición de intervalos fijos. Una vez completada esta reestructuración, los intervalos futuros solo requerirán ajustes de parámetros.
• Presión de prueba de zkEVM. Hay dos preocupaciones principales: la duración relativa de la prueba y el costo fijo de la prueba. 1) Duración relativa de la prueba: la proporción de tiempo disponible para la prueba dentro del intervalo. Los constructores de bloques actuales pueden comenzar a construir tan pronto como reciben la carga del bloque anterior; el bloque de referencia confirma la carga del intervalo actual. La carga debe ser probada antes de que el siguiente proponente de referencia publique un bloque. El tiempo mínimo disponible para completar la prueba es aproximadamente igual a un intervalo menos la latencia de propagación del bloque de referencia. La latencia de propagación es difícil de reducir, pero su valor es relativamente pequeño y no representa un cuello de botella crítico en esta etapa. Los constructores de bloques optimizados pueden llevar a cabo la prueba en paralelo mientras ensamblan la carga, sin tener que esperar a que la carga ganadora sea confirmada por el bloque de referencia. 2) Costo de prueba de zkEVM: el tiempo de prueba está generalmente relacionado de manera lineal con el tamaño del bloque, pero hay un costo fijo. Un tiempo de bloque más rápido significa que la frecuencia de activación del costo fijo aumenta, lo que incrementa la latencia bajo un mismo rendimiento. Con un presupuesto de latencia fijo, es necesario garantizar que el rendimiento no se vea afectado de manera significativa. Existen dos caminos de mejora en la industria: iteraciones de ingeniería que continúan reduciendo el tiempo de operación fijo; EIP-7862 que retrasa el cálculo de la raíz de estado, moviendo gran parte del trabajo de prueba fuera de la ruta crítica. Avanzar en ambas direcciones significa que intervalos más rápidos no obstaculizarán el crecimiento continuo del rendimiento en el futuro.
• Ruta de actualización post-cuántica. La solución de consenso desacoplada ha recibido suficiente apoyo, convirtiéndose en la dirección estable para la futura arquitectura de consenso. El desacoplamiento significa mover la votación de confirmación final fuera de la ruta crítica de producción de bloques. La agregación a gran escala de firmas post-cuánticas y la lógica relacionada con STARK recursivos se separarán de la ruta crítica. La producción de bloques y las reglas de selección de bifurcaciones dependerán únicamente de un grupo de aproximadamente 512 validadores (que se espera reducir a 256). Las firmas post-cuánticas son más grandes, pero pueden propagarse sin problemas dentro del intervalo planificado de 10 segundos (que se espera seguir acortando en el futuro).
• Adaptación de contratos inteligentes e infraestructura. El equipo está llevando a cabo una investigación exhaustiva sobre los escenarios de fuerte acoplamiento entre contratos inteligentes y la duración de los intervalos. Estamos analizando todos los contratos verificados en colaboración con Sourcify; al mismo tiempo, evaluamos el impacto de los cambios en los intervalos sobre EIP-4788 (raíz del bloque de referencia dentro de EVM) y el almacenamiento de la historia de la raíz del bloque de referencia. En términos de infraestructura, Etherscan informa que los ajustes en los intervalos probablemente aumentarán la carga del servidor, pero la infraestructura ya se adaptó a los tiempos de bloque variables durante la era de PoW, por lo que el alcance del cambio es controlable.

Abstracción de cuentas: optimización de la experiencia, seguridad y privacidad

El ecosistema de Ethereum ha necesitado durante mucho tiempo una abstracción de cuentas nativa (AA) para lograr mejoras en la experiencia de billeteras de claves de acceso, patrocinio de transacciones, pago de Gas con ERC20, transacciones en lote, entre otros. Sin embargo, el camino hacia la implementación de la abstracción de cuentas nativa ha sido excepcionalmente complicado: la AA afecta a toda la pila de Ethereum, abarcando clientes, L2, billeteras, RPC y herramientas de desarrollo, lo que requiere una colaboración multifacética. Esto no solo ha dificultado que los EIP relacionados avancen en el proceso de desarrollo impulsado por el consenso, sino que también enfrenta problemas de implementación en el ecosistema una vez que se lanzan.

Por lo tanto, hemos clasificado la propuesta de AA nativa de Hegotá, Frame Transactions, como de nivel A. No es que no se pueda alcanzar el estándar de nivel S en el aspecto técnico, sino que se necesita considerar adecuadamente el riesgo de implementación a gran escala en el ecosistema, lo que implica una gran carga de coordinación. Aprovechando la acumulación del equipo en el campo de la abstracción de cuentas, Ethlabs planea impulsar profundamente la implementación de Frame Transactions, colaborando con L2, billeteras y otros participantes para garantizar que la AA nativa se implemente sin problemas.

Ahora veamos las propuestas relacionadas con la abstracción de cuentas de Hegotá.

【EL】EIP-8141 Frame Transactions【Nivel A】

Creemos que Frame Transactions es la mejor solución para la abstracción de cuentas nativa de Ethereum. En comparación con otras soluciones de AA nativa, varias características se alinean con los principios de desarrollo de CROPS de Ethereum:

• Innovación de cuentas sin permisos: la lógica de verificación se ejecuta mediante código EVM, permitiendo a los desarrolladores personalizar cualquier regla de verificación; algunas soluciones de AA imponen lógicas de verificación en listas blancas, lo que limita la flexibilidad;
• Adaptación nativa a protocolos de privacidad: basado en el punto anterior, soluciones de privacidad como Railgun pueden albergar la lógica de verificación de transacciones Frame, permitiendo a los usuarios enviar transacciones privadas sin depender de intermediarios centralizados, mejorando significativamente la privacidad y la resistencia a la censura;
• Diseño orientado a la seguridad post-cuántica: desde el inicio del desarrollo, se ha alineado con la hoja de ruta post-cuántica de Ethereum. Soporta la agregación de firmas, incluso si el costo de verificación de una sola firma post-cuántica es alto, la agregación puede lograr un bajo costo de Gas.

La mayor debilidad de Frame Transactions también proviene de su flexibilidad: la lógica de verificación se ejecuta mediante código EVM, lo que hace que el costo de verificación fluctúe dinámicamente, lo que representa un desafío para L2 que busca un alto TPS.

Somos optimistas en que se puede resolver mediante estándares complementarios de EIP/ERC (por ejemplo, EIP-7819), declarando estáticamente la lógica de verificación de transacciones, permitiendo que el ordenante optimice el proceso de verificación mediante código nativo. Al mismo tiempo, colaboraremos con L2 y la Fundación Ethereum para realizar pruebas de referencia, identificando y resolviendo cuellos de botella de rendimiento.

【CL】【EL】Componentes adicionales de Frame Transactions

Existen muchos EIP que pueden considerarse extensiones de Frame Transactions y que mejoran su funcionalidad.

【EL】EIP-8250 Números aleatorios de claves para transacciones Frame【Nivel A】

Consideramos esta propuesta como una parte orgánica de EIP-8141 y sugerimos su lanzamiento simultáneo. Introduce un Nonce bidimensional, permitiendo que la cuenta envíe múltiples transacciones en paralelo al grupo de memoria de transacciones; los protocolos de privacidad también pueden almacenar valores nulos en el Nonce bidimensional. El costo de lectura y escritura del Nonce bidimensional es extremadamente bajo, en comparación con el modelo actual de escribir valores nulos en almacenamiento normal, las transacciones privadas pueden ahorrar significativamente en Gas. Esto es especialmente importante en el contexto del aumento del costo de almacenamiento de Gas en Glamsterdam (EIP-8037).

【EL】EIP-8272 Última raíz de transacciones Frame【Nivel B】

Optimiza aún más la experiencia de uso de transacciones Frame para protocolos de privacidad. El proceso de verificación de protocolos de privacidad necesita leer la última raíz de compromiso; si se almacena en almacenamiento normal, no solo es costoso, sino que también entra en conflicto con las reglas del grupo de transacciones públicas de Frame. Esta propuesta almacena los datos de raíz en un búfer circular de contratos del sistema, limpiando automáticamente los datos antiguos. Se clasifica como nivel B porque aumenta significativamente la complejidad de Frame para un único escenario de aplicación, y no estamos seguros de si existe una solución más general y sencilla.

【CL】EIP-8369 Archivo de configuración VOPS calificado para FOCIL【Nivel B】

Resuelve la interacción entre Frame y VOPS (solo sin estado de validez). La solución VOPS permite que los nodos del grupo de memoria solo mantengan la verificación de estado mínima para las transacciones, garantizando la resistencia a la censura del grupo de memoria en el futuro en un entorno sin estado de zkEVM. Se clasifica como nivel B porque esta solución está altamente vinculada a un conjunto de rutas de desestado que aún no han alcanzado un consenso en la comunidad.

【EL】EIP-7906 Afirmaciones de transacciones a través de códigos de operación de diferencia de estado【Nivel B】

Mejora la auditabilidad estática de los resultados de las transacciones. Actualmente, los usuarios pueden afirmar resultados positivos, pero no pueden restringir "la inexistencia de otros cambios de estado". Para demostrar que no hay modificaciones de estado adicionales, se necesita un nuevo código de operación. Las afirmaciones positivas (por ejemplo, que el saldo de WETH aumenta al menos 1.5) junto con afirmaciones negativas (sin otros cambios de estado), pueden bloquear todos los efectos de la transacción sin simulación, siendo los monederos de hardware los principales beneficiarios. Esta propuesta tiene una complejidad alta, y su inclusión en un hard fork debe ser considerada con cautela. Se sugiere avanzar solo si se cumplen dos condiciones: ① el equipo del cliente comprende completamente todos los detalles y efectos en cadena; ② el alcance de las pruebas y la evaluación de riesgos potenciales son completos.

【EL】Migración de EOA【Nivel B】

EIP-7851 y EIP-8151 son adecuados para ser considerados juntos, formando un esquema de migración de cuentas inteligentes desde cuentas externas. El camino es el siguiente: EOA primero se delega a la cuenta inteligente a través de EIP-7702; EIP-7851 introduce un código de operación que solidifica permanentemente la relación de delegación, deshabilitando la clave ECDSA original; EIP-8151 permite que ecRecover reconozca que la clave ha sido desactivada, evitando que claves antiguas roben activos a través de transacciones de tipo Permit. Se clasifica como nivel B porque es solo una de las soluciones de migración de EOA, y aún no ha recibido una revisión amplia ni consenso en la industria. El mayor riesgo radica en la compatibilidad entre cadenas: los usuarios deben repetir la operación de migración en cada L2, incluidas las cadenas aún no existentes, lo que resulta en una mala experiencia de usuario. Esperamos una solución que utilice L1 como raíz de confianza, donde una sola operación se aplique a todas las cadenas EVM, ya que solo tales soluciones tienen la oportunidad de ser elevadas a nivel A/S.

【EL】Estándar de firma post-cuántica【Nivel A】

Hegotá debe establecer un camino claro para la implementación de firmas post-cuánticas, pero se necesita definir el mecanismo óptimo antes de la implementación formal. EIP-8355 introduce un contrato precompilado de ML-DSA: en combinación con Frame Transactions, establece la capacidad de seguridad de cuentas post-cuánticas. Alternativas: registrar previamente el soporte para firmas post-cuánticas pero no activarlas, o definir un formato de derivación compatible con claves post-cuánticas.

【EL】Instrucción SETDELEGATE de EIP-7819【Nivel A】

Una vez que la AA nativa se implemente en Hegotá, reducir los costos de despliegue de cuentas inteligentes es crucial. Sin embargo, EIP-8037 de Glamsterdam aumentará los costos de creación de cuentas. EIP-7819 permite que nuevas cuentas utilicen punteros de delegación livianos, en lugar de contratos de agente, reduciendo significativamente el almacenamiento de estado adicional y disminuyendo los costos de despliegue. Se clasifica como nivel A porque un costo de despliegue de cuentas más bajo puede reducir significativamente la barrera de entrada para la implementación de AA.

Optimización del rendimiento: impulso continuo a la expansión de L1

Glamsterdam marca un cambio en el enfoque de desarrollo de Ethereum: el rendimiento se convierte en la restricción central del diseño del protocolo y el desarrollo del cliente. La ejecución diferida, el ajuste de precios de recursos y la optimización masiva del cliente han aumentado la capacidad de la red de 30 millones de Gas a al menos 200 millones de Gas en dos años. La optimización del rendimiento brinda opciones, y el margen de rendimiento liberado puede utilizarse para la expansión, acortar intervalos, reducir el umbral de hardware de nodos, o lograr múltiples objetivos simultáneamente.

La necesidad de expansión sigue siendo urgente. La selección de proyectos no solo considera el precio actual del Gas, sino también si Ethereum puede continuar y expandir de manera estable la oferta de espacio en bloques. La implementación continua de actualizaciones de expansión proporciona más confianza a los desarrolladores que un simple mapa de ruta en papel. La red principal aún tiene una brecha para manejar picos de tráfico: en el undécimo aniversario de Ethereum, la mediana de Gas fue de aproximadamente 0.1 gwei, y un evento de acuñación de NFT elevó el Gas a la franja de 10 gwei, superando el costo mediano de transacción de 1 dólar. La tendencia de expansión iniciada por Glamsterdam necesita continuar hasta Hegotá.

En resumen, las siguientes EIP continúan el impulso de expansión de Glamsterdam, al tiempo que refuerzan los principios más amplios que lo respaldan: el rendimiento debe ser siempre la principal consideración tanto en el trabajo del cliente como en el diseño del protocolo.

【EL】EIP-8131 & EIP-8279【Nivel S】

La propuesta de combinación de precios de datos después de la actualización de Glamsterdam ha convertido el cuello de botella central de la red en la propagación de la carga de bloques. La raíz del problema radica en la falta de uniformidad en los estándares de cálculo de Gas para diferentes tipos de recursos de bytes, e incluso algunos no tienen tarifas. EIP-8131 unifica el límite inferior de las transacciones: extiende las reglas de facturación mínima existentes a los datos que se pueden confirmar antes de la ejecución; EIP-8279 establece un límite inferior de bytes para la lista de acceso a bloques: se refiere a la facturación de los bytes de la lista de acceso generada dinámicamente durante el proceso de ejecución.

El mecanismo de facturación dinámica hace que EIP-8279 sea más complejo, pero ambas deben considerarse en conjunto. La solución combinada logra un cálculo unificado de los bytes relacionados con las transacciones, limitando el peor de los casos de carga de bloques, mientras que la gran mayoría de las transacciones ordinarias y de bajo consumo de datos no se ven afectadas. Esto llena los vacíos en el cálculo de recursos y allana el camino para futuros aumentos en el límite de Gas.

【CL】【EL】EIP-8146 【Nivel A】

EIP-8146 mejora el camino crítico en sí al separar la propagación de BAL y la carga útil, perfeccionando así el mecanismo de re-precio. Esto no solo mejora la eficiencia de la propagación, sino que también permite que el cliente de ejecución tenga una ventaja en el cálculo posterior a la recuperación del estado y la raíz del estado. Creemos que esta es una optimización de bajo umbral que no se debe perder. La implementación del trabajo se basa principalmente en el familiar mecanismo de gossip de CL, por lo que es un EIP de bajo costo y alto valor, especialmente en una rama con un gran volumen de código de EL.

Otras propuestas relacionadas con la escalabilidad

【EL】CPSB recalibración【Nivel A】

El cambio es simple. Sugerimos continuar avanzando, según lo planeado, con el aumento del límite de Gas, el estado en cadena y el uso de Gas de ejecución, eligiendo uno para incluir. EIP-8368 calibración de CPSB para el nuevo límite de Gas: plan de apoyo posterior a EIP-8037. El costo de los bytes de estado cambia de ajustarse dinámicamente con el límite de Gas a un valor fijo, simplificando el desarrollo y las pruebas. Actualmente, CPSB se calcula en base a un límite de Gas de 150 millones, y después del aumento del límite de Gas, es probable que Hegotá necesite recalibración. EIP-8372 estandariza el límite de Gas de estado: forma parte de la extensión de EIP-8368, con un ajuste más fino, para abordar el crecimiento del estado y las desviaciones de los objetivos de Gas regulares.

【EL】EIP-7862 retraso de la raíz de estado【Nivel B】

La norma en sí es bastante simple, pero hasta donde sabemos, la complejidad de la implementación del cliente no se ha comprendido completamente. La raíz del estado está presente en el repositorio de código. Los beneficios a corto plazo son limitados, y el valor central se concentra en el largo plazo (extender la duración de la prueba de la raíz del estado). La presión de los cambios en la capa de ejecución de Hegotá ya es bastante alta.

【CL】EIP-8341 compromiso de carga útil de ejecución parcial【Nivel D】

Sugerimos no incluirlo. Los beneficios son limitados (ligera demora en el cálculo de la raíz del estado), la demanda no es urgente, y EIP-7862 puede lograr un efecto más fuerte y puede reemplazarlo directamente.

Discusión de clasificación de EIP restante

A continuación, organizamos las propuestas restantes, agrupándolas por tema. Algunas propuestas aún están en formación, y actualizaremos continuamente en el futuro en comunicación con el equipo del cliente y los autores.

Se espera que Hegotá sea un hard fork centrado en cambios en la capa de ejecución, y debemos controlar estrictamente el umbral de admisión de EIP en la capa de ejecución. A excepción de FOCIL y Quick Slots, debemos controlar el alcance de los cambios en la capa de consenso: reducir el alcance de la actualización y dejar suficiente tiempo para el equipo del cliente para enfrentar futuras transformaciones arquitectónicas a gran escala.

【CL】Mecanismos de emisión relacionados

No clasificamos la emisión y destrucción progresiva de EIP-8363 por prioridad. La política de emisión inflacionaria no debe ser decidida unilateralmente por los desarrolladores centrales; la lista de prioridades es equivalente a presentar recomendaciones claras a los desarrolladores centrales. La gran mayoría de las EIP tienden a decisiones técnicas, y la comunidad delega el poder de decisión al equipo de desarrollo central; sin embargo, el mecanismo de emisión pertenece a la política monetaria, que requiere un amplio consenso de la comunidad. La opinión de los desarrolladores centrales solo debe considerarse como referencia para la discusión pública. Si se clasifica junto con las EIP ordinarias, equivale a considerarlo como una decisión técnica de ACD convencional.

Desde un punto de vista técnico, EIP-8363 tiene valor. A medida que aumenta la cantidad total de ETH en staking, la credibilidad del mecanismo de penalización disminuye; la mayoría de las nuevas recompensas bajo una alta tasa de staking compensan la inflación; el efecto de escala sigue ampliando la brecha entre los grandes operadores y los stakers independientes. Pero el cambio también conlleva riesgos: hay incertidumbre en la distribución del staking, y el proceso de consolidación de la política monetaria se reiniciará. El hilo de discusión publicado por Ansgar enumera completamente los puntos a favor y en contra, y coincide con nuestra posición. Algunos miembros del equipo apoyaron previamente el ajuste del mecanismo de emisión, y actualmente mantienen ese juicio.

Sugerimos discutir el ajuste del mecanismo de emisión una vez que se hayan definido todos los demás ámbitos de Hegotá. Dar a la comunidad suficiente tiempo para discutir y evitar interferir en la delimitación del alcance de la actualización.

【CL】Optimización de funciones de staking

Las mejoras en el staking tienen valor, pero se debe priorizar la optimización orientada al usuario final; los cambios puramente en la infraestructura deben retrasarse a menos que sean necesarios.

【CL】EIP-8015 eliminación de campos de depósito y eth1data【Nivel A】

Limpieza ligera de la deuda técnica histórica. Basado en EIP-7688 para compatibilidad hacia adelante con la estructura de datos de consenso, los campos irrelevantes no se verán afectados por la prueba de Merkle, y no afectarán a los lectores de datos en la cadena.

【EL】【CL】EIP-8237 sincronización independiente de la capa de consenso / capa de ejecución【Nivel B】

Basado en la separación de ePBS entre bloques de señal y carga, permite que CL y EL se sincronicen de forma independiente, lo que podría simplificar la lógica compleja del cliente.

【CL】EIP-8205 pre-registro de comprobantes de retiro【Nivel D】

Sugerimos no incluirlo. Aunque aborda un dolor real en el staking delegado, el esquema de depósito existente ya puede manejarlo, y la complejidad que trae un nuevo conjunto de mecanismos de protocolo es difícil de igualar con los beneficios en esta etapa.

【CL】EIP-8148 umbral de liquidación personalizado para validadores【Nivel D】

Sugerimos no incluirlo. El mecanismo es complejo (nuevos contratos del sistema, solicitudes de ejecución, lógica de la capa de consenso), los beneficios son limitados y solo impulsan ligeramente la integración del staking minorista. Dada la actual distribución del staking, es difícil cambiar significativamente la tendencia de concentración de validadores en toda la red.

【CL】EIP-8372 destrucción forzada de recompensas de ejecución de ePBS【Nivel D】

Sugerimos no incluirlo. Es probable que solo genere más canales fuera de la cadena. La discusión sobre la destrucción de MEV durante años no ha dado lugar a un plan de consenso amplio.

【CL】EIP-7716 penalización de prueba de correlación inversa【Nivel D】

Sugerimos no incluirlo. Falta evidencia suficiente que respalde un ajuste significativo en el mecanismo de incentivos de staking, y desacoplar la actualización de consenso rediseñará el sistema de incentivos de staking.

【CL】EIP-8333 alineación de puntos de control con bloques de frontera de época【Nivel D】

Sugerimos no incluirlo. Pertenece a trabajos de optimización y limpieza, y puede retrasarse hasta que se avance en una actualización de consenso más grande.

【CL】EIP-8359 campos de informe de bloques de señal【opinión en formación】

【CL】Trabajo previo a la actualización post-cuántica

Las siguientes propuestas reducen la dependencia de las firmas BLS, allanando el camino para la futura transición post-cuántica.

【CL】EIP-8365 eliminación de comprobantes de retiro BLS【Nivel A】

Eliminación de los antiguos comprobantes de retiro, simplificando el protocolo y allanando el camino para la futura transición post-cuántica. El cambio es simple y adecuado para la implementación actual.

【CL】EIP-8367 eliminación del mecanismo de caducidad de saldo de validadores BLS【Nivel D】

Sugerimos no incluirlo. La gran mayoría de los validadores de comprobantes 0x0 completarán la migración de comprobantes antes y después de la implementación de EIP-8365, retirando fondos o continuando con el staking. No es necesario crear un mecanismo adicional para manejar el stock restante; primero implementemos EIP-8365 y observemos la situación real.

【CL】EIP-8321 RANDAO de cadena hash【Nivel D】

Sugerimos no incluirlo. Implementar RANDAO por sí solo tiene un significado limitado en términos de seguridad post-cuántica, los riesgos para la clave BLS de cada validador aún existen; además, cada validador agrega 32 bytes de datos, lo que introduce lógica de gestión de claves y tiene un único propósito. Un plan completo de consenso post-cuántico aún no se ha implementado. Apoyamos la actualización iterativa, pero el primer paso debe seguir un mapa de ruta unificado para evitar que el plan sea reemplazado por el estándar final.

【EL】【CL】Optimización de adaptación de zkEVM

La mayoría de las optimizaciones previas de zkEVM tienen beneficios a corto plazo limitados, solo facilitan a grupos específicos ejecutar nodos completos, al tiempo que consumen recursos de desarrollo y pueden aumentar los costos de operación de EVM. Solo las propuestas cuyo valor a largo plazo sea significativamente mayor que los costos a corto plazo son adecuadas para ser incluidas.

【CL】EIP-8025 prueba de ejecución opcional【Nivel D】

Esta actualización no debe incluirse. La propuesta en sí no implica un hard fork obligatorio; su inclusión en Hegotá es solo una cuestión de prioridad, con la que no estamos de acuerdo. Antes de implementar pruebas opcionales, se debe aclarar primero la forma final a largo plazo y avanzar de manera constante, sin apresurarse a implementarla antes de que se definan los validadores / el modelo de estado. La cuestión central a resolver es: ¿deben los validadores retener y almacenar parte del estado, o deben ser completamente sin estado? Los validadores son un grupo de nodos importantes, que poseen recursos de hardware y red, y los cambios que debilitan su papel requieren estándares de admisión más altos.

【EL】EIP-7666 precompilación de identidad EVM【Nivel A】

El cambio es pequeño y tiene valor práctico.

【EL】EIP-8200 precompilación EVM【Nivel B】

Reemplazo de tres tipos de precompilaciones nativas con código de bytes EVM. Dos tipos tienen un uso bajo y una dificultad de migración baja; el tercer tipo se utiliza ampliamente para pruebas SNARK. Se necesita realizar una evaluación de impacto para confirmar que los costos de migración son controlables, o excluir el tercer tipo, y luego lo elevaremos a nivel A.

【EL】EIP-7709 lectura de BLOCKHASH desde el almacenamiento y ajuste de Gas【Nivel D】

El aumento de Gas es considerable, la perturbación es evidente y la demanda no es urgente. Para reducir el riesgo, se puede realizar una evaluación de impacto o retrasar la implementación junto con un mecanismo de precalentamiento de bloques.

【EL】EIP-8268 inclusión de la lista de acceso a bloques en la raíz de almacenamiento【Nivel B】

Se necesita evaluar el impacto real en el volumen de la lista de acceso y el costo de Gas de las transacciones (EIP-8279 cobrará por los bytes de la lista de acceso), cada entrada de cuenta de acceso adicional llevará la raíz de Merkle de almacenamiento.

【EL】Funciones nativas de EVM

Hegotá seguirá implementando algunas mejoras dispersas de EVM. Creemos que, después de esta actualización, Ethereum debería colaborar con todo el ecosistema de EVM para establecer una hoja de ruta de desarrollo a largo plazo para EVM, y Ethlabs participará en la co-construcción.

【EL】EIP-5920 Códigos de operación PAY【A nivel】

La lógica es sencilla, es un primitivo subyacente muy valioso para EVM. Se necesita aclarar más los escenarios de aplicación reales.

【EL】EIP-8163 Código de operación EXTENSION (0xae) reservado【A nivel】

Altamente práctico para L2, casi sin costo para L1, solo sirve como identificador reservado.

【EL】Reutilización de código de contrato【B nivel】

EIP-8058 deducción de código de bytes de contrato, EIP-8298 instrucción de reutilización SETCODEFROM, basadas en el modelo de almacenamiento del cliente: el código del contrato se almacena de forma independiente, y la cuenta solo apunta al código a través del hash del código. Ambas propuestas logran almacenar solo una copia del mismo código, reduciendo los costos de implementación. La idea es atractiva, pero necesita evaluar el impacto en la compatibilidad hacia adelante de la estructura de almacenamiento de árbol binario. Ambas propuestas no tienen preferencias claras por el momento.

【EL】Reforma de precios de memoria【B nivel】

Aún no hemos determinado si es adecuado implementar la reforma de memoria en Hegotá. Actualmente, nuestra comprensión del espacio de diseño no es suficiente.

EIP-7686 límite superior de memoria lineal de EVM: cambios menores, eliminación del costo de expansión de memoria de crecimiento secundario;

EIP-7923 precios de memoria lineales basados en paginación: reestructura las reglas subyacentes, más completo, pero con mayor complejidad.

【EL】EIP-8219 Códigos de operación aritmética con verificación de desbordamiento【B nivel】

Agregar funciones de cálculo seguras nativas a EVM tiene valor. Se necesita una prueba de referencia para confirmar que el precio es razonable; después de completar la evaluación de impacto (escala de transacciones beneficiadas, situación de adaptación del compilador), se espera que se eleve a A nivel.

【EL】EIP-8360 Código de operación TCREATE【B nivel】

Soporta la creación de contratos temporales dentro del ciclo de vida de la transacción, un primitivo subyacente general. Sin embargo, la complejidad de la propuesta es alta, y se puede volver a clasificar después de evaluar la dificultad de desarrollo y pruebas.

【EL】EIP-7645 Alias ORIGIN apuntando a SENDER【D nivel】

Se sugiere no incluir. Es un cambio destructivo, abuso de la semántica de ORIGIN.

【EL】EIP-8182 Transferencias nativas privadas de ETH y ERC20【D nivel】

Se sugiere no incluir. El tamaño del cambio es enorme, introduce dependencia de ZK. Si se implementa en el futuro, debería ser como propuesta central de actualización.

【EL】EIP-2488 Desuso del código de operación CALLCODE【Opinión en formación】

【EL】EIP-4758 Desuso de SELFDESTRUCT【Opinión en formación】

【EL】EIP-7979 Códigos de operación de llamada y retorno de EVM【Opinión en formación】

【EL】EIP-8173 Fundamentos del flujo de control de EVM【Opinión en formación】

【EL】EIP-8253 Incremento automático de Nonce de cuentas de almacenamiento cero【Opinión en formación】

【EL】EIP-8030 Soporte para el nuevo algoritmo P256【Opinión en formación】

【EL】Mecanismo de precios de EVM

Glamsterdam ha aumentado el costo de Gas de operaciones que limitan el rendimiento. Las propuestas de precios relacionadas con Hegotá son opuestas: reducen los costos de operación que son demasiado altos y limitan la implementación de aplicaciones, pero tienen una contribución limitada a la expansión de la red, son optimizaciones que son un lujo. Apoyamos ajustes de precios específicos, pero las propuestas de nuevos modelos de facturación deben estar bien diseñadas y contar con validadores sólidos que verifiquen los riesgos antes de ser incluidas.

【EL】EIP-8358 Facturación neta de Gas por cambios de cuenta【B nivel】

Los beneficios son dudosos. Muestra de 900 bloques de la red principal, 400,000 transacciones muestran: solo el 2.07% de las transacciones ahorran Gas, el total de Gas ahorrado en bloques solo representa el 1.14%.

【EL】EIP-7973 Facturación de escritura de cuentas calientes【Opinión en formación】

【EL】EIP-7609 Reducción de Gas base de TLOAD/TSTORE【Opinión en formación】

【EL】EIP-7971 Límite superior de almacenamiento instantáneo【Opinión en formación】

【EL】EIP-3298 Eliminación de la devolución de Gas【Opinión en formación】

【EL】EIP-8374 Mantener el conjunto de acceso caliente después de la reversión【Opinión en formación】

【EL】EIP-8115 Cobro masivo de tarifas prioritarias al final del bloque【Opinión en formación】

【EL】EIP-8188 Registro del bloque más reciente de escritura de cuentas y ranuras de almacenamiento【Opinión en formación】

【EL】【CL】Datos de ejecución e índices

【EL】【CL】EIP-7668 Eliminación del filtro de Bloom【Opinión en formación】

【EL】【CL】EIP-7807 Bloques de ejecución en formato SSZ【Opinión en formación】

【EL】EIP-8116 Simplificación de campos de recibos acumulativos【Opinión en formación】

【EL】EIP-8304 Índices de transacciones y registros de logs sin necesidad de confianza【Opinión en formación】

【EL】【CL】Capa de red

La red P2P de Ethereum aún tiene espacio para optimizaciones dirigidas, especialmente en la propagación de transacciones, blobs y mensajes de prueba.

【CL】EIP-8371 Reconstrucción distribuida de Blob RowDAS【A nivel】

Evitar la reconstrucción completa, el alojamiento de nodos completos se convierte en un cuello de botella para la expansión de blobs. A largo plazo, el mecanismo de reconstrucción distribuida debe ser incluido en el protocolo, con la esperanza de eliminar los requisitos de alojamiento de blobs para los validadores. Aún se necesita evaluar la complejidad de implementación.

【CL】EIP-8142 Bloques BiB incrustados en blobs【D nivel】

El momento no es maduro, la urgencia es insuficiente, quedan muchos problemas por resolver (si adoptar KZG, nuevo tema de difusión). No deseamos introducir el mecanismo KZG en la ruta crítica de producción de bloques, las alternativas aún no están claras.

【CL】EIP-8243 Difusión de pruebas en lotes desde la fuente【D nivel】

No se puede garantizar claramente la reducción del tiempo de confirmación final, el límite de carga no está claro; la capacidad de defensa contra DoS del mecanismo necesita ser verificada.

【EL】EIP-8077 Transacciones de difusión basadas en Nonce eth/XX【Opinión en formación】

【EL】EIP-8094 Protocolo de piscina de transacciones que soporta blobs eth/vhash【Opinión en formación】

【CL】EIP-8334 Difusión de pruebas en lotes【Opinión en formación】

Conclusión

La actualización de Ethereum tiene un alto riesgo, por lo que la complejidad es inevitable. Miles de nodos en todo el mundo necesitan sincronizar el cambio de reglas en el mismo momento, y la operación de la red no puede interrumpirse. Este rigor ha respaldado las actualizaciones exitosas de Ethereum, logrando una red descentralizada sin interrupciones durante 11 años.

Lo anterior es el juicio actual de Ethlabs sobre Hegotá. A medida que avanza el desarrollo y se profundizan las discusiones, actualizaremos continuamente nuestras opiniones si surgen nuevas evidencias. Algunas EIP son impulsadas por miembros de Ethlabs, mientras que otras propuestas provienen de una gran cantidad de excelentes investigadores, desarrolladores de clientes y contribuyentes independientes de Ethereum. Pero todas las soluciones que desean implementarse dependen de la colaboración de equipos de clientes, billeteras, aplicaciones, L2, proveedores de infraestructura, instituciones, operadores de nodos y usuarios finales. Ethereum pertenece al mundo, y los grandes avances en la red nunca son el resultado de una sola organización.