Paradigm CTO: Interpretando el Hard Fork de Praga después de la actualización de Ethereum Cancún

Texto: Georgios Konstantopoulos, CTO, Paradigm

Compilador: Luffy, Foresight News

El propósito de este artículo es proporcionar una visión general de los puntos de vista del equipo de Paradigm Reth sobre qué EIP deberían incluirse en el Hard Fork de Praga (la próxima actualización importante de Consensus Ethereum después del Hard Fork de Cancún) y nuestro plan general para “EL Core Dev” en 2024. Los siguientes puntos de vista están en constante evolución y representan los puntos de vista actuales del equipo de Reth y no representan necesariamente a todo el equipo de Paradigm.

Creemos que es probable que el Hard Fork de Praga se materialice en EthereumTestnet en el tercer trimestre de 2024 y en Mainnet a finales de año. Debe incluir:

• EIP relacionados con el staking, como EIP-7002 que admite el re-staking y los pools de staking sin confianza.
• Variaciones de EVM separadas.
• Estamos dispuestos a trabajar con cualquier equipo que quiera profundizar en Praga u otro futuro Hard Fork de EL y estaremos encantados de proporcionar orientación y asistencia sobre cómo modificar el código base de Reth.

Qué hacer:

• Creemos que se deben priorizar los siguientes EIP: 7002, 6110, 2537.
• Apoyamos el EOF descrito en la especificación y esperamos finalizar el alcance y crear un meta EIP lo antes posible.
• Estamos dispuestos a agregar EIP-4844 Max Blob Gas. No tenemos una opinión sobre números específicos, pero invitamos a la gente de datos a trabajar con nosotros en el tema.
• Nos complace lanzar una versión de EIP-7547: contiene una lista para ayudar a la capa base a resistir la censura.

Lo que no se debe hacer:

• No apoyamos la inclusión de Verkle Tries en el Hard Fork de Praga, pero apoyamos al equipo del cliente para que comience a trabajar en esto en el segundo trimestre de 2024 con el compromiso de lanzarlo en la actualización de Osaka en 2025.
• No creemos que debamos aumentar el límite de gas de ejecución de L1 o el tamaño del contrato, pero invitamos a la gente de datos a trabajar con nosotros para investigar su impacto en la red. Estamos dispuestos a cambiar nuestra percepción porque las pruebas anteriores han demostrado que Reth Node puede manejar el aumento de la carga sin ningún problema.
• Creemos que los EIP de abstracción de billetera/cuenta deben probarse de manera más contradictoria entre sí para comprender mejor el espacio de compensación. Si no son mutuamente excluyentes, entonces estaremos dispuestos a implementar múltiples EIP relacionados con AA en el futuro.
• Si la comunidad está de acuerdo con la rumoreada puerta trasera de la NSA, podemos cruzar la línea en EIP-7212 (secp256r1).
• Otros temas de la hoja de ruta: No tenemos una comprensión real del acoplamiento de las bifurcaciones CL EIP o CL/EL, pero las EIP 7549 y 7251 parecen prometedoras. También queremos contribuir al trabajo de PeerDAS desde el lado de EL tanto como sea posible. Por el momento, queremos evitar la introducción de raíces SSZ (EIP 6404, 6465, 6466). Por último, vemos la oportunidad de proporcionar una solución de archivado de datos a largo plazo para los blobs, el historial y el estado caducados, ya que tanto EIP-4844 como EIP-4444 lo dejan claro, y queda por determinar si Ethereum está dispuesto a proporcionar dicha solución.

Explícalo en detalle a continuación.

Cosas que hacer

En abstracto, apoyamos 1) cerrar aún más la brecha entre CL y EL, y 2) las modificaciones de EVM se pueden realizar como trabajo en solitario y se pueden probar por separado y en paralelo.

EIP-7002

Este EIP desbloquea grupos de re-staking y staking sin confianza al permitir que Smart Contract en el lado EL controle 1 o más validadores en el lado CL. En nuestra opinión, al menos permitirá que los grupos de participación existentes eliminen una capa de centralización del contrato inteligente que permite los retiros.

La introducción de la precompilación con estado en la EVM es una nueva abstracción que necesitamos obtener en nuestra implementación de EVM, pero más allá de eso, creemos que es una EIP sencilla.

EIP-6110

El EIP introduce los depósitos en el estado EL, simplificando la gestión estatal que debe realizarse en el CL. En términos de implementación, esto es similar al seguimiento de los retiros de CL, por lo que, en general, creemos que también es un EIP simple e independiente.

EIP-2537

Actualmente existen múltiples implementaciones de BLS12-381, que es una curva de uso frecuente en muchos SNARK, algoritmos de firma BLS y EIP-4844. Consideramos que es de baja complejidad de implementación porque solo expone el algoritmo de validación de la curva a través de una interfaz precompilada. Es posible que también necesitemos el hash de la curva BLS12-381 precompilado.

EOF

*Nota del traductor: EOF son las siglas de EVM Object Format, que se traduce como formato de objeto de Ethereum, y contiene una serie de EIP que prometen hacer que la ejecución de Ethereum sea más eficiente, coherente y actualizable. Los primeros planes se implementaron en la Actualización de Shanghái, que luego se eliminó. *

EOF será compatible tanto con Solidity como con Vyper. No hay duda de que el formato de código y los ajustes de verificación harán que el análisis de código de bytes sea mucho más simple, y recomendamos considerar cuidadosamente cualquier otra cosa. Hemos recomendado algunos EIP a continuación, pero estamos dispuestos a modificarlos aún más.

En el lado positivo:

• Cambios exclusivos de EVM que pueden ser probados usando Ethereum / Testnet e implementados por una sola persona.
• Cambios en EVM que quieren Vyper y Solidity
• Ayuda a mejorar el rendimiento y aumentar los límites de tamaño de los contratos.
• Elimina la necesidad de análisis de código de bytes en tiempo de ejecución para la EVM. Sin almacenamiento en caché, el tiempo de análisis puede ser tan alto como el 50% y aumenta a medida que aumenta el tamaño del contrato.
• Habilitar la carga parcial de código para ayudar a ejecutar grandes contratos inteligentes.
• Devex: Permitirá solucionar el problema de la “pila demasiado profunda” a través de dupN/swapN y otras mejoras en las herramientas.
• Preparado para el futuro: Las nuevas funciones se pueden introducir de forma segura en L2 y la herramienta sabrá qué es compatible.

Aspectos negativos:

• Alcance y objetivos dinámicos.
• No hay un fuerte impulso por parte de los proponentes para incluirlo.
• Todavía se requiere soporte para código heredado
• Antes de la adopción, hubo un desacuerdo temporal entre EthereumMainnet y otras cadenas de EVM.

Creemos que las siguientes características de EOF deberían implementarse en 2024. Recomendamos determinar el alcance y comprometerse con la implementación lo antes posible. Cualquier otra cosa debe tenerse en cuenta para implementaciones posteriores. Nuestras recomendaciones son:

• EIP-3540 (EOF - EVM Object Format v1): Introduce código y contenedores de datos, y agrega estructura y control de versiones al código de bytes de Ethereum.
• EIP-3670 (EOF - Validación de código): Rechaza cualquier contrato que no siga el formato EOF cuando se implementa. Ejecute código más estructurado y deshabilite las directivas no válidas e indefinidas. • EIP-663 (Instrucciones de SWAP Infinito y DUP): Esto resuelve el problema de la “pila demasiado profunda” en solidez y tiene efectos secundarios como un valor instantáneo a través del análisis JUMPDEST. Una característica muy deseable del lenguaje EVM.
• EIP-4200 (EOF - Static Relative Jumps): Mejor análisis estático sin saltos inciertos. Mejor compilación de AOT. Los saltos son más propicios para la reutilización del código.
• EIP-4750 (EOF - Función): Requiere resolución de subrutinas que pueden usar saltos dinámicos pero no estáticos. También permite que se cargue código parcial, lo que funciona perfectamente con Verkle para aumentar el límite de tamaño del contrato.
• EIP-5450 (EOF - Validación de pila): Verifique los requisitos de código y pila. Elimine las comprobaciones de desbordamiento y desbordamiento de la pila en tiempo de ejecución para todas las instrucciones excepto CALLF (EIP-4750)
• EIP-7480 (EOF - Instrucción de acceso a la sección de datos): Permite el acceso a la parte de datos del código de bytes.
• EIP-7069 (Directiva CALL mejorada): Capacidad para eliminar la observabilidad del gas de CALL, lo que facilita la revalorización del gas en el futuro. Aunque es independiente de EOF, vemos esta como una buena oportunidad para introducirlo.

No estamos tan seguros de EIP-6206 (EOF - JUMPF y función de no retorno). Si bien permite la optimización de llamadas de cola en funciones EOF, todavía tenemos que ver qué hace la generación de perfiles de lenguaje por ello. Si no lo hacemos, creemos que podemos eliminarlo del ámbito e incluirlo en una actualización posterior de EOF.

Estimamos que la carga de trabajo anterior es de 1 persona trabajando a tiempo completo durante 1-2 meses. Estamos dispuestos a reducirlo aún más.

Una nota sobre el código de bytes heredado:

• Si bien podemos prohibir el nuevo código de bytes heredado/no EOF, no podemos dejar de usar el código de bytes heredado existente, que actúa efectivamente como EOF “v0”. El código de bytes heredado todavía requiere el análisis JUMPDEST después de EOF y aún requiere un manejo especial del código para fragmentarlo en fragmentos en Verkle Trys.
• Hasta donde sabemos, no es posible verificar una conversión de código de bytes que no es EOF a EOF sin acceso al código fuente, pero estamos dispuestos a buscar mecanismos para facilitar esta conversión.
• Alternativamente, estaríamos dispuestos a explorar formas de forzar la migración estatal a EOF.

Aumentar el número de blobs EIP-4844

Estamos abiertos a este cambio, que corresponderá a un aumento de MAX_BLOB_GAS_PER_BLOCK y TARGET_BLOB_GAS_PER_BLOCK. EIP-4844 dice:

Seleccione los valores de TARGET_BLOB_GAS_PER_BLOCK y MAX_BLOB_GAS_PER_BLOCK para que correspondan a un destino de 3 blobs (0,375 MB) por bloque (hasta 6 blobs). Estos pequeños límites iniciales están diseñados para minimizar la tensión en la red causada por el EIP, y se espera que el número de blobs aumente en futuras actualizaciones a medida que la red demuestre confiabilidad en bloques más grandes.

En realidad, este es un pequeño cambio de código y necesitamos investigar su impacto real en el grupo de transacciones, pero pensamos que podríamos reutilizar la infraestructura de pruebas de estrés EIP-4844 para esto. Puede ser difícil para el CL difundir más manchas, y respetamos las opiniones del equipo del CL.

No lo hagas

Verkle intenta

Tl; En resumen: No vemos un intento de desplegar Verkle a finales de 2024 o principios de 2025. Recomendamos que el equipo asigne recursos para esto en el segundo trimestre de 2024 y se comprometa a implementarlo en el Osaka Hard Fork en el segundo y tercer trimestre de 2025.

En el lado positivo:

• Permite clientes ligeros más baratos con pruebas de almacenamiento más pequeñas.
• Ejecución sin estado mediante la inclusión del preestado de lectura en el encabezado del bloque, lo que también puede conducir a mejoras de rendimiento debido al acceso al estado estático.
• Aumente el límite de tamaño del contrato fragmentando el código de bytes y habilitando la carga parcial de código.
• La caducidad del estado se ha vuelto más aceptable debido al menor costo de “restaurar” el estado.

Desventajas:

• El impacto de los cambios y los esfuerzos para implementarlos y probarlos.
• Cambios en el cálculo de gas: Verkle Tries introduce el tamaño del testigo en la función de cálculo de gas. Nos preocupa que aún no se hayan explorado los cambios en los precios del almacenamiento (por ejemplo, ¿cuál es el costo de los principales consumidores de gas después de Verkle)?
• Integración de aplicaciones: ¿Qué debe hacer una aplicación con un validador Merkle Patricia Trie cuando se ejecuta la transición de superposición? ¿Cómo debe comportarse eth_getProof?

Si bien entendemos los beneficios de Verkle Try, creemos que se debe prestar más atención a cómo deben encajar las herramientas/contratos de terceros y qué impacto tendrá esto en la Capa 2 y similares durante el período de transición. Inicialmente teníamos dudas sobre la estrategia de migración porque establecía que el Verkle trie debía actualizarse cuando se leyera el estado de un MPT preexistente, pero ese ya no parece ser el caso. Por lo tanto, apoyamos el enfoque de superposición como una ruta de migración viable.

La documentación de la estrategia de migración de Verkle parece obsoleta, ya que la mayoría de los recursos todavía indican que el trie de Verkle debe actualizarse al leer el estado de MPT. Nos gustaría ver documentación de transición con los últimos enfoques, como este excelente. También nos gustaría ver un borrador de EIP sobre la estrategia de transición.

Por lo tanto, seguimos apoyando su despliegue en 2025 en lugar de implementarlo en el Hard Fork de Praga.

Límite de gas L1

No creemos que aumentar el límite de gas L1 suponga una gran diferencia en la práctica. También creemos que la mayoría de los clientes pueden soportar un aumento de carga promedio, pero queremos estar atentos al peor de los casos, por lo que no recomendamos aumentar el límite de gas L1 en este momento. Creemos que aumentar el límite de gas de burbujas es una solución más prometedora a corto plazo.

Invitamos a otros a trabajar con nosotros en la investigación en esta dirección, a menudo en torno a la ruptura de la medición de recursos en la EVM. La disertación de Broken Meter es un buen punto de partida para la investigación en esta área.

Abstracción de cuentas

Nos encantaría incluir 1 o más EIP, pero nos gustaría ver más comparaciones de la experiencia del usuario y la experiencia del desarrollador entre cada propuesta para comprender mejor las compensaciones y el esfuerzo de la integración de herramientas. Estamos analizando los siguientes EIP/ERC, pero no dude en aconsejarnos:

• EIP-3074: Código de operación AUTH y AUTHCALL
• ERC-4337: Uso de Alt Mempool para la abstracción de cuentas
• EIP-5806: Transacción delegada
• EIP-5920: Código de operación de pago
• EIP-6913: Directiva SETCODE
• EIP-7377: Transacciones de migración
• RIP-7560: Abstracción de cuentas nativas - Core EIP - Fellowship of Ethereum Magicians

Lo que debemos tener en cuenta anteriormente es que la “abstracción de cuentas” es como la “función de verificación abstracta, el objetivo principal es implementar la rotación de claves secretas, hacer una clave multifirma y proporcionarnos un camino para lograr automáticamente la resistencia cuántica”.