Investigador de Celestia: Interpretación de 4 nuevos esquemas de resumen

Autor: NashQ, Celestia; Compilador: Enlace, "Geek web3"

Introducción: este artículo está compuesto por los discursos dispersos del investigador de Celestia NashQ sobre el análisis del modelo Rollup, incluidas 4 nuevas variantes de Rollup. Anteriormente, en el artículo "Análisis del resumen desde la perspectiva de Celestia: resistencia a la censura y actividad de 6 variaciones", enumeró 6 modelos diferentes de resumen, y este artículo son sus 4 categorías recién resumidas basadas en este modelo de resumen.

Previamente, NashQ dividió el Secuenciador en dos módulos: agregador + Productor de Cabeceras, partiendo del ciclo de vida de las instrucciones de transacción, explicó el principio de funcionamiento del Rollup soberano de Celestia, discutió la anticensura y actividad de las diferentes variantes de Rollup, y la experiencia del usuario La configuración mínima bajo la premisa de minimizar la confianza (es decir, para lograr Trustless, qué tipos de nodos deben ejecutar al menos los usuarios del Rollup).

Variante 7: Rollup basado + Productores de encabezados múltiples + "MEV de protocolo más alto"

En esta variante de resumen, los usuarios de la red de resumen publican directamente los datos de transacción en los bloques de capa DA, y luego el productor de encabezado es responsable de la clasificación de transacciones, y MEV es extraído por él. Obviamente, el proceso de agregación/inclusión de transacciones de la Variante 7 de Rollup es el mismo que el Rollup Basado presentado anteriormente, que es responsabilidad de la capa DA (los usuarios envían transacciones directamente a la capa DA), pero el orden de las transacciones es diferente del Basado. Rollup, y los nodos de la capa DA no son responsables La clasificación es responsabilidad de HP (Header Producer).

Lo siguiente asume que hay tres HP que compiten entre sí y cumplen con el protocolo de asignación de MEV denominado "Protocolo MEV más alto". Este protocolo fue propuesto por el Skip Protocol del ecosistema Cosmos. A diferencia del esquema Ethereum PBS, el Block Builder necesita pagar una "propina" adicional al Validador de la red blockchain, y el bloque construido por el Builder con la mayor cantidad de tips será ser adoptado por los Validadores. Al mismo tiempo, el Protocolo SKIP propuso el concepto de "MEV soberano", con la intención de permitir que todos los Validadores y comunidades en la red de la cadena pública tengan la autonomía para asignar MEV y resolver el problema de que los Constructores en Ethereum PBS se están volviendo cada vez más. más centralizado debido al efecto volante (pero este no es el núcleo de este artículo).

En la variante de resumen presentada en este artículo, diferentes productores de encabezado deben declarar el monto de la propina en el encabezado de lote creado por ellos mismos, y el encabezado de lote emitido por el HP que paga la mayor cantidad de propinas es aceptado automáticamente por los nodos de resumen (a través del libro mayor). escrito en el código del nodo El algoritmo de selección de bifurcación se realiza automáticamente).

Además, el encabezado de lote publicado por HP debe poder corresponder al lote de transacción completo en la capa DA.

Si hay un error en el encabezado emitido por HP, por ejemplo, el resultado de la ejecución de la transacción Stateroot es incorrecto, o una transacción en el lote no está incluida (transacción perdida), el nodo completo del resumen honesto transmitirá la prueba de fraude al nodo ligero. . Pero por lo general (con optimismo), los nodos ligeros pueden aceptar el encabezado emitido por HP y creer que no hay problema con él.

Análisis de resistencia a la censura: Hay 2 puntos en este resumen que pueden realizar la revisión de transacciones. El primero existe en la capa DA, que puede censurar el contenido de las transacciones y rechazar transacciones que involucren a ciertos usuarios. El segundo lugar todavía existe en la capa DA, que puede revisar el encabezado enviado por HP y negarse a incluir un determinado encabezado, por lo que puede conspirar con el encabezado para monopolizar MEV a través de ataques de revisión.

Al mismo tiempo, HP es responsable de ordenar las transacciones.Debido a la existencia de pruebas de fraude (puede estar dirigida a la situación en la que HP pierde transacciones), HP por sí misma a menudo no lanza ataques de censura, pero puede sobornar a los nodos. de la capa DA para hacerlo (o ejecutar algunas capas DA por sí mismo) nodo). La solución a esto es extender el período de ventana para que finalice la secuencia de transacción de resumen, de modo que el encabezado rechazado por los nodos de capa DA maliciosos pueda ser incluido en la cadena por nodos de capa DA honestos antes del final del período de ventana, aumentando así la revisión del nodo de la capa DA La dificultad del ataque.

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

Si la capa DA tiene una falla de actividad, el resumen también tendrá una falla de actividad. En base a esto, Rollup fallará en vida solo cuando todos los HP fallen en vida.

Variante 8: Resumen ZK de agregador compartido + probador descentralizado

La variante 8 utiliza el agregador compartido Shared Aggregator (SA) para la inclusión y clasificación de transacciones. SA publica la secuencia de transacciones por lotes en la capa DA. Una vez que la secuencia de transacciones se envía a la capa DA, el orden de las transacciones no cambiará teóricamente.

Antes de que el Lote se envíe a la capa DA, el agregador compartido SA puede transmitir primero el Encabezado Batch+ SA al nodo completo y al Prover, y transmitir el Encabezado SA al nodo ligero, pero el Lote que no está en la capa DA es todavía inestable en este momento y puede bloquearse en cualquier momento.

Cabe señalar que el encabezado emitido por el agregador compartido SA no es el mismo que el encabezado del lote emitido por HP. El encabezado de SA contiene pruebas criptográficas para garantizar que el lote leído por el nodo de resumen de la capa de DA sea realmente generado por SA, no falsificado por otros.

Prover lee el lote de transacciones Batch desde la capa DA (también se puede sincronizar directamente con el agregador compartido), genera un encabezado ZK Proof+Batch y lo publica en la capa DA. Obviamente, Prover desempeñó el papel de HP.

Para los nodos ligeros de Rollup, después de recibir ZKProof, finalmente se confirma la secuencia de transacciones contenida en este lote. Por supuesto, Prover también puede transmitir ZKP a través de la red Rollup p2p bajo la cadena de capa DA, para que los nodos ligeros puedan recibirlo más rápido, pero en este momento ZKP no se ha enviado a la capa DA y no tiene " finalidad".

• **Resistencia a la censura: **En la variante 8, la capa DA no puede realizar ataques de censura en ciertas transacciones específicas, pero solo puede realizar ataques de revisión en todo el lote de transacciones enviadas por el agregador compartido. Al mismo tiempo, los agregadores compartidos pueden negarse a empaquetar las transacciones de ciertos usuarios.
• **Actividad: **L = L_da && L_sa && L_pm. En esta variante, si alguna pieza tiene una falla de vida, el Rollup tendrá una falla de vida. Si el Prover falla, los nodos de luz no podrán sincronizar de manera efectiva el progreso del libro mayor de resumen. Sin embargo, dado que el nodo completo sincroniza todos los lotes de secuencias de transacciones, puede mantenerse al día con el progreso del libro mayor. En este momento, todos los nodos no se verán afectados y todos los nodos ligeros fallarán, lo que equivale a la situación del resumen basado en el uso de un agregador compartido presentado anteriormente.
• **Configuración mínima para la minimización de confianza: **Nodo ligero de capa DA + nodo ligero de red de agregador compartido + nodo ligero acumulativo

Variante 9: Agregador compartido + Prover descentralizado + ZK-Rollup con múltiples DA

La variante 9 en realidad se basa en la variante 8 anterior, pero tiene más de una capa DA, lo que puede mejorar efectivamente la actividad de Rollup. En la Variante 9, el agregador compartido SA puede publicar la secuencia de transacciones por lotes en cualquier capa de DA, y puede elegir diferentes capas de DA para publicar datos de acuerdo con sus propias necesidades, de modo que pueda optimizar dinámicamente los parámetros relevantes de Rollup, como: costo de datos, seguridad, vitalidad, latencia de transacción y finalidad.

De acuerdo con las necesidades de la parte del proyecto Rollup, se puede personalizar el Rollup más barato, más seguro, más activo y de velocidad de liquidación, y se puede seleccionar la capa DA con el mayor rendimiento. En términos generales, los lotes de una cierta altura de bloque acumulativo (como el 10 000) no tienen que existir en diferentes capas DA al mismo tiempo, pero si existen, su contenido debe ser coherente. Si aparecen dos lotes con la misma altura y contenido diferente en diferentes capas de DA, significa que el agregador compartido bifurca intencionalmente el libro mayor.

Aquí, elegimos el mismo Prover Market descentralizado que la variante 8, donde Prover actúa como productor de cabecera y lanza Batch Header y ZKProof. En este punto, Prover necesita competir a través del mecanismo de subasta de propinas mencionado en la variante 7 (propuesta 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 con la generación de bloques más rápida.

Resistencia a la censura: Los agregadores compartidos pueden participar en ataques de censura, pero con más capas DA opcionales, se reduce la posibilidad de ataques de censura relacionados con las capas DA.

**活性：**L = ( L_da1 || L_da2) && L_sa && L_pm。

La variante 9 era más activa que la variante anterior. Mientras no todas las redes de capa DA experimenten fallas en vivo, todo funcionará bien.

Configuración mínima para la minimización de la confianza: nodos ligeros de diferentes capas DA + nodos ligeros de red de agregador compartido + nodos ligeros acumulativos.

Obviamente, cuantas más capas de DA adoptemos, más nodos ligeros tendremos que ejecutar. Pero los beneficios de hacerlo pueden superar los costos.

Variante 10: Dos ZK-Rollups+Prover descentralizado, con un nodo de luz en cadena (puenteable) entre sí

La Variante 10 es una extensión de la Variante 5 para crear 2 ZK-Rollups que pueden conectarse entre sí. En comparación con la variante 5 (consolidación basada + ZKP + probador descentralizado), la variante 10 tiene una función de retransmisión adicional, que envuelve el encabezado de lote + prueba ZK en una transacción. Siempre que esta transacción se envíe al nodo ligero Rollup1 que se ejecuta en Rollup2, puede probar que una cierta altura de Lote es válida. Por supuesto, Rollup2 también requiere nodos ligeros que ejecuten la capa DA.

Este es un requisito previo para mantener al mínimo la confianza entre los puentes de la cadena. Pero si es una cadena cruzada de Ethereum Rollup (SC Rollup basado en contrato inteligente) a Ethereum, no hay necesidad de ejecutar el nodo de luz de la capa DA de Rollup, porque la capa DA es Ethereum en sí. Esto es muy diferente del paquete acumulativo soberano de Celestia, cuyos paquetes acumulativos se extienden entre sí y deben ejecutar los nodos ligeros de la capa DA de la otra parte.

Cuando Relayer envía una transacción entre cadenas, será procesada por Aggregator 2 y HP2 de Rollup2. Agregamos ambos al gráfico para comprender cómo los nodos de Rollup2 procesan las transacciones en los Rollups.

El repetidor de Rollup2 obtendrá el encabezado de lote y el ZKP de Rollup 2 y los enviará de vuelta a Rollup1. Rollup 1 también tiene un nodo de luz de Rollup 2 y un nodo de luz de capa DA.

Podemos hacer el modelo más simplificado. Suponga que dos acumulaciones usan el mismo agregador compartido y productor de encabezado, en otras palabras, las capas DA que usan se superponen.

En este caso, el repetidor puede ser baneado directamente. Debido a que HP ha publicado el encabezado de lote y la prueba ZK en la misma capa DA, los datos como el encabezado y ZKP de otro paquete acumulativo se pueden leer directamente en la capa DA y ya no es necesario pasarlos al agregador compartido a través del Retransmisor.

Obviamente, Rollup que usa la misma capa DA no necesita depender de Relayer (muchos puentes entre cadenas se basan en nodos de retransmisión). Esto puede resolver el problema de seguridad de los puentes de cadenas cruzadas (desde este punto de vista, el tramo cruzado entre SC Rollups de Ethereum es más seguro que la cadena cruzada entre diferentes cadenas públicas).

En este momento, **configuración mínima de minimización de confianza: **nodo ligero de capa DA + nodo ligero acumulativo.