Nuevo artículo de Vitalik: El posible futuro del protocolo de Ethereum The Verge

De hecho, necesitaremos varios años para obtener una prueba de validez del consenso de Ethereum.

Título original: 《Possible futures of the Ethereum protocol, part 4: The Verge》

Autor: Vitalik Buterin

Traducción: Mensh, ChainCatcher

 

Agradecimientos especiales a Justin Drake, Hsia-wei Wanp, Guillaume Ballet, Icinacio, Rosh Rudolf, Lev Soukhanoy, Ryan Sean Adams y Uma Roy por sus comentarios y revisión.

Una de las funciones más poderosas de la blockchain es que cualquier persona puede ejecutar un nodo en su propia computadora y verificar la corrección de la blockchain. Incluso si 9596 nodos que ejecutan el consenso de la cadena (PoW, PoS) acuerdan inmediatamente cambiar las reglas y comienzan a producir bloques bajo las nuevas reglas, cualquier persona que ejecute un nodo de verificación completa rechazará aceptar la cadena. Los mineros que no formen parte de ese grupo conspirador se agruparán automáticamente en una cadena que sigue las reglas antiguas y continuarán construyendo sobre esa cadena, mientras que los usuarios que validan completamente seguirán esa cadena.

Esta es la diferencia clave entre la blockchain y los sistemas centralizados. Sin embargo, para que esta característica se mantenga, ejecutar un nodo de verificación completa debe ser realmente factible para suficientes personas. Esto aplica tanto para los creadores de bloques (porque si no verifican la cadena, no contribuyen a la ejecución de las reglas del protocolo), como para los usuarios comunes. Hoy en día, ejecutar un nodo en una laptop de consumo (incluyendo la laptop que estoy usando para escribir este artículo) es posible, pero difícil de lograr. The Verge busca cambiar esto, haciendo que el costo computacional de verificar completamente la cadena sea bajo, de modo que cada billetera móvil, billetera de navegador e incluso smartwatch validen por defecto.

Hoja de ruta de The Verge 2023

Originalmente, "Verge" se refería a trasladar el almacenamiento del estado de Ethereum a árboles Verkle, una estructura arbórea que permite pruebas más compactas y permite la verificación sin estado de los bloques de Ethereum. Un nodo puede verificar un bloque de Ethereum sin almacenar ningún estado de Ethereum (saldos de cuentas, código de contratos, almacenamiento, etc.) en su disco duro, a cambio de gastar unos cientos de KB de datos de prueba y unos cientos de milisegundos adicionales para verificar una prueba. Hoy en día, Verge representa una visión más amplia, enfocada en lograr la máxima eficiencia de recursos en la verificación de la cadena de Ethereum, lo que incluye no solo tecnología de verificación sin estado, sino también el uso de SNARKs para verificar toda la ejecución de Ethereum.

Además de la atención a largo plazo en la verificación SNARK de toda la cadena, otro nuevo problema es si los árboles Verkle son la mejor tecnología. Los árboles Verkle son vulnerables a ataques de computadoras cuánticas, por lo que si reemplazamos los actuales árboles Merkle Patricia KECCAK por árboles Verkle, tendremos que reemplazar el árbol nuevamente en el futuro. El método auto-sustituyente de los árboles Merkle es saltar directamente a usar STARKs sobre ramas Merkle, colocándolos en un árbol binario. Históricamente, esto se consideraba inviable por el sobrecosto y la complejidad técnica. Sin embargo, recientemente, hemos visto a Starkware probar 1.7 millones de hashes Poseidon por segundo en una laptop, y gracias a tecnologías como GKB, el tiempo de prueba de hashes más "tradicionales" también se está reduciendo rápidamente. Así, en el último año, "Verge" se ha vuelto más abierto y tiene varias posibilidades.

The Verge: Objetivos clave

• Cliente sin estado: el espacio de almacenamiento requerido para clientes de verificación completa y nodos marcadores no debe superar unos pocos GB.
• (A largo plazo) Verificación completa de la cadena (consenso y ejecución) en un smartwatch. Descargar algunos datos, verificar el SNARK, listo.

En este capítulo

• Cliente sin estado: ¿Verkle o STARKs?
• Prueba de validez de la ejecución de la EVM
• Prueba de validez del consenso

Verificación sin estado: ¿Verkle o STARKs?

¿Qué problema queremos resolver?

Hoy en día, los clientes de Ethereum necesitan almacenar cientos de gigabytes de datos de estado para verificar bloques, y esta cantidad aumenta cada año. Los datos de estado originales aumentan unos 30GB por año, y cada cliente debe almacenar algunos datos adicionales para actualizar eficientemente los tríos.

Esto reduce la cantidad de usuarios que pueden ejecutar un nodo de verificación completa de Ethereum: aunque los discos duros grandes capaces de almacenar todo el estado de Ethereum e incluso años de historia son comunes, las computadoras que la gente compra por defecto suelen tener solo unos cientos de gigabytes de almacenamiento. El tamaño del estado también genera mucha fricción al establecer un nodo por primera vez: el nodo debe descargar todo el estado, lo que puede llevar horas o días. Esto genera varios efectos en cadena. Por ejemplo, aumenta mucho la dificultad para que los creadores de nodos actualicen su configuración. Técnicamente, se puede hacer sin tiempo de inactividad: iniciar un nuevo cliente, esperar a que se sincronice, luego apagar el cliente antiguo y transferir las claves, pero en la práctica esto es muy complejo técnicamente.

¿Cómo funciona?

La verificación sin estado es una técnica que permite a los nodos verificar bloques sin tener todo el estado. En su lugar, cada bloque viene acompañado de un testigo, que incluye: (i) los valores, código, saldos y almacenamiento en posiciones específicas del estado que el bloque accederá; (ii) pruebas criptográficas de que esos valores son correctos.

En la práctica, implementar la verificación sin estado requiere cambiar la estructura del árbol de estado de Ethereum. Esto se debe a que el actual árbol Merkle Patricia es extremadamente poco amigable para cualquier esquema de prueba criptográfica, especialmente en el peor de los casos. Ya sea ramas Merkle "crudas" o la posibilidad de envolverlas en STARK, el principal problema proviene de algunas debilidades del MPT:

1. Es un árbol de seis ramas (es decir, cada nodo tiene 16 hijos). Esto significa que, en un árbol de tamaño N, una prueba requiere en promedio 32*(16-1)*log16(N) = 120*log2(N) bytes, o aproximadamente 3840 bytes en un árbol de 2^32 ítems. Para un árbol binario, solo se necesitan 32*(2-1)*log2(N) = 32*log2(N) bytes, o aproximadamente 1024 bytes.

2. El código no está merkleizado. Esto significa que para probar cualquier acceso al código de una cuenta, se debe proporcionar todo el código, hasta 24000 bytes.

 

Podemos calcular el peor caso así:

30000000 gas / 2400 (costo de lectura de cuenta fría) * (5 * 488 + 24000) = 330000000 bytes

El costo de las ramas es un poco menor (usando 5*480 en lugar de 8*480), porque cuando hay muchas ramas, la parte superior se repite. Pero aun así, la cantidad de datos a descargar en un slot es completamente irreal. Si intentamos envolverlo en STARK, nos encontramos con dos problemas: (i) KECCAK no es amigable para STARK; (ii) 330MB de datos significa que debemos probar 5 millones de llamadas a la función round de KECCAK, lo que puede ser imposible de probar para cualquier hardware excepto el de consumo más potente, incluso si logramos que STARK pruebe KECCAK de manera eficiente.

Si reemplazamos directamente el árbol hexadecimal por uno binario y merkleizamos adicionalmente el código, el peor caso sería aproximadamente 30000000/2400*32*(32-14+8) = 10400000 bytes (14 es la resta por los bits redundantes de 2^14 ramas, y 8 es la longitud de la prueba para entrar en la hoja del bloque de código). Cabe destacar que esto requiere cambiar el costo de gas, cobrando por cada bloque de código accedido; EIP-4762 hace esto. 10.4 MB es mucho mejor, pero para muchos nodos, sigue siendo demasiado para descargar en un slot. Por eso, necesitamos técnicas más potentes. Hay dos soluciones líderes: árboles Verkle y árboles hash binarios con STARK.

Árboles Verkle

Los árboles Verkle usan compromisos vectoriales basados en curvas elípticas para pruebas más cortas. La clave es que, sin importar el ancho del árbol, cada parte de la prueba correspondiente a una relación padre-hijo es de solo 32 bytes. La única limitación al ancho del árbol es que, si el árbol es demasiado ancho, la eficiencia de cálculo de la prueba disminuye. La implementación propuesta para Ethereum tiene un ancho de 256.

Así, el tamaño de una sola rama en la prueba se convierte en 32 - log256(N) = 4*log2(N) bytes. Por lo tanto, el tamaño máximo teórico de la prueba es aproximadamente 30000000 / 2400 *32* (32 -14 + 8) / 8 = 130000 bytes (debido a la distribución desigual de los bloques de estado, el cálculo real varía un poco, pero como primera aproximación es válido).

También hay que notar que, en todos los ejemplos anteriores, este "peor caso" no es el peor de todos: un caso peor sería que un atacante "minara" dos direcciones para que tengan un prefijo común largo en el árbol y leyera datos de una de ellas, lo que podría duplicar la longitud de la rama en el peor caso. Pero incluso así, la longitud máxima de la prueba en un árbol Verkle sería de 2.6MB, lo que coincide con los datos de verificación en el peor caso actual.

También aprovechamos esta observación para otra cosa: hacemos que el costo de acceder a espacios de almacenamiento "adyacentes" sea muy bajo: ya sea muchos bloques de código del mismo contrato o ranuras de almacenamiento adyacentes. EIP-4762 define la adyacencia y cobra solo 200 gas por acceso adyacente. En ese caso, el tamaño máximo de la prueba sería 30000000 / 200*32 - 4800800 bytes, lo que sigue estando dentro de un margen razonable. Si por seguridad queremos reducir este valor, podemos aumentar un poco el costo del acceso adyacente.

Árbol hash binario con STARK

La técnica es simple: se hace un árbol binario, se obtiene una prueba máxima de 10.4 MB, se prueban los valores en el bloque, y luego se reemplaza la prueba por una prueba STARK. Así, la prueba solo contiene los datos probados, más una sobrecarga fija de 100-300kB del STARK real.

El principal desafío aquí es el tiempo de verificación. Podemos hacer el mismo cálculo que antes, pero en vez de bytes, contamos hashes. Un bloque de 10.4 MB implica 330000 hashes. Si sumamos la posibilidad de que un atacante "mine" direcciones con prefijos comunes largos, el peor caso sería unos 660000 hashes. Así que, si podemos probar 200,000 hashes por segundo, está bien.

En laptops de consumo usando la función hash Poseidon, estos números ya se alcanzan, y Poseidon fue diseñado específicamente para ser amigable con STARK. Sin embargo, el sistema Poseidon aún es relativamente inmaduro, por lo que muchos no confían en su seguridad. Por lo tanto, hay dos caminos realistas:

1. Realizar rápidamente un análisis de seguridad exhaustivo de Poseidon y familiarizarse lo suficiente como para implementarlo en L1
2. Usar funciones hash más "conservadoras", como SHA256 o BLAKE

Si se quiere probar funciones hash conservadoras, el círculo STARK de Starkware solo puede probar 10-30k hashes por segundo en laptops de consumo al momento de escribir esto. Sin embargo, la tecnología STARK está mejorando rápidamente. Incluso hoy, la tecnología basada en GKR muestra que esta velocidad puede aumentar a 100-200k.

Casos de uso de testigos fuera de la verificación de bloques

Además de la verificación de bloques, hay otros tres casos clave que requieren verificación sin estado más eficiente:

• Mempool: cuando una transacción se transmite, los nodos de la red P2P deben verificar su validez antes de retransmitirla. Hoy, la verificación incluye la firma, pero también verificar que el saldo sea suficiente y que el nonce sea correcto. En el futuro (por ejemplo, con abstracción de cuentas nativa como EIP-7701), esto podría implicar ejecutar código EVM que acceda a cierto estado. Si el nodo es sin estado, la transacción debe incluir pruebas del estado de los objetos.
• Listas de inclusión: es una función propuesta que permite a los validadores de prueba de participación (probablemente pequeños y no complejos) forzar la inclusión de transacciones en el siguiente bloque, sin importar la voluntad de los constructores de bloques (probablemente grandes y complejos). Esto debilita la capacidad de los poderosos de manipular la blockchain retrasando transacciones. Sin embargo, requiere que los validadores puedan verificar la validez de las transacciones en la lista de inclusión.
• Clientes ligeros: si queremos que los usuarios accedan a la cadena a través de billeteras (como Metamask, Rainbow, Rabby, etc.), necesitan ejecutar un cliente ligero (como Helios). El módulo central de Helios proporciona a los usuarios la raíz de estado verificada. Para una experiencia completamente sin confianza, los usuarios necesitan pruebas para cada llamada RPC que hagan (por ejemplo, para llamadas de Ethereum, necesitan pruebas de todo el estado accedido durante la llamada).

Todos estos casos tienen en común que requieren muchas pruebas, pero cada una es pequeña. Por lo tanto, las pruebas STARK no tienen sentido práctico para ellos; lo más realista es usar ramas Merkle directamente. Otra ventaja de las ramas Merkle es que son actualizables: dada una prueba de un objeto de estado X con raíz en el bloque B, si se recibe un sub-bloque B2 y su testigo, se puede actualizar la prueba para que tenga raíz en B2. Las pruebas Verkle también son actualizables de forma nativa.

¿Qué relación tiene con la investigación existente?

• Verkle trees
• Papel original de John Kuszmaul sobre árboles Verkle
• Starkware
• Poseidon2 paper
• Ajtai (funciones hash rápidas alternativas basadas en la dureza de retículas)
• Verkle.info

¿Qué más se puede hacer?

El trabajo principal restante es:

1. Más análisis sobre las consecuencias de EIP-4762 (cambios en el costo de gas sin estado)

2. Más trabajo en completar y probar el programa de transición, que es la parte más compleja de cualquier implementación sin estado

3. Más análisis de seguridad de Poseidon, Ajtai y otras funciones hash "amigables con STARK"

4. Desarrollar aún más funciones de protocolo STARK ultra eficientes para hashes "conservadores" (o "tradicionales"), como las basadas en Binius o GKR.

Además, pronto decidiremos entre tres opciones: (i) árboles Verkle, (ii) funciones hash amigables con STARK y (iii) funciones hash conservadoras. Sus características se resumen en la siguiente tabla:

Además de estos "números principales", hay otras consideraciones importantes:

• Hoy en día, el código de los árboles Verkle ya está bastante maduro. Usar cualquier otro código que no sea Verkle retrasaría la implementación, probablemente retrasando un hard fork. Esto no es un problema, especialmente si necesitamos más tiempo para analizar funciones hash o implementar validadores, o si queremos incluir otras funciones importantes en Ethereum antes.
• Actualizar la raíz de estado usando hashes es más rápido que usando árboles Verkle. Esto significa que los métodos basados en hashes pueden reducir el tiempo de sincronización de los nodos completos.
• Los árboles Verkle tienen interesantes propiedades de actualización de testigos: los testigos Verkle son actualizables. Esta propiedad es útil para mempool, listas de inclusión y otros casos, y también puede ayudar a mejorar la eficiencia de implementación: si se actualiza un objeto de estado, se puede actualizar el testigo de la penúltima capa sin leer el contenido de la última capa.
• Los árboles Verkle son más difíciles de probar con SNARK. Si queremos reducir el tamaño de la prueba a unos pocos miles de bytes, las pruebas Verkle presentan dificultades. Esto se debe a que la verificación de pruebas Verkle introduce muchas operaciones de 256 bits, lo que requiere que el sistema de pruebas tenga mucha sobrecarga o una estructura interna personalizada con partes de prueba Verkle de 256 bits. Esto no es un problema para la verificación sin estado en sí, pero sí añade dificultades.

Si queremos obtener la actualizabilidad de los testigos Verkle de manera segura ante computadoras cuánticas y razonablemente eficiente, otra vía posible es un árbol Merkle basado en retículas.

Si en el peor de los casos la eficiencia del sistema de pruebas no es suficiente, podemos usar la herramienta inesperada del gas multidimensional: establecer límites de gas separados para (i) calldata; (ii) cómputo; (iii) acceso al estado y posiblemente otros recursos. El gas multidimensional aumenta la complejidad, pero a cambio limita más estrictamente la relación entre el caso promedio y el peor caso. Con gas multidimensional, el número máximo de ramas a probar podría reducirse de 12500 a, por ejemplo, 3000. Esto haría que BLAKE3 sea (apenas) suficiente incluso hoy.

El gas multidimensional permite que los límites de recursos de los bloques se acerquen más a los límites de recursos del hardware subyacente

Otra herramienta inesperada es retrasar el cálculo de la raíz de estado hasta el slot posterior al bloque. Así, tendríamos 12 segundos completos para calcular la raíz de estado, lo que significa que incluso en el caso más extremo, una velocidad de prueba de 60000 hashes por segundo sería suficiente, lo que nuevamente haría que BLAKE3 apenas cumpla con los requisitos.

La desventaja de este método es que aumenta la latencia del cliente ligero en un slot, aunque hay técnicas más ingeniosas para reducir esta latencia a solo la latencia de generación de la prueba. Por ejemplo, la prueba puede transmitirse en la red tan pronto como la genere cualquier nodo, sin esperar al siguiente bloque.

¿Cómo interactúa con otras partes de la hoja de ruta?

Resolver el problema sin estado aumenta mucho la dificultad del staking individual. Si hay tecnología que reduce el saldo mínimo para el staking individual, como Orbit SSF o estrategias a nivel de aplicación como staking en escuadrones, esto será más factible.

Si se introduce EOF al mismo tiempo, el análisis de gas multidimensional será más fácil. Esto se debe a que la principal complejidad de ejecución del gas multidimensional proviene de manejar llamadas hijas que no transmiten todo el gas del padre, y EOF simplemente hace que tales llamadas sean ilegales, lo que trivializa el problema (y la abstracción de cuentas nativa proporcionará una alternativa interna para los casos de uso actuales de gas parcial).

La verificación sin estado y la expiración histórica tienen una sinergia importante. Hoy, los clientes deben almacenar casi 1TB de datos históricos; estos datos son varias veces el tamaño de los datos de estado. Incluso si el cliente es sin estado, a menos que podamos liberar al cliente de almacenar datos históricos, el sueño de un cliente casi sin almacenamiento no se logrará. El primer paso en esta dirección es EIP-4444, que también significa almacenar datos históricos en torrents o en la Portal Network.

Prueba de validez de la ejecución de la EVM

¿Qué problema queremos resolver?

El objetivo a largo plazo de la verificación de bloques de Ethereum es claro: debería ser posible verificar un bloque de Ethereum mediante: (i) descargar el bloque, o incluso solo una pequeña parte del muestreo de disponibilidad de datos del bloque; (ii) verificar una pequeña prueba de validez del bloque. Esto sería una operación de muy bajo consumo de recursos, posible en clientes móviles, billeteras de navegador e incluso en otra cadena (sin la parte de disponibilidad de datos).

Para lograr esto, se necesitan pruebas SNARK o STARK tanto para (i) la capa de consenso (es decir, prueba de participación) como para (ii) la capa de ejecución (es decir, la EVM). La primera es un desafío en sí misma y debe abordarse a medida que se mejora la capa de consenso (por ejemplo, hacia la finalidad de slot único). La segunda requiere pruebas de ejecución de la EVM.

¿Qué es y cómo funciona?

Formalmente, en la especificación de Ethereum, la EVM se define como una función de transición de estado: tienes un estado previo S, un bloque B, y calculas un estado posterior S' = STF(S, B). Si el usuario usa un cliente ligero, no tiene S y S' completos, ni siquiera E; en cambio, tiene una raíz de estado previa R, una raíz de estado posterior R' y un hash de bloque H.

• Entrada pública: raíz de estado previa R, raíz de estado posterior R', hash de bloque H
• Entrada privada: cuerpo del bloque B, objetos en el estado accedidos por el bloque Q, los mismos objetos después de ejecutar Q', pruebas de estado (como ramas Merkle) P
• Reclamo 1: P es una prueba válida de que Q contiene ciertas partes del estado representado por R
• Reclamo 2: Si se ejecuta STF en Q, (i) el proceso solo accede a objetos internos de Q, (ii) el bloque es válido, (iii) el resultado es Q'
• Reclamo 3: Si se recalcula la nueva raíz de estado usando la información de Q' y P, se obtiene R'

Si esto existe, se puede tener un cliente ligero que verifique completamente la ejecución de la EVM de Ethereum. Esto hace que los recursos del cliente sean muy bajos. Para lograr un cliente de Ethereum completamente verificado, también se debe hacer lo mismo para el consenso.

Las pruebas de validez para el cálculo de la EVM ya existen y son ampliamente usadas en L2. Pero para que sean viables en L1, aún queda mucho trabajo por hacer.

¿Qué relación tiene con la investigación existente?

• EFPSE ZK-EVM (descontinuado por mejores opciones)
• Zeth, que compila la EVM en RISC-0 ZK-VM
• Proyecto de verificación formal de ZK-EVM

¿Qué más se puede hacer?

Hoy, las pruebas de validez de los sistemas de contabilidad electrónica son insuficientes en dos aspectos: seguridad y tiempo de verificación.

Una prueba de validez segura debe garantizar que el SNARK realmente verifica el cálculo de la EVM y que no hay vulnerabilidades. Las dos principales técnicas para mejorar la seguridad son los múltiples validadores y la verificación formal. Múltiples validadores significa tener varias implementaciones independientes de la prueba de validez, como tener varios clientes, y si un bloque es probado por un subconjunto suficientemente grande de estas implementaciones, el cliente acepta el bloque. La verificación formal implica usar herramientas normalmente usadas para probar teoremas matemáticos, como Lean4, para demostrar que la prueba de validez solo acepta ejecuciones correctas de la especificación subyacente de la EVM (por ejemplo, la semántica K de la EVM o la especificación EELS escrita en python).

Un tiempo de verificación suficientemente rápido significa que cualquier bloque de Ethereum puede ser verificado en menos de 4 segundos. Hoy estamos lejos de ese objetivo, aunque estamos más cerca de lo que imaginábamos hace dos años. Para lograrlo, debemos avanzar en tres direcciones:

• Paralelización: el verificador de EVM más rápido actualmente puede probar un bloque de Ethereum en promedio en 15 segundos. Esto se logra paralelizando entre cientos de GPU y luego agregando su trabajo. Teóricamente, sabemos cómo hacer un verificador de EVM que pruebe el cálculo en O(log(N)) tiempo: hacer que una GPU haga cada paso y luego hacer un "árbol de agregación":

Implementar esto tiene desafíos. Incluso en el peor caso, es decir, una transacción muy grande que ocupa todo el bloque, la división del cálculo no puede hacerse por transacción, sino por opcode (de la EVM o la máquina virtual subyacente como RISC-V). Asegurar que la "memoria" de la máquina virtual se mantenga coherente entre las diferentes partes de la prueba es un desafío clave en la implementación. Pero si logramos esta prueba recursiva, sabemos que, incluso sin otras mejoras, al menos el problema de latencia del verificador está resuelto.

• Optimización del sistema de pruebas: nuevos sistemas de prueba como Orion, Binius, GRK y otros probablemente reducirán aún más el tiempo de verificación de cálculos generales.
• Otros cambios en el costo de gas de la EVM: muchas cosas en la EVM pueden optimizarse para favorecer a los verificadores, especialmente en el peor caso. Si un atacante puede construir un bloque que bloquee al verificador durante diez minutos, no basta con poder probar un bloque normal de Ethereum en 4 segundos. Los cambios necesarios en la EVM pueden clasificarse así:
• Cambios en el costo de gas: si una operación tarda mucho en ser probada, aunque sea relativamente rápida de calcular, debería tener un alto costo de gas. EIP-7667 aborda los problemas más graves aquí: aumenta mucho el costo de gas de las funciones hash (opcode y precompiladas), que son relativamente baratas. Para compensar, podemos reducir el costo de gas de los opcodes de la EVM que son baratos de probar, manteniendo el rendimiento promedio.
• Reemplazo de estructuras de datos: además de reemplazar el árbol de estado por uno más amigable para STARK, también debemos reemplazar la lista de transacciones, el árbol de recibos y otras estructuras costosas de probar. El EIP de Etan Kissling que mueve transacciones y recibos a SSZ es un paso en esa dirección.

Además, las dos herramientas mencionadas en la sección anterior (gas multidimensional y raíz de estado retrasada) también pueden ayudar aquí. Pero, a diferencia de la verificación sin estado, usar estas dos herramientas significa que ya tenemos suficiente tecnología para lo que necesitamos ahora, aunque incluso con ellas, la verificación completa de ZK-EVM requiere más trabajo, solo que menos.

Un punto no mencionado arriba es el hardware del verificador: usar GPU, FPGA y ASIC para generar pruebas más rápido. Fabric Cryptography, Cysic y Accseal son tres empresas que han avanzado en esto. Esto es muy valioso para L2, pero probablemente no sea decisivo para L1, porque se espera que L1 permanezca altamente descentralizado, lo que significa que la generación de pruebas debe estar al alcance razonable de los usuarios de Ethereum y no depender del hardware de una sola empresa. L2 puede hacer compromisos más agresivos.

En estos campos, aún queda mucho por hacer:

• La paralelización de pruebas requiere que diferentes partes del sistema de pruebas puedan "compartir memoria" (como tablas de búsqueda). Sabemos cómo hacerlo, pero hay que implementarlo.
• Necesitamos más análisis para encontrar el conjunto ideal de cambios en el costo de gas que minimicen el tiempo de verificación en el peor caso.
• Necesitamos más trabajo en los sistemas de pruebas

Los posibles costos son:

• Seguridad vs. tiempo del verificador: elegir funciones hash más agresivas, sistemas de prueba más complejos o suposiciones de seguridad más agresivas u otros diseños puede reducir el tiempo del verificador.
• Descentralización vs. tiempo del verificador: la comunidad debe acordar las "especificaciones" del hardware del verificador objetivo. ¿Está bien que los verificadores sean entidades grandes? ¿Queremos que una laptop de consumo de alta gama pueda probar un bloque de Ethereum en 4 segundos? ¿Algo intermedio?
• Grado de ruptura de la compatibilidad hacia atrás: otras deficiencias pueden compensarse con cambios más agresivos en el costo de gas, pero esto probablemente aumente desproporcionadamente el costo de ciertas aplicaciones, obligando a los desarrolladores a reescribir y volver a implementar el código para mantener la viabilidad económica. Estas dos herramientas también tienen su propia complejidad y desventajas.

¿Cómo interactúa con otras partes de la hoja de ruta?

La tecnología central necesaria para la prueba de validez de la EVM en L1 se comparte en gran medida con otros dos campos:

• Prueba de validez en L2 (es decir, "ZK rollup")
• Método sin estado de "prueba hash binaria STARK"

Si se logra la prueba de validez en L1, finalmente se podrá hacer staking individual fácilmente: incluso las computadoras más débiles (incluyendo teléfonos o smartwatches) podrán hacer staking. Esto aumenta aún más el valor de resolver otras restricciones del staking individual (como el mínimo de 32ETH).

Además, la prueba de validez de la EVM en L1 puede aumentar mucho el límite de gas de L1.

Prueba de validez del consenso

¿Qué problema queremos resolver?

Si queremos verificar completamente un bloque de Ethereum con SNARK, la ejecución de la EVM no es la única parte que debemos probar. También debemos probar el consenso, es decir, la parte del sistema que maneja depósitos, retiros, firmas, actualizaciones de saldo de validadores y otros elementos de la prueba de participación de Ethereum.

El consenso es mucho más simple que la EVM, pero enfrenta el desafío de que no tenemos convolución EVM en L2, por lo que de todos modos, la mayor parte del trabajo debe hacerse. Por lo tanto, cualquier implementación de prueba del consenso de Ethereum debe hacerse "desde cero", aunque el sistema de pruebas en sí puede construirse sobre trabajo compartido.

¿Qué es y cómo funciona?

La Beacon Chain se define como una función de transición de estado, igual que la EVM. La función de transición de estado consta principalmente de tres partes:

• ECADD (para verificar firmas BLS)
• Emparejamiento (para verificar firmas BLS)
• Hash SHA256 (para leer y actualizar el estado)

En cada bloque, debemos probar 1-16 ECADD BLS12-381 por validador (puede ser más de uno, ya que una firma puede estar en varios conjuntos). Esto puede mitigarse con técnicas de pre-cálculo de subconjuntos, así que podemos decir que cada validador solo necesita una ECADD BLS12-381. Actualmente, hay 30000 firmas de validadores por slot. En el futuro, con la finalidad de slot único, esto podría cambiar en dos direcciones: si tomamos la ruta "fuerza bruta", el número de validadores por slot podría aumentar a 1 millón. Al mismo tiempo, si usamos Orbit SSF, el número de validadores se mantendrá en 32768 o incluso bajará a 8192.

Cómo funciona la agregación BLS: verificar la firma total solo requiere una ECADD por participante, no una ECMUL. Pero 30000 ECADD sigue siendo mucho para probar.

En cuanto a los emparejamientos, actualmente hay hasta 128 pruebas por slot, lo que significa verificar 128 emparejamientos. Con EIP-7549 y más cambios, esto puede reducirse a 16 por slot. Los emparejamientos son pocos, pero muy costosos: cada uno tarda miles de veces más que una ECADD.

Un gran desafío para probar operaciones BLS12-381 es que no hay una curva conveniente con el mismo orden que el campo de BLS12-381, lo que añade mucha sobrecarga a cualquier sistema de pruebas. Por otro lado, el árbol Verkle propuesto para Ethereum se construye con la curva Bandersnatch, lo que hace que BLS12-381 sea la curva nativa en el sistema SNARK para probar ramas Verkle. Una implementación simple puede probar 100 sumas G1 por segundo; para que la prueba sea lo suficientemente rápida, casi seguro se necesitarán técnicas inteligentes como GKR.

Para los hashes SHA256, el peor caso actual es el bloque de cambio de época, donde todo el árbol de balances cortos de validadores y muchos balances de validadores se actualizan. El árbol de balances cortos de cada validador tiene solo un byte, así que hay 1 MB de datos a re-hashear. Esto equivale a 32768 llamadas SHA256. Si mil validadores cruzan un umbral, se deben actualizar los balances efectivos en los registros de validadores, lo que equivale a mil ramas Merkle, es decir, unas diez mil llamadas hash. El mecanismo de barajado requiere 90 bits por validador (11 MB de datos), pero esto puede calcularse en cualquier momento de la época. Con finalidad de slot único, estos números pueden variar. El barajado puede dejar de ser necesario, aunque Orbit podría restaurar esa necesidad en cierta medida.

Otro desafío es que se debe recuperar todo el estado de los validadores, incluidas las claves públicas, para verificar un bloque. Para 1 millón de validadores, solo leer las claves públicas requiere 48 millones de bytes, más las ramas Merkle. Esto requiere millones de hashes por época. Si debemos probar la validez de PoS, una forma realista es algún tipo de cálculo incremental verificable: almacenar en el sistema de pruebas una estructura de datos optimizada para búsquedas eficientes y probar las actualizaciones de esa estructura.

En resumen, los desafíos son muchos. Para enfrentarlos de la manera más eficiente, probablemente se requiera un rediseño profundo de la Beacon Chain, que podría coincidir con el cambio a finalidad de slot único. Este rediseño podría incluir:

• Cambio de función hash: ahora se usa SHA256 "completo", por lo que cada llamada implica dos llamadas a la función de compresión subyacente por el padding. Si se usa solo la función de compresión SHA256, al menos se duplica la eficiencia. Si se usa Poseidon, se podría mejorar 100 veces, resolviendo todos los problemas de hashes (al menos): a 1.7 millones de hashes por segundo (54MB), incluso 1 millón de registros de validadores pueden "leerse" en la prueba en segundos.
• Si es Orbit, almacenar directamente los registros de validadores barajados: si se elige un número fijo de validadores (como 8192 o 32768) como comité para un slot, se colocan juntos en el estado, lo que permite leer todas las claves públicas con un mínimo de hashes. Esto también permite actualizar balances eficientemente.
• Agregación de firmas: cualquier esquema de agregación de firmas de alto rendimiento implicará pruebas recursivas, donde diferentes nodos de la red prueban subconjuntos de firmas. Esto distribuye el trabajo de prueba entre varios nodos, reduciendo mucho la carga del "verificador final".
• Otros esquemas de firmas: para firmas Lamport+Merkle, se necesitan 256 + 32 hashes para verificar una firma; multiplicado por 32768 firmantes, da 9437184 hashes. Optimizar el esquema de firmas puede mejorar aún más este resultado por un pequeño factor constante. Si usamos Poseidon, esto puede probarse en un solo slot. Pero en la práctica, usar esquemas de agregación recursiva será más rápido.

¿Qué relación tiene con la investigación existente?

• Pruebas concisas de consenso de Ethereum (solo para el comité de sincronización)
• Helios en SP1 conciso
• Precompilado BLS12-381 conciso
• Verificación de firmas agregadas BLS basada en Halo2

¿Qué más queda por hacer y cómo se decide?

De hecho, necesitaremos varios años para obtener una prueba de validez del consenso de Ethereum. Esto coincide aproximadamente con el tiempo necesario para lograr finalidad de slot único, Orbit, cambiar el algoritmo de firmas y el análisis de seguridad necesario para confiar en funciones hash "agresivas" como Poseidon. Por lo tanto, lo más sensato es resolver estos otros problemas y, al hacerlo, tener en cuenta la amigabilidad con STARK.

La principal decisión probablemente será sobre el orden de las operaciones, entre un enfoque más gradual para reformar la capa de consenso de Ethereum y un enfoque más agresivo de "cambiar muchas cosas a la vez". Para la EVM, el enfoque gradual es razonable porque minimiza la interrupción de la compatibilidad hacia atrás. Para la capa de consenso, el impacto en la compatibilidad hacia atrás es menor, y repensar más "integralmente" los detalles de la Beacon Chain para optimizar la amigabilidad con SNARK puede ser beneficioso.

¿Cómo interactúa con otras partes de la hoja de ruta?

Al rediseñar a largo plazo el PoS de Ethereum, la amigabilidad con STARK debe ser una prioridad, especialmente para la finalidad de slot único, Orbit, cambios en el esquema de firmas y agregación de firmas.