Título original: "Posibles futuros del protocolo Ethereum, parte 4: The Verge"

原文作者：Vitalik Buterin

原文编译：Mensh，ChainCatcher

Agradecemos especialmente los comentarios y revisiones de Justin Drake, Hsia-wei Wanp, Guillaume Ballet, Icinacio, Rosh Rudolf, Lev Soukhanoy Ryan Sean Adams y Uma Roy.

Una de las características más poderosas de la cadena Bloquear es que cualquier persona puede ejecutar un Nodo en su propia computadora y verificar la corrección de la cadena Bloquear. Incluso si los 9596 Nodos que ejecutan el consenso de la cadena (PoW, PoS) acuerdan de inmediato cambiar las reglas y comenzar a producir Bloquear según las nuevas reglas, cada persona que ejecute un Nodo completamente verificado rechazará la cadena. Los mineros que no formen parte de este grupo conspirador automáticamente se agruparán en una cadena on-chain que continúa siguiendo las reglas antiguas y continuarán construyendo esa cadena, mientras que los usuarios completamente verificados seguirán esa cadena.

Esta es la diferencia clave entre blockchain y sistemas centralizados. Sin embargo, para que esta característica sea válida, es factible que un Nodo de verificación completa se ejecute para suficientes personas. Esto se aplica tanto a los hacedores de tendencia (ya que si no verifican la cadena, no están contribuyendo a la ejecución del protocolo), como a los usuarios regulares. Hoy en día, es posible ejecutar un Nodo en una computadora portátil de consumo (incluida la computadora portátil utilizada para escribir este artículo), pero hacerlo es muy difícil. The Verge busca cambiar esta situación, reduciendo el costo computacional de la verificación de la cadena completa, lo que permitiría que cada billetera de teléfono, billetera de navegador e incluso reloj inteligente realice la verificación de forma predeterminada.

El mapa de ruta de The Verge 2023

Inicialmente, 'Verge' se refería a la transferencia del estado de cuenta de Ethereum a un árbol Verkle, una estructura de árbol que permite pruebas más compactas y verifica los bloques de Ethereum sin almacenar ningún estado de Ethereum (saldo de la cuenta, código de contrato, espacio de almacenamiento, etc.) en el disco. Un Nodo puede verificar un bloque de Ethereum sin necesidad de almacenar ningún estado de Ethereum en su disco (saldo de la cuenta, código de contrato, espacio de almacenamiento, etc.), 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, centrándose en lograr la máxima eficiencia de recursos en la cadena de Ethereum, que incluye no solo la tecnología de verificación sin estado, sino también la verificación de todos los ejecuciones de Ethereum utilizando SNARK.

Además de seguir a largo plazo la verificación de toda la cadena con SNARK, otro nuevo problema está relacionado con si el árbol Verkle es la mejor tecnología. El árbol Verkle es vulnerable a los ataques de Computadora cuántica, por lo que si reemplazamos el árbol Verkle en el árbol actual de KECCAK Merkle Patricia, tendremos que reemplazarlo nuevamente en el futuro. El método de auto-sustitución del árbol Merkle es saltar directamente a un árbol binario que no utiliza ramas de Merkle, utilizando STARK. Históricamente, este enfoque se ha considerado inviable debido al costo y la complejidad técnica. Sin embargo, recientemente hemos visto que Starkware ha demostrado 1.7 millones de hashes de Poseidon por segundo en una computadora portátil utilizando ckcle STARKs, y el tiempo de prueba de más hashes tradicionales también se está reduciendo rápidamente gracias a tecnologías como GKB. Por lo tanto, en el último año, Verge se ha vuelto más abierto y tiene varias posibilidades.

The Verge: Objetivo clave

• Cliente sin estado: El espacio de almacenamiento necesario para la validación completa del cliente y la marca Nodo no debe exceder varios GB.
• (A largo plazo) Verificar completamente la cadena (Consenso y ejecución) en un reloj inteligente. Descargar algunos datos, verificar SNARK, completar.

En este capítulo

• Cliente sin estado: Verkle o STARKs
• EVM ejecución de prueba de validez
• Prueba de validez de Consenso

Verificación sin estado: Verkle o STARKs

¿Qué problema estamos tratando de resolver?

Hoy en día, el cliente de ETH necesita almacenar cientos de gigabytes de datos de estado para verificar Bloquear, y esta cantidad aumenta cada año. Los datos de estado originales aumentan aproximadamente 30 GB cada año, y cada cliente individual debe almacenar algunos datos adicionales sobre él para actualizar eficientemente las tripletas.

Esto reduce la cantidad de usuarios que pueden ejecutar completamente validando el Nodo de Ethereum: aunque hay discos duros grandes disponibles en todas partes que son lo suficientemente grandes como para almacenar todos los estados de Ethereum e incluso años de historia, las computadoras que la gente compra por defecto a menudo solo tienen unos pocos cientos de gigabytes de espacio de almacenamiento. El tamaño del estado también ha creado una gran fricción en el proceso de establecimiento inicial del Nodo: el Nodo necesita descargar todo el estado, lo cual puede llevar varias horas o incluso días. Esto tiene muchas repercusiones. Por ejemplo, aumenta en gran medida la dificultad de los creadores de Nodos para actualizar su configuración de Nodo. Técnicamente, se puede hacer una actualización sin apagar el sistema: iniciar un nuevo cliente, esperar a que se sincronice, luego cerrar el cliente antiguo y transferir la llave secreta. Pero en la práctica, esto es muy complicado desde el punto de vista técnico.

¿Cómo funciona?

La verificación sin estado es una técnica que permite a los Nodos verificar Bloques sin tener que poseer el estado completo. En su lugar, cada Bloque viene con un testigo que incluye: (i) el valor, código, saldo, almacenamiento de posiciones específicas en el estado que el Bloque accederá; (ii) una prueba de encriptación que demuestra la veracidad de estos valores.

En realidad, lograr una verificación sin estado requiere cambiar la estructura del árbol de estado de Ethereum. Esto se debe a que el actual árbol de Merkle Patricia es extremadamente hostil para implementar cualquier esquema de encriptación, especialmente en el peor de los casos. Tanto las ramas 'originales' de Merblk como la posibilidad de 'empaquetar' en STARK son problemáticas. Las principales dificultades provienen de algunas debilidades de MPT:

1. Este es un árbol de 6 vías (es decir, cada Nodo tiene 16 sub-Nodos). Esto significa que, en un árbol de tamaño N, una prueba requiere en promedio 32*(16-1)log 16(N) = 120 log 2(N) bytes, o aproximadamente 3840 bytes en un árbol de 2^32 elementos. Para un árbol binario, solo se necesitan 32*(2-1)log 2(N) = 32 log 2(N) bytes, o aproximadamente 1024 bytes.

2. El código no ha sido Merkleizado. Esto significa que para demostrar cualquier acceso a la cuenta de código, se debe proporcionar todo el código, con un máximo de 24000 bytes.

Podemos calcular el peor escenario como sigue:

30000000 gas / 2400 (冷cuenta阅读成本) * （5 * 488 + 24000) = 330000000 字节

El costo de la rama es ligeramente más bajo (reemplazando 5* 480 con 8* 480) porque cuando hay más ramificaciones, su parte superior se repite. Sin embargo, incluso así, la cantidad de datos que se deben descargar en un solo intervalo de tiempo es completamente irreal. Si intentamos encapsularlo con STARK, nos enfrentamos a dos problemas: (i) KECCAK no es tan amigable con STARK; (ii) 330 MB de datos significa que debemos demostrar 5 millones de llamadas a la función de ronda KECCAK, lo que puede ser inalcanzable para todos los dispositivos, excepto los más potentes de consumo, incluso si podemos hacer que STARK demuestre la eficiencia de KECCAK.

Si reemplazamos directamente el árbol binario por el árbol hexadecimal y realizamos un procesamiento adicional de Merkle en el código, entonces en el peor de los casos, aproximadamente se convertirá en 30000000/2400* 32*( 32-14+ 8) = 10400000 bytes (14 es la resta realizada para las posiciones redundantes de 2 ^ 14 ramas, mientras que 8 es la longitud de la prueba para entrar en el bloque de código). Es importante tener en cuenta que esto requerirá cambiar el costo del gas, cobrando por el acceso a cada bloque de código individual; EIP-4762 hace precisamente eso. Una capacidad de 10.4 MB sería mucho mejor, pero para muchos Nodo, todavía sería demasiada información para descargar en un intervalo de tiempo. Por lo tanto, necesitamos introducir tecnologías más potentes. En este sentido, hay dos soluciones líderes: el árbol Verkle y el árbol de hash binario STARKed.

Árbol Verkle

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

Por lo tanto, se demuestra que el tamaño de una sola rama en la prueba se convierte en 32 - 1 og 256(N) = 4* log 2(N) bytes. Por lo tanto, el tamaño teórico máximo de la prueba es aproximadamente 30000000 / 2400 * 32* ( 32 -14 + 8) / 8 = 130000 bytes (debido a la distribución no uniforme del bloque de estado, los resultados reales de los cálculos son ligeramente diferentes, pero es aceptable como una primera aproximación).

Además, es importante tener en cuenta que en todos los ejemplos anteriores, este "peor caso" no es el peor caso: el peor caso sería que un atacante "excave" dos DIRECCIÓN con un prefijo común más largo en el árbol y lea datos de una de las DIRECCIÓN, lo que podría duplicar la longitud de la rama en el peor caso. Pero incluso en este caso, la longitud de prueba de Verkle Tree en el peor caso es de 2.6 MB, lo que es prácticamente igual a la longitud de verificación de datos en el peor caso actual.

Todavía utilizamos esta precaución para hacer otra cosa: hacer que el costo de acceder al espacio de almacenamiento 'adyacente' sea muy bajo: ya sea muchos bloques de código de un contrato similar o ranuras de almacenamiento adyacentes. EIP-4762 proporciona una definición de adyacencia y cobra solo 200 gas por acceso adyacente. En el caso de acceso adyacente, el tamaño de la prueba en el peor de los casos se convierte en 30000000 / 200 * 32 - 4800800 bytes, lo que aún está aproximadamente dentro del rango de tolerancia. Si por seguridad deseamos reducir este valor, podemos aumentar ligeramente el costo del acceso adyacente.

STARKed árbol de hash binario

El principio de esta tecnología es evidente: solo necesitas construir un árbol binario y obtener una prueba de hasta 10.4 MB para demostrar el valor del bloque, luego reemplazar la prueba con una prueba STARK. De esta manera, la prueba en sí misma solo contiene los datos que se están demostrando, además de un gasto fijo de 100-300 kB de STARK real.

El principal desafío aquí es verificar el tiempo. Podemos realizar cálculos muy similares a los anteriores, pero en lugar de calcular bytes, calculamos valores hash. Un Bloquear de 10.4 MB significa 330,000 valores hash. Si consideramos la posibilidad de que un atacante 'excave' en un árbol de DIRECCIÓN con un prefijo público largo, entonces en el peor de los casos tendremos alrededor de 660,000 valores hash. Por lo tanto, si podemos demostrar que los valores hash por segundo son 200,000, entonces no habrá problema.

En las computadoras portátiles de consumo que utilizan la función hash de Poseidon, estos números han alcanzado , y la función hash de Poseidon está diseñada específicamente para la amigabilidad de STARK. Sin embargo, el sistema de Poseidon aún es relativamente inmaduro, por lo que muchas personas no confían en su seguridad. Por lo tanto, existen dos caminos realistas a seguir:

1. Realice un análisis de seguridad exhaustivo de Poseidon de forma rápida y familiarícese lo suficiente para implementarlo en L1.
2. Utilice una función hash más "conservadora", como SHA 256 o BLAKE

Si se quiere demostrar una función hash conservadora, el círculo STARK de Starkware solo puede demostrar 10-30 mil millones de valores hash por segundo en una computadora portátil de consumo en el momento de escribir este artículo. Sin embargo, la tecnología STARK está mejorando rápidamente. Incluso hoy en día, la tecnología basada en GKR también muestra la capacidad de aumentar esta velocidad al rango de 100-200 mil millones.

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

Además de verificar Bloquear, hay otros tres casos de uso clave que requieren una verificación sin estado más eficiente:

• Memoria transaccional: cuando una transacción se difunde, un Nodo en la red P2P debe validar la transacción antes de volver a difundirla. La validación incluye la verificación de la firma, la comprobación del saldo adecuado y la corrección del prefijo. En el futuro (por ejemplo, utilizando la abstracción de cuentas nativas, como EIP-7701), esto puede implicar la ejecución de algún código EVM que realice algunas operaciones de acceso al estado. Si el Nodo es sin estado, la transacción debe estar acompañada de una prueba del objeto de estado.
• Lista de inclusión: Esta es una característica propuesta que permite a los validadores de Prueba de Participación (PoS) forzar la inclusión de transacciones en el próximo bloque, independientemente de la voluntad de los constructores de bloques (que pueden ser de gran escala y complejos). Esto debilitaría la capacidad de los actores con poder para manipular la cadena de bloques mediante la latencia de las transacciones. Sin embargo, esto requiere que los validadores tengan una forma de validar 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 una billetera (como Metamask, Rainbow, Rabby, etc.), necesitarán ejecutar un cliente ligero (como Helios). El módulo central de Helios proporciona a los usuarios una raíz de estado verificada. Y para lograr una experiencia completamente sin confianza, los usuarios deben proporcionar pruebas para cada llamada RPC que realicen (por ejemplo, para las solicitudes de red ETH, los usuarios deben demostrar acceso a todo el estado visitado durante la llamada).

Todos estos casos de uso tienen algo en común: requieren una cantidad considerable de pruebas, pero cada una de ellas es muy pequeña. Por lo tanto, las pruebas STARK no tienen un significado práctico para ellas; en cambio, la práctica más realista es utilizar directamente ramas de Merkle. Otra ventaja de las ramas de Merkle es que son actualizables: dada una prueba del objeto de estado X con raíz en el bloque B, si se recibe un sub-bloque B 2 y su testigo, la prueba se puede actualizar para que tenga como raíz el bloque B 2. Las pruebas Verkle también son nativamente actualizables.

¿Qué conexiones hay con la investigación existente?

• Árboles Verkle
• El artículo original de John Kuszmaul sobre el árbol Verkle
• Starkware
• Poseidon 2 papel
• Ajtai (una función hash alternativa rápida basada en la dureza de la red)
• Verkle.info

¿Qué más se puede hacer?

El resto del trabajo principal es

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

2. Completar y probar más trabajo de transición, esta es la parte principal de la complejidad de cualquier implementación sin nacionalidad.

3. Más análisis de seguridad sobre las funciones hash 'STARK-friendly' de Poseidon, Ajtai y otros

4. Para el desarrollo adicional de la función STARK de alta eficiencia para 'conservar' (o 'tradicional') hash, por ejemplo, basada en la visión de Binius o GKR.

Además, pronto decidiremos entre las siguientes tres opciones: (i) árbol Verkle, (ii) funciones hash amigables STARK y (iii) funciones hash conservadoras. Sus características se pueden resumir aproximadamente en la siguiente tabla:

Además de estos "números de título", hay otros factores importantes a considerar:

• Ahora mismo, el código de los árboles Verkle está bastante maduro. Usar cualquier otro código aparte de Verkle retrasaría la implementación, lo que probablemente retrasaría un hardfork. Esto no es un problema, especialmente si necesitamos más tiempo para analizar funciones hash o implementar validadores, o si hay otras características importantes que queremos incluir en Ethereum antes.
• Actualizar la raíz de estado utilizando valores hash es más rápido que utilizar un árbol Verkle. Esto significa que el método basado en valores hash puede reducir el tiempo de sincronización de un Nodo completo.
• Los árboles Verkle tienen una propiedad interesante de actualización de testigo: los testigos de los árboles Verkle son actualizables. Esta propiedad es útil para la mempool, las listas de inclusión y otros casos de uso, 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 necesidad de leer el contenido de la última capa.
• Verkle hace que la prueba SNARK sea más difícil de realizar. Si queremos reducir el tamaño de la prueba a solo unos pocos miles de bytes, la prueba Verkle presentará algunas dificultades. Esto se debe a que la verificación de la prueba Verkle introduce una gran cantidad de operaciones de 256 bits, lo que requiere que el sistema de prueba tenga o un gran gasto o una estructura interna personalizada que contenga la parte de la prueba Verkle de 256 bits. Esto no es un problema en sí mismo para el estado sin estado, pero presenta más dificultades.

Si queremos lograr la testificabilidad actualizable de Verkle de manera segura y eficiente en términos cuánticos, otra posibilidad es utilizar árboles de Merkle basados en lattice.

Si en el peor de los casos se demostrara que la eficiencia del sistema no es lo suficientemente alta, podríamos recurrir a herramientas inesperadas de gas multidimensional para compensar esta deficiencia: establecer límites de gas separados para (i) calldata; (ii) cálculos; (iii) acceso al estado y posiblemente otros recursos diferentes. El gas multidimensional agrega complejidad, pero como contrapartida, limita más estrictamente la relación entre el caso promedio y el peor de los casos. Con el gas multidimensional, teóricamente el número máximo de ramas que se necesita demostrar puede reducirse de 12500 a, por ejemplo, 3000. Esto haría que BLAKE 3 fuera (apenas) suficiente incluso hoy en día.

El gas multidimensional permite que los límites de recursos de Bloquear estén más cerca de los límites de recursos del hardware subyacente

Otra herramienta inesperada es calcular la latencia del estado raíz hasta el bloque después de la ranura. De esta manera, tenemos 12 segundos completos para calcular el estado raíz, lo que significa que incluso en el caso más extremo, el tiempo de prueba de trabajo de solo 60,000 hashes por segundo es suficiente, lo que nos hace pensar una vez más que BLAKE 3 solo puede cumplir con los requisitos con dificultad.

La desventaja de este método es que aumenta la latencia de un cliente ligero en un intervalo de tiempo, pero también hay técnicas más inteligentes que pueden reducir esta latencia a la generación de la prueba. Por ejemplo, la prueba puede transmitirse inmediatamente en la red después de ser generada en cualquier nodo, en lugar de esperar al siguiente bloque.

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

Resolver el problema sin estado ha aumentado en gran medida la dificultad de la fijación de un solo punto. Si hay tecnología que permita soltar el equilibrio mínimo de un solo punto, como la estrategia Orbit SSF o la Capa de aplicación, como el fijado por equipos, esto se volverá más factible.

Si se introduce EOF al mismo tiempo, el análisis de gas multidimensional se volverá más fácil. Esto se debe a que la complejidad de ejecución principal del gas multidimensional proviene del manejo de las llamadas secundarias que no transmiten todo el gas de la llamada principal, mientras que EOF solo necesita marcar estas llamadas secundarias como ilegales, lo que convierte este problema en algo trivial (y proporcionará una solución alternativa interna para el uso principal actual de gas parcial en el protocolo de la cuenta local).

La validación sin estado y la expiración del historial también tienen una importante sinergia. En la actualidad, los clientes deben almacenar casi 1 TB de datos históricos; estos datos son varias veces más grandes que los datos de estado. Incluso si el cliente está sin estado, el sueño de tener un cliente sin almacenamiento será casi imposible de lograr a menos que podamos liberar al cliente de la responsabilidad de almacenar datos históricos. El primer paso en este sentido es EIP-4444, lo que también significa almacenar datos históricos en torrents o en la red de portales Portal Network.

prueba de validez ejecutada por EVM

¿Qué problema estamos tratando de resolver?

El objetivo a largo plazo de la verificación de Ether Bloquear es muy claro: debería ser capaz de verificar Ether Bloquear de la siguiente manera: (i) descargando Bloquear, o incluso solo una pequeña parte de los datos disponibles en Bloquear; (ii) verificando una pequeña prueba de la validez de Bloquear. Esto sería una operación de recursos extremadamente baja, que se puede realizar en el cliente móvil, en el navegador de Billetera, e incluso en otra cadena (sin la parte de disponibilidad de datos).

Para lograr esto, se requiere una prueba de SNARK o STARK para (i) la capa de consenso (es decir, proof of stake) y (ii) la capa de ejecución (es decir, EVM). El primero en sí mismo es un desafío y debe abordarse en el proceso continuo de mejora de la capa de consenso (por ejemplo, en términos de finalidad de una sola ranura). El último requiere una prueba de ejecución de EVM.

¿Qué es esto y cómo funciona?

A primera vista, 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 un usuario utiliza un cliente ligero, no tiene completamente S y S', ni siquiera E; en su lugar, tienen una raíz de estado anterior R, una raíz de estado posterior R' y un valor hash del bloque H.

• Entrada pública: raíz de estado anterior R, raíz de estado posterior R', hash de bloque H
• Entrada privada: los objetos en los estados accedidos por el cuerpo principal del bloque B, el bloque de programa Q, los mismos objetos después de ejecutar el bloque de programa Q', y la prueba de estado (como la rama de Merkle) P
• Argumento 1: P es una prueba válida que demuestra que Q contiene ciertas partes del estado representado por R.
• Argumento 2: Si STF se ejecuta en Q, (i) el proceso de ejecución solo accede a objetos internos de Q, (ii) los bloques de datos son válidos, (iii) el resultado es Q'.
• Argumento 3: si se recalcula la raíz del estado utilizando la información de Q' y P, se obtendrá R'.

Si existe tal escenario, se puede tener un cliente ligero que valida completamente la ejecución de ETH EVM. Esto hace que los recursos del cliente sean bastante bajos. Para lograr un cliente completo de verificación de ETH, se necesita hacer el mismo trabajo en cuanto al Consenso.

La implementación de prueba de validez para cálculos EVM ya existe y es ampliamente utilizada en L2. Sin embargo, todavía queda mucho trabajo por hacer para que la prueba de validez EVM sea viable en L1.

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

• EFPSE ZK-EVM (discontinued due to better options available)
• Zeth, su funcionamiento consiste en compilar EVM en RISC-0 ZK-VM
• ZK-EVM  Verificación formal项目

¿Qué más se puede hacer?

Actualmente, el sistema de contabilidad electrónica tiene deficiencias en dos aspectos: seguridad y tiempo de verificación.

Una prueba de validez segura debe garantizar que SNARK realmente verifica el cálculo de EVM y no hay vulnerabilidades. Las dos principales tecnologías para mejorar la seguridad son los validadores múltiples y la verificación formal. Los validadores múltiples se refieren a la implementación de pruebas de validez independientes, al igual que con varios clientes, si un Bloquear es demostrado por un subconjunto lo suficientemente grande de estas implementaciones, el cliente aceptará el Bloquear. La verificación formal implica el uso de herramientas comúnmente utilizadas para demostrar teoremas matemáticos, como Lean 4, para demostrar que la prueba de validez solo acepta la ejecución correcta de las especificaciones subyacentes de EVM (como la semántica K de EVM o la especificación de la capa de ejecución de ETH escrita en Python (EELS)).

Un tiempo de verificación lo suficientemente rápido significa que cualquier bloque de la red ETH puede ser verificado en menos de 4 segundos. Hoy en día, todavía estamos lejos de este objetivo, a pesar de que estamos mucho más cerca de lo que imaginábamos hace dos años. Para lograr este objetivo, necesitamos avanzar en tres direcciones:

• La paralelización - Actualmente, el verificador EVM más rápido puede demostrar un bloque de Ethereum en un promedio de 15 segundos. Esto se logra mediante la paralelización entre cientos de GPU y luego consolidando su trabajo al final. En teoría, sabemos completamente cómo construir un verificador EVM que pueda demostrar cálculos en tiempo O(log(N)): haga que un GPU complete cada paso y luego haga un "árbol de agregación":

Hacer esto presenta desafíos. Incluso en el peor de los casos, cuando una transacción muy grande ocupa todo el bloque, no se puede dividir el cálculo por orden de aparición, sino que debe hacerse por código de operación (código de operación de la máquina virtual subyacente como EVM o RISC-V). Garantizar la coherencia de la "memoria" de la máquina virtual entre diferentes partes de la prueba es un desafío clave en la implementación. Sin embargo, si logramos lograr esta prueba recursiva, sabemos que al menos se ha resuelto el problema de latencia del probador, incluso sin mejoras en otros aspectos.

• Optimización del sistema de prueba: los nuevos sistemas de prueba, como Orion, Binius, GRK y otros, probablemente reduzcan significativamente el tiempo de verificación de cálculos generales.
• Otros cambios en el costo de gas de EVM - Muchas cosas en EVM se pueden optimizar para beneficiar a los validadores, especialmente en el peor de los casos. Si un atacante puede construir un Bloquear que bloquee a los validadores durante diez minutos, no será suficiente para demostrar un Bloquear ETH común en solo 4 segundos. Los cambios requeridos en EVM se pueden dividir aproximadamente en las siguientes categorías:

• Cambio en el costo de gas: si una operación tarda mucho tiempo en demostrarse, incluso si su velocidad de cálculo es relativamente rápida, debería tener un alto costo de gas. EIP-7667 es un EIP propuesto para abordar este problema grave: aumenta significativamente el costo de gas de las funciones hash (tradicionales) porque los códigos de operación y las precompilaciones de estas funciones son relativamente baratos. Para compensar este aumento en el costo de gas, podemos soltar el costo de gas de los códigos de operación de EVM que tienen un costo de demostración relativamente bajo, manteniendo así el rendimiento promedio.

• Reemplazo de la estructura de datos: Además de reemplazar el árbol de estado con un enfoque más amigable para STARK, también necesitamos reemplazar la lista de transacciones, el árbol de recibos y otras estructuras costosas de probar. El traslado de la estructura de transacciones y recibos a SSZ por parte de Etan Kissling es un paso en esta dirección.

Además, los dos instrumentos mencionados en la sección anterior (gas multidimensional y la raíz del estado de latencia) también pueden ayudar en este aspecto. Sin embargo, es importante tener en cuenta que, a diferencia de la verificación sin estado, el uso de estos dos instrumentos implica que ya tenemos la tecnología suficiente para completar el trabajo actual, y aunque con esta tecnología la verificación completa de ZK-EVM también requeriría más trabajo, simplemente requeriría menos trabajo.

Un punto que no se mencionó anteriormente es el hardware del generador de pruebas: el uso de GPU, FPGA y ASIC genera pruebas más rápidas. Fabric Cryptography, Cysic y Accseal son tres compañías que han avanzado en este aspecto. Esto es muy valioso para L2, pero es poco probable que sea un factor decisivo para L1, ya que la descentralización es muy importante y esto significa que la generación de pruebas debe estar dentro del rango razonable de los usuarios de la plataforma Ethereum, y no estar limitada por el hardware de una única empresa. L2 puede hacer consideraciones más positivas.

En estos campos, todavía hay mucho trabajo por hacer:

• La prueba de paralelización requiere que las diferentes partes del sistema puedan "compartir memoria" (como una tabla de búsqueda). Sabemos cómo hacerlo, pero necesita ser implementado.
• Necesitamos realizar más análisis para encontrar el conjunto ideal de cambios en el costo del gas para minimizar al máximo el tiempo de verificación en el peor de los casos.
• Necesitamos hacer más trabajo en el sistema de pruebas

El posible costo es:

• Seguridad y tiempo de validador: si se elige una función hash más agresiva, un sistema de prueba más complejo o suposiciones de seguridad más agresivas u otros esquemas de diseño, es posible acortar el tiempo del validador.
• Descentralización y tiempo de los validadores: ¿La comunidad necesita llegar a un acuerdo sobre las "especificaciones" del hardware del validador específico? ¿Los validadores deben ser entidades de gran escala? ¿Esperamos que una computadora portátil de consumo de alta gama pueda validar un bloque de la cadena de bloques ETH en 4 segundos? ¿Está en algún punto intermedio?
• El grado de ruptura de la compatibilidad hacia atrás: otras deficiencias pueden ser compensadas mediante cambios más activos en el costo del gas, pero es más probable que esto aumente desproporcionadamente los costos de ciertas aplicaciones, obligando a los desarrolladores a reescribir y redeploy el código para mantener la viabilidad económica. Del mismo modo, estas dos herramientas también tienen su propia complejidad y desventajas.

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

Las tecnologías clave necesarias para implementar L1 EVM prueba de validez comparten en gran medida con otros dos campos:

• La prueba de validez de L2 (también conocida como "ZK rollup")
• Método de prueba de hash binario "STARK" sin estado

Al lograr la prueba de validez en L1, se puede lograr fácilmente un stake individual: incluso el ordenador más débil (incluyendo teléfonos móviles o relojes inteligentes) puede stake. Esto mejora aún más el valor de superar otras limitaciones para el stake individual (como el límite mínimo de 32 ETH).

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

Consenso的prueba de validez

¿Qué problema estamos tratando de resolver?

Si queremos verificar completamente un bloque de Ethereum usando SNARK, la ejecución de EVM no es la única parte que debemos demostrar. También debemos demostrar el Consenso, es decir, la parte del sistema que maneja los depósitos, retiros, firmas, actualizaciones de saldo del validador y otros elementos de la Prueba de participación de Ethereum.

Consenso es mucho más simple que EVM, pero el desafío al que se enfrenta es que no tenemos convoluciones L2 EVM, por lo que de todas formas, la mayor parte del trabajo debe completarse. Por lo tanto, cualquier implementación de Consenso Ethereum necesita ser construida "desde cero", a pesar de que el sistema de consenso en sí puede ser compartido.

¿Qué es y cómo funciona?

La cadena de balizas se define como una función de transición de estado, al igual que EVM. La función de transición de estado consta principalmente de tres partes:

• ECADD（用于验证 BLS 签名）
• Pareja (utilizado para verificar la firma BLS)
• Valor de hash SHA 256 (utilizado para leer y actualizar el estado)

En cada bloque, necesitamos probar 1-16 BLS 12-381 ECADDs para cada validador (puede haber más de uno, ya que las firmas pueden estar contenidas en múltiples colecciones). Esto se puede compensar mediante técnicas de precálculo de subconjuntos, por lo que podemos decir que cada validador solo necesita probar un BLS 12-381 ECADD. Actualmente, hay 30.000 firmas de validador por ranura. En el futuro, esto podría cambiar en dos direcciones a medida que se logre la finalidad de una sola ranura: si tomamos la ruta de la "fuerza bruta", el número de validadores por ranura podría aumentar a 1 millón. Al mismo tiempo, si se adopta Orbit SSF, el número de validadores se mantendrá en 32.768 o incluso disminuirá a 8.192.

Cómo funciona BLS Aggregation: La firma total de verificación solo requiere un ECADD de cada participante en lugar de un ECMUL. Sin embargo, 30000 ECADD sigue siendo una cantidad considerable de pruebas.

En cuanto a la emparejamiento, actualmente hay un máximo de 128 pruebas por ranura, lo que significa que se necesita verificar 128 emparejamientos. Con ElP-7549 y modificaciones posteriores, cada ranura se puede reducir a 16. La cantidad de emparejamientos es pequeña, pero el costo es extremadamente alto: el tiempo de ejecución (o prueba) de cada emparejamiento es varias veces más largo que el de ECADD.

Una de las principales dificultades para demostrar la operación BLS 12-381 es que no existe una curva de orden igual al tamaño del campo BLS 12-381, lo que implica un gran costo para cualquier sistema de demostración. Por otro lado, el árbol Verkle propuesto para Ethereum se construye con la curva Bandersnatch, lo que convierte al BLS 12-381 en una curva autónoma utilizada en el sistema SNARK para demostrar ramas Verkle. Una implementación relativamente simple puede demostrar 100 G1 de sumas por segundo; para lograr una velocidad de demostración suficientemente rápida, probablemente se necesitarán técnicas inteligentes como GKR.

Para el valor hash SHA 256, el peor escenario actual es la conversión de bloques de época, donde se actualizará todo el árbol de equilibrio corto del validador y una gran cantidad de equilibrio de validadores. El árbol de equilibrio corto de cada validador tiene solo un byte, por lo que se volverá a calcular el hash de 1 MB de datos. Esto equivale a 32768 llamadas de hash SHA 256. Si hay mil validadores cuyo saldo esté por encima o por debajo de un umbral, se debe actualizar el saldo válido en los registros de los validadores, lo que equivale a mil ramas de Merkle, por lo que puede requerir diez mil valores hash. El mecanismo de barajado requiere 90 Bit por validador (por lo tanto, requiere 11 MB de datos), pero esto se puede calcular en cualquier momento de una época. En el caso de la finalización de una única ranura, estos números pueden variar según las circunstancias específicas. El barajado se vuelve innecesario, aunque Orbit puede recuperar en cierta medida esta necesidad.

Otro desafío es la necesidad de volver a obtener el estado de todos los validadores, incluida la llave pública, para poder verificar un bloque. Para 1 millón de validadores, solo la lectura de la llave pública requeriría 48 millones de bytes, además de las ramas de Merkle. Esto requeriría millones de valores hash en cada epoch. Si tenemos que demostrar la validez de PoS, un enfoque realista es algún tipo de cálculo verificable incremental: almacenar una estructura de datos separada en la memoria del sistema de prueba, optimizada para búsquedas eficientes y demostrar actualizaciones en esa estructura.

En resumen, hay muchos desafíos. Para abordar estos desafíos de la manera más efectiva, es probable que sea necesario realizar una reestructuración profunda de la cadena de beacons, posiblemente en conjunto con la transición hacia un final de ranura única. Las características de esta reestructuración pueden incluir:

• Cambios en la función hash: Ahora se utiliza la función hash SHA 256 "completa", por lo que, debido al relleno, cada llamada requiere dos llamadas de función de compresión subyacente. Si usamos la función de compresión SHA 256, al menos podríamos obtener el doble de beneficios. Si usamos Poseidón, podríamos obtener hasta 100 veces más ganancias, lo que resolvería por completo todos nuestros problemas (al menos en lo que respecta al valor hash): verificar incluso un millón de registros de forma rápida, con 1.7 millones de valores hash por segundo (54 MB), podríamos obtener la prueba en segundos.
• Si es Orbit, almacene directamente los registros de validadores barajados: si elige un número fijo de validadores (como 8192 o 32768) como comité para una ranura dada, colóquelos directamente en el estado junto a cada uno, de modo que se pueda leer la clave pública de todos los validadores en la prueba con el mínimo de hash. Esto también puede completar eficientemente todas las actualizaciones de equilibrio.
• Agregación de firmas: Cualquier esquema de agregación de firmas de alto rendimiento implicará alguna forma de prueba recursiva, donde diferentes Nodos en la red realizarán pruebas intermedias en subconjuntos de firmas. Esto naturalmente distribuye el trabajo de prueba entre múltiples Nodos en la red, reduciendo significativamente la carga de trabajo del "probador final".
• Otros esquemas de firma: para Lamport+ Merkle firma, necesitamos 256 + 32 valores hash para verificar la firma; multiplicado por 32768 firmantes, obtenemos 9437184 valores hash. Después de optimizar el esquema de firma, este resultado puede mejorarse aún más mediante un pequeño factor constante. Si usamos Poseidon, esto puede ser demostrado dentro de una sola ranura. Sin embargo, en realidad, el esquema de agregación recursiva será más rápido.

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

• Prueba de Consenso de Ethereum (solo para comités sincronizados)
• Helios dentro de SP 1 Concise
• Compilación previa BLS 12-381 concisa
• Verificación de firma de conjunto BLS basada en Halo 2

¿Qué otros trabajos quedan por hacer y cómo decidir cuáles hacer y cuáles no?

De hecho, necesitamos varios años para obtener una prueba de validez de Consenso ETH, lo que es aproximadamente el mismo tiempo que necesitamos para lograr la finalidad de una sola ranura, Orbit, modificar el algoritmo de firma y realizar un análisis de seguridad, que requiere suficiente confianza para utilizar funciones de hash "agresivas " como Poseidon. Por lo tanto, la opción más sabia es abordar estos otros problemas y considerar la amigabilidad de STARK al mismo tiempo.

La principal consideración probablemente esté en el orden de las operaciones, entre un enfoque más gradual en la reforma de la capa de consenso de Ethereum y un enfoque más radical de "cambiar muchas cosas a la vez". Para EVM, el enfoque gradual es razonable, ya que minimiza las interferencias con la compatibilidad hacia atrás. Para la capa de consenso, el impacto en la compatibilidad hacia atrás es menor, y también tiene sus ventajas repensar de manera más "integral" los diversos detalles de la construcción de la beacon chain para optimizar la amigabilidad con SNARK de la mejor manera posible.

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

Al realizar una revisión a largo plazo de la PoS de Ether, la amigabilidad de STARK debe ser la consideración principal, especialmente en lo que respecta a la finalidad de una sola ranura, la órbita, los cambios en el esquema de firmas y la agregación de firmas.