Análisis de Rollup desde la perspectiva de Celestia: revisión de resistencia y actividad de 6 variantes

Autor: NashQ, investigador de Celestia

原文标题：Redefinición de secuenciadores: comprensión del agregador y el productor de cabecera

Compilación: Fausto, Geek Web3

Nota del traductor: para que el modelo de resumen sea más fácil de comprender y analizar, el investigador de Celestia, NashQ**, dividió el secuenciador de resumen (secuenciador) en dos entidades lógicas: agregador y generador de encabezado. Al mismo tiempo, dividió el proceso de ordenación de transacciones en tres pasos lógicos: inclusión, ordenación y ejecución. **

Bajo la guía de este pensamiento analítico, las seis variantes importantes del Rollup soberano son más claras y fáciles de entender. **NashQ discutió en detalle la resistencia a la censura y la vitalidad de las diferentes variantes de Rollup, y también discutió la configuración mínima de los nodos de cada variante de Rollup en el estado de confianza minimizada (es decir, para lograr el estado Trustless, lo que los usuarios de Rollup deben ejecutar al menos tipo de nodo). **

Si bien este artículo analiza el Rollup desde la perspectiva de Celestia, que es diferente de la forma en que la comunidad Ethereum analiza el modelo Rollup, considerando las muchas interconexiones entre Ethereum Rollup y el soberano Rollup de Celestia, así como la creciente influencia de este último, es importante para For Entusiastas de Ethereum, este artículo también vale la pena leerlo.

¿Qué es el resumen?

Un Rollup es una cadena de bloques que publica sus "datos de transacción" en otra cadena de bloques y hereda su consenso y disponibilidad de datos.

¿Por qué utilicé deliberadamente la palabra "datos de transacción" en lugar de "bloquear"? Esto implica una distinción entre bloques acumulativos y datos acumulativos, con los acumulativos más compactos que solo requieren datos acumulativos como la primera variante a continuación.

Un bloque Rollup es una estructura de datos que representa el libro mayor de la cadena de bloques a una cierta altura de bloque. El bloque de resumen consiste en datos de resumen y encabezado de resumen. Entre ellos, los datos de resumen pueden ser un lote de transacciones o cambios de estado entre un lote de transacciones.

Variante 1: Resumen pesimista/Resumen basado

La forma más fácil de crear un resumen es permitir que los usuarios publiquen transacciones en otra cadena de bloques, a la que llamaremos capa de consenso y disponibilidad de datos (capa DA), y simplemente la llamaré capa DA a continuación (Nota del traductor: es similar a la Capa 1, que a menudo se dice en la comunidad Ethereum).

En la primera variante de Rollup que voy a presentar, los nodos de la red de Rollup deben volver a ejecutar las transacciones de Rollup contenidas en la capa DA para verificar el estado final del libro mayor. ¡Este es un resumen pesimista!

Pessimistic Rollup es un Rollup que solo admite nodos completos, y estos nodos completos deben volver a ejecutar todas las transacciones contenidas en el libro mayor de Rollup para verificar su validez.

Pero en este caso, ¿quién actúa como Secuenciador del Rollup? De hecho, a excepción de los nodos completos de Rollup, ninguna entidad ha ejecutado jamás las transacciones contenidas en el libro mayor de Rollup. En términos generales, el secuenciador agrega datos de transacciones y genera un encabezado de resumen. ¡Pero el resumen pesimista mencionado anteriormente no tiene encabezado de resumen!

Para facilitar la discusión, podemos dividir el secuenciador en dos entidades lógicas: Aggregator Aggregator y Header Generator. Para generar un encabezado de resumen, primero debe ejecutar la transacción, completar la transición de estado y luego calcular el encabezado correspondiente. Pero para un agregador, no necesita completar una transición de estado para continuar con el paso de agregación.

La secuenciación de clasificación es el proceso de "agregación + creación de encabezado de resumen".

La agregación es el paso de agrupar datos de transacciones en un lote. Un lote generalmente contiene muchas transacciones (Nota del traductor: Lote es la parte de los datos en el bloque Resumen que no sea el encabezado).

El paso de generación de encabezado es el proceso de creación de un encabezado de resumen. Encabezado de resumen son los metadatos sobre el bloque de resumen, que incluyen al menos el compromiso de los datos de transacción en el bloque (Nota del traductor: el compromiso mencionado aquí se refiere al compromiso con la corrección de los resultados del procesamiento de transacciones).

A través de la perspectiva anterior, se puede ver quién es el responsable de cada parte del Rollup. Primero mire la parte del agregador Aggregator. El Rollup pesimista mencionado anteriormente no tiene un proceso de generación de encabezados y los usuarios publican transacciones directamente en la capa DA, lo que significa que la red de la capa DA actúa esencialmente como un agregador.

Por lo tanto, Rollup pesimista es una variante de Rollup que delega el paso de agregación a la capa DA, que no tiene un secuenciador Sequencer. A veces, este tipo de resumen se denomina "resumen basado".

El resumen basado tiene la misma resistencia a la censura y 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 Rollup quieren alcanzar un estado de confianza mínima (lo más cercano a Trustless), deben ejecutar al menos un nodo ligero de la red de capa DA y un nodo completo de la red de Rollup.

Variante 2: Agregación pesimista usando un agregador compartido

Analicemos la agregación pesimista mediante un agregador compartido. Esta idea fue sugerida por Evan Forbes en su publicación en el foro sobre el diseño de secuenciadores compartidos. Su 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 esta manera:**

"Para lograr una experiencia de usuario equivalente a Web2, secuenciador compartido puede proporcionar Compromiso suave de generación rápida (garantía no muy confiable). Estos compromisos suaves brindan algunas garantías sobre la orden de transacción final (es decir, la orden de transacción de compromiso no cambio), y los pasos para actualizar el estado del libro mayor consolidado se pueden llevar a cabo por adelantado (pero la finalización aún no se ha completado).

Una vez que los datos del bloque de resumen se confirman y se liberan a la capa base Capa base (aquí debe referirse a la capa DA), la actualización de estado del libro mayor de resumen se finaliza y finaliza. "

La variante de Rollup mencionada anteriormente todavía pertenece a la categoría de Rollup pesimista, porque solo hay nodos completos en este tipo de sistema de Rollup y no hay nodos ligeros. Cada nodo de resumen debe ejecutar todas las transacciones para garantizar la validez de la actualización del estado del libro mayor. Debido a que este tipo de resumen no tiene nodos ligeros, no necesita un encabezado de resumen ni un generador de encabezado. (Nota del traductor: en general, los nodos ligeros de una cadena de bloques no necesitan sincronizar bloques completos, solo reciben encabezados de bloque)

Dado que no hay un paso de generación de encabezado de resumen, el secuenciador compartido de resumen mencionado anteriormente no necesita ejecutar transacciones para actualizaciones de estado (un requisito previo para generar encabezados), sino que solo incluye el proceso de agregar datos de transacciones. Así que prefiero llamarlo agregador compartido agregador compartido.

En esta variante, los usuarios de Rollup deben ejecutar al menos nodos ligeros de capa DA + nodos ligeros de la red agregada compartida + nodos completos de Rollup en un estado de confianza minimizada.

En este punto, es necesario verificar el encabezado del agregador publicado (no el encabezado del resumen) a través de los nodos ligeros de la red del agregador compartido. Como se mencionó anteriormente, el agregador compartido realiza el trabajo de clasificar las transacciones y contiene un compromiso criptográfico en el encabezado del agregador publicado, correspondiente al Lote que liberó en la capa DA.

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

• La inclusión es el proceso de incluir transacciones en la cadena de bloques.
• Clasificación Ordenar se refiere al proceso de organizar transacciones en la cadena de bloques en un orden específico.
• La ejecución se refiere al proceso de procesar transacciones en la cadena de bloques y completar las actualizaciones de estado.

Dado que el agregador compartido se encarga de la inclusión y clasificación, la resistencia a la censura de Rollup depende de ello.

Si se supone que L_ss es la actividad del agregador compartido y L_da es la actividad de la capa DA, entonces la actividad del modelo de acumulación es L = L_da && L_ss. En otras palabras, si alguna de las dos partes tiene una falla de actividad, el Rollup también tiene una falla de actividad.

Para simplificar, consideraré la vitalidad como un valor bool. Si el agregador compartido falla, el resumen no puede seguir funcionando. Si falla la red de la capa DA, el agregador compartido puede continuar proporcionando Compromiso flexible para los bloques acumulativos. Pero en este momento, los atributos de Rollup dependerán completamente de la red del agregador compartido, y los atributos de este último suelen ser muy inferiores a la capa DA original.

Sigamos explorando la resistencia a la censura del esquema de resumen anterior:

En este esquema, la capa DA no puede revisar algunas transacciones específicas (Nota del traductor: la revisión de transacciones a menudo puede negarse a permitir que ciertas transacciones se carguen en la cadena), solo puede comenzar para el lote completo de transacciones enviadas por el agregador compartido Revisión de transacciones (se negó a permitir que se incluyera un Lote en la capa DA).

Sin embargo, de acuerdo con el flujo de trabajo de resumen, cuando el agregador compartido envía el lote de transacciones Lote a la capa DA, ya ha completado la clasificación de transacciones y también se ha determinado el orden entre diferentes lotes. Por lo tanto, este tipo de revisión de transacciones en la capa DA no tiene otro efecto que retrasar la confirmación final del libro mayor de Rollup.

En resumen, creo que el objetivo de la resistencia a la censura es garantizar que ninguna entidad individual pueda controlar o manipular el flujo de información dentro del sistema, mientras que la vitalidad implica mantener la funcionalidad y disponibilidad del sistema, incluso en presencia de cortes de red y comportamiento de confrontación. Aunque esto entra en conflicto con la definición académica dominante actual, todavía usaré la definición del concepto que he articulado.

Variante 3: resumen pesimista basado en resumen basado y agregador compartido

Aunque el agregador compartido brinda beneficios a los usuarios y la comunidad, debemos evitar una dependencia excesiva de él y permitir que los usuarios se retiren del agregador compartido a la capa DA. Podemos combinar las dos variantes de resumen presentadas anteriormente, lo que permite a los usuarios enviar transacciones directamente a la capa DA mientras usan un agregador compartido. **

Asumimos que la secuencia final de la transacción de resumen depende de la secuencia de transacción enviada por el agregador compartido y las transacciones de resumen enviadas directamente por los usuarios en el bloque de capa DA. Llamamos a esta regla de selección de bifurcación de Rollup.

La agregación se divide aquí en dos pasos. Primero, entra en juego un agregador compartido, agregando algunas transacciones. Luego, la capa DA puede agregar el lote enviado por el agregador compartido y las transacciones enviadas directamente por el usuario.

**El análisis de resistencia a la censura es un poco más complicado en este punto. **Los nodos de la red de la capa DA pueden revisar el lote enviado por el agregador compartido antes de que se produzca el siguiente bloque de la capa DA. Después de conocer los datos de la transacción en el lote, los nodos de la capa DA pueden extraer el valor MEV. Las cuentas en la red inician de forma frontal. ejecutar transacciones e incluirlas primero en el bloque de la capa DA, y luego incluir el lote enviado por el agregador compartido de resumen.

Evidentemente, la firmeza de la orden de transacción garantizada por el compromiso flexible del tercer tipo de variante de Rollup es más frágil que la del segundo tipo de variante de Rollup antes mencionado. En este caso, el agregador compartido entregó el valor MEV a los nodos de la capa DA. En este sentido, recomiendo a los lectores que vean la conferencia de investigación sobre la explotación de MEV censurados rentables.

En la actualidad, han surgido algunos esquemas de diseño para reducir la capacidad de los nodos de la red de la capa DA para ejecutar tales transacciones MEV, como la función de "período de ventana de reorganización", que retrasará la ejecución de las transacciones enviadas directamente a la capa DA por los usuarios de la red Rollup. . Sovereign Labs describe esto en detalle en su propuesta de diseño llamada Secuenciación basada con confirmaciones suaves, que introduce el concepto de un "secuenciador preferido".

Dado que el problema de MEV depende del esquema agregador elegido por Rollup y las reglas de selección de bifurcación de rollup, algunos esquemas no filtrarán MEV a la capa DA, y algunos esquemas filtrarán parte o todo el MEV a la capa DA, pero esto es otro tema.

En cuanto a la vitalidad, este esquema de resumen tiene ventajas sobre los esquemas que solo permiten que los agregadores compartidos envíen transacciones a la capa DA. En el caso de una falla de actividad en un agregador compartido, los usuarios aún pueden enviar transacciones a la capa DA.

Finalmente, hablemos de la configuración mínima de los usuarios de Rollup bajo minimización de confianza:

Al menos ejecute el nodo ligero de la capa DA + el nodo ligero del agregador compartido + el nodo completo del resumen.

En este punto, aún es necesario verificar el encabezado del agregador emitido por el agregador compartido, de modo que el nodo completo del resumen pueda distinguir los lotes de transacciones de acuerdo con las reglas de selección de la bifurcación.

Variante 4: Resumen basado en optimismo y generador de encabezado centralizado

Analicemos una variante llamada Resumen optimista basado y un generador de encabezado centralizado. **Esta solución utiliza la capa DA para agregar transacciones de resumen, pero presenta un generador de encabezado centralizado para generar encabezados de resumen para habilitar nodos ligeros de resumen. **

Los nodos ligeros de resumen pueden verificar indirectamente la validez de las transacciones de resumen a través de una sola ronda de prueba de fraude. El nodo de luz será optimista sobre el generador del encabezado de resumen y realizará la confirmación final después de que finalice el período de prueba de fraude. Otra posibilidad es que reciba una prueba de fraude de un nodo completo honesto de que el generador de encabezado envió datos erróneos.

No voy a entrar en los detalles de cómo funciona una prueba de fraude de una sola ronda aquí, ya que eso está más allá del alcance de este artículo. La ventaja de una sola ronda de prueba de fraude es que puede acortar el período de ventana de prueba de fraude de días 7 hasta cierto punto.El valor específico aún no se ha determinado, pero el orden de magnitud es menor que el resumen optimista tradicional. Los nodos ligeros pueden obtener pruebas de fraude a través de la red P2P compuesta por nodos completos de Rollup sin esperar el proceso de disputa posterior, porque todos los criterios se proporcionan completamente en una sola prueba de fraude.

El modelo de resumen anterior utiliza la capa DA como agregador y hereda su resistencia a la censura. La capa DA en este punto es responsable de contener y ordenar las transacciones. El generador de encabezado centralizado leerá la secuencia de transacciones de resumen de la capa DA y construirá el encabezado de resumen correspondiente en consecuencia. El generador de encabezado publicará el encabezado y Stateroot en la capa DA. Estos Stateroots son necesarios al crear pruebas de fraude. **En resumen, el agregador es responsable de incluir y ordenar las transacciones, y el generador de encabezado ejecutará la transacción para actualizar el estado para obtener Stateroot. **

Suponga que la capa DA (que también actúa como un agregador para Rollup en este punto) está suficientemente descentralizada y es resistente a la censura. Además, el generador de encabezado no puede cambiar la secuencia de transacciones de resumen publicadas por el agregador. Ahora, si el generador de encabezado está descentralizado, el único beneficio es una mejor vivacidad, pero las otras propiedades de Rollup son las mismas que las de la primera variante de Rollup basado.

Si el generador de encabezado falla en la ejecución, el resumen también fallará en la ejecución. Los nodos ligeros no podrán seguir el progreso del libro mayor consolidado, pero los nodos completos sí. En este punto, el Rollup descrito en la Variante 4 degenera en el Rollup Basado descrito en la Variante 1. Aparentemente, la configuración mínima de confianza minimizada descrita por la Variante 4 es:

**Nodo de luz de capa DA + Nodo de luz acumulada. **

Variante 5: Basado en ZK-Rollup y mercado de prueba descentralizado

Hemos discutido Pessimistic Rollup (Based Rollup) y Optimistic Rollup, ahora es el momento de considerar ZK-Rollup. Recientemente, Toghrul pronunció un discurso sobre la separación del agregador (secuenciador) y el generador de encabezado (probador) (separación secuenciador-probador en acumulaciones de conocimiento cero). En este modelo, es más fácil manejar las transacciones de publicación como datos de resumen en lugar de diferencia de estado, por lo que me centraré en el primero. **La variante 5 es un Prover Market descentralizado basado en zk-rollup. **

A estas alturas, debería estar familiarizado con el funcionamiento de Rollup. La variante 5 delega la función de agregador a los nodos de la capa DA, que realizan el trabajo de incluir y clasificar las transacciones. Citaré la documentación de Sovereign-Labs, que tiene una buena explicación del ciclo de vida de una transacción en la variante 5:

El usuario publica un nuevo bloque de datos en la cadena L1 (capa DA). Una vez que estos bloques de datos se finalizan en la cadena L1, es lógicamente final (no modificable). Después de que los bloques de la cadena L1 entren en la etapa de finalización (es decir, no se pueden deshacer), los nodos completos de Rollup escanearán estos bloques, procesarán todos los bloques de datos relacionados con Rollup en orden y generarán el último estado de Rollup raíz Stateroot . En este punto, desde la perspectiva de los nodos completos de resumen, estos bloques de datos se han finalizado.

En este modelo, el generador de Cabecera es actuado por el Prover Market descentralizado.

El proceso de trabajo del nodo de prueba Prover (un nodo completo que se ejecuta en ZKVM) es similar al de un nodo completo de resumen normal: escanea la cadena de bloques de la capa DA y procesa todos los lotes de transacciones de resumen en orden para generar la prueba de conocimiento cero correspondiente y publicar en la cadena de capas DA. (Si el sistema Rollup quiere motivar al probador, este último debe enviar la prueba ZK generada a la cadena de capa DA, de lo contrario no será posible determinar qué Prover envió la prueba ZK primero). Una vez que la prueba ZK correspondiente a un determinado lote de transacciones se libera a la cadena, el lote de transacciones se finaliza a los ojos de todos los nodos Rolup (incluidos los nodos ligeros).

La variante 5 tiene la misma resistencia a la censura que la capa DA. El Prover Market descentralizado no puede revisar las transacciones de Rollup, porque la capa DA ya ha determinado el orden de transacción estándar, solo para obtener una mejor actividad y crear un mercado de incentivos, por lo que el generador de encabezado (aquí se refiere a Prover) es el cambio descentralizado.

La actividad aquí es L = L_da && L_pm (actividad del probador). Si los incentivos del Prover Market son inconsistentes o hay una falla activa, el nodo de luz de Rollup no podrá sincronizar el progreso de la cadena de bloques, pero el nodo completo de Rollup sí puede. Para el nodo completo, esto es solo un respaldo al Resumen basado/Resumen pesimista. La configuración mínima para la minimización de la confianza aquí es la misma que en el caso del Resumen optimista, a saber

Nodo de luz de capa DA + Nodo de luz acumulada.

Variante 6: Resumen basado en híbrido + Generador de encabezado optimista centralizado + Prover descentralizado

Todavía permitimos que los nodos de la capa DA actúen como agregadores de resumen y les deleguemos el trabajo de incluir y ordenar transacciones.

Como puede ver en la figura a continuación, tanto ZK Rollup como Optimistic Rollup utilizan el mismo lote de transacciones ordenadas en la capa DA como origen del libro mayor de Rollup. Esta es la razón por la que podemos usar ambos sistemas de prueba al mismo tiempo: el lote ordenado de transacciones en la capa DA no se ve afectado por el sistema de prueba.

Hablemos primero de la finalidad. Desde la perspectiva del nodo completo de resumen, cuando se finaliza el bloque de la capa DA, el lote de transacciones de resumen contenido en él se finaliza y no se puede cambiar. Pero nos importa más la finalidad desde la perspectiva de los nodos de luz. Suponga que el generador de encabezado centralizado hipoteca algunos activos, firma el encabezado de resumen generado y envía el Stateroot calculado a la capa DA.

Al igual que la variante anterior 4, el nodo ligero confiará de manera optimista en el generador de encabezados, creerá que el encabezado que emitió es correcto y esperará la prueba de fraude de la red de nodos completos. Si el período de ventana de la prueba de fraude ha terminado y la red de nodos completos no ha emitido la prueba de fraude, desde la perspectiva del nodo ligero de resumen, se finaliza el bloque de resumen.

El punto clave es que si podemos obtener una prueba ZK, no tenemos que esperar a que finalice la ventana de prueba de fraude. ¡Además de una sola ronda de pruebas de fraude, podemos reemplazar las pruebas de fraude con pruebas ZK y descartar encabezados falsos generados por generadores de encabezados maliciosos!

Cuando los nodos ligeros reciben una prueba ZK para un lote de transacciones de resumen, el lote se finaliza.

Ahora tenemos Soft Commitment rápido y finalización rápida.

La variante 6 todavía tiene la misma resistencia a la censura que la capa DA porque se basa en la capa DA. Para la vida, tendremos L = L_da && (L_op || L_pm), lo que significa que agregamos garantías de vida. Si el generador de encabezado centralizado o el mercado de prueba descentralizado tienen una falla de vida, podemos degenerar al otro de los dos.

En esta variante, la configuración mínima para la minimización de la confianza del usuario es:

**Un nodo de luz de capa DA + un nodo de luz de resumen. **

Resumen:

1. Dividimos el papel clave de Rollup - Sequencer en dos componentes lógicos:

Agregadores y generadores de cabecera.

2. Dividimos el trabajo de Sequencer en tres procesos lógicos: contención, clasificación y ejecución.

3. El resumen pesimista y el resumen basado son una cosa.

4. De acuerdo con sus necesidades, puede elegir diferentes soluciones de agregador y generador de encabezado.

5. Cada variante de Rollup presentada en esta publicación sigue el mismo patrón de diseño:

Finalmente, tengo algunos pensamientos. Por favor, piensa en:

• ¿Cómo se clasifica el Rollup clásico (refiriéndose a Ethereum Rollup) en las variantes anteriores?
• En todas las variantes, solo dejamos que el agregador se encargue de la inclusión + clasificación, y el generador de encabezado para ejecutar la transacción. ¿Qué pasa si el agregador solo es responsable de incluir transacciones y el generador de encabezado es responsable de ordenar y ejecutar transacciones? Teniendo en cuenta la introducción del paso de subasta en cadena, ¿podemos separar completamente estos tres pasos?
• ¿Qué es el mercado Productor de encabezado compartido / Productor de encabezado?
• ¿Quién captura el valor MEV? ¿Puede el usuario recuperarlo?