Introducción: El camino hacia la verificabilidad

La principal ventaja de la Web3 es la verificabilidad: los usuarios pueden verificar cómo funcionan realmente los sistemas. Esta característica explica por qué muchos, tanto dentro como fuera de la industria de las criptomonedas, describen la Web3 como un paso hacia una Internet más transparente y verificable.

A diferencia de las plataformas Web2 como Facebook o Instagram, donde los algoritmos y las reglas siguen siendo opacos incluso cuando están documentados, los protocolos criptográficos están diseñados para ser auditables por completo. Incluso si se comparten, no se tiene la capacidad de verificar si la plataforma funciona según lo especificado. Esto es lo opuesto a las criptomonedas, donde cada protocolo está diseñado para ser lo más auditable posible (o al menos, se espera que lo sea).

Hoy exploraremos “The Verge”, una sección de la serie de seis partes publicada recientemente por Vitalik sobre el futuro de Ethereum , para analizar los pasos que está dando Ethereum para lograr verificabilidad, sostenibilidad y escalabilidad en el futuro. Bajo el título “The Verge”, discutiremos cómo las arquitecturas de blockchain pueden volverse más verificables, las innovaciones que estos cambios traen a nivel de protocolo y cómo brindan a los usuarios un ecosistema más seguro. ¡Comencemos!

¿Qué significa “verificabilidad”?

Las aplicaciones Web2 funcionan como "cajas negras": los usuarios solo pueden ver sus entradas y las salidas resultantes, sin visibilidad sobre cómo funciona realmente la aplicación. En cambio, los protocolos de criptomonedas suelen poner a disposición del público su código fuente, o al menos tienen planes de hacerlo. Esta transparencia tiene dos propósitos: permite a los usuarios interactuar directamente con el código del protocolo si así lo desean, y les ayuda a comprender exactamente cómo funciona el sistema y qué reglas lo rigen.

“Descentraliza lo que puedas, verifica el resto”.

La verificabilidad garantiza que los sistemas sean responsables y, en muchos casos, garantiza que los protocolos funcionen como se espera. Este principio destaca la importancia de minimizar la centralización, ya que a menudo conduce a estructuras opacas e irresponsables en las que los usuarios no pueden verificar las operaciones. En cambio, deberíamos esforzarnos por descentralizar lo más posible y hacer que los elementos restantes sean verificables y responsables en los casos en que la descentralización no sea factible.

La comunidad Ethereum parece estar de acuerdo con esta perspectiva, ya que la hoja de ruta incluye un hito (llamado "The Verge") cuyo objetivo es hacer que Ethereum sea más verificable. Sin embargo, antes de sumergirnos en The Verge, debemos comprender qué aspectos de las cadenas de bloques deben verificarse y qué partes son cruciales desde la perspectiva de los usuarios.

Las cadenas de bloques funcionan básicamente como relojes globales. En una red distribuida con alrededor de 10.000 computadoras, puede llevar una cantidad significativa de tiempo que una transacción se propague desde el nodo de origen a todos los demás nodos. Por este motivo, los nodos de la red no pueden determinar el orden exacto de las transacciones (si una llegó antes o después de otra), ya que solo tienen sus propias perspectivas subjetivas.

Debido a que el orden de las transacciones es importante, las redes blockchain utilizan métodos especializados llamados “ algoritmos de consenso ” para garantizar que los nodos permanezcan sincronizados y procesen las secuencias de transacciones en el mismo orden. Aunque los nodos no pueden determinar el orden de las transacciones a nivel global, los mecanismos de consenso permiten que todos los nodos se pongan de acuerdo sobre la misma secuencia, lo que permite que la red funcione como una única computadora cohesionada.

Más allá de la capa de consenso, también existe la capa de ejecución que existe en cada blockchain. La capa de ejecución está determinada por las transacciones que los usuarios quieren ejecutar. Una vez que las transacciones se han ordenado con éxito por consenso, cada transacción debe aplicarse al estado actual en la capa de ejecución. Si se pregunta "¿Cuál es el estado?", probablemente haya visto las cadenas de bloques comparadas con bases de datos, o más específicamente, con la base de datos de un banco porque las cadenas de bloques, al igual que los bancos, mantienen un registro de los saldos de todos.

Si tienes $100 en el estado que llamamos "S" y quieres enviar $10 a otra persona, tu saldo en el siguiente estado, "S+1", será de $90. Este proceso de aplicar transacciones para pasar de un estado a otro es lo que llamamos una STF (Función de Transición de Estado) .

En Bitcoin, el STF se limita principalmente a los cambios de saldo, lo que lo hace relativamente simple. Sin embargo, a diferencia de Bitcoin, el STF de Ethereum es mucho más complejo porque Ethereum es una cadena de bloques totalmente programable con una capa de ejecución capaz de ejecutar código.

En una cadena de bloques, hay tres componentes fundamentales que necesitas (o puedes) verificar:

1. Estado : es posible que desee leer un fragmento de datos en la cadena de bloques, pero no tenga acceso al estado porque no ejecuta un nodo completo . Por lo tanto, solicita los datos a través de un proveedor de RPC (llamada a procedimiento remoto) como Alchemy o Infura. Sin embargo, debe verificar que el proveedor de RPC no haya alterado los datos.
2. Ejecución : como se mencionó anteriormente, las cadenas de bloques utilizan un STF. Debe verificar que la transición de estado se haya ejecutado correctamente, no por transacción, sino bloque por bloque.
3. Consenso : entidades de terceros, como las RPC, pueden proporcionarle bloques válidos que aún no se han incluido en la cadena de bloques. Por lo tanto, debe verificar que estos bloques hayan sido aceptados a través del consenso y agregados a la cadena de bloques.

I

Si esto parece confuso o poco claro, no se preocupe. Analizaremos cada uno de estos aspectos en detalle. ¡Comencemos con cómo verificar el estado de la cadena de bloques!

¿Cómo verificar el estado de la cadena de bloques?

El “estado” de Ethereum se refiere al conjunto de datos almacenados en la cadena de bloques en cualquier momento. Esto incluye saldos de cuentas (cuentas contractuales y cuentas de propiedad externa o EOA), código de contrato inteligente, almacenamiento de contratos y más. Ethereum es una máquina basada en estados porque las transacciones procesadas en la máquina virtual Ethereum (EVM) alteran el estado anterior y producen un nuevo estado.

Cada bloque de Ethereum contiene un valor que resume el estado actual de la red después de ese bloque: el stateRoot . Este valor es una representación compacta de todo el estado de Ethereum, que consta de un hash de 64 caracteres.

A medida que cada nueva transacción modifica el estado, el stateRoot registrado en el bloque siguiente se actualiza en consecuencia. Para calcular este valor, los validadores de Ethereum utilizan una combinación de la función hash de Keccak y una estructura de datos llamada árbol de Merkle para organizar y resumir las diferentes partes del estado.

Las funciones hash son funciones unidireccionales que transforman una entrada en una salida de longitud fija. En Ethereum, las funciones hash como Keccak se utilizan para generar resúmenes de datos, que sirven como una especie de huella digital para la entrada. Las funciones hash tienen cuatro propiedades fundamentales:

1. Determinismo : la misma entrada siempre producirá la misma salida.
2. Longitud de salida fija : independientemente de la longitud de la entrada, la longitud de salida siempre es fija.
3. Propiedad unidireccional : es prácticamente imposible derivar la entrada original de la salida.
4. Unicidad : Incluso un pequeño cambio en la entrada produce una salida completamente diferente. Por lo tanto, una entrada específica se corresponde con una salida prácticamente única.

Gracias a estas propiedades, los validadores de Ethereum pueden realizar la STF (State Transition Function) para cada bloque, es decir, ejecutar todas las transacciones del bloque y aplicarlas al estado, y luego verificar si el estado indicado en el bloque coincide con el estado obtenido después de la STF. Este proceso garantiza que el proponente del bloque haya actuado honestamente, lo que lo convierte en una de las principales responsabilidades de los validadores.

Sin embargo, los validadores de Ethereum no realizan un hash directo de todo el estado para encontrar su resumen. Debido a la naturaleza unidireccional de las funciones hash, realizar un hash directo del estado eliminaría la verificabilidad, ya que la única forma de reproducir el hash sería poseer el estado completo.

Dado que el estado de Ethereum tiene un tamaño de terabytes, no resulta práctico almacenar el estado completo en dispositivos cotidianos como teléfonos o computadoras personales. Por este motivo, Ethereum utiliza una estructura de árbol de Merkle para calcular el stateRoot, preservando la verificabilidad del estado tanto como sea posible.

Un árbol de Merkle es una estructura de datos criptográfica que se utiliza para verificar de forma segura y eficiente la integridad y la exactitud de los datos. Los árboles de Merkle se basan en funciones hash y organizan los hashes de un conjunto de datos de forma jerárquica, lo que permite verificar la integridad y la exactitud de estos datos. Esta estructura de árbol consta de tres tipos de nodos:

1. Nodos de hoja : estos nodos contienen los hashes de los datos individuales y se ubican en el nivel inferior del árbol. Cada nodo de hoja representa el hash de un dato específico en el árbol de Merkle.
2. Nodos de rama : estos nodos contienen los hashes combinados de sus nodos secundarios. Por ejemplo, en un árbol binario de Merkle (donde N=2), los hashes de dos nodos secundarios se concatenan y se vuelven a aplicar para generar el hash de un nodo de rama en un nivel superior.
3. Nodo raíz : el nodo raíz se encuentra en el nivel más alto del árbol de Merkle y representa el resumen criptográfico de todo el árbol. Este nodo se utiliza para verificar la integridad y la exactitud de todos los datos dentro del árbol.

Si te preguntas cómo construir un árbol de este tipo, solo implica dos sencillos pasos:

• Creación de nodos de hoja : cada pieza de datos se procesa mediante una función hash y los hashes resultantes forman los nodos de hoja. Estos nodos se ubican en el nivel inferior del árbol y representan el resumen criptográfico de los datos.

• Combinar y aplicar hash : los hashes de los nodos de hoja se agrupan (por ejemplo, en pares) y se combinan, para luego aplicarles un hash. Este proceso crea nodos de rama en el siguiente nivel. El mismo proceso se repite para los nodos de rama hasta que solo quede un único hash.

El hash final obtenido en la parte superior del árbol se denomina raíz de Merkle. La raíz de Merkle representa el resumen criptográfico de todo el árbol y permite la verificación segura de la integridad de los datos.

¿Cómo utilizamos las raíces de Merkle para verificar el estado de Ethereum?

Las pruebas de Merkle permiten al Verificador validar de manera eficiente fragmentos específicos de datos al proporcionar una serie de valores hash que crean una ruta desde los datos de destino (un nodo de hoja) hasta la raíz de Merkle almacenada en el encabezado del bloque. Esta cadena de valores hash intermedios permite al Verificador confirmar la autenticidad de los datos sin necesidad de aplicar un hash a todo el estado.

A partir del punto de datos específico, el Verificador lo combina con cada hash "hermano" proporcionado en la Prueba de Merkle y los convierte en hashes paso a paso a lo largo del árbol. Este proceso continúa hasta que se produce un único hash. Si este hash calculado coincide con la Raíz de Merkle almacenada, los datos se consideran válidos; de lo contrario, el Verificador puede determinar que los datos no corresponden al estado declarado.

Ejemplo: Verificación de un punto de datos con la prueba de Merkle

Supongamos que hemos recibido los datos n.° 4 de una RPC y queremos verificar su autenticidad mediante una prueba de Merkle. Para ello, la RPC proporcionaría un conjunto de valores hash a lo largo de la ruta necesaria para llegar a la raíz de Merkle. Para los datos n.° 4, estos valores hash hermanos incluirían el hash n.° 3, el hash n.° 12 y el hash n.° 5678.

1. Comenzamos con los datos 4 : primero, hacemos un hash de los datos n.° 4 para obtener el hash n.° 4.
2. Combinar con hermanos : luego combinamos el Hash #4 con el Hash #3 (su hermano a nivel de hoja) y los combinamos para producir el Hash #34.
3. Subir en el árbol : A continuación, tomamos el Hash n.° 34 y lo combinamos con el Hash n.° 12 (su hermano en el siguiente nivel superior) y los combinamos para obtener el Hash n.° 1234.
4. Paso final : por último, combinamos el hash n.° 1234 con el hash n.° 5678 (el último hermano proporcionado) y los combinamos. El hash resultante debe coincidir con la raíz de Merkle (hash n.° 12345678) almacenada en el encabezado del bloque.

Si la raíz de Merkle calculada coincide con la raíz del estado en el bloque, confirmamos que los datos n.° 4 son válidos dentro de este estado. Si no es así, sabemos que los datos no pertenecen al estado reclamado, lo que indica una posible manipulación. Como puede ver, sin proporcionar los hashes de todos los datos ni exigir al verificador que reconstruya todo el árbol de Merkle desde cero, el probador puede demostrar que los datos n.° 4 existen en el estado y no se han alterado durante su recorrido, utilizando solo tres hashes. Esta es la razón principal por la que las pruebas de Merkle se consideran eficientes.

Si bien los árboles de Merkle son indudablemente eficaces para proporcionar una verificación de datos segura y eficiente en grandes sistemas de cadenas de bloques como Ethereum, ¿son realmente lo suficientemente eficientes? Para responder a esta pregunta, debemos analizar cómo el rendimiento y el tamaño de los árboles de Merkle afectan la relación entre el comprobador y el comprobador.

Dos factores clave que afectan el rendimiento del árbol de Merkle

1. Factor de ramificación : la cantidad de nodos secundarios por rama.
2. Tamaño total de los datos : el tamaño del conjunto de datos que se representa en el árbol.

El efecto del factor de ramificación:

Utilicemos un ejemplo para comprender mejor su impacto. El factor de ramificación determina cuántas ramas emergen de cada nodo del árbol.

• Factor de ramificación pequeño (por ejemplo, árbol binario de Merkle) : si se utiliza un árbol binario de Merkle (factor de ramificación de 2), el tamaño de la prueba es muy pequeño, lo que hace que el proceso de verificación sea más eficiente para el verificador. Con solo dos ramas en cada nodo, el verificador solo necesita procesar un hash hermano por nivel. Esto acelera la verificación y reduce la carga computacional. Sin embargo, el factor de ramificación reducido aumenta la altura del árbol, lo que requiere más operaciones de hash durante la construcción del árbol, lo que puede resultar engorroso para los validadores.
• Factor de ramificación más grande (p. ej., 4) : un factor de ramificación más grande (p. ej., 4) reduce la altura del árbol, creando una estructura más corta y más ancha. Esto permite que los nodos completos construyan el árbol más rápido, ya que se necesitan menos operaciones de hash. Sin embargo, para el verificador, esto aumenta la cantidad de hashes hermanos que deben procesar en cada nivel, lo que genera un tamaño de prueba más grande. Más hashes por paso de verificación también significan mayores costos computacionales y de ancho de banda para el verificador, lo que efectivamente traslada la carga de los validadores a los verificadores.

El efecto del tamaño total de los datos

A medida que la cadena de bloques de Ethereum crece, con cada nueva transacción, contrato o interacción del usuario que se suma al conjunto de datos, el árbol de Merkle también debe expandirse. Este crecimiento no solo aumenta el tamaño del árbol, sino que también afecta el tamaño de la prueba y el tiempo de verificación.

• Los nodos completos deben procesar y actualizar periódicamente el conjunto de datos en crecimiento para mantener el árbol de Merkle.
• Los verificadores, a su vez, deben validar pruebas más largas y complejas a medida que crece el conjunto de datos, lo que requiere tiempo de procesamiento y ancho de banda adicionales.

Este creciente tamaño de datos aumenta la demanda tanto de nodos completos como de verificadores, lo que dificulta la ampliación eficiente de la red. En resumen, si bien los árboles Merkle ofrecen un cierto grado de eficiencia, no llegan a ser una solución óptima para el conjunto de datos en continuo crecimiento de Ethereum. Por este motivo, durante la fase The Verge , Ethereum pretende sustituir los árboles Merkle por una estructura más eficiente conocida como árboles Verkle . Los árboles Verkle tienen el potencial de ofrecer tamaños de prueba más pequeños manteniendo al mismo tiempo el mismo nivel de seguridad, lo que hace que el proceso de verificación sea más sostenible y escalable tanto para los probadores como para los verificadores.

The Verge: Revolucionando la verificabilidad en Ethereum

The Verge se desarrolló como un hito en la hoja de ruta de Ethereum destinada a mejorar la verificabilidad, fortalecer la estructura descentralizada de la cadena de bloques y mejorar la seguridad de la red. Uno de los objetivos principales de la red Ethereum es permitir que cualquier persona ejecute fácilmente un validador para verificar la cadena, creando una estructura en la que la participación esté abierta a todos sin centralización.

La accesibilidad de este proceso de verificación es una de las características clave que distingue a las cadenas de bloques de los sistemas centralizados. Si bien los sistemas centralizados no ofrecen capacidades de verificación, la exactitud de una cadena de bloques está completamente en manos de sus usuarios. Sin embargo, para mantener esta seguridad, la ejecución de un validador debe ser accesible para todos, un desafío que, en el sistema actual, está limitado debido a los requisitos de almacenamiento y computación.

Desde la transición a un modelo de consenso de prueba de participación con The Merge , los validadores de Ethereum han tenido dos responsabilidades principales:

1. Garantizar el consenso : apoyar el correcto funcionamiento de los protocolos de consenso tanto probabilísticos como deterministas y aplicar el algoritmo de elección de bifurcación.
2. Comprobación de la precisión del bloque : después de ejecutar las transacciones en un bloque, verificar que la raíz del árbol de estado resultante coincida con la raíz de estado declarada por el proponente.

Para cumplir con la segunda responsabilidad, los validadores deben tener acceso al estado anterior al bloque. Esto les permite ejecutar las transacciones del bloque y derivar el estado posterior. Sin embargo, este requisito impone una gran carga a los validadores, ya que deben gestionar importantes requisitos de almacenamiento.

Si bien Ethereum está diseñado para ser viable y los costos de almacenamiento han estado disminuyendo a nivel mundial, el problema no es tanto el costo como la dependencia de hardware especializado para los validadores. The Verge pretende superar este desafío creando una infraestructura donde se pueda realizar una verificación completa incluso en dispositivos con almacenamiento limitado, como teléfonos móviles, billeteras de navegador e incluso relojes inteligentes, lo que permite que los validadores se ejecuten en estos dispositivos.

Primer paso para lograr verificabilidad: verificación eficiente del estado

La transición a los árboles Verkle es una parte clave de este proceso. Inicialmente, The Verge se centró en reemplazar las estructuras de árboles Merkle de Ethereum con árboles Verkle. La razón principal para adoptar árboles Verkle es que estos representan un obstáculo importante para la verificabilidad de Ethereum. Si bien los árboles Merkle y sus pruebas pueden funcionar de manera eficiente en escenarios normales, su rendimiento se degrada drásticamente en los peores escenarios .

Según los cálculos de Vitalik, el tamaño medio de una prueba es de unos 4 KB , lo que parece manejable. Sin embargo, en el peor de los casos, el tamaño de la prueba puede aumentar hasta los 330 MB . Sí, has leído bien: 330 MB.

La extrema ineficiencia de los árboles Merkle de Ethereum en los peores escenarios se debe a dos razones principales:

1. Uso de árboles hexadecimales : Ethereum utiliza actualmente árboles Merkle con un factor de ramificación de 16. Esto significa que para verificar un solo nodo es necesario proporcionar los 15 hashes restantes en la rama. Dado el tamaño del estado de Ethereum y la cantidad de ramas, esto crea una carga sustancial en los peores escenarios.

2. No merkelización del código : en lugar de incorporar el código del contrato a la estructura de árbol, Ethereum simplemente convierte el código en un hash y utiliza el valor resultante como un nodo. Teniendo en cuenta que el tamaño máximo de un contrato es de 24 KB , este enfoque impone una carga significativa para lograr una verificabilidad completa.

El tamaño de la prueba es directamente proporcional al factor de ramificación. Reducir el factor de ramificación disminuye el tamaño de la prueba. Para abordar estos problemas y mejorar los escenarios más desfavorables, Ethereum podría cambiar de árboles hexarios a árboles binarios de Merkle y comenzar a merklizar los códigos de contrato. Si el factor de ramificación en Ethereum se reduce de 16 a 2 y los códigos de contrato también se merklizan, el tamaño máximo de la prueba podría reducirse a 10 MB .

Si bien se trata de una mejora significativa, es importante tener en cuenta que este costo se aplica a la verificación de un solo dato . Incluso una transacción simple que acceda a varios datos requeriría pruebas más grandes. Dada la cantidad de transacciones por bloque y el estado de crecimiento continuo de Ethereum, esta solución, si bien es mejor, aún no es completamente factible.

Por estas razones, la comunidad Ethereum ha propuesto dos soluciones distintas para abordar el problema:

1. Árboles Verkle
2. Pruebas STARK + Árboles binarios de Merkle

Árboles de Verkle y compromisos vectoriales

Los Verkle Trees , como su nombre indica, son estructuras de árbol similares a los Merkle Trees . Sin embargo, la diferencia más significativa radica en la eficiencia que ofrecen durante los procesos de verificación. En Merkle Trees , si una rama contiene 16 fragmentos de datos y queremos verificar solo uno de ellos, también se debe proporcionar una cadena hash que cubra los otros 15 fragmentos. Esto aumenta significativamente la carga computacional de la verificación y da como resultado pruebas de gran tamaño.

Por el contrario, los árboles Verkle utilizan una estructura especializada conocida como " compromisos vectoriales basados en curvas elípticas ", más específicamente, un compromiso vectorial basado en argumentos internos del producto (IPA) . Un vector es esencialmente una lista de elementos de datos organizados en una secuencia específica. El estado de Ethereum puede considerarse como un vector: una estructura en la que se almacenan numerosos datos en un orden particular, siendo cada elemento crucial. Este estado comprende varios componentes de datos como direcciones, códigos de contrato e información de almacenamiento, donde el orden de estos elementos juega un papel fundamental en el acceso y la verificación.

Los compromisos vectoriales son métodos criptográficos que se utilizan para probar y verificar elementos de datos dentro de un conjunto de datos. Estos métodos permiten verificar tanto la existencia como el orden de cada elemento en un conjunto de datos simultáneamente. Por ejemplo, las pruebas de Merkle , utilizadas en árboles de Merkle, también pueden considerarse una forma de compromiso vectorial . Si bien los árboles de Merkle requieren que todas las cadenas hash relevantes verifiquen un elemento, la estructura prueba inherentemente que todos los elementos de un vector están conectados en una secuencia específica.

A diferencia de los árboles de Merkle, los árboles de Verkle emplean compromisos vectoriales basados en curvas elípticas que ofrecen dos ventajas clave:

• Los compromisos vectoriales basados en curvas elípticas eliminan la necesidad de detalles de elementos distintos de los datos que se están verificando . En árboles de Merkle con un factor de ramificación de 16, verificar una sola rama requiere proporcionar los otros 15 hashes. Dado el gran tamaño del estado de Ethereum, que involucra muchas ramas, esto crea una ineficiencia significativa. Sin embargo, los compromisos vectoriales basados en curvas elípticas eliminan esta complejidad, lo que permite la verificación con menos datos y esfuerzo computacional.
• A través de pruebas múltiples, las pruebas generadas por los compromisos de vector basados en curvas elípticas se pueden comprimir en una única prueba de tamaño constante . El estado de Ethereum no solo es grande, sino que también crece continuamente, lo que significa que la cantidad de ramas que necesitan verificación para acceder a la raíz de Merkle aumenta con el tiempo. Sin embargo, con los árboles Verkle, podemos "comprimir" las pruebas de cada rama en una única prueba de tamaño constante utilizando el método detallado en el artículo de Dankrad Feist . Esto permite a los verificadores validar todo el árbol con una pequeña prueba en lugar de verificar cada rama individualmente. Esto también significa que los árboles Verkle no se ven afectados por el crecimiento del estado de Ethereum.

Estas características de los compromisos vectoriales basados en curvas elípticas reducen significativamente la cantidad de datos necesarios para la verificación, lo que permite que los árboles Verkle produzcan pruebas pequeñas y de tamaño constante incluso en los peores escenarios. Esto minimiza la sobrecarga de datos y los tiempos de verificación, lo que mejora la eficiencia de las redes a gran escala como Ethereum. Como resultado, el uso de compromisos vectoriales basados en curvas elípticas en los árboles Verkle permite un manejo más manejable y eficiente del estado en expansión de Ethereum.

Como todas las innovaciones, los árboles Verkle tienen sus limitaciones. Uno de sus principales inconvenientes es que se basan en la criptografía de curva elíptica, que es vulnerable a los ordenadores cuánticos . Los ordenadores cuánticos poseen una potencia computacional mucho mayor que los métodos clásicos, lo que supone una amenaza importante para los protocolos criptográficos basados en curvas elípticas. Los algoritmos cuánticos podrían romper o debilitar estos sistemas criptográficos, lo que plantea preocupaciones sobre la seguridad a largo plazo de los árboles Verkle.

Por esta razón, si bien los árboles Verkle ofrecen una solución prometedora para la falta de estado, no son la solución definitiva. Sin embargo, figuras como Dankrad Feist han enfatizado que, si bien es necesario un análisis cuidadoso al integrar la criptografía resistente a la tecnología cuántica en Ethereum, vale la pena señalar que los compromisos KZG que se utilizan actualmente para los blobs en Ethereum tampoco son resistentes a la tecnología cuántica. Por lo tanto, los árboles Verkle pueden servir como una solución provisional, brindando a la red tiempo adicional para desarrollar alternativas más sólidas.

Pruebas STARK + Árboles binarios de Merkle

Los árboles Verkle ofrecen tamaños de prueba más pequeños y procesos de verificación eficientes en comparación con los árboles Merkle, lo que facilita la gestión del estado en constante crecimiento de Ethereum. Gracias a los compromisos vectoriales basados en curvas elípticas , se pueden generar pruebas a gran escala con una cantidad significativamente menor de datos. Sin embargo, a pesar de sus impresionantes ventajas, la vulnerabilidad de los árboles Verkle a las computadoras cuánticas los convierte solo en una solución temporal.

Si bien la comunidad Ethereum ve a los árboles Verkle como una herramienta a corto plazo para ganar tiempo, el enfoque a largo plazo está en la transición a soluciones resistentes a la tecnología cuántica . Aquí es donde las pruebas STARK y los árboles binarios de Merkle presentan una alternativa sólida para construir una infraestructura de verificabilidad más sólida para el futuro.

En el proceso de verificación de estado de Ethereum, el factor de ramificación de los árboles de Merkle se puede reducir (de 16 a 2) mediante el uso de árboles binarios de Merkle . Este cambio es un paso fundamental para reducir el tamaño de las pruebas y hacer que los procesos de verificación sean más eficientes. Sin embargo, incluso en el peor de los casos, el tamaño de las pruebas puede alcanzar los 10 MB , lo cual es considerable. Aquí es donde entran en juego las pruebas STARK , que comprimen estas grandes pruebas binarias de Merkle a solo 100-300 kB .

Esta optimización es particularmente vital si se consideran las limitaciones de operar validadores en clientes livianos o dispositivos con hardware limitado, especialmente si se tiene en cuenta que las velocidades promedio globales de descarga y carga en dispositivos móviles son de aproximadamente 7,625 MB/s y 1,5 MB/s, respectivamente. Los usuarios pueden verificar transacciones con pruebas pequeñas y portátiles sin necesidad de acceder al estado completo, y los validadores pueden realizar tareas de verificación de bloques sin almacenar el estado completo.

Este enfoque de doble beneficio reduce tanto los requisitos de ancho de banda como de almacenamiento para los validadores, al tiempo que acelera la verificación, tres mejoras clave que respaldan directamente la visión de Ethereum sobre la escalabilidad.

Principales desafíos para las pruebas STARK

1. Alta carga computacional para los probadores : el proceso de generación de pruebas STARK es computacionalmente intensivo, especialmente en el lado del probador, lo que puede aumentar los costos operativos.
2. Ineficiencia en pruebas con datos pequeños: si bien las pruebas STARK son excelentes para manejar grandes conjuntos de datos, son menos eficientes cuando se trata de pruebas con pequeñas cantidades de datos, lo que puede dificultar su aplicación en ciertos escenarios. Cuando se trabaja con programas que involucran pasos o conjuntos de datos más pequeños, el tamaño relativamente grande de las pruebas STARK puede hacer que sean menos prácticas o rentables.

La seguridad cuántica tiene un costo: la carga computacional del lado del probador

La prueba Merkle de un bloque puede incluir aproximadamente 330.000 hashes y, en el peor de los casos, este número puede ascender a 660.000 . En tales casos, una prueba STARK necesitaría procesar alrededor de 200.000 hashes por segundo . Aquí es donde entran en juego las funciones hash compatibles con zk como Poseidon , optimizadas específicamente para pruebas STARK para reducir esta carga.

Poseidon está diseñado para funcionar de manera más fluida con las pruebas ZK en comparación con los algoritmos hash tradicionales como SHA256 y Keccak . La razón principal de esta compatibilidad radica en cómo funcionan los algoritmos hash tradicionales: procesan las entradas como datos binarios (0 y 1).

Por otro lado, las pruebas ZK funcionan con cuerpos primos, estructuras matemáticas que son fundamentalmente diferentes. Esta situación es análoga a la de las computadoras que operan en binario mientras que los humanos usan un sistema decimal en la vida cotidiana. Traducir datos basados en bits a formatos compatibles con ZK implica una sobrecarga computacional significativa. Poseidon resuelve este problema al operar de forma nativa dentro de cuerpos primos , acelerando drásticamente su integración con las pruebas ZK.

Sin embargo, dado que Poseidon es una función hash relativamente nueva, requiere un análisis de seguridad más extenso para establecer el mismo nivel de confianza que las funciones hash tradicionales como SHA256 y Keccak. Con este fin, iniciativas como Poseidon Cryptanalysis Initiative , lanzada por la Fundación Ethereum, invitan a expertos a probar y analizar rigurosamente la seguridad de Poseidon, asegurando que pueda resistir el escrutinio adversario y convertirse en un estándar sólido para aplicaciones criptográficas. Por otro lado, las funciones más antiguas como SHA256 y Keccak ya han sido ampliamente probadas y tienen un historial de seguridad comprobado, pero no son compatibles con ZK, lo que resulta en caídas de rendimiento cuando se usan con pruebas STARK.

Por ejemplo, las pruebas STARK que utilizan estas funciones hash tradicionales actualmente solo pueden procesar entre 10 000 y 30 000 hashes. Afortunadamente, los avances en la tecnología STARK sugieren que este rendimiento podría aumentar pronto a entre 100 000 y 200 000 hashes, lo que mejoraría significativamente su eficiencia.

La ineficiencia de los STARK para probar datos pequeños

Si bien las pruebas STARK son excelentes en cuanto a escalabilidad y transparencia para grandes conjuntos de datos, presentan limitaciones cuando se trabaja con elementos de datos pequeños y numerosos. En estos escenarios, los datos que se prueban suelen ser pequeños, pero la necesidad de múltiples pruebas sigue siendo la misma. Algunos ejemplos incluyen:

1. Validación de transacciones posterior a la abstracción de cuentas (AA ): con la abstracción de cuentas (AA), las billeteras pueden apuntar al código del contrato, lo que permite omitir o personalizar pasos como la verificación de firma y nonce, que actualmente son obligatorios en Ethereum. Sin embargo, esta flexibilidad en la validación requiere verificar el código del contrato u otros datos asociados en el estado para demostrar la validez de la transacción.
2. Llamadas RPC de clientes ligeros : los clientes ligeros consultan datos de estado de la red (por ejemplo, durante una solicitud eth_call) sin ejecutar un nodo completo. Para garantizar la exactitud de este estado, las pruebas deben respaldar los datos consultados y confirmar que coinciden con el estado actual de la red.
3. Listas de inclusión : los validadores más pequeños pueden utilizar mecanismos de listas de inclusión para garantizar que las transacciones se incluyan en el siguiente bloque, lo que limita la influencia de los productores de bloques poderosos. Sin embargo, para validar la inclusión de estas transacciones es necesario verificar su corrección.

En estos casos de uso, las pruebas STARK ofrecen pocas ventajas. Las STARK, que enfatizan la escalabilidad (como lo destaca la "S" en su nombre), funcionan bien para grandes conjuntos de datos, pero tienen dificultades con escenarios de datos pequeños. Por el contrario, las SNARK , diseñadas para ser concisas (como lo enfatiza la "S" en su nombre), se centran en minimizar el tamaño de las pruebas, lo que ofrece claras ventajas en entornos con restricciones de ancho de banda o almacenamiento.

Las pruebas STARK suelen tener un tamaño de entre 40 y 50 KB , lo que es aproximadamente 175 veces más grande que las pruebas SNARK, que tienen solo 288 bytes . Esta diferencia de tamaño aumenta tanto el tiempo de verificación como los costos de red. La razón principal de que las pruebas STARK sean más grandes es su dependencia de la transparencia y los compromisos polinomiales para garantizar la escalabilidad, lo que introduce costos de rendimiento en escenarios de datos pequeños. En tales casos, los métodos más rápidos y que ahorran más espacio, como las pruebas Merkle, pueden ser más prácticos. Las pruebas Merkle ofrecen bajos costos computacionales y actualizaciones rápidas, lo que las hace adecuadas para estas situaciones.

Como se resume en la tabla, Ethereum tiene cuatro caminos potenciales para elegir:

Árboles Verkle

1. Los árboles Verkle han recibido un amplio apoyo de la comunidad Ethereum, con reuniones quincenales celebradas para facilitar su desarrollo. Gracias a este trabajo y pruebas constantes, los árboles Verkle se destacan como la solución más madura y mejor investigada entre las alternativas actuales. Además, sus propiedades homomórficas aditivas eliminan la necesidad de volver a calcular cada rama para actualizar la raíz del estado, a diferencia de los árboles Merkle, lo que hace que los árboles Verkle sean una opción más eficiente. En comparación con otras soluciones, los árboles Verkle enfatizan la simplicidad, adhiriéndose a principios de ingeniería como "manténgalo simple" o "lo simple es lo mejor". Esta simplicidad facilita tanto la integración en Ethereum como el análisis de seguridad.

2. Sin embargo, los árboles Verkle no son seguros desde el punto de vista cuántico, lo que les impide ser una solución a largo plazo. Si se integran en Ethereum, es probable que esta tecnología deba reemplazarse en el futuro cuando se requieran soluciones resistentes a la tecnología cuántica. Incluso Vitalik ve a los árboles Verkle como una medida temporal para ganar tiempo para que los STARK y otras tecnologías maduren. Además, los compromisos vectoriales basados en curvas elípticas que se utilizan en los árboles Verkle imponen una mayor carga computacional en comparación con las funciones hash simples. Los enfoques basados en hash pueden ofrecer tiempos de sincronización más rápidos para nodos completos. Además, la dependencia de numerosas operaciones de 256 bits hace que los árboles Verkle sean más difíciles de probar utilizando SNARK dentro de los sistemas de prueba modernos, lo que complica los esfuerzos futuros para reducir los tamaños de prueba.

   
   

No obstante, es importante tener en cuenta que los árboles Verkle, debido a que no dependen del hash, son significativamente más demostrables que los árboles Merkle.

STARKs + Funciones hash conservadoras

1. La combinación de STARKs con funciones hash conservadoras bien establecidas como SHA256 o BLAKE proporciona una solución robusta que fortalece la infraestructura de seguridad de Ethereum. Estas funciones hash han sido ampliamente utilizadas y probadas tanto en el ámbito académico como en el práctico. Además, su resistencia cuántica mejora la resiliencia de Ethereum frente a futuras amenazas planteadas por las computadoras cuánticas. Para escenarios críticos para la seguridad, esta combinación ofrece una base confiable.

2. Sin embargo, el uso de funciones hash conservadoras en los sistemas STARK introduce limitaciones de rendimiento significativas. Los requisitos computacionales de estas funciones hash dan como resultado una alta latencia del probador , y la generación de pruebas demora más de 10 segundos. Esta es una desventaja importante, especialmente en escenarios como la validación de bloques que exige baja latencia. Si bien los esfuerzos como las propuestas de gas multidimensional intentan alinear la latencia del peor caso y la del caso promedio, los resultados son limitados. Además, aunque los enfoques basados en hash pueden facilitar tiempos de sincronización más rápidos, su eficiencia podría no estar alineada con los objetivos de escalabilidad más amplios de STARK. Los largos tiempos de cálculo de las funciones hash tradicionales reducen la eficiencia práctica y limitan su aplicabilidad.

   STARKs + Funciones hash relativamente nuevas

• Las STARK combinadas con funciones hash compatibles con STARK de nueva generación (por ejemplo, Poseidon) mejoran significativamente el rendimiento de esta tecnología. Estas funciones hash están diseñadas para integrarse sin problemas con los sistemas STARK y reducir drásticamente la latencia del probador . A diferencia de las funciones hash tradicionales, permiten la generación de pruebas en tan solo 1 o 2 segundos . Su eficiencia y baja sobrecarga computacional mejoran el potencial de escalabilidad de las STARK, lo que las hace muy efectivas para manejar grandes conjuntos de datos. Esta capacidad las hace particularmente atractivas para aplicaciones que requieren un alto rendimiento.

• Sin embargo, la relativa novedad de estas funciones hash requiere un análisis y pruebas de seguridad exhaustivos. La falta de pruebas exhaustivas introduce riesgos a la hora de considerar su implementación en ecosistemas críticos como Ethereum. Además, dado que estas funciones hash aún no se han adoptado ampliamente, los procesos de prueba y validación necesarios podrían retrasar los objetivos de verificabilidad de Ethereum . El tiempo necesario para garantizar plenamente su seguridad podría hacer que esta opción sea menos atractiva a corto plazo, lo que podría posponer las ambiciones de escalabilidad y verificabilidad de Ethereum.

  Árboles de Merkle basados en celosías

1. Los árboles de Merkle basados en celosías ofrecen una solución vanguardista que combina la seguridad cuántica con la eficiencia de actualización de los árboles Verkle. Estas estructuras abordan las debilidades tanto de los árboles Verkle como de los STARK y se consideran una opción prometedora a largo plazo. Con su diseño basado en celosías, brindan una fuerte resistencia a las amenazas de la computación cuántica, en línea con el enfoque de Ethereum en la preparación de su ecosistema para el futuro. Además, al conservar las ventajas de la capacidad de actualización de los árboles Verkle, apuntan a brindar una seguridad mejorada sin sacrificar la eficiencia.
2. Sin embargo, la investigación sobre los árboles de Merkle basados en celosías todavía se encuentra en sus primeras etapas y es en gran parte teórica. Esto genera una incertidumbre significativa sobre su implementación práctica y su rendimiento. La integración de una solución de este tipo en Ethereum requeriría una amplia investigación y desarrollo, así como pruebas rigurosas para validar sus posibles beneficios. Estas incertidumbres y complejidades de infraestructura hacen que sea poco probable que los árboles de Merkle basados en celosías sean una opción viable para Ethereum en el futuro cercano, lo que podría retrasar el progreso hacia los objetivos de verificabilidad de la red.

¿Qué pasa con la ejecución? Pruebas de validez de la ejecución de EVM

Todo lo que hemos discutido hasta ahora gira en torno a eliminar la necesidad de que los validadores almacenen el estado anterior, que utilizan para pasar de un estado al siguiente. El objetivo es crear un entorno más descentralizado en el que los validadores puedan realizar sus tareas sin mantener terabytes de datos de estado.

Incluso con las soluciones que hemos mencionado, los validadores no necesitarían almacenar el estado completo, ya que recibirían todos los datos necesarios para la ejecución a través de testigos incluidos en el bloque. Sin embargo, para realizar la transición al siguiente estado (y, por lo tanto, verificar el stateRoot en la parte superior del bloque), los validadores aún deben ejecutar el STF ellos mismos. Este requisito, a su vez, plantea otro desafío a la naturaleza sin permisos y la descentralización de Ethereum.

Inicialmente, The Verge fue concebido como un hito que se centraba únicamente en la transición del árbol de estados de Ethereum de Merkle Trees a Verkle Trees para mejorar la verificabilidad de los estados. Sin embargo, con el tiempo se ha convertido en una iniciativa más amplia destinada a mejorar la verificabilidad de las transiciones de estados y el consenso . En un mundo donde el trío de Estado, Ejecución y Consenso es totalmente verificable, los validadores de Ethereum podrían operar en prácticamente cualquier dispositivo con una conexión a Internet que pueda clasificarse como un Cliente Ligero . Esto acercaría a Ethereum a lograr su visión de "verdadera descentralización".

¿Cuál es, de nuevo, la definición del problema?

Como mencionamos anteriormente, los validadores ejecutan una función llamada STF (State Transition Function) cada 12 segundos. Esta función toma el estado anterior y un bloque como entradas y produce el siguiente estado como salida. Los validadores deben ejecutar esta función cada vez que se propone un nuevo bloque y verificar que el hash que representa el estado en la parte superior del bloque, comúnmente conocido como la raíz del estado , sea correcto.

Los altos requisitos del sistema para convertirse en validador se derivan principalmente de la necesidad de realizar este proceso de manera eficiente.

Si quieres convertir un refrigerador inteligente (sí, incluso un refrigerador) en un validador de Ethereum con la ayuda de algún software instalado, te enfrentas a dos obstáculos importantes :

1. Lo más probable es que su refrigerador no tenga Internet lo suficientemente rápido, lo que significa que no podrá descargar los datos y pruebas necesarios para la ejecución incluso con las soluciones de verificabilidad estatal que hemos discutido hasta ahora.

2. Incluso si tuviera acceso a los datos necesarios para STF, no tendrá la potencia computacional requerida para realizar la ejecución de principio a fin o para construir un nuevo árbol de estados.

   
   

Para resolver los problemas que generan los clientes Light que no tienen acceso ni al estado anterior ni a la totalidad del último bloque, The Verge propone que el proponente realice la ejecución y luego adjunte una prueba al bloque. Esta prueba incluiría la transición de la raíz del estado anterior a la raíz del siguiente estado, así como el hash del bloque. Con esto, los clientes Light pueden validar la transición de estado utilizando solo tres hashes de 32 bytes , sin necesidad de una prueba zk.

Sin embargo, dado que esta prueba funciona mediante hashes, sería incorrecto decir que solo valida la transición de estado . Por el contrario, la prueba adjunta al bloque debe validar varias cosas simultáneamente :

Raíz del estado en el bloque anterior = S, Raíz del estado en el siguiente bloque = S + 1, Hash del bloque = H

1. El bloque en sí debe ser válido y la prueba de estado que contiene (ya sea una prueba Verkle o STARK) debe verificar con precisión los datos que acompañan al bloque. En resumen: validación del bloque y la prueba de estado que lo acompaña .
2. Cuando se ejecuta el STF utilizando los datos necesarios para la ejecución e incluidos en el bloque correspondiente a H , se deben actualizar correctamente los datos que deben cambiar en el estado. En resumen: Validación de la transición de estado .
3. Cuando se reconstruye un nuevo árbol de estados con los datos actualizados correctamente, su valor raíz debe coincidir con S + 1. En resumen: Validación del proceso de construcción del árbol .

En la analogía Prover-Verifier a la que hicimos referencia anteriormente, generalmente es justo decir que suele haber un equilibrio computacional entre los dos actores. Si bien la capacidad de las pruebas requeridas para hacer que el STF sea verificable para validar múltiples cosas simultáneamente ofrece ventajas significativas para el Verifier , también indica que generar dichas pruebas para garantizar la corrección de la ejecución será relativamente desafiante para el Prover . Con la velocidad actual de Ethereum, un bloque de Ethereum debe probarse en menos de 4 segundos . Sin embargo, incluso el Prover EVM más rápido que tenemos hoy solo puede probar un bloque promedio en aproximadamente 15 segundos . [1]

Dicho esto, hay tres caminos distintos que podemos tomar para superar este gran desafío:

1. Paralelización en la prueba y agregación : una de las ventajas significativas de las pruebas ZK es su capacidad de ser agregadas . La capacidad de combinar múltiples pruebas en una sola prueba compacta proporciona una eficiencia sustancial en términos de tiempo de procesamiento. Esto no solo reduce la carga en la red, sino que también acelera los procesos de verificación de manera descentralizada. Para una red grande como Ethereum, permite la generación más eficiente de pruebas para cada bloque.

Durante la generación de pruebas, cada pequeña parte del proceso de ejecución (por ejemplo, los pasos de cálculo o el acceso a los datos) se puede probar individualmente, y estas pruebas se pueden agregar posteriormente en una única estructura. Con el mecanismo correcto, este enfoque permite que las pruebas de un bloque se generen rápidamente y de manera descentralizada por muchas fuentes diferentes (por ejemplo, cientos de GPU). Esto mejora el rendimiento y, al mismo tiempo, contribuye al objetivo de descentralización al involucrar a un grupo más amplio de participantes.

2. Uso de sistemas de prueba optimizados : los sistemas de prueba de nueva generación tienen el potencial de hacer que los procesos computacionales de Ethereum sean más rápidos y eficientes. Los sistemas avanzados como Orion , Binius y GKR pueden reducir significativamente el tiempo de prueba para cálculos de propósito general. Estos sistemas apuntan a superar las limitaciones de las tecnologías actuales, aumentando la velocidad de procesamiento y consumiendo menos recursos. Para una red enfocada en la escalabilidad y la eficiencia como Ethereum, tales optimizaciones brindan una ventaja significativa. Sin embargo, la implementación completa de estos nuevos sistemas requiere pruebas integrales y esfuerzos de compatibilidad dentro del ecosistema.
3. Cambios en el costo del gas : históricamente, los costos del gas para las operaciones en la máquina virtual Ethereum (EVM) generalmente se determinaban en función de sus costos computacionales . Sin embargo, hoy en día, otra métrica ha ganado prominencia: la complejidad del probador . Si bien algunas operaciones son relativamente fáciles de probar, otras tienen una estructura más compleja y requieren más tiempo para verificarse. Ajustar los costos del gas no solo en función del esfuerzo computacional sino también de la dificultad de probar las operaciones es fundamental para mejorar tanto la seguridad como la eficiencia de la red.

Este enfoque puede minimizar la brecha entre los escenarios de peor caso y los de caso promedio , lo que permite un rendimiento más consistente. Por ejemplo, las operaciones que son más difíciles de probar podrían tener costos de gas más altos, mientras que las que son más fáciles de probar podrían tener costos más bajos. Además, reemplazar las estructuras de datos de Ethereum (como el árbol de estados o la lista de transacciones ) con alternativas compatibles con STARK podría acelerar aún más los procesos de prueba. Dichos cambios ayudarían a Ethereum a lograr sus objetivos de escalabilidad y seguridad, al tiempo que harían que su visión de verificabilidad fuera más realista.

Los esfuerzos de Ethereum por habilitar pruebas de ejecución representan una oportunidad importante para lograr sus objetivos de verificabilidad. Sin embargo, alcanzar este objetivo requiere no solo innovaciones técnicas, sino también mayores esfuerzos de ingeniería y decisiones críticas dentro de la comunidad. Hacer que los procesos de ejecución sean verificables en la Capa 1 debe lograr un equilibrio entre ser accesibles para una amplia base de usuarios, al mismo tiempo que se preserva la descentralización y se alinea con la infraestructura existente.

Establecer este equilibrio aumenta la complejidad de los métodos utilizados para probar operaciones durante la ejecución, lo que resalta la necesidad de avances como la generación de pruebas en paralelo . Además, los requisitos de infraestructura de estas tecnologías (por ejemplo, las tablas de búsqueda ) deben implementarse y ponerse en funcionamiento, lo que aún exige una investigación y un desarrollo sustanciales.

Por otra parte, los circuitos especializados (por ejemplo, ASIC, FPGA, GPU) diseñados específicamente para determinadas tareas tienen un potencial significativo para acelerar el proceso de generación de pruebas. Estas soluciones proporcionan una eficiencia mucho mayor en comparación con el hardware tradicional y pueden acelerar los procesos de ejecución.

Sin embargo, los objetivos de descentralización de Ethereum en el nivel de capa 1 impiden que dicho hardware sea accesible solo para un grupo selecto de actores. Como resultado, se espera que estas soluciones se utilicen más ampliamente en los sistemas de capa 2. No obstante, la comunidad también debe llegar a un consenso sobre los requisitos de hardware para la generación de pruebas.

Surge una pregunta clave sobre el diseño: ¿debería funcionar la generación de pruebas en hardware de consumo, como computadoras portátiles de alta gama, o requerir una infraestructura industrial? La respuesta da forma a toda la arquitectura de Ethereum, lo que permite una optimización agresiva para las soluciones de capa 2 y exige enfoques más conservadores para la capa 1.

Por último, la implementación de pruebas de ejecución está directamente vinculada a otros objetivos de la hoja de ruta de Ethereum. La introducción de pruebas de validez no solo respaldaría conceptos como la falta de estado , sino que también mejoraría la descentralización de Ethereum al hacer que áreas como el staking en solitario sean más accesibles. El objetivo es permitir el staking incluso en los dispositivos con especificaciones más bajas. Además, la reestructuración de los costos del gas en la EVM en función de la dificultad computacional y la demostrabilidad podría minimizar la brecha entre los escenarios promedio y los peores .

Sin embargo, estos cambios podrían romper la compatibilidad con el sistema actual y obligar a los desarrolladores a reescribir su código. Por este motivo, la implementación de pruebas de ejecución no es solo un desafío técnico, es un proceso que debe diseñarse para mantener los valores de Ethereum a largo plazo.

Último paso para la verdadera verificabilidad total: el consenso

El mecanismo de consenso de Ethereum busca establecer un equilibrio único que preserve la descentralización y la accesibilidad y, al mismo tiempo, logre los objetivos de verificabilidad. En este marco, los métodos de consenso probabilísticos y deterministas ofrecen ventajas y desafíos distintos.

El consenso probabilístico se basa en un modelo de comunicación basado en chismes. En este modelo, en lugar de comunicarse directamente con todos los nodos que representan la red, un nodo comparte información con un conjunto seleccionado al azar de 64 o 128 nodos. La selección de la cadena de un nodo se basa en esta información limitada, lo que introduce la posibilidad de error. Sin embargo, con el tiempo, a medida que avanza la cadena de bloques, se espera que estas selecciones converjan hacia la cadena correcta con una tasa de error del 0%.

Una ventaja de la estructura probabilística es que cada nodo no transmite su vista de cadena como un mensaje separado, lo que reduce la sobrecarga de comunicación. En consecuencia, una estructura de este tipo puede funcionar con muchos más nodos descentralizados y sin permisos con menores requisitos del sistema.

Por el contrario, el consenso determinista funciona a través de un modelo de comunicación de uno a todos. En este caso, un nodo envía su vista de la cadena como un voto a todos los demás nodos. Este enfoque genera una mayor intensidad de mensajes y, a medida que aumenta el número de nodos, el sistema puede llegar a alcanzar sus límites.

Sin embargo, la mayor ventaja del consenso determinista es la disponibilidad de votos concretos, lo que permite saber exactamente qué nodo votó por qué bifurcación. Esto asegura la finalización rápida y definitiva de la cadena, garantizando que los bloques no puedan cambiar su orden y haciéndolos verificables.

Para proporcionar un mecanismo de consenso verificable y, al mismo tiempo, preservar la descentralización y una estructura sin permisos, Ethereum ha logrado un equilibrio entre los slots y las épocas. Los slots, que representan intervalos de 12 segundos, son las unidades básicas en las que un validador es responsable de producir un bloque. Aunque el consenso probabilístico utilizado a nivel de slot permite que la cadena funcione de forma más flexible y descentralizada, tiene limitaciones en términos de ordenación definitiva y verificabilidad.

Las épocas, que abarcan 32 espacios, introducen un consenso determinista. En este nivel, los validadores votan para finalizar el orden de la cadena, lo que garantiza la certeza y hace que la cadena sea verificable. Sin embargo, si bien esta estructura determinista proporciona verificabilidad a través de votos concretos a nivel de época, no puede ofrecer una verificabilidad completa dentro de las épocas mismas debido a la estructura probabilística. Para abordar esta brecha y fortalecer la estructura probabilística dentro de las épocas, Ethereum ha desarrollado una solución conocida como el Comité de Sincronización.

Protocolo de cliente ligero de Altair: Comité de sincronización

El Comité de Sincronización es un mecanismo introducido con la actualización de Altair para superar las limitaciones del consenso probabilístico de Ethereum y mejorar la verificabilidad de la cadena para los clientes ligeros. El comité está formado por 512 validadores seleccionados al azar que prestan servicios durante 256 épocas (aproximadamente 27 horas). Estos validadores producen una firma que representa la cabeza de la cadena, lo que permite a los clientes ligeros verificar la validez de la cadena sin necesidad de descargar datos históricos de la cadena. El funcionamiento del Comité de Sincronización se puede resumir de la siguiente manera:

1. Formación del Comité : Se seleccionan 512 validadores al azar entre todos los validadores de la red. Esta selección se actualiza periódicamente para mantener la descentralización y evitar la dependencia de un grupo específico.
2. Generación de firmas : los miembros del comité generan una firma que representa el último estado de la cadena. Esta firma es una firma BLS colectiva creada por los miembros y se utiliza para verificar la validez de la cadena.
3. Verificación de cliente ligero : los clientes ligeros pueden verificar la exactitud de la cadena simplemente verificando la firma del Comité de sincronización. Esto les permite rastrear la cadena de forma segura sin descargar datos de cadenas anteriores.

Sin embargo, el Comité de Sincronización ha sido objeto de críticas en algunas áreas. En particular, el protocolo carece de un mecanismo para eliminar a los validadores por comportamiento malicioso , incluso si los validadores seleccionados actúan intencionalmente contra el protocolo. Como resultado, muchos consideran que el Comité de Sincronización es un riesgo de seguridad y se abstienen de clasificarlo completamente como un Protocolo de Cliente Ligero . Sin embargo, la seguridad del Comité de Sincronización ha sido demostrada matemáticamente , y se pueden encontrar más detalles en este artículo sobre Eliminaciones del Comité de Sincronización .

La ausencia de un mecanismo de corte en el protocolo no es una elección de diseño, sino una necesidad que surge de la naturaleza del consenso probabilístico. El consenso probabilístico no ofrece garantías absolutas sobre lo que observa un validador. Incluso si la mayoría de los validadores informan que una bifurcación en particular es la más pesada, puede haber validadores excepcionales que observen una bifurcación diferente como la más pesada. Esta incertidumbre hace que sea difícil probar la intención maliciosa y, por lo tanto, imposible penalizar la mala conducta.

En este contexto, en lugar de etiquetar al Comité de Sincronización como inseguro, sería más preciso describirlo como una solución ineficiente. El problema no se deriva del diseño mecánico o del funcionamiento del Comité de Sincronización, sino de la naturaleza inherente del consenso probabilístico. Dado que el consenso probabilístico no puede ofrecer garantías definitivas sobre lo que observan los nodos, el Comité de Sincronización es una de las mejores soluciones que se pueden diseñar dentro de un modelo de este tipo. Sin embargo, esto no elimina las debilidades del consenso probabilístico a la hora de garantizar la finalidad de la cadena. El problema no radica en el mecanismo, sino en la estructura de consenso actual de Ethereum.

Debido a estas limitaciones, en el ecosistema Ethereum se están realizando esfuerzos para rediseñar el mecanismo de consenso e implementar soluciones que proporcionen una finalidad determinista en períodos más cortos. Propuestas como Orbit-SSF y 3SF tienen como objetivo remodelar la estructura de consenso de Ethereum desde cero, creando un sistema más eficaz para reemplazar el consenso probabilístico. Estos enfoques buscan no solo acortar el tiempo de finalidad de la cadena, sino también ofrecer una estructura de red más eficiente y verificable. La comunidad Ethereum continúa desarrollando y preparando activamente estas propuestas para su implementación futura.

La sarcificación del consenso

The Verge tiene como objetivo mejorar los mecanismos de consenso actuales y futuros de Ethereum haciéndolos más verificables a través de la tecnología a prueba de zk, en lugar de reemplazarlos por completo. Este enfoque busca modernizar los procesos de consenso de Ethereum al tiempo que preserva sus principios básicos de descentralización y seguridad. Optimizar todos los procesos de consenso históricos y actuales de la cadena con tecnologías zk juega un papel fundamental en el logro de los objetivos de escalabilidad y eficiencia a largo plazo de Ethereum. Las operaciones fundamentales utilizadas en la capa de consenso de Ethereum son de gran importancia en esta transformación tecnológica. Echemos un vistazo más de cerca a estas operaciones y los desafíos que enfrentan.

• ECADD :
• Objetivo : Esta operación se utiliza para agregar las claves públicas de los validadores y es vital para garantizar la precisión y la eficiencia de la cadena. Gracias a la naturaleza agregable de las firmas BLS, se pueden combinar varias firmas en una única estructura. Esto reduce la sobrecarga de comunicación y hace que los procesos de verificación en la cadena sean más eficientes. Garantizar la sincronización entre grandes grupos de validadores de manera más eficaz hace que esta operación sea fundamental.
• Desafíos : Como se mencionó anteriormente, los validadores de Ethereum votan sobre el orden de la cadena durante las épocas. Hoy, Ethereum es una red con aproximadamente 1,1 millones de validadores . Si todos los validadores intentaran propagar sus votos simultáneamente, crearía una tensión significativa en la red. Para evitar esto, Ethereum permite que los validadores voten en función de los espacios durante una época, donde solo 1/32 de todos los validadores votan por espacio. Si bien este mecanismo reduce la sobrecarga de comunicación de la red y hace que el consenso sea más eficiente, dado el recuento de validadores actual, alrededor de 34.000 validadores votan en cada espacio. Esto se traduce en aproximadamente 34.000 operaciones ECADD por espacio .
• Maridajes :
• Propósito : Las operaciones de emparejamiento se utilizan para verificar las firmas BLS , lo que garantiza la validez de las épocas en la cadena. Esta operación permite la verificación por lotes de firmas. Sin embargo, no es compatible con zk , lo que hace que sea extremadamente costoso probarla utilizando tecnología a prueba de zk. Esto presenta un gran desafío a la hora de crear un proceso de verificación integrado con tecnologías de conocimiento cero.
• Desafíos : Las operaciones de emparejamiento en Ethereum están limitadas a un máximo de 128 atestaciones (firmas agregadas) por ranura, lo que da como resultado menos operaciones de emparejamiento en comparación con los ECADD. Sin embargo, la falta de compatibilidad con zk en estas operaciones plantea un desafío significativo. Probar una operación de emparejamiento con pruebas zk es miles de veces más costoso que probar una operación ECADD [2]. Esto hace que la adaptación de las operaciones de emparejamiento para tecnologías de conocimiento cero sea uno de los mayores obstáculos en los procesos de verificación de consenso de Ethereum.
• Hashes SHA256 :
• Propósito : Las funciones hash SHA256 se utilizan para leer y actualizar el estado de la cadena, lo que garantiza la integridad de los datos de la cadena. Sin embargo, su falta de compatibilidad con zk genera ineficiencias en los procesos de verificación basados en zk-proof, lo que plantea un gran obstáculo para los objetivos futuros de verificabilidad de Ethereum.
• Desafíos : Las funciones hash SHA256 se utilizan con frecuencia para leer y actualizar el estado de la cadena. Sin embargo, su falta de compatibilidad con zk entra en conflicto con los objetivos de verificación basados en zk-proof de Ethereum. Por ejemplo, entre dos épocas, cada validador ejecuta el STF de la capa de consenso de Ethereum para actualizar el estado con recompensas y penalizaciones basadas en el rendimiento del validador durante la época. Este proceso depende en gran medida de las funciones hash SHA256, lo que aumenta significativamente los costos en los sistemas basados en zk-proof. Esto crea una barrera sustancial para alinear el mecanismo de consenso de Ethereum con las tecnologías zk.

Las operaciones ECADD, Pairing y SHA256 utilizadas en la capa de consenso actual desempeñan un papel fundamental en los objetivos de verificabilidad de Ethereum. Sin embargo, su falta de compatibilidad con zk plantea desafíos importantes en el camino hacia el logro de estos objetivos. Las operaciones ECADD crean una carga costosa debido al alto volumen de votos de los validadores, mientras que las operaciones Pairing, a pesar de ser menos numerosas, son miles de veces más caras de probar con pruebas zk.

Además, la falta de compatibilidad con zk de las funciones hash SHA256 hace que probar la transición de estado de la cadena de balizas sea extremadamente difícil. Estos problemas resaltan la necesidad de una transformación integral para alinear la infraestructura existente de Ethereum con las tecnologías de conocimiento cero.

Solución “Beam Chain”: reimaginando la capa de consenso de Ethereum

El 12 de noviembre de 2024, durante su presentación en Devcon, Justin Drake presentó una propuesta llamada "Beam Chain ", cuyo objetivo es transformar de manera fundamental e integral la capa de consenso de Ethereum. La Beacon Chain ha sido el núcleo de la red de Ethereum durante casi cinco años. Sin embargo, durante este período, no ha habido cambios estructurales importantes en la Beacon Chain. Por el contrario, los avances tecnológicos han progresado rápidamente, superando con creces la naturaleza estática de la Beacon Chain.

En su presentación, Justin Drake destacó que Ethereum ha aprendido lecciones importantes durante estos cinco años en áreas críticas como la comprensión de MEV , los avances en las tecnologías SNARK y la conciencia retrospectiva de los errores tecnológicos . Los diseños informados por estos nuevos aprendizajes se clasifican en tres pilares principales: producción de bloques , staking y criptografía . La siguiente imagen resume estos diseños y la hoja de ruta propuesta:

• Los cuadros verdes y grises representan desarrollos incrementales que se pueden implementar uno por uno cada año. Este tipo de mejoras, al igual que las actualizaciones anteriores, se pueden integrar paso a paso sin alterar la arquitectura existente de Ethereum.

• Por otro lado, los recuadros rojos significan cambios de gran escala, de gran sinergia y fundamentales que deben implementarse en conjunto. Según Drake, estos cambios tienen como objetivo mejorar la capacidad y la verificabilidad de Ethereum en un gran salto.

  
  

En esta sección, hemos examinado en detalle los pasos de consenso, estado y ejecución de The Verge, y uno de los problemas más destacados durante este proceso es el uso de la función hash SHA256 en la Beacon Chain de Ethereum. Si bien SHA256 desempeña un papel central para garantizar la seguridad de la red y procesar las transacciones, su falta de compatibilidad con zk plantea un obstáculo importante para lograr los objetivos de verificabilidad de Ethereum. Su alto costo computacional y su incompatibilidad con las tecnologías zk lo convierten en un problema crítico que debe abordarse en los desarrollos futuros de Ethereum.

La hoja de ruta de Justin Drake, presentada durante su charla en Devcon, prevé reemplazar SHA256 en Beacon Chain con funciones hash compatibles con zk como Poseidon . Esta propuesta tiene como objetivo modernizar la capa de consenso de Ethereum, haciéndola más verificable, eficiente y alineada con las tecnologías a prueba de zk.

En este contexto, vemos que Ethereum no solo enfrenta desafíos con funciones hash hostiles a zk, sino que también necesita reevaluar las firmas digitales utilizadas en su capa de consenso para la seguridad a largo plazo. Con el avance de la computación cuántica, los algoritmos de firma digital como ECDSA actualmente en uso podrían enfrentar amenazas significativas. Como se señala en las pautas publicadas por NIST , las variantes de ECDSA con un nivel de seguridad de 112 bits quedarán obsoletas para 2030 y completamente prohibidas para 2035. Esto requiere una transición para Ethereum y redes similares hacia alternativas más resistentes, como firmas de seguridad cuántica en el futuro.

En este punto, las firmas basadas en hash surgen como soluciones resistentes a la tecnología cuántica que podrían desempeñar un papel fundamental en el apoyo a los objetivos de seguridad y verificabilidad de la red. Abordar esta necesidad también elimina el segundo gran obstáculo para hacer que la Beacon Chain sea verificable: las firmas BLS . Uno de los pasos más importantes que Ethereum puede dar para garantizar la seguridad cuántica es adoptar soluciones poscuánticas como las firmas basadas en hash y los SNARK basados en hash .

Como enfatizó Justin Drake en su presentación en Devcon , las funciones hash son inherentemente resistentes a las computadoras cuánticas debido a su dependencia de la resistencia de preimagen, lo que las convierte en uno de los componentes fundamentales de la criptografía moderna. Esta propiedad garantiza que incluso las computadoras cuánticas no puedan realizar ingeniería inversa de manera eficiente a partir de la entrada original de un hash determinado, preservando su seguridad.

Los sistemas de firma basados en hash permiten a los validadores y atestiguadores generar firmas basadas completamente en funciones hash, lo que garantiza la seguridad postcuántica y, al mismo tiempo, proporciona un mayor nivel de verificabilidad en toda la red, especialmente si se utiliza una función hash compatible con SNARK. Este enfoque no solo mejora la seguridad de la red, sino que también hace que la infraestructura de seguridad a largo plazo de Ethereum sea más sólida y esté preparada para el futuro.

Este sistema se basa en la combinación de firmas basadas en hash y SNARK basados en hash (pruebas similares a STARK) para crear esquemas de firma agregables . Las firmas agregables comprimen miles de firmas en una sola estructura, reduciéndola a solo unos pocos cientos de kilobytes de prueba. Esta compresión disminuye significativamente la carga de datos en la red al tiempo que acelera enormemente los procesos de verificación. Por ejemplo, las miles de firmas de validador producidas para una sola ranura en Ethereum se pueden representar mediante una única firma agregada, lo que ahorra espacio de almacenamiento y potencia computacional.

Sin embargo, la característica más destacable de este esquema es su agregación infinitamente recursiva . Es decir, un grupo de firmas se puede combinar a su vez bajo otro grupo, y este proceso puede continuar a lo largo de la cadena. Con este mecanismo y considerando los avances tecnológicos futuros, es justo decir que esto abre la puerta a posibilidades que actualmente no se pueden lograr con BLS.

Conclusión

El camino de Ethereum hacia la verificabilidad representa un cambio fundamental en la tecnología blockchain. La iniciativa Verge aborda las ineficiencias centrales a través de árboles Verkle para la verificación de estado y pruebas STARK para transiciones escalables.

Una de las propuestas más ambiciosas es la Beam Chain , un rediseño integral de la capa de consenso de Ethereum. Al abordar las limitaciones de la Beacon Chain e incorporar alternativas compatibles con zk, este enfoque tiene como objetivo mejorar la escalabilidad de Ethereum al tiempo que preserva sus principios básicos de descentralización y accesibilidad . Sin embargo, la transición también destaca los desafíos que enfrenta Ethereum para equilibrar las demandas computacionales con su objetivo de mantener una red inclusiva y sin permisos.

Dado que el NIST planea eliminar gradualmente la criptografía de curva elíptica actual para 2035, Ethereum debe adoptar soluciones resistentes a la tecnología cuántica, como las firmas basadas en hash y Poseidon. Estas soluciones presentan sus propias desventajas en términos de eficiencia.

El uso de STARKs en la hoja de ruta de Ethereum enfatiza aún más la escalabilidad y la verificabilidad. Si bien se destacan por brindar pruebas transparentes y resistentes a la tecnología cuántica, su integración presenta desafíos relacionados con los costos computacionales del lado del probador y las ineficiencias de los datos pequeños . Estos obstáculos deben abordarse para hacer realidad por completo la visión de Ethereum de la falta de estado y la verificación eficiente de bloques, asegurando que la red se mantenga sólida frente a la creciente demanda.

A pesar de estos avances, aún quedan desafíos clave. Ethereum debe abordar cuestiones de compatibilidad con zk , escalabilidad de consenso y las complejidades de la integración de criptografía resistente a la tecnología cuántica . Además, la compatibilidad con versiones anteriores de la infraestructura existente plantea obstáculos prácticos que requieren soluciones de ingeniería cuidadosas para evitar interrupciones tanto para los desarrolladores como para los usuarios.

Lo que distingue a Ethereum no son solo sus innovaciones técnicas, sino su enfoque iterativo para resolver algunos de los problemas más difíciles de la cadena de bloques. El camino a seguir, ya sea a través de tecnologías como Beam Chain , Verkle Trees o pruebas STARK , depende de un esfuerzo colaborativo de desarrolladores, investigadores y la comunidad en general. Estos avances no tienen como objetivo lograr la perfección de la noche a la mañana, sino crear una base para una Internet transparente , descentralizada y verificable .

La evolución de Ethereum pone de relieve su papel como actor fundamental en la configuración de la era Web3. Al abordar los desafíos actuales con soluciones prácticas, Ethereum se acerca a un futuro en el que la verificabilidad , la resistencia cuántica y la escalabilidad se conviertan en el estándar, no en la excepción.