Lectura previa: "Vitalik sobre el posible futuro de Ethereum (1): La Fusión", "Vitalik sobre el posible futuro de Ethereum (2): El Auge", "Vitalik sobre el posible futuro de Ethereum (3): El Azote"

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

Una de las funciones más poderosas de la cadena Bloquear es que cualquiera puede ejecutar un Nodo en su propia computadora y verificar la corrección de la cadena Bloquear. Incluso si 9596 Nodos que ejecutan Consenso de la cadena (PoW, PoS) acuerdan inmediatamente cambiar las reglas y comienzan a producir Bloquear de acuerdo con las nuevas reglas, cualquier persona que ejecute un Nodo de verificación completa rechazará la cadena. Los acuñadores que no formen parte de este grupo conspirador se agruparán automáticamente en una on-chain que continúe siguiendo las reglas antiguas y seguirá construyendo esta cadena, y los usuarios completamente verificados seguirán esta cadena.

Esta es la diferencia clave entre la cadena de bloques y los 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 promotores (ya que si no verifican la cadena, no están contribuyendo a la aplicación de las reglas 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 bastante difícil. The Verge busca cambiar esta situación al hacer que el costo computacional de la verificación completa de la cadena sea más accesible, de modo que cada billetera de teléfono, 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 transferir el estado de almacenamiento de ETH a un árbol Verkle, una estructura de árbol que permite pruebas más compactas y verificación sin estado de bloques de ETH, Nodo puede verificar un bloque de ETH sin necesidad de almacenar ningún estado de ETH (saldo de la cuenta, código de contrato, espacio de almacenamiento, etc.) en su disco, a costa de unos cientos de KB de datos de prueba y unos cientos de milisegundos de tiempo adicional 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 ETH, que incluye no solo la tecnología de verificación sin estado, sino también la verificación de SNARK para todas las ejecuciones de ETH.

Además del seguimiento a largo plazo para la validación SNARK de toda la cadena, otra nueva pregunta tiene que ver con si el árbol de Verkle es la mejor técnica. El árbol Verkle es vulnerable a la Computadora cuántica, por lo que si tomamos el árbol Verkle en el árbol actual KECCAK Merkle Patricia, tendremos que reemplazar el árbol nuevamente en el futuro. Una alternativa a un árbol de Merkle es simplemente omitir el STARK que usa la rama de Merkle y ponerlo en un árbol binario. Históricamente, este enfoque se ha considerado inviable debido a los gastos generales y la complejidad técnica. Recientemente, sin embargo, hemos visto a Starkware probar 1,7 millones de hashes de Poseidón por segundo utilizando ckcle STARKs en un solo portátil, y el tiempo de prueba para los valores de hash más "tradicionales" está disminuyendo rápidamente gracias a tecnologías como GKB. Entonces, durante el último año, "Verge" se ha vuelto más abierto, tiene varias posibilidades.

The Verge: objetivo clave

· Cliente sin estado: El espacio de almacenamiento requerido para la validación completa del cliente y la marca Nodo no debe superar varios GB.

· (A largo plazo) Validar completamente la cadena en el reloj inteligente (Consenso y ejecución). Descargar algunos datos, verificar SNARK, completado.

En este capítulo

· Cliente sin estado: Verkle o STARKs

· EVM ejecuta la prueba de validez

·  Consenso的prueba de validez

Verkle o STARKs: Verificación sin estado

¿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 en 30 GB cada año, y cada cliente individual debe almacenar algunos datos adicionales sobre él para actualizar eficientemente las ternas.

Esto reduce la cantidad de usuarios que pueden ejecutar un Nodo de Ethereum completa: aunque hay suficiente espacio en disco duro en todas partes para almacenar todos los estados de Ethereum e incluso la historia de varios años, las computadoras que la gente compra por defecto a menudo tienen solo unos pocos cientos de gigabytes de espacio de almacenamiento. El tamaño del estado también ha introducido una gran fricción en el proceso de configuración inicial de un Nodo: el Nodo necesita descargar todo el estado, lo cual puede llevar horas o incluso días. Esto tiene diversas consecuencias. Por ejemplo, aumenta en gran medida la dificultad para que los creadores de Nodos actualicen su configuración de Nodo. Técnicamente, se puede realizar una actualización sin apagar el sistema, iniciando un nuevo cliente, esperando a que se sincronice y luego cerrando el cliente anterior y transfiriendo 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 los Bloques sin tener acceso al estado completo. En su lugar, cada Bloque viene con un testigo que incluye: (i) el valor, el código, el saldo y el almacenamiento de posiciones específicas en el estado al que el Bloque accederá; (ii) una prueba de encriptación que demuestra que estos valores son correctos.

De hecho, lograr una verificación sin estado requiere cambiar la estructura del árbol de estado de Ethereum. Esto se debe a que el árbol de Merkle Patricia actual es extremadamente hostil para implementar cualquier esquema de encriptación, especialmente en el peor de los casos. Tanto las ramas de Merblk "originales" como las posibilidades de "empaquetar" en STARK son problemáticas. La dificultad principal proviene de algunas debilidades de MPT:

1. Este es un árbol de 6 vías (es decir, cada Nodo tiene 16 subnodos). Esto significa que en un árbol de tamaño N, una prueba promedio requiere aproximadamente 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 requieren aproximadamente 32*(2-1)log2(N) = 32 log2(N) bytes, o alrededor de 1024 bytes.

2. El código no ha sido Merkle-izado. 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 de los casos como sigue:

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

El costo de la rama es ligeramente menor (reemplazando 5*480 con 8*480), ya que cuando hay muchas ramas, la parte superior se repite. Pero aun así, la cantidad de datos a descargar en un intervalo de tiempo es completamente irreal. Si intentamos encapsularlo con STARK, nos enfrentaremos a dos problemas: (i) KECCAK no es tan amigable con STARK; (ii) 330MB de datos significa que debemos demostrar 5 millones de llamadas a la función de ronda KECCAK, lo que puede ser imposible para cualquier hardware que no sea el más potente de consumo, incluso si logramos que STARK pruebe que la eficiencia de KECCAK es mayor.

Si reemplazamos directamente el árbol hexadecimal con un árbol binario y hacemos un procesamiento de Merkle adicional en el código, entonces el peor de los casos sería aproximadamente 30000000/2400*32*(32-14+8) = 10400000 bytes (14 es la resta de los bits redundantes de la rama 2^14, y 8 es la longitud de la prueba que entra en la hoja del bloque de código). Es importante tener en cuenta que esto requiere un cambio en los costos de gas para cobrar por acceder a cada bloque de código individual; EIP-4762 hace precisamente eso. 10,4 MB es mucho mejor, pero para muchos Nodo, descargar demasiados datos en una sola franja horaria sigue siendo demasiado. Por lo tanto, necesitamos introducir tecnologías más potentes. En este sentido, hay dos soluciones líderes: el árbol Verkle y el árbol hash binario STARKed.

Árbol Verkle

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

Por lo tanto, el tamaño de una sola rama en la prueba se convierte en 32 - 1og256(N) = 4* log2(N) bytes. Por lo tanto, el tamaño máximo teórico de la prueba es aproximadamente 30000000 / 2400 *32* (32 -14 + 8) / 8 = 130000 bytes (debido a la distribución desigual de los bloques de estado, los resultados reales de cálculo son ligeramente diferentes, pero como primera aproximación, está bien).

Además, tenga en cuenta que en todos los ejemplos anteriores, este "peor caso" no es el peor caso: un caso peor es cuando un atacante "mina" intencionalmente dos DIRECCIÓN con un prefijo común más largo en el árbol y lee datos de una de las DIRECCIÓN, lo que podría aumentar la longitud de la rama en el peor caso en un factor de 2. Pero incluso en este caso, la longitud de prueba del árbol Verkle es de 2.6MB, que es prácticamente igual a los datos de verificación en el peor caso actual.

También hemos hecho algo con esta precaución: hemos hecho que el costo de acceder al espacio de almacenamiento 'adyacente' sea muy bajo: ya sea muchos bloques de código del mismo contrato o ranuras de almacenamiento adyacentes. EIP-4762 proporciona una definición de adyacencia y cobra una tarifa de 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 sigue estando dentro del rango de tolerancia. Si por seguridad deseamos reducir este valor, podemos aumentar ligeramente el costo de acceso adyacente.

STARKed árbol de hash binario

El principio de esta tecnología es evidente por sí mismo: simplemente debes crear un árbol binario, obtener una prueba de hasta 10.4 MB que demuestre los valores en el bloque y luego reemplazar la prueba con STARK. De esta manera, la prueba solo contendrá los datos que se deben demostrar, junto con un gasto fijo de 100-300kB proveniente de STARK real.

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

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

1. Rápidamente realizar un análisis de seguridad exhaustivo de Poseidon y familiarizarse lo suficiente con él para implementarlo en L1

2. Usar una función de hash más "conservadora", como SHA256 o BLAKE

Si desea demostrar una función hash conservadora, el círculo STARK de Starkware solo puede demostrar 10-30k valores hash por segundo en una computadora portátil de consumo al 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-2O0k.

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

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

· Memoria de transacciones: Cuando se difunde una transacción en la red P2P, el Nodo necesita verificar si la transacción es válida antes de volver a difundirla. La verificación incluye la validación de la firma, el chequeo del saldo y la comprobación del prefijo correcto. En el futuro (por ejemplo, mediante la abstracción de cuenta nativa, como EIP-7701), esto puede implicar la ejecución de algún código EVM que realice algunos accesos de estado. Si el Nodo es sin estado, la transacción debe incluir una prueba del objeto de estado.

· Incluir lista: Esta es una característica propuesta que permite que los validadores (posiblemente a pequeña escala y no tan complicados) obliguen a que el próximo bloque contenga transacciones, independientemente de la voluntad de los constructores de bloques (posiblemente a gran escala y complicados). Esto debilitará la capacidad de los poderosos para manipular la cadena de bloques a través de la latencia de transacción. Sin embargo, esto requiere que los validadores tengan la capacidad de verificar la validez de las transacciones incluidas en la lista.

· cliente ligero: Si queremos que los usuarios accedan a la cadena a través de una billetera (como Metamask, Rainbow, Rabby, etc.), necesitan ejecutar un cliente ligero (como Helios). El módulo principal de Helios proporciona una raíz de estado verificada para los usuarios. Sin embargo, para obtener una experiencia completamente sin confianza, los usuarios necesitan proporcionar pruebas para cada llamada RPC que realizan (por ejemplo, para una solicitud de llamada ETH, deben demostrar todos los estados a los que acceden durante la llamada).

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

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

· Árboles Verkle

· El documento original de John Kuszmaul sobre el árbol Verkle

· Starkware

· Papel Poseidon2

· Ajtai (una función hash rápida alternativa basada en la dureza del retículo)

· 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 (cambios en el costo de gas sin estado)

2. Completar y probar más trabajo en el programa de transición, que es la parte principal de la complejidad de cualquier plan de implementación sin nacionalidad.

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

4. Para desarrollar aún más la función STARK altamente eficiente para 'conservar' (o 'tradicional') hash, por ejemplo, basada en las perspectivas de Binius o GKR.

Además, pronto decidiremos elegir una de las siguientes tres opciones: (i) Árboles Verkle, (ii) Funciones hash amigables con 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 tener en cuenta:

· Ahora, el código del árbol Verkle ya es bastante maduro. Aparte de Verkle, el uso de cualquier otro código retrasaría la implementación, posiblemente incluso un fork duro. Esto no importa, especialmente si necesitamos tiempo adicional para el análisis de hash o la implementación del validador, o si hay otras funciones importantes que queremos incluir más temprano en Ethereum.

· El uso de valores hash para actualizar la raíz del estado es más rápido que el uso del árbol Verkle. Esto significa que el método basado en valores hash puede reducir el tiempo de sincronización de los Nodos completos.

· El árbol Verkle tiene propiedades interesantes de actualización de testigos: los testigos del árbol Verkle son actualizables. Esta propiedad es útil para mempool, listas de inclusión y otros casos de uso, y también puede ayudar a mejorar la eficiencia de la implementación: si se actualiza el objeto de estado, se puede actualizar el testigo de la segunda capa desde el fondo, sin necesidad de leer el contenido de la última capa.

· Verkle trees are more difficult to perform SNARK proofs on. If we want to reduce the proof size to a few kilobytes, Verkle proofs will bring some difficulties. This is because the verification of Verkle proofs introduces a large number of 256-bit operations, which requires either a significant overhead in the proof system or a customized internal structure that includes a 256-bit Verkle proof section. This is not a problem for statelessness itself, but it brings more difficulties.

Si queremos obtener la actualización de Verkle de manera segura, eficiente y razonablemente con seguridad cuántica, otra posibilidad sería a través del árbol de Merkle basado en retícula.

Si en el peor de los casos se demuestra que la eficiencia del sistema no es lo suficientemente alta, aún podemos 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 diversos. El gas multidimensional agrega complejidad, pero a cambio, limita más estrictamente la relación entre el caso promedio y el peor caso. Con el gas multidimensional, teóricamente el número máximo de ramas que se deben demostrar podría reducirse de 12,500 a, por ejemplo, 3,000. Esto haría que BLAKE3 sea (apenas) suficiente incluso hoy en día.

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

Otra herramienta inesperada es calcular la latencia del estado raíz hasta el intervalo posterior de Bloquear. De esta manera, tenemos un total de 12 segundos para calcular el estado raíz, lo que significa que incluso en las situaciones más extremas, el tiempo de prueba de 60000 hashes por segundo es suficiente, lo que nos hace pensar una vez más que BLAKE3 solo puede cumplir con los requisitos de forma precaria.

La desventaja de este método es que aumentará la latencia de un intervalo de tiempo de cliente ligerolatencia, pero también hay técnicas más ingeniosas que pueden reducir esta latencia a solo la generación de latencia de prueba. Por ejemplo, la prueba puede ser transmitida inmediatamente en la red después de ser generada en cualquier Nodo, en lugar de esperar al siguiente Bloquear.

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

Resolver el problema de estado cero aumenta significativamente la dificultad de equilibrar un solo punto. Si hay tecnología para soltar el equilibrio mínimo de un solo punto, como la estrategia Orbit SSF o Capa de aplicación, como el equipo de punto de referencia, esto se volverá más factible.

Si se introduce EOF al mismo tiempo, el análisis de gas multidimensional será más fácil. Esto se debe a que la 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, y EOF solo necesita marcar estas llamadas secundarias como inválidas para hacer que este problema sea insignificante (y la abstracción de la cuenta local proporcionará un protocolo interno alternativo para el uso principal actual de gas).

La validación sin estado y la expiración del historial tienen una interacción importante. Hoy en día, los clientes deben almacenar cerca de 1TB de datos históricos; estos datos son múltiples veces los datos de estado. Incluso si el cliente es sin estado, el sueño casi imposible de no almacenar clientes no podrá realizarse 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 el Portal Network del sitio web del portal.

prueba de validez ejecutada por EVM

¿Qué problema estamos tratando de resolver?

El objetivo a largo plazo de la verificación de Bloquear ETH es claro: (i) descargar Bloquear o incluso solo una pequeña muestra de disponibilidad de datos en Bloquear; (ii) verificar una pequeña prueba de validez de Bloquear. Esta será una operación de bajo consumo de recursos que se puede realizar en dispositivos móviles, navegadores o incluso en otra cadena (sin una parte de disponibilidad de datos).

Para lograr esto, se requiere la prueba de SNARK o STARK para (i) la capa de consenso (es decir, Prueba de participación) y (ii) la capa de ejecución (es decir, EVM). El primero es un desafío en sí mismo 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 segundo requiere una prueba de ejecución de EVM.

¿Qué es y cómo funciona?

Desde un punto de vista formal, en la especificación de Ethereum, la Máquina Virtual 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 está utilizando un cliente ligero, no poseen completamente S y S', e incluso E; en cambio, tienen una raíz de estado anterior R, una raíz de estado posterior R' y un valor hash de bloque.

· Entrada pública: raíz del estado anterior R, raíz del estado posterior R', hash del bloque H

· Entrada privada: objetos en el estado accedido por el cuerpo principal del bloque B, objetos idénticos después de ejecutar el bloque Q', y prueba de estado (como la rama Merkle) P.

· La afirmación 1: P es una prueba válida de que Q contiene algunas partes del estado representado por R

· La afirmación 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'

· La afirmación 3: si se recalculara la raíz del estado con la información de Q' y P, se obtendría R'

Si existe esta situación, se puede tener un cliente ligero que ejecute completamente la EVM de ETH. Esto hace que los recursos del cliente sean bastante bajos. Para lograr un cliente completo de ETH validado, también 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 hay mucho trabajo por hacer para que la prueba de validez EVM sea viable en L1.

¿Cuáles son las conexiones con investigaciones existentes?

· EFPSE ZK-EVM (discontinued due to better alternatives)

· Zeth, su funcionamiento consiste en compilar EVM en RISC-0 ZK-VM

· ZK-EVM proyecto de 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.

Un prueba de validez seguro garantiza que SNARK verifica correctamente el cálculo de EVM y no hay vulnerabilidades. Las dos principales tecnologías para mejorar la seguridad son múltiples validadores y validación formal. Los múltiples validadores se refieren a múltiples implementaciones independientes de prueba de validez, al igual que múltiples clientes, si un Bloquear es probado por un subconjunto lo suficientemente grande de estas implementaciones, el cliente aceptará el Bloquear. La validación formal implica el uso de herramientas comúnmente utilizadas para demostrar teoremas matemáticos, como Lean4, para demostrar que la prueba de validez solo acepta una ejecución correcta de las especificaciones subyacentes de EVM (por ejemplo, semántica EVM K o 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 muy lejos de este objetivo, aunque estamos mucho más cerca de lo que imaginábamos hace dos años. Para lograr este objetivo, necesitamos progresar en tres direcciones:

· La paralelización: el verificador EVM más rápido actual puede demostrar un bloque 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 perfectamente cómo construir un verificador EVM que pueda demostrar cálculos en tiempo O(log(N)): haga que una GPU realice cada paso y luego cree un 'árbol de agregación'.

Lograr esto presenta desafíos. Incluso en el peor de los casos, cuando una transacción muy grande ocupa todo el bloque, la división del cálculo no puede realizarse por bloques, sino que debe hacerse por códigos de operación (códigos de operación de la Máquina Virtual subyacente, como EVM o RISC-V). Garantizar la consistencia de la "memoria" de la Máquina Virtual entre las diferentes partes de la prueba es un desafío clave en el proceso de implementación. Sin embargo, si podemos lograr esta prueba recursiva, sabemos que, incluso si no hay mejoras en otros aspectos, al menos se habrá resuelto el problema de latencia del verificador.

· Mejora del sistema de prueba: el nuevo sistema de prueba, como Orion, Binius, GRK y más, probablemente vuelva a reducir significativamente el tiempo de verificación del cómputo general.

· Otros cambios en el costo del gas EVM - Muchas cosas en EVM pueden optimizarse para hacerlas más favorables a los probadores, especialmente en el peor de los casos. Si un atacante puede construir un bloqueo Bloquear que bloquee a los probadores durante diez minutos, entonces no es suficiente para probar un bloque ETH común en solo 4 segundos. Los cambios necesarios en EVM se pueden dividir aproximadamente en las siguientes categorías:

• Cambio en el costo de gas: si una operación requiere mucho tiempo para ser probada, incluso si su velocidad de cálculo es relativamente rápida, el costo de gas debería ser muy alto. EIP-7667 es un EIP propuesto para abordar este grave problema: aumenta significativamente el costo de gas de las funciones de hash (tradicionales) debido a que los opcodes y precompilaciones de estas funciones son relativamente baratos. Para compensar este aumento en el costo de gas, podemos reducir el costo de gas de los opcodes de la EVM que tienen un costo de prueba más bajo, manteniendo así constante el rendimiento promedio.

• La sustitución de la estructura de datos - además de reemplazar el árbol de estado con un método más amigable para STARK, también necesitamos reemplazar la lista de transacciones, el árbol de recibos y otras estructuras costosas de demostración. El movimiento 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 raíz de estado latencia) también pueden ser útiles 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 significa que ya tenemos la tecnología suficiente para completar el trabajo actual que necesitamos, y aunque el uso de estas tecnologías, la verificación completa de ZK-EVM también requeriría más trabajo, solo que sería menos trabajo.

Un punto que no se mencionó anteriormente es el hardware de generación de pruebas: el uso de GPU, FPGA y ASIC genera pruebas de manera más rápida. Fabric Cryptography, Cysic y Accseal son tres empresas que han progresado en este aspecto. Esto es muy valioso para L2, pero es poco probable que sea un factor decisivo para L1, ya que las personas quieren que L1 mantenga una alta Descentralización, lo que significa que la generación de pruebas debe estar dentro del alcance razonable de los usuarios de Ethereum, y no debe estar limitada por los cuellos de botella del hardware de una sola empresa. L2 puede hacer equilibrios más activos.

En estos campos, hay mucho más trabajo por hacer:

· La prueba de paralelización requiere que las diferentes partes del sistema de prueba puedan "compartir memoria" (como una tabla de búsqueda). Sabemos cómo hacerlo, pero necesita ser implementado.

· Necesitamos realizar un análisis más detallado para encontrar un conjunto ideal de cambios en el costo del gas, con el fin de 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 del 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 diseños, es posible reducir el tiempo del validador.

· Descentralización y tiempo del validador: la comunidad necesita ponerse de acuerdo sobre las 'especificaciones' del hardware del validador en cuestión. ¿Se requiere que el validador sea una entidad a gran escala? ¿Esperamos que una computadora portátil de consumo de alta gama pueda validar un bloque de ETH en 4 segundos? ¿Está en algún punto intermedio?

· El nivel de ruptura de la compatibilidad hacia atrás: las deficiencias en otros aspectos se pueden compensar mediante cambios más activos en el costo del gas, pero esto probablemente aumentaría desproporcionadamente el costo de algunas aplicaciones, obligando a los desarrolladores a reescribir y volver a implementar 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 roadmap?

La tecnología central necesaria para implementar prueba de validez L1 EVM está en gran medida compartida con otros dos campos:

· La prueba de validez de L2 (es decir, "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 la participación individual: incluso la computadora más débil (incluidos teléfonos móviles o relojes inteligentes) puede participar. Esto mejora aún más el valor de superar otras limitaciones de la participación individual (como el requisito mínimo de 32ETH).

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

prueba de validez de Consenso

¿Qué problema estamos tratando de resolver?

Si queremos verificar completamente un bloque de ETH en SNARK, la ejecución de EVM no es la única parte que necesitamos demostrar. También necesitamos demostrar el Consenso, que involucra el manejo de depósitos, retiros, firmas, actualización de saldos de validadores y otros elementos de la Prueba de Participación de ETH.

Consenso es mucho más simple que EVM, pero se enfrenta al desafío de que no tenemos una convolución L2 EVM, por lo que la mayor parte del trabajo debe hacerse de todos modos. Por lo tanto, cualquier implementación de Consenso Ethereum requeriría 'empezar desde cero', aunque el sistema de consenso en sí se puede construir sobre el trabajo 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（utilizado para verificar firmas BLS）

· Par (utilizado para verificar la firma BLS)

· Valor hash SHA256 (utilizado para leer y actualizar el estado)

En cada Bloquear, necesitamos probar 1-16 BLS12-381 ECADDs para cada validador (posiblemente 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 ECADD BLS12-381. 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 verificación de la firma total solo requiere un ECADD por cada participante, en lugar de un ECMUL. Sin embargo, 30000 ECADD sigue siendo una cantidad de prueba considerable.

En cuanto a la emparejamiento, actualmente hay un máximo de 128 pruebas en cada ranura, lo que significa que se necesitan verificar 128 emparejamientos. Con ElP-7549 y modificaciones adicionales, se puede reducir a 16 pruebas por ranura. El número de emparejamientos es escaso, pero el costo es extremadamente alto: el tiempo de ejecución (o prueba) de cada emparejamiento es k veces mayor que ECADD.

Una de las principales dificultades de demostrar operaciones BLS12-381 es la falta de una curva de orden igual al tamaño del campo BLS12-381, lo que añade un gran costo a cualquier sistema de demostración. Por otro lado, el árbol Verkle propuesto para Ethereum se construye con la curva Bandersnatch, lo que hace que BLS12-381 en sí mismo sea una curva autónoma para demostrar ramas Verkle en sistemas SNARK. Una implementación simple puede demostrar la suma de 100 G1 por segundo; para que la velocidad de demostración sea lo suficientemente rápida, casi con certeza se necesitarán tecnologías ingeniosas como GKR.

Para el valor hash SHA256, el peor caso actual es la conversión de la era, se actualizará todo el árbol de equilibrio corto del validador y una gran cantidad de equilibrios de validador. El árbol de equilibrio corto de cada validador tiene solo un byte, por lo que se volverá a calcular el hash para 1 MB de datos. Esto equivale a 32768 llamadas SHA256. Si mil validadores tienen saldos por encima o por debajo de un umbral, será necesario actualizar los saldos válidos en el registro de validadores, lo que equivale a mil ramas de Merkle, por lo que puede ser necesario calcular el valor hash diez mil veces. El mecanismo de barajado requiere 90 Bit por validador (por lo tanto, se necesitan 11 MB de datos), pero esto se puede calcular en cualquier momento de una era. En el caso de la terminación de una sola ranura, estos números pueden aumentar o disminuir según las circunstancias. La barajado puede volverse innecesario, aunque Orbit puede restaurar esta necesidad en cierta medida.

Otro desafío es la necesidad de recuperar todos los estados de los validadores, incluyendo la Llave pública, para poder validar un Bloquear. Para un 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 sería 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 para demostrar actualizaciones en esa estructura.

En resumen, hay muchos desafíos. Para abordar de manera más efectiva estos desafíos, es probable que sea necesario realizar una profunda reconfiguración de la cadena de señales, posiblemente en conjunto con el cambio a la finalización de una sola ranura. Las características de esta reconfiguración pueden incluir:

· Cambios en la función hash: Ahora se utiliza la función hash SHA256 "completa", por lo que cada llamada corresponde a dos llamadas a la función de compresión subyacente debido al relleno. Si usamos la función de compresión SHA256 en su lugar, podemos obtener al menos 2 veces el beneficio. Si cambiamos a Poseidón, podríamos obtener una ganancia de 100x, lo que resuelve todos nuestros problemas (al menos en términos de valor de hash): a 1,7 millones de hashes por segundo (54 MB), incluso un millón de registros de verificación se pueden "leer" en la prueba en cuestión de segundos.

· Si es Orbit, simplemente almacene el registro de validadores reorganizado: si elige un número determinado de validadores (como 8192 o 32768) como comité para una ranura dada, simplemente colóquelos directamente en el estado contiguo entre sí, de modo que solo se necesite el mínimo hash para leer todas las llaves públicas de los validadores en la prueba. Esto también puede completar eficientemente todas las actualizaciones de saldo.

· Agregación de firmas: Cualquier esquema de agregación de firmas de alto rendimiento involucrará alguna forma de prueba recursiva, donde diferentes Nodos en la red realizarán pruebas intermedias en subconjuntos de firmas. Esto naturalmente distribuirá el trabajo de prueba entre varios Nodos de 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, podemos mejorar aún más este resultado mediante un pequeño factor constante. Si usamos Poseidon, se puede demostrar dentro de una sola ranura. Pero en realidad, usar un esquema de agregación recursiva es más rápido.

¿Cuáles son las conexiones con investigaciones existentes?

· Prueba de consenso de Etherium (solo para comités de sincronización)

· Helios dentro de SP1 conciso

· Precompilación concisa BLS12-381

Verificación de firma de conjunto BLS basada en Halo2

¿Qué otros trabajos hay que hacer y cómo hacer la elección?

De hecho, necesitaremos varios años para obtener la prueba de validez de Ether Consenso. Esto 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 hash "agresivas" como Poseidon. Por lo tanto, la estrategia más sensata es abordar estos otros problemas y, al hacerlo, tener en cuenta la amigabilidad de STARK.

La consideración principal probablemente recae en el orden de las operaciones, entre un enfoque más progresivo para reformar la capa de consenso de Ethereum y un enfoque más radical de 'cambiar muchas cosas de una vez'. Para EVM, el enfoque progresivo es razonable ya que minimiza las interferencias con la compatibilidad hacia atrás. Para la capa de consenso, las interferencias con la compatibilidad hacia atrás son menores y hay beneficios en reconsiderar de manera 'completa' 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 reestructuración a largo plazo de PoS en Ethereum, la amigabilidad de STARK debe ser considerada como un factor prioritario, especialmente en lo que respecta a la finalidad de una sola ranura, Orbit, cambios en el esquema de firmas y agregación de firmas.

Enlace al texto original