Chercheur Celestia : Interprétation de 4 nouveaux schémas cumulatifs

Auteur : NashQ, Celestia ; Compilateur : Lien, "Geek web3"

Introduction : Cet article est composé des discours épars du chercheur de Celestia NashQ sur l'analyse du modèle Rollup, dont 4 nouvelles variantes Rollup. Auparavant, dans l'article "Analyse du cumul du point de vue de Celestia : résistance à la censure et activité de 6 variations", il a répertorié 6 modèles de cumul différents, et cet article contient ses 4 catégories nouvellement extraites basées sur ce modèle de cumul.

Auparavant, NashQ divisait le Séquenceur en deux modules : agrégateur + Header Producer.Partant du cycle de vie des instructions de transaction, il expliquait le principe de fonctionnement du Rollup souverain de Celestia, discutait de l'anti-censure et de l'activité des différentes variantes de Rollup, et de l'expérience utilisateur. La configuration minimale sous le principe de minimiser la confiance (c'est-à-dire, pour atteindre Trustless, quels types de nœuds les utilisateurs de Rollup doivent exécuter au moins).

#### Variante 7 : Rollup basé sur plusieurs producteurs d'en-têtes + "Mev de protocole le plus élevé"

Dans cette variante Rollup, les utilisateurs du réseau Rollup publient directement les données de transaction dans les blocs de couche DA, puis le producteur d'en-tête est responsable du tri des transactions, et MEV en est extrait. De toute évidence, le processus d'agrégation/d'inclusion des transactions de Rollup Variant 7 est le même que le Based Rollup précédemment introduit, qui relève de la responsabilité de la couche DA (les utilisateurs envoient directement les transactions à la couche DA), mais l'ordre des transactions est différent du Based Rollup, et les nœuds de la couche DA ne sont pas responsables Le tri est de la responsabilité de HP (Header Producer).

Ce qui suit suppose qu'il y a trois HP qui se font concurrence et respectent le protocole d'attribution MEV nommé "protocole MEV le plus élevé". Ce protocole a été proposé par le Skip Protocol de l'écosystème Cosmos. Contrairement au schéma Ethereum PBS, le Block Builder doit payer un "pourboire" supplémentaire au Validateur du réseau blockchain, et le bloc construit par le Builder avec le plus de pourboires sera être adopté par les Validateurs. . Dans le même temps, SKIP Protocol a proposé le concept de "MEV souverain", dans le but de permettre à tous les validateurs et communautés du réseau de la chaîne publique d'avoir l'autonomie d'allouer des MEV, et de résoudre le problème que les constructeurs d'Ethereum PBS deviennent de plus en plus nombreux. plus centralisé en raison de l'effet volant (mais ce n'est pas le cœur de cet article).

Dans la variante Rollup présentée dans cet article, différents producteurs d'en-tête doivent déclarer le montant du pourboire dans l'en-tête de lot créé par eux-mêmes, et l'en-tête de lot émis par le HP qui paie le plus de pourboires est automatiquement accepté par les nœuds Rollup (via le grand livre écrit dans le code du nœud L'algorithme de sélection des fourches se fait automatiquement).

De plus, l'en-tête de lot publié par HP doit pouvoir correspondre au lot de transaction complet sur la couche DA.

S'il y a une erreur dans l'en-tête émis par HP, par exemple, si le résultat d'exécution de la transaction Stateroot est incorrect, ou si une transaction du lot n'est pas incluse (transaction perdue), le nœud complet Rollup honnête diffusera la preuve de fraude au nœud léger. . Mais généralement (de manière optimiste), les nœuds légers peuvent accepter l'en-tête émis par HP et croire qu'il n'y a aucun problème avec cela.

Analyse de la résistance à la censure : Il y a 2 points dans ce Rollup qui peuvent mener à l'examen des transactions. Le premier existe au niveau de la couche DA, qui peut censurer le contenu des transactions et rejeter les transactions impliquant certains utilisateurs. La deuxième place existe toujours dans la couche DA, qui 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 MEV par le biais d'attaques de révision.

Dans le même temps, HP est responsable de la commande des transactions. En raison de l'existence de preuves de fraude (il peut être ciblé sur la situation où HP perd des transactions), HP lui-même ne lance souvent pas d'attaques de censure, mais il peut corrompre les nœuds de la couche DA pour le faire (ou exécuter certaines couches DA par lui-même) nœud). La solution consiste à prolonger la période de fenêtre pour la finalisation de la séquence de transaction Rollup, de sorte que l'en-tête rejeté par les nœuds de couche DA malveillants puisse être inclus dans la chaîne par des nœuds de couche DA honnêtes avant la fin de la période de fenêtre, augmentant ainsi l'examen du nœud de la couche DA La difficulté de l'attaque.

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

Si la couche DA a un échec de vivacité, le cumul aura également un échec de vivacité. Sur cette base, Rollup n'échouera à la vivacité que lorsque tous les HP échoueront à la vivacité.

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

La variante 8 utilise l'agrégateur partagé Shared Aggregator (SA) pour l'inclusion et le tri des transactions. SA publie la séquence de transactions Batch sur la couche DA. Une fois la séquence de transactions envoyée à la couche DA, l'ordre des transactions ne changera pas théoriquement.

Avant que le lot ne soit envoyé à la couche DA, l'agrégateur partagé SA peut d'abord diffuser l'en-tête Batch+ SA au nœud complet et au prouveur, et diffuser l'en-tête SA au nœud léger, mais le lot qui n'est pas sur la couche DA est encore instable à ce moment et peut être bloqué à tout moment.

Il convient de noter que l'en-tête émis par l'agrégateur partagé SA n'est pas le même que l'en-tête de lot émis par HP. L'en-tête SA contient des preuves cryptographiques pour garantir que le lot lu par le nœud Rollup à partir de la couche DA est bien généré par SA, et non falsifié par d'autres.

Le prouveur lit le lot de transactions Batch à partir de la couche DA (il peut également être directement synchronisé avec l'agrégateur partagé), génère un en-tête ZK Proof+Batch et le publie sur la couche DA. Évidemment Prover a joué le rôle de HP.

Pour les nœuds légers de Rollup, après réception de ZKProof, la séquence de transaction contenue dans ce lot est finalement confirmée. Bien sûr, Prover peut également diffuser ZKP via le réseau Rollup p2p sous la chaîne de couches DA, afin qu'il puisse être reçu plus rapidement par les nœuds légers, mais pour le moment, ZKP n'a pas été envoyé à la couche DA, et il n'a pas " finalité".

• **Résistance à la censure : **Dans la variante 8, la couche DA ne peut pas mener d'attaques de censure sur certaines transactions spécifiques, mais peut uniquement mener des attaques de révision sur l'ensemble du lot de transactions soumises par l'agrégateur partagé. Dans le même temps, les agrégateurs partagés peuvent refuser de regrouper les transactions de certains utilisateurs.
• **Activité : **L = L_da && L_sa && L_pm. Dans cette variante, si une partie a un échec de vivacité, le cumul aura un échec de vivacité. Si le prouveur échoue, les nœuds légers ne pourront pas synchroniser efficacement la progression du registre Rollup. Cependant, étant donné que le nœud complet synchronise tous les lots de séquences de transactions, il peut suivre la progression du grand livre. À ce stade, tous les nœuds ne seront pas affectés et tous les nœuds légers échoueront, ce qui équivaut à la situation de Based Rollup utilisant un agrégateur partagé présentée précédemment.
• **Configuration minimale pour la minimisation de la confiance : **nœud léger de couche DA + nœud léger de réseau d'agrégateur partagé + nœud léger de cumul

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

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

Selon les besoins de la partie du projet Rollup, le Rollup le moins cher, le plus sûr, le plus actif et la vitesse de règlement peuvent être personnalisés, et la couche DA avec le débit le plus élevé peut être sélectionnée. De manière générale, les lots d'une certaine hauteur de bloc cumulatif (comme le 10 000e) n'ont pas besoin d'exister sur différentes couches DA en même temps, mais s'ils existent, leur contenu doit être cohérent. Si deux lots avec la même hauteur et un contenu différent apparaissent sur différentes couches DA, cela signifie que l'agrégateur partagé bifurque intentionnellement le grand livre.

Ici, nous choisissons le même marché de preuves décentralisé que la variante 8, où Prover agit en tant que producteur d'en-tête et publie Batch Header et ZKProof. À ce stade, le prouveur doit concourir via le mécanisme d'enchères pourboires mentionné dans la variante 7 (proposée 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 avec la génération de blocs la plus rapide.

Résistance à la censure : Les agrégateurs partagés peuvent s'engager dans des attaques de censure, mais avec plus de couches DA facultatives, la possibilité d'attaques de censure liées aux couches DA est réduite.

**活性：**L = ( L_da1 || L_da2) && L_sa && L_pm。

La variante 9 était plus active que la variante précédente. Tant que tous les réseaux de couche DA ne connaissent pas de pannes en direct, tout fonctionnera correctement.

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

Évidemment, plus nous adoptons de couches DA, plus nous devons exécuter de nœuds légers. Mais les avantages de le faire peuvent l'emporter sur les coûts.

Variante 10 : Deux ZK-Rollups + Prover décentralisé, avec un nœud léger sur la chaîne (pontable) entre eux

La variante 10 est une extension de la variante 5 pour créer 2 ZK-Rollups qui peuvent se relier. Par rapport à la variante 5 (Based Rollup + ZKP + Decentralized Prover), la variante 10 a un rôle de relais supplémentaire, qui encapsule Batch Header + ZK-Proof dans une transaction. Tant que cette transaction est envoyée au nœud léger Rollup1 s'exécutant sur Rollup2, elle peut prouver qu'une certaine hauteur de Batch est valide. Bien sûr, Rollup2 nécessite également des nœuds légers exécutant la couche DA.

Il s'agit d'une condition préalable pour maintenir au minimum la confiance entre les ponts en chaîne. Mais s'il s'agit d'une chaîne croisée d'Ethereum Rollup (SC Rollup basé sur un contrat intelligent) à Ethereum, il n'est pas nécessaire d'exécuter le nœud léger de la couche DA de Rollup, car la couche DA est Ethereum elle-même. Ceci est très différent du Rollup souverain de Celestia, dont les Rollups s'étendent les uns sur les autres et doivent exécuter les nœuds légers de la couche DA de l'autre partie.

Lorsque Relayer envoie une transaction inter-chaînes, elle sera traitée par l'agrégateur 2 et HP2 de Rollup2. Nous ajoutons les deux au graphique pour comprendre comment les nœuds de Rollup2 traitent les transactions à travers les Rollups.

Le relais de Rollup2 obtiendra l'en-tête de lot et le ZKP de Rollup 2 et les renverra à Rollup1. Rollup 1 a également un nœud léger Rollup 2 et un nœud léger de couche DA.

Nous pouvons rendre le modèle plus simplifié. Supposons que deux cumuls utilisent le même agrégateur partagé et le même producteur d'en-tête, en d'autres termes, les couches DA qu'ils utilisent se chevauchent.

Dans ce cas, le Relayer peut être banni directement. É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 le ZKP d'un autre cumul peuvent être lues directement sur la couche DA et n'ont plus besoin d'être transmises à l'agrégateur partagé via le Relais.

De toute évidence, Rollup utilisant la même couche DA n'a pas besoin de dépendre de Relayer (de nombreux ponts inter-chaînes reposent sur des nœuds de relais). Cela peut résoudre le problème de sécurité des ponts inter-chaînes (de ce point de vue, le cross-span entre SC Rollups d'Ethereum est plus sécurisé que le cross-chain entre différentes chaînes publiques).

À l'heure actuelle, **configuration minimale de la minimisation de la confiance : **nœud léger de couche DA + nœud léger de cumul.