Introducción: desde que Rollup se hizo popular, la descentralización de Sequencer siempre ha sido el foco de la comunidad de Ethereum/Celestia, y también es una montaña insuperable en la investigación y el desarrollo de Layer2. En este sentido, diferentes esquemas de Rollup han propuesto ideas sobre la descentralización de nodos, brindando un espacio de imaginación extremadamente amplio para este tema.
El autor de este artículo toma como ejemplo el conocido proyecto ZKRollup Aztec, y utiliza las dos propuestas denominadas B52 y Fernet propuestas recientemente por Aztec Labs como punto de partida para analizar cómo ZKR realiza la descentralización de los nodos secuenciadores para los lectores.
Propuesta B52: esquema de secuenciador sin permiso
La propuesta B52 pretende lograr lo siguiente (idealmente):
Red de secuenciador descentralizada, los propios nodos L2 eligen cada ronda de proponentes
Red de prueba descentralizada, bajos requisitos de hardware para nodos de prueba
Rollup tiene buena resistencia a la censura en su conjunto.
El valor MEV generado por L2 es adquirido por los nodos L2
Cuando el bloque L2 se envía a la capa DA, se puede obtener una finalidad más efectiva, y la finalidad irreversible tiene que esperar a que se envíe ValidityProof (prueba de validez).
El token L2 puede tener un buen modelo económico
Tanto los bloques L2 como los datos de transacción se propagan en la red L2 p2p
L2 hereda la seguridad de L1
Este esquema divide todo el proceso de producción del bloque L2 en tres etapas de tiempo:
Ventana de propuesta de bloque (BPW)
Ventana de aceptación de bloques (BAW)
Anticipos del Estado
Entre ellos, la etapa BPW (propuesta de bloque) es un proceso en el que múltiples secuenciadores Seuqnecer proponen diferentes bloques y compiten, y Prover selecciona un bloque candidato para votar.
BAW (aceptación de bloque) es el proceso en el que Prover construye una prueba de validez para un bloque y la envía.
Ventana de propuesta de bloque (etapa de propuesta de bloque):
BPW se puede subdividir en tres etapas: Propuesta en bloque, Votación en bloque, Agregación.
Cualquier persona en la fase de propuesta de bloque (BP) puede recopilar transacciones y transmitir su propio contenido de BP. El contenido de BP contendrá tres partes: hash de orden de txs, porcentaje de recompensa del probador, cantidad de token de quemado
hash de orden de txs: el proponente selecciona y ordena el lote de transacciones más valioso del grupo de transacciones L2 (mempool) y luego coloca el valor hash de este lote de transacciones en el bloque que construye.
porcentaje de recompensa del probador: El porcentaje de recompensa del bloque compartido por Sequencer to Prover
cantidad de token quemado: El número de token nativo L2 propuesto por el Proponente para ser destruido, y luego envía el BP propuesto a la red p2p L2
Etapa de votación en bloque:
Después de que el Demostrante reciba el BP propuesto por diferentes Proponentes en la red p2p, votará por el BP que pueda obtener la mayor recompensa. Sin embargo, la composición del voto es muy especial:
Vote={BlockHash, índice del árbol de prueba}
BlockHash es el hash de la Propuesta sobre la que votará Prover, e Index of Proof Tree es el valor del índice de hoja del Proof Tree en el que Prover participará en la construcción (se explica más adelante)
Agregación de agregación: El proponente recopila los votos de Provers para BP en la red p2p L2, los agrega y los coloca en BP, y los envía a L1 (cada BP generalmente solo contiene registros de votación relacionados con él mismo).
Aquí es necesario enfatizar los prerrequisitos para que BP sea seleccionado e incluido en el libro mayor de Rollp:
NUM_PROVERS (x) es el número de votos Prover obtenidos por el BP, y BURN_BID es el número de Tokens L2 propuestos para ser destruidos por el BP. Dado que cuanto mayor sea BURN_BID, menos recompensa obtendrá el proponente de BP al final, por lo que este valor debe establecerse correctamente.
Al mismo tiempo, el BP debe enviarse a L1 antes del final de la Ventana de propuesta de bloque, y la prueba de validez correspondiente debe cargarse a L1 antes del final de la Ventana de aceptación de bloque.
Nota: En el cálculo de las puntuaciones de BP, el número de votos representa la mayor proporción, seguido del número de fichas quemadas. Al mismo tiempo, el esquema B52 permite que múltiples proponentes (en realidad secuenciadores) compitan por una cuota efectiva de BP
El esquema B52 solo requiere que el Proponente (secuenciador) especifique la cantidad de tokens de grabación en su propio BP (similar al método de EIP1559) sin tokens de participación por adelantado, lo que puede hacer que la red no tenga permiso (sin permiso de acceso), y es también beneficioso para L2 Native Token produce deflación.
Además, BP no contiene datos completos de la transacción, sino solo el hash de la secuencia de la transacción. La razón es similar al esquema Ethereum PBS, que tiene como objetivo evitar que MEV sea espiado por otros Proponentes.
Ventana de aceptación de bloques (etapa de aceptación de bloques) explicación detallada:
Una vez que finaliza la ventana de propuesta de bloque, Prover debe revelar los datos completos de la transacción correspondientes a su BP. Si se selecciona el BP votado por el Demostrante (la puntuación más alta se puede consultar a través del contrato L1), deben construir el Sub Árbol de Prueba correspondiente al Índice de Árbol de Prueba dado durante la votación.
Suponiendo que el bloque de Aztec contiene 2 ^ 13 = 16 384 transacciones y hay 2048 probadores, entonces cada probador construye un árbol de prueba secundario que consta de transacciones 2 ^ 3 = 8. Luego, el probador transmite el árbol de prueba secundario construido por sí mismo a In the L2 p2p red. Después de que el proponente lo reciba, agregará todos los subárboles de prueba en una prueba de bloque.
Luego, el Proponente envía la prueba agregada al contrato L1 Rollup, y el contrato verificará la exactitud de la prueba y los resultados de transición de estado correspondientes. Cabe señalar aquí que si el Prover deliberadamente no presenta la prueba, no solo no podrá obtener el dividendo de recompensa en bloque prometido por el Proponente, sino que también será reducido, porque para convertirse en Prover, necesita Token de compromiso por adelantado. Por lo tanto, a diferencia de Proposer (secuenciador), Prover no es sin permiso.
Avance estatal (etapa de avance estatal) explicación detallada:
Después de que finalice la ventana de aceptación del bloque, el contrato de acumulación seleccionará un bloque con la puntuación más alta para incluirlo en el libro mayor de acumulación y enviará la recompensa de recompensa del bloque al Proponente y al Probador respectivamente de acuerdo con la proporción declarada por el Proponente (Secuenciador) en avance.
La anterior es la solución B52 de Aztec. Sin embargo, el autor de este artículo cree que existen algunos problemas potenciales con la propuesta B52:
Pregunta 1: Si 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 las recompensas del bloque, para garantizar que el Proponente no tenga ninguna motivación para no presentar deliberadamente una prueba completa. Al mismo tiempo, Prover también puede presentar pruebas directamente al contrato.
De acuerdo con la descripción de la propuesta, es aceptable aceptar un bloque sin una prueba de validez de transacciones completas. En realidad, esto no es razonable: porque: zkrollup solo declara que el nuevo estado correspondiente a este bloque es válido cuando se proporciona la prueba de validez.
Si a la prueba agregada enviada por el proponente a L1 le falta la prueba de una determinada transacción, es obvio que las pruebas de transición de estado de todas las transacciones que ocurren después de esta transacción no son válidas (porque las transacciones se ejecutan secuencialmente y tienen dependencias de estado), nosotros También es imposible 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 que espera infinitamente hasta que se presenten todas las pruebas de la transacción.
Pregunta 2: **Si el bloque con mayor puntaje es un bloque ilegal (esto no se explica en el esquema B52). **BP solo contiene el hash de la secuencia de la transacción, por lo que un proponente malintencionado puede construir deliberadamente transacciones problemáticas, como transacciones de doble gasto. Entonces, en este momento, es necesario agregar una función en el contrato L1 para que cualquiera pueda enviar una prueba ilegal. Esta prueba ilegal se usa para demostrar que el BP con la puntuación más alta es un bloque ilegal.
Y este tipo de informe debe ser recompensado, podemos recompensar el token de quemado enviado por el proponente del contrato al nodo informador que envió la prueba ilegal.
**Pensamiento interesante:**Acerca de los bloques de tíos y el trabajo de demostración redundante: el esquema B52 en realidad usará otros BP (que hayan enviado pruebas completas) que aparecen en esta ronda como tíos después de que aparezca el BP con la puntuación más alta y efectivo en cada ronda. bloque, asigne una determinada recompensa de bloque de tío.
En realidad, esto sigue el enfoque del mecanismo de consenso ETH POW. Para evitar una concentración excesiva de poder de cómputo, es necesario asignar una parte de las recompensas de bloque a los proponentes de bloque no aceptados (mineros) para proteger los intereses de los pequeños grupos mineros/mineros individuales. y evitar que el poder de cómputo esté monopolizado por grandes grupos mineros. Por lo tanto, también es una opción muy inteligente adoptar el mecanismo de bloque tío que Ethereum realiza bien.
La importancia de la propuesta B52 en términos de descentralización de acumulación: El proponente está descentralizado y no requiere compromiso, y el umbral de entrada es bajo; pero porque necesita construir los bloques más valiosos usted mismo y necesita recopilar votos de otros Proponentes y agregar todas las Pruebas. De hecho, el umbral de hardware del Proponente no es tan bajo como se indica en la propuesta (por ejemplo, el ancho de banda puede no ser muy bajo).
Por lo tanto, eventualmente se convertirá en una red relativamente centralizada, similar a Mev-Boost Builder, porque el proponente que finalmente puede generar bloques es a menudo el Block Builder que es mejor para capturar MEV.
Al mismo tiempo, el Prover en el esquema B52 necesita comprometer activos, pero debido a que solo se necesita generar la prueba del subárbol, en comparación con aquellos esquemas que necesitan generar completamente la prueba de bloque completa, **El grado de descentralización del Prover será mejor (los requisitos de hardware se pueden reducir). **
Active Liveness: La red Liveness en general es buena, porque L2 tiene su propia red p2p para transmitir transacciones y votos/BP, y Sequencer y Prover están relativamente descentralizados. Pero necesitamos resolver los dos problemas que mencionamos anteriormente. Uno es que el bloque con el puntaje más alto debe ser un bloque legal, y el segundo es que debe esperar a que se envíe la prueba de bloque completa a L1 antes de ingresar un nuevo bloque. estado. Por lo tanto, se necesita un mecanismo de incentivos más efectivo para evitar que toda la red de Rollup funcione mal (tiempo de inactividad) debido a la falta de cierta parte de la prueba de tx.
**Resistencia a la censura: **Si podemos garantizar que cualquier persona puede publicar la propuesta de bloque BP y asegurarnos de que no solo el Proponente puede enviar pruebas de bloqueo, entonces la red tendrá una buena resistencia a la censura.
**Finalidad: **La finalidad de L2 está estrechamente relacionada con la vitalidad de la red, porque la finalidad final verificada aún debe esperar el envío de la prueba de bloque, pero de hecho también puede confiar en el contenido del bloque correspondiente a un BP con la puntuación más alta (siempre y cuando 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 debe esperar una Ventana de propuesta de bloque y el bloque donde se puede aceptar la transacción que envió.
Heredar la seguridad de L1: Como un L2 que actualiza su estado al enviar una prueba de validez, puede heredar la seguridad de L1.
Propuesta Fernet: Introducir VDF para seleccionar Proponente legal
Introducción al esquema Fernet: A través de VDF, en cada ronda del ciclo de generación de bloques, se establece una puntuación estimada para diferentes nodos del Comité (es decir, el conjunto de nodos del Secuenciador), y el bloque propuesto por el Secuenciador con el la puntuación final más alta pasará a ser pieza válida.
**Primero, ¿cómo unirse al Comité? De hecho, debe comprometer 16 ETH en L1, ** y esperar 4 bloques L1 después de que se complete la operación de compromiso, y luego unirse al Comité Secuenciador. En cuanto a salir del Comité Secuenciador, debe llamar a la función Unstake en el contrato L1, y luego puede recuperar el monto restante de su compromiso después de otros 3 días.
Entonces, ¿qué es un VDF? La función de retardo verificable es una función de retardo verificable. Esta función matemática satisface las estrictas características de ejecución en serie. Realizará algunos pasos de cálculo y consumirá al menos un período de tiempo predecible. Registramos el valor calculado por VDF como Score, que satisface una distribución normal uniforme. Por lo tanto, después de que Sequencer calcula VDF Score, puede juzgar la probabilidad de ser seleccionado como proponente legal. **
El VDF del secuenciador se calcula de la siguiente manera:
entradas públicas = { número de bloque actual , randao }
randao es un número aleatorio que se usa para evitar que Sequencer calcule su propia puntuación VDF en todas las alturas de bloque futuras por adelantado
Todo el proceso de Fernet se divide principalmente en 3 etapas:
Fase de propuesta 2. Fase de prueba 3. Finalización
**Fase de propuesta:**PROPUESTA_FASE_L1_BLOCKS = 2 bloques Ethereum (esta fase tendrá una duración de 2 bloques L1)
Al comienzo de esta etapa, cada secuenciador utilizará VDF para calcular su puntuación VDF correspondiente a la altura de bloque actual. Si Sequencer cree que es probable que su puntaje VDF gane el derecho a producir un bloque esta vez (suponiendo que el puntaje satisfaga una distribución normal), entonces enviará un contrato de resumen de propuesta a L1. La propuesta contiene: el hash de la secuencia de transacciones, que apunta a qué bloque L2 anterior.
bloque no probado: Solo se presenta el contenido del bloque de la Propuesta al contrato de Rollup. A continuación, **Sequencer necesita enviar el contenido del bloque correspondiente al bloque no probado y la prueba de VDF a la red L2 p2p. **
ProvingPhase: PROVING_PHASE_L1_BLOCKS= 50 bloques L1 (esta fase mantendrá 50 bloques L1, unos 10 min)
Prover recibe todas las transacciones correspondientes en Block Contents de la red L2 p2p, y construirá Proof para bloques con mayor VDF Score. La construcción de Proof también adopta el método de múltiples Provers colaborando en paralelo (similar al esquema B52).
Por lo tanto, Sequencer necesita agregar pruebas correspondientes a varias transacciones diferentes en una prueba de bloque (incluida la prueba VDF) al final y enviarla al contrato de acumulación de L1. Cualquiera puede enviar contenido de bloque que haya enviado prueba de bloque al contrato de resumen.
Finalización: Es necesario enviar una transacción L1 para finalizar el bloque. Un bloque que se puede finalizar debe cumplirse: se envían los contenidos del bloque y la prueba del bloque, y el bloque anterior al que se apunta debe finalizarse. Sobre la base de cumplir con las condiciones anteriores, también debe tener la puntuación más alta.
Mecanismo de producción de bloques de pipeline: Cabe señalar que Fernet adopta un mecanismo de producción de bloques de pipeline, cuando finaliza la fase de Propuesta del bloque N, comienza la Propuesta del bloque N+1 (Aptos y otras cadenas públicas también tienen prácticas similares). Pero para el bloque N+1, debe esperar a que finalice el bloque N antes de poder enviar la transacción del bloque final L1 y pasar la verificación para convertirse en un bloque final.
Dimensiones potenciales del ataque: Si el secuenciador con la puntuación VDF más alta deliberadamente no transmite los contenidos del bloque en L2 p2p, puede provocar la reorganización del bloque.
Cálculo del número de bloques L2 en reorganización: 1+DEMOSTRACIÓN_FASE_L1_BLOQUES / PROPUESTA_FASE_L1_BLOQUES =1+50/2=26 bloques
Solución: Aumente 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 Fernet en términos de descentralización: Sequencer se une al Comité de Secuenciadores prometiendo 16 ETH, y el umbral de entrada no es alto (pero no bajo). Prover no requiere ningún compromiso, pero no hay penalización si Prover no genera Prueba. Esto es básicamente lo contrario del esquema B52.
**Active Liveness: **Se puede garantizar el Liveness de la red en general, porque el mecanismo de bloques VDF+uncle puede garantizar que haya más de un productor de bloques en cada ronda.
**MEV: **Las consideraciones MEV son las más especiales. El plan planea introducir PBS, de modo que después de calcular una puntuación VDF alta como secuenciador, pueda encontrar directamente un generador de bloques para construir un bloque más valioso.
**Resistencia a la censura: **Fernet también adoptará el mismo mecanismo de PBS que Ethereum, por lo que, en esencia, el problema de anticensura de Fernet es equivalente al del PBS de Ethereum.
Ver originales
El contenido es solo de referencia, no una solicitud u oferta. No se proporciona asesoramiento fiscal, legal ni de inversión. Consulte el Descargo de responsabilidad para obtener más información sobre los riesgos.
Análisis de la propuesta B52 de Aztec Labs: ¿Cómo realiza ZK-Rollup la descentralización de los nodos secuenciadores?
Autor: 0xhhh, EthStorage
Editor: Fausto, Geek web3
Introducción: desde que Rollup se hizo popular, la descentralización de Sequencer siempre ha sido el foco de la comunidad de Ethereum/Celestia, y también es una montaña insuperable en la investigación y el desarrollo de Layer2. En este sentido, diferentes esquemas de Rollup han propuesto ideas sobre la descentralización de nodos, brindando un espacio de imaginación extremadamente amplio para este tema.
El autor de este artículo toma como ejemplo el conocido proyecto ZKRollup Aztec, y utiliza las dos propuestas denominadas B52 y Fernet propuestas recientemente por Aztec Labs como punto de partida para analizar cómo ZKR realiza la descentralización de los nodos secuenciadores para los lectores.
Propuesta B52: esquema de secuenciador sin permiso
La propuesta B52 pretende lograr lo siguiente (idealmente):
Red de secuenciador descentralizada, los propios nodos L2 eligen cada ronda de proponentes
Red de prueba descentralizada, bajos requisitos de hardware para nodos de prueba
Rollup tiene buena resistencia a la censura en su conjunto.
El valor MEV generado por L2 es adquirido por los nodos L2
Cuando el bloque L2 se envía a la capa DA, se puede obtener una finalidad más efectiva, y la finalidad irreversible tiene que esperar a que se envíe ValidityProof (prueba de validez).
El token L2 puede tener un buen modelo económico
Tanto los bloques L2 como los datos de transacción se propagan en la red L2 p2p
L2 hereda la seguridad de L1
Este esquema divide todo el proceso de producción del bloque L2 en tres etapas de tiempo:
Entre ellos, la etapa BPW (propuesta de bloque) es un proceso en el que múltiples secuenciadores Seuqnecer proponen diferentes bloques y compiten, y Prover selecciona un bloque candidato para votar.
BAW (aceptación de bloque) es el proceso en el que Prover construye una prueba de validez para un bloque y la envía.
Ventana de propuesta de bloque (etapa de propuesta de bloque):
BPW se puede subdividir en tres etapas: Propuesta en bloque, Votación en bloque, Agregación.
Cualquier persona en la fase de propuesta de bloque (BP) puede recopilar transacciones y transmitir su propio contenido de BP. El contenido de BP contendrá tres partes: hash de orden de txs, porcentaje de recompensa del probador, cantidad de token de quemado
hash de orden de txs: el proponente selecciona y ordena el lote de transacciones más valioso del grupo de transacciones L2 (mempool) y luego coloca el valor hash de este lote de transacciones en el bloque que construye.
porcentaje de recompensa del probador: El porcentaje de recompensa del bloque compartido por Sequencer to Prover
cantidad de token quemado: El número de token nativo L2 propuesto por el Proponente para ser destruido, y luego envía el BP propuesto a la red p2p L2
Etapa de votación en bloque:
Después de que el Demostrante reciba el BP propuesto por diferentes Proponentes en la red p2p, votará por el BP que pueda obtener la mayor recompensa. Sin embargo, la composición del voto es muy especial:
Vote={BlockHash, índice del árbol de prueba}
BlockHash es el hash de la Propuesta sobre la que votará Prover, e Index of Proof Tree es el valor del índice de hoja del Proof Tree en el que Prover participará en la construcción (se explica más adelante)
Agregación de agregación: El proponente recopila los votos de Provers para BP en la red p2p L2, los agrega y los coloca en BP, y los envía a L1 (cada BP generalmente solo contiene registros de votación relacionados con él mismo).
Aquí es necesario enfatizar los prerrequisitos para que BP sea seleccionado e incluido en el libro mayor de Rollp:
Tener la puntuación más alta:
PUNTUACIÓN (y) = NÚM_PRUEBAS (x)^3 * QUEMA_BID(z)^2
NUM_PROVERS (x) es el número de votos Prover obtenidos por el BP, y BURN_BID es el número de Tokens L2 propuestos para ser destruidos por el BP. Dado que cuanto mayor sea BURN_BID, menos recompensa obtendrá el proponente de BP al final, por lo que este valor debe establecerse correctamente.
Al mismo tiempo, el BP debe enviarse a L1 antes del final de la Ventana de propuesta de bloque, y la prueba de validez correspondiente debe cargarse a L1 antes del final de la Ventana de aceptación de bloque.
Nota: En el cálculo de las puntuaciones de BP, el número de votos representa la mayor proporción, seguido del número de fichas quemadas. Al mismo tiempo, el esquema B52 permite que múltiples proponentes (en realidad secuenciadores) compitan por una cuota efectiva de BP
El esquema B52 solo requiere que el Proponente (secuenciador) especifique la cantidad de tokens de grabación en su propio BP (similar al método de EIP1559) sin tokens de participación por adelantado, lo que puede hacer que la red no tenga permiso (sin permiso de acceso), y es también beneficioso para L2 Native Token produce deflación.
Además, BP no contiene datos completos de la transacción, sino solo el hash de la secuencia de la transacción. La razón es similar al esquema Ethereum PBS, que tiene como objetivo evitar que MEV sea espiado por otros Proponentes.
Ventana de aceptación de bloques (etapa de aceptación de bloques) explicación detallada:
Una vez que finaliza la ventana de propuesta de bloque, Prover debe revelar los datos completos de la transacción correspondientes a su BP. Si se selecciona el BP votado por el Demostrante (la puntuación más alta se puede consultar a través del contrato L1), deben construir el Sub Árbol de Prueba correspondiente al Índice de Árbol de Prueba dado durante la votación.
Suponiendo que el bloque de Aztec contiene 2 ^ 13 = 16 384 transacciones y hay 2048 probadores, entonces cada probador construye un árbol de prueba secundario que consta de transacciones 2 ^ 3 = 8. Luego, el probador transmite el árbol de prueba secundario construido por sí mismo a In the L2 p2p red. Después de que el proponente lo reciba, agregará todos los subárboles de prueba en una prueba de bloque.
Luego, el Proponente envía la prueba agregada al contrato L1 Rollup, y el contrato verificará la exactitud de la prueba y los resultados de transición de estado correspondientes. Cabe señalar aquí que si el Prover deliberadamente no presenta la prueba, no solo no podrá obtener el dividendo de recompensa en bloque prometido por el Proponente, sino que también será reducido, porque para convertirse en Prover, necesita Token de compromiso por adelantado. Por lo tanto, a diferencia de Proposer (secuenciador), Prover no es sin permiso.
Avance estatal (etapa de avance estatal) explicación detallada:
Después de que finalice la ventana de aceptación del bloque, el contrato de acumulación seleccionará un bloque con la puntuación más alta para incluirlo en el libro mayor de acumulación y enviará la recompensa de recompensa del bloque al Proponente y al Probador respectivamente de acuerdo con la proporción declarada por el Proponente (Secuenciador) en avance.
La anterior es la solución B52 de Aztec. Sin embargo, el autor de este artículo cree que existen algunos problemas potenciales con la propuesta B52:
Pregunta 1: Si 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 las recompensas del bloque, para garantizar que el Proponente no tenga ninguna motivación para no presentar deliberadamente una prueba completa. Al mismo tiempo, Prover también puede presentar pruebas directamente al contrato.
De acuerdo con la descripción de la propuesta, es aceptable aceptar un bloque sin una prueba de validez de transacciones completas. En realidad, esto no es razonable: porque: zkrollup solo declara que el nuevo estado correspondiente a este bloque es válido cuando se proporciona la prueba de validez.
Si a la prueba agregada enviada por el proponente a L1 le falta la prueba de una determinada transacción, es obvio que las pruebas de transición de estado de todas las transacciones que ocurren después de esta transacción no son válidas (porque las transacciones se ejecutan secuencialmente y tienen dependencias de estado), nosotros También es imposible 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 que espera infinitamente hasta que se presenten todas las pruebas de la transacción.
Pregunta 2: **Si el bloque con mayor puntaje es un bloque ilegal (esto no se explica en el esquema B52). **BP solo contiene el hash de la secuencia de la transacción, por lo que un proponente malintencionado puede construir deliberadamente transacciones problemáticas, como transacciones de doble gasto. Entonces, en este momento, es necesario agregar una función en el contrato L1 para que cualquiera pueda enviar una prueba ilegal. Esta prueba ilegal se usa para demostrar que el BP con la puntuación más alta es un bloque ilegal.
Y este tipo de informe debe ser recompensado, podemos recompensar el token de quemado enviado por el proponente del contrato al nodo informador que envió la prueba ilegal.
**Pensamiento interesante:**Acerca de los bloques de tíos y el trabajo de demostración redundante: el esquema B52 en realidad usará otros BP (que hayan enviado pruebas completas) que aparecen en esta ronda como tíos después de que aparezca el BP con la puntuación más alta y efectivo en cada ronda. bloque, asigne una determinada recompensa de bloque de tío.
En realidad, esto sigue el enfoque del mecanismo de consenso ETH POW. Para evitar una concentración excesiva de poder de cómputo, es necesario asignar una parte de las recompensas de bloque a los proponentes de bloque no aceptados (mineros) para proteger los intereses de los pequeños grupos mineros/mineros individuales. y evitar que el poder de cómputo esté monopolizado por grandes grupos mineros. Por lo tanto, también es una opción muy inteligente adoptar el mecanismo de bloque tío que Ethereum realiza bien.
La importancia de la propuesta B52 en términos de descentralización de acumulación: El proponente está descentralizado y no requiere compromiso, y el umbral de entrada es bajo; pero porque necesita construir los bloques más valiosos usted mismo y necesita recopilar votos de otros Proponentes y agregar todas las Pruebas. De hecho, el umbral de hardware del Proponente no es tan bajo como se indica en la propuesta (por ejemplo, el ancho de banda puede no ser muy bajo).
Por lo tanto, eventualmente se convertirá en una red relativamente centralizada, similar a Mev-Boost Builder, porque el proponente que finalmente puede generar bloques es a menudo el Block Builder que es mejor para capturar MEV.
Al mismo tiempo, el Prover en el esquema B52 necesita comprometer activos, pero debido a que solo se necesita generar la prueba del subárbol, en comparación con aquellos esquemas que necesitan generar completamente la prueba de bloque completa, **El grado de descentralización del Prover será mejor (los requisitos de hardware se pueden reducir). **
Active Liveness: La red Liveness en general es buena, porque L2 tiene su propia red p2p para transmitir transacciones y votos/BP, y Sequencer y Prover están relativamente descentralizados. Pero necesitamos resolver los dos problemas que mencionamos anteriormente. Uno es que el bloque con el puntaje más alto debe ser un bloque legal, y el segundo es que debe esperar a que se envíe la prueba de bloque completa a L1 antes de ingresar un nuevo bloque. estado. Por lo tanto, se necesita un mecanismo de incentivos más efectivo para evitar que toda la red de Rollup funcione mal (tiempo de inactividad) debido a la falta de cierta parte de la prueba de tx.
**Resistencia a la censura: **Si podemos garantizar que cualquier persona puede publicar la propuesta de bloque BP y asegurarnos de que no solo el Proponente puede enviar pruebas de bloqueo, entonces la red tendrá una buena resistencia a la censura.
**Finalidad: **La finalidad de L2 está estrechamente relacionada con la vitalidad de la red, porque la finalidad final verificada aún debe esperar el envío de la prueba de bloque, pero de hecho también puede confiar en el contenido del bloque correspondiente a un BP con la puntuación más alta (siempre y cuando 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 debe esperar una Ventana de propuesta de bloque y el bloque donde se puede aceptar la transacción que envió.
Heredar la seguridad de L1: Como un L2 que actualiza su estado al enviar una prueba de validez, puede heredar la seguridad de L1.
Propuesta Fernet: Introducir VDF para seleccionar Proponente legal
Introducción al esquema Fernet: A través de VDF, en cada ronda del ciclo de generación de bloques, se establece una puntuación estimada para diferentes nodos del Comité (es decir, el conjunto de nodos del Secuenciador), y el bloque propuesto por el Secuenciador con el la puntuación final más alta pasará a ser pieza válida.
**Primero, ¿cómo unirse al Comité? De hecho, debe comprometer 16 ETH en L1, ** y esperar 4 bloques L1 después de que se complete la operación de compromiso, y luego unirse al Comité Secuenciador. En cuanto a salir del Comité Secuenciador, debe llamar a la función Unstake en el contrato L1, y luego puede recuperar el monto restante de su compromiso después de otros 3 días.
Entonces, ¿qué es un VDF? La función de retardo verificable es una función de retardo verificable. Esta función matemática satisface las estrictas características de ejecución en serie. Realizará algunos pasos de cálculo y consumirá al menos un período de tiempo predecible. Registramos el valor calculado por VDF como Score, que satisface una distribución normal uniforme. Por lo tanto, después de que Sequencer calcula VDF Score, puede juzgar la probabilidad de ser seleccionado como proponente legal. **
El VDF del secuenciador se calcula de la siguiente manera:
Puntuación = VDF (clave privada, entradas públicas)
entradas públicas = { número de bloque actual , randao }
randao es un número aleatorio que se usa para evitar que Sequencer calcule su propia puntuación VDF en todas las alturas de bloque futuras por adelantado
Todo el proceso de Fernet se divide principalmente en 3 etapas:
**Fase de propuesta:**PROPUESTA_FASE_L1_BLOCKS = 2 bloques Ethereum (esta fase tendrá una duración de 2 bloques L1)
Al comienzo de esta etapa, cada secuenciador utilizará VDF para calcular su puntuación VDF correspondiente a la altura de bloque actual. Si Sequencer cree que es probable que su puntaje VDF gane el derecho a producir un bloque esta vez (suponiendo que el puntaje satisfaga una distribución normal), entonces enviará un contrato de resumen de propuesta a L1. La propuesta contiene: el hash de la secuencia de transacciones, que apunta a qué bloque L2 anterior.
bloque no probado: Solo se presenta el contenido del bloque de la Propuesta al contrato de Rollup. A continuación, **Sequencer necesita enviar el contenido del bloque correspondiente al bloque no probado y la prueba de VDF a la red L2 p2p. **
ProvingPhase: PROVING_PHASE_L1_BLOCKS= 50 bloques L1 (esta fase mantendrá 50 bloques L1, unos 10 min)
Prover recibe todas las transacciones correspondientes en Block Contents de la red L2 p2p, y construirá Proof para bloques con mayor VDF Score. La construcción de Proof también adopta el método de múltiples Provers colaborando en paralelo (similar al esquema B52).
Por lo tanto, Sequencer necesita agregar pruebas correspondientes a varias transacciones diferentes en una prueba de bloque (incluida la prueba VDF) al final y enviarla al contrato de acumulación de L1. Cualquiera puede enviar contenido de bloque que haya enviado prueba de bloque al contrato de resumen.
Finalización: Es necesario enviar una transacción L1 para finalizar el bloque. Un bloque que se puede finalizar debe cumplirse: se envían los contenidos del bloque y la prueba del bloque, y el bloque anterior al que se apunta debe finalizarse. Sobre la base de cumplir con las condiciones anteriores, también debe tener la puntuación más alta.
Mecanismo de producción de bloques de pipeline: Cabe señalar que Fernet adopta un mecanismo de producción de bloques de pipeline, cuando finaliza la fase de Propuesta del bloque N, comienza la Propuesta del bloque N+1 (Aptos y otras cadenas públicas también tienen prácticas similares). Pero para el bloque N+1, debe esperar a que finalice el bloque N antes de poder enviar la transacción del bloque final L1 y pasar la verificación para convertirse en un bloque final.
Dimensiones potenciales del ataque: Si el secuenciador con la puntuación VDF más alta deliberadamente no transmite los contenidos del bloque en L2 p2p, puede provocar la reorganización del bloque.
Cálculo del número de bloques L2 en reorganización: 1+DEMOSTRACIÓN_FASE_L1_BLOQUES / PROPUESTA_FASE_L1_BLOQUES =1+50/2=26 bloques
Solución: Aumente 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 Fernet en términos de descentralización: Sequencer se une al Comité de Secuenciadores prometiendo 16 ETH, y el umbral de entrada no es alto (pero no bajo). Prover no requiere ningún compromiso, pero no hay penalización si Prover no genera Prueba. Esto es básicamente lo contrario del esquema B52.
**Active Liveness: **Se puede garantizar el Liveness de la red en general, porque el mecanismo de bloques VDF+uncle puede garantizar que haya más de un productor de bloques en cada ronda.
**MEV: **Las consideraciones MEV son las más especiales. El plan planea introducir PBS, de modo que después de calcular una puntuación VDF alta como secuenciador, pueda encontrar directamente un generador de bloques para construir un bloque más valioso.
**Resistencia a la censura: **Fernet también adoptará el mismo mecanismo de PBS que Ethereum, por lo que, en esencia, el problema de anticensura de Fernet es equivalente al del PBS de Ethereum.