De la théorie à la pratique : analyser le mécanisme d'Ethereum Rollup pour mettre en œuvre des transactions résistantes à la censure

Titre original : "Introduction au mécanisme d'inclusion de force de Rollup"

Auteur : NIC Lin, responsable du Meetup Ethereum de Taipei

Hier encore, quelque chose s'est produit qui a choqué d'innombrables personnes : Linea, la deuxième couche d'Ethereum lancée par la société mère Metamask, Consensys, a été fermée de manière proactive. Les responsables ont déclaré que le but était de réduire l'impact de l'incident de piratage de Velocore. Et cela ne peut que rappeler aux gens la précédente fermeture de BSC Chain (BNB Chain) sous coordination officielle afin de réduire les pertes dues aux attaques de pirates. Chaque fois que les gens parlent de ce genre de choses, ils doutent de la valeur décentralisée prônée par Web3.

Bien entendu, la raison principale des incidents mentionnés ci-dessus réside davantage dans l’imperfection de l’infrastructure elle-même, c’est-à-dire dans une décentralisation insuffisante : si une chaîne est suffisamment décentralisée, elle ne doit pas s’arrêter d’un seul coup. En raison de la structure unique de la deuxième couche d'Ethereum, la plupart de la couche 2 repose sur le séquenceur centralisé. Bien qu'il y ait eu de plus en plus d'arguments en faveur des séquenceurs décentralisés ces dernières années, compte tenu de l'objectif de la deuxième couche et de sa structure, nous l'avons probablement. On peut considérer que le trieur de couche 2 ne sera probablement pas très décentralisé, et pourrait ne pas être aussi décentralisé que la chaîne BSC au final. Si tel est effectivement le cas, que devons-nous faire ?

En fait, pour la deuxième couche, le préjudice le plus direct causé par la non-décentralisation du trieur réside dans sa résistance et son activité à la censure. S'il n'y a que quelques entités (séquenceurs) qui traitent les transactions, alors elles ont le pouvoir absolu de vous servir : elles peuvent vous rejeter s'elles le souhaitent, et vous n'aurez peut-être pas le choix. Comment résoudre le problème anti-censure de la couche 2 est évidemment un sujet important.

Au cours des dernières années, les principales secondes couches d'Ethereum ont proposé diverses solutions aux problèmes d'anti-censure, telles que Loopring et Degate, les fonctions de retrait forcé et de trappe d'évacuation de StarkEx, ainsi que la fonction d'inclusion forcée d'Arbitrum et d'autres OP Rollup, ces méthodes peuvent créer des contrôles. et se solde sur le Séquenceur sous certaines conditions pour l'empêcher de rejeter la demande de transaction d'un utilisateur sans raison.

Dans l'article d'aujourd'hui, NIC Lin de la Taipei Ethereum Association donne son propre récit, a personnellement expérimenté les fonctions de transaction résistantes à la censure de quatre Rollups traditionnels et a analysé en profondeur la conception du mécanisme de Force Inclusion sous des aspects tels que le flux de travail et les méthodes de fonctionnement, qui sont très important pour Ethereum, il est particulièrement précieux pour la communauté et les grands investisseurs disposant d’énormes actifs.

Examen des transactions et inclusion forcée

La résistance à la censure des transactions (Censorship Resistance) est très importante pour une blockchain. Si la blockchain peut arbitrairement examiner et rejeter les transactions initiées par les utilisateurs, ce ne sera pas différent d'un serveur Web2. La résistance actuelle des transactions d'Ethereum à la censure vient de son grand nombre de validateurs. Si quelqu'un veut examiner les transactions de Bob et empêcher que ses transactions soient téléchargées sur la chaîne, il doit soit essayer de soudoyer la plupart des validateurs du réseau, soit envoyer du spam à l'ensemble. réseau. Envoyez en continu des transactions indésirables avec des frais de traitement plus élevés que Bob pour capturer de l'espace de bloc. Quoi qu’il en soit, le coût sera très élevé.

Remarque : dans la structure PBS actuelle d'Ethereum, le coût d'examen des transactions sera considérablement réduit. Vous pouvez vous référer à la proportion de blocs qui coopèrent avec l'OFAC pour examiner les transactions Tornado Cash. La résistance actuelle à la censure s’appuie sur des vérificateurs et des relais indépendants en dehors de la juridiction de l’OFAC et du gouvernement.

Mais qu’en est-il du Rollup ? Rollup ne nécessite pas un grand nombre de validateurs pour assurer la sécurité Même si Rollup n'a qu'un seul rôle centralisé (Sequencer) pour générer des blocs, il est aussi sécurisé que L1. Mais la sécurité et la résistance à la censure sont deux choses différentes. Même si un Rollup est aussi sécurisé qu'Ethereum, avec un seul séquenceur centralisé, les transactions de n'importe quel utilisateur peuvent être censurées.

Sequencer peut refuser de traiter la transaction de l'utilisateur, ce qui entraîne la retenue des fonds de l'utilisateur et son incapacité à quitter le Rollup.

Mécanisme d’inclusion forcée

Plutôt que d’exiger que Rollup dispose d’un grand nombre de Séquenceurs décentralisés, il est préférable d’utiliser directement les capacités anti-censure de L1 :

À l'origine, Sequencer consiste à regrouper les données de transaction et à les envoyer au contrat Rollup L1. Il est préférable d'ajouter une conception au contrat afin que les utilisateurs puissent insérer eux-mêmes des transactions dans le contrat Rollup. Ce mécanisme est appelé « Forcer l'inclusion ». Tant que Sequencer ne peut pas censurer les utilisateurs au niveau L1, il ne peut pas empêcher les utilisateurs d'insérer de force des transactions au niveau L1. De cette manière, Rollup peut hériter de la résistance à la censure de L1.

Le séquenceur ne peut pas examiner les transactions L1 de l'utilisateur sans payer un coût élevé

Comment les transactions forcées devraient-elles prendre effet ?

Si les transactions peuvent être écrites directement dans le contrat de cumul via Forcer l'inclusion (c'est-à-dire avec effet immédiat), le statut du cumul changera immédiatement. Par exemple, Bob insère une transaction de « transfert de 1 000 DAI à Carol » via Forcer l'inclusion. Si la transaction prend effet immédiatement, le solde de Bob dans le dernier état sera de 1 000 DAI de moins et celui de Carol sera de 1 000 DAI de plus.

Si Force Inclusion peut directement écrire la transaction dans le contrat Rollup et prendre effet immédiatement, le statut changera immédiatement.

Si le séquenceur collecte également des transactions hors chaîne à ce moment-là et envoie le prochain lot de transactions au contrat Rollup, il peut être affecté par les transactions que Bob insère de force et prendre effet immédiatement. Ce type de problème doit être évité autant que possible, de sorte que le rollup ne fait généralement pas prendre effet immédiatement à la transaction Forcer l'inclusion, mais permet d'abord à l'utilisateur d'insérer la transaction dans la file d'attente sur L1 et d'entrer dans l'état « en préparation ». .

Lorsque Sequencer regroupe les transactions hors chaîne et les envoie au contrat Rollup, il choisit d'insérer ou non les transactions susmentionnées dans la séquence de transactions. Si Sequencer a ignoré ces transactions dans l'état « préparation », après la fin de la période de fenêtre, l'utilisateur. peut forcer ces transactions. Insérer dans le contrat Rollup.

Le séquenceur peut décider quand "recevoir accidentellement" les transactions en attente dans la file d'attente

Le séquenceur peut toujours refuser de traiter les transactions dans la file d'attente.

Si le séquenceur refuse pendant une longue période, après un certain temps, n'importe qui peut forcer la transaction dans le contrat Rollup via la fonction Forcer l'inclusion.

Ensuite, nous présenterons dans l'ordre la mise en œuvre du mécanisme Force Inclusion de quatre Rollup bien connus, dont Optimism, Arbitrum, StarkNet et zkSync.

Le mécanisme d’inclusion de force d’Optimism

Tout d'abord, nous présenterons le processus de dépôt d'Optimism. Ce dépôt fait non seulement référence au dépôt d'argent dans Optimism, mais inclut également « l'envoi des informations envoyées par l'utilisateur à L2 » à L2. Après avoir reçu le message nouvellement déposé, le nœud L2 convertira le message en une transaction L2 pour exécution et l'enverra au destinataire désigné du message.

Message de l'utilisateur du dépôt L1 vers L2

Contrat L1CrossDomainMessenger

Lorsqu'un utilisateur souhaite déposer des jetons ETH ou ERC-20 dans Optimism, il interagira avec le contrat L1StandardBridge sur L1 via la page Web frontale, spécifiant le montant à déposer et quelle adresse L2 pour recevoir ces actifs.

Le contrat L1StandardBridge transmettra le message au contrat L1CrossDomainMessenger de niveau suivant. Ce contrat est principalement utilisé comme composant de communication entre L1 et L2. Il communique avec le L2StandardBridge sur L2 via ce composant de communication général pour décider qui peut lancer le jeton dans L2. .pièces, ou qui peut débloquer des jetons de L1.

Si un développeur a besoin de développer un contrat qui communique et synchronise le statut entre L1 et L2, il peut alors le construire sur le contrat L1CrossDomainMessenger.

Le message de l'utilisateur est transmis de L1 à L2 via le contrat CrossDomainMessenger

Remarque : Dans certaines images de cet article, CrossDomainMessager est écrit sous la forme CrossChainMessager.

Contrat du portail Optimisme

Le contrat L1CrossDomainMessenger enverra ensuite le message au contrat OptimismPortal de niveau le plus bas. Après le traitement, le contrat OptimismPortal lancera un événement appelé TransactionDeposited. Les paramètres incluent « la personne qui a envoyé le message », « la personne qui a reçu le message ». et les paramètres d'exécution associés.

Ensuite, le nœud L2 Optimism écoutera l'événement Transaction Deposited lancé par le contrat OptimismPortal et convertira les paramètres de l'événement en une transaction L2. L'initiateur de cette transaction sera « l'expéditeur du message » spécifié dans le paramètre de l'événement Transaction Deposited. le récepteur de transaction est la « personne qui reçoit le message » dans les paramètres de l'événement, et d'autres paramètres de transaction sont également dérivés des paramètres des événements ci-dessus.

Le nœud L2 convertira le paramètre d'événement Transaction Deposited d'OptimismPortalemit en une transaction L2

Par exemple, il s'agit d'une transaction dans laquelle un utilisateur dépose 0,01ETH via le contrat L1StandardBridge. Ce message et l'ETH sont transmis jusqu'au contrat OptimismPortal (l'adresse est 0xbEb5...06Ed), puis convertis en L2. transaction quelques minutes plus tard :

L'initiateur du message est le contrat L1CrossDomainMessenger ; le destinataire est le contrat L2CrossDomainMessenger sur L2 ; le contenu du message est que L1StandardBridge a reçu le dépôt de 0,01 ETH de BoB. Après cela, certains processus seront déclenchés, comme l'émission de 0,01 ETH supplémentaires à L2StandardBridge, qui seront ensuite transférés à Bob.

Comment le déclencher spécifiquement

Lorsque vous souhaitez forcer une transaction dans le contrat Rollup d'Optimism, l'effet que vous souhaitez obtenir est de permettre à une « transaction initiée et exécutée sur L2 à partir de votre adresse L2 » d'être exécutée en douceur. À ce stade, vous devez utiliser votre adresse L2. soumet le message directement au contrat OptimismPortal (notez que le contrat OptimismPortal est en fait sur L1, mais le format d'adresse de l'OP est le même que le format d'adresse L1. Vous pouvez appeler directement le contrat ci-dessus en utilisant le compte L1 avec la même adresse que le compte L2).

L'« initiateur » de la transaction L2 convertie par l'événement Transaction Deposited lancé par le contrat sera votre compte L2. À ce stade, le format de la transaction est cohérent avec la transaction L2 normale.

Dans la transaction L2 convertie à partir de l'événement Transaction Deposited, l'initiateur sera Bob lui-même ; le destinataire est le contrat Uniswap et il sera accompagné de l'ETH spécifié, tout comme Bob lui-même a initié la transaction L2 ;

Si vous souhaitez appeler la fonction Force Inclusion d'Optimism, vous devez appeler directement la fonction depositTransaction du contrat OptimismPortal et renseigner les paramètres de la transaction que vous souhaitez exécuter en L2.

J'ai fait une simple expérience Forcer l'inclusion. Cette transaction voulait accomplir une chose : utiliser mon adresse pour effectuer un auto-transfert sur L2 (0xeDc1...6909), et j'ai joint un message texte de "forcer l'inclusion".

Il s'agit de la transaction L1 dans laquelle j'exécute la fonction depositTransaction via le contrat OptimismPortal. Vous pouvez voir que dans l'événement Transaction Deposited, elle est lancée à la fois depuis et vers moi-même.

Les valeurs de la colonne de données opaque restante codent "la quantité d'ETH fournie avec la personne qui appelle la fonction de transaction de dépôt", "la quantité d'ETH que l'initiateur de la transaction L2 souhaite envoyer au destinataire", "la transaction L2 GasLimit" et " aux données du récepteur L2" et d'autres informations.

Après avoir décodé les informations ci-dessus, vous obtiendrez :

« Combien d'ETH a été attaché par la personne qui a appelé la transaction de dépôt : 0, car je n'ai pas déposé d'ETH de L1 à L2 ;

"Combien d'ETH l'initiateur de la transaction L2 souhaite-t-il envoyer au destinataire" : 5566 (wei)

"GasLimit pour les transactions L2" : 50 000

"Données pour le récepteur L2" : 0x666f72636520696e636c7573696f6e, qui est le codage hexadécimal de la chaîne "forcer l'inclusion"

Peu de temps après, la transaction L2 convertie est apparue : une transaction L2 dans laquelle je me suis transféré de l'argent, le montant était de 5 566 wei et les données étaient la chaîne « forcer l'inclusion ». Et vous pouvez remarquer que le TxnType (type de transaction) dans Autres attributs dans l'avant-dernière ligne de l'image montre la transaction système 126 (Système), ce qui signifie que cette transaction n'a pas été initiée par moi en L2, mais a été déposée par la transaction L1. . Les événements sont transformés.

Transaction L2 convertie

Si vous souhaitez appeler le contrat L2 et envoyer différentes données via Force Inclusion, il suffit de remplir les paramètres un par un dans la fonction de transaction de dépôt précédente. N'oubliez pas d'utiliser la même adresse L1 que votre compte L2 pour appeler le. fonction de transaction de dépôt, de sorte que lorsque l'événement déposé est converti en transaction L2, l'initiateur est votre compte L2.

Fenêtre Séquenceur

Le nœud Optimism L2 mentionné précédemment convertit l'événement Transaction Deposited en une transaction L2. En fait, ce nœud Optimism fait référence au séquenceur. Après tout, cela est lié au séquençage des transactions, donc seul le séquenceur peut décider quand convertir l'événement susmentionné en. une transaction L2.

Lors de l'écoute de l'événement TransactionDeposited, le Sequencer ne convertit pas nécessairement immédiatement l'événement en transaction L2. Il peut y avoir un délai. La valeur maximale de cette période est appelée SequencerWindow.

La fenêtre actuelle du séquenceur sur le réseau principal Optimism est de 24 heures, c'est-à-dire que lorsqu'un utilisateur dépose une somme d'argent depuis L1 ou force l'inclusion d'une transaction, le pire des cas est qu'elle soit incluse dans l'historique des transactions L2 après 24 heures.

Mécanisme d’inclusion de force d’Arbitrum

Dans Optimism, l'opération Deposit de L1 lancera un événement Transaction Deposited, et le reste consiste à attendre que le séquenceur collecte les opérations ci-dessus, mais dans Arbitrum, les opérations qui se produisent dans L1 (économiser de l'argent ou envoyer des messages à L2, etc.) .) sera stocké dans L1 dans une file d'attente, plutôt que de simplement lancer un événement.

Le séquenceur disposera d'un délai pour inclure les transactions dans la file d'attente ci-dessus dans l'historique des transactions L2. Si le séquenceur ne fait rien une fois le temps écoulé, n'importe qui peut le terminer pour le séquenceur.

Arbitrum maintiendra une file d'attente dans le contrat L1. Si le séquenceur ne traite pas activement les transactions dans la file d'attente, lorsque le temps est écoulé, n'importe qui peut forcer les transactions dans la file d'attente à être incluses dans l'historique des transactions L2.

Dans la conception d'Arbitrum, les opérations telles que les dépôts effectués sur L1 doivent passer par le contrat Delayed Inbox. Comme son nom l'indique, les opérations ici seront retardées pour prendre effet. Le séquenceur télécharge les transactions L2 vers L1. Chaque fois que le séquenceur télécharge une transaction L2, il peut supprimer certaines transactions en attente de la boîte de réception différée et les écrire dans l'historique des transactions.

Lorsque Sequencer écrit une nouvelle transaction, il peut retirer la transaction de DelayedInbox et l'écrire ensemble.

Des conceptions complexes et de nombreux documents de référence

Si les lecteurs se réfèrent directement au chapitre officiel d'Arbitrum sur le séquenceur et l'inclusion de force, ils verront qu'il mentionne le fonctionnement approximatif de Force Inclusion, ainsi que certains noms de paramètres et noms de fonctions :

L'utilisateur accède d'abord au contrat DelayedInbox pour appeler la fonction sendUnsignedTransaction. Si le Sequencer n'est pas inclus dans un délai d'environ 24 heures, l'utilisateur peut appeler la fonction forceInclusion du contrat SequencerInbox. Ensuite, le responsable d'Arbitrum n'a pas joint le lien de la fonction vers le document du site officiel, vous ne pouvez donc consulter que la fonction correspondante dans le code du contrat.

Lorsque vous trouvez la fonction sendUnsignedTransaction, vous constatez que vous devez remplir vous-même la valeur occasionnelle et la valeur maxFeePerGas. Quelle adresse est l'occasion ? Sur quel réseau se trouve maxFeePerGas ? Quelle est la meilleure façon de le remplir ? Il n'y a aucune référence de fichier, pas même Natpsec. Ensuite, vous trouverez également un tas de fonctions d'apparence similaire dans le contrat Arbitrum :

SendL1FundedUnsignedTransaction, sendUnsignedTransactionToFork, sendContractTransaction, sendL1FundedContractTransaction, il n'existe aucun document vous expliquant la différence entre ces fonctions, comment les utiliser, comment renseigner les paramètres, pas même Natpsec.

Vous essayez de remplir les paramètres et d'envoyer la transaction avec la mentalité de l'essayer. Vous souhaitez utiliser des essais et des erreurs pour voir si vous pouvez trouver l'utilisation correcte, mais vous constatez que ces fonctions effectuent toutes un AddressAliasing sur votre adresse L1. , entraînant l'erreur finale sur L2. L'expéditeur lors du lancement de la transaction est simplement une adresse différente, donc votre adresse L2 reste immobile.

envoyerL2Message

Plus tard, j'ai accidentellement cliqué sur la recherche Google et découvert qu'Arbitrum dispose d'une bibliothèque de didacticiels, qui contient des scripts qui montrent comment envoyer des transactions L2 à partir de L1 (ce que signifie Forcer l'inclusion), et les fonctions qui y sont répertoriées ne font partie des fonctions mentionnées ci-dessus, mais une fonction appelée sendL2Message, et le paramètre message est en fait une transaction signée avec le compte L2 ?

Qui aurait su que le « message envoyé à L2 via Force Inclusion » serait en réalité une « transaction L2 signée » ? Et il n'existe aucune documentation ni Natspec expliquant quand et comment utiliser cette fonction.

Conclusion : il est difficile de générer manuellement une transaction forcée Arbitrum. Il est recommandé de suivre le didacticiel officiel et d'exécuter le SDK Arbitrum. Contrairement aux autres Rollups, Arbitrum dispose d'une documentation claire pour les développeurs et de notes de code. L'objectif et les paramètres de nombreuses fonctions manquent d'explications, ce qui oblige les développeurs à passer plus de temps que prévu pour y accéder et les utiliser. J'ai également interrogé les gens d'Arbitrum sur Arbitrum Discord mais je n'ai pas obtenu de réponse satisfaisante.

Lorsque j'ai posé la question sur Discord, l'autre partie m'a seulement demandé de regarder sendL2Message. Ils n'ont pas voulu expliquer les fonctions des autres fonctions (même sendUnsignedTransaction mentionné dans le document Force Inclusion), à quoi elles servent, comment les utiliser. , et quand les utiliser.

Le mécanisme ForceInclusion de StarkNet

Malheureusement, StarkNet ne dispose actuellement pas de mécanisme ForceInclusion. Il n'y a que deux articles traitant de la censure et de la ForceInclusion sur le forum officiel.

Impossible de prouver l'échec de la transaction

La raison ci-dessus est en fait due au fait que le système de preuve sans connaissance de StarkNet ne peut pas prouver l'échec d'une transaction, donc l'inclusion forcée ne peut pas être autorisée. Parce que si quelqu'un par malveillance (ou involontairement) force l'inclusion d'une transaction échouée qui ne peut pas être prouvée, StarkNet sera directement bloqué : car une fois la transaction incluse de force, Prover doit prouver l'échec de la transaction, mais il n'a aucun moyen de le prouver.

StarkNet prévoit d'introduire la fonction de preuve des transactions ayant échoué dans la version v0.15.0, et il devrait ensuite être possible d'implémenter davantage le mécanisme Forcer l'inclusion.

Mécanisme ForceInclusion de zkSync

La transmission des messages L1-> L2 de zkSync et le mécanisme d'inclusion forcée sont tous effectués via la fonction requestL2Transaction du contrat MailBox. L'utilisateur spécifie l'adresse L2, les données d'appel, le montant ETH supplémentaire, la valeur L2GasLimit, etc. requestL2Transaction combinera ces paramètres dans un L2. la transaction est ensuite placée dans la file d'attente prioritaire (PriorityQueue). Lorsque la transaction est empaquetée et téléchargée sur L1 (via la fonction commitBatches), le séquenceur indiquera le nombre de transactions à retirer de la file d'attente prioritaire et les inclura dans l'enregistrement de transaction L2. .

zkSync est très similaire à Optimism sous la forme d'inclusion forcée. Il utilise l'adresse L2 de l'initiateur (cohérente avec l'adresse L1) pour appeler les fonctions associées et remplir les données (appelé, données d'appel, etc.), plutôt que comme Arbitrum Fill. dans une transaction L2 signée ; mais la conception est la même que celle d'Arbitrum, les deux maintiennent une file d'attente dans L1, et le séquenceur retire les transactions en attente soumises directement par l'utilisateur de la file d'attente et les écrit dans le milieu de l'historique des transactions.

Si vous accédez au dépôt ETH via le pont officiel de zkSync, comme cette transaction, il appelle la fonction requestL2Transaction du contrat MailBox. Il placera la transaction L2 de dépôt ETH dans la file d'attente prioritaire et lancera un événement NewPriorityRequest. Étant donné que le contrat encode les données de la transaction L2 dans une chaîne d'octets, il est difficile à lire si vous regardez les paramètres de cette transaction L1, vous verrez que le destinataire de L2 dans les paramètres est également l'initiateur de la transaction (. car elle est déposée sur vous-même), donc après un certain temps, lorsque cette transaction L2 est retirée de la file d'attente prioritaire par Sequencer et incluse dans l'historique des transactions, elle sera convertie en une transaction transférée à elle-même sur L2, et le montant de le transfert est le dépôt de l'initiateur de la transaction en L1. Le montant d'ETH transporté dans la transaction ETH.

Dans la transaction L1Deposit, l'initiateur et le destinataire de la transaction sont tous deux 0xeDc1...6909, le montant est de 0,03ETH et les données d'appel sont vides.

Il y aura une transaction de 0xeDc1...6909 vous transférant de l'argent sur L2. Le type de transaction (TxnType) est 255, qui est une transaction système.

Ensuite, j'ai directement appelé la fonction requestL2Transaction de zkSync et envoyé un auto-transfert comme je l'avais fait auparavant lorsque j'ai expérimenté la fonction de transaction forcée de l'OP : sans aucun ETH, les données d'appel introduisaient le codage HEX de la chaîne "forcer l'inclusion".

Ensuite, il est converti en dernière transaction de L2 pour lui-même. Les données d'appel sont la chaîne hexadécimale de "forcer l'inclusion": 0x666f72636520696e636c7573696f6e.

Lorsque le séquenceur retire la transaction de PriorityQueue et l'écrit dans l'historique des transactions, elle sera convertie en transaction L2 correspondante sur L2.

Grâce à la fonction requestL2Transaction, les utilisateurs peuvent utiliser le compte L1 avec la même adresse L2 pour soumettre des informations en L1, en spécifiant le destinataire L2, le montant ETH associé et les données d'appel. Si l'utilisateur souhaite appeler d'autres contrats avec des données différentes, il fait de même en remplissant les paramètres un par un dans la fonction requestL2Transaction.

Il n'existe aucune fonction permettant aux utilisateurs de forcer l'inclusion

Bien qu'une fois la transaction L2 placée dans la file d'attente prioritaire, la période d'attente pour que la transaction L2 soit incluse dans le séquenceur sera calculée accidentellement. Cependant, la conception actuelle de zkSync n'a pas de fonction Forcer l'inclusion que les utilisateurs peuvent appliquer, ce qui est le cas. équivalent à seulement un demi-ensemble. C'est-à-dire que bien qu'il y ait un « délai d'attente pour l'inclusion », il s'agit en fait toujours de « voir si le Séquenceur souhaite recevoir des revenus » : le Séquenceur peut attendre son expiration avant de recevoir la transaction, ou il ne peut jamais recevoir de transactions. dans la file d'attente prioritaire.

À l'avenir, zkSync devrait ajouter des fonctions associées afin que les utilisateurs puissent forcer l'inclusion de la transaction dans l'historique des transactions L2 lorsque la période de validité des revenus est dépassée mais n'a pas été incluse dans le séquenceur. Il s'agit d'un mécanisme d'inclusion forcée vraiment efficace.

Résumer

L1 s'appuie sur un grand nombre de validateurs pour assurer la « sécurité » et la « résistance à la censure » du réseau. Rollup utilise un petit nombre voire un seul séquenceur pour écrire des transactions, et sa résistance à la censure est encore plus faible. Par conséquent, Rollup a besoin d'un mécanisme d'inclusion forcée pour permettre aux utilisateurs de contourner Sequencer et d'écrire les transactions dans l'historique afin d'éviter d'être examinées par Sequencer et de rendre impossible l'utilisation et le retrait de fonds du Rollup.

Forcer l'inclusion permet aux utilisateurs de forcer l'écriture des transactions dans l'historique, mais dans la conception, ils doivent choisir si la transaction peut être immédiatement insérée dans l'historique et prendre effet immédiatement. Si les transactions sont autorisées à prendre effet immédiatement, cela aura un impact négatif sur le séquenceur, car les transactions en attente de réception sur L2 peuvent être affectées par des transactions reçues de force par L1.

Par conséquent, le mécanisme actuel de force d'inclusion de Rollup mettra d'abord les transactions insérées sur L1 dans un état d'attente, et donnera au séquenceur un délai pour réagir et choisir d'inclure ou non ces transactions en attente.

zkSync et Arbitrum maintiennent une file d'attente en L1 pour gérer les transactions L2 envoyées par les utilisateurs de L1 ou les messages vers L2. Arbitrum s'appelle DelayedInbox ; zkSync s'appelle PriorityQueue ;

Cependant, la façon dont zkSync envoie les transactions L2 est similaire à celle d'Optimism, qui utilise l'adresse L2 pour envoyer des messages à L1. Après la conversion en transaction L2, l'initiateur sera l'adresse L2. La fonction d'Optimism pour envoyer des transactions L2 est appelée depositTransaction ; zkSync est appelée requestL2Transaction. Arbitrum génère et signe une transaction L2 complète, puis l'envoie via la fonction sendL2Message. Arbitrum restaurera le signataire via la signature sur L2 en tant qu'initiateur de la transaction L2.

StarkNet n'a actuellement pas de mécanisme d'inclusion forcée ; zkSync est comme un demi-ensemble de Force Inclusion - il existe une PriorityQueue et chaque transaction L2 dans la file d'attente a une date d'expiration d'inclusion, mais cette date d'expiration n'est actuellement qu'à des fins de décoration. Le séquenceur peut choisir de ne pas inclure du tout de transactions L2 dans PriorityQueue