El camino hacia la verificabilidad

La ventaja principal de Web3 es la verificabilidad: los usuarios pueden verificar cómo funcionan realmente los sistemas. Esta característica explica por qué muchos dentro y fuera de la industria criptográfica describen a web3 como un paso hacia un 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 una completa auditabilidad. Incluso si se comparten, carece de la capacidad para verificar si la plataforma funciona como se especifica. Esto es lo contrario de la criptografía, 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 del recientemente publicado de Vitalikserie de seis partes sobre el futuro de Ethereum, para analizar los pasos que está dando Ethereum hacia la consecución de la verificabilidad, sostenibilidad y escalabilidad en el futuro. Bajo el título 'The Verge', discutiremos cómo se pueden hacer las arquitecturas de blockchain más verificables, las innovaciones que estos cambios aportan a nivel de protocolo y cómo proporcionan 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 poder ver cómo funciona realmente la aplicación. En contraste, los protocolos de criptomonedas suelen hacer que su código fuente esté públicamente disponible, o al menos tienen planes de hacerlo. Esta transparencia sirve para 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 opera el sistema y qué reglas lo gobiernan.

“Descentraliza lo que puedas, verifica el resto.”

La verificabilidad asegura que los sistemas son responsables y, en muchos casos, garantiza que los protocolos funcionen según lo previsto. Este principio destaca la importancia de minimizar la centralización, ya que a menudo conduce a estructuras opacas e irresponsables donde los usuarios no pueden verificar las operaciones. En cambio, debemos esforzarnos por descentralizar tanto como sea posible y hacer que los elementos restantes sean verificables y responsables cuando la descentralización no sea factible.

La comunidad de Ethereum parece alinearse con esta perspectiva, como el roadmapincluye un hito (llamado "The Verge") destinado a hacer que Ethereum sea más verificable. Sin embargo, antes de sumergirnos en The Verge, debemos entender qué aspectos de las blockchains deben ser verificados y qué partes son cruciales desde la perspectiva de los usuarios.

Las cadenas de bloques funcionan esencialmente como relojes globales. En una red distribuida con alrededor de 10,000 computadoras, puede llevar una cantidad significativa de tiempo para que una transacción se propague desde el nodo de origen a todos los demás nodos. Por esta razón, los nodos en toda 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 consensopara asegurar 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 estén de acuerdo con la misma secuencia, lo que permite que la red funcione como un solo y coherente ordenador.

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á formada por las transacciones que los usuarios desean ejecutar.

Una vez que las transacciones han sido ordenadas con éxito por consenso, cada transacción debe ser aplicada al estado actual en la capa de ejecución. Si te estás preguntando, "¿Qué es el estado?", probablemente hayas visto comparaciones entre blockchains y bases de datos, o más específicamente con la base de datos de un banco, porque los blockchains, 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 alguien más, tu saldo en el próximo estado, “S+1”, será de $90. Este proceso de aplicar transacciones para moverse de un estado a otro es lo que llamamos una Función de Transición de Estado (STF).

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 completamente 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: Puede que desees leer un fragmento de datos en la cadena de bloques, pero no tengas acceso al estado ya que no ejecutas un nodo completo. Por lo tanto, solicita los datos a través de un proveedor de RPC (Remote Procedure Call) como Alchemy o Infura. Sin embargo, debes verificar que los datos no hayan sido manipulados por el proveedor de RPC.
2. Ejecución: Como se mencionó anteriormente, las cadenas de bloques utilizan un STF. Debe verificar que la transición de estado se ejecutó correctamente, no en base a transacciones individuales, sino en base a bloques.
3. Consensus: Entidades de terceros, como RPCs, pueden proporcionarte bloques válidos que aún no se han incluido en la cadena de bloques. Por lo tanto, debes verificar que estos bloques hayan sido aceptados mediante consenso y añadidos a la cadena de bloques.

Si esto parece confuso o poco claro, no te preocupes. Vamos a repasar cada uno de estos aspectos en detalle. ¡Empecemos con cómo verificar el estado del blockchain!

¿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 dado. Esto incluye los saldos de las cuentas (cuentas de contratos y cuentas de propiedad externa o EOAs), el código de los contratos inteligentes, el almacenamiento de contratos y más. Ethereum es una máquina basada en el estado porque las transacciones procesadas en la Máquina Virtual de 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, consistente en un hash de 64 caracteres.

A medida que cada nueva transacción modifica el estado, el stateRoot registrado en el bloque subsiguiente se actualiza en consecuencia. Para calcular este valor, los validadores de Ethereum utilizan una combinación de la función hash Keccak y una estructura de datos llamada el Árbol de Merkleorganizar y resumir 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 Keccakse utilizan para generar resúmenes de datos, sirviendo 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 la salida es siempre fija.
3. Propiedad unidireccional: Es prácticamente imposible derivar la entrada original a partir 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 asigna a una salida prácticamente única.

Gracias a estas propiedades, los validadores de Ethereum pueden realizar la FTE (Función de Transición de Estado) para cada bloque, ejecutando todas las transacciones en el bloque y aplicándolas al estado, y luego verificar si el estado indicado en el bloque coincide con el estado obtenido después de la FTE. Este proceso asegura que el proponente del bloque haya actuado honestamente, convirtiéndolo en una de las responsabilidades clave de los validadores.

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

Dado que el estado de Ethereum tiene un tamaño de varios terabytes, es imposible almacenar el estado completo en dispositivos cotidianos como teléfonos o computadoras personales. Por esta razón, Ethereum utiliza una estructura de árbol de Merkle para calcular el stateRoot, preservando la verificabilidad del estado tanto como sea posible.

A árbol de Merklees una estructura de datos criptográfica utilizada para verificar de forma segura y eficiente la integridad y corrección de datos. Los árboles de Merkle se construyen sobre funciones hash y organizan jerárquicamente los hashes de un conjunto de datos, lo que permite verificar la integridad y corrección de estos datos. Esta estructura de árbol consta de tres tipos de nodos:

1. Nodos hoja: Estos nodos contienen los hashes de las piezas de datos individuales y se encuentran en el nivel inferior del árbol. Cada nodo hoja representa el hash de una pieza de datos específica en el árbol de Merkle.
2. Nodos de rama: Estos nodos contienen los hashes combinados de sus nodos hijos. Por ejemplo, en un árbol de Merkle binario (donde N=2), los hashes de dos nodos hijos se concatenan y se vuelven a hashear para producir el hash de un nodo de rama en un nivel superior.
3. Nodo raíz: El nodo raíz se encuentra en el nivel superior del árbol Merkle y representa el resumen criptográfico de todo el árbol. Este nodo se utiliza para verificar la integridad y corrección de todos los datos dentro del árbol.

Si te preguntas cómo construir un árbol así, solo implica dos simples pasos:

• Creación de nodo hoja: Cada pieza de datos se procesa a través de una función hash, y los hashes resultantes forman los nodos hoja. Estos nodos residen en el nivel más bajo del árbol y representan el resumen criptográfico de los datos.

• Combinar y resumir: Los hashes de los nodos hoja se agrupan (por ejemplo, en pares) y se combinan, seguido de un resumen. 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 solo hash.

El hash final obtenido en la parte superior del árbol se llama 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 usamos las raíces de Merkle para verificar el estado de Ethereum?

Las pruebas de Merkle permiten que el Verificador valide eficientemente piezas específicas de datos al proporcionar una serie de valores hash que crean un camino desde los datos objetivo (un nodo hoja) hasta la Raíz de Merkle almacenada en la cabecera del bloque. Esta cadena de hashes intermedios permite al Verificador confirmar la autenticidad de los datos sin necesidad de hashear el estado completo.

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

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

Digamos que hemos recibido Data #4 de un RPC y queremos verificar su autenticidad usando una Prueba de Merkle. Para hacer esto, el RPC proporcionaría un conjunto de valores hash a lo largo del camino necesario para llegar a la Raíz de Merkle. Para Data 4, estos valores hash hermanos incluirían Hash #3, Hash #12 y Hash #5678.

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

Si la Raíz de Merkle calculada coincide con la raíz de estado en el bloque, confirmamos que Data #4 es válida dentro de este estado. Si no, sabemos que los datos no pertenecen al estado reclamado, lo que indica un posible manipulación. Como puede ver, sin proporcionar los hashes de todos los datos o requerir que el Verificador reconstruya todo el Árbol de Merkle desde cero, el Probador puede demostrar que el Data #4 existe en el estado y no ha sido alterado durante su recorrido, usando solo tres hashes. Esta es la razón principal por la que las Pruebas de Merkle se consideran eficientes.

Si bien los Merkle Trees son indudablemente efectivos para proporcionar una verificación de datos segura y eficiente en grandes sistemas de blockchain como Ethereum, ¿son realmente lo suficientemente eficientes? Para responder a esto, debemos analizar cómo el rendimiento y el tamaño del árbol de Merkle impactan en la relación Prover-Verifier.

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

1. Factor de ramificación: El número de nodos hijos por rama.
2. Tamaño total de 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 entender mejor su impacto. El factor de ramificación determina cuántas ramas emergen de cada nodo en el árbol.

• Pequeño factor de ramificación (por ejemplo, árbol Merkle binario):
  Si se utiliza un árbol de Merkle binario (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 de 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 ser una carga pesada para los validadores.
• Factor de ramificación más grande (por ejemplo, 4):
  Un factor de ramificación mayor (por ejemplo, 4) reduce la altura del árbol, creando una estructura más corta y ancha. Esto permite a los Nodos Completo construir el árbol más rápido ya que se necesitan menos operaciones de hash. Sin embargo, para el Verificador, esto aumenta el número de hashes hermanos que deben procesar en cada nivel, lo que conduce a un tamaño de prueba más grande. Más hashes por paso de verificación también significan costos computacionales y de ancho de banda más altos para el Verificador, lo que desplaza efectivamente la carga de los validadores a los verificadores.

El Efecto del Tamaño Total de los Datos:

A medida que crece la cadena de bloques de Ethereum, con cada nueva transacción, contrato o interacción del usuario que se añade 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 al tamaño de la prueba y al tiempo de verificación.

• Los nodos completos deben procesar y actualizar regularmente 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 crecimiento del tamaño de los datos aumenta la demanda tanto en los nodos completos como en los verificadores, lo que dificulta escalar la red de manera eficiente.

En resumen, si bien los Árboles de Merkle ofrecen un grado de eficiencia, no son una solución óptima para el conjunto de datos en constante crecimiento de Ethereum. Por esta razón, durante la fase The Verge, Ethereum tiene como objetivo reemplazar los Árboles de Merkle por una estructura más eficiente conocida como Árboles VerkleLos árboles Verkle tienen el potencial de ofrecer tamaños de prueba más pequeños mientras mantienen 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.

Capítulo 2: Revolucionando la Verificabilidad en Ethereum - The Verge

Verge se desarrolló como un hito en la hoja de ruta de Ethereum con el objetivo de mejorar la verificabilidad, fortalecer la estructura descentralizada del blockchain y mejorar la seguridad de la red. Uno de los objetivos principales de la red de Ethereum es permitir que cualquiera pueda ejecutar 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 blockchains de los sistemas centralizados. Mientras que los sistemas centralizados no ofrecen capacidades de verificación, la corrección de una blockchain está completamente en manos de sus usuarios. Sin embargo, para mantener esta garantía, ejecutar un validador debe ser accesible para todos, un desafío que, bajo 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. Asegurando el consenso: Apoyando el funcionamiento adecuado de los protocolos de consenso probabilísticos y deterministas y aplicando el algoritmo de elección de bifurcación.
2. Verificació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 coincide 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 pesada carga a los validadores, ya que necesitan manejar requisitos de almacenamiento significativos. Si bien Ethereum está diseñado para ser factible y los costos de almacenamiento han estado disminuyendo a nivel mundial, el problema es menos acerca del costo y más acerca de la dependencia de hardware especializado para los validadores. The Verge tiene como objetivo superar este desafío creando una infraestructura donde la verificación completa pueda realizarse incluso en dispositivos con almacenamiento limitado, como teléfonos móviles, billeteras de navegador e incluso smartwatches, lo que permite a los validadores ejecutarse en estos dispositivos.

Primer Paso de la Verificabilidad: 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 los árboles Verkle es que los árboles Merkle representan un obstáculo significativo para la verificabilidad de Ethereum. Si bien los árboles Merkle y sus pruebas pueden funcionar eficientemente en escenarios normales, su rendimiento degrada drásticamente en escenarios de peor caso.

Según los cálculos de Vitalik, el tamaño promedio de la prueba es de alrededor de 4 KB, lo que suena manejable. Sin embargo, en escenarios de peor caso, el tamaño de la prueba puede hincharse hasta 330 MB. Sí, leíste bien: 330 MB.

La extrema ineficiencia de los Árboles de Merkle de Ethereum en escenarios de peor caso se debe a dos razones principales:

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

1. No-Merkelización del código: En lugar de incorporar el código del contrato en la estructura del árbol, Ethereum simplemente hace un hash del código y usa 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 verificación completa.

El tamaño de la prueba es directamente proporcional al factor de ramificación. La reducción del factor de ramificación disminuye el tamaño de la prueba. Para abordar estos problemas y mejorar los escenarios peores, Ethereum podría cambiar de árboles hexagonales a árboles de Merkle binarios 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 disminuir a 10 MB. Si bien esta es una mejora significativa, es importante tener en cuenta que este costo se aplica para verificar solo una pieza de datos. Incluso una transacción simple que acceda a múltiples piezas de datos requeriría pruebas más grandes. Dado el número de transacciones por bloque y el estado continuamente en crecimiento de Ethereum, esta solución, aunque mejor, todavía no es completamente factible.

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

1. Árboles Verkle
2. STARK Proofs + Árboles Binarios Merkle

Verkle Trees & Vector Commitments

Los árboles Verkle, como su nombre sugiere, son estructuras de árbol similares a los árboles Merkle. Sin embargo, la diferencia más significativa radica en la eficiencia que ofrecen durante los procesos de verificación. En los árboles Merkle, si una rama contiene 16 piezas de datos y queremos verificar solo una de ellas, también se debe proporcionar una cadena de hash que cubra las otras 15 piezas. Esto aumenta significativamente la carga computacional de verificación y resulta en tamaños de prueba grandes.

En contraste, los árboles Verkle utilizan una estructura especializada conocida como "Compromisos de Vectores basados en Curvas Elípticas", más específicamente, un Compromiso de Vectores basado en Argumento de Producto Interno (IPA). Un vector es esencialmente una lista de elementos de datos organizados en una secuencia específica. El estado de Ethereum se puede considerar como un vector: una estructura donde se almacenan numerosas piezas de datos en un orden particular, siendo cada elemento crucial. Este estado comprende diversos componentes de datos como direcciones, códigos de contrato e información de almacenamiento, donde el orden de estos elementos desempeña un papel crítico en el acceso y la verificación.

Los compromisos vectoriales son métodos criptográficos utilizados 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 los árboles de Merkle, también pueden considerarse una forma de compromiso vectorial. Mientras que los árboles de Merkle requieren todas las cadenas de hash relevantes para verificar un elemento, la estructura demuestra 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 utilizan 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 que no sean los datos que se verifican. En los árboles de Merkle con un factor de ramificación de 16, la verificación de una sola rama requiere la provisión de los otros 15 hashes. Dada la gran cantidad de estados de Ethereum, que involucra muchas ramas, esto crea una ineficiencia significativa. Sin embargo, los compromisos vectoriales basados en curvas elípticas eliminan esta complejidad, permitiendo la verificación con menos datos y esfuerzo computacional. \

• A través de las pruebas múltiples, las pruebas generadas por los compromisos vectoriales 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 el número 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 Artículo de Dankrad FeistEsto 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 de 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 a los árboles Verkle producir pruebas pequeñas de tamaño constante incluso en escenarios de peor caso. Esto minimiza la sobrecarga de datos y los tiempos de verificación, mejorando la eficiencia de 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. Una de sus principales desventajas es que dependen de la criptografía de curva elíptica, que es vulnerable a los ordenadores cuánticos. Los ordenadores cuánticos poseen un poder computacional mucho mayor que los métodos clásicos, lo que supone una amenaza significativa para los protocolos criptográficos basados en curvas elípticas. Los algoritmos cuánticos podrían potencialmente 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, aunque los árboles Verkle ofrecen una solución prometedora hacia la falta de estado, no son la solución definitiva. Sin embargo, figuras como Dankrad Feist han enfatizado que, si bien se necesita una consideración cuidadosa al integrar la criptografía resistente a los ataques cuánticos en Ethereum, vale la pena señalar que los compromisos KZG actualmente utilizados para los bloques en Ethereum tampoco son resistentes a los ataques cuánticos. Por lo tanto, los árboles Verkle pueden servir como una solución provisional, brindando a la red tiempo adicional para desarrollar alternativas más robustas.

Pruebas STARK + Árboles de Merkle Binarios

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 siempre creciente de Ethereum. Gracias a las Compromisos Vectoriales Basados en Curvas Elípticas, se pueden generar pruebas a gran escala con significativamente menos datos. Sin embargo, a pesar de sus impresionantes ventajas, la vulnerabilidad de los árboles Verkle a las computadoras cuánticas los convierte en solo una solución temporal. Mientras la comunidad de Ethereum ve los árboles Verkle como una herramienta a corto plazo para ganar tiempo, el enfoque a largo plazo está en la transición hacia soluciones resistentes a los cuánticos. Aquí es donde las Pruebas STARK y los Árboles Merkle Binarios presentan una sólida alternativa para construir una infraestructura de verificabilidad más robusta para el futuro.

En el proceso de verificación de estado de Ethereum, el factor de ramificación de los árboles de Merkle puede reducirse (de 16 a 2) mediante el uso de árboles de Merkle binarios. Este cambio es un paso crítico para reducir los tamaños de prueba y hacer que los procesos de verificación sean más eficientes. Sin embargo, incluso en el peor de los casos, los tamaños de prueba aún pueden alcanzar los 10 MB, lo que es sustancial. Aquí es donde entran en juego las Pruebas STARK, comprimiendo estas grandes Pruebas de Merkle Binario a solo 100-300 kB.

Esta optimización es particularmente vital al considerar las limitaciones de operar validadores en clientes ligeros o dispositivos con hardware limitado, especialmente si se tiene en cuenta que la velocidad promedio de descarga y carga móvil a nivel mundial es 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 todo el estado.

Este enfoque de doble beneficio reduce tanto el ancho de banda como los requisitos 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.

Desafíos clave para las pruebas STARK:

1. Alta carga computacional para los verificadores: \
   El proceso de generación de pruebas STARK es intensivo en computación, especialmente en el lado del comprobador, lo que puede aumentar los costos operativos.
2. Ineficiencia en las Pruebas de Pequeños Datos:

Si bien las pruebas de STARK destacan en el manejo de conjuntos de datos grandes, son menos eficientes al demostrar pequeñas cantidades de datos, lo que puede obstaculizar su aplicación en ciertos escenarios. Al lidiar con programas que involucran pasos o conjuntos de datos más pequeños, el tamaño de prueba relativamente grande de los STARKs puede hacerlos menos prácticos o rentables.

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

La Prueba de Merkle de un bloque puede incluir aproximadamente 330,000 hashes, y en escenarios de peor caso, este número puede aumentar 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 amigables con zk, como Poseidón, optimizadas específicamente para las pruebas STARK para reducir esta carga. Poseidón 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 (0s y 1s). Por otro lado, las pruebas ZK trabajan con campos primos, estructuras matemáticas que son fundamentalmente diferentes. Esta situación es análoga a las computadoras que operan en binario mientras que los humanos utilizan un sistema decimal en la vida cotidiana. Traducir datos basados en bits a formatos compatibles con ZK implica una sobrecarga computacional significativa. Poseidón resuelve este problema al operar nativamente dentro de campos 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 el Iniciativa de Criptoanálisis Poseidón, lanzado por la Ethereum Foundation, invita a expertos a probar y analizar rigurosamente la seguridad de Poseidon, asegurando que pueda resistir el escrutinio adversarial y convertirse en un estándar sólido para aplicaciones criptográficas. Por otro lado, 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 una disminución del rendimiento cuando se utilizan con pruebas STARK.

Por ejemplo, las pruebas STARK que utilizan estas funciones hash tradicionales actualmente solo pueden procesar de 10,000 a 30,000 hashes. Afortunadamente, los avances en la tecnología STARK sugieren que esta capacidad de procesamiento podría aumentar pronto a 100,000 a 200,000 hashes, mejorando significativamente su eficiencia.

La ineficiencia de STARKs en demostrar pequeños datos

Si bien las pruebas STARK sobresalen en escalabilidad y transparencia para conjuntos de datos grandes, presentan limitaciones al trabajar 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. Ejemplos incluyen:

1. Validación de transacción posterior-AA: \
   Con Account Abstraction (AA), las carteras pueden apuntar al código de contrato, evitando o personalizando pasos como la verificación de nonce y firma, 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 del cliente ligero: \
   Los clientes ligeros consultan los datos del estado desde la red (por ejemplo, durante una solicitud de eth_call) sin ejecutar un nodo completo. Para garantizar la corrección 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 lista de inclusión para asegurarse de que las transacciones se incluyan en el siguiente bloque, limitando la influencia de los poderosos productores de bloques. Sin embargo, validar la inclusión de estas transacciones requiere verificar su corrección.

En tales casos de uso, las pruebas STARK proporcionan poca ventaja. Los STARK, haciendo hincapié en la escalabilidad (como se destaca por la "S" en su nombre), funcionan bien para grandes conjuntos de datos pero tienen dificultades con escenarios de datos pequeños. Por el contrario, los SNARK, diseñados para la concisión (como se enfatiza por la "S" en su nombre), se centran en minimizar el tamaño de la prueba, ofreciendo claras ventajas en entornos con limitaciones de ancho de banda o almacenamiento.

Las pruebas STARK suelen tener un tamaño de 40-50 KB, lo que es aproximadamente 175 veces más grande que las pruebas SNARK, que solo tienen 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, métodos más rápidos y eficientes en espacio como las Pruebas de Merkle podrían ser más prácticos. Las Pruebas de Merkle ofrecen bajos costos computacionales y actualizaciones rápidas, lo que las hace adecuadas para estas situaciones.

No obstante, las pruebas STARK siguen siendo cruciales para el futuro sin estado de Ethereum debido a su seguridad cuántica.

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

• Árboles de Verkle
  1. Los Verkle Trees han recibido un amplio apoyo de la comunidad de Ethereum, con reuniones quincenales celebradas para facilitar su desarrollo. Gracias a este trabajo y pruebas constantes, Verkle Trees se destaca como la solución más madura y mejor investigada entre las alternativas actuales. Además, sus propiedades aditivamente homomórficas eliminan la necesidad de volver a calcular cada rama para actualizar la raíz de estado, a diferencia de los árboles de Merkle, lo que hace que los árboles de Verkle sean una opción más eficiente. En comparación con otras soluciones, Verkle Trees enfatiza 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 cuánticamente seguros, lo que impide que sean una solución a largo plazo. Si se integra en Ethereum, es probable que esta tecnología deba reemplazarse en el futuro cuando se requieran soluciones resistentes a la cuántica. Incluso Vitalik ve Verkle Trees 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 utilizados en Verkle Trees 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 el tamaño de las pruebas.

No obstante, es importante tener en cuenta que los árboles Verkle, debido a su falta de dependencia de la función hash, son significativamente más demostrables que los árboles Merkle.

• STARKs + Funciones de hash conservadoras
  1. Combinar 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 exhaustivamente tanto en el ámbito académico como en el práctico. Además, su resistencia cuántica mejora la resistencia de Ethereum ante las futuras amenazas planteadas por los ordenadores cuánticos. Para escenarios críticos de seguridad, esta combinación ofrece una base confiable.
  2. Sin embargo, el uso de funciones hash conservadoras en sistemas STARK introduce limitaciones significativas de rendimiento. Los requisitos computacionales de estas funciones hash resultan en una alta latencia del demostrador, con la generación de la prueba que lleva más de 10 segundos. Esta es una desventaja importante, especialmente en escenarios como la validación de bloques que exigen baja latencia. Si bien esfuerzos como propuestas de gas multidimensionales intentan alinear la latencia del peor caso y 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 alinearse con los objetivos de escalabilidad más amplios de STARKs. Los largos tiempos de computación de las funciones hash tradicionales reducen la eficiencia práctica y limitan su aplicabilidad.
• STARKs + Funciones de hash relativamente nuevas
  1. La combinación de STARKs con nuevas funciones hash compatibles con STARKs de nueva generación (por ejemplo, Poseidon) mejora significativamente el rendimiento de esta tecnología. Estas funciones hash están diseñadas para integrarse perfectamente con los sistemas STARK y reducir drásticamente la latencia del probador. A diferencia de las funciones hash tradicionales, permiten generar pruebas en tan solo 1-2 segundos. Su eficiencia y baja sobrecarga computacional mejoran el potencial de escalabilidad de STARKs, lo que los hace altamente efectivos para manejar grandes conjuntos de datos. Esta capacidad los hace especialmente atractivos para aplicaciones que requieren alto rendimiento.
  2. Sin embargo, la novedad relativa de estas funciones hash requiere un extenso análisis de seguridad y pruebas. La falta de pruebas exhaustivas introduce riesgos al considerar su implementación en ecosistemas críticos como Ethereum. Además, dado que estas funciones hash aún no son ampliamente adoptadas, los procesos de prueba y validación requeridos podrían retrasar los objetivos de verificabilidad de Ethereum. El tiempo necesario para garantizar completamente su seguridad podría hacer que esta opción sea menos atractiva a corto plazo, posiblemente postergando las ambiciones de escalabilidad y verificabilidad de Ethereum.
• Árboles de Merkle basados en retícula
  1. Los árboles de Merkle basados en lattice ofrecen una solución visionaria 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 lattice, ofrecen una resistencia sólida a las amenazas de la computación cuántica, alineándose con el enfoque de Ethereum en la futurización de su ecosistema. Además, al retener las ventajas de actualización de los árboles Verkle, buscan ofrecer una seguridad mejorada sin sacrificar la eficiencia.
  2. Sin embargo, la investigación sobre los árboles de Merkle basados en retículas todavía está en sus etapas iniciales y es en gran medida teórica. Esto crea una incertidumbre significativa sobre su implementación práctica y rendimiento. Integrar una solución de este tipo en Ethereum requeriría una investigación y desarrollo extensos, así como pruebas rigurosas para validar sus posibles beneficios. Estas incertidumbres y complejidades infraestructurales hacen que los árboles de Merkle basados en retículas sean poco probables como una opción factible para Ethereum en un futuro cercano, lo que podría retrasar el progreso hacia los objetivos de verificabilidad de la red.

¿Qué hay de 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 a otro. El objetivo es crear un entorno más descentralizado donde 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 todo el estado, ya que recibirían todos los datos necesarios para la ejecución a través de testigos incluidos con el bloque. Sin embargo, para pasar al siguiente estado y así verificar el stateRoot en la parte superior del bloque, los validadores aún deben ejecutar ellos mismos el STF. Este requisito, a su vez, plantea otro desafío para la naturaleza permisiva y descentralizada de Ethereum.

Inicialmente, The Verge se concibió como un hito que se centraba únicamente en la transición del árbol de estado de Ethereum de Merkle Trees a Verkle Trees para mejorar la verificabilidad del estado. Con el tiempo, sin embargo, se ha convertido en una iniciativa más amplia destinada a mejorar la verificabilidad de las transiciones estatales y el consenso. En un mundo en el que 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 la definición del problema?

Como mencionamos anteriormente, los validadores ejecutan una función llamada STF (Función de Transición de Estado) cada 12 segundos. Esta función toma el estado anterior y un bloque como entradas y produce el próximo 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 un validador provienen principalmente de la necesidad de realizar este proceso de manera eficiente.

Si deseas 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 principales:

1. Es probable que tu refrigerador no tenga una conexión a internet lo suficientemente rápida, lo que significa que no podrá descargar los datos y pruebas necesarios para la ejecución, incluso con las soluciones de verificación de estado que hemos discutido hasta ahora.
2. Incluso si tuviera acceso a los datos necesarios para STF, no tendría la potencia computacional necesaria para realizar la ejecución de principio a fin o para construir un nuevo árbol de estado.

Para resolver los problemas causados por los clientes ligeros 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 adjunte una prueba al bloque. Esta prueba incluiría la transición desde la raíz del estado anterior hasta la raíz del estado siguiente, así como el hash del bloque. Con esto, los clientes ligeros 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 a través de hashes, sería incorrecto decir que solo valida la transición de estado. Por el contrario, la prueba adjunta al bloque debe validar múltiples cosas simultáneamente:

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

1. El bloque en sí mismo debe ser válido y la prueba de estado en su interior, ya sea una Prueba de Verkle o STARKs, debe verificar con precisión los datos que acompañan al bloque.
   En resumen: Validación del bloque y la prueba de estado correspondiente.
2. Cuando se ejecuta el STF utilizando los datos necesarios para la ejecución e incluidos en el bloque correspondiente a H, los datos que deben cambiar en el estado deben actualizarse correctamente.
   En resumen: Validación de la transición de estado.
3. Cuando se reconstruye un nuevo árbol de estado 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 Proveedor-Verificador a la que nos referimos anteriormente, es justo decir que generalmente hay un equilibrio computacional entre los dos actores. Si bien la capacidad de pruebas requerida para que el STF sea verificable y valide múltiples cosas simultáneamente ofrece ventajas significativas para el Verificador, también indica que generar tales pruebas para garantizar la corrección de la ejecución será relativamente desafiante para el Proveedor. Con la velocidad actual de Ethereum, un bloque de Ethereum debe ser probado en menos de 4 segundos. Sin embargo, incluso el Proveedor 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 desafío principal:

1. Paralelización en la demostración y agregación: Una de las ventajas significativas de las pruebas de conocimiento cero es su capacidad de ser agregadas. La capacidad de combinar múltiples pruebas en una única 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 pieza del proceso de ejecución (por ejemplo, los pasos de la computación o el acceso a los datos) puede ser probada individualmente, y estas pruebas pueden ser posteriormente agregadas en una única estructura. Con el mecanismo correcto, este enfoque permite que las pruebas de un bloque sean generadas rápidamente y de manera descentralizada por muchas fuentes diferentes (por ejemplo, cientos de GPUs). Esto aumenta el rendimiento y contribuye a la meta de descentralización al involucrar a un grupo más amplio de participantes.

1. Usando 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. Sistemas avanzados como Orion, Binius, y GKRpuede reducir significativamente el tiempo del probador para cálculos de propósito general. Estos sistemas tienen como objetivo 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 proporcionan una ventaja significativa. Sin embargo, la implementación completa de estos nuevos sistemas requiere pruebas exhaustivas y esfuerzos de compatibilidad dentro del ecosistema.
2. Cambios en el costo del gas: Históricamente, los costos de gas para operaciones en la Máquina Virtual Ethereum (EVM) se determinaban típicamente en función de sus costos computacionales. Sin embargo, hoy en día, otra métrica ha ganado prominencia: la complejidad del probador. Mientras que algunas operaciones son relativamente fáciles de probar, otras tienen una estructura más compleja y tardan más en verificar. Ajustar los costos de 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 escenarios 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 estado o la lista de transacciones) con alternativas compatibles con STARK podría acelerar aún más los procesos de prueba. Estos cambios ayudarían a Ethereum a alcanzar sus objetivos de escalabilidad y seguridad, al tiempo que harían que su visión de verificabilidad sea más realista.

Los esfuerzos de Ethereum para habilitar pruebas de ejecución representan una oportunidad significativa para lograr sus objetivos de verificabilidad. Sin embargo, alcanzar este objetivo requiere no solo innovaciones técnicas sino también un aumento en los 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 encontrar un equilibrio entre ser accesible a una amplia base de usuarios y preservar la descentralización y alinearse con la infraestructura existente. Establecer este equilibrio aumenta la complejidad de los métodos utilizados para demostrar operaciones durante la ejecución, destacando la necesidad de avances como la generación paralela de pruebas. Además, los requisitos de infraestructura de estas tecnologías (por ejemplo, tablas de búsqueda) debe implementarse y operacionalizarse, lo cual aún requiere una investigación y desarrollo sustanciales.

Por otro lado, los circuitos especializados (por ejemplo, ASIC, FPGAs, GPUs) diseñados específicamente para ciertas 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 evitan que dicho hardware sea accesible solo a un grupo selecto de actores. Como resultado, se espera que estas soluciones vean un uso más extensivo 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 de diseño: ¿debería la generación de pruebas funcionar en hardware de grado de consumo como computadoras portátiles de gama alta, o requerir infraestructura industrial? La respuesta da forma a toda la arquitectura de Ethereum, permitiendo una optimización agresiva para las soluciones de Capa 2 mientras exige enfoques más conservadores para la Capa 1.

Finalmente, la implementación de las pruebas de ejecución está directamente vinculada a otros objetivos del plan 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 individual sean más accesibles. El objetivo es permitir el staking incluso en dispositivos de baja especificación. Además, la reestructuración de los costos de gas en el EVM basada en la dificultad computacional y la demostrabilidad podría minimizar la brecha entre los escenarios promedio y los peores casos. Sin embargo, tales cambios podrían romper la compatibilidad con el sistema actual y obligar a los desarrolladores a reescribir su código. Por esta razón, la implementación de las pruebas de ejecución no es solo un desafío técnico, sino un viaje que debe diseñarse para mantener los valores a largo plazo de Ethereum.

Último paso para la verdadera plena verificabilidad: Consenso

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

El consenso probabilístico se basa en un modelo de comunicación de 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 un índice de error del 0%.

Una ventaja de la estructura probabilística es que cada nodo no difunde su vista de la cadena como un mensaje separado, lo que reduce la sobrecarga de comunicación. En consecuencia, esta estructura puede funcionar con muchos más nodos descentralizados y sin permisos con requisitos de sistema más bajos. En contraste, el consenso determinista opera a través de un modelo de comunicación de uno a todos. Aquí, 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 eventualmente a sus límites. Sin embargo, la mayor ventaja del consenso determinista es la disponibilidad de votos concretos, lo que te permite saber exactamente qué nodo votó por qué bifurcación. Esto garantiza una finalidad rápida y definitiva de la cadena, lo que garantiza que los bloques no puedan cambiar su orden y los hace verificables.

Para proporcionar un mecanismo de consenso verificable mientras se preserva la descentralización y una estructura sin permisos, Ethereum ha logrado un equilibrio entre slots y epochs. Los slots, que representan intervalos de 12 segundos, son las unidades básicas donde un validador es responsable de producir un bloque. Aunque el consenso probabilístico utilizado a nivel de slot permite que la cadena opere de manera más flexible y descentralizada, tiene limitaciones en cuanto al orden definitivo y la verificabilidad.

Los Epochs, que abarcan 32 slots, introducen un consenso determinista. En este nivel, los validadores votan para finalizar el orden de la cadena, asegurando la certeza y haciendo que la cadena sea verificable. Sin embargo, aunque esta estructura determinista proporciona verificabilidad a través de votos concretos a nivel de epoch, no puede ofrecer una verificabilidad completa dentro de los epochs mismos debido a la estructura probabilística. Para abordar esta brecha y fortalecer la estructura probabilística dentro de los epochs, 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 Altair para superar las limitaciones del consenso probabilístico de Ethereum y mejorar la verificabilidad de la cadena para clientes ligeros. El comité está formado por 512 validadores seleccionados al azar que sirven durante 256 épocas (~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. La operación del Comité de Sincronización se puede resumir de la siguiente manera:

1. Formación del Comité:
   Se seleccionan aleatoriamente 512 validadores de todos los validadores en la red. Esta selección se actualiza regularmente para mantener la descentralización y evitar depender de un grupo específico.
2. Generación de Firma:
   Los miembros del comité producen una firma que representa el estado más reciente de la cadena. Esta firma es una firma colectiva de BLS creada por los miembros y se utiliza para verificar la validez de la cadena.
3. Verificación del cliente ligero:
   Los clientes ligeros pueden verificar la corrección de la cadena simplemente comprobando la firma del Comité de Sincronización. Esto les permite rastrear de forma segura la cadena sin descargar datos de cadenas pasadas.

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 recortar validadores por comportamiento malicioso, incluso si los validadores seleccionados actúan intencionalmente en contra del protocolo. Como resultado, muchos consideran que el Comité de Sincronización representa un riesgo para la 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 Sync Committee Slashings.

La ausencia de un mecanismo de reducción en el protocolo no es una elección de diseño, sino una necesidad derivada de la naturaleza del consenso probabilístico. El consenso probabilístico no proporciona garantías absolutas sobre lo que un validador observa. Incluso si la mayoría de los validadores informan que una bifurcación en particular es la más pesada, todavía puede haber validadores excepcionales que observen una bifurcación diferente como más pesada. Esta incertidumbre dificulta demostrar la intención maliciosa y, por lo tanto, imposible penalizar el mal comportamiento.

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 proviene del diseño o funcionamiento mecánico 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 dicho modelo. Sin embargo, esto no elimina las debilidades del consenso probabilístico en 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, existen esfuerzos en curso en el ecosistema de Ethereum para rediseñar el mecanismo de consenso e implementar soluciones que proporcionen finalidad determinista en periodos más cortos. Propuestas como Orbit-SSFy3SFpretende reformar la estructura de consenso de Ethereum desde cero, creando un sistema más efectivo para reemplazar el consenso probabilístico. Tales enfoques buscan no solo acortar el tiempo de finalización de la cadena, sino también ofrecer una estructura de red más eficiente y verificable. La comunidad de Ethereum continúa desarrollando activamente y preparando estas propuestas para su implementación futura.

Snarkificación del consenso

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 zk-proof, en lugar de reemplazarlos por completo. Este enfoque busca modernizar los procesos de consenso de Ethereum mientras preserva sus principios fundamentales 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 crítico 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. Veamos más de cerca estas operaciones y los desafíos a los que se enfrentan.

• ECADDs:
  • Propósito: Esta operación se utiliza para agregar claves públicas de validadores y es vital para garantizar la precisión y eficiencia de la cadena. Gracias a la naturaleza agregable de las firmas BLS, múltiples firmas pueden combinarse en una sola 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 grupos grandes de validadores de manera más efectiva hace que esta operación sea crítica.
  • Desafíos: Como se mencionó anteriormente, los validadores de Ethereum votan sobre el orden de la cadena durante las épocas. Hoy en día, 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 a los validadores votar por ranura durante una época, donde solo 1/32 de todos los validadores votan por ranura. Si bien este mecanismo reduce la sobrecarga de comunicación en la red y hace que el consenso sea más eficiente, dado el número actual de validadores, alrededor de 34,000 validadores votan en cada ranura. Esto se traduce en aproximadamente 34,000 operaciones ECADD por ranura.
• Pares:
  • Propósito: Las operaciones de emparejamiento se utilizan para verificar las firmas BLS, asegurando 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 demostrarlo utilizando tecnología de prueba zk. Esto presenta un desafío importante al 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 certificaciones (firmas agregadas) por ranura, lo que resulta en menos operaciones de emparejamiento en comparación con ECADDs. Sin embargo, la falta de amistad zk en estas operaciones plantea un desafío significativo. Probar una operación de emparejamiento con zk-pruebas es miles de veces más costoso que probar una operación ECADD [2]. Esto hace que adaptar 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, asegurando la integridad de los datos de la cadena. Sin embargo, su falta de amigabilidad con zk conlleva ineficiencias en los procesos de verificación basados en pruebas zk, lo que supone 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 incompatibilidad con zk afecta a los objetivos de verificación basados en pruebas zk de Ethereum. Por ejemplo, entre dos épocas, cada validador ejecuta 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 sistemas basados en pruebas zk. Esto crea una barrera sustancial para alinear el mecanismo de consenso de Ethereum con tecnologías zk.

Las operaciones de 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 amistad con zk plantea desafíos significativos en el camino hacia el logro de estos objetivos. Las operaciones de ECADD crean una carga costosa debido al alto volumen de votos de los validadores, mientras que las operaciones de Pairing, a pesar de ser menos numerosas, son miles de veces más caras de demostrar con pruebas zk. Además, la falta de amistad con zk de las funciones hash SHA256 hace que sea extremadamente difícil demostrar la transición de estado de la cadena de faros. 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" con el objetivo de transformar fundamental y comprehensivamente 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. En contraste, los avances tecnológicos han progresado rápidamente, superando ampliamente la naturaleza estática de la Beacon Chain.

En su presentación, Justin Drake enfatizó que Ethereum ha aprendido lecciones significativas durante estos cinco años en áreas críticas como la comprensión de MEV, avances en tecnologías SNARK y conciencia retrospectiva de 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 visual resume estos diseños y el plan de acción propuesto:

• Las cajas 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 perturbar la arquitectura existente de Ethereum.

• Por otro lado, las cajas rojas significan cambios de gran escala, alta sinergia y fundamentales que deben implementarse juntos. Según Drake, estos cambios tienen como objetivo avanzar en la capacidad y 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 de hash SHA256 en la Beacon Chain de Ethereum. Si bien SHA256 desempeña un papel central en garantizar la seguridad de la red y procesar transacciones, su falta de compatibilidad con zk plantea un obstáculo significativo para alcanzar los objetivos de verificabilidad de Ethereum. Su alto costo computacional e 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 amigables 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 zk-proof.

En este contexto, vemos que Ethereum no solo enfrenta desafíos con funciones de hash no amigables para 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 serán obsoletas para 2030 y estarán completamente prohibidas para 2035. Esto requiere una transición para Ethereum y redes similares hacia alternativas más resistentes en el futuro, como firmas cuánticas seguras.

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

Como destacó 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 bloques de construcción fundamentales de la criptografía moderna. Esta propiedad garantiza que incluso las computadoras cuánticas no pueden ingeniar eficientemente la entrada original a partir de un hash dado, preservando su seguridad. Los sistemas de firma basados en hash permiten a los validadores y atestiguadores generar firmas basadas completamente en funciones hash, asegurando la seguridad poscuántica y proporcionando 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 a prueba de futuro.

Este sistema se basa en combinar firmas basadas en hash y SNARKs basados en hash (pruebas similares a STARK) para crear esquemas de firmas 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 en gran medida los procesos de verificación. Por ejemplo, las miles de firmas de validador producidas para una sola ranura en Ethereum pueden ser representadas por una única firma agregada, ahorrando tanto espacio de almacenamiento como potencia computacional.

Sin embargo, la característica más notable de este esquema es su agregación infinitamente recursiva. Es decir, un grupo de firmas puede combinarse aún más 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 actualmente inalcanzables con BLS.

Conclusiones finales y conclusión

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

Una de las propuestas más ambiciosas es Beam Chain, una rediseño integral de la capa de consenso de Ethereum. Al abordar las limitaciones de Beacon Chain e incorporar alternativas zk-friendly, este enfoque tiene como objetivo mejorar la escalabilidad de Ethereum preservando sus principios fundamentales de descentralización y accesibilidad. Sin embargo, la transición también pone de manifiesto los desafíos que Ethereum enfrenta al equilibrar las demandas computacionales con su objetivo de mantener una red permisiva e inclusiva.

Con la planificación del NIST de eliminar gradualmente la criptografía de curva elíptica actual para 2035, Ethereum debe adoptar soluciones resistentes a la computación cuántica como firmas basadas en hash y Poseidon. Estas soluciones presentan sus propios compromisos de eficiencia.

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

A pesar de estos avances, aún existen desafíos clave. Ethereum debe sortear problemas de amistosidad zk, escalabilidad de consenso y las complejidades de integrar criptografía resistente a la computación cuántica. Además, la compatibilidad inversa 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 también su enfoque iterativo para resolver algunos de los problemas más difíciles en blockchain. El camino hacia adelante, ya sea a través de tecnologías como Beam Chain, Verkle Trees o pruebas STARK, depende de un esfuerzo colaborativo por parte de desarrolladores, investigadores y la comunidad en general. Estos avances no se tratan de lograr la perfección de la noche a la mañana, sino de crear una base para una internet transparente, descentralizada y verificable.

La evolución de Ethereum subraya 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 convierten en la norma, no en la excepción.

Descargo de responsabilidad:

1. Este artículo es una reimpresión de[Investigación 2077]. Todos los derechos de autor pertenecen al autor original [ Koray Akpinarr]. Si hay objeciones a esta reimpresión, por favor contacte al Gate Learnequipo, y ellos lo manejarán rápidamente.
2. Renuncia de responsabilidad: Las vistas y opiniones expresadas en este artículo son únicamente las del autor y no constituyen ningún consejo de inversión.
3. Las traducciones del artículo a otros idiomas son realizadas por el equipo de gate Learn. A menos que se indique lo contrario, está prohibido copiar, distribuir o plagiar los artículos traducidos.