• Título original reenviado: Investigador de Celestia analiza 6 variantes de Rollup: Secuenciador = agregador + generador de encabezado

Nota: Con el fin de facilitar la comprensión y el análisis del modelo Rollup, el investigador de Celestia, NashQ, dividió el secuenciador Rollup en dos entidades lógicas: el agregador y el productor de encabezados. Al mismo tiempo, dividió el proceso de ordenación de transacciones en tres pasos lógicos: inclusión, ordenación y ejecución.

Guiados por este pensamiento analítico, las seis variantes principales de Sovereign Rollup son más claras y fáciles de entender. NashQ discutió en detalle la resistencia a la censura y la vida de las diferentes variantes de Rollup, así como la configuración mínima de cada nodo de variante de Rollup en el estado de minimización de confianza (es decir, para lograr un estado sin confianza, al menos qué tipos de nodos deben ejecutar los usuarios de Rollup).

Aunque este artículo analiza Rollup desde la perspectiva de Celestia, que es diferente de la forma en que la comunidad de Ethereum analiza el modelo Rollup, teniendo en cuenta las muchas interconexiones entre Ethereum Rollup y Celestia Sovereign Rollup, así como la creciente influencia de este último, este artículo también vale la pena leerlo para los entusiastas de Ethereum.

¿Qué es un Rollup?

Los rollups son cadenas de bloques que publican los datos de sus transacciones en otra cadena de bloques y heredan su consenso y disponibilidad de datos.

¿Por qué estoy cambiando "bloquear" por "datos de transacción" aquí? Déjame decirte la diferencia entre un bloque de acumulación y los datos de acumulación y mostrarte que la acumulación mínima solo necesita datos de acumulación con nuestra primera variante.

Un bloque acumulativo es una estructura de datos que representa la cadena de bloques a una determinada altura. Consta de datos consolidados y encabezado acumulativo. Y los datos consolidados son un lote de transacciones o la diferencia de estado entre lotes de transacciones.

Variante 1 : Rollup pesimista basado

La forma más sencilla de crear un rollup comienza con un usuario que publica transacciones en otra cadena de bloques. Llamaremos a esta cadena de bloques la capa de consenso y disponibilidad de datos, pero la acortaré a DA-Layer en todos los diagramas siguientes. (Nota: similar a la capa 1 a la que a menudo se hace referencia en la comunidad de Ethereum).

En nuestra primera variante, cada nodo de rollup debe reproducir todas las transacciones en la cadena de bloques para verificar el estado más reciente. ¡Acabamos de crear un Rollup pesimista!

Un resumen pesimista es un resumen que solo admite nodos completos que reproducen todas las transacciones del paquete acumulativo para comprobar su validez.

Pero en este caso, ¿quién es el secuenciador en este caso? Ninguna entidad está ejecutando realmente las transacciones, aparte de los propios nodos completos consolidados. Por lo general, un secuenciador agregaría las transacciones y produciría un encabezado acumulativo, ¡pero no hay encabezado en este caso!

Para facilitar la discusión, dividimos el secuenciador en dos entidades lógicas: el agregador y el productor del encabezado lo diferencian. Una entidad debe tener en cuenta el estado (es decir, debe ejecutar el estado para calcular el encabezado), pero el agregador no necesita comprender el estado para poder agregarlo.

La secuenciación es el proceso de agregación y producción de encabezados.

La agregación es el proceso de agrupar transacciones por lotes en un lote. Un lote de transacciones consta de una o más transacciones. (Nota: Lote es la parte de los datos del bloque Rollup, excepto el encabezado).

La producción de cabecera es el proceso de creación de la cabecera consolidada.

El encabezado consolidado son metadatos sobre el bloque, que como mínimo, incluyen un compromiso con las transacciones de ese bloque. (Nota: El compromiso aquí se refiere al compromiso con la corrección de los resultados del procesamiento de la transacción).

A través de la perspectiva anterior, podemos ver quién desempeña el papel de cada componente de Rollup. Veamos primero la parte del agregador. El resumen pesimista mencionado anteriormente no tiene un proceso de producción de encabezados y los usuarios publican transacciones directamente en la capa DA, lo que significa que la red DA-Layer actúa esencialmente como un agregador.

Un paquete acumulativo pesimista es una variante del paquete acumulativo que delega el paso de agregación a la capa DA. No tiene secuenciador. A veces, este tipo de rollup se denomina "rollup basado".

El Rollup basado tiene la misma resistencia a la censura y la misma actividad que la capa DA (la actividad mide la velocidad de respuesta del sistema a las solicitudes de los usuarios). Si los usuarios de este tipo de paquete acumulativo desean alcanzar un estado de confianza mínima (el más cercano a Sin confianza), deben ejecutar al menos un nodo ligero de capa de DA y un nodo completo de acumulación.

Variante 2: Resumen pesimista mediante un agregador compartido

Analicemos la agregación pesimista mediante agregadores compartidos. Esta idea fue propuesta por Evan Forbes en su publicación en el foro sobre el diseño de secuenciadores compartidos. EsoLa suposición clave es que un secuenciador compartido es la única forma formal de secuenciar transacciones. Evan explica los beneficios de los secuenciadores compartidos de la siguiente manera:

"Para desbloquear una experiencia de usuario equivalente a la web2, los secuenciadores compartidos [...] puede proporcionar compromisos blandos rápidos (nota: no es una garantía muy confiable). Estos compromisos blandos proporcionan una promesa arbitraria del orden final de las transacciones (es decir, prometen que el orden de las transacciones no cambiará) y se pueden usar para crear versiones actualizadas prematuramente del estado (pero la finalización aún no se ha completado en este momento).

Tan pronto como se haya confirmado que los datos del bloque se publicarán en la capa base (s/b refiriéndose a DAlayer), el estado se puede considerar definitivo".

Debido a que todavía somos un rollup pesimista, solo tenemos nodos completos de rollup y no nodos ligeros. Cada nodo tiene que ejecutar todas las transacciones para garantizar la validez. No hay nodos ligeros en este sistema, por lo que no hay necesidad de un encabezado acumulativo, también conocido como productor de encabezados. (Nota: En términos generales, un nodo ligero de una cadena de bloques no necesita sincronizar bloques completos, sino que solo recibe encabezados de bloque)

Dado que no hay ningún paso de producción de encabezado consolidado, el secuenciador compartido de resumen mencionado anteriormente no necesita ejecutar transacciones para las actualizaciones de estado (un requisito previo para la producción de encabezado), sino que solo incluye el proceso de agregación de datos de transacción. Así que prefiero llamarlo un agregador compartido.

En esta variante, los usuarios de Rollup deben ejecutar al menos lo siguiente en un estado de confianza minimizada:

Nodo ligero de capa DA + nodo claro de la red agregadora compartida + nodo completo acumulativo.

En este momento, es necesario verificar el encabezado del agregador publicado (sin hacer referencia al encabezado Rollup) a través del nodo ligero de la red de agregador compartida. Como se mencionó anteriormente, el agregador compartido se encarga de la tarea de clasificación de transacciones. En el encabezado del agregador publicado, contiene un compromiso criptográfico, correspondiente al lote que publicó en la capa DA.

De esta manera, el operador del nodo Rollup puede confirmar que el lote recibido de la capa de DA fue creado por el agregador compartido, no por otros.

(Debido a que el contenido contenido anterior es relativamente oscuro, puede volver a leer el diagrama)

La inclusión es el proceso por el cual una transacción es aceptada en la cadena de bloques.

El pedido es el proceso de organizar transacciones en una secuencia específica en la cadena de bloques.

La ejecución es el proceso mediante el cual se procesan las transacciones en la cadena de bloques y sus efectos se aplican al estado de la cadena de bloques.

Debido a que el agregador compartido controla la inclusión y el orden, heredamos su resistencia a la censura.

Si asumimos L_ss es la vida del agregador compartido, y L_da es la vida de la capa DA, entonces la vida de este esquema es L = L_da && L_ss. En otras palabras, si alguno de los sistemas tiene un error de ejecución, el paquete acumulativo también tiene un error de ejecución.

Para simplificar, usaré liveness como booleano. Si se produce un error en el agregador compartido, no podemos continuar con el resumen. Si la capa de DA falla, podríamos continuar con los compromisos blandos del agregador compartido. Aun así, dependeríamos del consenso y la disponibilidad de datos del agregador compartido, que sería peor que la capa de DA original.

Continuemos explorando la resistencia a la censura de la solución Rollup anterior:

En este esquema, la capa DA no puede censurar transacciones específicas. (Nota: La revisión de transacciones a menudo puede negarse a permitir que ciertas transacciones se carguen en la cadena). Solo puede censurar lotes consolidados completos que el agregador compartido ya haya agregado. (rechazando un lote para ser incluido en la capa DA).

Sin embargo, de acuerdo con el flujo de trabajo de Rollup, cuando el agregador de uso compartido envía el lote de transacciones a la capa DA, ya ha completado la secuenciación de transacciones y también se ha determinado el orden entre los diferentes lotes. Por lo tanto, este tipo de revisión de transacciones por parte de DA-Layer no tiene otro efecto que retrasar la finalidad del libro mayor de Rollup.

En resumen, creo que el enfoque de la resistencia a la censura es garantizar que ninguna entidad pueda controlar o manipular el flujo de información dentro del sistema, mientras que la vida implica mantener la funcionalidad y la disponibilidad del sistema, incluso en presencia de interrupciones de la red y acciones adversas. Aunque esto entra en conflicto con la definición académica dominante actual, seguiré utilizando la definición del concepto que he expuesto.

Variante 3: Rollup pesimista con agregación basada y compartida

A pesar de que la comunidad disfruta de los beneficios de un agregador compartido, queremos evitar depender de él y queremos tener una alternativa a la capa DA. Combinaremos los pedidos y permitiremos a los usuarios enviar transacciones directamente a DA-Layer. Combina agregación basada y compartida.

Suponemos que el orden final se interpretará como todas las transacciones ordenadas por el agregador compartido y luego todas las transacciones basadas después de eso por bloque DA-Layer. A esto lo llamamos la regla de elección de bifurcación de rollups.

En este caso, la agregación es un proceso de dos pasos. En primer lugar, el agregador compartido toma la iniciativa, agregando algunas transacciones. A continuación, la capa DA se agrega con los lotes y transacciones ya ordenados que el usuario envió directamente.

El análisis de la resistencia a la censura ahora es más complejo. El nodo de red DA-Layer puede revisar el lote enviado por el agregador compartido antes de que se produzca el siguiente bloque DA-Layer. Después de conocer los datos de la transacción en el lote, el nodo DA-Layer puede extraer el valor MEV, iniciar una transacción de ejecución anticipada con su cuenta en la red Rollup e incluirla en el bloque DA-Layer antes de incluir el lote enviado por el agregador compartido Rollup.

Aparentemente, la finalidad de la orden de transacción garantizada por el compromiso blando del tercer tipo de variante Rollup es más frágil que el segundo tipo de variante Rollup mencionado anteriormente. En este caso, el agregador compartido entrega el valor MEV al nodo DA-Layer. Con respecto a esto, sugiero a los lectores que vean la conferencia sobre la censura rentable de MEV.

En la actualidad, han aparecido algunas soluciones de diseño para reducir la capacidad de los nodos de la red DA-Layer para ejecutar dichas transacciones MEV, como la función de "período de ventana de reorganización", que retrasará las transacciones enviadas directamente por los usuarios de la red Rollup a la DA-Layer. Sovereign Labs lo ha detallado en su propuesta de diseño denominada Secuenciación Basada con Confirmaciones Blandas, donde se propone el concepto de "secuenciador preferido".

Como MEV depende del esquema de agregador que elija y de la regla de elección de bifurcación del rollup, algunos no filtrarán ninguno, y otros filtrarán parte o todo MEV a la capa DA, pero ese es un tema para otro día.

En cuanto a la vida, este diseño rollup tiene una ventaja sobre el simple hecho de tener un agregador compartido. Si el agregador compartido tiene un error de ejecución, el usuario aún puede enviar transacciones a la capa DA.

Por último, hablemos de la configuración más pequeña con confianza minimizada: un nodo ligero de capa DA + nodo ligero de agregador compartido + nodo completo acumulativo.

En este momento, todavía tenemos que validar los encabezados del agregador compartido para nuestro nodo completo consolidado para poder diferenciar los lotes de transacciones para su regla de elección de bifurcación.

Variante 4: Rollup optimista basado en un productor de encabezado centralizado

Comencemos a cocinar algunos nodos ligeros usando una variante llamada rollup optimista basado con un productor de encabezado centralizado. Este diseño utiliza la capa de DA para agregar transacciones, pero introducimos un productor de encabezado centralizado para habilitar los nodos ligeros acumulativos.

Los nodos ligeros de Rollup pueden verificar indirectamente la validez de las transacciones de Rollup a través de una sola ronda de prueba de fraude. El nodo ligero adoptará una actitud optimista hacia el generador del encabezado acumulativo y realizará una confirmación final después de que finalice el período de ventana a prueba de fraude. Otra posibilidad es que reciba una prueba de fraude de un nodo completo honesto, sabiendo que el generador de encabezados ha enviado datos incorrectos.

No entraré en detalles sobre cómo funcionan las pruebas de fraude de una sola ronda, ya que esto rompería el alcance de este artículo. El beneficio aquí es que puede reducir el tiempo de la ventana a prueba de fraude de 7 días a una cierta cantidad, que aún no se ha determinado pero es de magnitudes menores. Los nodos ligeros son capaces de recibir pruebas de fraude a través de la capa p2p sin necesidad de esperar a una disputa, ya que todo se captura en una sola prueba.

Usamos la capa DA como el agregador que hereda su resistencia a la censura. Hace inclusión y ordenación. El productor de encabezado centralizado leerá el orden canónico de la capa DA y podrá construir un encabezado válido a partir de eso. El productor de encabezado centralizado publicará el encabezado y las raíces de estado en la capa DA. Estas raíces estatales son esenciales para crear una prueba de fraude contra este compromiso. El agregador realiza la inclusión y el orden, mientras que el productor del encabezado realiza la ejecución.

Se supone que la capa DA (que también actúa como agregador de Rollup en este momento) está suficientemente descentralizada y tiene una buena resistencia a la censura. Además, el productor de encabezado no puede cambiar la secuencia de transacciones Rollup publicada por el agregador. Ahora, si el productor de encabezado está descentralizado, el único beneficio es una mejor vida, pero las otras propiedades de Rollup son las mismas que las de la primera variante, Based Rollup.

Si el productor de encabezado tiene un error de ejecución, el resumen también tiene un error de ejecución. El nodo ligero no podrá seguir la cadena, mientras que los nodos completos aún podrían seguir la cadena si es deseable, volviendo a un rollup pesimista basado como se describe en la variante 1. Obviamente, la configuración mínima para la minimización de la confianza descrita en la variante 4 es:

Nodo de luz DA-Layer + nodo de luz Rollup.

Variante 5 : ZK-Rollup basado en un mercado de probadores descentralizado

Hemos hablado de Pessimistic Rollup (Based Rollup) y Optimistic Rollup, ahora es el momento de considerar ZK-Rollup. Recientemente, Toghrul hizo una presentación sobre la separación del agregador (Sequencer) y el productor de encabezado (Prover) (Sequencer-Prover Separation in Zero-Knowledge Rollups). En este modelo, la publicación de transacciones como datos consolidados en lugar de diferencias de estado es más fácil de tratar, por lo que me centraré en lo primero. La variante 5 es un zk-rollup basado en un mercado de probadores descentralizado.

A estas alturas, debería estar familiarizado con lo que hace un paquete acumulativo basado en él. La variante 5 delega la función de agregador a los nodos DA-Layer, que realizan el trabajo de inclusión y ordenación. Citaré el documento de Sovereign-Labs, que hace un trabajo increíble al explicar el ciclo de vida de su diseño. Lo adaptaré ligeramente para que se ajuste a la variante 5.

Los usuarios publican un nuevo blob de datos en la cadena L1. Tan pronto como el blob se finaliza en L1, es lógicamente final. Inmediatamente después de finalizar el bloque L1, los nodos completos del paquete acumulativo lo examinan y procesan todos los blobs de datos relevantes en el orden en que aparecen, lo que genera una nueva raíz de estado consolidado. En este punto, el bloque se finaliza subjetivamente desde la perspectiva de todos los nodos completos.

Nuestro productor de cabeceras en este diseño es el mercado de probadores descentralizados.

Los nodos probadores (nodos completos que se ejecutan dentro de un ZKVM) realizan aproximadamente el mismo proceso que los nodos completos: escanean el bloque DA y procesan todos los lotes en orden, producen pruebas y las publican en la cadena. (Las pruebas deben publicarse en la cadena si el rollup quiere incentivar a los probadores; de lo contrario, es imposible saber qué probador fue el primero en procesar un lote determinado). Una vez que se ha publicado una prueba para un lote determinado en la cadena, el lote es subjetivamente final para todos los nodos, incluidos los nodos ligeros.

(Debido a que hay muchos conceptos involucrados, puede volver a mirar el diagrama esquemático)

La variante 5 goza de la misma resistencia a la censura que la capa DA. El mercado de probadores descentralizado no puede censurar las transacciones porque la capa DA determina el orden canónico. Descentralizamos el productor de cabecera solo para mejorar la vida y crear un mercado de incentivos. La vida aquí es L = L_da && L_pm (mercado probador). Si los incentivos del mercado de probadores están desalineados, o tiene una falla de vida, los nodos ligeros no podrán seguir la cadena, pero los nodos completos de rollup aún podrían seguir la cadena si lo desean, volviendo a un rollup pesimista basado. La configuración de confianza minimizada más pequeña está aquí, al igual que en el caso optimista de tener un nodo de luz de capa DA + un nodo de luz acumulativo.

Variante 6 : Rollup híbrido basado con un productor de encabezado optimista centralizado y un probador descentralizado

Seguimos dejando que los nodos de la capa de DA actúen como agregadores para el resumen y los deleguemos para que se encarguen de la inclusión y la clasificación de las transacciones.

Como puede ver en la figura siguiente, tanto ZK Rollup como Optimistic Rollup utilizan los mismos lotes de transacciones ordenadas en la capa DA como origen del libro mayor de acumulación. Esta es la razón por la que podemos utilizar dos sistemas de prueba al mismo tiempo: los lotes de transacciones ordenados en la capa DA no se ven afectados por el sistema de prueba en sí.

Hablemos de finalidad. Desde la perspectiva de un nodo completo de acumulación, la acumulación es definitiva cuando la capa de DA es definitiva, ya que solo necesita ejecutar las transacciones para esta variante. Pero nos importa más la finalidad del nodo de luz. Supongamos que el productor de encabezado centralizado pone alguna apuesta, firma sobre un encabezado y publica las raíces de estado calculadas en la capa DA.

Al igual que con la variante 4 anterior, los nodos ligeros confiarán con optimismo en la ejecución y esperarán una prueba de fraude de un nodo completo honesto que muestre que el productor del encabezado cometió fraude. Una vez finalizada la ventana a prueba de fraudes, el bloque de acumulación es definitivo desde la perspectiva de un nodo ligero de acumulación.

El punto clave es que si podemos obtener una prueba de ZK, ya no tenemos que esperar a que termine la ventana a prueba de fraude. Además de las pruebas de fraude de una sola ronda, podemos reemplazar las pruebas de fraude con pruebas ZK y descartar cualquier encabezado malicioso que se generó a partir del productor de encabezado optimista.

Cuando el nodo ligero reciba el certificado ZK correspondiente a un determinado lote de transacciones Rollup, el lote finalizará.

Ahora tenemos un compromiso rápido y suave y una finalidad rápida.

La variante 6 sigue gozando de la misma resistencia a la censura que la capa DA en la que se basa. Para la vida, tendremos L = L_da && (L_op || L_pm ), lo que significa que aumentamos nuestra garantía de vida. Si el productor de cabecera centralizado o el mercado de probadores tienen una falla de vida, podemos recurrir al otro esquema.

La configuración más pequeña con confianza minimizada es un nodo de luz de capa DA + un nodo de luz acumulativo.

Resumen:

1. Dividimos el secuenciador en dos entidades lógicas: el agregador y el productor de encabezado

2. Dividimos el secuenciador en tres procesos lógicos: inclusión, ordenación y ejecución.

3. Los rollups pesimistas y los rollups basados son una cosa

4. Dependiendo de sus necesidades, puede agregar agregadores y productores de encabezados plug-and-play.

5. Cada variante de Rollup de este artículo siguió este patrón de diseño:
   

Por último, tengo algunas reflexiones. Por favor, piense en:

• ¿Cómo encajan los rollups clásicos en esto? (refiriéndose a Ethereum Rollup)
• En todas las variantes, solo hicimos que el agregador hiciera inclusión + ordenamiento y la ejecución del productor de encabezado. ¿Qué pasa si el agregador solo hace la inclusión y el productor del encabezado hace el orden y la ejecución? Piensa en las subastas on-chain. ¿Podríamos separar los tres?
• ¿Qué es un productor de cabecera compartido / mercado de productor de cabecera?
• ¿Quién recibe el MEV? ¿Y podremos recuperarlo?

Renuncia:

1. Este artículo es una reimpresión de [Geek Web3], Forward the Original Title'Celestia researcher analyzes 6 Rollup variants: Sequencer = aggregator + Header generator',Todos los derechos de autor pertenecen al autor original [NashQ, Celestia Researcher]. Si hay objeciones a esta reimpresión, comuníquese con el equipo de Gate Learn y ellos lo manejarán de inmediato.
2. Descargo de responsabilidad: Los puntos de vista y opiniones expresados en este artículo son únicamente los 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 mencione, está prohibido copiar, distribuir o plagiar los artículos traducidos.