En plus des bien connus Validity Rollup et Optimistic Rollup, quelles sont les différentes méthodes de classification Rollup ?
Écrit par : NIC Lin
Connaissance préalable:
Comprendre le fonctionnement du Rollup et la problématique de disponibilité des données (Data Availability) du Rollup
Récapitulatif sur le cumul
Qu'il s'agisse d'un cumul de validité ou d'un cumul optimiste, ils téléchargeront des données sur L1 (comme Ethereum), afin que tout le monde puisse accéder aux données du cumul en accédant à L1, et l'utiliser pour dériver le dernier statut du cumul, tel que Alice a 10 USDT et Bob a 5 USDT.
Ceux qui ne téléchargent pas de données vers L1 n'appartiennent pas à Rollup (comme Validium, zkPorter ou Arbitrum AnyTrust), et ils ne font pas l'objet de cet article. De plus, cet article n'abordera pas la façon dont le cumul vérifie la validité de l'état, c'est-à-dire la différence entre le cumul de validité et le cumul optimiste.
La première partie de cet article présentera Sovereign Rollup. Sovereign Rollup, comme son nom l'indique, est un Rollup avec autonomie. Les mises à niveau de version de Rollup ou les hard forks se produisent tous sur les Sovereign Rollups, contrairement aux Rollups que tout le monde connaît maintenant (ci-après dénommés Classic Rollups). L'emplacement du fork est pas sur Classic Rollup, mais sur le contrat L1 Rollup : le contrat L1 Rollup effectue des mises à jour de version via des portefeuilles multi-signatures ou un vote de gouvernance. C'est-à-dire qu'un contrat sur L1 détermine la version qu'un Rollup doit utiliser actuellement. Et s'il y a une attaque sur le Rollup en L1, comme l'attaque du mécanisme de gouvernance ou l'attaque du contrat Rollup lui-même, le Rollup sera affecté. Au contraire, parce que Sovereign Rollup considère simplement L1 comme un endroit pour stocker des données, tous les membres de Sovereign Rollup peuvent décider quelle version utiliser actuellement sous la chaîne, et peu importe ce qui arrive à L1, tant que L1 elle-même n'est pas attaquée (comme comme la réorganisation ou l'arrêt de la chaîne), Sovereign Rollup ne sera pas affecté.
La deuxième partie présentera le cumul basé. Based Rollup supprime le rôle de séquenceur et confie le pouvoir de tri des transactions aux mineurs L1, aux validateurs, aux chercheurs MEV, etc. Cela rend non seulement le tri des transactions plus décentralisé, mais simplifie également la conception et supprime de nombreux composants du système.
Cumul souverain
Couche de disponibilité des données et couche de règlement
Les cumuls classiques tels que Arbitrum, Optimism, StarkNet, etc., considèrent non seulement Ethereum (L1) comme un lieu de stockage des données (c'est-à-dire la couche de disponibilité des données), mais considèrent également Ethereum comme une couche de règlement en même temps : le règlement est effectué sur Ethereum, et l'état de L2 est (c'est-à-dire le solde de chaque adresse dans L2) est écrit sur L1.
Pourquoi avez-vous besoin d'écrire l'état L2 sur L1 ? Parce que de cette façon, L2 et L1 peuvent échanger des informations et des actifs : les dApps L1/L2 peuvent synchroniser les informations et coopérer, l'ETH de L1 peut être transféré en toute sécurité entre L1/L2, et l'ARB/OP de L2 peut également être transféré en toute sécurité entre L1/L2. transfert entre L2.
L1 peut lire l'état de L2 et peut transmettre des messages en toute sécurité, et L1/L2 peuvent communiquer entre eux *
Le cumul souverain supprime la couche de règlement (ou se transforme en couche de règlement) et utilise simplement L1 comme couche de disponibilité des données.
L1 ne lit que les données de bloc ou de transaction que Sovereign Rollup place dans L1, mais ne connaît pas le dernier état de L2, il n'y a donc aucun moyen de communiquer *
Pourquoi supprimer la couche de règlement ? Il existe différents motifs ou causes :
Comme mentionné au début, si la couche de règlement de Rollup est en L1, elle sera affectée par L1, qu'elle soit mise à niveau ou attaquée
Peut-être que L1 lui-même ne prend pas en charge les calculs complexes pour enregistrer l'état Rollup et utiliser cet état pour communiquer des actifs d'information.Par exemple, sur Celestia, vous ne pouvez que simplement mettre des données dessus, ou sur Bitcoin, vous pouvez Il ne peut effectuer que des calculs avec des capacités limitées, et un tel L1 ne peut pas devenir une couche de règlement
Peut-être que le Rollup lui-même n'a pas besoin d'une autre chaîne en tant que couche de règlement, il a ses propres jetons et écologie natifs, et n'a pas besoin d'échanger des actifs avec L1
Fonctionnement de Sovereign Rollup
Sovereign Rollup utilise simplement L1 comme couche de disponibilité des données, télécharge les données sur L1 et s'appuie sur L1 pour s'assurer que les données sont disponibles et que l'ordre des données ne changera pas. Les nœuds Sovereign Rollup s'appuient sur la lecture et l'interprétation des données sur L1 pour calculer le dernier état du Sovereign Rollup. "L'interprétation et le calcul" représentent en fait les règles de consensus et la fonction de transition d'état de Sovereign Rollup : comment filtrer les blocs et les transactions conformes au format et aux règles de Sovereign Rollup à partir des données L1, comment vérifier ces blocs et ces transactions après le filtrage, et vérifier ensuite comment exécuter ces transactions pour calculer le dernier état.
Le nœud Sovereign Rollup filtre ses propres blocs à partir des données L1, et interprète et calcule le dernier statut *
Si deux nœuds Sovereign Rollup sont de versions différentes, ils peuvent interpréter des données différentes ou calculer différents derniers états, et donc ces deux nœuds ne seront pas sur la même chaîne, ce qu'ils voient est en fait l'une des deux chaînes fourchues.
Différentes versions de nœuds peuvent avoir des statuts différents, et ils sont bifurqués vers différentes chaînes *
C'est en fait la même chose que d'exécuter différentes versions de nœuds Ethereum, les deux versions peuvent ne pas être la même chaîne. Par exemple, après le hard fork, ceux qui oublient de mettre à jour la version du nœud ou ne veulent pas mettre à jour la version du nœud resteront naturellement sur la chaîne d'origine (comme ETC, ETHPoW), tandis que ceux qui mettent à jour la version du nœud seront sur le nouvelle chaîne (ETH ).
Les lecteurs ici doivent également savoir pourquoi il s'appelle Sovereign Rollup, car dans Sovereign Rollup, chacun peut choisir la version du nœud et interpréter les données en fonction du consensus (social) de son propre groupe. S'il y a un désaccord dans la communauté Sovereign Rollup aujourd'hui comme ETHPoW vs ETH, cela signifie que chacun suit son propre chemin et choisit différentes versions de nœuds pour interpréter les données, mais les données sont toujours celles d'origine et n'ont pas changé.
*Remarque : Bien sûr, après le fork, les nœuds de leurs versions respectives téléchargeront des données conformes à leurs propres règles vers L1, puis les deux parties filtreront directement les données téléchargées par l'autre partie. *
Au milieu du temps, les nœuds suivants sont passés à la version v1.1.2, puis les blocs les uns des autres étaient indépendants *
Quels Sovereign Rollups existe-t-il ?
Il n'y a actuellement aucun exemple de Sovereign Rollups, mais comme la tendance de conception modulaire de la blockchain devient de plus en plus populaire, il y aura certainement de nombreux Sovereign Rollups. Par exemple, le cadre modulaire Rollkit que Celestia est en train de concevoir peut créer un Sovereign Rollup via le SDK Cosmos. Contrairement à la chaîne d'origine (une L1) construite à l'aide du SDK Cosmos, qui aurait besoin de mettre en œuvre le consensus Tendermint pour déterminer l'ordre des transactions, le Sovereign Rollup peut utiliser un seul séquenceur pour trier les transactions comme le Rollup commun actuel, éliminant ainsi le besoin d'un consensus multiple. nœuds et en s'appuyant sur ses problèmes de sécurité et les ressources consommées pour exécuter l'algorithme de consensus. Et le Sovereign Rollup télécharge les données de transaction sur Celestia, mais en même temps, comme il s'agit d'un Sovereign Rollup, il ne sera pas affecté par L1 (comme la mise à niveau ou l'attaque).
*Remarque 1 : Rollkit a également pris en charge ultérieurement l'utilisation de Bitcoin en tant que couche de disponibilité des données. Un tel cumul peut hériter de la sécurité de Bitcoin, mais le débit sera limité à Bitcoin. *
*Remarque 2 : Fondamentalement, les chaînes basées sur Celestia peuvent être appelées Sovereign Rollup. *
Ou supposons qu'Arbitrum n'utilise plus Ethereum comme couche de règlement, n'a plus besoin d'échanger des informations ou des actifs avec Ethereum, et considère simplement Ethereum comme un lieu de stockage de données, alors cet Arbitrum deviendra également un Sovereign Rollup.
Cumul des règlements
Il existe également des définitions telles que Settlement Rollup, mais il s'agit essentiellement d'un Sovereign Rollup, et ce Sovereign Rollup sera également la couche de règlement d'autres chaînes. C'est-à-dire que s'il existe d'autres chaînes sur un cumul souverain et que d'autres cumuls le considèrent comme une couche de règlement, ce cumul souverain peut être appelé un cumul de règlement.
*Remarque : Pour pouvoir devenir la couche de règlement d'autres chaînes, elle doit avoir des fonctions de contrat intelligent de base, afin que les deux parties puissent échanger des informations et des actifs. *
Si Ethereum est modifié pour télécharger toutes les informations de la chaîne sur Celestia aujourd'hui, alors cet Ethereum sera un Sovereign Rollup sur Celestia, et ce sera également un Settlement Rollup, car il existe de nombreuses chaînes sur Ethereum, et de nombreux Rollups le considèrent comme une couche de règlement. .
Ethereum est le Sovereign Rollup sur Celestia et aussi le Settlement Rollup
Remarque : Peut-être qu'à l'avenir, chacun se familiarisera progressivement avec la modularisation et les fonctions des différentes couches, et ne partira plus du point de vue du cumul, et des termes tels que Sovereign Rollup ou Settlement Rollup disparaîtront progressivement. Quoi qu'il en soit, l'important est de savoir comment concevoir votre chaîne (que ce soit L1, L2, L3, etc.), comment faire des compromis et choisir des outils de construction adaptés aux différentes couches.
Cumul basé
Une autre classification Rollup récemment apparue est le Rollup basé, ou connu sous le nom de Rollup séquencé L1. Based Rollup's Based fait référence au tri des transactions. Le rollup n'est pas remis à un séquenceur (ou à plusieurs séquenceurs) pour trier les transactions, mais entièrement remis aux mineurs L1, aux validateurs ou aux chercheurs MEV, etc. pour trier les transactions. Lorsque Classic Rollup télécharge des données vers L1, le contrat L1 Rollup vérifie si elles sont téléchargées par un séquenceur qualifié, tandis que Based Rollup n'a aucune restriction et n'importe qui peut les télécharger.
Tout le monde peut télécharger des blocs de cumul basé
Le plus grand avantage de Based Rollup est qu'il n'y a pas de séquenceur, donc il n'y a pas de point de défaillance unique ni même besoin de s'inquiéter du fait que Sequencer ait un pouvoir de commande de transaction complet, c'est-à-dire qu'il n'y a pas besoin de s'inquiéter du plantage de Sequencer et de l'arrêt de la chaîne. ou refuser délibérément des transactions d'utilisateurs spécifiques, ou craindre que le séquenceur ne capture de manière malveillante le MEV de l'utilisateur. Le cumul basé hérite pleinement du degré de décentralisation de L1 dans la génération de blocs.
Le cumul basé présente les avantages suivants :
Le coût pour les utilisateurs de quitter Rollup est très faible
Généralement, Rollup concevra un mécanisme Force Inclusion ou Escape Hatch afin que les utilisateurs puissent s'installer directement dans L1 sans utiliser Sequencer afin d'empêcher Sequencer de ne pas accepter intentionnellement des transactions utilisateur spécifiques ou des pannes Sequencer qui empêchent les utilisateurs de quitter Rollup. Bloc L2. Cependant, le premier coût d'une telle conception est élevé. Les utilisateurs doivent payer les frais du mineur L1 pour insérer des transactions. Le deuxième coût est que les transactions insérées à partir de L1 peuvent affecter le processus de conditionnement des blocs L2 par le séquenceur : il est possible que L1 insert La transaction invalidera la transaction que le séquenceur a l'intention de collecter dans le bloc L2. Par exemple, la transaction insérée par Alice dans L1 transfère tout l'argent à Bob, entraînant l'échec de la transaction dans laquelle Alice transfère de l'argent à Carol dans le bloc L2.
Après avoir reçu la transaction d'Alice, Sequencer confirme le résultat de la transaction et le place dans le bloc suivant
Mais Alice envoie une autre transaction directement à L1 via Force Inclusion, provoquant l'échec de la transaction Alice reçue par Sequencer
Afin d'éviter que la transaction insérée par L1 n'affecte le processus de conditionnement des blocs L2 par Sequencer, Arbitrum ne prendra pas effet immédiatement lorsque la transaction insérée par L1 doit attendre que Sequencer demande activement que la transaction soit incluse dans le dernier bloc avant il prendra effet, ou si Sequencer ne répond pas, il prendra effet après un certain temps. L'optimisme permet à la transaction de prendre effet immédiatement. Si la transaction insérée par L1 affecte la transaction dans le bloc L2, Sequencer doit trouver un moyen de la traiter. Vous pouvez lire cette introduction pour en savoir plus sur la comparaison entre Arbitrum et Optimism dans le traitement des transactions de placement L1.
Conception beaucoup plus simple
Le Rollup basé a moins le rôle de Sequencer que le Rollup général, ce qui signifie moins de charge matérielle (pas besoin de se soucier de la charge de la machine Sequencer) et tout mécanisme pour rendre les transactions de commande plus équitables (comme le mécanisme du Sequencer décentralisé). Ensuite, le mécanisme Force Inclusion/Escape Hatch n'est pas nécessaire, y compris les contrats liés à la L1 et les outils hors chaîne associés pour permettre aux utilisateurs de placer eux-mêmes des transactions dans la L1.
Mais Based Rollup a aussi quelques inconvénients :
Aucun service de confirmation de transaction à l'avance
Avec Sequencer, Sequencer peut indiquer rapidement à l'utilisateur le résultat de l'exécution de sa transaction. Tant que l'utilisateur fait confiance au séquenceur, le résultat de la transaction peut être confirmé immédiatement sans attendre que la transaction soit téléchargée sur L1.
Dans le cumul basé, Alice attend que la transaction soit téléchargée sur L1 avant de croire que sa transaction est incluse, et elle doit attendre au moins un bloc L1
En général Rollup, si Alice pense que le séquenceur acceptera sa transaction, elle peut immédiatement confirmer si la transaction sera acceptée
Le protocole perd sa source de revenus MEV
Le MEV n'est plus remis au Séquenceur pour vérification et extraction, mais à L1, donc L2 lui-même n'a aucun moyen d'obtenir les avantages du MEV. Les revenus du MEV peuvent être capturés en concevant un mécanisme d'appel d'offres pour les droits de production de blocs, mais cela augmentera relativement le seuil pour que les participants L1 participent à la production de blocs, ce qui réduira le degré de décentralisation, et l'introduction d'un mécanisme d'appel d'offres apportera également un certain degré de complexité.
Références et lectures complémentaires recommandées
Rollup Souverain
Rollup basé
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.
Un article pour comprendre le classement des Rollup
Écrit par : NIC Lin
Connaissance préalable:
Comprendre le fonctionnement du Rollup et la problématique de disponibilité des données (Data Availability) du Rollup
Récapitulatif sur le cumul
Qu'il s'agisse d'un cumul de validité ou d'un cumul optimiste, ils téléchargeront des données sur L1 (comme Ethereum), afin que tout le monde puisse accéder aux données du cumul en accédant à L1, et l'utiliser pour dériver le dernier statut du cumul, tel que Alice a 10 USDT et Bob a 5 USDT.
Ceux qui ne téléchargent pas de données vers L1 n'appartiennent pas à Rollup (comme Validium, zkPorter ou Arbitrum AnyTrust), et ils ne font pas l'objet de cet article. De plus, cet article n'abordera pas la façon dont le cumul vérifie la validité de l'état, c'est-à-dire la différence entre le cumul de validité et le cumul optimiste.
La première partie de cet article présentera Sovereign Rollup. Sovereign Rollup, comme son nom l'indique, est un Rollup avec autonomie. Les mises à niveau de version de Rollup ou les hard forks se produisent tous sur les Sovereign Rollups, contrairement aux Rollups que tout le monde connaît maintenant (ci-après dénommés Classic Rollups). L'emplacement du fork est pas sur Classic Rollup, mais sur le contrat L1 Rollup : le contrat L1 Rollup effectue des mises à jour de version via des portefeuilles multi-signatures ou un vote de gouvernance. C'est-à-dire qu'un contrat sur L1 détermine la version qu'un Rollup doit utiliser actuellement. Et s'il y a une attaque sur le Rollup en L1, comme l'attaque du mécanisme de gouvernance ou l'attaque du contrat Rollup lui-même, le Rollup sera affecté. Au contraire, parce que Sovereign Rollup considère simplement L1 comme un endroit pour stocker des données, tous les membres de Sovereign Rollup peuvent décider quelle version utiliser actuellement sous la chaîne, et peu importe ce qui arrive à L1, tant que L1 elle-même n'est pas attaquée (comme comme la réorganisation ou l'arrêt de la chaîne), Sovereign Rollup ne sera pas affecté.
La deuxième partie présentera le cumul basé. Based Rollup supprime le rôle de séquenceur et confie le pouvoir de tri des transactions aux mineurs L1, aux validateurs, aux chercheurs MEV, etc. Cela rend non seulement le tri des transactions plus décentralisé, mais simplifie également la conception et supprime de nombreux composants du système.
Cumul souverain
Couche de disponibilité des données et couche de règlement
Les cumuls classiques tels que Arbitrum, Optimism, StarkNet, etc., considèrent non seulement Ethereum (L1) comme un lieu de stockage des données (c'est-à-dire la couche de disponibilité des données), mais considèrent également Ethereum comme une couche de règlement en même temps : le règlement est effectué sur Ethereum, et l'état de L2 est (c'est-à-dire le solde de chaque adresse dans L2) est écrit sur L1.
Pourquoi avez-vous besoin d'écrire l'état L2 sur L1 ? Parce que de cette façon, L2 et L1 peuvent échanger des informations et des actifs : les dApps L1/L2 peuvent synchroniser les informations et coopérer, l'ETH de L1 peut être transféré en toute sécurité entre L1/L2, et l'ARB/OP de L2 peut également être transféré en toute sécurité entre L1/L2. transfert entre L2.
Le cumul souverain supprime la couche de règlement (ou se transforme en couche de règlement) et utilise simplement L1 comme couche de disponibilité des données.
Pourquoi supprimer la couche de règlement ? Il existe différents motifs ou causes :
Fonctionnement de Sovereign Rollup
Sovereign Rollup utilise simplement L1 comme couche de disponibilité des données, télécharge les données sur L1 et s'appuie sur L1 pour s'assurer que les données sont disponibles et que l'ordre des données ne changera pas. Les nœuds Sovereign Rollup s'appuient sur la lecture et l'interprétation des données sur L1 pour calculer le dernier état du Sovereign Rollup. "L'interprétation et le calcul" représentent en fait les règles de consensus et la fonction de transition d'état de Sovereign Rollup : comment filtrer les blocs et les transactions conformes au format et aux règles de Sovereign Rollup à partir des données L1, comment vérifier ces blocs et ces transactions après le filtrage, et vérifier ensuite comment exécuter ces transactions pour calculer le dernier état.
Si deux nœuds Sovereign Rollup sont de versions différentes, ils peuvent interpréter des données différentes ou calculer différents derniers états, et donc ces deux nœuds ne seront pas sur la même chaîne, ce qu'ils voient est en fait l'une des deux chaînes fourchues.
C'est en fait la même chose que d'exécuter différentes versions de nœuds Ethereum, les deux versions peuvent ne pas être la même chaîne. Par exemple, après le hard fork, ceux qui oublient de mettre à jour la version du nœud ou ne veulent pas mettre à jour la version du nœud resteront naturellement sur la chaîne d'origine (comme ETC, ETHPoW), tandis que ceux qui mettent à jour la version du nœud seront sur le nouvelle chaîne (ETH ).
Les lecteurs ici doivent également savoir pourquoi il s'appelle Sovereign Rollup, car dans Sovereign Rollup, chacun peut choisir la version du nœud et interpréter les données en fonction du consensus (social) de son propre groupe. S'il y a un désaccord dans la communauté Sovereign Rollup aujourd'hui comme ETHPoW vs ETH, cela signifie que chacun suit son propre chemin et choisit différentes versions de nœuds pour interpréter les données, mais les données sont toujours celles d'origine et n'ont pas changé.
*Remarque : Bien sûr, après le fork, les nœuds de leurs versions respectives téléchargeront des données conformes à leurs propres règles vers L1, puis les deux parties filtreront directement les données téléchargées par l'autre partie. *
Quels Sovereign Rollups existe-t-il ?
Il n'y a actuellement aucun exemple de Sovereign Rollups, mais comme la tendance de conception modulaire de la blockchain devient de plus en plus populaire, il y aura certainement de nombreux Sovereign Rollups. Par exemple, le cadre modulaire Rollkit que Celestia est en train de concevoir peut créer un Sovereign Rollup via le SDK Cosmos. Contrairement à la chaîne d'origine (une L1) construite à l'aide du SDK Cosmos, qui aurait besoin de mettre en œuvre le consensus Tendermint pour déterminer l'ordre des transactions, le Sovereign Rollup peut utiliser un seul séquenceur pour trier les transactions comme le Rollup commun actuel, éliminant ainsi le besoin d'un consensus multiple. nœuds et en s'appuyant sur ses problèmes de sécurité et les ressources consommées pour exécuter l'algorithme de consensus. Et le Sovereign Rollup télécharge les données de transaction sur Celestia, mais en même temps, comme il s'agit d'un Sovereign Rollup, il ne sera pas affecté par L1 (comme la mise à niveau ou l'attaque).
*Remarque 1 : Rollkit a également pris en charge ultérieurement l'utilisation de Bitcoin en tant que couche de disponibilité des données. Un tel cumul peut hériter de la sécurité de Bitcoin, mais le débit sera limité à Bitcoin. *
*Remarque 2 : Fondamentalement, les chaînes basées sur Celestia peuvent être appelées Sovereign Rollup. *
Ou supposons qu'Arbitrum n'utilise plus Ethereum comme couche de règlement, n'a plus besoin d'échanger des informations ou des actifs avec Ethereum, et considère simplement Ethereum comme un lieu de stockage de données, alors cet Arbitrum deviendra également un Sovereign Rollup.
Cumul des règlements
Il existe également des définitions telles que Settlement Rollup, mais il s'agit essentiellement d'un Sovereign Rollup, et ce Sovereign Rollup sera également la couche de règlement d'autres chaînes. C'est-à-dire que s'il existe d'autres chaînes sur un cumul souverain et que d'autres cumuls le considèrent comme une couche de règlement, ce cumul souverain peut être appelé un cumul de règlement.
*Remarque : Pour pouvoir devenir la couche de règlement d'autres chaînes, elle doit avoir des fonctions de contrat intelligent de base, afin que les deux parties puissent échanger des informations et des actifs. *
Si Ethereum est modifié pour télécharger toutes les informations de la chaîne sur Celestia aujourd'hui, alors cet Ethereum sera un Sovereign Rollup sur Celestia, et ce sera également un Settlement Rollup, car il existe de nombreuses chaînes sur Ethereum, et de nombreux Rollups le considèrent comme une couche de règlement. .
Ethereum est le Sovereign Rollup sur Celestia et aussi le Settlement Rollup
Remarque : Peut-être qu'à l'avenir, chacun se familiarisera progressivement avec la modularisation et les fonctions des différentes couches, et ne partira plus du point de vue du cumul, et des termes tels que Sovereign Rollup ou Settlement Rollup disparaîtront progressivement. Quoi qu'il en soit, l'important est de savoir comment concevoir votre chaîne (que ce soit L1, L2, L3, etc.), comment faire des compromis et choisir des outils de construction adaptés aux différentes couches.
Cumul basé
Une autre classification Rollup récemment apparue est le Rollup basé, ou connu sous le nom de Rollup séquencé L1. Based Rollup's Based fait référence au tri des transactions. Le rollup n'est pas remis à un séquenceur (ou à plusieurs séquenceurs) pour trier les transactions, mais entièrement remis aux mineurs L1, aux validateurs ou aux chercheurs MEV, etc. pour trier les transactions. Lorsque Classic Rollup télécharge des données vers L1, le contrat L1 Rollup vérifie si elles sont téléchargées par un séquenceur qualifié, tandis que Based Rollup n'a aucune restriction et n'importe qui peut les télécharger.
Tout le monde peut télécharger des blocs de cumul basé
Le plus grand avantage de Based Rollup est qu'il n'y a pas de séquenceur, donc il n'y a pas de point de défaillance unique ni même besoin de s'inquiéter du fait que Sequencer ait un pouvoir de commande de transaction complet, c'est-à-dire qu'il n'y a pas besoin de s'inquiéter du plantage de Sequencer et de l'arrêt de la chaîne. ou refuser délibérément des transactions d'utilisateurs spécifiques, ou craindre que le séquenceur ne capture de manière malveillante le MEV de l'utilisateur. Le cumul basé hérite pleinement du degré de décentralisation de L1 dans la génération de blocs.
Le cumul basé présente les avantages suivants :
Le coût pour les utilisateurs de quitter Rollup est très faible
Généralement, Rollup concevra un mécanisme Force Inclusion ou Escape Hatch afin que les utilisateurs puissent s'installer directement dans L1 sans utiliser Sequencer afin d'empêcher Sequencer de ne pas accepter intentionnellement des transactions utilisateur spécifiques ou des pannes Sequencer qui empêchent les utilisateurs de quitter Rollup. Bloc L2. Cependant, le premier coût d'une telle conception est élevé. Les utilisateurs doivent payer les frais du mineur L1 pour insérer des transactions. Le deuxième coût est que les transactions insérées à partir de L1 peuvent affecter le processus de conditionnement des blocs L2 par le séquenceur : il est possible que L1 insert La transaction invalidera la transaction que le séquenceur a l'intention de collecter dans le bloc L2. Par exemple, la transaction insérée par Alice dans L1 transfère tout l'argent à Bob, entraînant l'échec de la transaction dans laquelle Alice transfère de l'argent à Carol dans le bloc L2.
Après avoir reçu la transaction d'Alice, Sequencer confirme le résultat de la transaction et le place dans le bloc suivant
Mais Alice envoie une autre transaction directement à L1 via Force Inclusion, provoquant l'échec de la transaction Alice reçue par Sequencer
Afin d'éviter que la transaction insérée par L1 n'affecte le processus de conditionnement des blocs L2 par Sequencer, Arbitrum ne prendra pas effet immédiatement lorsque la transaction insérée par L1 doit attendre que Sequencer demande activement que la transaction soit incluse dans le dernier bloc avant il prendra effet, ou si Sequencer ne répond pas, il prendra effet après un certain temps. L'optimisme permet à la transaction de prendre effet immédiatement. Si la transaction insérée par L1 affecte la transaction dans le bloc L2, Sequencer doit trouver un moyen de la traiter. Vous pouvez lire cette introduction pour en savoir plus sur la comparaison entre Arbitrum et Optimism dans le traitement des transactions de placement L1.
Conception beaucoup plus simple
Le Rollup basé a moins le rôle de Sequencer que le Rollup général, ce qui signifie moins de charge matérielle (pas besoin de se soucier de la charge de la machine Sequencer) et tout mécanisme pour rendre les transactions de commande plus équitables (comme le mécanisme du Sequencer décentralisé). Ensuite, le mécanisme Force Inclusion/Escape Hatch n'est pas nécessaire, y compris les contrats liés à la L1 et les outils hors chaîne associés pour permettre aux utilisateurs de placer eux-mêmes des transactions dans la L1.
Mais Based Rollup a aussi quelques inconvénients :
Aucun service de confirmation de transaction à l'avance
Avec Sequencer, Sequencer peut indiquer rapidement à l'utilisateur le résultat de l'exécution de sa transaction. Tant que l'utilisateur fait confiance au séquenceur, le résultat de la transaction peut être confirmé immédiatement sans attendre que la transaction soit téléchargée sur L1.
Dans le cumul basé, Alice attend que la transaction soit téléchargée sur L1 avant de croire que sa transaction est incluse, et elle doit attendre au moins un bloc L1
En général Rollup, si Alice pense que le séquenceur acceptera sa transaction, elle peut immédiatement confirmer si la transaction sera acceptée
Le protocole perd sa source de revenus MEV
Le MEV n'est plus remis au Séquenceur pour vérification et extraction, mais à L1, donc L2 lui-même n'a aucun moyen d'obtenir les avantages du MEV. Les revenus du MEV peuvent être capturés en concevant un mécanisme d'appel d'offres pour les droits de production de blocs, mais cela augmentera relativement le seuil pour que les participants L1 participent à la production de blocs, ce qui réduira le degré de décentralisation, et l'introduction d'un mécanisme d'appel d'offres apportera également un certain degré de complexité.
Références et lectures complémentaires recommandées