Autores: krane, lamby (Asula), sylve, lancelot (Hyle) Fuente: investigaciones bedlam Traducción: Shanon, Golden Finance

Introducción

Durante la última semana, hemos visto múltiples propuestas sobre la hoja de ruta de Consenso de Ethereum (ETH). Lo más destacado fue la exposición de Justin Drake en Devcon 2024, en la que presentó su visión para la era ZK de ETH, llamada beam chain o beam fork. Esto permitiría la implementación de importantes actualizaciones para ETH, como la reducción del tiempo de slot, la aceleración de la finalidad y la 'snarkificación' del Consenso de ETH en cantidades masivas. La reacción de la gente a estas ambiciosas propuestas y la línea de tiempo para estos cambios ha sido mixta. Sin embargo, considerando la escala económica de ETH, también deberíamos reconocer cuán importante es tratarlo con precaución. A pesar de esto, es útil considerar cuál es la ambiciosa visión futura del ecosistema centrado en rollup en la capa base. En el espíritu de 'no ser retenidos por el pasado, sino solo por el futuro', este artículo presenta una forma de estudiar el progreso de la investigación de ZK y Consenso en el futuro.

Comenzaremos estudiando la capa base desde una perspectiva de principios básicos, luego exploraremos los conceptos fundamentales en la investigación del Consenso. Por último, analizaremos en profundidad cómo aplicar esta investigación al diseño de la próxima generación de capa base, especialmente en el mecanismo ZK.

Capa base

Hoy en día, la mayoría de los Rollup utilizan un ordenador centralizado para ordenar y ejecutar las transacciones. Una vez que el ordenador genera un bloque, también es responsable de generar una prueba de ejecución para que otros la verifiquen. Para que la ejecución sea verificable, terceros necesitan los datos de estado del Rollup y la prueba de ejecución. Los datos de estado y la prueba suelen ser publicados en la capa de disponibilidad de datos (DA) y la capa de verificación (a menudo erróneamente llamada capa de liquidación) verifica la transición de estado.

En las primeras etapas, Ethereum estableció una hoja de ruta centrada en rollup y se convirtió en la capa base original, ejecutando tanto DA como verificación. El estado único de Ethereum, que es una gran cantidad de activos valiosos emitidos en Ethereum, lo convierte en una capa de verificación o Asentamiento natural para rollup. Al utilizar Ethereum como base, rollup no solo puede heredar su seguridad, sino también su Liquidez. Sin embargo, en ese momento no había opciones específicas de Asentamiento o DA en el mercado.

Incluso en el mundo de hoy con muchas capas especializadas, Ethereum con la mayor cantidad de validadores PoS y soporte de blob como capa de DA es una opción muy segura. Además, el número de familias de activos en Ethereum y la capitalización de mercado han estado subiendo constantemente. Dado que 'Asentamiento' es específico de los activos, la verificación debe realizarse en cadena para los activos de emisión en rollup que permiten salidas forzosas. Si un rollup desea permitir la emisión de activos de Ethereum para salidas forzosas, debe realizar la verificación en Ethereum.

Hoy, la red de Ethereum se ve así:

Sin embargo, las capas especializadas de DA y Asentamiento también compiten directamente con ETH para llevar a cabo estas operaciones. Por ejemplo, Celestia y EigenDA ya ofrecen una capacidad de procesamiento de DA significativamente mayor (aunque con un modelo de seguridad diferente). Del mismo modo, Initia está ampliando el concepto de verificación o centro de Asentamiento al proporcionar una experiencia de billetera unificada, máquina de oráculo incorporada y interoperabilidad integrada, brindando una experiencia más fluida a los usuarios dentro del ecosistema (lo cual también se ha convertido en un punto importante en el roadmap de ETH en los últimos meses).

Todos estos sistemas adoptan la misma forma que ETH, donde la capa base se descompone en disponibilidad y verificación de datos, y cada capa actúa como un centro especializado para sus propias operaciones:

La idea clave del nuevo diseño es la optimización y separación de la capa DA y la capa de validación. El propósito original de la cadena de bloques era lograr la descentralización de terceros confiables entre dos partes que no confían mutuamente. En un sistema centrado en rollup, el papel de la capa base es actuar como un tercero confiable de descentralización entre los rollup para lograr su interoperabilidad. Una vez que la capa base valida el estado del rollup, todos los demás rollup pueden confiar implícitamente en la capa base. Otra característica central del diseño centrado en rollup es que permite a las aplicaciones proporcionar a los usuarios acceso rápido y económico a la confirmación de transacciones en condiciones promedio (a través de un ordenador en cierta medida centralizado), sin comprometer la resistencia a una revisión final en casos extremos (mediante la salida forzada de la capa base).

Dado nuestro entendimiento de la separación entre la disponibilidad de datos y la validación, así como la funcionalidad central en la emisión de activos y la interoperabilidad entre la resistencia final y Rollup en la capa base, podemos inferir cómo construir una capa base mejor. En este momento, Rollup publica datos de estado en la capa base cada pocas horas, lo que significa que las preconfirmaciones proporcionadas por el ordenador de Rollup solo se finalizan en la base durante este período de tiempo. La mayor capacidad de procesamiento de datos en la capa base que en ETH L1 puede permitir a Rollup publicar datos con más frecuencia, reduciendo el tiempo desde la preconfirmación en Rollup hasta la confirmación en la capa base, lo que aumenta la seguridad de Rollup. Del mismo modo, la verificación a una velocidad más alta puede lograr una interoperabilidad más rápida entre Rollup, sin la necesidad de puentes de liquidez y creadores de mercado. Podemos utilizar información concreta sobre la forma en que se debe manejar la carga de trabajo en la capa base para construir una capa base con mayor capacidad de procesamiento y comunicación más rápida entre Rollup.

La integración de la cadena de bloques tiene áreas de 'estado caliente', como los DEX pools que a menudo son atacados. Esto hace que el orden relativo de las transacciones de todos los participantes sea muy importante. Por otro lado, los rollup generalmente funcionan en un espacio de estado ampliamente independiente, donde la mayoría de las transacciones solo afectan al estado interno de su propio rollup. Si bien las interacciones entre rollups ocurren (por ejemplo, cuando los usuarios transfieren activos entre rollups o combinan rollups), estas interacciones son explícitas, definidas y conocidas de antemano. Dado que la mayoría de las transacciones en cada rollup funcionan en un estado desvinculado y las transacciones entre rollups se manejan a través de mecanismos de interoperabilidad específicos, la necesidad de un estricto ordenamiento global de datos en la capa base es menor. En cambio, el ordenamiento solo se realiza selectivamente cuando los rollups interactúan explícitamente.

Dos Rollup publican una lista de diferencias de estado y sus transiciones de estado a la capa base con una prueba de conocimiento cero (ZK)

注意：Suponemos que Rollup publica aquí una lista de diferencias de estado y su prueba de conocimiento cero (ZK) de la transición de estado de Rollup.

Las ideas clave aquí giran en torno a las relaciones de causa y efecto entre las transacciones, y respaldan el extenso trabajo realizado en torno al modelo de Consenso de Gráfico Acíclico Dirigido (DAG). En general, el Algoritmo DAG intenta identificar explícitamente las dependencias para que los cálculos/procesamientos puedan realizarse en paralelo. Inspirados en estas ideas, anticipamos que surgirá una capa base de rollup, donde el Consenso se relajará en gran medida para admitir una mayor capacidad de procesamiento y una menor latencia.

La división natural del estado de Rollup indica que puede ser innecesario obligar a todas las transacciones de Rollup a seguir un orden total. Los sistemas como delta y Hylé aprovechan esta idea permitiendo que Rollup funcione de forma independiente, solo requiriendo la coordinación de transferencias de activos entre dominios. Sin embargo, esto no elimina por completo el consenso; más bien, es una mejora en los lugares donde el consenso es realmente necesario. La innovación radica en reconocer que este ordenamiento puede limitarse a los lugares donde realmente se necesite, en lugar de aplicarse globalmente en todas las transacciones.

El mayor impacto de esta partición es crear una solución elegante de Rollup para aumentar el rendimiento del entorno de ejecución especializado sin sacrificar la capacidad de combinación con otros Rollups.

Orden causal y orden total

Antes de continuar con la discusión, vamos a repasar primero la clasificación. En un sentido amplio, Consenso es el acuerdo general de todos los Nodos en la red sobre la clasificación de transacciones válidas:

• La cadena de bloques lineal debe lograr un consenso total sobre el orden completo de las transacciones, es decir, un orden lineal completo de eventos a la vista de todos los nodos participantes. Las transacciones no relacionadas se colocarán ordenadamente en el orden global.
• Por otro lado, el orden causal solo es un ordenamiento de transacciones, es decir, las transacciones que ocurren primero se colocan antes que las transacciones que dependen de sus salidas. Las transacciones sin relación causal no necesitan ser ordenadas entre sí. Esto también se conoce como un orden parcial. DAG es simplemente una estructura de datos que implementa un orden parcial en un conjunto de transacciones. El orden parcial también abre la puerta a transacciones paralelas entre partes no intersecantes en el DAG. Aquí no hay un único orden global de transacciones que todos los nodos estén de acuerdo.

La totalidad puede construirse sobre el DAG. Requiere un Mecanismo de consenso adicional para lograr consenso sobre el orden de eventos concurrentes. Un ejemplo de esto es la evolución más reciente en Narwhal And Tusk o el protocolo Mysticeti de SUI.

Las transacciones dentro de DAG pueden confirmarse de forma independiente a otras transacciones no relacionadas. Una vez que una transacción recibe la aprobación de la mayoría de los validadores, se considera válida. Permitir la confirmación individual de transacciones en lugar de confirmarlas en un Bloquear puede aumentar significativamente la capacidad de procesamiento de transacciones, ya que permite proponer y confirmar muchas transacciones en paralelo. Esto puede considerarse como una generalización del Consenso de líder único, donde cualquier validador puede proponer nuevas transacciones (Nota: esto también puede considerarse como proponer un Bloquear que contiene una única transacción).

Resumamos el principio de verificación de transacciones en DAG:

• Los usuarios envían un subconjunto de Emisión de transacciones a los nodos validadores.
• Cuando Nodo recibe una transacción, primero verifica si la transacción está en conflicto con cualquier transacción que conozca actualmente, según la vista local del gráfico.
• Si hay conflictos, como intentar gastar la misma cantidad de dinero, la transacción será rechazada.
• Si no hay conflictos, el Nodo receptor interactuará con otros Nodos en la red para llegar a algún tipo de consenso sobre la validez de la transacción. Uno de los métodos es el muestreo de subconjuntos, donde el Nodo comienza varias rondas de consultas, muestreando un subconjunto de otros Nodos y preguntándoles si consideran que la transacción es válida según su punto de vista local. Si el umbral de respuesta positiva del Nodo muestreado se cumple, se considera que la ronda de consulta es exitosa y se alcanza un número mínimo requerido. Este proceso se repite hasta que el Nodo tenga plena confianza en la validez de la transacción. Este proceso permite que el Nodo alcance rápidamente un consenso probabilístico sobre la validez de la transacción sin necesidad de un consenso global. El muestreo repetido ayuda a garantizar que toda la red alcance un consenso, lo que hace extremadamente improbable que se acepten transacciones conflictivas al mismo tiempo.

Realizar submuestreo de verificación de transacciones

Es importante destacar que cualquier Nodo puede ejecutar este proceso interactivo en cualquier momento para alcanzar el número requerido por ley, lo que permite múltiples vías para lograr el Consenso. En cierto sentido, cada validador o copia está ejecutando su propia cadena de bloques y se sincroniza periódicamente con otros Nodos. Esta idea de avanzar con múltiples cadenas de bloques antes de la coordinación también se ha explorado en diseños no DAG, como Autobahn (que aún depende de la separación de la propagación y el ordenamiento de datos). En Autobahn, cada validador mantiene su propio canal de transacciones y luego se coordina durante el proceso de sincronización. Aunque no se les denomina explícitamente como cadenas de bloques en este artículo, consideramos que los canales son muy similares a las cadenas de bloques, y el proceso de sincronización se asemeja a fusionar varias cadenas de bloques.

Relación de causa y efecto en la capa base

Ahora que entendemos el concepto de causalidad, podemos intentar reconstruir la relación entre este concepto y la capa base. Como se mencionó anteriormente, el rollup suele publicar datos de estado o listas de diferencias de estado, que corresponden a actualizaciones de estado en su propia partición persistente. Los datos publicados por dos rollups no entran en conflicto con algunos 'estados calientes' entre sí, ya que los datos no se superponen en absoluto. Esto relaja la necesidad de un orden global en la capa base. Además, para verificar el nuevo estado de rollup, solo es necesario verificar el estado de rollup publicado previamente. Por lo tanto, la capa base puede ordenar libremente estas transacciones de rollup, permitiéndoles operar de forma independiente entre sí, sin necesidad de esperar un orden global.

En un sentido más amplio, rollup debería poder publicar datos y pruebas en la capa base libremente, sin preocuparse por los costos. A medida que los datos se propagan en la red, los validadores de la capa base verificarán las pruebas publicadas por el ordenador de rollup. Si un número determinado de validadores verifica la prueba, se asume que la transacción está confirmada. Este tipo de sistema permitiría a rollup lograr confirmaciones a la velocidad de propagación de datos a través de la capa base. Teóricamente, esto también debería acortar el tiempo entre la preconfirmación del ordenador de rollup y la confirmación en la capa base.

El sistema anterior depende de la ejecución basada en ZK Fragmentación en lugar de la ejecución replicada como el futuro de las aplicaciones verificables.

El movimiento de datos entre dos rollups en una transacción cruzada de fragmentación requiere ordenación, pero también es parcial. Por ejemplo, transferir el activo X de rollup A a rollup B requiere que la transacción de retiro de rollup A alcance el número legal antes de que rollup B pueda incluir la transacción de depósito. Las confirmaciones rápidas desde la capa base proporcionarán una garantía confiable para la interoperabilidad entre rollups en el mismo ecosistema, creando así efectos de red para la capa base. La rápida interoperabilidad junto con una gran cantidad de activos valiosos puede ser suficiente para hacer que la capa base sea atractiva para los rollups potenciales. En resumen, este diseño especial permitirá:

• El tiempo de confirmación de las transacciones Rollup es rápido.
• Interoperabilidad rápida entre Rollups (sin necesidad de puente de Liquidez o proveedor de liquidez).
• Volumen de transacciones DA dedicado para Rollup.
• Herramienta de verificación especializada para Rollup (más sistemas de prueba).

Acumulación del valor del activo base

La discusión anterior proporciona una base barata, rápida y segura para rollup. Sin embargo, gran parte de la discusión actual en torno al roadmap centrado en rollup se centra en la acumulación de valor de ETH y Ethereum. Las capas 2 con relaciones de usuario (como Base) pueden cobrar primas por su espacio de bloqueo y solo necesitan devolver una pequeña parte de sus ingresos a Ethereum en forma de tarifas DA.

Al permitir que rollup publique datos de estado con mayor frecuencia, se puede obtener alguna de la rentabilidad que normalmente se perdería para los proveedores de liquidez y puentes de liquidez. Aunque el valor de un sistema de interoperabilidad mejorado para la capa base depende completamente de la cantidad de rollups que necesiten comunicarse entre sí. En configuraciones donde rollup no satisface las necesidades de múltiples aplicaciones, el valor acumulado para la capa base se vuelve más claro. Las aplicaciones solo necesitan interactuar con la capa base para lograr la componibilidad. Pueden obtener un alto rendimiento y control sobre su propio espacio sin sacrificar la componibilidad.

Hay argumentos que sugieren que mejorar la ejecución de la capa base aumentaría la acumulación de valor del token nativo. Esto permite a la capa base competir con rollup, lo cual va en contra del principio de diseño centrado en rollup. Otro enfoque para la ejecución (posiblemente nuestro preferido) es construir un rollup consagrado, donde los activos de la capa base están protegidos mediante stake de rollup. Incluso el conjunto de validadores de la capa base podría actuar como el conjunto de ordenadores de rollup (aunque no necesariamente tienen que ser los mismos). De hecho, después de la charla de Martin Köppelmann en Devcon 2024, el tema del rollup consagrado o nativo ha ganado popularidad. Para ecosistemas como Ethereum, esto permitiría que ETH recupere parte del valor perdido, al tiempo que permite a los desarrolladores experimentar más libremente en rollup, ya que el stake de rollup podría ser mucho menor que en la capa base de Ethereum.

Conclusión

En general, creemos que la era de ZK representa un futuro emocionante y visionario para Ethereum y toda la blockchain. En este artículo, resumimos cómo la combinación de ZK con el avanzado mecanismo de consenso representa una nueva dirección potencial para la capa base en sistemas centrados en rollup. Al combinar la prueba de conocimiento cero con ideas tomadas del mecanismo de consenso basado en DAG, podemos repensar la capa base optimizada específicamente para rollup. El mecanismo de consenso solo se aplica donde se comparte el estado real y no como un requisito unificado para todas las operaciones. A medida que el ecosistema continúa evolucionando hacia un diseño modular, esperamos que este enfoque más refinado del mecanismo de consenso en la capa base se convierta en el estándar de blockchain modular.

En general, creemos que, dado que varias nuevas tecnologías de apoyo acaban de entrar en producción, la capa base debe adoptar esta tecnología para mantener su competitividad.

No debemos tener miedo de tener sueños más grandes.