Autor: Vitalik, fundador de Ethereum; Compilador: Deng Tong, Golden Finance

Nota: Este artículo es la cuarta parte de la serie 'Desarrollo futuro del protocolo Ethereum' publicado recientemente por Vitalik, fundador de Ethereum, titulado 'Futuros posibles del protocolo Ethereum, parte 4: The Verge'. La tercera parte se puede ver en 'Vitalik: Objetivos clave de la fase The Scourge de Ethereum', la segunda parte en 'Vitalik: Cómo debería desarrollarse el protocolo Ethereum en la fase The Surge', y la primera parte en '¿Qué mejoras se pueden hacer en Ethereum PoS?'. A continuación se presenta el texto completo de la cuarta parte:

Un agradecimiento especial a Justin Drake, Hsiao-wei Wang, Guillaume Ballet, Ignacio, Josh Rudolf, Lev Soukhanov, Ryan Sean Adams y Uma Roy por sus comentarios y revisiones.

Una de las características más poderosas de la blockchain es que cualquiera puede ejecutar un nodo en su computadora y verificar que la cadena es correcta. Incluso si el 95% de los nodos que ejecutan el consenso en la cadena (PoW, PoS...) acuerdan de inmediato cambiar las reglas y comienzan a producir bloques bajo las nuevas reglas, cualquier persona que ejecute un nodo completamente verificado se negará a aceptar esa cadena. Los interesados que no pertenecen a tal grupo se agruparán automáticamente y seguirán construyendo una cadena que continúe siguiendo las viejas reglas, y los usuarios completamente verificados seguirán esa cadena.

Esta es la diferencia clave entre blockchain y sistemas centralizados. Sin embargo, para mantener esta característica, operar nodos completamente verificados debe ser factible para un número crítico de personas. Esto se aplica tanto a los participantes (como si los participantes no verifican la cadena, en realidad no están contribuyendo a la ejecución de las reglas del protocolo) como a los usuarios comunes. Hoy en día, se pueden ejecutar nodos en computadoras portátiles de consumo (incluida la computadora utilizada para escribir esto), pero hacerlo es complicado. The Verge busca cambiar esto, haciendo que el costo computacional de una cadena completamente verificada sea tan bajo que cada billetera móvil, billetera de navegador e incluso reloj inteligente lo hagan por defecto.

The Verge, hoja de ruta 2023.

Originalmente, 'Verge' se refería a la idea de trasladar el almacenamiento de estado de Ethereum al árbol Verkle: esta estructura de árbol permite pruebas más compactas, lo que lleva a la verificación sin estado de los bloques de Ethereum. Los nodos pueden verificar bloques de Ethereum sin tener ningún estado de Ethereum (saldos de cuentas, código de contratos, almacenamiento...) en su disco duro, pero a costa de gastar cientos de kilobytes de datos de prueba y cientos de milisegundos de tiempo adicional para verificar la prueba. Hoy en día, Verge representa una visión más grande, centrada en lograr la validación de la cadena de Ethereum con la máxima eficiencia de recursos, que no solo incluye técnicas de verificación sin estado, sino también el uso de SNARK para verificar toda la ejecución de Ethereum.

Además de centrarse a largo plazo en la verificación SNARK de toda la cadena, otra nueva cuestión es si el árbol Verkle es la mejor tecnología. Los árboles Verkle son fácilmente atacables por computadoras cuánticas, por lo que si sustituimos los árboles Merkle Patricia KECCAK actuales por árboles Verkle, tendríamos que reemplazar esos árboles nuevamente más adelante. La alternativa natural a los árboles Merkle es saltar directamente a usar ramas Merkle STARK en un árbol binario. Históricamente, esto se ha considerado inviable debido al sobrecosto y la complejidad técnica. Sin embargo, recientemente hemos visto a Starkware probar 1.7 millones de hashes Poseidon por segundo en una computadora portátil con Circle STARK, y gracias a tecnologías como GKR, el tiempo de prueba de más 'tradicionales' hashes también se está reduciendo rápidamente.

Por lo tanto, en el último año, Verge se ha vuelto más abierto y hay múltiples posibilidades.

The Verge: objetivos clave

  • Cliente sin estado: un cliente completamente verificado y un nodo de participación no necesitan más de unos pocos GB de espacio de almacenamiento.

  • (A largo plazo) validar completamente la cadena en un reloj inteligente (consenso y ejecución). Descargar algunos datos, validar SNARK y listo.

En este artículo, nos enfocamos en lo siguiente:

  • Verificación sin estado: Verkle o STARKs

  • Prueba de validez de la ejecución de EVM

  • Prueba de validez del consenso

Verificación sin estado: Verkle o STARKs

¿Qué problema estamos tratando de resolver?

Hoy en día, los clientes de Ethereum necesitan almacenar cientos de GB de datos de estado para validar bloques, y esta cantidad sigue aumentando cada año. Los datos de estado originales aumentan aproximadamente 30 GB al año, y cada cliente individual también debe almacenar datos adicionales, además de poder actualizar el trie de manera efectiva.

Esto reduce la cantidad de usuarios que pueden ejecutar nodos completamente verificados de Ethereum: aunque los discos duros son lo suficientemente grandes como para almacenar todo el estado de Ethereum e incluso años de historial, las computadoras que la gente tiende a comprar por defecto a menudo solo tienen unos pocos cientos de gigabytes de espacio de almacenamiento. El tamaño del estado también complica el proceso de configuración inicial de nodos: los nodos necesitan descargar todo el estado, lo que puede llevar horas o días. Esto tiene una serie de repercusiones. Por ejemplo, dificulta que los participantes actualicen su configuración de participación. Técnicamente, esto podría hacerse sin interrupción: iniciar un nuevo cliente, esperar que se sincronice y luego apagar el antiguo cliente y transferir la clave, pero en la práctica, esto es técnicamente complicado.

¿Qué es y cómo funciona?

La verificación sin estado es una técnica que permite a los nodos validar bloques sin poseer el estado completo. En cambio, cada bloque viene con un testigo que incluye (i) los valores en posiciones específicas del estado que el bloque accederá (por ejemplo, código, saldo, almacenamiento) y (ii) una prueba criptográfica de que esos valores son correctos.

La implementación real de la verificación sin estado requiere cambiar la estructura del árbol de estado de Ethereum. Esto se debe a que el árbol Merkle Patricia actual es extremadamente poco amigable para implementar cualquier esquema de prueba criptográfica, especialmente en el peor de los casos. Tanto el 'ramal' Merkle como la posibilidad de 'envolver' las ramas de Merkle en STARK son así. La principal dificultad proviene de las dos debilidades de MPT:

  • Es un árbol de seis vías (es decir, cada nodo tiene 16 hijos). Esto significa que, en promedio, la prueba en un árbol de tamaño N tiene 32*(16-1)*log16(N) = 120*log2(N) bytes, o alrededor de 3840 bytes en un árbol con 2^32 elementos. Para un árbol binario, solo se necesitarían 32*(2-1)*log2(N) = 32*log2(N) bytes, es decir, alrededor de 1024 bytes.

  • Este código no está merkelizado. Esto significa que cualquier acceso que proporcione código de cuenta deberá proporcionar el código completo, con una longitud máxima de 24000 bytes.

Podemos calcular el peor de los casos de la siguiente manera:

30,000,000 Gas / 2,400 ('costo de lectura de cuentas frías') * (5 * 480 + 24,000) = 330,000,000 bytes

El costo de las ramas ha disminuido ligeramente (5*480 en lugar de 8*480), ya que cuando hay muchas ramas, la parte superior de las ramas tiende a repetirse. Pero aun así, la cantidad de datos descargados en un slot es completamente poco realista. Si intentamos envolver esto en STARK, nos enfrentaríamos a dos problemas: (i) KECCAK es relativamente poco amigable con STARK, (ii) 330 MB de datos significa que tendríamos que probar 5 millones de llamadas a la función de ronda de KECCAK, lo cual es un camino que incluso si pudiéramos hacer que STARK probara KECCAK de manera más eficiente, hay muchas cosas que no se pueden probar en todo el hardware que no sea el más potente.

Si simplemente reemplazamos el árbol de seis vías por un árbol binario, más merkelizamos el código, entonces en el peor de los casos se volvería aproximadamente 30,000,000 / 2,400 * 32 * (32 - 14 + 8) = 10,400,000 bytes ~214 ramas de las que 8 son la longitud de prueba que entra en una hoja). Tenga en cuenta que esto requiere cambiar el costo de Gas para cobrar por acceder a cada bloque de código individual; EIP-4762 es así. 10.4 MB es mucho mejor, pero sigue siendo demasiados datos para descargar en un solo slot para muchos nodos. Así que necesitamos introducir algunas técnicas más poderosas. Para esto, hay dos soluciones principales: el árbol Verkle y el árbol de hash binario con STARK.

Árbol Verkle

El árbol Verkle utiliza compromisos vectoriales basados en curvas elípticas para hacer pruebas más cortas. La clave es que, sin importar cuán ancho sea el árbol, cada fragmento de prueba correspondiente a cada relación padre-hijo solo tiene 32 bytes. La única limitación del ancho del árbol es que, si el árbol es demasiado ancho, la eficiencia computacional de la prueba disminuye. La implementación sugerida para Ethereum tiene un ancho de 256.

Por lo tanto, el tamaño de una sola rama en la prueba se convierte en 32*log256(N) = 4*log2(N) bytes. El tamaño máximo teórico de la prueba se convierte en aproximadamente 30,000,000/2,400*32*(32-14+8)/8 = 1,300,000 bytes (debido a la distribución desigual de bloques de estado, los cálculos matemáticos difieren ligeramente en la práctica, pero esto sirve como una buena referencia inicial).

Como advertencia adicional, tenga en cuenta que en todos los ejemplos anteriores, esta 'peor situación' no es realmente la peor: la peor situación sería que un atacante deliberadamente 'minara' dos direcciones para tener un largo prefijo común en el árbol, y leer desde una de ellas podría extender la longitud de la rama en la peor situación aproximadamente 2 veces más. Pero incluso con tal advertencia, los árboles Verkle nos permiten obtener aproximadamente 2.6 MB de prueba en la peor situación, lo cual coincide aproximadamente con los datos de llamada en la peor situación hoy.

También aprovechamos esta advertencia para hacer otra cosa: hacemos que el acceso a la memoria 'adyacente' sea muy barato: muchos bloques de código del mismo contrato, o slots de almacenamiento adyacentes. EIP-4762 proporciona la definición de adyacencia, el acceso adyacente solo cobra 200 de Gas. Para el acceso adyacente, el tamaño de prueba en el peor de los casos se convierte en 30,000,000/200*32 = 4,800,800 bytes, que todavía está aproximadamente dentro del rango de tolerancia. Si deseamos reducir este valor por razones de seguridad, podemos aumentar ligeramente el costo de acceso adyacente.

Árbol de hash binario con estrella

La técnica aquí es muy no trivial: haces un árbol binario, tomas una prueba de max-10.4-MB de los valores que necesitas probar en un bloque, y reemplazas esa prueba con STARK. Esto nos lleva a descubrir que la prueba en sí solo incluye los datos que están siendo probados, más un sobrecosto fijo de aproximadamente 100-300 kB para la STARK real.

El principal desafío aquí es el tiempo de prueba. Podemos llevar a cabo cálculos muy similares a los anteriores, solo que en lugar de calcular bytes, calculamos hashes. Un bloque de 10.4 MB significa 330,000 hashes. Si agregamos la posibilidad de que un atacante 'miné' direcciones en el árbol que tengan un largo prefijo común, entonces el verdadero peor de los casos se convertirá en aproximadamente 660,000 hashes. Así que si podemos probar aproximadamente 200,000 hashes por segundo, no habría problema.

Estos números ya se han alcanzado en computadoras portátiles de consumo que tienen la función hash Poseidon, diseñada específicamente para ser amigable con STARK. Sin embargo, Poseidon es relativamente inmaduro, por lo que muchas personas aún no confían en su seguridad. Por lo tanto, hay dos caminos realistas hacia adelante:

  • Análisis de seguridad a gran escala de Poseidon y familiarizarse con él para desplegarlo en L1

  • Usar funciones hash más 'conservadoras', como SHA256 o BLAKE

Al momento de escribir esto, el probador STARK de Starkware puede probar aproximadamente 10-30k hashes por segundo en computadoras portátiles de consumo si se trata de una función hash conservadora. Sin embargo, la tecnología STARK avanza rápidamente. Incluso hoy, la tecnología basada en GKR muestra potencial para elevar esto a aproximadamente 100-200k.

Casos de uso de testigos más allá de la validación de bloques

Además de la validación de bloques, hay otros tres casos de uso clave que pueden lograr una verificación sin estado más eficiente:

  • Memoria pool: cuando se transmiten transacciones, los nodos en la red p2p necesitan verificar si las transacciones son válidas antes de retransmitir. Hoy en día, la verificación no solo incluye verificar la firma, sino también comprobar si el saldo es suficiente y si el nonce es correcto. En el futuro (por ejemplo, usando abstracción de cuentas nativas, como EIP-7701), esto podría implicar ejecutar algo de código EVM que realizaría algún acceso al estado. Si el nodo es sin estado, la transacción necesitaría ir acompañada de una prueba del objeto de estado.

  • Lista de inclusión: esta es una función propuesta que permite a los validadores de prueba de participación (posiblemente pequeños y no complejos) forzar que el siguiente bloque incluya una transacción, independientemente de la voluntad del constructor del bloque (que podría ser grande y complejo). Esto reduciría la capacidad de los participantes poderosos para manipular la blockchain mediante el retraso de transacciones. Sin embargo, esto requiere que los validadores tengan una manera de verificar la validez de las transacciones en la lista de inclusión.

  • Cliente ligero: si queremos que los usuarios accedan a la cadena a través de billeteras (como Metamask, Rainbow, Rabby...) sin confiar en participantes centralizados, necesitan ejecutar un cliente ligero (como Helios). El módulo central de Helios proporciona a los usuarios una raíz de estado verificada. Sin embargo, para tener una experiencia completamente sin confianza, los usuarios necesitan proporcionar pruebas para cada llamada RPC individual que realicen (por ejemplo, para una solicitud de eth_call, el usuario necesita una prueba de todo el estado al que accede durante la llamada);

Un punto en común de todos estos casos de uso es que requieren una cantidad considerable de pruebas, pero cada prueba es pequeña. Por lo tanto, las pruebas STARK no tienen sentido para ellos; en cambio, usar directamente ramas de Merkle es lo más realista. Otra ventaja de las ramas de Merkle es que son actualizables: dado un prueba de un objeto de estado X con raíz en el bloque B, si recibe un subtipo B2 con su testigo, puede actualizar esa prueba para que tenga raíz en el bloque B2. Las pruebas Verkle también son actualizables.

¿Qué conexiones existen con la investigación actual?

Árbol Verkle: https://vitalik.eth.limo/general/2021/06/18/verkle.html

Artículo original de John Kuszmaul sobre árboles Verkle: https://math.mit.edu/research/highschool/primes/materials/2018/Kuszmaul.pdf

Datos de prueba de Starkware: https://x.com/StarkWareLtd/status/1807776563188162562

Artículo de Poseidon2: https://eprint.iacr.org/2023/323

Ajtai (alternativa rápida basada en la dureza de la rejilla): https://www.wisdom.weizmann.ac.il/~oded/COL/cfh.pdf

Verkle.info: https://verkle.info/

¿Qué más se necesita hacer, y qué compensaciones hay que considerar?

El trabajo principal que queda por hacer es:

  • Más análisis de las consecuencias de EIP-4762 (cambio de costo de gas sin estado)

  • Más trabajo completado y probado en programas de transición, que es una gran parte de la complejidad de cualquier EIP sin estado

  • Más análisis de seguridad de funciones hash 'amigables con STARK' como Poseidon, Ajtai y otras

  • Desarrollo adicional de protocolos STARK ultr eficientes para funciones hash 'conservadoras' (o 'tradicionales'), como ideas basadas en Binius o GKR.

Pronto llegaremos a un punto de decisión sobre cuál de las siguientes tres opciones elegir: (i) árbol Verkle, (ii) funciones hash amigables con STARK, y (iii) funciones hash conservadoras. Sus atributos se pueden resumir aproximadamente en la siguiente tabla:

Además de estos 'números de encabezado', hay otras consideraciones importantes:

  • Hoy en día, el código del árbol Verkle ya es bastante maduro. Usar cualquier cosa que no sea Verkle retrasaría efectivamente el despliegue, probablemente a través de un hard fork. Esto puede no ser un problema, especialmente si necesitamos tiempo adicional para realizar análisis de funciones hash o implementar probadores, y si tenemos otras características importantes que quisiéramos incluir en Ethereum lo antes posible.

  • Actualizar la raíz de estado usando hashes es más rápido que usar un árbol Verkle. Esto significa que un enfoque basado en hashes puede reducir el tiempo de sincronización de nodos completos.

  • Los árboles Verkle tienen interesantes propiedades de actualización de testigos: los testigos de los árboles Verkle son actualizables. Esta propiedad es útil para las piscinas de memoria, listas de inclusión y otros casos de uso, y también podría ayudar a aumentar la eficiencia de implementación: si se actualiza un objeto de estado, puede actualizar el testigo del penúltimo nivel sin siquiera tener que leer el último nivel.

  • Los árboles Verkle son más difíciles de probar mediante SNARK. Si queremos reducir el tamaño de la prueba a unos pocos kilobytes, las pruebas Verkle presentan algunos desafíos. Esto se debe a que la verificación de las pruebas Verkle introduce una gran cantidad de operaciones de 256 bits, lo que exige que el sistema de prueba tenga un gran sobrecoste o que tenga una estructura interna personalizada que contenga la parte de 256 bits necesaria para las pruebas Verkle.

Si queremos que la actualizabilidad de los testigos de Verkle sea de una manera cuánticamente segura y razonablemente eficiente, otra posible vía es un árbol Merkle basado en una cuadrícula.

Si el sistema de prueba no es lo suficientemente eficiente en el peor de los casos, podemos utilizar otro 'conejo en la chistera' para compensar esta deficiencia, que es Gas multidimensional: restricciones de Gas separadas para (i) calldata, (ii) cálculo, (iii) acceso al estado y posiblemente otros recursos diferentes. El Gas multidimensional aumenta la complejidad, pero a cambio, restringe más estrictamente la relación entre el caso promedio y el peor caso. Para Gas multidimensional, el máximo teórico de ramas a probar podría reducirse de 30,000,000 / 2400 = 12,500 a 3000. Esto haría que BLAKE3 (apenas) sea suficiente incluso hoy, sin más mejoras en la prueba.

El Gas multidimensional permite que las limitaciones de recursos de los bloques se reproduzcan más de cerca a las limitaciones de recursos del hardware subyacente.

Otro 'conejo que apareció de la chistera' es la propuesta de diferir el cálculo de la raíz de estado hasta después del bloque. Esto nos daría exactamente 12 segundos para calcular la raíz de estado, lo que significa que incluso en el peor de los casos, un tiempo de prueba de solo aproximadamente 60,000 hashes/segundo sería suficiente, lo que nuevamente nos coloca en el rango justo de BLAKE3.

La desventaja de este enfoque es que aumentaría la latencia del cliente ligero por un período, aunque hay versiones más inteligentes de esta técnica que pueden reducir esa latencia a solo la latencia de generación de pruebas. Por ejemplo, siempre que cualquier nodo genere una prueba, esa prueba puede ser transmitida a través de la red, en lugar de esperar al siguiente bloque.

¿Cómo interactúa con otras partes del mapa?

Resolver el problema sin estado aumenta significativamente la conveniencia de la participación individual. Si se disponen de técnicas para reducir el saldo mínimo de participación individual (por ejemplo, Orbit SSF o estrategias de capa de aplicación (por ejemplo, participación en equipos)), esto se volverá más valioso.

Si se introduce EOF al mismo tiempo, Gas multidimensional se volverá más fácil. Esto se debe a que una de las complejidades clave del Gas multidimensional para la ejecución es manejar las llamadas secundarias que no trasladan el Gas completo de la llamada padre, mientras que EOF simplemente hará que tales llamadas secundarias sean ilegales (y la abstracción de cuentas nativas proporcionará un protocolo alternativo para los principales casos de uso de las llamadas secundarias de Gas en la actualidad).

Otra sinergia importante es la sinergia entre la verificación sin estado y la caducidad histórica. Hoy en día, los clientes deben almacenar casi un TB de datos históricos; esta cantidad es varias veces más grande que la de un país. Incluso si el cliente es sin nacionalidad, a menos que podamos aliviar la responsabilidad del cliente de almacenar la historia, el sueño de un cliente casi sin almacenamiento no puede cumplirse. El primer paso en este sentido es EIP-4444, lo que también implica almacenar datos históricos en redes torrent o Portal.

Prueba de validez de la ejecución de EVM

¿Qué problema estamos tratando de resolver?

El objetivo a largo plazo de la validación de bloques de Ethereum es claro: deberías poder validar bloques de Ethereum de la siguiente manera: (i) descargando el bloque, y quizás incluso solo una pequeña parte de él y muestreando la disponibilidad de datos, y (ii) validando una pequeña parte para probar que el bloque es válido. Esto sería una operación que consume muy pocos recursos, que podría realizarse en un cliente móvil, billetera de navegador o incluso (sin la parte de disponibilidad de datos) en otra cadena.

Para lograr esto, se necesita tener (i) una capa de consenso (es decir, prueba de participación) y (ii) una capa de ejecución (es decir, EVM) con pruebas SNARK o STARK. La primera por sí sola ya es un desafío y debe resolverse en el proceso de mejorar aún más la capa de consenso (por ejemplo, asegurando la finalización de un solo slot). La segunda requiere pruebas de la ejecución de EVM.

¿Qué es y cómo funciona?

Formalmente, en la especificación de Ethereum, EVM se define como una función de transición de estado: tienes un estado anterior S, un bloque B, y estás calculando un estado posterior S' = STF(S, B). Si el usuario está usando un cliente ligero, no tiene S y S', ni siquiera el bloque completo B; en su lugar, tiene una raíz de estado anterior R, una raíz de estado posterior R' y un hash de bloque H. La declaración completa que necesita ser probada es aproximadamente:

  • Entrada pública: raíz de estado anterior R, raíz de estado posterior R', hash de bloque H.

  • Entrada privada: objetos en el estado accesibles desde el bloque B y el bloque Q, el mismo objeto después de ejecutar el bloque Q', prueba de estado (por ejemplo, rama de Merkle) P.

  • Afirmación 1: P es una prueba válida de ciertas partes del estado representadas por Q que incluye R.

  • Afirmación 2: Si ejecuta STF en Q, (i) la ejecución solo accede a objetos dentro de Q, (ii) el bloque es válido, y (iii) el resultado es Q'.

  • Afirmación 3: Si recalcula la nueva raíz de estado usando la información de Q' y P, obtendrá R'.

Si existe, puedes tener un cliente ligero que valide completamente la ejecución de EVM de Ethereum. Esto reduce considerablemente los recursos necesarios para un cliente. Para tener un cliente completamente verificado de Ethereum, también necesitas hacer lo mismo para las partes de consenso.

La implementación de pruebas de validez de la ejecución de EVM ya existe y se utiliza ampliamente en L2. Sin embargo, para que las pruebas de validez de EVM sean aplicables a L1, queda mucho trabajo por hacer.

¿Qué conexiones existen con la investigación actual?

EC PSE ZK-EVM (ahora obsoleto, ya que hay mejores opciones): https://github.com/privacy-scaling-explorations/zkevm-Circuits

Zeth, que funciona compilando EVM en RISC-0 ZK-VM: https://github.com/risc0/zeth

Proyecto de verificación formal ZK-EVM: https://verified-zkevm.org/

¿Qué más se necesita hacer, y qué compensaciones hay que considerar?

Hoy en día, las pruebas de validez de EVM no son suficientes en dos aspectos: seguridad y tiempo de prueba.

La prueba de seguridad y efectividad debe garantizar que SNARK realmente verifica los cálculos de EVM y que no hay errores. Las dos principales técnicas para mejorar la seguridad son múltiples probadores y verificación formal. Múltiples probadores significa tener múltiples implementaciones de pruebas de validez escritas de forma independiente, como tener varios clientes, y si un subconjunto lo suficientemente grande de estas implementaciones prueba un bloque, se permite que el cliente acepte ese bloque. La verificación formal implica usar herramientas comúnmente utilizadas para probar teoremas matemáticos (como Lean4) para probar que las pruebas de validez solo aceptan entradas que corresponden a ejecuciones correctas de la especificación de EVM subyacente escrita en Python.

Un tiempo de prueba lo suficientemente rápido significa que cualquier bloque de Ethereum puede ser probado en menos de 4 segundos. Hoy en día, estamos lejos de este objetivo, aunque estamos mucho más cerca de lo que imaginábamos hace dos años. Para lograr este objetivo, necesitamos avanzar en tres frentes:

  • Paralelización: el probador EVM más rápido en la actualidad puede probar un bloque promedio de Ethereum en aproximadamente 15 segundos. Esto se logra paralelizando entre cientos de GPU y luego agregando su trabajo al final.

Implementar esto presenta desafíos. Incluso en el peor de los casos (es decir, transacciones muy grandes ocupando todo el bloque) funcionaría, la segmentación de los cálculos no puede hacerse por transacción; debe hacerse por cada código de operación (EVM o VM subyacente (como RISC-V)). Uno de los principales desafíos de implementación que hace que esto no sea trivial es asegurar que la 'memoria' de la VM sea consistente entre las diferentes partes de la prueba. Sin embargo, si podemos hacer esta prueba recursiva, sabemos que al menos se resuelve el problema del tiempo del probador, incluso si no hay mejoras en ningún otro eje.

  • Optimización del sistema de pruebas: nuevos sistemas de prueba como Orion, Binius, GKR, etc. podrían reducir drásticamente el tiempo de prueba para cálculos generales nuevamente.

  • El consumo de Gas de EVM tiene otros cambios: muchas cosas en EVM se pueden optimizar para que sean más amigables para los probadores, especialmente en el peor de los casos. Si un atacante puede construir un bloque que tome diez minutos al probador, simplemente probar un bloque promedio de Ethereum en 4 segundos no será suficiente. Los cambios en EVM requeridos se pueden dividir principalmente en dos categorías:

  • Cambio en el costo de Gas: si una operación tarda mucho en probarse, entonces debería tener un costo de Gas alto, incluso si la velocidad de cálculo es relativamente rápida. EIP-7667 es una propuesta de EIP destinada a abordar el problema más serio en este sentido: aumenta significativamente el costo de Gas de funciones hash (tradicionales) que se publican como códigos de operación relativamente baratos y precompilados. Para compensar este aumento en los costos de Gas, podemos reducir el costo de Gas para los códigos de operación de EVM que son relativamente baratos de probar, manteniendo así el mismo rendimiento promedio.

  • Reemplazo de estructuras de datos: además de reemplazar el árbol de estado con alternativas más adecuadas para STARK, también necesitamos reemplazar listas de transacciones, árboles de recibos y otras estructuras que son costosas de probar. La EIP de Ethan Kissling mueve las estructuras de transacciones y recibos a SSZ ([1] [2] [3]), lo cual es un paso en esta dirección.

Además, los dos 'conejos de la chistera' mencionados en la sección anterior (Gas multidimensional y raíz de estado diferida) también pueden ayudar aquí. Sin embargo, vale la pena notar que, a diferencia de la verificación sin estado, la verificación sin estado significa que tenemos suficiente tecnología para hacer lo que necesitamos hoy en día; incluso usando estas tecnologías, la verificación completa de ZK-EVM aún requerirá más trabajo: simplemente se necesitará menos trabajo.

Una cosa que no se mencionó anteriormente es el hardware de prueba: generar pruebas más rápido usando GPU, FPGA y ASIC. Fabric Cryptography, Cysic y Accseal son los precursores de estas tres empresas. Esto es muy valioso para la capa 2, pero es poco probable que se convierta en un factor decisivo para la capa 1, ya que hay un fuerte deseo de mantener la capa 1 altamente descentralizada, lo que significa que la generación de pruebas debe estar dentro del rango de capacidad de un subconjunto considerable de usuarios de Ethereum, y no debe verse limitada por el hardware de una sola empresa. La capa 2 puede hacer compromisos más radicales.

Hay más trabajo por hacer en estos campos:

  • Las pruebas paralelas requieren sistemas de prueba donde diferentes partes de la prueba pueden 'compartir memoria' (por ejemplo, tablas de búsqueda). Sabemos cómo hacer esto técnicamente, pero requiere implementación.

  • Necesitamos más análisis para encontrar el conjunto ideal de cambios de costo de Gas para minimizar el tiempo de prueba en el peor de los casos.

  • Necesitamos hacer más trabajo en los sistemas de prueba

Las compensaciones posibles aquí incluyen:

  • Seguridad y tiempo del probador: la elección positiva de funciones hash, sistemas de prueba con mayor complejidad o hipótesis de seguridad más agresivas, o cualquier otra elección de diseño, puede reducir el tiempo del probador.

  • Descentralización y tiempo del probador: la comunidad debe acordar la 'especificación' del hardware del probador que desea. ¿Es aceptable que el probador sea una entidad a gran escala? ¿Queremos que las computadoras portátiles de consumo de gama alta puedan probar un bloque de Ethereum en 4 segundos? ¿Algo entre ambos?

  • El grado de ruptura de la compatibilidad hacia atrás: las deficiencias en otros campos podrían compensarse con cambios más agresivos en el costo de gas, pero esto es más probable que aumente desproporcionadamente el costo de ciertas aplicaciones y obligue a los desarrolladores a reescribir y redeplegar el código para mantener la viabilidad económica. Asimismo, los 'conejos de la chistera' tienen sus propias complejidades y desventajas.

¿Cómo interactúa con otras partes del mapa?

Las tecnologías centrales necesarias para implementar pruebas de validez de EVM en la capa 1 se comparten en gran medida con los otros dos campos:

  • Pruebas de validez en la capa 2 (es decir, 'ZK rollups')

  • Método sin estado de 'prueba de hash binario STARK'

La implementación exitosa de pruebas de validez en la capa 1 puede permitir una fácil participación individual final: incluso las computadoras más débiles (incluyendo teléfonos móviles o relojes inteligentes) podrán participar. Esto aumenta aún más el valor de resolver otras limitaciones de la participación individual (como el mínimo de 32 ETH).

Además, la prueba de validez de EVM en L1 puede mejorar significativamente el límite de Gas de L1.

Prueba de validez del consenso

¿Qué problema estamos tratando de resolver?

Si queremos ser capaces de validar bloques de Ethereum completamente con SNARK, entonces la ejecución de EVM no es la única parte que necesitamos probar. También necesitamos probar el consenso: la parte del sistema que maneja depósitos, retiros, firmas, actualizaciones de saldo de validadores y otros elementos de la parte de prueba de participación de Ethereum.

El consenso es mucho más simple que EVM, pero el desafío que enfrenta es que no tenemos un EVM de capa 2 que agregue, que es también la razón por la que se necesita hacer la mayor parte del trabajo de todos modos. Así que cualquier implementación que pruebe el consenso de Ethereum necesita hacerse 'desde cero', aunque el sistema de prueba en sí puede construirse sobre el trabajo compartido que está por venir.

¿Qué es y cómo funciona?

La cadena de beacon se define como una función de transición de estado, igual que EVM. La función de transición de estado se determina por tres factores:

  • ECADD (para verificar firmas BLS)

  • Paring (para verificar firmas BLS)

  • SHA256 hash (para leer y actualizar el estado)

En cada bloque, necesitamos probar de 1 a 16 ECADD de BLS12-381 (posiblemente más de uno, ya que las firmas pueden incluirse en múltiples agregados). Esto puede compensarse mediante técnicas de precomputación de subconjuntos, de modo que podamos decir que cada validador es un ECADD de BLS12-381. Hoy en día, hay alrededor de 30,000 validadores firmando cada época. En el futuro, para la finalización de un solo slot, esto podría cambiar en cualquier dirección (consulte la explicación aquí): si tomamos el enfoque 'agresivo', cada slot podría aumentar a un millón de validadores. Mientras tanto, usando Orbit SSF, se mantendría en 32,768, incluso podría reducirse a 8,1.

Cómo funciona la agregación BLS. Verificar firmas agregadas solo requiere ECADD de cada participante, en lugar de ECMUL. Pero 30,000 ECADD todavía son muchas pruebas.

Para los pares, actualmente hay un máximo de 128 pruebas por slot, lo que significa que se deben validar 128 pares. A través de EIP-7549 y cambios adicionales, esto podría reducirse a 16 por slot. Aunque la cantidad de pares es pequeña, el costo es extremadamente alto: el tiempo de ejecución (o prueba) de cada par es miles de veces más largo que ECADD.

Un desafío principal para probar operaciones BLS12-381 es la falta de curvas convenientes cuyo orden de curva sea igual al tamaño del campo BLS12-381, lo que agrega un costo considerable a cualquier sistema de prueba. Por otro lado, el árbol Verkle propuesto para Ethereum está construido con la curva Bandersnatch, lo que hace que BLS12-381 en sí mismo sea la curva natural utilizada en el sistema SNARK para probar ramas Verkle. Una implementación bastante simple puede proporcionar alrededor de 100 G1 additions por segundo; seguramente se necesitarán técnicas inteligentes como GKR para probar lo suficientemente rápido.

Para SHA256, el peor de los casos actualmente es un bloque de transición de época, donde se actualizan el árbol de saldos cortos de validadores y muchos saldos de validadores. El árbol de saldos cortos de validadores tiene solo un byte por validador, así que aproximadamente 1 MB de datos se volverían a hashear. Esto equivale a 32,768 llamadas a SHA256. Si el saldo de mil validadores está por encima o por debajo de un umbral, entonces es necesario actualizar el saldo efectivo en el registro de validadores, lo que corresponde a mil ramas de Merkle, por lo que puede haber otros diez mil hashes. El mecanismo de barajado requiere 90 bits por validador (por lo que se necesitan 11 MB de datos), pero esto se puede calcular en cualquier momento durante el proceso de una época. Para la finalización de un solo slot, estos números pueden aumentar o disminuir nuevamente dependiendo de los detalles. El barajado se vuelve innecesario, aunque la órbita puede recuperar algo de la necesidad de barajar.

Otro desafío es la necesidad de leer el estado de todos los validadores (incluidas las claves públicas) para validar un bloque. Para un millón de validadores, junto con la rama de Merkle, solo leer las claves públicas requiere 48 millones de bytes. Esto requiere millones de hashes por periodo. Si hoy tuviéramos que probar la verificación de prueba de participación, un enfoque realista sería alguna forma de cálculo verificable incremental: almacenar una estructura de datos independiente en el sistema de prueba que esté optimizada para búsquedas eficientes y proporcionar actualizaciones a esa estructura.

En resumen, hay muchos desafíos.

Para abordar estos desafíos de la manera más efectiva, probablemente será necesario un rediseño profundo de la cadena de beacon, que podría ocurrir simultáneamente con el cambio a la finalización de un solo slot. Las características de este rediseño podrían incluir:

  • Cambio de función hash: hoy en día, se usa la función hash 'completa' SHA256, por lo que, debido al relleno, cada llamada corresponde a dos llamadas a la función de compresión subyacente. Al menos, podemos obtener un aumento de 2 al cambiar a la función de compresión SHA256. Si cambiamos a Poseidon, podemos obtener un aumento de alrededor de 100 veces, lo que podría resolver todos nuestros problemas (al menos en lo que respecta a los hashes): 1.7 millones de hashes por segundo (54 MB), y hasta podríamos 'leer un millón de registros de validadores' y 'probarlo en unos pocos segundos'.

  • Si es Orbit, almacenar directamente los registros de validadores barajados: si eliges un número determinado de validadores (por ejemplo, 8,192 o 32,768) como el comité para un slot dado, colócalos directamente en estados adyacentes, de modo que la cantidad mínima de hashes sea la que necesita para leer todas las claves públicas de los validadores en la prueba. Esto también permitirá que todas las actualizaciones de saldo se realicen de manera eficiente.

  • Agregación de firmas: cualquier esquema de agregación de firmas de alto rendimiento implicará en realidad algún tipo de prueba recursiva, donde las pruebas intermedias de un subconjunto de firmas serán realizadas por varios nodos en la red. Esto dispersa naturalmente la carga de prueba entre muchos nodos en la red, lo que hace que la carga de trabajo del 'probador final' sea mucho menor.

  • Otros esquemas de firma: para la firma Lamport+Merkle, necesitamos 256+32 hashes para verificar la firma; multiplicado por 32,768 firmantes, eso da 9,437,184 hashes. La optimización de los esquemas de firma puede mejorar esto aún más con un pequeño factor constante. Si usamos Poseidon, esto está dentro del rango de lo que se puede probar en un solo slot. Pero en realidad, esto se volverá más rápido mediante soluciones de agregación recursiva.

¿Qué conexiones existen con la investigación actual?

Conciso, prueba de consenso de Ethereum (solo para el comité de sincronización): https://github.com/succinctlabs/eth-proof-of-consensus

Conciso, Helios en SP1: https://github.com/succinctlabs/sp1-helios

BLS12-381 precompilado conciso: https://blog.succinct.xyz/succinctshipsprecompiles/

Verificación de firmas agregadas BLS basada en Halo2: https://ethresear.ch/t/zkpos-with-halo2-pairing-for-verifying-aggregate-bls-signatures/14671

¿Qué más se necesita hacer, y qué compensaciones hay que considerar?

De hecho, necesitamos varios años para obtener una prueba de validez del consenso de Ethereum. Esto coincide aproximadamente con el cronograma necesario para implementar la finalización de un solo slot, las órbitas, los cambios en los algoritmos de firma y el análisis de seguridad potencial necesario para tener suficiente confianza para usar funciones hash 'radicales' como Poseidon. Por lo tanto, abordar estos otros problemas tiene más sentido y, al hacer este trabajo, es importante tener en cuenta la amigabilidad con STARK.

La principal compensación probablemente recaerá en 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 'realizar muchos cambios a la vez'. Para EVM, el enfoque incremental tiene sentido, ya que minimiza la ruptura de la compatibilidad hacia atrás. Para la capa de consenso, los problemas de compatibilidad hacia atrás son menores, y es beneficioso reconsiderar más 'completamente' varios detalles sobre cómo se construye la cadena de beacon para optimizar mejor la amigabilidad con SNARK.

¿Cómo interactúa con otras partes del mapa?

La amigabilidad STARK debe convertirse en un enfoque principal para el rediseño a largo plazo del consenso de prueba de participación de Ethereum, notablemente la finalización de un solo slot, Orbit, cambios en esquemas de firma y agregación de firmas.