Sequences = agrégateur + producteur d'en-têtes

• Titre original transmis : Un chercheur de Celestia analyse 6 variantes du rollup : Sequencer=Aggregator+Header generator

Remarque : Afin de faciliter la compréhension et l'analyse du modèle Rollup, NashQ, chercheur chez Celestia, a divisé le séquenceur Rollup en deux entités logiques : l'agrégateur et le producteur d'en-têtes. Dans le même temps, il a divisé le processus de commande des transactions en trois étapes logiques : inclusion, classement et exécution.

Guidées par cette approche analytique, les six principales variantes de Sovereign Rollup sont plus claires et plus faciles à comprendre. NashQ a discuté en détail de la résistance à la censure et de la vivacité des différentes variantes du Rollup, ainsi que de la configuration minimale de chaque nœud de variante Rollup dans un état de minimisation de confiance (c'est-à-dire, pour atteindre un état sans confiance, au moins quels types de nœuds les utilisateurs du Rollup doivent exécuter).

Bien que cet article analyse le Rollup du point de vue de Celestia, ce qui est différent de la façon dont la communauté Ethereum analyse le modèle Rollup, compte tenu des nombreuses interconnexions entre Ethereum Rollup et Celestia Sovereign Rollup, ainsi que de l'influence croissante de cette dernière, cet article vaut également le détour pour les passionnés d'Ethereum.

Qu'est-ce qu'un Rollup ?

Les rollups sont des blockchains qui publient les données de leurs transactions sur une autre blockchain et héritent de son consensus et de la disponibilité des données.

Pourquoi est-ce que je remplace « bloquer » par « données de transaction » ici ? Permettez-moi de vous expliquer la différence entre un bloc de cumul et des données de cumul et de vous montrer que le cumul minimal ne nécessite que des données cumulatives avec notre première variante.

Un bloc cumulatif est une structure de données représentant la blockchain à une certaine hauteur. Il se compose de données cumulatives et d'un en-tête cumulatif. Et les données cumulatives sont soit un lot de transactions, soit la différence d'état entre les lots de transactions.

Variante 1 : cumul pessimiste basé sur le pessimisme

Le moyen le plus simple de créer un cumul est de publier des transactions par un utilisateur sur une autre blockchain. Nous appellerons cette blockchain la couche de consensus et de disponibilité des données, mais je vais la raccourcir en couche DA dans tous les diagrammes suivants. (Remarque : similaire à Layer1, souvent mentionnée dans la communauté Ethereum).

Dans notre première variante, chaque nœud de cumul doit rejouer toutes les transactions sur la blockchain pour vérifier l'état le plus récent. Nous venons de créer un Rollup pessimiste !

Un cumul pessimiste est un cumul qui ne prend en charge que les nœuds complets qui rejouent toutes les transactions du cumul pour vérifier sa validité.

Mais dans ce cas, qui est le séquenceur ? Aucune entité n'exécute réellement les transactions à part les nœuds complets de cumul eux-mêmes. D'habitude, un séquenceur regroupe les transactions et produit un en-tête cumulatif, mais il n'y en a pas dans ce cas !

Pour faciliter la discussion, nous avons divisé le séquenceur en deux entités logiques : l'agrégateur et le producteur d'en-têtes le différencient. Une entité doit connaître l'état (c'est-à-dire qu'elle doit exécuter l'état pour calculer l'en-tête), mais l'agrégateur n'a pas besoin de comprendre l'état pour pouvoir l'agréger.

Le séquençage est le processus d'agrégation et de production d'en-têtes.

L'agrégation est le processus qui consiste à regrouper les transactions en un seul lot. Un lot de transactions consiste en une ou plusieurs transactions. (Remarque : le lot est la partie des données du bloc Rollup, à l'exception de l'en-tête).

La production de l'en-tête est le processus de création de l'en-tête cumulatif.

Rollup Header est une métadonnée relative au bloc, qui inclut au minimum un engagement concernant les transactions contenues dans ce bloc. (Remarque : l'engagement fait référence à l'engagement en faveur de l'exactitude des résultats du traitement des transactions).

De ce point de vue, nous pouvons voir qui joue le rôle de chaque composant du Rollup. Regardons d'abord la partie agrégateur. Le cumul pessimiste mentionné plus haut ne comporte aucun processus de production d'en-tête, et les utilisateurs publient les transactions directement sur la couche DA, ce qui signifie que le réseau de la couche DA agit essentiellement comme un agrégateur.

Le cumul pessimiste est une variante du cumul qui délègue l'étape d'agrégation à la couche DA. Il n'y a pas de séquenceur. Parfois, ce type de cumul est appelé « cumul basé ».

Based Rollup possède la même résistance à la censure et la même vivacité que la couche DA (l'activité mesure la vitesse de réponse du système aux demandes des utilisateurs). Si les utilisateurs de ce type de rollup veulent atteindre un niveau de confiance minimal (le plus proche de Trustless), ils doivent gérer au moins un nœud léger de couche DA et un nœud complet de cumul.

Variante 2 : cumul pessimiste à l'aide d'un agrégateur partagé

Parlons de l'agrégation pessimiste à l'aide d'agrégateurs partagés. Cette idée a été proposée par Evan Forbes dans son billet de forum sur la conception de séquenceurs partagés. L'hypothèse clé est qu'un séquenceur partagé est le seul moyen formel de séquencer les transactions. Evan explique les avantages des séquenceurs partagés comme suit :

« Pour débloquer une expérience utilisateur équivalente à Web2, les séquenceurs partagés [...] peuvent proposer des engagements souples rapides (remarque : ce n'est pas une garantie très fiable). Ces engagements souples fournissent des promesses arbitraires quant à l'ordre final des transactions (c'est-à-dire qu'ils promettent que l'ordre des transactions ne changera pas) et peuvent être utilisés pour créer des versions mises à jour prématurément de l'état (mais la finalisation n'est pas encore terminée pour le moment).

Dès qu'il aura été confirmé que les données bloquées sont publiées sur la couche de base (s/b faisant référence à DALayer), l'état peut être considéré comme définitif. »

Comme nous sommes toujours pessimistes, nous n'avons que des nœuds complets de cumul et aucun nœud lumineux. Chaque nœud doit exécuter toutes les transactions pour garantir leur validité. Il n'y a pas de nœuds lumineux dans ce système, donc pas besoin d'un en-tête cumulatif, c'est-à-dire d'un producteur d'en-têtes. (Remarque : d'une manière générale, un nœud léger d'une blockchain n'a pas besoin de synchroniser des blocs complets, mais ne reçoit que des en-têtes de bloc)

Comme il n'y a aucune étape de production d'en-tête cumulatif, le séquenceur partagé Rollup mentionné ci-dessus n'a pas besoin d'exécuter de transactions pour les mises à jour de statut (une condition préalable à la production d'en-tête), mais inclut uniquement le processus d'agrégation des données de transaction. Je préfère donc parler d'agrégateur partagé.

Dans cette variante, les utilisateurs de Rollup doivent exécuter au moins les opérations suivantes en minimisant la confiance :

Nœud lumineux de la couche DA + nœud lumineux du réseau d'agrégateurs partagé + nœud complet Rollup.

Pour le moment, il est nécessaire de vérifier l'en-tête d'agrégateur publié (sans faire référence à l'en-tête cumulatif) via le nœud lumineux du réseau d'agrégateurs partagé. Comme indiqué plus haut, l'agrégateur partagé se charge du tri des transactions. Dans l'en-tête de l'agrégateur publié, il contient un engagement cryptographique, correspondant au lot publié sur la couche DA.

Ainsi, l'opérateur du nœud Rollup peut confirmer que le lot reçu depuis la couche DA a été créé par l'agrégateur partagé, et non par d'autres.

(Le contenu ci-dessus étant relativement obscur, vous pouvez relire le schéma)

L'inclusion est le processus par lequel une transaction est acceptée dans la blockchain.

La commande est le processus qui consiste à organiser les transactions dans un ordre spécifique dans la blockchain.

L'exécution est le processus par lequel les transactions de la blockchain sont traitées et leurs effets sont appliqués à l'état de la blockchain.

Comme l'agrégateur partagé contrôle l'inclusion et l'ordre, nous héritons de sa résistance à la censure.

Si nous supposons que L_ss est la vivacité de l'agrégateur partagé et que L_da est la vivacité de la couche DA, alors la vivacité de ce schéma est L = L_da & & L_ss. En d'autres termes, si l'un ou l'autre des systèmes rencontre un échec de vivacité, le cumul entraîne également un échec de vivacité.

Par souci de simplicité, j'utiliserai liveness comme booléen. Si l'agrégateur partagé échoue, nous ne pouvons pas procéder au cumul. Si la couche DA tombe en panne, nous pourrions poursuivre les engagements souples de l'agrégateur partagé. Nous nous en remettrons au consensus et à la disponibilité des données de l'agrégateur partagé, ce qui serait pire que la couche DA d'origine.

Continuons à explorer la résistance à la censure de la solution Rollup ci-dessus :

Dans ce schéma, la couche DA ne peut pas censurer des transactions spécifiques. (Remarque : l'examen des transactions peut souvent refuser le téléchargement de certaines transactions sur la chaîne). Il ne peut censurer que les lots cumulatifs complets que l'agrégateur partagé a déjà agrégés. (rejetant un lot à inclure dans la couche DA).

Cependant, selon le flux de travail de Rollup, lorsque l'agrégateur de partage soumet le lot de transactions à la couche DA, il a déjà terminé le séquençage des transactions et l'ordre entre les différents lots a également été déterminé. Par conséquent, ce type d'examen des transactions par la couche DA n'a d'autre effet que de retarder la finalisation du registre de Rollup.

En résumé, je pense que l'objectif de la résistance à la censure est de faire en sorte qu'aucune entité ne puisse contrôler ou manipuler le flux d'informations au sein du système, alors que la vivacité implique de maintenir les fonctionnalités et la disponibilité du système, même en cas de panne de réseau et d'actions contradictoires. Bien que cela soit contraire à la définition universitaire dominante actuelle, je continuerai à utiliser la définition du concept que j'ai énoncée.

Variante 3 : cumul pessimiste avec agrégation basée et partagée

Même si la communauté bénéficie des avantages d'un agrégateur partagé, nous voulons éviter de dépendre de lui et nous rabattre sur la couche DA. Nous allons combiner les commandes et permettre aux utilisateurs de soumettre des transactions directement à la couche DA. Il combine une agrégation basée et partagée.

Nous partons du principe que l'ordre final sera interprété comme toutes les transactions commandées par l'agrégateur partagé, puis toutes les transactions basées sur la base par bloc de couche DA. C'est ce que nous appelons la règle de choix des fourchettes des rollups.

L'agrégation se fait ici en deux étapes. Tout d'abord, l'agrégateur partagé prend les devants en agrégeant certaines transactions. Ensuite, la couche DA regroupe les lots déjà commandés et les transactions que l'utilisateur a directement soumises.

L'analyse de la résistance à la censure est désormais plus complexe. Le nœud du réseau de la couche DA peut examiner le lot soumis par l'agrégateur partagé avant la production du bloc de couche DA suivant. Après avoir pris connaissance des données de transaction du lot, le nœud de la couche DA peut extraire la valeur MEV, lancer une transaction initiale avec son compte sur le réseau Rollup et l'inclure dans le bloc de la couche DA avant d'inclure le lot soumis par l'agrégateur partagé Rollup.

Apparemment, la finalité de l'ordre de transaction garantie par l'engagement souple du troisième type de variante Rollup est plus fragile que celle du deuxième type de variante Rollup mentionné plus haut. Dans ce cas, l'agrégateur partagé transmet la valeur MEV au nœud de la couche DA. À ce propos, je suggère aux lecteurs de suivre la conférence sur la censure rentable du MEV.

À l'heure actuelle, certaines solutions de conception sont apparues pour réduire la capacité des nœuds du réseau de la couche DA à exécuter de telles transactions MEV, comme la fonction « période de réorganisation », qui retarde les transactions soumises directement par les utilisateurs du réseau Rollup à la couche DA. Sovereign Labs l'a détaillé dans sa proposition de design intitulée Based Sequencing with Soft Confirmations, où le concept de « séquenceur préféré » est proposé.

Comme le MEV dépend du système d'agrégation que vous choisissez et de la règle de choix des fork pour le cumul, certains n'en divulgueront aucune, tandis que d'autres divulgueront une partie ou la totalité du MEV vers la couche DA, mais ce sera un sujet pour un autre jour.

Pour ce qui est de la vivacité, ce design cumulatif a une longueur d'avance par rapport au simple fait d'avoir un agrégateur partagé. Si l'agrégateur partagé échoue, l'utilisateur peut toujours soumettre des transactions à la couche DA.

Enfin, parlons de la plus petite configuration minimisant la confiance : un nœud lumineux de couche DA + un nœud d'éclairage agrégateur partagé + un nœud complet de cumul.

Pour le moment, nous devons encore valider les en-têtes de l'agrégateur partagé pour notre nœud complet de cumul afin de pouvoir différencier les lots de transactions en fonction de sa règle de choix des fork.

Variante 4 : cumul optimiste basé sur un générateur d'en-têtes centralisé

Commençons à préparer quelques nœuds légers en utilisant une variante appelée le rollup optimiste basé sur un producteur d'en-têtes centralisé. Ce design utilise la couche DA pour agréger les transactions, mais nous avons introduit un producteur d'en-têtes centralisé pour activer les nœuds légers de cumul.

Les nœuds Rollup Light peuvent vérifier indirectement la validité des transactions Rollup grâce à un seul cycle de prévention des fraudes. Le nœud lumineux adoptera une attitude optimiste à l'égard du générateur de l'en-tête cumulatif et émettra une confirmation finale à la fin de la période de protection contre les fraudes. Une autre possibilité est qu'elle reçoive une preuve de fraude de la part d'un nœud complet honnête, sachant que le générateur d'en-têtes a soumis des données incorrectes.

Je n'entrerai pas dans les détails sur le fonctionnement des preuves de fraude en un seul tour, car cela dépasserait le cadre de cet article. L'avantage, c'est que vous pouvez réduire le délai de protection contre les fraudes de 7 jours à un certain montant, qui reste à déterminer mais qui est inférieur. Light Nodes peut recevoir des preuves de fraude via la couche p2p sans avoir à attendre un litige, car tout est saisi dans une seule preuve.

Nous utilisons la couche DA comme agrégateur, héritant de sa résistance à la censure. Il inclut et commande. Le producteur d'en-têtes centralisé lira l'ordre canonique de la couche DA et sera en mesure de créer un en-tête valide à partir de celui-ci. Le producteur d'en-tête centralisé publiera l'en-tête et les racines de l'état sur la couche DA. Ces racines étatiques sont essentielles pour créer une preuve contre les fraudes contre cet engagement. L'agrégateur s'occupe de l'inclusion et de la commande, tandis que le producteur d'en-têtes s'occupe de l'exécution.

On suppose que la couche DA (qui fait également office d'agrégateur pour le Rollup en ce moment) est suffisamment décentralisée et résiste bien à la censure. De plus, le producteur d'en-tête ne peut pas modifier la séquence des transactions cumulatives publiée par l'agrégateur. Maintenant, si le producteur Header est décentralisé, le seul avantage est une meilleure vivacité, mais les autres propriétés du Rollup sont les mêmes que celles de la première variante, Based Rollup.

Si le producteur d'en-tête a un échec de vivacité, le cumul a également un échec de vivacité. Le nœud léger ne sera pas en mesure de suivre la chaîne, tandis que les nœuds complets pourront toujours suivre la chaîne si cela est souhaitable, en revenant à un cumul pessimiste, comme décrit dans la variante 1. Évidemment, la configuration minimale pour minimiser la confiance décrite dans la variante 4 est la suivante :

Nœud d'éclairage de la couche DA + Nœud d'éclairage Rollup.

Variante 5 : ZK-Rollup basé sur un marché de prouvateurs décentralisé

Nous avons discuté du cumul pessimiste (cumul basé) et du cumul optimiste. Il est maintenant temps de passer à ZK-Rollup. Toghrul a récemment fait une présentation sur la séparation entre l'agrégateur (séquenceur) et le producteur d'en-têtes (Prover) (séparation séquenceur-prouveur dans des rollups à connaissance nulle). Dans ce modèle, il est plus facile de publier les transactions sous forme de données cumulatives plutôt que sous forme de State Diff. Je vais donc me concentrer sur le premier. La variante 5 est un zk-rollup basé sur un marché de provers décentralisé.

À présent, vous devriez savoir à quoi sert un cumul basé. La variante 5 délègue le rôle d'agrégateur aux nœuds de la couche DA, qui effectuent le travail d'inclusion et de classement. Je vais citer un extrait du document de Sovereign-Labs qui explique à merveille le cycle de vie de leur conception. Je vais l'adapter légèrement pour qu'il corresponde à la variante 5.

Les utilisateurs publient un nouveau blob de données sur la chaîne L1. Dès que le blob est finalisé en L1, il est logiquement définitif. Immédiatement après la finalisation du bloc L1, les nœuds complets du cumul le parcourent et traitent tous les blocs de données pertinents dans l'ordre dans lequel ils apparaissent, générant ainsi une nouvelle racine d'état de cumul. À ce stade, le bloc est finalisé subjectivement du point de vue de tous les nœuds complets.

Dans ce design, notre producteur d'en-têtes est le marché décentralisé des prouvateurs.

Les nœuds prover (nœuds complets s'exécutant dans une ZKVM) effectuent à peu près le même processus que les nœuds complets : ils parcourent le bloc DA et traitent tous les lots dans l'ordre, produisent des preuves et les publient sur une chaîne. (Les preuves doivent être publiées sur la chaîne si le cumul vise à inciter les étalons. Sinon, il est impossible de savoir quel étaleur a traité un lot donné en premier). Une fois qu'une épreuve pour un lot donné a été publiée sur la chaîne, le lot est subjectivement final pour tous les nœuds, y compris les nœuds légers.

(Comme de nombreux concepts entrent en jeu, vous pouvez consulter à nouveau le schéma)

La variante 5 présente la même résistance à la censure que la couche DA. Le marché décentralisé des étalons ne peut pas censurer les transactions car c'est la couche DA qui détermine l'ordre canonique. Nous avons décentralisé le producteur d'en-têtes uniquement pour améliorer la vivacité et créer un marché incitatif. La vivacité ici est L = L_da & & L_PM (marché des provers). Si les incitations du marché des étalons ne sont pas alignées, ou si celui-ci échoue, les nœuds légers ne seront pas en mesure de suivre la chaîne, mais les nœuds complets pourront toujours suivre la chaîne si cela est souhaitable, revenant à un cumul pessimiste basé sur le cumul. La plus petite configuration minimisant la confiance se trouve ici, comme dans le cas optimiste avec un nœud d'éclairage de la couche DA et un nœud d'éclairage cumulatif.

Variante 6 : Rollup hybride basé sur un producteur d'en-têtes optimiste centralisé et un testeur décentralisé

Nous laissons toujours les nœuds de la couche DA agir en tant qu'agrégateurs pour le rollup, et nous les déléguons pour gérer l'inclusion et le tri des transactions.

Comme vous pouvez le voir sur la figure ci-dessous, ZK Rollup et Optimistic Rollup utilisent les mêmes lots de transactions ordonnées sur la couche DA comme source du registre de cumul. C'est pourquoi nous pouvons utiliser deux systèmes de preuve en même temps : les lots de transactions ordonnés sur la couche DA ne sont pas affectés par le système de preuve lui-même.

Parlons de finalité. Du point de vue d'un nœud complet de cumul, le cumul est final lorsque la couche DA est finale, car elle doit simplement exécuter les transactions pour cette variante. Mais nous nous soucions davantage de la finalité du nœud lumineux. Supposons que le producteur d'en-tête centralisé participe, signe par-dessus un en-tête et publie les racines d'état calculées sur la couche DA.

Comme pour la variante 4 précédente, les light nodes feront confiance à l'exécution avec optimisme et attendront une preuve de fraude de la part d'un nœud complet honnête indiquant que le producteur de l'en-tête a commis une fraude. Une fois la fenêtre anti-fraude terminée, le bloc de roulement est définitif du point de vue d'un nœud lumineux d'enroulement.

L'essentiel est que si nous parvenons à obtenir une preuve ZK, nous n'aurons plus à attendre la fin de la période de protection contre la fraude. Outre les preuves de fraude en un seul tour, nous pouvons les remplacer par des preuves ZK et supprimer tout en-tête malveillant généré par un producteur d'en-têtes optimiste !

Lorsque le light node recevra le certificat ZK correspondant à un certain lot de transactions Rollup, le lot sera finalisé.

Maintenant, nous avons un engagement rapide et doux et une finalité rapide.

La variante 6 bénéficie toujours de la même résistance à la censure que la couche DA telle qu'elle est basée. Pour ce qui est de la vivacité, nous aurons L = L_da & & (L_op || L_PM), ce qui signifie que nous avons augmenté notre garantie de vivacité. Si le marché centralisé des producteurs d'en-têtes ou des prouvateurs rencontre un problème de vivacité, nous pouvons revenir à l'autre schéma.

La plus petite configuration minimisant la confiance est un nœud d'éclairage de couche DA et un nœud d'éclairage cumulatif.

Résumé :

1. Nous avons divisé le séquenceur en deux entités logiques : l'agrégateur et le producteur d'en-têtes

2. Nous avons divisé le séquenceur en trois processus logiques : inclusion, classement et exécution.

3. Les cumuls pessimistes et les cumuls basés existent

4. Selon vos besoins, vous pouvez connecter des agrégateurs et des producteurs d'en-têtes prêts à l'emploi.

5. Chaque variante du Rollup de cet article a suivi le schéma suivant :
   

Enfin, j'ai quelques idées. S'il vous plaît, pensez à :

• Comment s'intègrent les rollups classiques dans tout cela ? (en référence à Ethereum Rollup)
• Dans toutes les variantes, nous avons uniquement fait en sorte que l'agrégateur s'occupe de l'inclusion et de la commande et de l'exécution du producteur d'en-têtes. Et si l'agrégateur s'occupe uniquement de l'inclusion et que le producteur d'en-têtes s'occupe de la commande et de l'exécution ? Pensez aux enchères en chaîne. Pouvons-nous séparer les trois ?
• Qu'est-ce qu'un marché de producteurs d'en-têtes ou de producteurs d'en-têtes partagés ?
• Qui obtient le MEV ? Et pouvons-nous le récupérer ?

Avertissement：

1. Cet article est repris de [Geek Web3], Forward the Original Title « Unchercheur de Celestia analyse 6 variantes du Rollup : séquenceur = agrégateur + générateur d'en-têtes ». Tous les droits d'auteur appartiennent à l'auteur original [NashQ, Celestia Researcher]. 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.