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

Artículo: Ethlabs

Compilación: Chopper, Foresight News

La dirección del desarrollo de Ethereum afecta a todas las personas que construyen aplicaciones, utilizan la red, poseen ETH y creen en el potencial futuro de Ethereum. El futuro a largo plazo de Ethereum está finalmente determinado por los participantes que construyen productos, operan aplicaciones y comunidades sobre él todos los días, pero las actualizaciones de la red son el medio central para iterar el protocolo y satisfacer las necesidades de los usuarios. Hegotá es la próxima actualización de red planificada de Ethereum después de Glamsterdam. Este artículo expondrá la dirección y las razones que, según Ethlabs, Ethereum debería priorizar en esta actualización.

Actualmente, el alcance de la actualización Hegotá se está determinando preliminarmente a través del proceso técnico público de Ethereum. Las diversas propuestas mencionadas a continuación incorporan los logros de numerosos desarrolladores, equipos de investigación y equipos de clientes. Este artículo presenta claramente las direcciones que Ethlabs recomienda priorizar, así como los puntos sobre los cuales aún no tenemos una opinión formada. Damos la bienvenida a la evaluación, cuestionamiento y mejora de estas propuestas por parte de la industria; en los próximos días y semanas, iteraremos también nuestros puntos de vista con discusiones continuas y actualizaciones de información.

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

• Mayor resistencia a la censura: Cualquier persona, independientemente de su identidad o propósito, pueda hacer que sus transacciones sean incluidas en un bloque;
• Un Ethereum más rápido: Bloques más rápidos significan confirmaciones de transacciones más rápidas, precios en cadena en tiempo real y tiempos de finalización más cortos;
• Abstracción de cuentas nativa: Las cuentas admiten claves de paso, patrocinio de transacciones, pago de Gas con tokens, transacciones por lotes, mayor protección de privacidad y una ruta de actualización hacia claves post-cuánticas.
• Escalado continuo de L1: Incluso durante los picos de demanda, las aplicaciones puedan obtener una capacidad de red estable y asequible.

Aclaración previa: ¿Cómo funciona el proceso de avance de las EIP?

Antes de interpretar formalmente las propuestas, aclaremos un contexto clave: la segunda fase para definir el alcance de la actualización Hegotá acaba de comenzar. La primera fase ya ha determinado FOCIL como la propuesta central de actualización para 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 ACD evaluará completamente el plan integral de actualización de Hegotá.

Todas las siguientes EIP se encuentran actualmente en la etapa PFI (Propuesta para Inclusión). Enviar una EIP para su consideración en una actualización es sin permiso, pero la gran mayoría de las propuestas finalmente no se incluyen en la actualización formal.

A medida que avanza el desarrollo, las propuestas pasan por múltiples rondas de revisión, ascendiendo de etapa, aumentando la certeza de su implementación:

PFI (Propuesta para Inclusión): La propuesta se envía para esta actualización. Esta etapa no tiene barreras de entrada, no representa el apoyo de los equipos de clientes ni garantiza su lanzamiento final;

CFI (Considerada para Inclusión): Los equipos de clientes han completado la revisión y planean comenzar el desarrollo de prototipos y pruebas;

SFI (Determinada para Inclusión): Hay un amplio acuerdo para su inclusión, sujeto a un desarrollo y pruebas exitosos.

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

Guía de lectura

Este artículo sigue el sistema de clasificación de Forkcast para expresar el juicio de prioridad de Ethlabs sobre las diversas EIP de Hegotá. Para simplificar la decisión, todas las propuestas evaluadas se dividen en cinco niveles:

• 【Nivel S】 Fuerte recomendación para su inclusión
• 【Nivel A】 Recomendación para su inclusión si se resuelven obstáculos como la dificultad de desarrollo, evaluación de impacto, adopción del ecosistema, etc.
• 【Nivel B】 Tienen valor, pero es difícil incluirlas en esta actualización
• 【Nivel D】 En las condiciones actuales, no se recomienda su inclusión en Hegotá
• 【Opinión pendiente】 Todavía estamos investigando y evaluando esta EIP

⚠️ Atención: Lo anterior es solo una recomendación de Ethlabs. Evaluamos principalmente en base a los objetivos de la propuesta, las especificaciones técnicas y la complejidad estimada de desarrollo; tenemos información más completa para proyectos en los que participamos profundamente (por ejemplo, Frames, Quick Slots). Posteriormente, actualizaremos nuestros puntos de vista combinando los comentarios de ethPandaOps, equipos de prueba y los diversos clientes. La marca 【CL】 significa que afecta al cliente de la capa de consenso; 【EL】 significa que afecta al 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 objetivamente todas las propuestas, sin que nuestra participación influya, pero los lectores pueden tener en cuenta este contexto al referenciar nuestros puntos de vista.

Lista de prioridades CL

Lista de prioridades EL

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

Las cuatro direcciones centrales de Hegotá

FOCIL: Fortalecer la resistencia a la censura

La EIP-7805 FOCIL ya ha entrado en la etapa SFI, confirmándose oficialmente 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, solo lo explicaremos brevemente aquí: solo una cadena de bloques que se mantenga neutral para todos puede convertirse en la base confiable para todos. Esta es la base para que Ethereum escale, crezca hasta convertirse en una capa de liquidación económica real y sirva a cada participante.

Quick Slots: Un Ethereum más rápido

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

• Mayor velocidad de confirmación de transacciones para usuarios de L1, optimizando la experiencia;
• Los mercados en cadena de L1 obtienen datos de precios más actualizados, mejorando los diferenciales de compra-venta y los ingresos de los proveedores de liquidez;
• La finalidad y las reglas de confirmación rápida están vinculadas a la duración del intervalo, por lo que bloques más rápidos mejorarán simultáneamente la interoperabilidad cross-chain de Ethereum;
• El aumento en el número de proponentes de bloques por segundo fortalece la resistencia a la censura, incluida la resistencia económica: el costo requerido para intentar censurar vaciando bloques continuamente es mayor.

Acortar el intervalo entre bloques mientras se preserva la descentralización de Ethereum puede aumentar el valor del espacio de bloques de Ethereum, devolviendo los beneficios a la red y al propio ETH. Cada reducción de latencia crea valor directamente para el usuario. Al mismo tiempo, la aceleración es también una de las mejoras más solicitadas por los desarrolladores de aplicaciones.

Iniciar esta transformación ahora es razonable. El ajuste de la duración del intervalo no se puede lograr de una sola vez. Al igual que con el escalado, la optimización iterativa mediante implementación y pruebas reales brinda mucha más certeza a los desarrolladores de aplicaciones que las simples promesas de una hoja de ruta. Alcanzar un intervalo de menos de 6 segundos es un objetivo a largo plazo, y el camino se divide en dos pasos:

• Refactorización única: Hacer que las especificaciones y el código del cliente admitan la modificación flexible de la duración del intervalo;
• Realizar el primer acortamiento en Hegotá, y continuar reduciéndolo en futuras bifurcaciones duras, acumulando datos de operación segura.

Hegotá es un momento oportuno para asumir el costo de la refactorización única. La ePBS de la actualización Glamsterdam ya refactorizó la lógica relacionada con los intervalos; los cambios en la capa de consenso en esta actualización son relativamente manejables. Una vez que se abra la ventana para actualizaciones de consenso desacopladas, los recursos de desarrollo de la capa de consenso estarán muy tensionados, y es poco probable que haya otra oportunidad como esta en múltiples bifurcaciones duras futuras.

En pocas palabras, o mantenemos un intervalo de 12 segundos durante al menos los próximos dos años, o implementamos un intervalo de 10 segundos en la actualización Hegotá dentro de un año, con la posibilidad de reducirlo aún más a menos de 10 segundos en la siguiente ronda. Estas dos aceleraciones no son solo optimizaciones teóricas; pueden mejorar directamente el valor para el usuario y optimizar el modelo económico de la red. Creemos que el momento es adecuado.

Respuesta a las principales controversias

Recopilamos cuatro preocupaciones principales que surgieron en la comunicación inicial con los equipos de desarrollo de clientes y el equipo de protocolos de la Fundación Ethereum:

• Complejidad de desarrollo. La lógica de temporización de intervalos a nivel de milisegundos ya se fusionó con las especificaciones de consenso basándose en ePBS; los borradores de especificaciones para la capa de consenso y ejecución de la EIP-8198 están completos, y la tarifa base, el límite de Gas y la programación de Blobs se han convertido completamente, garantizando un comportamiento de red estable por segundo. El trabajo restante se centra en adaptar diversas herramientas del cliente y probar escenarios límite que asumían un intervalo fijo. Una vez completada esta refactorización única, los acortamientos posteriores solo requerirán ajustar parámetros.
• Presión de pruebas para zkEVM. Hay dos preocupaciones principales: duración relativa de la prueba y sobrecarga fija de la prueba. 1) Duración relativa de la prueba: proporción de tiempo disponible para pruebas dentro de un intervalo. Actualmente, los constructores de bloques pueden comenzar a construir después de recibir la carga útil del bloque anterior; el bloque beacon confirma la carga útil del intervalo actual. La carga útil debe probarse antes de que el próximo proponente beacon publique un bloque. El tiempo mínimo disponible para completar la prueba es aproximadamente igual a un intervalo menos el retraso de propagación del bloque beacon. El retraso de propagación es difícil de comprimir, pero su valor absoluto es pequeño y actualmente no constituye un cuello de botella central. Los constructores de bloques optimizados pueden realizar pruebas en paralelo mientras ensamblan la carga útil, sin esperar a que la carga útil ganadora sea confirmada por el bloque beacon. 2) Sobrecarga fija de pruebas zkEVM: El tiempo de prueba es aproximadamente lineal con el tamaño del bloque, pero existe una sobrecarga fija. Bloques más rápidos significan una mayor frecuencia de activación de esta sobrecarga fija, aumentando la latencia para el mismo rendimiento. Bajo un presupuesto de latencia fijo, se debe garantizar que el rendimiento no se vea afectado significativamente. La industria tiene dos caminos de mejora: iteración de ingeniería para reducir continuamente el tiempo de las operaciones fijas; la EIP-7862 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 impedirán el crecimiento continuo del rendimiento futuro.
• Ruta de actualización post-cuántica. La solución de consenso desacoplado ha obtenido suficiente apoyo como dirección estable para la arquitectura de consenso futura. El desacoplamiento significa mover los votos de finalización fuera de la ruta crítica de producción de bloques. La lógica relacionada con la agregación a gran escala de firmas post-cuánticas y STARK recursivos se alejará de la ruta crítica. La producción de bloques y las reglas de elección de bifurcación dependerán solo de un pequeño comité de, según lo planeado, 512 (posiblemente reducido a 256) validadores. Las firmas post-cuánticas son más grandes, pero pueden propagarse sin problemas dentro del intervalo planificado de 10 segundos (con posibilidad de acortarse aún más en el futuro).
• Adaptación de contratos inteligentes e infraestructura. El equipo está investigando exhaustivamente los escenarios donde los contratos inteligentes están fuertemente acoplados a la duración del intervalo. Analizamos junto con Sourcify todos los contratos verificados; también evaluamos el impacto del cambio de intervalo en el almacenamiento de raíces de bloques beacon históricas introducido por la EIP-4788 (raíz del bloque beacon dentro del EVM). A nivel de infraestructura, el feedback de Etherscan es: el ajuste del intervalo probablemente aumentará la carga del servidor, pero la infraestructura ya se adaptaba a tiempos de bloque variables en la era de PoW, por lo que el alcance de los cambios es manejable.

Abstracción de cuentas: Optimizar experiencia, seguridad y privacidad

El ecosistema de Ethereum ha necesitado durante mucho tiempo una abstracción de cuentas nativa (AA) para habilitar mejoras en la experiencia como billeteras con claves de paso, patrocinio de transacciones, pago de Gas con ERC20 y transacciones por lotes. Sin embargo, el camino hacia una AA nativa ha sido excepcionalmente tortuoso: la AA afecta toda la pila de Ethereum, abarcando clientes, L2, billeteras, RPC, herramientas de desarrollo, requiriendo coordinación entre múltiples partes. Esto no solo ha hecho que las EIP relacionadas sean difíciles de avanzar a través del proceso de desarrollo impulsado por consenso, sino que también presenta desafíos de adopción en el ecosistema después del lanzamiento.

Por lo tanto, clasificamos la propuesta de AA nativa Frame Transactions para Hegotá como Nivel A. No es que no cumpla técnicamente con el estándar Nivel S, sino que es necesario considerar plenamente los riesgos de adopción a gran escala en el ecosistema, y el trabajo de coordinación es enorme. Basándonos en nuestra experiencia acumulada en el campo de la abstracción de cuentas, Ethlabs planea impulsar profundamente la implementación de Frame Transactions, vinculándonos con participantes como L2 y billeteras para garantizar un lanzamiento exitoso de la AA nativa.

Ahora veamos las propuestas relacionadas con la abstracción de cuentas para 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 otros esquemas de AA nativa, varias características se alinean con los principios de desarrollo CROPS de Ethereum:

• Innovación sin permiso para cuentas: La lógica de verificación es ejecutada por código EVM, permitiendo a los desarrolladores definir reglas de verificación arbitrarias; algunos esquemas de AA imponen listas blancas para la lógica de verificación, careciendo de flexibilidad;
• Adaptación nativa a protocolos de privacidad: Basado en el punto anterior, esquemas de privacidad como Railgun pueden albergar lógica de verificación de transacciones Frame, permitiendo a los usuarios enviar transacciones privadas sin depender de retransmisores centralizados, mejorando significativamente la privacidad y resistencia a la censura;
• Diseñado para seguridad post-cuántica: Desarrollado desde el principio para alinearse con la hoja de ruta post-cuántica de Ethereum. Admite agregación de firmas, por lo que incluso si la verificación de una sola firma post-cuántica es costosa, la agregación puede lograr un costo de Gas bajo.

La mayor debilidad de Frame Transactions también proviene de su flexibilidad: al delegar la lógica de verificación al código EVM, el costo de verificación es dinámico, lo que plantea desafíos para L2 que buscan alto TPS.

Somos optimistas de que se puede resolver mediante estándares EIP/ERC complementarios (por ejemplo, EIP-7819), donde las transacciones declaren estáticamente la lógica de verificación, permitiendo a los secuenciadores optimizar la ruta de verificación con código nativo. Simultáneamente, 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

Hay muchas EIP que pueden verse como extensiones de las transacciones Frame, y que mejoran su funcionalidad en base a ellas.

【EL】EIP-8250 Nonce de clave para transacciones Frame【Nivel A】

Vemos esta propuesta como una parte integral de la EIP-8141 y recomendamos su lanzamiento simultáneo. Introduce un Nonce bidimensional, permitiendo a las cuentas enviar múltiples transacciones en paralelo al mempool; los protocolos de privacidad también pueden almacenar valores nulos en el Nonce bidimensional. El costo de lectura/escritura en almacenamiento para el Nonce bidimensional es extremadamente bajo. Comparado con el modelo actual de escribir valores nulos en almacenamiento regular, las transacciones privadas pueden ahorrar significativamente Gas. Esto es especialmente importante en el contexto del aumento del costo de Gas de almacenamiento en Glamsterdam (EIP-8037).

【EL】EIP-8272 Raíz más reciente para transacciones Frame【Nivel B】

Optimiza aún más la experiencia de los protocolos de privacidad al usar transacciones Frame. El proceso de verificación de protocolos de privacidad necesita leer la raíz de compromiso más reciente. Si se almacena en almacenamiento regular, no solo es costoso, sino que también entra en conflicto con las reglas del pool público de transacciones Frame. Esta propuesta almacena los datos de la raíz a través de un búfer circular de contratos del sistema, limpiando automáticamente los datos antiguos. Clasificado como Nivel B porque agrega complejidad significativa a Frame para un único caso de uso, y no estamos seguros de si existe una solución más general y simple.

【CL】EIP-8369 Perfil VOPS para elegibilidad FOCIL【Nivel B】

Resuelve la interacción entre Frame y VOPS (Verkle Stateless). El esquema VOPS permite que los nodos del mempool mantengan un estado mínimo para verificar transacciones, garantizando la resistencia a la censura del mempool en un entorno futuro sin estado para zkEVM. Clasificado como Nivel B porque este esquema está muy vinculado a una hoja de ruta sin estado que aún no tiene consenso comunitario.

【EL】EIP-7906 Aserciones de transacción mediante códigos de operación de diferencia de estado【Nivel B】

Mejora la capacidad de auditoría estática de los resultados de las transacciones. Los usuarios actualmente pueden afirmar resultados positivos, pero no pueden restringir que "no existan otros cambios de estado". Para probar que no hay modificaciones de estado adicionales, se necesitan nuevos códigos de operación. Una aserción positiva (por ejemplo, saldo de WETH aumenta al menos 1.5) combinada con una aserción negativa (sin otros cambios de estado) puede bloquear todo el impacto de una transacción sin simulación, siendo las billeteras de hardware un escenario beneficiario clave. Esta propuesta es bastante compleja y su inclusión en una bifurcación dura requiere precaución. Se recomienda avanzar solo si se cumplen dos condiciones: 1) Los equipos de clientes comprenden completamente todos los detalles y efectos secundarios; 2) El alcance de las pruebas y la evaluación de riesgos potenciales están completos.

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

La EIP-7851 y la EIP-8151 son adecuadas para verse juntas, formando un esquema para migrar cuentas externas a cuentas inteligentes. La ruta es la siguiente: Primero, una EOA delega a una cuenta inteligente a través de la EIP-7702; la EIP-7851 agrega un código de operación para solidificar permanentemente la relación de delegación, deshabilitando la clave ECDSA original; la EIP-8151 hace que ecRecover reconozca que la clave está desactivada, evitando que la clave antigua robe activos a través de transacciones tipo Permit. Calificación Nivel B: Este es solo uno de los esquemas de migración de EOA, y aún no ha sido ampliamente revisado ni tiene consenso en la industria. El mayor riesgo es la compatibilidad cross-chain: los usuarios necesitarían repetir la operación de migración en cada L2, incluidas las cadenas que aún no existen, lo que resulta en una mala experiencia de usuario. Esperamos un esquema que utilice L1 como raíz de confianza, donde una sola operación se aplique a todas las cadenas EVM; dicho esquema tendría la oportunidad de ascender a los niveles A/S.

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

Hegotá debería establecer una ruta clara para la implementación de firmas post-cuánticas, pero necesita determinar el mecanismo óptimo antes de la implementación formal. La EIP-8355 agrega un contrato precompilado ML-DSA: combinado con transacciones Frame, habilita capacidades de seguridad de cuentas post-cuánticas. Alternativa: pre-registrar soporte para firmas post-cuánticas sin activarlas inmediatamente, o definir un formato de derivación compatible con claves post-cuánticas.

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

Una vez que la AA nativa se implemente en Hegotá, reducir el costo de implementación de cuentas inteligentes es crucial. Sin embargo, la EIP-8037 de Glamsterdam aumentará el costo de creación de cuentas. La EIP-7819 permite que las nuevas cuentas utilicen un puntero de delegación ligero, reemplazando los contratos proxy, reduciendo significativamente el nuevo almacenamiento de estado y los costos de implementación. Calificación Nivel A porque costos más bajos de implementación de cuentas pueden reducir significativamente la barrera de entrada para la AA.

Optimización de rendimiento: Escalado continuo de L1

Glamsterdam marcó un cambio en el enfoque de desarrollo de Ethereum: el rendimiento se convirtió en una restricción central en el diseño de protocolos y el desarrollo de clientes. La ejecución diferida, los ajustes en la fijación de precios de recursos y las optimizaciones masivas de clientes aumentaron la capacidad de carga 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: el margen de rendimiento liberado puede usarse para escalar, acortar intervalos, reducir los requisitos de hardware de los nodos o lograr múltiples objetivos simultáneamente.

La necesidad de escalado sigue siendo urgente. Los proyectos eligen ubicación no solo según los precios actuales del Gas, sino también según la capacidad de Ethereum para expandir de manera continua y estable el suministro de espacio de bloques. Implementar actualizaciones de escalado de manera continua brinda mucha más confianza a los desarrolladores que una hoja de ruta en papel. La red principal aún tiene distancia para manejar picos de tráfico de manera estable: en el 11º aniversario de Ethereum, la mediana de Gas era de solo ~0.1 gwei, y una sola actividad de acuñación NFT elevó el Gas al rango de 10 gwei, con el costo mediano de transacción superando 1 dólar. La tendencia de escalado iniciada por Glamsterdam debe continuar en Hegotá.

En resumen, las siguientes EIP continúan el impulso de escalado de Glamsterdam, al tiempo que fortalecen el principio más amplio detrás de él: el rendimiento siempre debe ser una consideración primordial tanto en el trabajo de los clientes como en el diseño del protocolo.

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

Propuestas combinadas de fijación de precios de datos. Después de la actualización Glamsterdam, el cuello de botella central de la red se convirtió en la propagación de la carga útil del bloque. La raíz radica en la falta de estandarización en la contabilidad de Gas para diferentes tipos de bytes, e incluso algunos no tienen tarifas. La EIP-8131 unifica el límite inferior de base para transacciones: extiende las reglas mínimas de tarificación existentes a datos que se pueden confirmar antes de la ejecución; La EIP-8279 límite inferior de bytes para listas de acceso de bloques: tarifica los bytes de listas de acceso generados dinámicamente durante la ejecución.

El mecanismo de tarificación dinámica hace que la EIP-8279 sea más compleja, pero ambas deben verse juntas. La combinación logra una contabilidad unificada para los bytes asociados a las transacciones, limita el peor escenario de carga de bloques, mientras que la gran mayoría de las transacciones ordinarias y de bajo uso de datos no se ven afectadas. Cubre las lagunas en la contabilidad de recursos, allanando el camino para futuros aumentos del límite de Gas.

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

La EIP-8146 mejora la propia ruta crítica al separar la propagación de la BAL y la carga útil, perfeccionando así el mecanismo de reprecio. Esto no solo mejora la eficiencia de propagación, sino que también permite que el cliente de ejecución se anticipe en la precarga de estado y el cálculo posterior de la raíz de estado. Creemos que es una optimización de bajo umbral que no se debe perder. El trabajo de implementación se basa principalmente en el conocido mecanismo CL gossip, por lo que es una EIP de bajo esfuerzo y alto valor, especialmente en una rama con una cantidad significativa de código EL.

Otras propuestas relacionadas con el escalado

【EL】Recalibración de CPSB【Nivel A】

Cambio simple. Recomendamos continuar avanzando, e incluir una según el aumento planificado del límite de Gas y el uso de Gas de estado y ejecución en cadena. EIP-8368 Calibración CPSB para el nuevo límite de Gas: Esquema complementario posterior a la EIP-8037. Cambia el costo de los bytes de estado de un ajuste dinámico según el límite de Gas a un valor fijo, simplificando el desarrollo y las pruebas. La CPSB actual se calcula basándose en un límite de Gas de 150 millones. Después de aumentar el límite de Gas, es probable que Hegotá necesite una recalibración. EIP-8372 Límite de Gas de estado estandarizado: Es una extensión de la EIP-8368, con un ajuste más granular, para escenarios donde los objetivos de crecimiento de estado y los objetivos regulares de Gas se desvían de lo esperado.

【EL】EIP-7862 Raíz de estado diferida【Nivel B】

La especificación en sí es simple, pero según nuestro conocimiento, la complejidad de la implementación del cliente aún no se comprende completamente. La raíz de estado está omnipresente en las bases de código. Los beneficios a corto plazo son limitados, y el valor central se concentra en el largo plazo (extender el tiempo disponible para las pruebas de raíz de estado). Esta Hegotá ya tiene una presión considerable de cambios en la capa de ejecución.

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

Se recomienda no incluirlo. Beneficios limitados (pequeño retraso en el cálculo de la raíz de estado), la necesidad no es urgente, y la EIP-7862 puede lograr un efecto más fuerte, pudiendo reemplazarlo directamente.

Discusión clasificada de las EIP restantes

A continuación, revisamos las propuestas restantes, agrupadas por tema. Para algunas propuestas, nuestra opinión aún se está formando, y la actualizaremos en el futuro combinándola con la comunicación de los equipos de clientes y los autores.

Se espera que Hegotá sea una bifurcación dura con cambios pesados en la capa de ejecución, por lo que debemos controlar estrictamente el umbral de entrada para las EIP de la capa de ejecución. Además de FOCIL y Quick Slots, debemos tratar de limitar el alcance de los cambios en la capa de consenso: reducir el alcance de la actualización, reservando tiempo suficiente para los equipos de clientes para abordar futuras transformaciones arquitectónicas importantes.

【CL】Relacionadas con el mecanismo de emisión

No asignamos una prioridad a la EIP-8363 Emisión y quema progresivas. La política de emisión inflacionaria no debe ser decidida unilateralmente por los desarrolladores centrales. Una lista de prioridades equivaldría a dar una recomendación explícita de implementación a los desarrolladores centrales. La gran mayoría de las EIP son decisiones técnicas, donde la comunidad delega la autoridad de decisión a los equipos centrales de desarrollo; pero el mecanismo de emisión es una política monetaria, que requiere un amplio consenso comunitario. La opinión de los desarrolladores centrales solo debe servir como referencia para la discusión pública. Si se clasifica junto con EIP ordinarias, equivaldría a tratarla como una decisión técnica rutinaria de ACD.

Técnicamente, la EIP-8363 tiene valor. A medida que aumenta el total de ETH apostado, la credibilidad del mecanismo de penalización disminuye; con una alta tasa de participación, las nuevas recompensas en su mayoría compensan la inflación; las economías de escala continúan ampliando la brecha entre los operadores grandes y los apostadores independientes. Pero el cambio también conlleva riesgos: existe incertidumbre en la distribución de las participaciones, y el proceso de solidificación de la política monetaria se reiniciaría. La publicación de discusión de Ansgar enumera completamente los pros y los contras, alineándose con nuestra postura. Algunos miembros de nuestro equipo apoyaron previamente ajustar el mecanismo de emisión y mantienen ese juicio.

Recomendamos discutir el ajuste del mecanismo de emisión solo después de que se haya finalizado todo el resto del alcance de Hegotá. Esto da tiempo suficiente para la discusión comunitaria, evitando interferir con la línea principal de definició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 las optimizaciones orientadas al usuario final. Los cambios puramente de infraestructura deben posponerse a menos que sean necesarios.

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

Limpieza ligera de deuda técnica histórica. Basado en la EIP-7688 para compatibilidad directa con las estructuras de datos de consenso, las pruebas Merkle para campos irrelevantes no se ven afectadas y no afectan a las partes que leen datos en cadena.

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

Se basa en la separación de ePBS entre bloques beacon y carga útil, permitiendo la sincronización independiente de CL y EL, lo que podría simplificar la lógica compleja del cliente.

【CL】EIP-8205 Prerregistro de credenciales de retiro【Nivel D】

Se recomienda no incluirlo. Aunque aborda un punto de dolor real del staking delegado, los esquemas existentes de depósito anticipado ya pueden manejarlo. La complejidad agregada por un nuevo mecanismo completo de protocolo no coincide con los beneficios en esta etapa.

【CL】EIP-8148 Umbral de liquidación personalizable por validador【Nivel D】

Se recomienda no incluirlo. Mecanismo complejo (nuevo contrato del sistema, solicitudes de ejecución, lógica de capa de consenso), beneficios limitados, solo impulsa marginalmente la consolidación del staking minorista. Dada la distribución actual de las participaciones, es poco probable que cambie significativamente la tendencia de concentración de validadores en toda la red.

【CL】EIP-8372 Quema obligatoria de recompensas de ejecución ePBS【Nivel D】

Se recomienda no incluirlo. Probablemente solo generaría más canales fuera de cadena. Años de discusión sobre la quema de MEV no han producido un esquema con consenso amplio.

【CL】EIP-7716 Penalización por pruebas de anti-correlación【Nivel D】

Se recomienda no incluirlo. Falta evidencia suficiente para justificar un ajuste importante en los incentivos de staking, y las actualizaciones de consenso desacopladas rediseñarán el sistema de incentivos de staking.

【CL】EIP-8333 Alineación de puntos de control con límites de época de bloques【Nivel D】

Se recomienda no incluirlo. Es un trabajo de limpieza y optimización que puede posponerse para la actualización de consenso desacoplado de mayor escala.

【CL】EIP-8359 Campo de informe de bloque beacon【Opinión pendiente】

【CL】Trabajo preparatorio para actualización post-cuántica

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

【CL】EIP-8365 Eliminación de credenciales de retiro BLS【Nivel A】

Elimina credenciales de retiro antiguas, simplificando el protocolo y preparando el camino para una futura transición post-cuántica. Cambio simple, adecuado para implementar ahora.

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

Se recomienda no incluirlo. La gran mayoría de los validadores con credencial 0x0 migrarán sus credenciales alrededor del lanzamiento de la EIP-8365, retirando fondos o continuando apostando. No es necesario agregar un mecanismo específico para manejar el stock restante; implementemos primero la EIP-8365 y observemos la situación real.

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

Se recomienda no incluirlo. Implementar solo la seguridad post-cuántica para RANDAO tiene un significado limitado, ya que las claves BLS de los validadores aún presentan riesgo; además, agrega 32 bytes de datos por validador y nueva lógica de gestión de claves, con un propósito único. El esquema completo de consenso post-cuántico aún no se ha implementado. Apoyamos las actualizaciones iterativas, pero el primer paso debe seguir una hoja de ruta unificada, evitando que el esquema sea reemplazado por el estándar final.

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

La mayoría de las optimizaciones previas para zkEVM tienen beneficios limitados a corto plazo, solo facilitan que grupos específicos ejecuten nodos completos, mientras consumen recursos de desarrollo y pueden aumentar el costo de ejecución del EVM. Solo las propuestas cuyo valor a largo plazo supere claramente el costo a corto plazo son adecuadas para su inclusión.

【CL】EIP-8025 Pruebas de ejecución opcionales【Nivel D】

No se debe incluir en esta actualización. La propuesta en sí no requiere una bifurcación dura; vincularla a Hegotá es solo una solicitud de prioridad, con la que no estamos de acuerdo. Antes de implementar pruebas opcionales, se debe aclarar la forma final a largo plazo y avanzar de manera constante, no implementar apresuradamente antes de que se definan los modelos de validador/estado. Pregunta central por resolver: ¿Deben los validadores retener/almacenar parte del estado, o ser completamente sin estado? Los validadores son un grupo importante de nodos con recursos de hardware y red; los cambios que debiliten su papel requieren un umbral de entrada más alto.

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

Cambio pequeño, tiene valor práctico.

【EL】EIP-8200 Conversión de precompilaciones a EVM【Nivel B】

Reemplaza tres tipos de precompilaciones nativas con bytecode EVM. Dos tienen bajo uso y son fáciles de migrar; el tercer tipo se usa ampliamente en pruebas SNARK. Es necesario completar una evaluación de impacto, confirmar que el costo de migración es manejable, o eliminar el tercer tipo del alcance, para que podamos elevarlo a Nivel A.

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

El aumento de Gas es significativo, la perturbación es notable y la necesidad no es urgente. Para reducir el riesgo, se podría realizar una evaluación de impacto o implementarlo junto con un mecanismo de precalentamiento de bloques más adelante.

【EL】EIP-8268 Inclusión de raíz de almacenamiento en lista de acceso de bloque【Nivel B】

Necesita evaluar el impacto real en el volumen de la lista de acceso y el costo de Gas de las transacciones (la EIP-8279 tarificará los bytes de la lista de acceso), donde cada entrada de cuenta de acceso lleva adicionalmente una raíz Merkle de almacenamiento.

【EL】Funcionalidades nativas de EVM

Hegotá aún implementará algunas mejoras dispersas para el EVM. Creemos que después de esta actualización, Ethereum debería desarrollar una hoja de ruta a largo plazo para el desarrollo del EVM junto con todo el ecosistema EVM, y Ethlabs participará en su construcción.

【EL】EIP-5920 Código de operación PAY【Nivel A】

Lógica concisa, es un primitivo subyacente muy valioso para el EVM. Aún es necesario aclarar más los casos de uso reales.

【EL】EIP-8163 Reserva del código de operación EXTENSION (0xae)【Nivel A】

Altamente útil para L2, casi sin costo para L1, solo reserva un identificador.

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

EIP-8058 Descuento por deduplicación de bytecode de contrato, EIP-8298 Instrucción SETCODEFROM para reutilización de código Basado en el modelo de almacenamiento del cliente: el código del contrato se almacena de forma independiente, las cuentas solo apuntan al código a través de su hash. 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 directa con la estructura de almacenamiento de árbol binario. Por ahora, no hay una preferencia clara entre las dos propuestas.

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

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 lineal de memoria EVM: cambio pequeño, elimina el costo de crecimiento cuadrático de expansión de memoria; EIP-7923 Precios lineales de memoria basados en paginación: reformula las reglas subyacentes, más completo pero más complejo.

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

Añadir funciones de operación seguras nativas al EVM tiene valor. Se necesitan pruebas de referencia para confirmar precios razonables; después de completar una evaluación de impacto (escala de transacciones beneficiadas, situación de adaptación del compilador) podría elevarse a Nivel A.

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

Admite la creación de contratos temporales durante el ciclo de vida de una transacción, un primitivo subyacente genérico. Pero la propuesta es bastante compleja; después de completar la evaluación de dificultad de desarrollo y pruebas, se podría reclasificar.

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

Se recomienda no incluirlo. Es un cambio disruptivo, abusando de la semántica de ORIGIN.

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

Se recomienda no incluirlo. El alcance del cambio es enorme, introduce dependencia de ZK. Si se implementa en el futuro, debería ser una propuesta central de actualización.

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

【EL】EIP-4758 Desactivación de SELFDESTRUCT【Opinión pendiente】

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

【EL】EIP-8173 Fundamentos de flujo de control EVM【Opinión pendiente】

【EL】EIP-8253 Incremento automático de Nonce para cuentas de almacenamiento con Nonce cero【Opinión pendiente】

【EL】EIP-8030 Adición de soporte para algoritmo P256【Opinión pendiente】

【EL】Mecanismos de precios de EVM

Glamsterdam aumentó el costo de Gas para operaciones con precios bajos que limitaban el rendimiento. Las propuestas de precios relacionadas en Hegotá van en la dirección opuesta: reducir el costo de operaciones actualmente sobrepreciadas que limitan la adopción de aplicaciones, pero contribuyen poco al escalado de toda la red, siendo optimizaciones "agradables de tener". Apoyamos ajustes de precios específicos, pero las propuestas que agregan nuevos modelos de tarificación deben estar bien diseñadas y tener proponentes comprometidos que verifiquen completamente los riesgos antes de su inclusión.

【EL】EIP-8358 Tarificación neta de Gas por cambios de cuenta【Nivel B】

Los beneficios son cuestionables. Datos de una muestra de 900 bloques de mainnet y 400k transacciones muestran: solo el 2.07% de las transacciones ahorran Gas, y el Gas total ahorrado por bloque es solo el 1.14%.

【EL】EIP-7973 Tarificación de escrituras en cuentas calientes【Opinión pendiente】

【EL】EIP-7609 Reducción del Gas base para TLOAD/TSTORE【Opinión pendiente】

【EL】EIP-7971 Límite máximo duro para almacenamiento transitorio【Opinión pendiente】

【EL】EIP-3298 Eliminación de reembolsos de Gas【Opinión pendiente】

【EL】EIP-8374 Retención de conjunto de acceso caliente después de reversión【Opinión pendiente】

【EL】EIP-8115 Cobro por lotes de tarifas prioritarias al final del bloque【Opinión pendiente】

【EL】EIP-8188 Registro del último bloque de escritura para cuentas y slots de almacenamiento【Opinión pendiente】

【EL】【CL】Datos de ejecución e indexación

【EL】【CL】EIP-7668 Eliminación del filtro Bloom【Opinión pendiente】

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

【EL】EIP-8116 Simplificación del campo acumulado de recibos【Opinión pendiente】

【EL】EIP-8304 Indexación de logs y transacciones sin confianza【Opinión pendiente】

【EL】【CL】Capa de red

La red P2P de Ethereum aún tiene espacio para optimizaciones específicas, especialmente en los mecanismos de propagación de mensajes de transacciones, blobs y pruebas.

【CL】EIP-8371 RowDAS Reconstrucción distribuida de Blobs【Nivel A】

Evita que la reconstrucción completa y el alojamiento de nodos completos se conviertan en un cuello de botella para la escalabilidad de Blobs. A largo plazo, un mecanismo de reconstrucción distribuida debe incorporarse al protocolo, lo que podría eliminar el requisito de alojamiento de Blobs para los validadores. Aún se necesita evaluar más la complejidad de implementación.

【CL】EIP-8142 Blob-in-Block (BiB)【Nivel D】

El momento no es oportuno, la urgencia no es suficiente, quedan muchos problemas por resolver (si usar KZG, nuevo tema de transmisión). No deseamos introducir mecanismos KZG en la ruta crítica de producción de bloques, y las alternativas aún no están claras.

【CL】EIP-8243 Transmisión por lotes de pruebas desde la fuente【Nivel D】

No puede garantizar claramente un acortamiento del tiempo de finalización, el límite superior de carga no está claro; la capacidad del mecanismo para defenderse de DoS necesita ser verificada.

【EL】EIP-8077 eth/XX Transmisión de transacciones basada en Nonce【Opinión pendiente】

【EL】EIP-8094 eth/vhash Protocolo de pool de transacciones compatible con Blobs【Opinión pendiente】

【CL】EIP-8334 Transmisión por lotes de pruebas【Opinión pendiente】

Conclusión

Las actualizaciones de Ethereum son de alto riesgo, por lo que la complejidad es inevitable. Miles de nodos en todo el mundo necesitan cambiar las reglas de forma sincronizada en el mismo intervalo, y el funcionamiento de la red no puede interrumpirse. Este rigor ha respaldado las exitosas actualizaciones anteriores de Ethereum, logrando una red descentralizada con cero tiempo de inactividad durante 11 años consecutivos.

Lo anterior es el juicio actual de Ethlabs sobre Hegotá. A medida que avance el desarrollo y se profundicen las discusiones, actualizaremos continuamente nuestros puntos de vista una vez que surja nueva evidencia. Algunas EIP son impulsadas por miembros de Ethlabs, mientras que otras provienen de la gran cantidad de excelentes investigadores, desarrolladores de clientes y contribuyentes independientes de Ethereum. Pero para que cualquier esquema se implemente, se requiere la colaboración de los equipos de clientes, billeteras, aplicaciones, L2, proveedores de infraestructura, instituciones, operadores de nodos y usuarios finales. Ethereum pertenece al mundo, y los grandes avances de la red nunca han sido el logro de una sola organización.