• Reenviar el título original:Descentralización del rollup: Análisis de la solución de secuenciador descentralizado de Aztec

Introducción: Desde que Rollup se hizo prominente, la descentralización del secuenciador siempre ha sido un foco de la comunidad Ethereum/Celestia, y también es una montaña difícil de cruzar en el trabajo de desarrollo de Layer2. En este sentido, diferentes planes Rollup han propuesto ideas para la descentralización de nodos, proporcionando un rango de imaginación extremadamente amplio para este tema.

El autor de este artículo toma como ejemplo el conocido proyecto ZKRollup Aztec, y utiliza como punto de entrada las dos propuestas denominadas B52 y Fernet recientemente propuestas por Aztec Labs, para analizar a los lectores cómo ZKR realiza la descentralización de los nodos secuenciadores.

Propuesta B52: Esquema de secuenciador sin permiso

La propuesta B52 pretende alcanzar los siguientes objetivos (idealmente):

1. Red de secuenciadores descentralizada, con nodos L2 que eligen a los proponentes para cada ronda.

2. Red de probadores descentralizada, con bajos requisitos de hardware para los nodos de probadores.

3. Rollup posee una excelente resistencia a la censura en general.

4. El valor MEV generado en L2 es obtenido por los nodos L2.

5. Cuando los bloques L2 se envían a la capa DA, se puede obtener una finalidad relativamente efectiva. La finalidad irreversible requiere que se complete la presentación de la prueba de validez.

6. Los tokens L2 pueden tener un modelo tokenómico decente.

7. Tanto el bloque L2 como los datos de transacción se propagan en la red p2p de L2.

8. L2 hereda la seguridad de L1.

(La propuesta B52 asume la estructura Rollup, el Proponente es esencialmente el Secuenciador)

Este plan divide todo el proceso de producción de bloques L2 en tres etapas temporales:

Ventana de Propuesta de Bloque (BPW) Ventana de Aceptación de Bloque (BAW) Avances de estado

Entre ellos, la etapa BPW (Block Proposal) es el proceso en el que varios secuenciadores proponen diferentes bloques y compiten, y Prover selecciona un bloque candidato para votar. BAW (Aceptación de bloques) es el proceso en el que Prover construye una prueba de validez para el bloque y la envía. Ventana de Propuesta de Bloque (Fase de Propuesta de Bloque): BPW se puede subdividir en tres etapas: Propuesta de Bloque, Votación de Bloque, Agregación.

(Diagrama de proceso de la ventana de propuesta de bloques)

Etapa de Propuesta de Bloque (BP): cualquier persona en la etapa puede recopilar transacciones y transmitir su propio contenido de BP. El contenido de BP incluirá tres partes: hash de orden de txs, porcentaje de recompensa del probador y cantidad de tokens de quema.

Hash de orden de txs: el proponente selecciona el lote de transacciones más valioso del grupo de transacciones L2 (mempool), las ordena y, a continuación, coloca el valor hash de estas transacciones en el bloque que están construyendo. Porcentaje de recompensas del probador: el porcentaje de recompensas de bloque que el secuenciador comparte con el probador. burn token amount: La cantidad de L2 Native Tokens que el Proponente propone quemar, luego envía su BP a la red L2 p2p.

Etapa de votación en bloque:

Después de que el Prover reciba BPs propuestos por diferentes Proponentes en la red p2p, votará por el BP que le permita obtener la mayor cantidad de recompensas. Sin embargo, la composición de la votación es especial:

Voto={BlockHash, Index of Proof Tree}

BlockHash es el hash de la Propuesta por la que Prover quiere votar, y Index of Proof Tree es el valor del índice hoja del Proof Tree en el que Prover quiere participar en la construcción (se explicará más adelante)

Agregación: El Proponente recopila los votos de los Proprobadores en el BP en la red P2P L2, los agrega y los coloca en el BP, y los envía a L1 (cada BP generalmente solo contiene registros de votación relacionados consigo mismo).

Aquí, es necesario enfatizar el requisito previo para que BP sea seleccionado e incluido en el libro mayor de Rollp:

Tener la puntuación más alta:

PUNTUACIÓN(y) = NUM_PROVERS (x)^3 * BURN_BID(z)^2'

NUM_PROVERS (x) es el número de votos de probador que ha recibido este BP, y BURN_BID es el número de tokens L2 propuestos para ser quemados por este BP. Porque cuanto mayor sea el BURN_BID, menos recompensas obtendrá al final el proponente de BP, por lo que este valor debe establecerse adecuadamente.

Al mismo tiempo, este BP debe enviarse a L1 antes de que finalice la ventana de propuesta de bloque, y la prueba de validez correspondiente debe cargarse en L1 antes del final de la ventana de aceptación de bloques.

Nota: En la puntuación de BP, el número de votos ocupa el mayor peso, seguido del número de tokens de quema. Al mismo tiempo, el esquema B52 permite que múltiples proponentes (en realidad secuenciadores) compitan por una cuota de BP válida.

El esquema B52 solo requiere que el proponente (secuenciador) especifique el número de tokens de quema en su propio BP (similar al método EIP1559) sin tener que apostar tokens por adelantado, lo que puede hacer que la red sea más sin permisos (sin permiso de admisión) y también es propicio para la deflación de tokens nativos de L2.

Además, el BP no contiene datos completos de la transacción, sino que solo contiene el hash de la secuencia de la transacción, que es similar al esquema PBS de Ethereum, con el objetivo de evitar que MEV sea espiado y adelantado por otros proponentes.

Explicación detallada de la ventana de aceptación de bloques:

(Diagrama esquemático de la ventana de aceptación de bloques, escrito como prueba de aceptación en la imagen)

Una vez finalizada la ventana de propuesta de bloque, el probador debe revelar los datos completos de la transacción correspondientes a su BP. Si se selecciona el BP por el que vota el Prover (que tiene la puntuación más alta, que se puede consultar a través del contrato L1), debe construir el Sub Árbol de Pruebas correspondiente al Índice de Árbol de Pruebas dado al votar.

Supongamos que un bloque azteca contiene 2^13=16384 cantidades de transacciones, y hay 2048 probadores, entonces cada demostrador construye un árbol de subprueba compuesto por 2^3=8 transacciones. A continuación, el probador transmite su árbol de prueba de subwoofer construido a la red P2P L2. Después de recibirlo, el proponente agregará todos los árboles de subprueba en una prueba de bloque.

A continuación, Propsoer enviará la prueba agregada al contrato L1 Rollup, que verificará la exactitud de esta prueba y los resultados de la transición de estado correspondiente. Cabe señalar aquí que si Prover deliberadamente no presenta la prueba, no solo no recibirá los dividendos de recompensa en bloque prometidos por Proposer, sino que también será recortado, porque convertirse en Prover requiere apostar tokens por adelantado. Por lo tanto, a diferencia del Proponente (Secuenciador), el Probador no es Permissionless.

Explicación detallada de los Anticipos del Estado:

Una vez finalizada la Ventana de Aceptación de Bloques, el contrato de Rollup seleccionará el bloque con la puntuación más alta para ser incluido en el libro mayor de Rollup, y la recompensa del bloque se enviará al Proponente (Secuenciador) y al Prover en la proporción previamente declarada por el Proponente.

Lo anterior es el esquema B52 de Azteca. Sin embargo, el autor de este artículo cree que la propuesta B52 tiene algunos problemas potenciales:

Problema uno: Supongamos que la prueba de validez de un bloque con la puntuación más alta está incompleta. La solución dada en la propuesta es que si el proponente solo proporciona el 50% de la prueba, entonces solo puede obtener el 50% de la recompensa del bloque, lo que garantiza que el proponente no tenga ningún incentivo para no presentar deliberadamente una prueba completa. Al mismo tiempo, el Probador también puede presentar directamente la prueba al contrato.

De acuerdo con la descripción de la propuesta, es aceptable que un bloque no tenga una prueba completa de validez de transacción. En realidad, esto no es razonable porque: zkrollup declara que el nuevo estado correspondiente a este bloque es válido solo cuando se da la prueba de validez.

Si a la prueba agregada que el proponente finalmente envía a L1 le falta la prueba de una determinada transacción, es obvio que la prueba de transición de estado de todas las transacciones que ocurren después de esta transacción no es válida (porque las transacciones se ejecutan en secuencia y tienen dependencias de estado), y no podemos confirmar que el nuevo estado correspondiente a este bloque sea válido.

Por lo tanto, en este momento, la forma razonable debería ser ingresar a la ventana de aceptación de bloques de espera infinita hasta que se presenten todas las pruebas de transacción.

Problema 2: Supongamos que el bloqueo con mayor puntuación es un bloqueo ilegal (este punto no se explica en el plan B52). El BP solo contiene el hash de la secuencia de transacciones, por lo que un proponente malintencionado podría construir intencionadamente transacciones problemáticas, como transacciones de doble gasto. En este momento, es necesario agregar una función al contrato L1 que permita a cualquiera presentar una prueba ilegal. Esta prueba ilegal se utiliza para demostrar que el BP con la puntuación más alta es un bloqueo ilegal.

Además, este tipo de informe debe ser recompensado. Podemos dar todos los tokens de quema enviados al contrato por el proponente como recompensa al nodo que presentó la prueba ilegal.

Pensamiento interesante: Sobre los bloques de tío y el trabajo de prueba redundante: El plan B52 en realidad, después de que aparezca cada ronda del BP más alto y válido, tratará a otros BP (que hayan presentado pruebas completas) en esta ronda como bloques de tío y distribuirá una cierta cantidad de recompensas de bloque de tío.

En realidad, esto sigue la práctica del mecanismo de consenso de ETH POW. Para evitar una concentración excesiva de la potencia de cálculo, es necesario asignar una parte de la recompensa por bloque a los proponentes de los bloques que no se adoptan (mineros), para proteger los intereses de los pequeños pools de minería/mineros individuales y para evitar que la potencia minera sea monopolizada por los grandes pools de minería. Por lo tanto, adoptar el mecanismo de bloque tío de Ethereum, que funciona bien, también es una opción muy inteligente.

La importancia de la propuesta B52 en términos de descentralización Rollup: El Proponente está descentralizado y no requiere una promesa, y la barrera de entrada es baja. Sin embargo, debido a que requiere construir el bloque más valioso por sí mismo, así como recopilar votos de otros Proprobadores y agregar todas las Pruebas, el umbral de hardware del Proponente no es tan bajo como se describe en la propuesta (por ejemplo, el ancho de banda puede no ser muy bajo).

Por lo tanto, eventualmente se convertirá en una red más centralizada, similar a Mev-Boost Builder, porque el proponente que eventualmente puede producir el bloque es a menudo el Block Builder que es mejor para capturar MEV.

Al mismo tiempo, el Prover en el esquema B52 necesita pignorar activos, pero debido a que solo necesita generar una prueba de subárbol, en comparación con aquellas soluciones que necesitan generar completamente la prueba de bloque completo, el grado de descentralización del Prover será mejor (los requisitos de hardware se pueden reducir).

Liveness: La Liveness general de la red es buena, porque L2 tiene su propia red p2p para transmitir transacciones y votaciones/BP, y tanto Sequencer como Prover están relativamente descentralizados. Pero tenemos que resolver los dos problemas mencionados anteriormente, uno es que el bloque con la puntuación más alta debe ser un bloque legal, y el segundo es que tenemos que esperar a que se envíe la prueba de bloque completa a L1 antes de entrar en un nuevo estado. Por lo tanto, se necesita un mecanismo de incentivos más efectivo para evitar que toda la red Rollup deje de funcionar normalmente (se detenga) debido a la falta de alguna prueba de tx.

Resistencia a la censura: Si podemos asegurarnos de que cualquiera pueda publicar propuestas de bloqueo BP, y asegurarnos de que no solo el proponente pueda presentar una prueba de bloque, entonces la red tendrá una buena resistencia a la censura.

Finalidad: La finalidad de L2 está estrechamente relacionada con la vida de la red, porque la finalidad final verificada aún debe esperar el envío de Block Proof, pero de hecho también puede confiar en el contenido del bloque correspondiente al BP con la puntuación más alta (siempre que no contenga transacciones maliciosas).

Este bloque se revelará al comienzo de la Ventana de Aceptación de Bloques, lo que significa que, como usuario, solo necesita esperar un tiempo de la Ventana de Propuesta de Bloque, y el bloque donde se encuentra su transacción puede ser adoptado.

Heredar la seguridad de L1: como L2 que actualiza el estado mediante el envío de pruebas de validez, puede heredar la seguridad de L1.

Propuesta de Fernet: Introducción de VDF para la selección de proponentes

Visión general del Esquema Fernet: Utilizando VDF dentro de cada ciclo de generación de bloques, se asigna una puntuación proyectada a diferentes nodos dentro del Comité (la colección de nodos del Secuenciador), y el bloque propuesto por el Secuenciador con la puntuación final más alta se convierte en el bloque válido.

En primer lugar, ¿cómo se puede formar parte del Comité? Esencialmente, requiere apostar 16 ETH en L1 y luego, después de que se complete el proceso de participación, esperar 4 bloques L1 antes de unirse al Comité de Secuenciadores. En cuanto a salir del Comité de Secuenciadores, es necesario llamar a la función Unstake en el contrato L1, después de lo cual se tarda 3 días en recuperar la cantidad restante apostada.

A continuación, ¿qué es VDF? La función de retardo verificable es una función matemática que se adhiere a estrictas características de ejecución en serie. Ejecuta ciertos pasos computacionales y consume una cantidad predecible de tiempo. Denotamos el valor calculado por VDF como la puntuación, que sigue una distribución normal uniforme. Por lo tanto, una vez que el secuenciador calcula la puntuación VDF, puede determinar la probabilidad de ser seleccionado como un proponente legítimo.

El cálculo de VDF para Sequencer es el siguiente:

Puntuación = VDF( clave privada , entradas públicas )

Aportes públicos = { current block number , randao }

randao es un número aleatorio que se utiliza para evitar que los secuenciadores calculen prematuramente su puntuación VDF para todas las alturas de bloque futuras

Todo el proceso de Fernet se divide principalmente en tres etapas:

1. Fase 2 de la propuesta. Fase de prueba 3. Finalización

Fase de propuesta: PROPOSAL_PHASE_L1_BLOCKS = 2 bloques de Ethereum (Esta fase durará 2 bloques L1)

Al comienzo de esta fase, cada secuenciador calculará su propia puntuación VDF a la altura del bloque actual. Si el secuenciador cree que es probable que su puntuación VDF gane el derecho de producción de bloques de este bloque (suponiendo que la puntuación satisfaga la distribución normal), presentará una propuesta al contrato de acumulación de L1. La propuesta incluye: el hash de la secuencia de transacciones, apuntando a un bloque L2 anterior.

bloque no probado: el bloque que solo ha enviado la propuesta al contenido del bloque de contrato acumulativo. A continuación, el secuenciador debe enviar el contenido del bloque correspondiente al bloque no probado y la prueba de VDF a la red P2P L2.

Fase de prueba: PROVING_PHASE_L1_BLOCKS= 50 bloques L1 (Esta fase durará 50 bloques L1, unos 10 min)

El probador recibe todas las transacciones correspondientes al contenido del bloque de la red P2P L2 y crea una prueba para el bloque con una puntuación VDF más alta. La construcción de la prueba también adopta un método de múltiples Provers cooperando en paralelo (similar al esquema B52).

Por lo tanto, el secuenciador debe finalmente agregar las pruebas de varias transacciones diferentes en una prueba de bloque (incluida la prueba VDF) y enviarla al contrato L1 Rollup. Cualquier persona que ya haya enviado la prueba de bloque al contrato acumulativo puede enviar el contenido del bloque.

Finalización: Necesita enviar una transacción L1 para finalizar el bloque, un bloque que finalmente se puede finalizar debe cumplir: contenido del bloque enviado y prueba de bloque, el bloque anterior al que apunta debe estar finalizado. Sobre esta base, también debe tener la puntuación más alta.

(El proceso de bloqueo de estilo canalización, tan pronto como finaliza la etapa de propuesta del bloque anterior, comienza la etapa de propuesta del siguiente bloque, sin esperar a que finalice la etapa de prueba del bloque anterior).

Mecanismo de generación de bloques de gasoductos: Vale la pena señalar que Fernet adopta un mecanismo de generación de bloques de gasoductos. Cuando finaliza la fase de Propuesta del bloque N, comienza la Propuesta del bloque N+1 (similar a lo que hacen Aptos y otras cadenas públicas). Sin embargo, para el bloque N+1, debe esperar a que el bloque N finalice antes de poder enviar la transacción de bloque final de L1 y validarse para convertirse en el bloque final.

Vectores de ataque potenciales: Si el secuenciador con la puntuación VDF más alta no transmite intencionalmente el contenido del bloque en el P2P L2, puede provocar una reorganización del bloque (reorg).

Cálculo de la cantidad de bloques L2 para la reorganización: 1+PROVING_PHASE_L1_BLOCKS / PROPOSAL_PHASE_L1_BLOCKS =1+50/2=26 bloques

Solución: Introducir el mecanismo de bloque tío para evitar tener solo un bloque candidato completo para cada ranura L2 (ranura de tiempo de generación de bloques).

La importancia de la descentralización en Fernet: Los secuenciadores se unen al Comité de Secuenciadores apostando 16 ETH, y el umbral de entrada no es alto (pero tampoco bajo). Los Provers no necesitan ningún staking, pero si los Provers no generan Proof, no hay penalización. Esto es básicamente opuesto al esquema B52.

Liveness: Se puede garantizar la Liveness de la red general porque el mecanismo de bloque VDF + uncle puede garantizar que haya más de un productor de bloques en cada ronda.

MEV: La consideración de MEV es particularmente singular. Este esquema planea introducir PBS, de modo que después de que un secuenciador calcule una puntuación VDF de alta puntuación, pueda acercarse directamente al generador de bloques para construir un bloque más valioso.

Resistencia a la censura: Fernet también adoptará un mecanismo PBS consistente con Ethereum, por lo que esencialmente, el problema de resistencia a la censura de Fernet es equivalente al problema de resistencia a la censura PBS de Ethereum.

Renuncia:

1. Este artículo es una reimpresión de [Geek Web3], Forward the Original Title'ollup Decentralization: Analysis of Aztec's Decentralized Sequencer Solution',Todos los derechos de autor pertenecen al autor original [xhhh,EthStorage]. 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.