Introduction : Depuis que Rollup est devenu populaire, la décentralisation de Sequencer a toujours été au centre de la communauté Ethereum/Celestia, et c'est aussi une montagne insurmontable dans la recherche et le développement de Layer2. À cet égard, différents schémas Rollup ont proposé des idées sur la décentralisation des nœuds, offrant un espace d'imagination extrêmement large pour ce sujet.
L'auteur de cet article prend comme exemple le 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 de départ pour analyser comment ZKR réalise la décentralisation des nœuds de séquenceur pour les lecteurs.
Proposition B52 : schéma de séquenceur sans autorisation
La proposition B52 vise à atteindre les objectifs suivants (idéalement) :
Réseau de séquenceur décentralisé, les nœuds L2 eux-mêmes élisent chaque tour de proposants
Réseau de preuves décentralisé, faible configuration matérielle requise pour les nœuds de preuves
Rollup a une bonne résistance à la censure dans son ensemble.
La valeur MEV générée par L2 est acquise par les nœuds L2
Lorsque le bloc L2 est soumis à la couche DA, une finalité plus efficace peut être obtenue, et la finalité irréversible doit attendre que le ValidityProof (preuve de validité) soit soumis
L2 Token peut avoir un bon modèle économique
Les blocs L2 et les données de transaction sont propagés dans le réseau p2p L2
L2 hérite de la sécurité de L1
Ce schéma divise l'ensemble du processus de production du bloc L2 en trois étapes :
Fenêtre de proposition de bloc (BPW)
Fenêtre d'acceptation des blocs (BAW)
Avances de l'État
Parmi eux, l'étape BPW (proposition de bloc) est un processus dans lequel plusieurs séquenceurs Seuqnecer proposent différents blocs et s'affrontent, et Prover sélectionne un bloc candidat pour donner un vote.
BAW (Block Acceptance) est le processus dans lequel le prouveur construit une preuve de validité pour un bloc et la soumet.
Fenêtre de proposition de bloc (étape de proposition de bloc) :
BPW peut être subdivisé en trois étapes : Proposition de bloc, Vote de bloc, Agrégation.
N'importe qui dans la phase de proposition de bloc (BP) peut collecter des transactions et diffuser son propre contenu BP. Le contenu BP contiendra trois parties : le hachage de la commande txs, le pourcentage de récompense du prouveur, le montant du jeton de gravure
txs order hash : Le proposant sélectionne et trie le lot de transactions le plus précieux du pool de transactions L2 (mempool), puis place la valeur de hachage de ce lot de transactions dans le bloc qu'il construit.
pourcentage de récompense du prouveur : le pourcentage de récompense du bloc partagé par le séquenceur au prouveur
burn token amount : Le nombre de jetons natifs L2 proposés par le proposant à détruire, puis il envoie le BP proposé au réseau p2p L2
Étape du vote en bloc :
Après avoir reçu le BP proposé par différents proposants du réseau p2p, le prouveur votera pour le BP qui lui rapportera le plus de récompenses. Cependant, la composition du vote est très particulière :
Vote={BlockHash, Index of Proof Tree}
BlockHash est le hachage de la proposition sur laquelle le prouveur votera, et l'index de l'arbre de preuve est la valeur de l'index de feuille de l'arbre de preuve que le prouveur participera à la construction (expliqué plus tard)
** Agrégation d'agrégation : ** Le proposant collecte les votes des Provers pour BP dans le réseau p2p L2, les agrège et les place dans BP, et les soumet à L1 (chaque BP ne contient généralement que des enregistrements de vote liés à lui-même).
** Ici, il est nécessaire de souligner les conditions préalables pour que BP soit sélectionné et inclus dans le registre Rollp : **
Avoir le score le plus élevé :
SCORE(y) = NUM_PROVERS (x)^3 * BURN_BID(z)^2
NUM_PROVERS (x) est le nombre de votes Prover obtenus par le BP, et BURN_BID est le nombre de Tokens L2 proposés à la destruction par le BP. Étant donné que plus le BURN_BID est élevé, moins le proposant BP obtiendra de récompense à la fin, donc cette valeur doit être définie correctement.
Dans le même temps, le BP doit être soumis à L1 avant la fin de la fenêtre de proposition de bloc, et la preuve de validité correspondante doit être téléchargée à L1 avant la fin de la fenêtre d'acceptation de bloc.
Remarque : dans le calcul des scores BP, le nombre de votes représente la plus grande proportion, suivi du nombre de jetons brûlés. Dans le même temps, le schéma B52 permet à plusieurs proposants (en fait des séquenceurs) de concourir pour un quota BP effectif
Le schéma B52 exige uniquement que le proposant (séquenceur) spécifie le nombre de jetons de gravure dans son propre BP (similaire à la méthode de EIP1559) sans jetons de mise à l'avance, ce qui peut rendre le réseau plus sans autorisation (pas d'autorisation d'accès), et est également bénéfique pour L2 Native Token produit une déflation.
De plus, BP ne contient pas de données de transaction complètes, mais uniquement le hachage de la séquence de transaction.La raison est similaire au schéma Ethereum PBS, qui vise à empêcher que MEV ne soit espionné par d'autres proposants.
Explication détaillée de la fenêtre d'acceptation des blocs (étape d'acceptation des blocs) :
Une fois la fenêtre de proposition de bloc terminée, le prouveur doit révéler les données de transaction complètes correspondant à son BP. Si le BP voté par le prouveur est sélectionné (le score le plus élevé peut être interrogé via le contrat L1), il doit construire le sous-arbre de preuve correspondant à l'index de l'arbre de preuve donné lors du vote.
En supposant que le bloc d'Aztec contient 2 ^ 13 = 16384 transactions et qu'il y a 2048 prouveurs, alors chaque prouveur construit un sous-arbre de preuve composé de 2 ^ 3 = 8 transactions. Ensuite, le prouveur diffuse l'arbre de sous-preuve construit par lui-même à In the L2 p2p réseau. Une fois que le proposant l'a reçu, il regroupera tous les sous-arbres de preuve dans une preuve de bloc.
Ensuite, Propsoer soumet la preuve agrégée au contrat L1 Rollup, et le contrat vérifiera l'exactitude de la preuve et les résultats de transition d'état correspondants. Il convient de noter ici que si le Prover omet délibérément de soumettre la preuve, non seulement il ne pourra pas obtenir le dividende de récompense global promis par le Proposer, mais il sera également amputé, car pour devenir un Prover, il doit gage de jeton à l'avance. Par conséquent, contrairement à Proposer (Sequencer), Prover n'est pas Permissionless.
Explication détaillée des avances d'état (étape d'avancement d'état) :
Après la fin de la fenêtre d'acceptation de bloc, le contrat de cumul sélectionnera un bloc avec le score le plus élevé à inclure dans le grand livre de cumul, et enverra la récompense de récompense de bloc au proposant et au prouveur respectivement selon la proportion déclarée par le proposant (séquenceur) dans avance.
**Ce qui précède est la solution B52 d'Aztec. Cependant, l'auteur de cet article pense qu'il y a des problèmes potentiels avec la proposition B52 : **
Question 1 : Si la preuve de validité d'un bloc avec le score le plus élevé est incomplète. La solution proposée dans la proposition est que si le proposant ne fournit que 50 % de la preuve, il ne peut obtenir que 50 % des récompenses globales, afin de s'assurer que le proposant n'a aucune motivation pour ne pas soumettre délibérément une preuve complète. Dans le même temps, Prover peut également soumettre une preuve directement au contrat.
Selon la description de la proposition, il est acceptable d'accepter un bloc sans preuve de validité des transactions terminées. C'est en fait déraisonnable : car : zkrollup ne déclare que le nouvel état correspondant à ce bloc est valide que lorsque la preuve de validité est donnée.
Si la preuve agrégée soumise par le proposant à L1 manque la preuve d'une certaine transaction, il est évident que les preuves de transition d'état de toutes les transactions qui se produisent après cette transaction sont invalides (car les transactions sont exécutées séquentiellement et ont des dépendances d'état), nous Il est également impossible de confirmer que le nouvel état correspondant à ce bloc est valide.
Par conséquent, à ce stade, la manière raisonnable devrait être d'entrer dans la fenêtre d'acceptation des blocs qui attend indéfiniment jusqu'à ce que toutes les preuves de transaction soient soumises.
Question 2 : **Si le bloc avec le score le plus élevé est un bloc illégal (ceci n'est pas expliqué dans le schéma B52). **BP ne contient que le hachage de la séquence de transaction, de sorte qu'un proposant malveillant peut en fait construire délibérément des transactions problématiques, telles que des transactions à double dépense. Donc, à ce moment, il est en fait nécessaire d'ajouter une fonction dans le contrat L1 pour que n'importe qui puisse soumettre une preuve illégale.Cette preuve illégale est utilisée pour prouver que le BP avec le score le plus élevé est un bloc illégal.
Et ce genre de rapport devrait être récompensé, on peut récompenser le jeton de gravure envoyé par le proposant au contrat au nœud rapporteur qui a soumis la preuve illégale.
** Réflexion intéressante : ** À propos des blocs d'oncle et du travail de preuve redondant : le schéma B52 utilisera en fait d'autres BP (qui ont soumis des preuves complètes) qui apparaissent dans ce tour en tant qu'oncles après l'apparition du BP avec le score le plus élevé à chaque tour. bloc, attribuer une certaine récompense de bloc oncle.
Cela suit en fait l'approche du mécanisme de consensus ETH POW.Afin d'éviter une concentration excessive de la puissance de calcul, il est nécessaire d'allouer une partie des récompenses de bloc aux proposants de bloc non acceptés (mineurs) pour protéger les intérêts des petits pools miniers/mineurs individuels et éviter La puissance de calcul est monopolisée par de grands pools de minage. Par conséquent, c'est aussi un choix très intelligent d'adopter le mécanisme de bloc oncle qu'Ethereum fonctionne bien.
L'importance de la proposition B52 en termes de décentralisation du Rollup : Le proposant est décentralisé et ne nécessite pas de promesse de don, et le seuil d'entrée est bas ; mais parce que vous devez construire vous-même les blocs les plus précieux et que vous devez collecter des votes d'autres Proposants et regrouper toutes les Preuves. En fait, le seuil matériel du Proposant n'est pas aussi bas que celui indiqué dans la proposition (par exemple, la bande passante peut ne pas être très faible).
Par conséquent, il finira par devenir un réseau relativement centralisé, similaire à Mev-Boost Builder, car le proposant qui peut enfin générer des blocs est souvent le Block Builder qui est le meilleur pour capturer MEV.
Dans le même temps, le prouveur du schéma B52 doit mettre en gage des actifs, mais comme seule la preuve de sous-arbre doit être générée, par rapport aux schémas qui doivent générer complètement la preuve de bloc entière, ** le degré de décentralisation du prouveur sera mieux (les exigences matérielles peuvent être réduites). **
Active Liveness : La vivacité globale du réseau est bonne, car L2 a son propre réseau p2p pour diffuser les transactions et les votes/BP, et Sequencer et Prover sont relativement décentralisés. Mais nous devons résoudre les deux problèmes que nous avons mentionnés ci-dessus. Le premier est que le bloc avec le score le plus élevé doit être un bloc légal, et le second est qu'il doit attendre que la preuve complète du bloc soit soumise à L1 avant d'entrer dans un nouveau bloc. État. Par conséquent, un mécanisme d'incitation plus efficace est nécessaire pour empêcher tout dysfonctionnement du réseau Rollup (temps d'arrêt) en raison de l'absence d'une certaine partie de la preuve tx.
**Résistance à la censure : **Si nous pouvons garantir que n'importe qui peut publier la proposition de bloc BP, et s'assurer que non seulement le proposant peut soumettre une preuve de bloc, alors le réseau aura une bonne résistance à la censure.
**Finalité : **La finalité de L2 est étroitement liée à la vivacité du réseau, car la finalité vérifiée finale doit encore attendre la soumission de Block Proof, mais en fait, vous pouvez également faire confiance au contenu du bloc correspondant à un BP avec le score le plus élevé (tant qu'il ne contient pas de transactions malveillantes).
Ce bloc sera révélé au début de la fenêtre d'acceptation de bloc, ce qui signifie qu'en tant qu'utilisateur, vous n'avez qu'à attendre une fenêtre de proposition de bloc et le bloc où la transaction que vous avez soumise peut être acceptée.
Hériter de la sécurité L1 : En tant que L2 qui met à jour son statut en soumettant une preuve de validité, il peut hériter de la sécurité de L1.
Proposition Fernet : Introduire VDF pour sélectionner Proposeur légal
Introduction au schéma de Fernet : via VDF, à chaque tour du cycle de génération de blocs, un score estimé est défini pour différents nœuds du comité (c'est-à-dire l'ensemble des nœuds du séquenceur), et le bloc proposé par le séquenceur avec le le score final le plus élevé deviendra pièce valide.
**Premièrement, comment rejoindre le Comité ? En fait, vous devez engager 16 ETH en L1, ** et attendre 4 blocs L1 une fois l'opération d'engagement terminée, puis rejoindre le comité du séquenceur. En ce qui concerne la sortie du comité du séquenceur, vous devez appeler la fonction Unstake dans le contrat L1, puis vous pourrez récupérer le montant restant de votre engagement après 3 jours supplémentaires.
Alors, qu'est-ce qu'un VDF ? La fonction de retard vérifiable est une fonction de retard vérifiable. Cette fonction mathématique satisfait des caractéristiques d'exécution en série strictes. Elle effectuera certaines étapes de calcul et consommera au moins une période de temps prévisible. Nous enregistrons la valeur calculée par VDF en tant que score, qui satisfait une distribution normale uniforme. Par conséquent, après que Sequencer a calculé le score VDF, il peut juger de la probabilité d'être sélectionné comme proposant légal. **
Au début de cette étape, chaque séquenceur utilisera VDF pour calculer son score VDF correspondant à la hauteur de bloc actuelle. ** Si le séquenceur pense que son score VDF est susceptible de gagner le droit de produire un bloc cette fois (en supposant que le score satisfait une distribution normale) **, il soumettra alors un contrat cumulatif de la proposition à L1. La proposition contient : le hachage de la séquence de transaction, pointant vers quel bloc L2 précédent.
bloc non prouvé : seul le contenu du bloc de la proposition au contrat Rollup est soumis. Ensuite, ** Sequencer doit envoyer le contenu du bloc correspondant au bloc non prouvé et la preuve de VDF au réseau L2 p2p. **
Le prouveur reçoit toutes les transactions correspondantes dans le contenu des blocs du réseau p2p L2 et créera une preuve pour les blocs avec un score VDF plus élevé. La construction de Proof adopte également la méthode de plusieurs Provers collaborant en parallèle (similaire au schéma B52).
Par conséquent, Sequencer doit agréger les preuves correspondant à plusieurs transactions différentes dans une preuve de bloc (y compris la preuve VDF) à la fin, et la soumettre au contrat Rollup de L1. Tout le monde peut soumettre des contenus de bloc qui ont soumis une preuve de bloc au contrat Rollup.
Finalisation : Il est nécessaire de soumettre une transaction L1 pour finaliser le bloc. Un bloc qui peut être finalisé doit être satisfait : le contenu du bloc et la preuve du bloc sont soumis, et le bloc précédent pointé doit être finalisé. Sur la base du respect des conditions ci-dessus, vous devez également avoir le score le plus élevé.
Mécanisme de production de bloc pipeline : Il est à noter que Fernet adopte un mécanisme de production de bloc pipeline.Lorsque la phase de Proposition du bloc N se termine, la phase de Proposition du bloc N+1 commence (Aptos et d'autres chaînes publiques ont également des pratiques similaires) . Mais pour le bloc N + 1, il doit attendre que le bloc N soit finalisé avant de pouvoir soumettre la transaction de bloc final L1 et réussir la vérification pour devenir un bloc final.
Dimensions potentielles de l'attaque : Si le séquenceur avec le score VDF le plus élevé ne diffuse délibérément pas le contenu du bloc en L2 p2p, cela peut entraîner une réorganisation du bloc.
Calcul du nombre de blocs L2 dans reorg : 1+PROVING_PHASE_L1_BLOCKS / PROPOSAL_PHASE_L1_BLOCKS =1+50/2=26 blocs
Solution : Augmenter le mécanisme de bloc oncle pour éviter d'avoir un seul bloc candidat complet pour chaque créneau L2 (créneau temporel de génération de bloc).
L'importance de Fernet en termes de décentralisation : Sequencer rejoint le Sequencer Committee en engageant 16 ETH, et le seuil d'entrée n'est pas élevé (mais pas bas). Le prouveur n'exige aucun gage, mais il n'y a pas de pénalité si le prouveur ne génère pas de preuve. C'est fondamentalement l'opposé du schéma B52.
**Activité active : **La vivacité de l'ensemble du réseau peut être garantie, car le mécanisme de bloc VDF+oncle peut garantir qu'il y a plus d'un producteur de blocs à chaque tour.
**MEV : **Les considérations MEV sont les plus spéciales. Le plan prévoit d'introduire le PBS, de sorte qu'après avoir calculé un score VDF élevé en tant que séquenceur, vous puissiez directement trouver un constructeur de blocs pour construire un bloc plus précieux.
**Résistance à la censure : **Fernet adoptera également le même mécanisme PBS qu'Ethereum. Par conséquent, le problème anti-censure de Fernet est équivalent à celui du PBS d'Ethereum.
Voir l'original
Le contenu est fourni à titre de référence uniquement, il ne s'agit pas d'une sollicitation ou d'une offre. Aucun conseil en investissement, fiscalité ou juridique n'est fourni. Consultez l'Avertissement pour plus de détails sur les risques.
Comment ZK-Rollup réalise-t-il la décentralisation des nœuds du séquenceur ?
Auteur : 0xhhh, EthStorage ; Compilateur : Faust, "Geek web3"
Introduction : Depuis que Rollup est devenu populaire, la décentralisation de Sequencer a toujours été au centre de la communauté Ethereum/Celestia, et c'est aussi une montagne insurmontable dans la recherche et le développement de Layer2. À cet égard, différents schémas Rollup ont proposé des idées sur la décentralisation des nœuds, offrant un espace d'imagination extrêmement large pour ce sujet.
L'auteur de cet article prend comme exemple le 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 de départ pour analyser comment ZKR réalise la décentralisation des nœuds de séquenceur pour les lecteurs.
Proposition B52 : schéma de séquenceur sans autorisation
La proposition B52 vise à atteindre les objectifs suivants (idéalement) :
Réseau de séquenceur décentralisé, les nœuds L2 eux-mêmes élisent chaque tour de proposants
Réseau de preuves décentralisé, faible configuration matérielle requise pour les nœuds de preuves
Rollup a une bonne résistance à la censure dans son ensemble.
La valeur MEV générée par L2 est acquise par les nœuds L2
Lorsque le bloc L2 est soumis à la couche DA, une finalité plus efficace peut être obtenue, et la finalité irréversible doit attendre que le ValidityProof (preuve de validité) soit soumis
L2 Token peut avoir un bon modèle économique
Les blocs L2 et les données de transaction sont propagés dans le réseau p2p L2
L2 hérite de la sécurité de L1
Ce schéma divise l'ensemble du processus de production du bloc L2 en trois étapes :
Parmi eux, l'étape BPW (proposition de bloc) est un processus dans lequel plusieurs séquenceurs Seuqnecer proposent différents blocs et s'affrontent, et Prover sélectionne un bloc candidat pour donner un vote.
BAW (Block Acceptance) est le processus dans lequel le prouveur construit une preuve de validité pour un bloc et la soumet.
Fenêtre de proposition de bloc (étape de proposition de bloc) :
BPW peut être subdivisé en trois étapes : Proposition de bloc, Vote de bloc, Agrégation.
N'importe qui dans la phase de proposition de bloc (BP) peut collecter des transactions et diffuser son propre contenu BP. Le contenu BP contiendra trois parties : le hachage de la commande txs, le pourcentage de récompense du prouveur, le montant du jeton de gravure
txs order hash : Le proposant sélectionne et trie le lot de transactions le plus précieux du pool de transactions L2 (mempool), puis place la valeur de hachage de ce lot de transactions dans le bloc qu'il construit.
pourcentage de récompense du prouveur : le pourcentage de récompense du bloc partagé par le séquenceur au prouveur
burn token amount : Le nombre de jetons natifs L2 proposés par le proposant à détruire, puis il envoie le BP proposé au réseau p2p L2
Étape du vote en bloc :
Après avoir reçu le BP proposé par différents proposants du réseau p2p, le prouveur votera pour le BP qui lui rapportera le plus de récompenses. Cependant, la composition du vote est très particulière :
Vote={BlockHash, Index of Proof Tree}
BlockHash est le hachage de la proposition sur laquelle le prouveur votera, et l'index de l'arbre de preuve est la valeur de l'index de feuille de l'arbre de preuve que le prouveur participera à la construction (expliqué plus tard)
** Agrégation d'agrégation : ** Le proposant collecte les votes des Provers pour BP dans le réseau p2p L2, les agrège et les place dans BP, et les soumet à L1 (chaque BP ne contient généralement que des enregistrements de vote liés à lui-même).
** Ici, il est nécessaire de souligner les conditions préalables pour que BP soit sélectionné et inclus dans le registre Rollp : **
Avoir le score le plus élevé :
SCORE(y) = NUM_PROVERS (x)^3 * BURN_BID(z)^2
NUM_PROVERS (x) est le nombre de votes Prover obtenus par le BP, et BURN_BID est le nombre de Tokens L2 proposés à la destruction par le BP. Étant donné que plus le BURN_BID est élevé, moins le proposant BP obtiendra de récompense à la fin, donc cette valeur doit être définie correctement.
Dans le même temps, le BP doit être soumis à L1 avant la fin de la fenêtre de proposition de bloc, et la preuve de validité correspondante doit être téléchargée à L1 avant la fin de la fenêtre d'acceptation de bloc.
Remarque : dans le calcul des scores BP, le nombre de votes représente la plus grande proportion, suivi du nombre de jetons brûlés. Dans le même temps, le schéma B52 permet à plusieurs proposants (en fait des séquenceurs) de concourir pour un quota BP effectif
Le schéma B52 exige uniquement que le proposant (séquenceur) spécifie le nombre de jetons de gravure dans son propre BP (similaire à la méthode de EIP1559) sans jetons de mise à l'avance, ce qui peut rendre le réseau plus sans autorisation (pas d'autorisation d'accès), et est également bénéfique pour L2 Native Token produit une déflation.
De plus, BP ne contient pas de données de transaction complètes, mais uniquement le hachage de la séquence de transaction.La raison est similaire au schéma Ethereum PBS, qui vise à empêcher que MEV ne soit espionné par d'autres proposants.
Explication détaillée de la fenêtre d'acceptation des blocs (étape d'acceptation des blocs) :
Une fois la fenêtre de proposition de bloc terminée, le prouveur doit révéler les données de transaction complètes correspondant à son BP. Si le BP voté par le prouveur est sélectionné (le score le plus élevé peut être interrogé via le contrat L1), il doit construire le sous-arbre de preuve correspondant à l'index de l'arbre de preuve donné lors du vote.
En supposant que le bloc d'Aztec contient 2 ^ 13 = 16384 transactions et qu'il y a 2048 prouveurs, alors chaque prouveur construit un sous-arbre de preuve composé de 2 ^ 3 = 8 transactions. Ensuite, le prouveur diffuse l'arbre de sous-preuve construit par lui-même à In the L2 p2p réseau. Une fois que le proposant l'a reçu, il regroupera tous les sous-arbres de preuve dans une preuve de bloc.
Ensuite, Propsoer soumet la preuve agrégée au contrat L1 Rollup, et le contrat vérifiera l'exactitude de la preuve et les résultats de transition d'état correspondants. Il convient de noter ici que si le Prover omet délibérément de soumettre la preuve, non seulement il ne pourra pas obtenir le dividende de récompense global promis par le Proposer, mais il sera également amputé, car pour devenir un Prover, il doit gage de jeton à l'avance. Par conséquent, contrairement à Proposer (Sequencer), Prover n'est pas Permissionless.
Explication détaillée des avances d'état (étape d'avancement d'état) :
Après la fin de la fenêtre d'acceptation de bloc, le contrat de cumul sélectionnera un bloc avec le score le plus élevé à inclure dans le grand livre de cumul, et enverra la récompense de récompense de bloc au proposant et au prouveur respectivement selon la proportion déclarée par le proposant (séquenceur) dans avance.
**Ce qui précède est la solution B52 d'Aztec. Cependant, l'auteur de cet article pense qu'il y a des problèmes potentiels avec la proposition B52 : **
Question 1 : Si la preuve de validité d'un bloc avec le score le plus élevé est incomplète. La solution proposée dans la proposition est que si le proposant ne fournit que 50 % de la preuve, il ne peut obtenir que 50 % des récompenses globales, afin de s'assurer que le proposant n'a aucune motivation pour ne pas soumettre délibérément une preuve complète. Dans le même temps, Prover peut également soumettre une preuve directement au contrat.
Selon la description de la proposition, il est acceptable d'accepter un bloc sans preuve de validité des transactions terminées. C'est en fait déraisonnable : car : zkrollup ne déclare que le nouvel état correspondant à ce bloc est valide que lorsque la preuve de validité est donnée.
Si la preuve agrégée soumise par le proposant à L1 manque la preuve d'une certaine transaction, il est évident que les preuves de transition d'état de toutes les transactions qui se produisent après cette transaction sont invalides (car les transactions sont exécutées séquentiellement et ont des dépendances d'état), nous Il est également impossible de confirmer que le nouvel état correspondant à ce bloc est valide.
Par conséquent, à ce stade, la manière raisonnable devrait être d'entrer dans la fenêtre d'acceptation des blocs qui attend indéfiniment jusqu'à ce que toutes les preuves de transaction soient soumises.
Question 2 : **Si le bloc avec le score le plus élevé est un bloc illégal (ceci n'est pas expliqué dans le schéma B52). **BP ne contient que le hachage de la séquence de transaction, de sorte qu'un proposant malveillant peut en fait construire délibérément des transactions problématiques, telles que des transactions à double dépense. Donc, à ce moment, il est en fait nécessaire d'ajouter une fonction dans le contrat L1 pour que n'importe qui puisse soumettre une preuve illégale.Cette preuve illégale est utilisée pour prouver que le BP avec le score le plus élevé est un bloc illégal.
Et ce genre de rapport devrait être récompensé, on peut récompenser le jeton de gravure envoyé par le proposant au contrat au nœud rapporteur qui a soumis la preuve illégale.
** Réflexion intéressante : ** À propos des blocs d'oncle et du travail de preuve redondant : le schéma B52 utilisera en fait d'autres BP (qui ont soumis des preuves complètes) qui apparaissent dans ce tour en tant qu'oncles après l'apparition du BP avec le score le plus élevé à chaque tour. bloc, attribuer une certaine récompense de bloc oncle.
Cela suit en fait l'approche du mécanisme de consensus ETH POW.Afin d'éviter une concentration excessive de la puissance de calcul, il est nécessaire d'allouer une partie des récompenses de bloc aux proposants de bloc non acceptés (mineurs) pour protéger les intérêts des petits pools miniers/mineurs individuels et éviter La puissance de calcul est monopolisée par de grands pools de minage. Par conséquent, c'est aussi un choix très intelligent d'adopter le mécanisme de bloc oncle qu'Ethereum fonctionne bien.
L'importance de la proposition B52 en termes de décentralisation du Rollup : Le proposant est décentralisé et ne nécessite pas de promesse de don, et le seuil d'entrée est bas ; mais parce que vous devez construire vous-même les blocs les plus précieux et que vous devez collecter des votes d'autres Proposants et regrouper toutes les Preuves. En fait, le seuil matériel du Proposant n'est pas aussi bas que celui indiqué dans la proposition (par exemple, la bande passante peut ne pas être très faible).
Par conséquent, il finira par devenir un réseau relativement centralisé, similaire à Mev-Boost Builder, car le proposant qui peut enfin générer des blocs est souvent le Block Builder qui est le meilleur pour capturer MEV.
Dans le même temps, le prouveur du schéma B52 doit mettre en gage des actifs, mais comme seule la preuve de sous-arbre doit être générée, par rapport aux schémas qui doivent générer complètement la preuve de bloc entière, ** le degré de décentralisation du prouveur sera mieux (les exigences matérielles peuvent être réduites). **
Active Liveness : La vivacité globale du réseau est bonne, car L2 a son propre réseau p2p pour diffuser les transactions et les votes/BP, et Sequencer et Prover sont relativement décentralisés. Mais nous devons résoudre les deux problèmes que nous avons mentionnés ci-dessus. Le premier est que le bloc avec le score le plus élevé doit être un bloc légal, et le second est qu'il doit attendre que la preuve complète du bloc soit soumise à L1 avant d'entrer dans un nouveau bloc. État. Par conséquent, un mécanisme d'incitation plus efficace est nécessaire pour empêcher tout dysfonctionnement du réseau Rollup (temps d'arrêt) en raison de l'absence d'une certaine partie de la preuve tx.
**Résistance à la censure : **Si nous pouvons garantir que n'importe qui peut publier la proposition de bloc BP, et s'assurer que non seulement le proposant peut soumettre une preuve de bloc, alors le réseau aura une bonne résistance à la censure.
**Finalité : **La finalité de L2 est étroitement liée à la vivacité du réseau, car la finalité vérifiée finale doit encore attendre la soumission de Block Proof, mais en fait, vous pouvez également faire confiance au contenu du bloc correspondant à un BP avec le score le plus élevé (tant qu'il ne contient pas de transactions malveillantes).
Ce bloc sera révélé au début de la fenêtre d'acceptation de bloc, ce qui signifie qu'en tant qu'utilisateur, vous n'avez qu'à attendre une fenêtre de proposition de bloc et le bloc où la transaction que vous avez soumise peut être acceptée.
Hériter de la sécurité L1 : En tant que L2 qui met à jour son statut en soumettant une preuve de validité, il peut hériter de la sécurité de L1.
Proposition Fernet : Introduire VDF pour sélectionner Proposeur légal
Introduction au schéma de Fernet : via VDF, à chaque tour du cycle de génération de blocs, un score estimé est défini pour différents nœuds du comité (c'est-à-dire l'ensemble des nœuds du séquenceur), et le bloc proposé par le séquenceur avec le le score final le plus élevé deviendra pièce valide.
**Premièrement, comment rejoindre le Comité ? En fait, vous devez engager 16 ETH en L1, ** et attendre 4 blocs L1 une fois l'opération d'engagement terminée, puis rejoindre le comité du séquenceur. En ce qui concerne la sortie du comité du séquenceur, vous devez appeler la fonction Unstake dans le contrat L1, puis vous pourrez récupérer le montant restant de votre engagement après 3 jours supplémentaires.
Alors, qu'est-ce qu'un VDF ? La fonction de retard vérifiable est une fonction de retard vérifiable. Cette fonction mathématique satisfait des caractéristiques d'exécution en série strictes. Elle effectuera certaines étapes de calcul et consommera au moins une période de temps prévisible. Nous enregistrons la valeur calculée par VDF en tant que score, qui satisfait une distribution normale uniforme. Par conséquent, après que Sequencer a calculé le score VDF, il peut juger de la probabilité d'être sélectionné comme proposant légal. **
Le VDF du séquenceur est calculé comme suit :
Score = VDF( clé privée , entrées publiques )
entrées publiques = { numéro de bloc actuel , randao }
randao est un nombre aléatoire utilisé pour empêcher Sequencer de calculer à l'avance son propre score VDF à toutes les hauteurs de bloc futures
L'ensemble du processus de Fernet est principalement divisé en 3 étapes :
**Phase de proposition :**PROPOSITION_PHASE_L1_BLOCKS = 2 blocs Ethereum (cette phase durera 2 blocs L1)
Au début de cette étape, chaque séquenceur utilisera VDF pour calculer son score VDF correspondant à la hauteur de bloc actuelle. ** Si le séquenceur pense que son score VDF est susceptible de gagner le droit de produire un bloc cette fois (en supposant que le score satisfait une distribution normale) **, il soumettra alors un contrat cumulatif de la proposition à L1. La proposition contient : le hachage de la séquence de transaction, pointant vers quel bloc L2 précédent.
bloc non prouvé : seul le contenu du bloc de la proposition au contrat Rollup est soumis. Ensuite, ** Sequencer doit envoyer le contenu du bloc correspondant au bloc non prouvé et la preuve de VDF au réseau L2 p2p. **
ProvingPhase : PROVING_PHASE_L1_BLOCKS= 50 blocs L1 (cette phase maintiendra 50 blocs L1, environ 10 min)
Le prouveur reçoit toutes les transactions correspondantes dans le contenu des blocs du réseau p2p L2 et créera une preuve pour les blocs avec un score VDF plus élevé. La construction de Proof adopte également la méthode de plusieurs Provers collaborant en parallèle (similaire au schéma B52).
Par conséquent, Sequencer doit agréger les preuves correspondant à plusieurs transactions différentes dans une preuve de bloc (y compris la preuve VDF) à la fin, et la soumettre au contrat Rollup de L1. Tout le monde peut soumettre des contenus de bloc qui ont soumis une preuve de bloc au contrat Rollup.
Finalisation : Il est nécessaire de soumettre une transaction L1 pour finaliser le bloc. Un bloc qui peut être finalisé doit être satisfait : le contenu du bloc et la preuve du bloc sont soumis, et le bloc précédent pointé doit être finalisé. Sur la base du respect des conditions ci-dessus, vous devez également avoir le score le plus élevé.
Mécanisme de production de bloc pipeline : Il est à noter que Fernet adopte un mécanisme de production de bloc pipeline.Lorsque la phase de Proposition du bloc N se termine, la phase de Proposition du bloc N+1 commence (Aptos et d'autres chaînes publiques ont également des pratiques similaires) . Mais pour le bloc N + 1, il doit attendre que le bloc N soit finalisé avant de pouvoir soumettre la transaction de bloc final L1 et réussir la vérification pour devenir un bloc final.
Dimensions potentielles de l'attaque : Si le séquenceur avec le score VDF le plus élevé ne diffuse délibérément pas le contenu du bloc en L2 p2p, cela peut entraîner une réorganisation du bloc.
Calcul du nombre de blocs L2 dans reorg : 1+PROVING_PHASE_L1_BLOCKS / PROPOSAL_PHASE_L1_BLOCKS =1+50/2=26 blocs
Solution : Augmenter le mécanisme de bloc oncle pour éviter d'avoir un seul bloc candidat complet pour chaque créneau L2 (créneau temporel de génération de bloc).
L'importance de Fernet en termes de décentralisation : Sequencer rejoint le Sequencer Committee en engageant 16 ETH, et le seuil d'entrée n'est pas élevé (mais pas bas). Le prouveur n'exige aucun gage, mais il n'y a pas de pénalité si le prouveur ne génère pas de preuve. C'est fondamentalement l'opposé du schéma B52.
**Activité active : **La vivacité de l'ensemble du réseau peut être garantie, car le mécanisme de bloc VDF+oncle peut garantir qu'il y a plus d'un producteur de blocs à chaque tour.
**MEV : **Les considérations MEV sont les plus spéciales. Le plan prévoit d'introduire le PBS, de sorte qu'après avoir calculé un score VDF élevé en tant que séquenceur, vous puissiez directement trouver un constructeur de blocs pour construire un bloc plus précieux.
**Résistance à la censure : **Fernet adoptera également le même mécanisme PBS qu'Ethereum. Par conséquent, le problème anti-censure de Fernet est équivalent à celui du PBS d'Ethereum.