Introduction au mécanisme d'inclusion de force de Rollup

Auteur original : NIC Lin
Source originale : support
Que la force soit avec toi. Cet article présentera le mécanisme anti-censure des transactions de Rollup - Forcer l'inclusion, et utilisera la conception et la pratique de plusieurs Rollups célèbres comme exemples.
Photo par Artur Tumasjan sur Unsplash
Connaissances préalables :
Savoir comment fonctionne le Rollup et pourquoi le Rollup doit télécharger les transactions vers L1
Résistance à la censure des transactions
La capacité des transactions à résister à la censure (résistante à la censure) est très importante pour une blockchain. Si une blockchain peut effectuer des transactions pour n'importe quel utilisateur censuré, alors cette blockchain n'est pas différente d'un serveur Web2. La résistance actuelle des transactions d'Ethereum à la censure vient du grand nombre de validateurs. Si Alice veut examiner les transactions de Bob et empêcher que ses transactions soient téléchargées sur la chaîne, alors Alice devra essayer de soudoyer tous les validateurs du réseau, sinon elle le sera. L'ensemble du réseau de messagerie continue d'envoyer des transactions de spam supérieures aux transactions de Bob pour remplir les blocs. Quoi qu’il en soit, ses coûts seront très élevés.
Remarque : Dans l’architecture PBS actuelle d’Ethereum, le coût de la révision a en effet été considérablement réduit. Vous pouvez vous référer à la révision par l’OFAC de la proportion de blocs dans 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 des Rollups ? Rollup ne nécessite pas un grand nombre de validateurs pour assurer sa sécurité. De plus, Rollup n'a qu'un rôle centralisé (Sequencer, appelé séquenceur ou séquenceur) pour batcher les blocs, et il est aussi sécurisé que L1. Mais la sécurité et la résistance à la censure sont deux choses différentes. Construire un Rollup est aussi sécurisé qu'Ethereum, mais il ne dispose que d'un séquenceur centralisé. Le séquenceur peut ensuite examiner les transactions de n'importe quel utilisateur s'il le souhaite.
Sequencer peut refuser de recevoir des transactions utilisateur, ce qui empêche les utilisateurs d'utiliser ou de quitter Rollup.
mécanisme d'inclusion forcée
En même temps, Rollup doit avoir autant de validateurs que L1 pour assurer la résistance à la censure. Il est préférable d'utiliser directement la résistance à la censure de L1 : le séquenceur compresse également les données de transaction dans le contrat Rollup de L1. une fonction dans le contrat Rollup pour surveiller les utilisateurs. Vous pouvez également insérer des transactions dans le tri. Cette méthode est appelée inclusion forcée. Tant que Sequencer ne peut pas examiner les « transactions L1 » des utilisateurs surveillés, il ne peut pas empêcher les utilisateurs d'insérer de force des transactions Rollup via L1, et le fonctionnement et la sécurité de Rollup sont basés sur les capacités anti-censure de L1.
Le séquenceur ne peut pas revoir les transactions L1 de l'utilisateur sauf en cas de coût très complexe
Remarque : L'inclusion forcée n'est possible que si le Rollup est conçu. Les utilisateurs peuvent définitivement franchir L1 et insérer de force des transactions Rollup. Si Rollup ne fournit pas de mécanisme d'inclusion forcée, les utilisateurs ne peuvent que prier pour que l'examen du séquenceur ne s'échange pas d'eux-mêmes.
La transaction prend effet immédiatement plutôt qu'un effet différé
Si nous permettons aux transactions insérées via Force Inclusion d'être directement écrites dans l'historique des transactions du Rollup (avec effet immédiat), alors le statut du Rollup sera modifié immédiatement. Par exemple, Bob insère un stylo via le mécanisme Force Inclusion "Il a transféré 1000 DAI. à la transaction "Carol", si la transaction prend effet immédiatement, alors le solde de Bob dans le dernier état sera de 1 000 DAI de moins et Carol sera de 1 000 DAI de plus (bien sûr, le principe est que le solde de Bob dépasse 1 000 DAI).
Si la transaction de Bob peut être directement écrite dans l'historique des transactions et prendre effet immédiatement, alors le statut du Rollup changera immédiatement.
Si le séquenceur collecte des transactions hors chaîne à ce moment-là et attend que la prochaine transaction soit envoyée au contrat Rollup, il peut être affecté par la transaction que Bob insère de force et prend effet immédiatement. Par exemple, Bob n'a qu'à envoyer à l'avance une transaction de paiement de type "il" transfère 1 000 DAI à Alice" à Sequencer. Sequencer équivaut à vérifier qu'il n'y a pas de problème et à promettre de recevoir un revenu. Alice et Bob peuvent demander à Sequencer si la transaction sera reçue et calculera le résultat du dernier statut (Alice a 1000 DAI de plus et Bob a 1000 DAI de moins). Mais lorsque le séquenceur a découvert que Bob s'était précipité pour insérer de force la transaction, le statut d'exécution des transactions entre ses mains avait changé, il savait que la transaction « Bob a transféré 1 000 DAI à Alice » était devenue un échec d'exécution, et Alice ne pouvait pas. obtenez-le à 1000 DAI.
Le séquenceur reçoit la transaction de Bob, donc Alice pense qu'elle recevra 1 000 DAI
En conséquence, Bob a directement forcé la réception d'une autre transaction conflictuelle sur L1, empêchant la réception de la transaction dans la main de Sequencer, et Alice n'a pas pu obtenir le DAI.
Cela peut ne pas être une bonne expérience utilisateur, donc Rollup fait généralement prendre effet immédiatement la transaction d'inclusion forcée, mais fait passer la transaction à un état de « préparation ». Le Séquenceur peut choisir d'ajouter ou non les transactions qui entrent dans l'état "en préparation" à la fin du lot lors de l'envoi de la transaction budgétaire. Si le Séquenceur ne souhaite jamais traiter ces états "en préparation", alors ces transactions seront traitées après un délai. Après un certain temps, il peut être inséré de force dans l'historique des transactions.
Bob veut tromper Alice en forçant la transaction de revenus, mais en fait, la transaction sera d'abord mise en file d'attente
Le séquenceur peut décider lui-même quand "inclure" les transactions en attente dans la file d'attente, donc la transaction de Bob à Alice DAI sera exécutée en premier.
Si le séquenceur n'attend pas les transactions dans la file d'attente, après un certain temps, l'utilisateur (ou n'importe qui) peut forcer lui-même les revenus.
Le séquenceur refuse de recevoir la transaction de Bob, donc Bob met la transaction en file d'attente depuis L1
Le séquenceur peut encore continuer à rejeter les transactions dans la file d'attente pendant un certain temps
Cependant, Sequencer ne peut pas toujours rejeter les transactions en attente dans la file d'attente. Après un certain temps, n'importe qui peut déclencher un revenu forcé. Nous présenterons ensuite la mise en œuvre du mécanisme de confinement forcé des Rollup les plus célèbres tels que Optimism, Arbitrum, StarkNet et zkSync. .
Mécanisme optimiste d’inclusion du pouvoir
Tout d’abord, introduisons le processus de dépôt d’Optimism. Ce dépôt ne fait pas seulement référence au dépôt d’argent dans Optimism, mais équivaut au « dépôt de messages pour L2 » plus général dans L2. Après avoir reçu le message nouvellement déposé, le nœud L2 transmet le message et le convertit en transaction sur le port L2 pour exécution, et transmet le message au destinataire désigné.
Message de l'utilisateur déposant de l'argent de L1 à L2
Contrat L1CrossDomainMessenger
Lorsqu'un utilisateur décide de déposer des jetons ETH ou ERC-20 dans Optimism, il interagit (cross-web) avec le contrat L1StandardBridge sur L1, spécifiant le montant à déposer et à quelle adresse le recevoir, etc. Ensuite, le message de connexion L1StandardBridge est transmis au contrat L1CrossDomainMessenger de la couche suivante. Ce contrat est principalement utilisé comme contrat de communication général entre L1 et L2. L1StandardBridge utilise ce contrat de communication général pour communiquer avec L2StandardBridge sur L2 afin de décider qui peut commencer par frapper. jetons de L2 ou retrait de jetons de L1. Si un développeur a besoin de développer un contrat d'interopérabilité et de synchronisation entre L1 et L2, il peut alors le construire sur L1CrossDomainMessenger.
Le contrat CrossChainMessenger de messagerie de l'utilisateur est passé de L1 à L2
Contrat du portail Optimisme
Le contrat L1CrossDomainMessenger enverra ensuite le message au contrat OptimismPortal de niveau le plus bas. Une fois le contrat OptimismPortal traité, il émettra un événement TransactionDeposited. Les paramètres de l'événement 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 Optimism de L2 écoutera l'événement TransactionDeposited émis par l'accord OptimismPortal et convertira les paramètres de l'événement en une transaction qui enregistre L2. L'initiateur de cette transaction L2 peut être « l'expéditeur du message » dans l'événement TransactionDeposited, la personne qui a envoyé la transaction Le destinataire sera la "personne qui reçoit le message" dans l'événement, et d'autres paramètres d'exécution sont également transmis par les paramètres de l'événement.
Le nœud L2 insère l'événement TransactionDeposited émis par OptimismPortal dans les transactions L2 annotées
Par exemple, il s'agit d'une transaction dans laquelle un utilisateur dépose 0,01 ETH via le contrat L1StandardBridge. Ce message et l'ETH sont transmis jusqu'au contrat OptimismPortal (l'adresse est 0xbEb5...06Ed). dans une transaction L2 et l'initiateur du message est le contrat L1CrossDomainMessenger ; le destinataire est le contrat L2CrossDomainMessenger livré avec 0,01 ETH ;
inclusion forcée
Lorsque l'utilisateur souhaite forcer l'exécution de sa transaction de manière optimiste, il n'a pas besoin d'envoyer de message de L1 à L2, il n'utilisera donc pas le contrat L1CrossDomainMessenger. L'effet qu'il souhaite obtenir est de rendre la facture spécifique "la transaction qu'il envoie et exécute sur L2 à partir de son adresse L2" soit exécutée en douceur, de sorte qu'il interagira directement avec le contrat OptimismPortal et laissera son adresse L2 appeler le contrat OptimismPortal, donc que lorsque l'événement TransactionDeposited est converti en transaction L2, "l'initiateur de la transaction" sera son adresse L2", afin que la transaction puisse être revue.
Dans la transaction L2 convertie à partir de l'événement TransactionDeposited, 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 ;
Utilisez l'adresse L2 pour appeler la fonction depositTransaction signée par OptimismPortal, et pensez à renseigner un par un les paramètres de la transaction L2.
J'ai effectué une simple transaction d'inclusion forcée : me transférer de l'argent à mon adresse L2 (0xeDc1...6909) et j'ai joint un message texte "inclusion forcée". Il s'agit de la transaction L1 dans laquelle j'exécute la fonction de dépôt de transaction via le contrat optimiste. Quelle quantité d'ETH la personne attache-t-elle", "L'initiateur de la transaction L2 doit attacher l'ETH au destinataire L2", "Limite de gaz de transaction L2" et "Données au destinataire L2" et d'autres informations.
Événement TransactionDeposited émis par la transaction L1
Après avoir interprété les valeurs numériques de plusieurs informations dans ce opaqueData, vous obtiendrez :
"Combien d'ETH est attaché à la personne qui a appelé DepositTransaction" : 0 car je ne souhaite pas recharger ETH de L1 à L2
"Combien d'ETH l'initiateur de la transaction L2 doit-il envoyer au destinataire L2" : 5566 (wei), car je souhaite me transférer de l'argent
« Limite de gaz de transaction L2 » : 50 000
"Données pour récepteur L2" : 0x666f72636520696e636c7573696f6e, effacer "inclusion forcée" de l'encodage hexadécimal de cette chaîne
Peu de temps après, la transaction L2 convertie est apparue : enregistrez la transaction L2 sur laquelle je me suis transféré de l'argent, le montant est de 5566 et les données sont la chaîne « inclusion obligatoire ». Et vous pouvez remarquer que le type de transaction (type de transaction) dans Autres attributs dans l'avant-dernière ligne de la figure est la transaction système 126 (Système), ce qui signifie que la transaction n'a pas été initiée par moi en L2, mais a été convertie à partir de l'événement L1TransactionDeposited.
Conversion terminée, transaction L2
Si l'utilisateur souhaite appeler d'autres contrats avec des données différentes, il fait de même en renseignant un par un les paramètres dans la lettre depositTransaction. N'oubliez pas d'utiliser l'adresse L2 pour exécuter sur L1, afin que l'initiateur de la transaction L2. sera l'adresse L2.
fenêtre du séquenceur
Le nœud Optimism L2 mentionné précédemment convertit l'événement TransactionDeposited en une transaction L2. En fait, ce nœud Optimism fait référence au nœud Sequencer. Après tout, il s'agit du séquençage des transactions, donc seul le séquenceur peut décider quand le convertir en transaction L2. . Lors de l'écoute de l'événement TransactionDeposited, le séquenceur ne convertit pas nécessairement l'événement en transaction L2 immédiatement, mais il peut décider de le convertir pendant une période de temps. Cette période de temps est appelée la fenêtre du séquenceur sur l'Optimism. le réseau principal est actuellement de 24 heures. Ensuite, lorsque l'utilisateur commence à déposer de l'argent depuis L1 ou reçoit un rappel, ou inclut de force une transaction de recharge, le pire des cas sera qu'il soit officiellement inclus dans l'historique des transactions L2 24 heures plus tard, mais au moins c'est mieux que la transaction qui ne peut jamais être évitée. Le résultat d'être inclus.
Le mécanisme d’inclusion forcée d’Arbitrum
Dans l'optimisme, l'opération de dépôt de L1 émettra un événement TransactionDeposited, et le reste consiste à attendre que le séquenceur reçoive l'opération de dépôt, mais dans toute opération de L1 (dépôt d'argent ou envoi de messages à L2, etc.) sera stockée ; dans une file d'attente convenue par L1 , au lieu de simplement émettre des événements. Le séquenceur disposera d'un délai pour ajouter les opérations L1 dans cette file d'attente à l'historique des transactions. Si le séquenceur est épuisé lorsque le temps est écoulé, il peut être terminé sans que personne n'ait à remplacer le séquenceur.
L'arbitrage maintiendra une file d'attente dans le contrat L1. Si le séquenceur ne reçoit pas activement les transactions dans la file d'attente, lorsque le temps est écoulé, n'importe qui peut forcer l'entrée des transactions dans la file d'attente dans l'historique des transactions.
Toutes les opérations L1 sont des contrats Delayed Inbox. Comme leur nom l'indique, les opérations ici seront retardées et expireront ; l'autre contrat est Sequencer Inbox, qui est une interface pour télécharger les transactions L2 vers Sequencer. Les transactions téléchargées par Sequencer seront directement écrites dans l'historique des transactions. De plus, lors du téléchargement par Sequencer, vous pouvez choisir le nombre d'opérations L1 à effectuer dans la boîte de réception différée et les écrire ensemble dans l'historique des transactions, afin que ces opérations L1 puissent prendre en charge. effet.
SequencerInbox contient l'historique des transactions. Généralement, seul Sequencer peut écrire directement de nouvelles transactions ; DelayedInbox contient les transactions en attente de réception.
Lorsque Sequencer écrit une nouvelle transaction, il peut lancer une transaction à partir de DelayedInbox et l'écrire ensemble.
Conceptions complexes et documentation impressionnante
Si les lecteurs se réfèrent directement au chapitre officiel d'Arbitrum sur Sequencer et Force Inclusion, ils verront comment Force Inclusion qui y est mentionnée est compatible, ainsi que certains noms de paramètres et noms de fonctions : L'utilisateur se rend d'abord dans Inbox pour prendre rendez-vous pour appeler la fonction sendUnsignedTransaction. Si le Sequencer n'est pas au rendez-vous Income dans les 24 heures, alors l'utilisateur peut appeler la fonction forceInclusion signée par Sequencer Inbox. De cette façon, même le lien n'est pas inclus et vous ne pouvez vous mettre d'accord que sur la fonction correspondante dans le code du programme.
Lorsque vous trouvez la fonction sendUnsignedTransaction, vous constatez que vous devez en fait remplir vous-même la valeur occasionnelle et la valeur maxFeePerGas. Quelle adresse est l'occasion ? Sur quel réseau correspond la valeur maxFeePerGas ? Quelle est la meilleure façon de le remplir ? Il n'y a aucune documentation, même pas celle de Natpsec. Ensuite vous trouvez également une fonction qui accumule les skins : sendL1FundedUnsignedTransaction, sendUnsignedTransactionToFork, sendContractTransaction, sendL1FundedContractTransaction. Il n'y a également aucun document vous expliquant la différence entre ces fonctions, comment les utiliser, et comment renseigner les paramètres, pas même Natpsec.
Vous réfléchissez à tout cela et essayez avant de remplir les paramètres et d'envoyer la transaction. Vous souhaitez utiliser des essais et des erreurs pour voir si vous pouvez trouver la bonne méthode, mais vous constatez que ces fonctions utiliseront toutes votre adresse L1 comme adresse. alias d'adresse, ce qui donne l'initiateur de transaction final sur L2 est fondamentalement une adresse différente, donc votre adresse L2 ne bouge pas du tout.
Envoyer un message L2
Plus tard, j'ai accidentellement cliqué sur un lien sur la page de recherche Google et découvert qu'Arbitrum contenait à l'origine une bibliothèque de didacticiels. Il contenait un script démontrant comment envoyer des transactions L2 à partir de L1 (ou ce que signifie Forcer l'inclusion), et sa fonction était complètement. différent de celui mentionné ci-dessus. L'un d'entre eux est simplement une fonction appelée sendL2Message, et le paramètre de message est en fait une transaction Arbitrum L2 signée ? ? ? Qui aurait cru que « envoyer des messages L2 » signifiait en réalité « transaction L2 signée » ? ? Et encore une fois, 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 de revenu forcé Arbitrum. Il est recommandé de suivre le tutoriel 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 de projet. L'objectif et les paramètres de nombreuses fonctions manquent d'explications, ce qui oblige les développeurs à consacrer plus de temps que prévu à y accéder et à les utiliser. J'ai également interrogé des personnes d'Arbitrum sur Arbitrum Discord, mais je n'ai pas obtenu de réponse satisfaisante.
Remarque : lorsque j'ai demandé sur Discord, l'autre partie m'a simplement demandé d'écouter sendL2Message. Il n'était pas nécessaire d'expliquer à quoi servent les autres fonctions (même sendUnsignedTransaction mentionnées dans le fichier d'inclusion obligatoire), comment les utiliser et quand. Utilise les.
Malheureusement, StarkNet n'applique pas actuellement l'inclusion. Il n’y a que deux articles sur le forum officiel qui traitent de la censure et des mécanismes d’inclusion obligatoire.
Impossible de prouver l'échec de la transaction
La raison en est que le système de preuve sans connaissance de StarkNet ne peut pas prouver les transactions qui n’ont pas été enregistrées, le crédit forcé ne peut donc pas être autorisé. Parce que si quelqu'un force par malveillance (ou involontairement) l'entrée d'une transaction qui échoue et ne peut pas être prouvée, StarkNet sera directement bloqué : car une fois la transaction entrée 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 de mettre en œuvre davantage le mécanisme d'inclusion obligatoire.
Le mécanisme d'inclusion obligatoire de zkSync
Le mécanisme de transmission des messages L1->L2 et d'inclusion forcée de zkSync est tous effectué via la fonction requestL2Transaction du contrat MailBox. L'utilisateur spécifie l'adresse L2 à appeler, les données d'appel, la quantité d'ETH transportée, la valeur de la limite de gaz L2, etc. , et divise les paramètres de requestL2Transaction Combinés en une transaction L2 puis simulés dans la file d'attente prioritaire, le séquenceur spécifiera le nombre de transactions à retirer de la file d'attente prioritaire et à recevoir ensemble lorsque la sauvegarde de la transaction est téléchargée sur L1 (fonction commitBatches). .
zkSync est très similaire à Optimistic en termes d'interface d'inclusion forcée. Les deux utilisent l'adresse L2 de l'utilisateur pour appeler et remplir les données pertinentes (appelé, données d'appel, etc.), au lieu de remplir une transaction L2 signée comme Arbitrum. en termes de conception, les transactions sont les mêmes qu'Arbitrum en ce qu'elles maintiennent une file d'attente d'entités dans L1, et le séquenceur prend les transactions de la file d'attente et les écrit dans l'historique des transactions.
L'utilisateur insère les transactions L2 dans la file d'attente prioritaire via requestL2Transaction, et le séquenceur peut communiquer avec la transaction depuis la file d'attente prioritaire lors de la validation des lots.
Si vous rechargez l'ETH via le pont officiel de zkSync, ce qui équivaut à la transaction à ce moment-là, il appelle la fonction requestL2Transaction du contrat MailBox. Il conservera l'ETH rechargé dans la file d'attente prioritaire des transactions L2 et émettra un événement NewPriorityRequest. Étant donné que le contrat code les données de la transaction L2 dans une chaîne d'octets, il n'est pas facile à lire. Si vous regardez plutôt les paramètres de la transaction L1, vous verrez que le destinataire de L2 dans les paramètres est également l'initiateur de la transaction. transaction car (c'est un dépôt pour vous-même), donc après un certain temps, lorsque la transaction d'échange L2 est sortie de la file d'attente prioritaire par le séquenceur et incluse dans l'historique des transactions, elle sera convertie sur L2 en une transaction qui enregistre le transfert à lui-même, et le montant du transfert est celui de l'initiateur de la transaction en L1. Déposez le montant d'ETH apporté à l'échange ETH.
Dans la transaction de recharge L1, l'initiateur et le destinataire de la transaction sont tous deux 0xeDc1…6909, le montant est de 0,03 ETH et les données d'appel sont vides.
La comptabilité 0xeDc1…6909 apparaîtra sur L2, une transaction que vous vous transférez. Le type de transaction (Txn Type) est 255, qui est une transaction système.
Ensuite, j'ai appelé la lettre requestL2Transaction directement selon le script et je me suis envoyé la transaction qui a enregistré l'appel : sans aucun ETH, les données de l'appel incluaient le codage hexadécimal de la chaîne « inclusion forcée ». La formule suivante est convertie en une transaction sur L2 qui enregistre son propre appel. Les données d'appel contiennent la chaîne « inclusion forcée » : 0x666f72636520696e636c7573696f6e.
Lorsque le séquenceur retire la transaction de la file d'attente prioritaire et l'écrit dans l'historique des transactions, elle peut être convertie en transaction L2 correspondante sur L2.
Grâce à la fonction requestL2Transaction, les utilisateurs peuvent demander une transaction L2 sur L1 avec l'adresse L2, en spécifiant le destinataire L2, la quantité d'ETH apportée et les données d'appel. Si l'utilisateur souhaite appeler d'autres contrats avec des données différentes, il doit également renseigner les paramètres un par un dans la fonction requestL2Transaction. N'oubliez pas d'utiliser l'adresse L2 pour exécuter sur L1, afin que l'initiateur de la transaction L2 soit le L2. adresse. .
Il n'y a aucune fonction qui permet aux utilisateurs de forcer les revenus
Bien que le placement des transactions L2 dans la file d'attente prioritaire calcule automatiquement la période pendant laquelle les transactions L2 doivent être collectées par le séquenceur, la conception actuelle de zkSync n'inclut pas de fonctions associées obligatoires que les utilisateurs peuvent exécuter eux-mêmes, ce qui équivaut à un demi-ensemble. Ainsi, même s'il existe une « période de validité des revenus », en fait, cela dépend toujours du fait que le séquenceur souhaite recevoir des revenus : le séquenceur peut attendre la transition pour recevoir des revenus, ou il ne peut jamais recevoir de transactions dans la file d'attente prioritaire. À l'avenir, zkSync devrait ajouter des fonctions pertinentes afin que les utilisateurs puissent forcer les revenus lorsque les revenus sont passés mais n'ont pas encore été reçus par le séquenceur. Il s'agit d'un mécanisme d'inclusion forcée vraiment efficace.
Résumer
L1 s'appuie sur un grand groupe de personnes pour assurer la « sécurité » et la « résistance à la censure » d'Internet, tandis que Rollup s'appuie sur « la résistance à la censure de L1 » pour obtenir « la même sécurité que L1 », mais n'inclut pas la résistance à la censure de Rollup. capacité
Au contraire, comme Rollup utilise un petit nombre, voire un seul séquenceur, pour écrire des transactions, sa capacité anti-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 des transactions dans l'historique afin d'éviter d'être examiné par Sequencer et de ne pas pouvoir utiliser ou quitter Rollup.
L'inclusion forcée 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 entraînera des problèmes pour le séquenceur et une expérience utilisateur difficile, 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 d'inclusion forcée actuel 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 d'entités dans L1 pour gérer les transactions L2 envoyées par les utilisateurs de L1 ou les messages vers L2. Arbitrum l'appelle boîte de réception différée ; zkSync l'appelle file d'attente prioritaire.
Cependant, la façon dont zkSync envoie les transactions L2 est similaire à Optimism. Elles sont envoyées à L1 en utilisant l'adresse L2, donc l'initiateur de la transaction L2 sera l'adresse L2. La fonction d'Optimism pour l'envoi de transactions L2 est appelée depositTransaction ; zkSync est appelée requestL2Transaction. Arbitrum crée une transaction L2 terminée et la signe, puis l'envoie via la lettre 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 a implémenté un demi-ensemble d'inclusions obligatoires - il existe une file d'attente prioritaire et les transactions L2 dans chaque file d'attente ont une période de validité de revenu, mais cette période de validité n'est actuellement qu'à des fins de décoration. , le séquenceur peut choisir de ne plus recevoir du tout de transactions L2 dans la file d'attente prioritaire