Introduction: Cet article est consolidé par les déclarations dispersées du chercheur de Celestia, NashQ, concernant l'analyse du modèle Rollup, y compris 4 nouvelles variantes de Rollup. Auparavant, dans l'article " Celestia Researcher analyse 6 variantes de cumul : Séquenceur = Agrégateur + Générateur d’en-tête“, il a répertorié 6 modèles Rollup différents, et cet article est une nouvelle abstraction de 4 types de modèles Rollup sur la base de cet article.

Précédemment, NashQ a divisé le séquenceur Sequencer en deux modules, Aggregator + Header Producer, et a décrit le cycle de vie des instructions transactionnelles pour expliquer le fonctionnement de Celestia Sovereign Rollup, explorant la résistance à la censure et l'activité des différentes variantes de Rollup, ainsi que la configuration minimale pour qu'un utilisateur soit trust-minimized (c'est-à-dire pour être sans confiance, quels sont les types minimum de nœuds qu'un utilisateur Rollup devrait exécuter).

Variante 7 : Rollup basé + Multiples producteurs d'en-tête + "MEV de protocole le plus élevé"

Dans cette variante Rollup, l'utilisateur du réseau Rollup poste les données de transaction directement dans le bloc de la couche DA, puis le producteur d'en-têtes est responsable de l'ordonnancement des transactions et le MEV en est extrait. De toute évidence, le processus d'agrégation/inclusion des transactions de la variante Rollup 7 est le même que celui du Rollup basé introduit précédemment, qui est géré par la couche DA (les utilisateurs postent directement leurs transactions à la couche DA), mais le tri des transactions est différent du Rollup basé en ce que les nœuds de la couche DA ne sont pas chargés du tri, qui est géré par le HP (Producteur d'En-têtes).

Supposons qu'il y ait trois HP qui sont en concurrence les uns avec les autres et suivent un protocole d'allocation de MEV appelé «Protocole MEV le plus élevé». Ce protocole est proposé par le protocole de saut de l'écosystème Cosmos, qui diffère du schéma Ether PBS en ce que les constructeurs de blocs versent un «pourboire» supplémentaire aux validateurs du réseau blockchain, et les blocs construits par les constructeurs les plus pourboisés sont adoptés par les validateurs. Les blocs construits par les constructeurs les plus pourboisés seront adoptés par les validateurs. En même temps, le protocole SKIP propose le concept de «MEV souverain», qui vise à permettre à tous les validateurs et à la communauté du réseau de chaînes publiques d'avoir l'autonomie de l'allocation de MEV, et à résoudre le problème de l'augmentation de la centralisation des constructeurs en raison de l'effet de volant dans Ethernet PBS (mais ce n'est pas le cœur de cet article).

Dans la variante Rollup présentée dans ce document, les différents producteurs d'en-têtes doivent déclarer le montant du pourboire dans l'en-tête de lot qu'ils créent, et l'en-tête de lot publié par le HP qui donne le plus de pourboires est automatiquement accepté par les nœuds de Rollup (automatiquement via un algorithme de sélection de fourche de registre écrit dans le code du nœud).

En plus de cela, l'en-tête de lot publié par HP doit pouvoir correspondre à un lot de transactions complet sur la couche DA.

S'il y a une erreur dans l'en-tête publiée par HP, comme par exemple, le résultat de l'exécution de la transaction Stateroot est incorrect, ou qu'elle ne contient pas une transaction particulière dans le lot (transaction perdue), le nœud complet Rollup honnête diffuse la preuve de fraude au nœud léger. Cependant, généralement (de manière optimiste), le nœud léger peut accepter l'en-tête publiée par HP et croire qu'il n'a aucun problème.

Analyse de la résistance à la censure : il existe 2 points dans ce Rollup où la censure des transactions est possible. Le premier existe au niveau de la couche DA, où il peut examiner le contenu de la transaction et rejeter l’inclusion des transactions de certains utilisateurs. La deuxième place est toujours dans la couche DA, il peut examiner l’en-tête soumis par HP et refuser d’inclure un certain en-tête, de sorte qu’il peut conspirer avec l’en-tête pour monopoliser le MEV par le biais d’une attaque de censure.

Dans le même temps, le séquençage des transactions est géré par HP, et en raison de l’existence de preuves de fraude (qui peuvent être utilisées dans le cas où HP abandonne des transactions), HP lui-même a tendance à ne pas lancer d’attaques de censure, mais il peut soudoyer les nœuds de la couche DA pour le faire (ou exécuter lui-même certains nœuds de la couche DA). La solution à ce problème consiste à prolonger la période de fenêtre au cours de laquelle la séquence de transaction de cumul est finalisée, de sorte que l’en-tête rejeté par le nœud de couche DA malveillant puisse être inclus dans la chaîne par le nœud de couche DA honnête à temps avant la fin de la période de fenêtre, ce qui augmente la difficulté de l’attaque de censure du nœud de couche DA.

Activité : L = L_da && ( L_hp1 || L_hp2 || L_hp3 )

Si la couche DA a une faute active, alors Rollup aura également une faute active. Sur cette base, Rollup n'aura une faute active que si tous les HP ont une faute active.

Variante 8: ZK Rollup avec agrégateur partagé + prouveur décentralisé

La variante 8 utilise l'Aggrégateur Partagé (SA) pour l'inclusion et l'ordonnancement des transactions, où le SA publie le lot de séquence de transactions sur la couche DA, et l'ordre des transactions ne change théoriquement pas après l'envoi de la séquence de transactions à la couche DA.

Et avant que le lot ne soit envoyé à la couche DA, la SA de l’agrégateur partagé peut d’abord diffuser l’en-tête Batch + SA au nœud complet et au prouveur, et l’en-tête SA au nœud léger, sauf qu’à ce moment-là, le lot qui n’est pas sur la couche DA est toujours instable et peut être remplacé à tout moment.

Il est important de noter que l'en-tête publié par le partage Aggregator SA n'est pas la même chose que l'en-tête de lot publié par HP. l'en-tête SA contient des preuves cryptographiques pour garantir que le lot que le nœud Rollup lit de la couche DA a effectivement été généré par le SA, et non pas forgé par celui-ci.

Le vérificateur lit le lot de transactions Batch de la couche DA (et se synchronise également directement avec l'agrégateur partagé), génère une preuve ZK+En-tête de lot, et la publie sur la couche DA. De toute évidence, le vérificateur agit en tant que HP.

Pour le nœud léger de Rollup, après avoir reçu ZKProof, la séquence des transactions contenues dans ce lot sera finalisée. Bien sûr, le prouveur peut également diffuser ZKP à travers le réseau Rollup p2p sous la chaîne de couche DA, de sorte qu'il puisse être reçu par les nœuds légers plus rapidement, mais à ce moment-là, ZKP n'a pas encore été envoyé à la couche DA et n'a pas de "finalité".

Résistance à la censure : dans la variante 8, la couche DA ne peut pas effectuer d'attaques de censure sur certaines transactions spécifiques au stylo, mais peut uniquement effectuer des attaques de censure en lot sur l'ensemble du lot de transactions soumises par l'agrégateur partagé. En même temps, l'agrégateur partagé peut refuser d'emballer les transactions de certains utilisateurs.

Actif : L = L_da && L_sa && L_pm. Si une partie de cette variante échoue activement, Rollup échouera activement. Si le vérificateur échoue, alors le nœud léger ne pourra pas synchroniser efficacement le progrès du grand livre Rollup. Mais puisque le nœud complet synchronise toute la séquence de transaction Batch, il peut suivre le progrès du livre. À ce moment-là, le nœud complet est unaffected et tous les nœuds légers échouent, ce qui équivaut au cas précédemment décrit de Based Rollup avec un agrégateur partagé.

Configuration minimale pour la minimisation de la confiance : nœuds légers de niveau DA + nœuds légers du réseau d'agrégation partagé + nœuds légers de Rollup

Variante 9: Agrégateur partagé + Prover décentralisé + ZK-Rollup avec plusieurs DAs

La variante 9 est en fait basée sur la variante 8 ci-dessus, sauf qu’elle a plus d’une couche DA, ce qui peut améliorer efficacement l’activité du Rollup. Dans la variante 9, l’agrégateur partagé SA peut publier la séquence de transaction Batch sur n’importe quelle couche DA, et il peut choisir différentes couches DA pour publier les données en fonction de ses propres besoins, afin qu’il puisse optimiser dynamiquement les paramètres pertinents du Rollup, tels que : le coût des données, la sécurité, l’activité, le délai de transaction et la finalité.

En fonction des besoins du projecteur à enroulement, le projecteur à enroulement le moins cher, le plus sûr, le plus actif et le plus rapide peut être personnalisé, et la couche DA avec le débit le plus élevé peut être sélectionnée. D’une manière générale, il n’est pas nécessaire qu’un lot d’une certaine hauteur de bloc Rollup (par exemple, 10 000e) existe sur différentes couches DA en même temps, mais si c’est le cas, leur contenu doit être le même. Si deux lots de même hauteur et de contenu différent sont présents sur des couches DA différentes, cela signifie que l’agrégateur partagé s’engage intentionnellement dans un fork de registre.

Ici, nous choisissons le même marché décentralisé du Prover que dans la variante 8, où le Prover agit en tant que producteur d'en-têtes et publie l'en-tête de lot et ZKProof. À ce stade, le Prover doit concourir à travers le mécanisme d'enchères de pourboires mentionné dans la variante 7 (proposé par le protocole SKIP).

La vitesse de règlement des transactions (vitesse de confirmation finale) de la variante 9 est affectée par la couche DA la plus rapide qu'elle utilise parmi les blocs.

Résistance à la censure : les agrégateurs partagés peuvent s’engager dans des attaques de censure, mais le nombre de couches DA facultatives augmente et la probabilité d’attaques de censure associées aux couches DA diminue.

Activité : L = (L_da1 || L_da2) && L_sa && L_pm.

La variante 9 est plus active par rapport aux variantes précédentes. Tant qu'il n'y a pas de défaillance d'activité dans tous les réseaux de la couche DA, tout est capable de se dérouler normalement.

Configuration minimale pour la minimisation de la confiance : nœuds légers dans différentes couches DA + nœuds légers du réseau d'agrégation partagé + nœuds légers Rollup.

De toute évidence, plus nous utilisons de couches DA, plus nous devons exécuter de nœuds légers. Mais les avantages de ceci peuvent l'emporter sur ses coûts.

Variante 10: Deux ZK-Rollups + Prover décentralisé avec un nœud léger on-chain pour communiquer entre eux (pontable)

La variante 10 est une extension de la variante 5 dans le but de créer 2 ZK-Rollups qui peuvent se relier l'un à l'autre. Par rapport à la variante 5 (Rollup basé + ZKP + Prover décentralisé), la variante 10 a le rôle supplémentaire d'un relais répéteur, qui enveloppe l'en-tête de lot + preuve ZK dans une seule transaction. Simplement en envoyant cette transaction au nœud léger Rollup1 où Rollup2 s'exécute prouve qu'un lot d'une certaine hauteur est valide. Bien sûr, Rollup2 doit également exécuter le nœud léger de la couche DA.

Ceci est une condition préalable pour maintenir la confiance minimisée dans le pont inter-chaînes. Cependant, si l'on passe d'un rouleau Ether (un rouleau SC basé sur un contrat intelligent) à Ether, il n'est plus nécessaire de faire fonctionner le nœud léger de la couche DA du rouleau, car la couche DA est Ether elle-même. Cela est extrêmement différent du rouleau souverain de Celestia, où les rouleaux doivent faire fonctionner les nœuds légers de la couche DA de l'autre pour se croiser.

Lorsque le Relayer envoie une transaction inter-chaînes, elle est traitée par l'agrégateur 2 de Rollup2 et HP2. Nous les ajoutons tous les deux au graphique pour comprendre comment les nœuds dans Rollup2 gèrent les transactions inter-Rollup.

Le relais répéteur de Rollup 2 recevra l'en-tête de lot et la preuve de connaissance nulle (ZKP) de Rollup 2 et les renverra à Rollup 1. Rollup 1 dispose également d'un nœud léger pour Rollup 2 et d'un nœud léger pour la couche DA.

Nous pouvons simplifier davantage le modèle. Supposons que deux Rollups utilisent le même Agrégateur Partagé et Producteur d'En-tête, en d'autres termes, ils emploient des couches DA superposées.

Dans ce cas, le Relayer peut être directement interdit. Étant donné que l'en-tête de lot et la preuve ZK ont été publiés par HP sur la même couche DA, les données telles que l'en-tête et la ZKP d'un autre Rollup peuvent être lues directement sur la couche DA, et n'ont plus besoin d'être transmises à l'agrégateur partagé via le Relayer.

De toute évidence, les Rollups qui utilisent la même couche DA n'ont pas besoin de compter sur des Relayers (de nombreux ponts inter-chaînes comptent sur des nœuds relais). Cela peut résoudre le problème de sécurité des ponts inter-chaînes (de ce point de vue, l'inter-étendue entre les Rollups SC sur Ethernet est plus sécurisée que l'inter-étendue entre différentes chaînes publiques).

À ce stade, la configuration minimale pour la minimisation de la confiance : un nœud léger de niveau DA + un nœud léger de Rollup.

Déclaration :

1. Cet article est une reproduite de [[Geek Web3](https://mp.weixin.qq.com/s/Wi4FPTCZli5g8UGVkYFnlw) ], les droits d'auteur appartiennent à l'auteur original[NashQ, Celestia], si vous avez des objections à la réimpression, veuillez contacterl’équipe Gate Learn, l'équipe sera traitée selon le processus pertinent dès que possible.
2. Avertissement : Les points de vue et opinions exprimés dans cet article représentent les points de vue personnels de l'auteur et ne constituent pas des conseils en investissement.
3. Les articles dans d'autres langues sont traduits par l'équipe Gate Learn et ne peuvent être reproduits, distribués ou copiés sans référence à Gate.io.