Analyse de Rollup du point de vue de Celestia : 6 variantes de la résistance à la censure

Auteur : NashQ, Celestia Researcher ; Compilateur : Faust, Geek Web3

Note du traducteur : Afin de rendre le modèle Rollup plus facile à comprendre et à analyser, le chercheur de Celestia, NashQ, a divisé le séquenceur de Rollup (Sequencer) en deux entités logiques : l'agrégateur et le générateur d'en-tête. Dans le même temps, il a divisé le processus de commande des transactions en trois étapes logiques : inclusion, commande et exécution.

Sous la direction de cette réflexion analytique, les six variantes importantes du Rollup souverain sont plus claires et plus faciles à comprendre. NashQ a discuté en détail de la résistance à la censure et de l'activité des différentes variantes de Rollup, et a également discuté de la configuration minimale du nœud de chaque variante de Rollup dans l'état de confiance minimisé (c'est-à-dire, pour atteindre l'état sans confiance, quels types d'utilisateurs de Rollup doivent exécuter au moins nœud).

Bien que cet article analyse 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 souverain Rollup, ainsi que l'influence croissante de ce dernier, il est important pour For Amateurs d'Ethereum, cet article vaut également la peine d'être lu.

Qu'est-ce qu'un cumul ?

Un Rollup est une blockchain qui publie ses "données de transaction" vers une autre blockchain et hérite de son consensus et de la disponibilité des données.

Pourquoi ai-je délibérément utilisé le mot "données de transaction" au lieu de "bloquer" ? Cela implique une distinction entre les blocs de cumul et les données de cumul, les cumuls les plus compacts ne nécessitant que des données de cumul comme la première variante ci-dessous.

Un bloc Rollup est une structure de données qui représente le registre de la blockchain à une certaine hauteur de bloc. Le bloc de cumul se compose de données de cumul et d'en-tête de cumul. Parmi elles, les données de cumul peuvent être un lot de transactions ou des changements d'état entre un lot de transactions.

### Variante 1 : Cumul pessimiste / Cumul basé

Le moyen le plus simple de créer un Rollup est de laisser les utilisateurs publier des transactions sur une autre blockchain, que nous appellerons la couche de consensus et de disponibilité des données (DA-Layer), et je l'appellerai simplement la couche DA dans ce qui suit (Note du traducteur : C'est similaire à la couche 1, ce qui est souvent dit dans la communauté Ethereum).

Dans la première variante Rollup que je vais présenter, les nœuds du réseau Rollup doivent ré-exécuter les transactions Rollup contenues dans la couche DA pour vérifier l'état final du ledger. C'est un Rollup pessimiste !

Pessimistic Rollup est un Rollup qui ne prend en charge que les nœuds complets, et ces nœuds complets doivent réexécuter toutes les transactions contenues dans le registre Rollup pour vérifier leur validité.

Mais dans ce cas, qui fait office de Séquenceur du Rollup ? En fait, à l'exception des nœuds complets de Rollup, aucune entité n'a jamais exécuté les transactions contenues dans le registre Rollup. De manière générale, le séquenceur agrège les données de transaction et génère un en-tête Rollup. Mais le Rollup pessimiste mentionné ci-dessus n'a pas d'en-tête Rollup !

Pour la commodité de la discussion, nous pouvons diviser le séquenceur en deux entités logiques : Aggregator Aggregator et Header Generator. Pour générer un Rollup Header, vous devez d'abord exécuter la transaction, terminer la transition d'état, puis calculer l'en-tête correspondant. Mais pour un agrégateur, il n'est pas nécessaire de terminer une transition d'état pour procéder à l'étape d'agrégation.

Le séquençage de tri est le processus "d'agrégation + création d'en-tête de cumul".

L'agrégation est l'étape de regroupement des données de transaction dans un lot. Un lot contient généralement de nombreuses transactions (Note du traducteur : le lot est la partie des données du bloc Rollup autre que l'en-tête).

L'étape de génération d'en-tête est le processus de création d'un en-tête cumulatif. Rollup Header est la métadonnée sur le bloc Rollup, incluant au moins l'engagement des données de transaction dans le bloc (Note du traducteur : l'engagement mentionné ici fait référence à l'engagement à l'exactitude des résultats du traitement de la transaction).

Grâce à la perspective ci-dessus, on peut voir qui est responsable de chaque partie de Rollup. Regardez d'abord la partie de l'agrégateur Aggregator. Le cumul pessimiste susmentionné n'a pas de processus de génération 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.

Par conséquent, le Rollup pessimiste est une variante de Rollup qui délègue l'étape d'agrégation à la couche DA, qui ne possède pas de séquenceur Sequencer. Parfois, ce type de cumul est appelé "cumul basé".

Le cumul basé a la même résistance à la censure et la même activité que la couche DA (l'activité mesure la vitesse de réaction du système aux demandes des utilisateurs). Si les utilisateurs de ce type de Rollup souhaitent atteindre un état de confiance minimale (le plus proche de Trustless), ils doivent exécuter au moins un nœud léger du réseau de couche DA et un nœud complet du réseau Rollup.

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

Discutons de l'agrégation pessimiste à l'aide d'un agrégateur partagé. Cette idée a été suggérée par Evan Forbes dans son article de forum sur la conception de séquenceurs partagés. Son hypothèse clé est qu'un séquenceur partagé est le seul moyen formel de séquencer les transactions. Evan explique ainsi les avantages des séquenceurs partagés :

"Afin d'obtenir une expérience utilisateur équivalente à Web2, le séquenceur partagé peut fournir une génération rapide de Soft Commitments (garanties peu fiables). Ces Soft Commitments apportent certaines garanties sur l'ordre de transaction final (c'est-à-dire que l'ordre de transaction d'engagement ne sera pas Modifier), et l'étape de mise à jour du statut du registre Rollup peut être effectuée à l'avance (mais la finalisation n'est pas encore terminée à ce stade).

Une fois que les données du bloc Rollup sont confirmées et publiées sur la couche de base Base Layer (ici, elles doivent faire référence à la couche DA), la mise à jour de l'état du registre Rollup est finalisée et finalisée. "

La variante Rollup susmentionnée appartient toujours à la catégorie des Rollup pessimistes, car il n'y a que des nœuds complets dans ce type de système Rollup et aucun nœud léger. Chaque nœud Rollup doit exécuter toutes les transactions pour garantir la validité de la mise à jour du statut du grand livre. Étant donné que ce type de cumul n'a pas de nœuds légers, il n'a pas besoin d'en-tête de cumul, ni de générateur d'en-tête. (Note du traducteur : en général, les nœuds légers d'une blockchain n'ont pas besoin de synchroniser des blocs complets, ne reçoivent que des en-têtes de bloc)

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

Dans cette variante, les utilisateurs de Rollup doivent au moins exécuter des nœuds légers de couche DA + des nœuds légers du réseau d'agrégateur partagé + des nœuds complets de Rollup dans un état de confiance minimisé.

À ce stade, l'en-tête d'agrégateur publié (et non l'en-tête cumulatif ici) doit être vérifié par les nœuds légers partageant le réseau d'agrégateur. Comme mentionné ci-dessus, l'agrégateur partagé effectue le travail de tri des transactions.Il contient un engagement cryptographique dans l'en-tête de l'agrégateur publié, correspondant au lot qu'il a publié sur la couche DA.

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

• L'inclusion est le processus d'inclusion des transactions dans la blockchain.
• La commande de tri fait référence au processus d'organisation des transactions dans la blockchain dans un ordre spécifique.
• L'exécution fait référence au processus de traitement des transactions dans la blockchain et à la réalisation des mises à jour de statut.

Étant donné que l'agrégateur partagé s'occupe de l'inclusion et du tri, la résistance à la censure de Rollup en dépend.

Si l'on suppose que L_ss est l'activité de l'agrégateur partagé et L_da est l'activité de la DA-Layer, alors l'activité du modèle Rollup est L = L_da && L_ss. En d'autres termes, si l'une des deux parties a un échec de vivacité, le cumul a également un échec de vivacité.

Pour plus de simplicité, je considérerai la vivacité comme une valeur booléenne. Si l'agrégateur partagé échoue, Rollup ne peut pas continuer à fonctionner. Si le réseau de couche DA échoue, l'agrégateur partagé peut continuer à fournir un engagement souple pour les blocs cumulatifs. Mais à ce stade, les attributs de Rollup dépendront entièrement du réseau d'agrégateur partagé, et les attributs de ce dernier sont souvent bien inférieurs à la couche DA d'origine.

Passons à l'exploration de la résistance à la censure du schéma Rollup ci-dessus :

Dans ce schéma, la couche DA ne peut pas examiner certaines transactions spécifiques (Note du traducteur : l'examen des transactions peut souvent refuser d'autoriser le téléchargement de certaines transactions dans la chaîne), il ne peut commencer que pour l'ensemble du lot de transactions soumis par l'agrégateur partagé Examen des transactions (refusé d'autoriser l'inclusion d'un lot dans la couche DA).

Cependant, selon le flux de travail Rollup, lorsque l'agrégateur partagé soumet le lot de transactions Batch à la couche DA, il a déjà terminé le tri des transactions et l'ordre entre les différents lots a également été déterminé. Par conséquent, ce type de révision des transactions au niveau de la couche DA n'a d'autre effet que de retarder la confirmation finale du grand livre de Rollup.

En résumé, je crois que le but de la résistance à la censure est de s'assurer qu'aucune entité ne peut contrôler ou manipuler le flux d'informations au sein du système, tandis que la vivacité implique le maintien de la fonctionnalité et de la disponibilité du système, même en présence de pannes de réseau et comportement conflictuel. Bien que cela entre en conflit avec la définition académique dominante actuelle, j'utiliserai toujours la définition du concept que j'ai articulée.

### Variante 3 : cumul pessimiste basé sur un cumul basé et un agrégateur partagé

Bien que l'agrégateur partagé apporte des avantages aux utilisateurs et à la communauté, nous devons éviter de trop nous fier à lui et permettre aux utilisateurs de se retirer de l'agrégateur partagé vers la couche DA. Nous pouvons combiner les deux variantes de Rollup introduites précédemment, permettant aux utilisateurs de soumettre des transactions directement à la couche DA tout en utilisant un agrégateur partagé.

Nous supposons que la séquence de transactions Rollup finale dépend de la séquence de transactions soumise par l'agrégateur partagé et des transactions Rollup directement soumises par les utilisateurs dans le bloc de couche DA. Nous appelons cette règle de sélection de fourchette de Rollup.

L'agrégation est ici divisée en deux étapes. Tout d'abord, un agrégateur partagé entre en jeu, agrégeant certaines transactions. Ensuite, la couche DA peut agréger le lot soumis par l'agrégateur partagé et les transactions directement soumises par l'utilisateur.

L'analyse de la résistance à la censure à ce stade est un peu plus compliquée. Les nœuds du réseau de la couche DA peuvent 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 dans le lot, les nœuds de la couche DA peuvent extraire la valeur de MEV et s'utiliser d'abord sur le cumul réseau Le compte initie une transaction frontale et l'inclut d'abord dans le bloc de couche DA, puis inclut le lot soumis par l'agrégateur partagé Rollup.

Évidemment, la finalité de l'ordre de transaction garantie par l'engagement souple du troisième type de variante Rollup est plus fragile que le deuxième type de variante Rollup précité. Dans ce cas, l'agrégateur partagé a transmis la valeur MEV aux nœuds de la couche DA. À cet égard, je recommande aux lecteurs de regarder la conférence de recherche sur l'exploitation rentable du MEV censuré.

À l'heure actuelle, certains schémas de conception ont émergé pour réduire la capacité des nœuds du réseau de la couche DA à exécuter de telles transactions MEV, telles que la fonction "période de fenêtre de réorganisation", qui retardera l'exécution des transactions soumises directement à la couche DA par les utilisateurs du réseau Rollup. . Sovereign Labs décrit cela en détail dans leur proposition de conception appelée séquençage basé avec confirmations logicielles, qui introduit le concept de « séquenceur préféré ».

Étant donné que le problème MEV dépend du schéma d'agrégation choisi par Rollup et des règles de sélection de la fourche de cumul, certains schémas ne divulgueront pas de MEV vers la couche DA, et certains schémas divulgueront une partie ou la totalité du MEV vers la couche DA, mais c'est un autre sujet.

En ce qui concerne la vivacité, ce schéma de cumul présente des avantages par rapport aux schémas qui permettent uniquement aux agrégateurs partagés de soumettre des transactions à la couche DA. En cas de défaillance de l'activité sur un agrégateur partagé, les utilisateurs peuvent toujours soumettre des transactions à la couche DA.

Enfin, parlons de la configuration minimale des utilisateurs Rollup sous minimisation de la confiance :

Au moins, exécutez le nœud léger de la couche DA + le nœud léger de l'agrégateur partagé + le nœud complet de cumul.

À ce stade, il est encore nécessaire de vérifier l'en-tête d'agrégateur émis par l'agrégateur partagé, afin que le nœud complet de cumul puisse distinguer les lots de transactions en fonction des règles de sélection de fourche.

Variante 4 : cumul basé sur l'optimisme et générateur d'en-tête centralisé

Discutons d'une variante appelée Based Optimistic Rollup et d'un générateur d'en-tête centralisé. Cette solution utilise la couche DA pour agréger les transactions Rollup, mais introduit un générateur d'en-tête centralisé pour générer des en-têtes Rollup afin d'activer les nœuds légers Rollup.

Les nœuds légers Rollup peuvent vérifier indirectement la validité des transactions Rollup via un seul cycle de preuve de fraude. Le nœud léger sera optimiste quant au générateur de l'en-tête cumulatif et effectuera la confirmation finale après la fin de la période de fenêtre anti-fraude. Une autre possibilité est qu'il reçoive une preuve de fraude d'un nœud complet honnête que le générateur d'en-tête a soumis des données erronées.

Je ne vais pas entrer dans les détails du fonctionnement d'une preuve de fraude à un tour ici, car cela dépasse le cadre de cet article. L'avantage d'un seul cycle de preuve de fraude est qu'il peut raccourcir dans une certaine mesure la période de la fenêtre de preuve de fraude de 7. La valeur spécifique reste à déterminer, mais l'ordre de grandeur est plus petit que le cumul optimiste traditionnel. Les nœuds légers peuvent obtenir des preuves de fraude via le réseau P2P composé de nœuds complets Rollup sans attendre le processus de contestation ultérieur, car tous les critères sont entièrement fournis dans une seule preuve de fraude.

Le modèle Rollup ci-dessus utilise la couche DA comme agrégateur et hérite de sa résistance à la censure. La couche DA à ce stade est chargée de contenir et de classer les transactions. Le générateur d'en-tête centralisé lira la séquence de transaction Rollup à partir de la couche DA et construira l'en-tête Rollup correspondant en conséquence. Le générateur d'en-tête publiera l'en-tête et la racine d'état sur la couche DA. Ces Stateroots sont nécessaires lors de la création de preuves de fraude. En bref, l'agrégateur est responsable de l'inclusion et du tri des transactions, et le générateur d'en-tête exécutera la transaction pour mettre à jour l'état afin d'obtenir le Stateroot.

Supposons que la couche DA (qui agit également comme un agrégateur pour Rollup à ce stade) est suffisamment décentralisée et résistante à la censure. De plus, le générateur d'en-tête ne peut pas modifier la séquence des transactions Rollup publiées par l'agrégateur. Maintenant, si le générateur d'en-tête est décentralisé, le seul avantage est une meilleure vivacité, mais les autres propriétés de Rollup sont les mêmes que la première variante Based Rollup.

Si le générateur d'en-tête échoue en vivacité, le cumul échouera également en vivacité. Les nœuds légers ne pourront pas suivre la progression du grand livre Rollup, mais les nœuds complets le pourront. À ce stade, le cumul décrit dans la variante 4 dégénère en le cumul basé décrit dans la variante 1. Apparemment, la configuration minimale de confiance minimisée décrite par la variante 4 est :

Nœud de lumière de couche DA + nœud de lumière Rollup.

Variante 5 : ZK-Rollup basé et marché de preuves décentralisé

Nous avons discuté du cumul pessimiste (cumul basé) et du cumul optimiste, il est maintenant temps d'envisager ZK-Rollup. Récemment, Toghrul a prononcé un discours sur la séparation de l'agrégateur (Sequencer) et du générateur d'en-tête (Prover) (Sequencer-Prover Separation in Zero-Knowledge Rollups). Dans ce modèle, il est plus facile de gérer les transactions de publication en tant que données Rollup plutôt que State Diff, je vais donc me concentrer sur la première. La variante 5 est un marché de preuves décentralisé basé sur zk-rollup.

À présent, vous devriez être familiarisé avec le fonctionnement de Rollup. La variante 5 délègue le rôle d'agrégateur aux nœuds de couche DA, qui effectuent le travail d'inclusion et de tri des transactions. Je citerai la documentation de Sovereign-Labs, qui explique bien le cycle de vie d'une transaction dans la variante 5 :

L'utilisateur publie un nouveau bloc de données dans la chaîne L1 (couche DA). Une fois ces blocs de données finalisés sur la chaîne L1, celle-ci est logiquement définitive (inchangeable). Une fois que les blocs de la chaîne L1 sont entrés dans l'étape de finalisation (c'est-à-dire qu'ils ne peuvent pas être annulés), les nœuds complets de Rollup analysent ces blocs, traitent tous les blocs de données liés à Rollup dans l'ordre et génèrent la dernière racine d'état Rollup Stateroot . À ce stade, du point de vue des nœuds complets de cumul, ces blocs de données ont été finalisés.

Dans ce modèle, le générateur d'en-tête est géré par le marché décentralisé du prouveur.

Le processus de travail du nœud de preuve Prover (un nœud complet fonctionnant dans ZKVM) est similaire à celui d'un nœud complet Rollup normal - en analysant la blockchain de la couche DA et en traitant tous les lots de transactions Rollup afin de générer la preuve à connaissance zéro correspondante et publier sur la chaîne de couches DA. (Si le système Rollup veut motiver le prouveur, ce dernier doit envoyer la preuve ZK générée à la chaîne de couches DA, sinon il ne sera pas possible de déterminer quel prouveur a soumis la preuve ZK en premier). Une fois que la preuve ZK correspondant à un certain lot de transactions est publiée dans la chaîne, le lot de transactions est finalisé aux yeux de tous les nœuds Rolup (y compris les nœuds légers).

La variante 5 a la même résistance à la censure que la couche DA. Le Prover Market décentralisé ne peut pas examiner les transactions Rollup, car la couche DA a déjà déterminé l'ordre de transaction standard, uniquement pour obtenir une meilleure activité et créer un marché incitatif, de sorte que le générateur d'en-tête (se réfère ici à Prover) est un changement décentralisé.

L'activité ici est L = L_da && L_pm (activité du prouveur). Si les incitations du Prover Market sont incohérentes, ou s'il y a une défaillance active, le nœud léger Rollup ne pourra pas synchroniser la progression de la blockchain, mais le nœud complet Rollup le pourra. au cumul basé/cumul pessimiste. La configuration minimale pour la minimisation de la confiance ici est la même que dans le cas du Rollup optimiste, à savoir

Nœud de lumière de couche DA + nœud de lumière Rollup.

Variante 6 : Rollup hybride + générateur d'en-tête optimiste centralisé + prouveur décentralisé

Nous laissons toujours les nœuds de la couche DA agir en tant qu'agrégateurs Rollup et leur déléguons le travail d'inclusion et de commande des transactions.

Comme vous pouvez le voir sur la figure ci-dessous, ZK Rollup et Optimistic Rollup utilisent le même lot de transactions ordonnées sur la couche DA comme source du grand livre Rollup. C'est la raison pour laquelle nous pouvons utiliser les deux systèmes de preuve en même temps : le lot ordonné de transactions sur la couche DA n'est pas lui-même affecté par le système de preuve.

Parlons d'abord de la finalité. Du point de vue du nœud Rollup complet, lorsque le bloc de la couche DA est finalisé, le lot de transactions Rollup qu'il contient est finalisé et ne peut pas être modifié. Mais nous nous soucions plus de la finalité du point de vue des nœuds légers. Supposons que le générateur d'en-tête centralisé hypothèque certains actifs, signe l'en-tête cumulatif généré et soumette le Stateroot calculé à la couche DA.

Comme la variante 4 précédente, le nœud léger fera confiance avec optimisme au générateur d'en-tête, croira que l'en-tête qu'il a émis est correct et attendra la preuve de fraude du réseau de nœuds complet. Si la fenêtre de la preuve de fraude est terminée et que le réseau de nœuds complet n'a pas émis la preuve de fraude, du point de vue du nœud léger Rollup, le bloc Rollup est finalisé.

Le point clé est que si nous pouvons obtenir une preuve ZK, nous n'avons pas à attendre la fin de la fenêtre de preuve de fraude. En plus d'une seule série de preuves de fraude, nous pouvons remplacer les preuves de fraude par des preuves ZK et supprimer les faux en-têtes générés par des générateurs d'en-tête malveillants !

Lorsque les nœuds légers reçoivent une preuve ZK pour un lot de transactions Rollup, le lot est finalisé.

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

La variante 6 a toujours la même résistance à la censure que la couche DA car elle est basée sur la couche DA. Pour la vivacité, nous aurons L = L_da && (L_op || L_pm), ce qui signifie que nous ajoutons des garanties de vivacité. Si le générateur d'en-tête centralisé ou le marché de preuves décentralisé a une panne de vivacité, nous pouvons dégénérer à l'autre des deux.

Dans cette variante, la configuration minimale pour la minimisation de la confiance des utilisateurs est :

Un nœud léger de couche DA + un nœud léger Rollup.

Résumé:

1. Nous divisons le rôle clé de Rollup - Sequencer en deux composants logiques :

Agrégateurs et générateurs d'en-tête.

2. Nous divisons le travail de Sequencer en trois processus logiques : confinement, tri et exécution.

3. Le cumul pessimiste et le cumul basé sont une chose.

4. Selon vos besoins, vous pouvez choisir différentes solutions d'agrégateur et de générateur d'en-tête.

5. Chaque variante de Rollup présentée dans cet article suit le même modèle de conception :

Enfin, j'ai quelques idées. Merci de penser à :

• Comment le Rollup classique (faisant référence à Ethereum Rollup) est-il classé dans les variantes ci-dessus ?
• Dans toutes les variantes, nous laissons uniquement l'agrégateur être responsable de l'inclusion + du tri, et le générateur d'en-tête d'exécuter la transaction. Que se passe-t-il si l'agrégateur n'est responsable que de l'inclusion des transactions et que le générateur d'en-tête est responsable de la commande et de l'exécution des transactions ? Compte tenu de l'introduction de l'étape d'enchères en chaîne, peut-on complètement séparer ces trois étapes ?
• Qu’est-ce que le marché des producteurs d’en-têtes partagés/producteurs d’en-têtes ?
• Qui capture la valeur MEV ? L'utilisateur peut-il le récupérer ?