Vitalik: El posible futuro del protocolo Ethereum: el borde

Autor: Vitalik, fundador de Ethereum;

Nota: Este artículo es la cuarta parte de la serie de artículos publicados recientemente por Vitalik, fundador de Ethereum.>Posibles futuros del Protocolo Ethereum, Parte 4: El borde«. Ver «Vitalik: Objetivos clave del Ethereum the Scourge Fase«, Vea la segunda parte»Vitalik: ¿Cómo debería desarrollarse el protocolo Ethereum en la etapa de sobretensión?«, Vea la primera parte»¿Qué más se puede mejorar en Ethereum POS?«.

---

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 potentes de Blockchain es que cualquiera puede ejecutar nodos en sus propias computadoras y verificar que la cadena sea correcta.Incluso si el 95% de los nodos que ejecutan consenso en la cadena (POW, POS …) inmediatamente acuerdan cambiar las reglas y comenzar a producir bloques de acuerdo con las nuevas reglas, todos los que ejecutan un nodo totalmente validado se negarán a aceptar la cadena.Las partes interesadas que no pertenecen a dichos grupos convergerán automáticamente y continuarán construyendo una cadena que continúe siguiendo las reglas antiguas, y los usuarios totalmente verificados seguirán la cadena.

Esta es la diferencia clave entre blockchain y sistemas centralizados.Sin embargo, para mantener esta característica, la ejecución de nodos totalmente validados debe ser realmente factible para un número crítico de personas.Esto se aplica a ambos Stakers (como si los Stakers no tuvieran una cadena de verificación, en realidad no contribuyen a la aplicación de las reglas de protocolo) y a los usuarios comunes.Hoy, los nodos se pueden ejecutar en computadoras portátiles de consumo, incluidas las que se usan para escribir este artículo, pero es difícil hacerlo.El borde tiene como objetivo cambiar esto, lo que hace que el costo informático de una cadena de verificación completa sea tan baja que cada billetera móvil, billetera del navegador e incluso el reloj inteligente lo haga de manera predeterminada.

The Verge, Hoja de ruta 2023.

Inicialmente, el «borde» se refiere a la idea de transferir el almacenamiento del estado de Ethereum a los árboles verkle, una estructura de árboles que permite pruebas más compactas que permiten la verificación sin estado de los bloques de Ethereum.Los nodos pueden verificar los bloques de Ethereum sin ningún estado de Ethereum (saldo de la cuenta, código de contrato, almacenamiento …) en su disco duro, pero a costa de gastar cientos de kilobytes de datos de prueba y cientos de milisegundos de tiempo extra para verificar la prueba.Hoy, Verge representa una visión más grande centrada en lograr la máxima verificación de eficiencia de recursos de la cadena Ethereum, que incluye no solo la tecnología de verificación sin estado, sino también validar todas las ejecuciones de Ethereum usando Snark.

Además del enfoque a largo plazo en la validación de Snark de toda la cadena, otra nueva pregunta está relacionada con si los árboles de Verkle son la mejor tecnología.Los árboles verkle son vulnerables a las computadoras cuánticas, por lo que si reemplazamos los árboles actuales de Keccak Merkle Patricia con árboles verkle, tendremos que reemplazar estos árboles nuevamente más tarde.Una alternativa natural a los árboles de Merkle es saltar directamente al uso de la rama Stark Merkle en el árbol binario.Históricamente, esto se ha considerado inviable debido a la complejidad técnica y de sobrecarga.Sin embargo, recientemente, hemos visto que Starkware ha demostrado que 1,7 millones de hashs Poseidon por segundo en computadoras portátiles con Circle Stark, y el tiempo de prueba para el hashs más «tradicional» también se está reduciendo rápidamente debido a tecnologías como GKR.

Entonces, durante el año pasado, Verge se ha vuelto más abierto y hay múltiples posibilidades.

El borde: objetivos clave

• Cliente sin estado: Verifique completamente que el cliente y el nodo estampado no requieran más de unos pocos GB de espacio de almacenamiento.

• (A largo plazo) cadena de verificación integral (consenso y ejecución) en relojes inteligentes.Descargue algunos datos, verifique Snark y termine.

En este artículo, se destaca el siguiente contenido:

• 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é problemas queremos resolver?

Hoy, los clientes de Ethereum necesitan almacenar cientos de GB de datos estatales para verificar los bloques, y este número continúa aumentando cada año.Los datos del estado sin procesar aumentan aproximadamente 30 GB por año, y los clientes personales deben almacenar algunos datos adicionales además de poder actualizar de manera efectiva los intentos.

Esto reduce el número de usuarios que pueden ejecutar nodos Ethereum totalmente verificados: aunque el disco duro es lo suficientemente grande como para almacenar todo el estado de Ethereum e incluso años de historia, las computadoras compran de forma predeterminada tienden a tener solo unos pocos cientos de gigabytes de espacio de almacenamiento.El tamaño del estado también puede causar grandes problemas al proceso de configuración de un nodo por primera vez: el nodo necesita descargar todo el estado, que puede llevar horas o días.Esto producirá varias reacciones en cadena.Por ejemplo, esto hace que sea más difícil para los Stakers actualizar su configuración de estaca.Técnicamente, esto se puede hacer sin un tiempo de inactividad, iniciando un nuevo cliente, esperando que se sincronice, luego cierre el cliente anterior y transfiera la clave, pero en realidad, esto es técnicamente complejo.

¿Qué es y cómo funciona?

La verificación sin estado es una técnica que permite que los nodos verifiquen bloques sin tener un estado completo.En cambio, cada bloque viene con un testigo, que incluye (i) valores en una ubicación específica en el estado, el bloque accederá (por ejemplo, código, equilibrio, almacenamiento) y (ii) la prueba criptográfica de estos valores es correcto de.

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 actual de Merkle Patricia es extremadamente hostil para implementar cualquier esquema de prueba de contraseña, especialmente en el peor de los casos.Esto es cierto para la rama de Merkle «original» y la posibilidad de «envolver» la rama de Merkle en Stark.Las principales dificultades provienen de dos debilidades en MPT:

• Es un hexagrama (es decir, cada nodo tiene 16 nodos infantiles).Esto significa que, en promedio, la prueba en un árbol de tamaño n tiene 32*(16-1)*log16 (n) = 120*bytes log2 (n), o aproximadamente 3840 bytes en un árbol de 232 ítems.Para árboles binarios, solo se necesitan 32*(2-1)*log2 (n) = 32*log2 (n) bytes, es decir, alrededor de 1024 bytes.

• Este código no es merkelizado.Esto significa que se requiere acceso al código de cuenta para proporcionar el código completo, con una longitud máxima de 24,000 bytes.

Podemos calcular el peor caso de la siguiente manera:

30,000,000 de gas / 2,400 (costo de lectura de cuenta «fría») * (5 * 480 + 24,000) = 330,000,000 bytes

Los costos de la rama son ligeramente más bajos (5*480 en lugar de 8*480), porque cuando hay muchas ramas, la parte superior de la rama se repetirá.Pero aun así, la cantidad de datos descargados en una ranura es completamente poco realista.Si intentamos envolverlo en Stark, tenemos dos problemas: (i) Keccak no es amigable en relación con Stark, (ii) 330 MB de datos significa que tenemos que demostrar 5 millones de llamadas a la función redonda de Keccak, que es una forma Incluso si podemos hacer que Stark demuestre Keccak más eficiente, hay muchas más cosas que no se pueden probar en todo el hardware además del hardware de consumo más potente.

Si solo reemplazamos el hexagrama con un árbol binario y agregamos el código de merkelize, el peor de los casos será de aproximadamente 30,000,000 / 2,400 * 32 * (32 – 14 + 8) = 10,400,000 bytes ~ 214 ramas, 8 son prueba de longitud que ingresa una hoja).Tenga en cuenta que esto requiere cambiar el costo de gas para acceder a cada bloque de código individual;10.4 MB es mucho mejor, pero para muchos nodos, todavía hay demasiados datos para descargar en una ranura.Por lo tanto, necesitamos introducir algunas tecnologías más poderosas.Para hacer esto, hay dos soluciones principales: el árbol Verkle y el árbol de hash binario rígido.

Árbol verkle

Los árboles verkle usan compromisos vectoriales basados ​​en curvas elípticas para hacer pruebas más cortas.La clave es que no importa el ancho del árbol, el fragmento de prueba correspondiente para cada relación padre-hijo es de solo 32 bytes.La única limitación del ancho del árbol es que si el árbol es demasiado ancho, se reducirá la eficiencia computacional de la prueba.El ancho de implementación recomendado de Ethereum es 256.

Por lo tanto, el tamaño de una sola rama en la prueba se convierte en 32*log256 (n) = 4*log2 (n) bytes.Teóricamente, el tamaño de prueba máxima se convierte en aproximadamente 30,000,000/2,400*32*(32-14+8)/8 = 1,300,000 bytes (los cálculos matemáticos son ligeramente diferentes en la práctica debido a la distribución desigual de los bloques de estado, pero este es el primero muy bueno) .

Como una advertencia adicional, tenga en cuenta que en todos los ejemplos anteriores, este «peor de los casos» no es el peor de los casos: el peor caso es que el atacante «minas» deliberadamente dos direcciones para tener un largo público en el prefijo de árboles y leer desde Uno de ellos, esto puede extender la longitud de la rama del peor de los casos en aproximadamente 2 veces.Pero incluso con tal advertencia, el árbol de Verkle nos da aproximadamente 2.6 MB de la peor prueba de casos, lo que coincide aproximadamente con los datos de llamadas de los peores casos de hoy.

También usamos esta advertencia para hacer otra cosa: hacemos acceso al almacenamiento «adyacente» muy barato: muchos bloques de código del mismo contrato o ranuras de almacenamiento adyacentes.EIP-4762 proporciona la definición de adyacencia, y el acceso a la adyacencia solo se le cobra una tarifa de gas de 200.Para el acceso adyacente, el tamaño de prueba del 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 queremos reducir este valor para la seguridad, podemos aumentar ligeramente el costo del acceso adyacente.

Árbol de hash binario protagonizado

La técnica aquí se explica por sí misma: usted hace un árbol binario, tome la prueba máxima de 10.4 mb de que necesita probar el valor en un bloque y reemplazar la prueba con la dura de esa prueba.Esto nos lleva a descubrir que la prueba en sí contiene solo los datos que están probados, más la sobrecarga fija del Stark real.

El principal desafío aquí es probar el tiempo.Podemos hacer básicamente el mismo cálculo que anteriormente, excepto que no calculamos los bytes, sino que calculamos el valor hash.Un bloque de 10.4 Mb significa 330,000 hash.Si agregamos la posibilidad de que un atacante «mine la dirección con un largo prefijo público en el árbol, el verdadero peor de los casos se convertirá en aproximadamente 660,000 hashes.Entonces, si podemos probar alrededor de 200,000 hash por segundo, entonces está bien.

Se han alcanzado estos números en computadoras portátiles de consumo con una función de hash Poseidon diseñada específicamente para una clara amistad.Sin embargo, Poseidón es relativamente inmaduro, por lo que muchas personas aún no confían en su seguridad.Por lo tanto, hay dos caminos realistas:

• Realice rápidamente un montón de análisis de seguridad en Poseidon y esté familiarizado con él para implementarlo en L1

• Use una función hash más «conservadora», como Sha256 o Blake

Al momento de escribir, Starkware’s Stark Prover solo puede probar alrededor de 10-30k hash por segundo en una computadora portátil de consumo si quiere demostrar una función de hash conservadora.Sin embargo, la tecnología Stark está avanzando rápidamente.Incluso hoy en día, la tecnología basada en GKR muestra potencial para aumentarla al rango de aproximadamente 100-200k.

Casos de uso de testigos distintos de los bloques de verificación

Además del bloque de verificación, hay otros tres casos de uso clave que permiten una verificación sin estado más eficiente:

• Grupo de memoria:Cuando se transmite una transacción, los nodos en la red P2P deben verificar que la transacción sea válida antes de la retransmitencia.Hoy, la verificación incluye no solo verificar la firma, sino también verificar que el equilibrio es suficiente y que el número aleatorio es correcto.En el futuro (por ejemplo, utilizando abstracciones de cuenta nativa, como EIP-7701), esto puede implicar ejecutar algún código EVM que realice algún acceso de estado.Si el nodo no tiene estado, la transacción requerirá una prueba con una prueba del objeto de estado.

• Incluir la lista:Esta es una característica propuesta que permite que los validadores de prueba de prueba (posiblemente pequeños y sin complicaciones) forzaran que el siguiente bloque contenga transacciones, independientemente de los deseos (posiblemente grandes y complejos) del constructor de bloques.Esto reducirá la capacidad de los poderosos participantes para manipular blockchains al retrasar las transacciones.Sin embargo, esto requiere que los validadores tengan una forma de verificar la validez de las transacciones en la lista incluida.

• Cliente de luz:Si queremos que los usuarios accedan a la cadena a través de billeteras (por ejemplo, Metamask, Rainbow, Rabby …) sin confiar en los participantes centralizados, deben ejecutar un cliente ligero (por ejemplo, Helios).El módulo Core Helios proporciona a los usuarios una raíz de estado validada.Sin embargo, para obtener una experiencia totalmente confiable, los usuarios deben proporcionar pruebas para cada llamada RPC individual que realicen (por ejemplo, para una solicitud ETH_CALL, los usuarios necesitan pruebas de todos los estados accedidos durante la llamada);

Una cosa que todos estos casos de uso son comunes es que requieren muchas pruebas, pero cada prueba es pequeña.Por lo tanto, Stark demuestra que en realidad no tiene sentido para ellos;Otra ventaja de las ramas de Merkle es que se están actualizando: dada una prueba de objeto de estado x enraizada en el bloque B, puede actualizar esa prueba si recibe un subblockear B2 con su testigo.La prueba de Verkle en sí también está actualizada.

¿Cuáles son las conexiones con la investigación existente?

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

El papel de árbol Verkle original de John Kuszmaul:https://math.mit.edu/research/highschool/primes/materials/2018/kuszmaul.pdf

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

Documento Poseidon2:https://eprint.iacr.org/2023/323

Ajtai (función de hash rápida alternativa basada en la dureza de la cuadrícula):https://www.wisdom.weizmann.ac.il/~oded/col/cfh.pdf

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

¿Qué más hay que hacer y qué compensaciones deben sopesarse?

Las tareas principales restantes a realizar son:

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

• Más procedimientos de transición de finalización y prueba de trabajo, que es una gran parte de cualquier complejidad de EIP apátrida

• Más análisis de seguridad de Poseidón, Ajtai y otras funciones de hash «amigables con la vida»

• Desarrolle aún más los protocolos Stark ultraeficientes para las funciones de hash «conservadoras» (o «tradicionales»), como la idea basada en Binius o GKR.

Pronto tomaremos un punto de decisión para elegir cuál de las siguientes tres opciones: (i) Árbol Verkle, (ii) función hash amigable con la claridad y (iii) función de hash conservador.Sus propiedades se pueden resumir aproximadamente de la siguiente manera:

Además de estos «números de título», hay algunas otras consideraciones importantes:

• ahora,El código de árbol Verkle es bastante maduro.Usar cualquier otra cosa que no sea Verkle retrasará la implementación, muy probablemente a través de horquillas duras.Esto puede estar bien, especialmente si necesitamos tiempo extra para hacer un análisis de funciones hash o una implementación de Prover de todos modos, y si tenemos otras características importantes que queremos incluir en Ethereum lo antes posible.

• Actualizar la raíz de estado con hash es más rápido que usar árboles verkle.Esto significa que el enfoque basado en hash puede acortar el tiempo de sincronización del nodo completo.

• VEl árbol de Erkle tiene interesantes propiedades de actualización de testigos– Verkle Tree Witness se está actualizando.Esta propiedad es útil para grupos de memoria, incluye listas y otros casos de uso, y también puede ayudar a lograr la eficiencia: si actualiza el objeto de estado, puede actualizar al testigo a nivel penúltimo sin siquiera leer el último nivel.

• Los árboles Verkle son más difíciles de probar con Snark.Si queremos reducir el tamaño de prueba hasta unos pocos kilobytes, las pruebas de Verkle pueden causar algunas dificultades.Esto se debe a que la verificación de prueba de Verkle introduce una gran cantidad de operaciones de 256 bits, lo que requiere que el sistema de prueba tenga muchas sobrecargas o en sí misma tenga una estructura interna personalizada que contiene la parte de 256 bits para la prueba de Verkle.

Otro posible enfoque es el Merkle Tree basado en la malla si queremos que la actualización presenciada por Verkle se haga de una manera cuántica segura y bastante eficiente.

Si se demuestra que el sistema no es lo suficientemente efectivo en el peor de los casos, podemos compensar esta deficiencia con otro «conejo en el sombrero», que es gas multidimensional: acceso a (i) calldata, (ii) computación, (( iii) el estado y posiblemente otros recursos diferentes tienen restricciones de gas separadas.El gas multidimensional agrega complejidad, pero a cambio, limita más estrictamente la relación entre el escenario promedio y el peor de los casos.Para el gas multidimensional, el número máximo teórico de ramas para probar puede reducirse de 30,000,000 / 2400 = 12,500 a 3000.Esto hará que Blake3 (apenas) sea suficiente incluso hoy, sin mejoras de prueba adicionales.

El gas multidimensional permite limitaciones de recursos de bloque para replicar las limitaciones de recursos de hardware subyacentes más cercanas a las del hardware subyacente.

Otra «respiración que aparece» es la propuesta de retrasar el cálculo de la raíz del estado hasta después del bloque.Esto nos dará 12 segundos completos para calcular la raíz de estado, lo que significa que incluso en los casos más extremos, solo alrededor de 60,000 hash/segundo tiempo de prueba es suficiente, lo que nuevamente nos coloca en Blake3 apenas lo suficientemente dentro del rango de uso.

La desventaja de este enfoque es que aumenta la latencia de la luz del cliente en un período, aunque hay versiones más inteligentes de la tecnología que pueden reducir esta latencia a solo la latencia de generación de pruebas.Por ejemplo, mientras cualquier nodo genere una prueba, la prueba se puede transmitir en la red en lugar de esperar el siguiente bloque.

¿Cómo interactúa con el resto de la hoja de ruta?

Resolver el problema sin estado aumenta enormemente la conveniencia de las promesas separadas.Esto se volverá más valioso si las tecnologías que pueden reducir el equilibrio mínimo de las apuestas individuales, como la órbita SSF o las políticas de la capa de aplicación, como las apuestas de escuadrón, están disponibles.

El gas multidimensional será más fácil si el EOF se introduce al mismo tiempo.Esto se debe a que una complejidad clave del gas multidimensional para la ejecución es manejar las llamadas infantiles que no pasan la llamada de los padres al gas completo, y EOF simplemente hace que una llamada de este niño sea ilegal (y la abstracción de la cuenta nativa proporcionará una corriente en la corriente Alternativas de protocolo de subcall de gas para los principales casos de uso).

Otra sinergia importante es la sinergia entre la verificación sin estado y el vencimiento histórico.Hoy, los clientes deben almacenar casi terabytes de datos históricos;Incluso si el cliente no tiene estado, el sueño del cliente de casi ningún almacenamiento no puede realizarse a menos que también podamos aliviar la responsabilidad del historial de almacenamiento del cliente.El primer paso a este respecto es EIP-4444, lo que también significa almacenar datos históricos en una red de torrente o portal.

Prueba de validez de la ejecución de EVM

¿Qué problemas queremos resolver?

El objetivo a largo plazo de la verificación del bloque Ethereum es claro: debería poder verificar un bloque Ethereum: (i) descargando el bloque, tal vez incluso una pequeña porción del bloque y la disponibilidad de datos de muestreo, y (ii) verificar un Pequeña porción para demostrar que el bloque es válido.Esta será una operación con un consumo de recursos mínimo que se puede hacer en un cliente móvil, dentro de una billetera del navegador o incluso (sin parte de disponibilidad de datos) en otra cadena.

Para lograr esto, se requieren pruebas de Snark o Stark con (i) capa de consenso (es decir, prueba de estaca) y (ii) capa de ejecución (es decir, EVM).El primero es un desafío en sí mismo y debe abordarse en el proceso de mejorar aún más la capa de consenso (por ejemplo, finalidad de un solo rango).Este último requiere prueba de 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: tiene algunos pre-estado S, un bloque B, y está calculando un stf post-estatal s ‘= stf (s, b).Si el usuario está usando un cliente ligero, no tiene S y S ‘, o incluso B Full B;La declaración completa que debe probarse es aproximadamente:

• Entrada pública:La raíz estatal anterior R, la última raíz de estado R ‘y el bloque de Hash H.

• Entrada privada:Bloque B, Objetos en el estado accedido por bloque Q, se ejecutó el mismo objeto después del bloque Q ‘, prueba de estado (como la rama de Merkle) P.

• Proposición 1:P es una prueba válida de que Q contiene algunas partes del estado representadas por R.

• Proposición 2:Si ejecuta STF en Q, (i) ejecuta solo objetos de acceso dentro de Q, (ii) El bloque es válido, y (iii) el resultado es Q ‘.

• Proposición 3:Si recalcula la nueva raíz de estado utilizando la información en Q ‘y P, obtendrá R’.

Si existe, puede tener un cliente ligero que pueda verificar completamente la ejecución de Ethereum EVM.Esto hace que los recursos del cliente sean bastante pequeños.Para obtener un cliente Ethereum verdaderamente validado, también debe hacer lo mismo para la parte de consenso.

La implementación de la prueba de validez de la computación EVM ya existe y es ampliamente utilizada por L2.Sin embargo, todavía hay mucho trabajo por hacer para que la prueba de validez EVM funcione aplicable a L1.

¿Cuáles son las conexiones con la investigación existente?

EC PSE ZK-EVM (ahora en desuso porque 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 de ZK-EVM:https://verified-zkevm.org/

¿Qué más hay que hacer y qué compensaciones deben sopesarse?

ahora,La prueba de validez de EVM no es suficiente en dos aspectos: seguridad y tiempo de prueba.

La prueba de efectividad de seguridad debe garantizar que Snark verifique los cálculos de EVM y que no haya errores en él.Las dos técnicas principales para mejorar la seguridad son múltiples proverbios y verificación formal.Multi-probado significa tener múltiples pruebas de validez por escrito independientemente, al igual que tener múltiples clientes, y si un subconjunto lo suficientemente grande de estas implementaciones demuestra un bloque, el cliente acepta ese bloque.La validación formal implica el uso de herramientas comúnmente utilizadas para probar los teoremas matemáticos (como Lean4) para demostrar que las pruebas de validez aceptan solo la entrada que se ejecuta correctamente por la especificación EVM subyacente escrita en Python.

El tiempo de prueba bastante rápido significa que cualquier bloque Ethereum puede probarse en menos de 4 segundos.Hoy, todavía estamos lejos de este objetivo, a pesar de que estamos mucho más cerca de lo que pensamos hace dos años.Para lograr esto, necesitamos avanzar en tres aspectos:

• Paralelización: el Prover de EVM más rápido de hoy puede probar el bloque de Ethereum promedio en aproximadamente 15 segundos.Lo hace paralelizando a cientos de GPU y finalmente juntando su trabajo.En teoría, sabemos exactamente cómo hacer un prover EVM que pueda probar el cálculo en el tiempo O (log (n)): deje que una GPU realice cada paso y luego realice el «Árbol de agregación»:

Hay desafíos en la implementación de esto.Incluso en el peor de los casos (es decir, las transacciones muy grandes ocupan todo el bloque), la división calculada no se puede hacer por transacción;Un desafío de implementación clave que hace que esto no sea del todo trivial es la necesidad de garantizar que la «memoria» de la VM sea consistente en diferentes partes de la prueba.Sin embargo, si podemos hacer esta prueba recursiva, entonces sabemos que al menos se ha resuelto el problema de retraso de Prover, incluso si no hay mejora en ningún otro eje.

• Optimización del sistema de prueba:Nuevos sistemas de prueba como Orion, Binius, GKR pueden dar lugar a una reducción significativa en el tiempo de prueba para computados en general.

• El gas de EVM consume otros cambios –Muchas cosas en EVM se pueden optimizar para que sean más amigables con el Prover, especialmente en el peor de los casos.Si un atacante puede construir un bloque que toma diez minutos para el Prover, no es suficiente para demostrar un bloque de ethereum promedio en 4 segundos.Los cambios EVM requeridos se pueden dividir en dos categorías:

• Cambios de costos de gas –Si una operación tarda mucho en probar, debe tener un costo de gas más alto incluso si el cálculo es relativamente rápido.EIP-7667 es un EIP propuesto para lidiar con el problema más grave a este respecto: aumenta significativamente el costo del gas como códigos de operación relativamente baratos y precompilas y funciones de hash expuestas (tradicionales).Para compensar estos mayores costos de gas, podemos reducir los costos de gas de probar códigos de operación EVM relativamente baratos, manteniendo así el rendimiento promedio igual.

• Reemplazo de la estructura de datos –Además de reemplazar el árbol de estado con una alternativa que sea más adecuada para Stark, también necesitamos reemplazar las listas de transacciones, los árboles de recibos y otras estructuras que resultan costosas.El EIP de Ethan Kissling mueve la estructura de transacción y recibo a SSZ ([1] [2] [3]), un paso en esta dirección.

Además, los dos «conejos que salen del sombrero» mencionados en la sección anterior (gas multidimensional y raíces estatales retrasadas) también pueden ayudar aquí.Sin embargo, vale la pena señalar 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, e incluso con estas tecnologías, una verificación completa de ZK-EVM requerirá más trabajo, solo requiere menos trabajo.

Una cosa no mencionada anteriormente es el hardware de prueba: generar pruebas más rápido usando GPU, FPGA y ASICS.La criptografía de tela, Cysic y AccSeal son los promotores de estas tres compañías.Esto es muy valioso para el Nivel 2, pero es poco probable que sea una consideración decisiva para el Nivel 1, ya que existe un fuerte deseo de mantener el Nivel 1 altamente descentralizado, lo que significa que la generación de pruebas debe estar en un subconjunto considerable dentro del alcance de la capacidad .Los usuarios de Ethereum no deben encontrar cuellos de botella en el hardware de una sola empresa.La capa 2 permite compensaciones más radicales.

Hay más trabajo por hacer en estas áreas:

• La prueba paralela requiere un sistema de prueba donde diferentes partes de la prueba pueden ser «memoria compartida» (como tablas de búsqueda).Conocemos las técnicas para hacer esto, pero deben implementarse.

• Necesitamos más análisis para encontrar el conjunto ideal de variaciones de costo de gas para minimizar el peor tiempo de prueba.

• Necesitamos hacer más sobre el sistema de prueba

Las posibles compensaciones aquí incluyen:

• Seguridad y tiempo de prover:Las opciones activas que utilizan funciones hash, sistemas de prueba con supuestos de seguridad más complejos o más activos u otras opciones de diseño pueden reducir el tiempo de saco.

• Tiempo descentralizado y prover:La comunidad necesita estar de acuerdo sobre la «normativa» de su hardware de prover objetivo.¿Está bien pedirle a la prueba que sea una entidad a gran escala?¿Esperamos que las computadoras portátiles de consumo de alta gama puedan probar el bloque Ethereum en 4 segundos?¿Algo intermedio?

• El grado en que se rompe la compatibilidad con atrasado:Las deficiencias en otras áreas pueden compensarse haciendo cambios de costo de gas más agresivos, pero es más probable que esto aumente el costo de ciertas aplicaciones de manera desproporcionada y obligue a los desarrolladores a reescribir y redistribuir el código para mantenerlas económicamente viables.Del mismo modo, el «conejo en el sombrero» también tiene su propia complejidad y desventajas.

¿Cómo interactúa con el resto de la hoja de ruta?

Las tecnologías centrales requeridas para implementar la prueba de validez EVM en la capa 1 se comparten ampliamente con otras dos áreas:

• Prueba de validez de la capa 2 (es decir, «Rollups ZK»)

• Método sin estado «Prueba de hash binaria Stark»

La implementación exitosa de la validez en el Nivel 1 demuestra que, en última instancia, una explosión separada fácil: incluso las computadoras más débiles, incluidos los teléfonos móviles o los relojes inteligentes, pueden ser replantes.Esto aumenta aún más el valor de abordar otras restricciones para replantear individualmente (por ejemplo, mínimo 32 ETH).

Además, la validez EVM de L1 demostró aumentar significativamente el límite de gas de L1.

Prueba de validez del consenso

¿Qué problemas queremos resolver?

Si queremos poder verificar completamente los bloques de Ethereum con Snark, entonces la ejecución de EVM no es la única parte que debemos probar.También debemos probar el consenso: las partes del sistema que manejan depósitos, retiros, firmas, actualizaciones de saldo de validador y otros elementos de la sección de estaca de Ethereum.

El consenso es mucho más simple que EVM, pero el desafío que enfrenta es que no tenemos un resumen EVM de la capa 2, por lo que la mayoría del trabajo debe hacerse de todos modos.Por lo tanto, cualquier implementación del consenso de Ethereum de prueba debe hacerse «desde cero», aunque el sistema de prueba en sí es un trabajo compartido que se puede construir en él.

¿Qué es y cómo funciona?

Una cadena de baliza se define como una función de transición de estado, al igual que un EVM.La función de transferencia de estado está determinada por tres factores:

• ECADD (para verificación de firmas BLS)

• Emparejamiento (para verificación de firmas BLS)

• Hash SHA256 (para el estado de lectura y actualización)

En cada bloque, necesitamos probar 1-16 BLS12-381 Ecadds para cada validador (probablemente más de uno, ya que la firma puede incluirse en múltiples agregados).Esto puede compensarse mediante técnicas de precomputación de subconjuntos, por lo que podemos decir que cada validador es un BLS12-381 ECADD.Hoy, hay alrededor de 30,000 firmas de validadores por período.En el futuro, para la finalidad de una sola ranura, esto puede cambiar en cualquier dirección(Ver las instrucciones aquí): Si tomamos la ruta «fuerte», cada ranura puede aumentar a 1 millón de validadores.Mientras tanto, con SSF de órbita, permanecerá en 32,768, o incluso se reducirá a 8,1.

Cómo funciona la agregación BLS.Verificar la firma agregada requiere solo ECADD para cada participante, no ECMUL.Pero todavía hay mucho que demostrar en 30,000 ecadios.

Para el emparejamiento, actualmente hay hasta 128 pruebas por ranura, lo que significa que se deben verificar 128 pares.Con EIP-7549 y cambios adicionales, esto puede reducirse a 16 por ranura.El número de pares es pequeño, pero el costo es extremadamente alto: cada par funciona (o demuestra) miles de veces más tiempo que ECADD.

Un desafío importante en la operación de prueba BLS12-381 es la falta de curvas convenientes cuyo orden de curva es igual al tamaño del campo BLS12-381, lo que agrega considerable sobrecarga a cualquier sistema de prueba.Por otro lado, el árbol Verkle propuesto para Ethereum está construido con curvas de Bandersnatch, lo que hace que BLS12-381 sea una curva natural utilizada en el sistema de tranqueo para probar las ramas Verkle.Una implementación bastante simple puede proporcionar aproximadamente 100 adiciones G1 por segundo;

Para el hash SHA256, el peor de los casos es el bloque de conversión de la época, donde se actualizan todo el árbol de balance corto de validador y una gran cantidad de saldos de validador.Árbol de balance corto de validador Solo hay un byte por validador, por lo que se volverán a hacer aproximadamente 1 MB de datos.Esto es equivalente a 32,768 llamadas SHA256.Si el equilibrio de mil validadores está por encima o por debajo del umbral, el saldo válido en el registro de validador debe actualizarse, que corresponde a mil ramas de Mil Merkle, por lo que puede haber diez mil hashes.El mecanismo de barajamiento requiere 90 bits por validador (y, por lo tanto, 11 MB de datos), pero esto se puede calcular en cualquier momento en un proceso de época.Para la finalidad de la ranura única, estos números pueden aumentar o disminuir nuevamente de acuerdo con los detalles.Una baraja se vuelve innecesaria, aunque la pista puede restaurar de alguna manera la necesidad de una baraja.

Otro desafío es que necesita leer todos los estados de validador (incluidas las claves públicas) para verificar el bloque.Para 1 millón de validadores, más la sucursal de Merkle, se requieren 48 millones de bytes para leer solo la clave pública.Esto requiere millones de hashes por época.Si tenemos que probar la verificación de la prueba de la estaca hoy, entonces un enfoque realista es una forma de computación verificable incremental: se almacena una estructura de datos separada en el sistema PROOM que está optimizado para búsquedas eficientes y proporciona las actualizaciones a esta estructura.

En general, hay muchos desafíos.

Es probable que la solución más eficiente a estos desafíos requiera un rediseño profundo de la cadena de baliza, que puede ocurrir simultáneamente con el cambio a la finalidad de un solo rango.Las características de este rediseño pueden incluir:

• Cambios de función hash:Hoy, se usa la función hash SHA256 «completa», por lo que debido al relleno, cada llamada corresponde a dos llamadas de función comprimida subyacente.Al menos, podemos obtener 2X ganancia cambiando a la función de compresión SHA256.Si usamos Poseidon en su lugar, podemos obtener aproximadamente 100 veces ganancia, lo que resuelve completamente todos nuestros problemas (al menos para hashes): 1.7 millones de hashes por segundo (54 MB) e incluso «leen un millón de» registros de verificadores «» puede probarlo en segundos.

• Si es órbita, el registro del verificador interrumpido se almacenará directamente:Si elige un cierto número de validadores (por ejemplo, 8,192 o 32,768) como el comité para una ranura determinada, colóquelos directamente en el estado adyacente entre sí para que el hash mínimo sea necesario para leer todas las claves públicas de validador en la prueba.Esto también permitirá que todas las actualizaciones de saldo se completen de manera eficiente.

• Agregación de la firma:Cualquier esquema de agregación de firma de alto rendimiento realmente involucrará algún tipo de prueba recursiva, donde la prueba intermedia del subconjunto de firmas será realizada por nodos individuales en la red.Esto naturalmente distribuye la carga de prueba en muchos nodos en la red, lo que hace que el «Provergido final» sea mucho menos trabajo.

• Otros esquemas de firma:Para las firmas de Lamport+Merkle, necesitamos 256+32 hashes para verificar la firma;La optimización del esquema de firma puede mejorarse aún más con un pequeño factor constante.Si usamos Poseidón, esto está dentro del alcance de la prueba dentro de una sola ranura.Pero en realidad, con un esquema de agregación recursiva, esto se vuelve más rápido.

¿Cuáles son las conexiones con la investigación existente?

Prueba de consenso concisa, Ethereum (Comité Sincrónico solamente):https://github.com/succinctlabs/eth-proof-of-consensus

Simple, helios en SP1:>https://github.com/succinctlabs/sp1-helios

Concise BLS12-381 Precompilado:https://blog.succinct.xyz/succinctshipsprecompiles/

Verificación de firma de agregación BLS basada en Halo2:https://ethresear.ch/t/zkpos-with-halo2-pairing-for-verify-gregate-lignatures/14671

¿Qué más hay que hacer y qué compensaciones deben sopesarse?

De hecho, llevará años obtener la validez del consenso de Ethereum.Esta es aproximadamente la misma línea de tiempo que necesitamos implementar la finalidad de un solo rango, las pistas, los cambios en los algoritmos de firma y el análisis de seguridad potencial para tener suficiente confianza para usar una función de hash «radical» como Poseidon.Por lo tanto, tiene más sentido resolver estos otros problemas y tener en cuenta en mente al hacer estas tareas.

Es probable que la principal compensación esté en el orden de operaciones, entre un enfoque más progresivo para reformar la capa de consenso de Ethereum y un enfoque más radical para «hacer muchos cambios a la vez».Para EVM, el enfoque incremental tiene sentido porque minimiza el daño a la compatibilidad hacia atrás.Para la capa de consenso, los problemas de compatibilidad hacia atrás son menos problemáticos y más «completos» repensando los diversos detalles de cómo se construyen las cadenas de baliza para optimizar mejor la amistad de Snark.

¿Cómo interactúa con el resto de la hoja de ruta?

Stark Friendly debe ser el foco principal del rediseño a largo plazo del consenso de prueba de estaca de Ethereum, sobre todo, finalidad de un solo rango, órbita, cambios de esquema de firma y agregación de firma.