• Suivant le titre original：Decentralizing Rollup : analyse de la solution de séquenceur décentralisé d'Aztec

Introduction : Depuis que Rollup a pris de l'importance, la communauté Ethereum/Celestia s'est toujours concentrée sur la décentralisation du Sequencer, et c'est également une montagne difficile à franchir dans le cadre du travail de développement de Layer2. À cet égard, différents plans Rollup ont proposé des idées pour la décentralisation des nœuds, laissant libre cours à une très large imagination sur ce sujet.

L'auteur de cet article prend l'exemple du célèbre projet ZKRollup Aztec et utilise les deux propositions nommées B52 et Fernet récemment proposées par Aztec Labs comme point d'entrée, afin d'analyser aux lecteurs comment ZKR réalise la décentralisation des nœuds du séquenceur.

Proposition B52 : Schéma de séquenceur sans autorisation

La proposition B52 vise à atteindre les objectifs suivants (idéalement) :

1. Réseau de séquenceur décentralisé, avec des nœuds L2 qui élisent les proposants pour chaque tour.

2. Réseau d'essais décentralisé, peu exigeant en termes de matériel pour les nœuds d'essai.

3. Rollup possède une excellente résistance à la censure dans l'ensemble.

4. La valeur MEV générée sur L2 est obtenue par les nœuds L2.

5. Lorsque les blocs L2 sont soumis à la couche DA, une finalité relativement efficace peut être obtenue. Pour obtenir une finalité irréversible, il faut remplir la preuve de validité.

6. Les jetons L2 peuvent avoir un bon modèle de tokenomique.

7. Les données de bloc et de transaction L2 sont propagées sur le réseau p2p de la L2.

8. La L2 hérite de la sécurité de la L1.

(La proposition B52 repose sur la structure du rollup, le proposant étant essentiellement le séquenceur)

Ce plan divise l'ensemble du processus de production des blocs L2 en trois étapes :

Fenêtre de proposition de bloc (BPW) Fenêtre d'acceptation de bloc (BAW) Avancées d'état

Parmi elles, l'étape BPW (Block Proposal) est le processus au cours duquel plusieurs séquenceurs proposent différents blocs et s'affrontent, et Prover sélectionne un bloc de candidats pour voter. Le BAW (Block Acceptance) est le processus par lequel Prover crée une preuve de validité pour le bloc et la soumet. Fenêtre de proposition en bloc (phase de proposition en bloc) : Le BPW peut être subdivisé en trois étapes : proposition en bloc, vote en bloc, agrégation.

(Schéma du processus de la fenêtre de proposition par blocs)

Étape Block Proposal (BP) : chaque participant peut collecter des transactions et diffuser son propre contenu BP. Le contenu BP comprendra trois parties : le hachage de la commande TXS, le pourcentage de récompense du prouveur, le montant du jeton à brûler.

hachage de la commande txs : Le proposant sélectionne le lot de transactions le plus précieux dans le pool de transactions L2 (mempool), les trie, puis place la valeur de hachage de ces transactions dans le bloc qu'il est en train de créer. pourcentage de récompenses du prover : le pourcentage des récompenses par bloc que le séquenceur partage avec le prouveur. montant du jeton de gravure : la quantité de jetons natifs L2 que le proposant propose de brûler, puis il envoie son BP au réseau P2P L2.

Étape du vote par bloc :

Une fois que le Prover aura reçu des BP proposés par différents proposants sur le réseau p2p, il votera pour le BP qui lui permettra d'obtenir le plus de récompenses. Cependant, la composition des voix est particulière :

Vote={BlockHash, Index of Proof Tree}

BlockHash est le hash de la proposition pour laquelle Prover veut voter, et Index of Proof Tree est la valeur de l'indice foliaire de l'arbre de preuve à la construction duquel Prover souhaite participer (cela sera expliqué plus tard)

Agrégation : Le Proposeur collecte les votes des Provers sur le BP sur le réseau P2P L2, les agrège et les place dans le BP, puis les soumet à la L1 (chaque BP ne contient généralement que des records de vote qui le concernent lui-même).

Ici, il faut souligner la condition préalable pour que BP soit sélectionnée et incluse dans le registre Rollp :

Ayant obtenu le meilleur score :

SCORE (y) = NUM_PROVERS (x) ^3 * BURN_BID (z) ^2`

NUM_PROVERS (x) est le nombre de votes de proue que ce BP a obtenus, et BURN_BID est le nombre de jetons L2 proposés pour être brûlés par ce BP. Parce que plus le BURN_BID est élevé, moins le proposant de BP obtiendra de récompenses au final. Cette valeur doit donc être réglée de manière appropriée.

En même temps, ce BP doit être soumis à la L1 avant la fin de la fenêtre de proposition de blocage, et la preuve de validité correspondante doit être téléchargée en L1 avant la fin de la fenêtre d'acceptation de bloc.

Remarque : dans le classement de BP, le nombre de votes occupe la plus grande place, suivi du nombre de burn tokens. Dans le même temps, le système B52 permet à plusieurs proposants (en fait des séquenceurs) de s'affronter pour un quota BP valide.

Le schéma B52 oblige uniquement le Proposeur (séquenceur) à spécifier le nombre de jetons à brûler dans son propre BP (comme pour la méthode EIP1559) sans avoir à miser des jetons à l'avance, ce qui peut rendre le réseau moins autorisé (pas d'autorisation d'admission) et favorise également la déflation native des jetons en L2.

De plus, le BP ne contient pas de données complètes sur les transactions, mais uniquement le hachage de la séquence des transactions, qui est similaire au schéma PBS d'Ethereum, dans le but d'éviter que le MEV ne soit vu et devancé par les autres proposants.

Explication détaillée de la fenêtre d'acceptation des blocs :

(Schéma de la fenêtre d'acceptation des blocs, écrit comme preuve d'acceptation sur la photo)

Une fois la fenêtre de proposition de blocage terminée, le Prover doit révéler les données complètes de ses transactions, correspondant à son BP. Si le BP pour lequel le Prover vote est sélectionné (il a obtenu le meilleur score, ce qui peut être demandé dans le cadre du contrat L1), il doit créer l'arbre des sous-preuves correspondant à l'indice de l'arbre de preuve indiqué lors du vote.

Supposons qu'un bloc aztèque contienne 2^13=16 384 quantités de transactions, et qu'il y ait 2 048 preuves, puis chaque prouveur construit un arbre de sous-preuves composé de 2^3=8 transactions. Ensuite, le testeur diffuse l'arbre de sous-preuve qu'il a construit sur le réseau P2P L2. Après l'avoir reçu, l'auteur de la proposition regroupera tous les arbres de sous-preuves pour former une preuve par blocs.

Propsoer soumettra ensuite la preuve agrégée au contrat L1 Rollup, qui vérifiera l'exactitude de cette preuve et les résultats de la transition d'État correspondants. Il convient de noter ici que si Prover ne soumet pas délibérément la preuve, non seulement il ne recevra pas les dividendes globaux promis par le Proposeur, mais il sera également réduit, car pour devenir Prover, il faut miser des jetons à l'avance. Par conséquent, contrairement au Proposer (Sequencer), le Prover n'est pas sans autorisation.

Explication détaillée des avancées de l'État :

À la fin de la fenêtre d'acceptation des blocs, le contrat de cumul sélectionnera le bloc ayant obtenu le meilleur score à inclure dans le registre de cumul, et la récompense du bloc sera envoyée au proposant (séquenceur) et au prouveur dans la proportion précédemment déclarée par le proposant.

Ce qui précède est le schéma B52 d'Aztec. L'auteur de cet article pense toutefois que la proposition B52 présente certains problèmes potentiels :

Problème 1 : supposons que la preuve de validité d'un bloc ayant obtenu le score le plus élevé soit incomplète. La solution proposée dans la proposition est que si le proposant ne fournit que 50 % de la preuve, il ne pourra obtenir que 50 % de la récompense globale, ce qui ne l'incitera pas à ne pas soumettre délibérément une preuve complète. Dans le même temps, le Prover peut également soumettre directement la preuve du contrat.

Selon la description de la proposition, il est acceptable qu'un bloc ne soit pas accompagné d'une preuve complète de validité de la transaction. C'est en fait déraisonnable car zkrollup déclare que le nouvel état correspondant à ce bloc est valide uniquement lorsque la preuve de validité est fournie.

Si la preuve globale que le proposant soumet finalement à L1 ne contient pas la preuve d'une certaine transaction, il est évident que la preuve de transition d'état de toutes les transactions effectuées après cette transaction n'est pas valide (car les transactions sont exécutées dans l'ordre et dépendent de l'état), et nous ne pouvons pas confirmer que le nouvel état correspondant à ce bloc est valide.

Par conséquent, pour le moment, la solution raisonnable devrait être d'entrer dans la fenêtre d'acceptation des blocs infinie jusqu'à ce que toutes les preuves de transaction soient soumises.

Problème 2 : Supposons que le bloc le plus marqué soit illégal (ce point n'est pas expliqué dans le plan B52). Le BP ne contient que le hachage de la séquence des transactions, de sorte qu'un proposant malveillant pourrait intentionnellement créer des transactions problématiques, comme des transactions à double dépense. Pour le moment, il est en fait nécessaire d'ajouter une fonction au contrat L1 qui permet à quiconque de soumettre une preuve illégale. Cette preuve illégale est utilisée pour prouver que le score le plus élevé est un blocage illégal.

De plus, ce type de rapport devrait être récompensé. Nous pouvons donner tous les burn tokens envoyés au contrat par le proposant en récompense au nœud qui a soumis la preuve illégale.

Une idée intéressante : À propos des blocages d'oncles et de la redondance de Prover Work : Le plan B52 traitera les autres BP (qui ont soumis des preuves complètes) au cours de ce round comme des blocs d'oncle et distribuera un certain nombre de récompenses de bloc-oncle.

Cela suit en fait la pratique du mécanisme de consensus POW de l'ETH. Pour éviter une concentration excessive de la puissance informatique, il est nécessaire d'allouer une partie de la récompense globale aux proposants des blocs qui ne sont pas adoptés (mineurs), afin de protéger les intérêts des petits pools miniers et des mineurs individuels et pour empêcher que la puissance minière ne soit monopolisée par de grands pools miniers. Par conséquent, adopter le très performant mécanisme de blocage des oncles d'Ethereum est également un choix très intelligent.

L'importance de la proposition B52 en termes de décentralisation cumulative : le proposant est décentralisé et n'a pas besoin d'engagement, et la barrière d'entrée est faible. Cependant, comme cela nécessite de créer lui-même le bloc le plus précieux, de recueillir les votes des autres Provers et d'agréger toutes les preuves, le seuil matériel du proposant n'est pas aussi bas que celui décrit dans la proposition (par exemple, la bande passante n'est peut-être pas très faible).

Par conséquent, il finira par devenir un réseau plus centralisé, similaire à Mev-Boost Builder, car le proposant qui finira par produire le bloc est souvent le Block Builder qui est le meilleur pour capturer le MEV.

Dans le même temps, le Prover du schéma B52 doit mettre des actifs en gage, mais comme il n'a besoin que de générer une preuve de sous-arborescence, par rapport aux solutions qui doivent générer la totalité de la preuve par blocs, le degré de décentralisation du Prover sera meilleur (la configuration matérielle requise peut être abaissée).

Liveness : L'ensemble du réseau Liveness est bon, car L2 possède son propre réseau p2p pour diffuser les transactions et les votes/BP, et Sequencer et Prover sont tous deux relativement décentralisés. Mais nous devons résoudre les deux problèmes mentionnés plus haut : le premier est que le bloc le plus marqué doit être un bloc légal, et le second est que nous devons attendre que la preuve complète soit soumise à la L1 avant d'entrer dans un nouvel État. Par conséquent, un mécanisme d'incitation plus efficace est nécessaire pour éviter que l'ensemble du réseau Rollup ne fonctionne pas normalement (arrêt) faute de preuve fiscale.

Résistance à la censure : Si nous pouvons faire en sorte que tout le monde puisse publier des propositions bloquées BP, et faire en sorte que le proposant ne soit pas le seul à soumettre des preuves de blocage, alors le réseau résistera bien à la censure.

Finalité : La finalité de la L2 est étroitement liée à la vivacité du réseau, car la finalité finale vérifiée doit encore attendre la soumission de Block Proof, mais en fait, vous pouvez également vous fier au contenu du bloc correspondant au BP le plus élevé (tant qu'il ne contient pas de transactions malveillantes).

Ce blocage sera révélé au début de la fenêtre d'acceptation des blocages, ce qui signifie qu'en tant qu'utilisateur, vous n'aurez qu'à attendre le temps de la fenêtre de proposition de blocage, pour que le bloc dans lequel se trouve votre transaction soit adopté.

Hériter de la sécurité L1 : en tant que L2 qui met à jour l'état en soumettant une preuve de validité, elle peut hériter de la sécurité de la L1.

Fernet Proposal : introduction du VDF pour la sélection des soumissionnaires

Présentation du schéma Fernet : En utilisant le VDF à chaque cycle de génération de blocs, un score projeté est attribué aux différents nœuds du Comité (l'ensemble des nœuds du séquenceur), et le bloc proposé par le séquenceur ayant le score final le plus élevé devient le bloc valide.

Tout d'abord, comment rejoindre le Comité ? En gros, il faut miser 16 ETH en L1, puis, une fois le processus de jalonnement terminé, attendre 4 blocs L1 avant de rejoindre le Sequencer Committee. Pour ce qui est de quitter le Sequencer Committee, il faut activer la fonction Unstake du contrat de L1, après quoi il faut 3 jours pour récupérer le montant misé restant.

Ensuite, qu'est-ce que le VDF ? La fonction de délai vérifiable est une fonction mathématique qui respecte des caractéristiques d'exécution en série strictes. Il exécute certaines étapes de calcul et prend un temps prévisible. Nous désignons la valeur calculée par VDF comme score, qui suit une distribution normale uniforme. Ainsi, une fois que le séquenceur aura calculé le score VDF, il pourra déterminer la probabilité d'être sélectionnée comme proposant légitime.

Le calcul de la VDF pour Sequencer est le suivant :

Score = VDF (clé privée, entrées publiques)

entrées publiques = { current block number , randao }

randao est un chiffre aléatoire utilisé pour empêcher Sequencers de calculer prématurément son score VDF pour toutes les hauteurs de blocs à venir

L'ensemble du processus de Fernet est principalement divisé en trois étapes :

1. Phase 2 de la proposition. Prouver la phase 3. Finalisation

Phase de proposition : PROPOSAL_PHASE_L1_BLOCKS = 2 blocs Ethereum (Cette phase durera 2 blocs L1)

Au début de cette phase, chaque séquenceur calculera son propre score VDF à la hauteur de bloc actuelle. Si le séquenceur pense que son score VDF est susceptible de remporter la production de ce bloc (en supposant que le score soit conforme à la distribution normale), il soumettra une proposition au contrat L1 Rollup. La proposition inclut : le hachage de la séquence de transactions, qui pointe vers un bloc L2 précédent.

bloc non prouvé : Le bloc qui n'a soumis que la proposition au contenu du bloc du contrat Rollup. Ensuite, le séquenceur doit envoyer le contenu du bloc correspondant au bloc non prouvé et à la preuve de VDF au réseau P2P L2.

Phase de démonstration : PROVING_PHASE_L1_BLOCKS= 50 blocs L1 (Cette phase durera 50 blocs L1, soit 10 minutes environ)

Le Prover reçoit toutes les transactions correspondant au contenu du bloc depuis le réseau P2P L2 et crée une preuve pour le bloc avec un score VDF plus élevé. La construction du Proof adopte également une méthode selon laquelle plusieurs Provers coopèrent en parallèle (comme dans le schéma B52).

Le séquenceur doit donc enfin agréger les preuves de plusieurs transactions différentes dans un Block Proof (y compris VDF Proof), et les soumettre au contrat L1 Rollup. Tout le monde peut soumettre le contenu du bloc s'il a déjà soumis le Block Proof au contrat Rollup.

Finalisation : Il faut soumettre une transaction L1 pour finaliser le bloc. Un bloc qui peut être finalement finalisé doit répondre à : contenu du bloc soumis et preuve du bloc, le bloc précédent vers lequel il pointe doit être finalisé. Sur cette base, elle doit également obtenir le meilleur score.

(Le processus de blocage de type pipeline, dès que la phase de proposition du bloc précédent se termine, la phase de proposition du bloc suivant commence, sans attendre la fin de la phase de validation du bloc précédent.)

Mécanisme de génération de blocs de canalisations : Il convient de noter que Fernet adopte un mécanisme de génération de blocs de canalisations. À la fin de la phase de proposition du bloc N, la proposition pour le bloc N+1 commence (comme le font Aptos et les autres chaînes publiques). Cependant, pour le bloc N+1, il doit attendre que le bloc N soit finalisé avant de pouvoir soumettre la transaction Final Block de L1 et être validée pour devenir le Final Block.

Vecteurs d'attaque potentiels : si le séquenceur ayant le score VDF le plus élevé ne diffuse pas intentionnellement le contenu des blocs en P2P de la L2, cela peut entraîner une réorganisation des blocs (réorganisation).

Calcul de la quantité de blocs L2 pour la réorganisation : 1+PROVING_PHASE_L1_BLOCKS/PROPOSAL_PHASE_L1_BLOCKS =1+50/2=26 blocs

Solution : Introduire le mécanisme des blocages afin d'éviter de n'avoir qu'un seul bloc de candidats complet par créneau L2 (créneau horaire de génération de blocs).

L'importance de la décentralisation chez Fernet : les séquenceurs rejoignent le Sequencer Committee en misant 16 ETH, et le seuil d'entrée n'est pas élevé (mais pas bas non plus). Les Provers n'ont pas besoin de staking, mais s'ils ne génèrent pas de Proof, il n'y a pas de pénalité. C'est tout à fait le contraire du schéma B52.

Vivacité : La vivacité globale du réseau peut être garantie car le mécanisme de blocage VDF + Oncle peut garantir qu'il y a plus d'un producteur de blocs à chaque round.

MEV : La prise en compte du MEV est particulièrement unique. Ce programme prévoit d'introduire le PBS. Ainsi, une fois qu'un séquenceur aura calculé un score VDF élevé, il pourra s'adresser directement au Block Builder pour créer un bloc plus précieux.

Résistance à la censure : Fernet adoptera également un mécanisme PBS compatible avec Ethereum. En gros, le problème de résistance à la censure de Fernet est équivalent au problème de résistance à la censure du PBS d'Ethereum.

Avertissement：

1. Cet article est repris de [Geek Web3], Forward the Original Title'Ollup Decentralization : Analysis of Aztec's Decentralized Sequencer Solution'. Tous les droits d'auteur appartiennent à l'auteur original [xhhh，ETHStorage]. En cas d'objection à cette réimpression, contactez l'équipe de Gate Learn, elle s'en occupera rapidement.
2. Avertissement en matière de responsabilité : Les points de vue et opinions exprimés dans cet article sont uniquement ceux de l'auteur et ne constituent en aucun cas un conseil d'investissement.
3. Les traductions de l'article dans d'autres langues sont effectuées par l'équipe de Gate Learn. Sauf mention contraire, il est interdit de copier, de distribuer ou de plagier les articles traduits.