Introducción

En 2024, ocurrieron muchos eventos significativos en torno a Ethereum. A principios de año, Ethereum introdujo blobs a través de la actualización Dencun. Esta actualización redujo drásticamente los costos de transacción para los rollups existentes, sentando las bases para la rápida expansión de los ecosistemas rollup.

(Reducción de tarifas en las OP Chains después de la actualización Dencun | Fuente:Optimismo X)

Sin embargo, a medida que las dapps dentro del ecosistema migraron a rollups altamente escalables y redes alternativas de Capa 1 (L1), la actividad de los usuarios en Ethereum mismo comenzó a disminuir. Además, a medida que los rollups dejaron de enviar altas comisiones a Ethereum, comenzaron a surgir preocupaciones dentro de la comunidad.

Además, 2024 fue un año en el que las L1 centradas en la escalabilidad, como Solana y Sui, demostraron una fuerza significativa. El enorme TPS (transacciones por segundo) generado por estas redes hizo que la actividad en los rollups pareciera relativamente pequeña.

En este contexto, surgieron críticas como "La hoja de ruta centrada en rollup de Ethereum es defectuosa" o "El desarrollo de Ethereum es demasiado lento para tener éxito". ¿Está Ethereum realmente en el camino correcto? ¿Cómo se verá Ethereum en 2025 o incluso en 2030?

Esta serie explora partes del plan de Ethereum bajo dos temas principales, analizando su futuro basado en detalles técnicos. El primer tema es la Beam Chain.

¿Cuál es la propuesta de Beam Chain y por qué es importante?

Si uno tuviera que elegir el tema más comentado dentro de la comunidad de Ethereum este año, probablemente sería el anuncio del investigador de Ethereum Justin Drake sobre la Beam Chain en Devcon. Este anuncio generó mucho interés y, en consecuencia, mucho ruido. Analicemos lo que significa esta propuesta.

La idea principal de la propuesta de Beam Chain es rediseñar completamente la capa de consenso de Ethereum. Justin Drake presentó las siguientes tres razones por las cuales la capa de consenso actual, la Beacon Chain, necesita ser rediseñada:

• Mejor comprensión de MEV a través de experiencias pasadas
• Avances rápidos en la tecnología SNARK (por ejemplo, el desarrollo de zkVM avanza a una velocidad sorprendente, más de 10 veces más rápido)
• Eliminando la "deuda técnica" presente dentro de la Beacon Chain

Actualmente, la hoja de ruta de la capa de consenso de Ethereum incluye los siguientes elementos:

Entre estos, las cuatro áreas marcadas en negrita representan cambios fundamentales que van más allá de simples modificaciones en Beacon Chain. Por ejemplo, la snarkificación de la cadena se refiere a convertir el manejo de estados de la capa de consenso a tecnología ZK, lo que requiere cambios fundamentales que van desde las funciones hash hasta los métodos de merkleizar/serializar el estado.

Además, ranuras más rápidas y finalidad más rápida son nuevos diseños propuestos para lograr mejoras de rendimiento manteniendo la seguridad, un factor no priorizado en los diseños iniciales. Implementar esto requiere cambios extensos en la capa de consenso.

La Beam Chain propone lograr estos cambios a través de una sola bifurcación dura. En resumen:

1. Implementar la hoja de ruta de la capa de consenso de Ethereum requiere una rediseño completo de la capa de consenso.
2. Con este fin, los cambios importantes en la hoja de ruta se agruparán en una bifurcación dura llamada Beam Chain.
3. Incluye cuatro elementos: tiempos de bloque más rápidos, finalización más rápida, snarkificación de cadena y resistencia cuántica.

A continuación, exploremos cómo se implementa cada uno de ellos y los impactos técnicos que conllevan.

Detalles técnicos del diseño de la cadena Beam

Ranuras más rápidas y finalidad más rápida

Actualmente, el tiempo de ranura de Ethereum es de 12 segundos, y tarda de 2 a 3 épocas (aproximadamente 15 minutos) para que un bloque conectado a una ranura alcance la finalidad. Mejorar estos tiempos tendría un impacto positivo en los usuarios, aplicaciones y rollups de Ethereum que se están construyendo.

Mayor finalidad (Orbit SSF)

Este tema, conocido entre los investigadores de Ethereum como SSF (Finalidad de un Solo Slot), tiene como objetivo reducir el tiempo para que los bloques de Ethereum alcancen la finalidad de unos 15 minutos a unos 12 segundos, proporcionando a los usuarios una confirmación más rápida. Para entender la finalidad de un solo slot, debemos comprender el algoritmo de consenso actual de Ethereum, Gasper.

Un principio clave de diseño de Gasper es asegurar que un bloque propuesto en una ranura alcance cierto nivel de seguridad económica después de un tiempo establecido, minimizando la carga de comunicación en cada validador. Para lograrlo, Ethereum divide todo el conjunto de validadores en comités distribuidos en 32 ranuras. Cada ranura puede contener hasta 64 comités, y el objetivo es componer cada comité de 128 validadores (aunque este número puede aumentar si el número total de validadores activos supera esto).

Los validadores dentro de cada comité verifican independientemente el bloque y votan sobre él utilizando firmas BLS. El mecanismo de firma BLS permite que múltiples firmas se agreguen en una, lo que significa que un nodo designado dentro del comité recopila estas firmas y las compila en un paquete de datos compacto único. Al transmitir esta firma agregada, el próximo proponente de bloque puede confirmar con un mínimo de datos que el bloque ha sido verificado correctamente.

(Agregación de firmas BLS entre los validadores de Ethereum | Fuente: eth2book)

En resumen, Gasper de Ethereum logra tanto la escalabilidad como la seguridad económica a través de los siguientes mecanismos:

• Los validadores se distribuyen en ranuras en comités durante un período de 6.4 minutos, eliminando la necesidad de comunicación directa entre todos los validadores.
• El proceso de firma agregada garantiza que los votos de los validadores en el bloque se puedan verificar utilizando una pequeña cantidad de datos.

Sin embargo, surge un problema porque Gasper opera en base de épocas y la “conectividad” entre épocas debe ser verificada antes de que un slot pueda alcanzar la finalidad. En Gasper, deben pasar como mínimo dos épocas (64 slots) antes de lograr una finalidad equivalente a la seguridad económica completa de Ethereum.

Esto resulta en la siguiente representación diagramática:

(Economic Finality at Gasper | Fuente:Orbit SSF)

Esto presenta diversos desafíos y disminuye la UX. Por ejemplo:

• Al retirar fondos de un CEX (intercambio centralizado) a Ethereum, o viceversa, el período de confirmación puede ser de unos 10 minutos, lo cual es relativamente excesivo.
• Los rollups y las dApps de Ethereum se enfrentan al riesgo de que los bloques L1 en los que confían no se finalicen y puedan invalidarse. Si no se implementan medidas correctas, esto podría causar problemas.

Por ejemplo, en marzo de 2024, Polygon zkEVM experimentó una parada de la cadena que duró más de dos días debido a un manejo inadecuado de la reorganización de Ethereum.

Reducir el tiempo de finalización no es imposible, como demuestran los algoritmos de consenso como Tendermint, que ya se aplican en varios protocolos. Sin embargo, el desafío de adoptar el mecanismo de Tendermint radica en la frecuente comunicación P2P entre los nodos, lo que introduce limitaciones de escalabilidad.

En Tendermint, si el número de nodos es N, su complejidad de mensajes es O(N^3). Esto significa que a medida que aumenta el número de nodos, la frecuencia de comunicación entre ellos crece exponencialmente, lo que restringe la escalabilidad. Por lo tanto, protocolos como Ethereum, con muchos validadores, no pueden adoptar directamente Tendermint tal como está.

Se necesita realizar trabajo adicional para abordar estos problemas y aplicar el consenso de estilo Tendermint a Ethereum.

Una descripción general de la propuesta Orbit SSF

Orbit SSF tiene como objetivo modificar el mecanismo de comité de Gasper para reducir el tiempo de finalidad de ranura manteniendo una alta seguridad económica.

La propuesta es reducir el tamaño de la época de 32 ranuras a una sola ranura (~12 segundos). Sin embargo, como se mencionó anteriormente, esto aumentaría el uso de recursos para la comunicación de los validadores, afectando negativamente la descentralización de Ethereum.

Para abordar esto, Orbit SSF propone las siguientes ideas:

Aumentar la cantidad máxima de apuesta para cada validador de Ethereum puede lograr el mismo nivel de seguridad económica con menos validadores.

En lugar de tener múltiples comités por ranura, Orbit SSF sugiere introducir un único “super comité”. Los validadores con cantidades de participación más altas casi siempre serían incluidos de manera proporcional en el comité, asegurando que se mantenga el mismo nivel de seguridad económica incluso con menos comités.

La próxima actualización de Ethereum, Pectra, incluye EIP-7251, que propone aumentar la cantidad máxima de apuesta (MaxEB) para los validadores de 32 ETH a 2048 ETH. Si bien esta propuesta es atractiva para los operadores de infraestructura de nodos de Ethereum, también es un requisito previo para Orbit SSF.

Sin embargo, si los validadores con grandes cantidades de participación son casi siempre incluidos en comités, los validadores solitarios más pequeños podrían experimentar recompensas reducidas, lo que podría dañar potencialmente la descentralización de Ethereum. Para prevenir esto, Orbit SSF ajusta las recompensas para que la TAE aumente linealmente con la cantidad de participación, asegurando al mismo tiempo que los validadores más grandes sean incluidos en comités con más frecuencia.

(Recompensa y probabilidad de ser incluido en el comité en Orbit SSF | Fuente:Orbit SSF)

Además, Orbit SSF se inclina hacia la 'finalidad basada en comités'. En Gasper, los comités solo podían contribuir a la finalidad después de que hubieran pasado dos o más épocas, pero Orbit SSF permite que cada comité asignado a una ranura contribuya a la finalidad en tiempo real. Su objetivo es hacer que los comités sean contribuyentes más activos a la finalidad y lograr una escalabilidad más rápida.

(Finalidad en Orbit SSF utilizando Cap-and-slow-rotate | Fuente:Orbit SSF)

La clave aquí radica en la composición de los miembros del comité. Orbit SSF propone un mecanismo de "rotación lenta" donde los validadores con grandes apuestas están casi fijos matemáticamente dentro de los comités, mientras que los validadores más pequeños se rotan dentro y fuera. Esto permite que el valor de F, que representa el umbral de seguridad económica, se establezca muy alto al tiempo que se mantiene una sobrecarga mínima de comunicación entre los validadores y se garantizan tiempos de finalización bajos.

Por ejemplo, establecer n = 3 y un F significativamente grande permitiría a Ethereum lograr la finalidad en aproximadamente tres slots, logrando así la visión de Justin Drake de una FFG de 3 slots.

Sin embargo, elevar F al nivel de todo el conjunto de validadores de Ethereum no es fácil. Podría reducir el costo de llevar a cabo un ataque del 51% en Ethereum. Como tal, el desafío principal para Orbit SSF en el futuro es determinar cómo aumentar técnicamente F para garantizar que la seguridad de Ethereum siga siendo sólida sin sacrificar mucha descentralización.

Tiempos de ranura más cortos (ranuras de 4 segundos) Incluso si se logra SSF (o finalidad de 3 ranuras), los usuarios de Ethereum seguirían experimentando un tiempo mínimo de confirmación de transacción de 12 segundos. Esto conlleva dos desventajas principales para los usuarios:

1. Latencia larga en comparación con otras L1 como Solana y Sui
2. Mayor vulnerabilidad a MEV (MEV disminuye a medida que el tiempo de bloque se acorta, lo que hace que los usuarios de Ethereum sean más susceptibles a MEV)

Además, un tiempo de bloque de 12 segundos es particularmente desfavorable para los rollups, especialmente los rollups basados. Por ejemplo, Taiko implementa un rollup basado publicando cada bloque L2 en L1. Como resultado, el tiempo de bloque de Taiko podría aumentar a un mínimo de 12 segundos y, a veces, superar los 24 segundos.

Se han propuesto dos soluciones para abordar esto:

a. Reducir el tiempo de bloque de Ethereum a 4 o 8 segundos

b. Use preconfirmations

Reduciendo el tiempo de bloqueo de Ethereum

Reducir el tiempo de bloqueo de Ethereum es un tema de discusión activa. Se ha formalizado como EIP-7782, que propone reducir el tiempo de ranura de 12 segundos a 8 segundos, aumentando así la escalabilidad de Ethereum en un 33%. Sin embargo, un tiempo de ranura de 8 segundos puede no ser óptimo para la experiencia del usuario o para los rollups basados en. Parece más deseable lograr un tiempo de ranura más corto.

Dicho esto, tiempos de bloque más cortos podrían llevar a una mayor centralización del conjunto de validadores. Debido a limitaciones físicas, los validadores geográficamente distantes enfrentan tiempos de comunicación más largos, y un tiempo de ranura de 4 segundos podría hacer que la comunicación sea inviable en ciertos escenarios.

Las estadísticas de tiempo de propagación de bloques de la red principal de Ethereum proporcionan información sobre la viabilidad de un tiempo de bloque de 4 segundos. El gráfico a continuación muestra la distribución de los tiempos de propagación de bloques.

(CDF de tiempos de llegada de mensajes | Fuente:Latencia de propagación de mensajes de Gossipsub)

Aproximadamente el 98% de los bloques se propagan en 4 segundos, mientras que aproximadamente el 2% tarda más tiempo. Según estos datos, un tiempo de bloque de 4 segundos puede parecer factible. Sin embargo, el tiempo de bloque no solo incluye la comunicación, sino también la ejecución y la votación. Teniendo en cuenta estos factores, solo estarían disponibles alrededor de 2 segundos de un tiempo de bloque de 4 segundos para la comunicación. Bajo estas condiciones, lograr un tiempo de bloque de 4 segundos es un desafío.

Para abordar esto, el tamaño de los datos transmitidos debe reducirse, el rendimiento de los componentes P2P en los clientes debe maximizarse, o la comunicación física debe volverse más eficiente.

Utilizando preconfirmaciones

Mientras tanto, las preconfirmaciones pueden mejorar la experiencia del usuario. Las preconfirmaciones permiten a las entidades que producen bloques prometer a los usuarios: “Su transacción se incluirá en el próximo bloque”, ofreciendo resultados a los usuarios más rápido que el tiempo de ranura.

La ventaja de la preconfirmación es que los validadores de L1 pueden utilizarla sin necesidad de una bifurcación o modificaciones del cliente. Por ejemplo, Commit-Boost es un software que permite a los validadores de Ethereum generar y propagar preconfirmaciones de manera segura.

Commit-Boost, al igual que MEV-Boost, es un acompañante opcional para los validadores, que les permite generar y propagar de manera segura los 'compromisos'. Dependiendo del caso de uso, estos compromisos pueden adoptar diversas formas:

Utilizando el tercer tipo de arquitectura de precónfirmación, la latencia percibida por los usuarios puede reducirse significativamente, incluso con tiempos de bloque más largos. Cuando un validador recibe la transacción de un usuario, puede ejecutarla y devolver el resultado al usuario. Dado que este resultado se basa en el compromiso del validador y no en la creación de bloques, los usuarios pueden recibirlo en cuestión de milisegundos.

Sin embargo, la efectividad de Commit-Boost depende de la adopción de los validadores. Si solo unos pocos validadores lo utilizan, el impacto en la experiencia de usuario será mínimo. Dicho esto, Commit-Boost ha obtenido un fuerte apoyo de la comunidad de Ethereum y tiene el potencial de convertirse en una herramienta ampliamente utilizada como MEV-Boost. Ha recibido el respaldo de operadores de validadores conocidos como Rocket Pool, Renzo, SSV, Luganodes, Nethermind, Puffer, A41 y Figment. Además, ha obtenido subvenciones de EF, Lido y Eigenlayer, y cuenta con un sólido apoyo de Titan, un constructor de bloques.

Sin embargo, como se mencionó anteriormente, es más probable que la preconfirmación se utilice como un acompañante externo fuera de cadena, al igual que MEV-Boost, en lugar de integrarse directamente en el protocolo.

El papel de Beam Chain en ranuras más rápidas

Como se discutió en la presentación de Justin Drake, el objetivo de Beam Chain es reducir los tiempos de bloque. Por lo tanto, la investigación y la implementación probablemente se centrarán en reducir el tiempo de ranura a 4 segundos sin sacrificar la descentralización. Esto podría resolverse con la snarkificación completa de Ethereum, que se explicará en la última parte de este artículo.

Snarkificación en cadena y resistencia cuántica

Justin afirmó en su presentación que el objetivo de Beam Chain es snarkify el cliente de consenso utilizando la tecnología ZK. ¿Qué significa esto, cómo se puede lograr y por qué es necesario?

Snarkificación de la cadena

Actualmente, la Beacon Chain de Ethereum logra consenso al hacer que los validadores "re-ejecuten" cada bloque para verificar que la raíz del estado resultante sea correcta. Este proceso de re-ejecución introduce ineficiencias y actúa como una barrera para reducir los requisitos de hardware para los validadores.

Beam Chain tiene como objetivo reemplazar este proceso de reejecución con "verificación" utilizando la tecnología ZK. Reduciría significativamente los requisitos de hardware para los validadores y permitiría a cualquiera ejecutar un nodo de Ethereum desde cualquier lugar. Para lograr esto, Beam Chain y Ethereum utilizarán ZK SNARKs.

ZK en el protocolo Ethereum

ZK SNARKs tienen las siguientes dos propiedades:

1. Permiten verificar el hecho de que cierto cálculo se haya realizado sin necesidad de volver a ejecutar el cálculo
2. El tamaño de prueba es compacto en comparación con los datos originales

La idea es aplicar ZK a los cálculos y datos necesarios para el consenso en Ethereum, generando una prueba de que la lógica prescrita ha sido seguida. Esto significa que los validadores pueden alcanzar consenso verificando la prueba ZK en lugar de volver a ejecutar todo el bloque y almacenar el estado actualizado. Verificar una prueba ZK es mucho más eficiente en cuanto al tamaño de los datos y la escalabilidad que la reejecución.

Como resultado, los requisitos de hardware para los validadores de Ethereum pueden reducirse drásticamente. Por ejemplo, Vitalik ha expresado en un artículo de The Verge que el objetivo es permitir que los validadores operen incluso en entornos con recursos limitados como los relojes inteligentes.

¿Qué necesita ser hecho?

El primer paso es hacer snarkificar la función de transición de estado. La función de transición de estado generalmente toma la siguiente forma:

f(S,B)=S’

Aquí:

• S: El estado previo de la cadena de bloques
• B: El bloque dado
• S': El estado posterior de la cadena de bloques después de ejecutar el bloque
• f: La función de transición de estado

Todas las blockchain se basan en funciones de transición de estado deterministas, y Ethereum no es una excepción. Ethereum tiene diferentes funciones de transición de estado para sus capas de consenso y ejecución. Snarkificar ambas haría posible verificar todo el sistema Ethereum utilizando ZK, lo que permitiría validadores completamente ligeros.

En Beam Chain, el objetivo es snarkificar la función de transición de estado de la capa de consenso. Actualmente, la función de transición de estado dentro de la capa de consenso de Ethereum se ejecuta en cada ranura y realiza las siguientes acciones:

• Actualiza la información de la ranura y la cabecera del bloque después de recibir un bloque
• Verifica la firma del validador que propuso el bloque
• Valida las transacciones dentro del bloque
• Procesa retiros, slashing, finalización de bloques y otra información cada vez que una época hace la transición

Esta función se ejecuta cada vez que un validador recibe un bloque de otro validador. Si esta función está snarkificada, los validadores ya no necesitarían ejecutar directamente la función de transición de estado. En su lugar, podrían verificar una prueba que demuestre que la función se ejecutó correctamente.

En este caso, ¿quién genera la prueba ZK? Típicamente, uno podría asumir que el proponente del bloque también es responsable de generar la prueba ZK. Sin embargo, es importante tener en cuenta que no todos los validadores pueden generar pruebas ZK.

Beam Chain tiene como objetivo lograr un rendimiento en el que una prueba de conocimiento nula se pueda generar en 3 segundos en una computadora portátil estándar. Sin embargo, incluso si se cumple este objetivo, los validadores que se ejecutan en dispositivos como relojes inteligentes o teléfonos inteligentes pueden no tener recursos suficientes para generar pruebas de conocimiento nulas.

Aquí, la red puede confiar en el altruismo. Solo se necesita una prueba ZK para la transición de estado de la capa de consenso por bloque, y no necesariamente tiene que ser generada por el proponente del bloque. En otras palabras, siempre y cuando al menos una entidad en la red genere una prueba ZK para cada bloque, puede asegurar que los bloques de la Beam Chain se produzcan correctamente.

Futuro: Snarkificación completa de Ethereum

Este cambio por sí solo puede no mejorar significativamente el rendimiento del validador. La función de transición de estado de la capa de consenso implica acciones relativamente livianas en comparación con la función de transición de estado de la capa de ejecución. Sin embargo, el cuello de botella principal no radica en los recursos necesarios para ejecutar la función de transición de estado, sino en el ancho de banda de la red. Los validadores luchan por lograr consenso dentro del tiempo asignado cuando el tamaño de los datos (bloques) que intercambian aumenta. Esta es una de las razones por las que Ethereum ha mantenido un límite de gas de 30M durante los últimos tres años.

Si este cambio se implementa junto con la snarkificación de la capa de ejecución, los validadores solo necesitarían intercambiar cantidades mucho más pequeñas de datos en comparación con bloques enteros. Esto se debe a que las pruebas SNARK son significativamente más compactas que los datos originales. Los validadores de Ethereum completamente snarkificados intercambiarían menos datos, reduciendo los requisitos de red en comparación con el sistema actual.

En resumen, las siguientes son las ventajas de la plena snarkificación de Ethereum para los validadores.

1. Los validadores solo necesitan verificar pruebas, no volver a ejecutar cálculos, lo que reduce las demandas computacionales
2. Los validadores intercambian datos de prueba en lugar de datos de bloque completos, lo que reduce los requisitos de ancho de banda de la red

Como resultado, el ecosistema de Ethereum podría cambiar drásticamente. Por ejemplo:

• Cosas como las “Aplicaciones de Nodo de Ethereum” podrían permitir a los validadores trabajar en dispositivos móviles.
• Cualquier persona que cumpla con los requisitos mínimos de participación puede ejecutar un nodo Ethereum, lo que reduce significativamente la barrera para convertirse en un validador.

Esto haría que la participación de los validadores sea mucho más accesible y descentralizada.

Firmas resistentes a la computación cuántica

¿La snarkificación de la función de transición de estado por sí sola es suficiente para la cadena Beam como capa de consenso?

¿Qué problemas enfrentará Ethereum en un mundo post-cuántico?

Hay otra área en la que Beam Chain tiene como objetivo snarkificar: la generación de firmas. La capa de consenso de Ethereum actualmente utiliza las firmas de los validadores como datos de certificación para finalizar bloques y determinar la cadena correcta en caso de bifurcaciones.

En la actualidad, Ethereum utiliza firmas BLS para este propósito, las cuales, como se explicó anteriormente, tienen la propiedad de agregación, lo que permite combinar múltiples firmas en una sola. Esta agregación mejora significativamente la eficiencia del proceso de consenso de Ethereum. Sin embargo, este mecanismo de firma tiene un problema fundamental: es vulnerable a las computadoras cuánticas.

Las firmas BLS utilizadas en la Beacon Chain de Ethereum se basan en curvas elípticas. La seguridad de los mecanismos de firma basados en curvas elípticas depende del Problema del Logaritmo Discreto (DLP), que la potencia computacional superior de los ordenadores cuánticos podría comprometer. Esto hace que las firmas basadas en curvas elípticas sean inherentemente vulnerables a los ordenadores cuánticos.

La computación cuántica ha estado avanzando rápidamente, como lo demuestran los recientes avances de Google con chips de computación cuántica como Willow. Google afirma que Willow puede realizar cálculos en 5 minutos que llevarían a una supercomputadora 10^25 años. Si bien esto aún no amenaza fundamentalmente la seguridad de las curvas elípticas, los avances continuos a este ritmo podrían poner en riesgo los sistemas de blockchain dentro de unos pocos años.

(Transición a los estándares de criptografía post-cuántica | Fuente: NIST IR 8547)

El Instituto Nacional de Estándares y Tecnología (NIST) de los EE.UU. ya ha comenzado los esfuerzos para estandarizar algoritmos de firma resistentes a la cuántica para hacer frente al colapso anticipado de los sistemas existentes debido a las computadoras cuánticas.

Ethereum también está tomando este problema en serio. En Beam Chain, el objetivo es lograr algoritmos de firma resistentes a la computación cuántica.

Existen varios tipos de firmas resistentes a la computación cuántica, pero la presentación de la Beam Chain de Justin mencionó específicamente los algoritmos de firma basados en hash. A diferencia de las curvas elípticas, las firmas basadas en hash no dependen de mecanismos matemáticos, lo que las hace significativamente más difíciles de comprometer para las computadoras cuánticas. Como resultado, las firmas basadas en hash se consideran resistentes a la computación cuántica, y Beam Chain tiene como objetivo adoptar tales firmas.

Desafíos y el papel de ZK

El principal desafío es que las firmas basadas en hash carecen de la propiedad de agregación presente en las firmas BLS. Ethereum depende de la agregación de firmas durante el consenso para lograr eficiencia. Sin la agregación, Ethereum ya no sería capaz de acomodar un gran conjunto de validadores.

ZK se puede utilizar para abordar esto. Implica aprovechar la Agregación de Pruebas, una tecnología que combina múltiples pruebas ZK en una sola prueba. El mecanismo funciona de la siguiente manera:

(Diagrama de Agregación de Prueba | Fuente: Figment Capital)

1. Los validadores firman un bloque utilizando un algoritmo resistente a la cuántica.
2. Las firmas se envían a un agregador**o Comité de Agregación.
3. El agregador genera una prueba ZK verificando la corrección de las firmas.
4. Utilizando técnicas de agregación de pruebas, el agregador combina nuevas pruebas con las existentes a medida que se reciben nuevas firmas.

Este enfoque permite que Ethereum logre la misma eficiencia que la agregación de firmas BLS al tiempo que alcanza resistencia cuántica a nivel de consenso.

Roles de ZK en Beam Chain

En resumen, Beam chain con ZK traerá las siguientes ventajas:

1. Permitir a los validadores realizar la verificación de prueba en lugar de la reejecución de la función de transición de estado de la capa de consenso, lo que contribuye a los requisitos ligeros del validador.
2. Sirviendo como base para un algoritmo de agregación de firmas resistentes a la computación cuántica, mejorando la eficiencia de la capa de consenso.

zkVM como base para ZK en Beam Chain

El sistema de prueba subyacente de ZK en Beam Chain será zkVM. zkVM basado en Risc-V permite la prueba de cualquier programa en cualquier lenguaje, ofreciendo una mayor flexibilidad.

(La transición de estado de Beam se compilará en Risc-V y se probará en zkVMs | Fuente: Anuncio de Beam Chain por Justin Drake)

Esto se alinea bien con el ecosistema existente de clientes de Ethereum, que se desarrolla en múltiples lenguajes, preservando la diversidad y tolerancia a fallos de Ethereum. En la futura cadena Beam, varios clientes escribirán la función de transición de estado en múltiples lenguajes de programación, la compilarán a Risc-V y permitirán que se demuestre en cualquier zkVM basado en Risc-V. Por esta razón, zkVM es una elección natural para Beam Chain.

Conclusión

Si Beam Chain se implementa con éxito, es probable que Ethereum tenga las siguientes características:

1. Los usuarios experimentarán confirmaciones de transacciones en 4 segundos, con un logro final en 12 segundos.
2. Los validadores verificarán las transiciones de estado en la capa de consenso utilizando pruebas de conocimiento cero (ZK proofs). Si la capa de ejecución también está snarkificada, los validadores solo necesitarán cantidades mínimas de datos para participar en el consenso.
3. Las firmas de los validadores serán resistentes a la computación cuántica
4. t, evitando que los ordenadores cuánticos comprometan el consenso de Ethereum.

Actualmente, Beam Chain no ha sido reconocido oficialmente como parte del plan de Ethereum. Implementarlo requeriría una extensa investigación, desarrollo y pruebas durante un largo período. Sin embargo, si Ethereum continúa con el fork de Beam Chain, las mejoras resultantes en la experiencia del usuario podrían ser transformadoras.

Esto concluye nuestra exploración de cómo Ethereum podría evolucionar en cinco años a través de la lente de Beam Chain. En el próximo artículo, examinaremos cómo podría verse Ethereum en 2025 desde dos perspectivas: UX y resistencia a la censura.

Apéndice: Preguntas frecuentes sobre Beam Chain

(P): La propuesta de Justin Drake se discutió en privado. ¿No entra en conflicto esto con el valor central de Ethereum de ser 'abierto'?

(A): No, no lo hace. La propuesta de la Beam Chain simplemente sugiere implementar ciertas partes del roadmap existente de Ethereum de una vez. Si se implementará o no es algo que aún requiere discusión en la comunidad. Todos los temas discutidos anteriormente ya tienen EIPs asociados o publicaciones en Ethresear.ch. Esto, más o menos, muestra que la Beam Chain no es una propuesta que sugiere una dirección nueva, previamente no revelada para Ethereum. Además, las discusiones sobre el roadmap de Ethereum se llevan a cabo públicamente durante la llamada quincenal de All Core Devs, a la que cualquiera puede unirse. Si alguien no está de acuerdo con el roadmap o tiene nuevas ideas, puede expresar sus opiniones durante estas llamadas o presentar nuevas propuestas en forma de EIPs o publicaciones en Ethresear.ch.

En resumen, la propuesta de Beam Chain de Justin no se trata de cambiar la hoja de ruta, sino de agrupar partes de la hoja de ruta bajo un solo nombre o meme.

(Q): ¿No es demasiado tiempo implementar Beam Chain en 5 años?

(A): Cinco años pueden parecer mucho tiempo, pero se deben considerar dos factores:

1. Ethereum se basa en una arquitectura de múltiples clientes.
2. Ethereum tiene el mayor número de validadores de cualquier blockchain.

(Diversidad de clientes de consenso | Fuente: Diversidad de Clientes Ethereum)

El mecanismo de consenso de Ethereum sigue un protocolo basado en BFT donde si más de un tercio de los validadores actúan de manera diferente a otros, los bloques no pueden ser finalizados. Si Ethereum fuera construido con solo uno o dos clientes, cualquier error en estos clientes podría interrumpir la producción de bloques. Por lo tanto, Ethereum siempre ha apuntado a una arquitectura multi-cliente desarrollada en múltiples lenguajes de programación. Esta diversidad es evidente en el ecosistema actual de clientes de Ethereum.

Como se muestra en la imagen, la capa de consenso de Ethereum opera actualmente con al menos cuatro clientes. Para reemplazar la Beacon Chain con la Beam Chain, los cuatro equipos de clientes deben colaborar en el desarrollo. Teniendo en cuenta esto y el gran conjunto de validadores de Ethereum, el proceso de desarrollo de Beam Chain debe priorizar la estabilidad y no puede acelerarse en un plazo de unos pocos meses o 1-2 años.

Descargo de responsabilidad:

1. Este artículo es un extracto de [.2077research]. Todos los derechos de autor pertenecen al autor original [sm-stack]. Si hay objeciones a esta reimpresión, por favor contacte al Aprendizaje de la puertael equipo y ellos lo resolverán rápidamente.
2. Descargo de responsabilidad: Las opiniones expresadas en este artículo son únicamente las del autor y no constituyen ningún consejo de inversión.
3. El equipo de Learn de gate realiza traducciones del artículo a otros idiomas. A menos que se mencione, está prohibido copiar, distribuir o plagiar los artículos traducidos.