Introducción: Este artículo es una recopilación de las declaraciones dispersas del investigador de Celestia, NashQ, sobre el análisis del modelo Rollup, que incluye 4 nuevas variantes de Rollup. Anteriormente, en el artículo " El investigador de Celestia analiza 6 variantes de Rollup: Secuenciador=Aggregator+Generador de encabezado", enumeró 6 modelos Rollup diferentes, y este artículo es una nueva abstracción de 4 tipos de modelos Rollup sobre la base de este artículo.

Anteriormente, NashQ dividió el secuenciador Sequencer en dos módulos, Aggregator + Header Producer, y cortó a través del ciclo de vida de las instrucciones transaccionales para explicar cómo funciona Celestia Sovereign Rollup, explorando la resistencia a la censura y la actividad de las diferentes variantes de Rollup, así como la configuración mínima para que un usuario sea minimizado en confianza (es decir, para ser Trustless, ¿cuáles son los tipos mínimos de nodos que un usuario de Rollup debería ejecutar).

Variante 7: Rollup basado + Múltiples Productores de Encabezados + “MEV de Protocolo más Alto”

En esta variante Rollup, el usuario de red Rollup contabiliza los datos de la transacción directamente en el bloque de capa DA y, a continuación, el productor de cabecera es responsable del orden de la transacción y extrae el MEV. Obviamente, el proceso de agregación/inclusión de transacciones de la variante 7 de Rollup es el mismo que el de la acumulación basada introducida anteriormente, que es manejada por la capa DA (los usuarios publican sus transacciones directamente en la capa DA), pero la clasificación de transacciones es diferente de la acumulación basada en que los nodos de la capa DA no están a cargo de la clasificación. que es manejado por el HP (Header Producer).

Supongamos que hay tres HPs que compiten entre sí y siguen un protocolo de asignación de MEV llamado “highest Protocol MEV”. Este protocolo fue propuesto por el protocolo Skip del ecosistema Cosmos, que difiere del esquema Ether PBS en que los Block Builders pagan una “propina” adicional a los Validadores de la red blockchain, y los bloques construidos por los Builders más propinados son adoptados por los Validadores. Los bloques construidos por los Builders más propinados serán adoptados por los Validadores. Al mismo tiempo, SKIP Protocol propone el concepto de “Sovereign MEV”, que pretende permitir que todos los Validadores y la comunidad de la red de cadena pública tengan la autonomía de asignación de MEV, y resolver el problema de la creciente centralización de los constructores debido al efecto flywheel en Ethernet PBS (pero esto no es el núcleo de este artículo).

En la variante de Rollup presentada en este documento, diferentes Productores de Encabezado deben declarar la cantidad de propina en el Encabezado de Lote que crean, y el Encabezado de Lote publicado por el PE que da la mayor propina es automáticamente aceptado por los nodos de Rollup (automáticamente a través de un algoritmo de selección de horquilla de libro mayor escrito en el código del nodo).

Además de esto, el encabezado de lote publicado por HP debe poder corresponder a un lote de transacciones completo en la capa DA.

Si hay un error en el encabezado publicado por HP, como que el resultado de la ejecución de la transacción Stateroot es incorrecto, o no contiene una transacción específica en el lote (transacción perdida), el nodo completo Rollup honesto transmite la prueba de fraude Prueba de fraude al nodo ligero. Sin embargo, por lo general (optimista), el nodo ligero puede aceptar el encabezado publicado por HP y creer que no tiene problemas.

Análisis de Resistencia a la Censura: existen 2 puntos en este Rollup donde es posible la censura de transacciones. El primero existe en la capa DA, donde puede revisar el contenido de la transacción y rechazar la inclusión de transacciones de ciertos usuarios. El segundo lugar sigue estando en la capa DA, puede revisar el Encabezado enviado por HP y negarse a incluir un cierto Encabezado, de modo que pueda conspirar con el Encabezado para monopolizar el MEV a través de un ataque de censura.

Al mismo tiempo, la secuenciación de transacciones es manejada por HP, y debido a la existencia de pruebas de fraude (que pueden ser usadas contra el caso de HP abandonando transacciones), HP tiende a no lanzar ataques de censura, pero puede sobornar a nodos de capa DA para hacerlo (o ejecutar algunos nodos de capa DA por sí mismo). La solución a esto es extender el período de ventana durante el cual se finaliza la secuencia de transacciones Rollup, para que el Encabezado rechazado por el nodo malicioso de capa DA pueda ser incluido en la cadena por el nodo honesto de capa DA a tiempo antes del final del período de ventana, lo que a su vez aumenta la dificultad del ataque de censura del nodo de capa DA.

Actividad: L = L_da && ( L_hp1 || L_hp2 || L_hp3 )

Si la capa DA tiene una falla activa, entonces Rollup también tendrá una falla activa. En esta base, Rollup solo tendrá una falla activa si todos los HP tienen una falla activa.

Variante 8: ZK Rollup con Agregador Compartido + Demostrador Descentralizado

La variante 8 utiliza el agregador compartido (SA) para la inclusión + ordenación de transacciones, donde la SA publica la secuencia de transacciones Batch en la capa DA y, en teoría, el orden de las transacciones no cambia después de que la secuencia de transacciones se envía a la capa DA.

Y antes de que el Lote se envíe a la capa DA, el Agregador Compartido SA puede transmitir primero el Lote + Encabezado SA al nodo completo y al Probador, y el Encabezado SA al nodo ligero, excepto que en este momento, el Lote que no está en la capa DA todavía es inestable y puede ser reemplazado en cualquier momento.

Es importante tener en cuenta que el Encabezado publicado por el Agregador Compartido SA no es lo mismo que el Encabezado de Lote publicado por HP. El Encabezado de SA contiene pruebas criptográficas para asegurar que el Lote que el nodo Rollup lee de la capa DA fue realmente generado por SA, y no falsificado por él.

El probador lee el lote de transacciones Lote de la capa DA (y también se sincroniza directamente con el agregador compartido), genera una Prueba ZK+Cabecera de Lote, y la publica en la capa DA. Obviamente, el probador actúa como el HP.

Para el nodo ligero de Rollup, después de recibir ZKProof, la secuencia de transacciones contenidas en este lote se finalizará. Por supuesto, el Probador también puede transmitir ZKP a través de la red p2p de Rollup bajo la cadena de capa DA, para que pueda ser recibido por los nodos ligeros más rápido, pero en este momento, ZKP aún no se ha enviado a la capa DA, y no tiene la "finalidad".

Resistencia a la censura: en la variante 8, la capa DA no puede llevar a cabo ataques de censura en algunas transacciones específicas, pero solo puede realizar ataques de censura en lotes en todo el grupo de transacciones enviadas por el agregador compartido. Al mismo tiempo, el agregador compartido puede negarse a empaquetar las transacciones de ciertos usuarios.

Activo: L = L_da && L_sa && L_pm. si alguna parte de esta variante falla activa entonces Rollup fallará activo. Si el probador falla, entonces el nodo ligero no podrá sincronizar eficientemente el progreso del libro mayor Rollup. Pero dado que el nodo completo sincroniza toda la secuencia de transacciones por lotes, puede mantenerse al día con el progreso del libro. En este momento, el nodo completo no se ve afectado y todos los nodos ligeros fallan, lo que equivale al caso descrito anteriormente de Rollup basado con el agregador compartido.

Configuración mínima para minimización de confianza: nodos ligeros de nivel DA + nodos ligeros de red de agregadores compartida + nodos ligeros de Rollup

Variante 9: Agregador Compartido + Probador Descentralizado + ZK-Rollup con múltiples DAs

La variante 9 se basa en el despliegue de la variante 8 mencionada anteriormente, excepto que tiene más de una capa DA, lo que puede mejorar eficazmente la actividad de Rollup. En la variante 9, el agregador compartido SA puede publicar la secuencia de transacciones Batch en cualquier capa DA, y puede elegir diferentes capas DA para publicar los datos según sus necesidades, de modo que pueda optimizar dinámicamente los parámetros relevantes de Rollup, como: costo de datos, seguridad, actividad, retraso de transacciones y finalización.

Dependiendo de las necesidades del proyector Rollup, el Rollup más barato, seguro, activo y de liquidación más rápida se puede personalizar, y se puede seleccionar la capa DA con la mayor capacidad de procesamiento. En general, un Lote de una cierta altura de bloque Rollup (por ejemplo, el 10,000°) no tiene que existir en diferentes capas DA al mismo tiempo, pero si lo hacen, sus contenidos deben ser iguales. Si dos Lotes con la misma altura y diferentes contenidos están presentes en diferentes capas DA, significa que el agregador compartido está participando intencionalmente en una bifurcación de libro mayor.

Aquí, elegimos el mismo Mercado de Prover descentralizado que en la variante 8, donde el Prover actúa como Productor de Encabezados y publica el Encabezado del Lote y ZKProof. en este punto, el Prover necesita competir a través del mecanismo de subasta de propinas mencionado en la variante 7 (propuesto por el Protocolo SKIP).

La velocidad de liquidación de transacciones (velocidad de confirmación final) de la variante 9 se ve afectada por la capa DA más rápida que emplea de entre los bloques.

Resistencia a la censura: los agregadores compartidos pueden participar en ataques de censura, pero el número de capas de DA opcionales aumenta y la probabilidad de ataques de censura asociados con las capas de DA disminuye.

Actividad: L = (L_da1 || L_da2) && L_sa && L_pm.

La variante 9 es más activa en comparación con las variantes anteriores. Si no hay un fallo de actividad en todas las redes de capa DA, todo puede proceder con normalidad.

Configuración mínima para minimización de confianza: nodos ligeros en diferentes capas DA + nodos ligeros de red de agregadores compartida + nodos ligeros de Rollup.

Obviamente, cuantas más capas de DA empleemos, más nodos ligeros debemos ejecutar. Pero los beneficios de esto pueden superar sus costos.

Variante 10: Dos ZK-Rollups + Proveedor Descentralizado con un nodo ligero en cadena entre sí (interconectable)

La variante 10 es una extensión de la variante 5 con el objetivo de crear 2 ZK-Rollups que puedan conectarse entre sí. En comparación con la variante 5 (Rollup Basado + ZKP + Proveedor Descentralizado), la Variante 10 tiene el papel adicional de un Repeater Relayer, que envuelve el Encabezado de Lote + ZK-Proof en una sola transacción. Simplemente enviando esta transacción al nodo ligero Rollup1 donde se está ejecutando Rollup2 demuestra que un Lote de cierta altura es válido. Por supuesto, Rollup2 también necesita ejecutar el nodo ligero de la capa DA.

Este es un requisito previo para mantener la confianza en el puente entre cadenas minimizada. Sin embargo, si alguien está cruzando desde un Ether Rollup (un SC Rollup basado en contratos inteligentes) a Ether, ya no es necesario ejecutar el nodo ligero de capa DA del Rollup, ya que la capa DA es Ether en sí misma. Esto es extremadamente diferente del Sovereign Rollup de Celestia, donde los Rollups deben ejecutar los nodos ligeros de la capa DA de cada uno para cruzarse.

Cuando Relayer envía una transacción entre cadenas, es procesada por el agregador 2 de Rollup2 y HP2. Agregamos ambos al gráfico para entender cómo los nodos en Rollup2 manejan transacciones entre Rollups.

El repetidor Relayer de Rollup 2 obtendrá el encabezado de lote y ZKP de Rollup 2 y lo enviará de vuelta a Rollup 1. El paquete acumulativo 1 también tiene un nodo claro para el paquete acumulativo 2 y un nodo claro para la capa DA.

Podemos simplificar más el modelo. Supongamos que dos Rollups utilizan el mismo Agregador Compartido y Productor de Encabezado, en otras palabras, emplean capas DA superpuestas.

En este caso, el Relayer puede ser ilegalizado directamente. Dado que el Encabezado de Lote y la Prueba ZK han sido publicados por HP en la misma capa DA, los datos como el Encabezado y ZKP de otro Rollup pueden ser leídos directamente en la capa DA, y ya no necesitan ser enviados al Agregador Compartido a través del Relayer.

Obviamente, los Rollups que utilizan la misma capa DA no necesitan depender de los Relevadores (muchos puentes entre cadenas cruzadas dependen de nodos de relevo). Esto puede resolver el problema de seguridad de los puentes entre cadenas cruzadas (desde este punto de vista, la interconexión entre los Rollups de SC en Ethernet es más segura que la interconexión entre diferentes cadenas públicas).

En este punto, la configuración mínima para minimizar la confianza: un nodo ligero de nivel DA + un nodo ligero de Rollup.

Declaración:

1. Este artículo es una reproducción de [[Geek Web3]https://mp.weixin.qq.com/s/Wi4FPTCZli5g8UGVkYFnlw), los derechos de autor pertenecen al autor original [NashQ, Celestia], if you have any objections to the reprint, please contactel equipo de Gate Learn, el equipo será tratado de acuerdo con el proceso pertinente tan pronto como sea posible.
2. Descargo de responsabilidad: Los puntos de vista y opiniones expresados en este artículo representan los puntos de vista personales del autor y no constituyen ningún consejo de inversión.
3. Los artículos en otros idiomas son traducidos por el equipo de Gate Learn y no pueden ser reproducidos, distribuidos o copiados sin referencia a Gate.io.