Quand peut-on être certain qu'une transaction de couche 2 (L2) sera incluse dans un bloc? Quand peut-on être sûr que les revenus d'une transaction de couche 2 ne seront pas jetés en raison d'une réorganisation?

Cet article présentera l'ensemble du processus de mise en œuvre de la transaction L2 et analysera les performances de sécurité à chaque étape du processus de transaction.

Connaissances préliminaires:

• L'ensemble du processus des transactions L1 (couche 1)
• Raisons et impacts des occurrences de Re-org
• Comprendre les rôles et les méthodes de fonctionnement dans l'architecture actuelle de PBS Ethereum
• Différences entre Optimistic Rollup et Validité (ZK) Rollup

Comprendre les transactions de couche 1

Processus de transaction

Une fois qu’un utilisateur a émis et signé une transaction, celle-ci est envoyée au réseau p2p, en attente d’inclusion dans un bloc par un mineur dans le cadre du mécanisme de consensus Proof of Work (PoW) ou par un proposant dans le cadre du mécanisme de consensus Proof of Stake (PoS). Lorsqu’un utilisateur remarque que sa transaction a été incluse dans le dernier bloc, il n’est pas encore certain que la transaction sera enregistrée de manière permanente dans l’historique de la blockchain. Cette incertitude est due à la possibilité d’une « réorganisation » (réorganisation) sur la blockchain. Les utilisateurs doivent attendre que la probabilité d’une réorganisation soit suffisamment faible pour être sûrs que leur transaction sera enregistrée de manière permanente dans l’historique de la blockchain.

Processus de transaction L1 illustré

Même après qu'une transaction a été incluse dans un bloc, une réorganisation peut encore se produire, ce qui signifie que la confirmation ne peut être assurée que lorsque la probabilité d'une réorganisation devient peu probable.

La probabilité et le coût d'une réorganisation varient en fonction de l'algorithme de consensus de chaque blockchain et de la valeur marchande de ses actifs. Ce document n'abordera pas les méthodes de calcul des coûts de réorganisation.

Comprendre les transactions de couche 2

Processus de transaction

Les utilisateurs de la L2 génèrent et signent des transactions, les envoyant généralement directement à un Séquenceur, qui inclut ensuite ces transactions dans un bloc L2. Ensuite, lorsque le Séquenceur publie les données du bloc L2 de retour à la L1 via une transaction L1, les utilisateurs peuvent voir leurs transactions incluses dans le dernier bloc L2.

Cependant, il est important de noter que puisque les données de bloc L2 sont envoyées à L1 via une transaction L1, il est toujours possible qu'un retrait de L1 se produise, ce qui pourrait entraîner le bloc L2 ne soit pas enregistré de manière permanente dans l'historique de la blockchain. Ce scénario est similaire à un retrait de L2, donc les utilisateurs doivent attendre que la probabilité d'un retrait de L1 soit suffisamment faible pour être certains que leur transaction sera enregistrée de manière permanente dans l'historique de la blockchain.

Processus de transaction L2 illustré

Les utilisateurs doivent d'abord attendre que leur transaction soit incluse dans un bloc L2, puis que le bloc L2 soit posté sur L1 via une transaction L1, et enfin que la transaction L1 soit finalisée.

Bien que les transactions L2 impliquent un temps d'attente supplémentaire pour être incluses dans un bloc L2 par le Séquenceur par rapport aux transactions L1, cette attente est généralement courte si la capacité du bloc L2 est grande et que la génération de bloc est rapide, car la principale période d'attente est pour que la transaction L1 soit confirmée. Ainsi, l'expérience utilisateur globale des transactions L1 et L2 est similaire.

Pre-Confirmation/Fast Confirmation/Soft Confirmation

Les utilisateurs doivent vérifier personnellement que leurs transactions L2, ainsi que le bloc L2, ont été inclus dans un bloc L1, et même attendre que la probabilité d'une réorganisation soit suffisamment faible pour avoir confiance que leur transaction L2 a été incluse.

Mais que se passe-t-il si les utilisateurs sont prêts à faire confiance au Séquenceur? Le Séquenceur pourrait être géré par l'équipe de développement L2 ou par une institution réputée. Si le Séquenceur assure immédiatement les utilisateurs dès réception de leurs transactions qu'elles seront incluses dans un bloc spécifique, cette garantie pourrait suffire à ceux qui sont prêts à faire confiance au Séquenceur. C'est similaire à un utilisateur faisant confiance à son application de portefeuille et ne vérifiant pas de manière obsessionnelle Etherscan pour confirmation après avoir été informé de l'inclusion d'une transaction.

De telles garanties fournies par le séquenceur sont appelées pré-confirmation, confirmation rapide ou confirmation douce. Il s'agit de "préliminaires" ou d'assurances "douces" de l'inclusion de la transaction, ne nécessitant pas que la transaction L2 soit incluse dans un bloc L1. Cependant, il s'agit simplement d'engagements verbaux du séquenceur, qui peuvent être oubliés en raison d'un bug ou délibérément rompus par un séquenceur malveillant, entraînant au pire une attaque de double-dépense.

Par la suite, nous présenterons les différentes façons dont les statuts d'inclusion de transactions L2 sont présentés.

Statut d'inclusion de la transaction Arbitrum/Optimism

Actuellement, les utilisateurs sur Arbitrum ou Optimism peuvent presque immédiatement recevoir un reçu de transaction après l'envoi d'une transaction, indiquant le résultat de l'exécution de la transaction. Cela signifie que le Séquenceur a déjà séquencé et simulé localement la transaction, fournissant aux utilisateurs une Pré-Confirmation.

En savoir plus

Pour plus d'informations détaillées sur le cycle de vie des transactions d'Arbitrum, veuillez vous référer à la documentation officielle : https://docs.arbitrum.io/tx-lifecycle

Pour plus d'informations détaillées sur le cycle de vie des transactions Optimism, veuillez vous référer à la documentation officielle : https://community.optimism.io/docs/protocol/txn-flow/#posting-to-l1

Statut des revenus de trading pour Arbitrum/Optimism

Actuellement, après que les utilisateurs envoient une transaction sur Arbitrum ou Optimism, ils peuvent presque immédiatement obtenir un reçu de transaction (Transaction Receipt), qui contiendra les résultats de l'exécution de la transaction. Cela signifie que le Séquenceur a séquencé la transaction localement et l'a simulée une fois. Ce reçu de transaction est la Pré-Confirmation donnée à l'utilisateur.

apprendre plus

Pour une introduction plus détaillée au cycle de vie des transactions d'Arbitrum, vous pouvez copier le lien ci-dessous dans le navigateur pour vous référer au document officiel :

https://docs.arbitrum.io/tx-lifecycle

Pour une introduction plus détaillée au cycle de vie de transaction d'Optimism, vous pouvez copier le lien ci-dessous dans le navigateur et consulter le document officiel :

https://community.optimism.io/docs/protocol/txn-flow/#posting-to-l1

Vérifiez le statut des revenus de transaction sur Arbitrum

Les transactions visibles sur l'explorateur Arbitrum incluront des transactions de pré-confirmation, c'est-à-dire des transactions qui n'ont pas été téléchargées sur L1. Pour cette transaction, comme le montre la figure ci-dessous, vous pouvez voir une marque Confirmé par le séquenceur à côté du numéro de bloc 145353000 :

L'image ci-dessus montre des transactions qui n'ont été confirmées que par le séquenceur mais n'ont pas encore été téléchargées sur L1.

S'il s'agit d'une transaction qui a été téléchargée sur L1 comme le montre la figure ci-dessous, son statut a été modifié en 69 confirmations de blocs L1, ce qui signifie qu'elle a été téléchargée sur L1 et que le bloc Layer1 contenant les données de la transaction a été suivi de 69 blocs :

Le bloc L1 contenant ces données de transaction a déjà 69 blocs qui le suivent. Plus il y a de blocs qui le suivent, plus il est sécurisé.

Ou pour cette transaction comme indiqué dans la capture d'écran ci-dessous, le bloc L1 contenant ces données de transaction a déjà 6174 blocs qui le suivent, ce qui est déjà très sûr.

Mais en fait, ce qui peut être fait de mieux ici, c'est de le présenter en combinaison avec les informations de Finality de L1.

Dire simplement à l'utilisateur combien de confirmations de blocs L1 il y a est d'une aide limitée pour l'utilisateur, car l'utilisateur doit comprendre et calculer le niveau de sécurité représenté par un tel nombre de confirmations de blocs. Et comme Layer1 (c'est-à-dire Ethereum) a déjà un mécanisme de finalité comme Casper FFG, l'Explorateur peut en fait afficher directement si le bloc Layer1 a été finalisé dans Layer1. Actuellement, l'Explorateur d'Optimism a implémenté une telle fonction.

Vérification du statut du reçu de transaction sur Optimism

Les transactions consultées sur l'Optimism Explorer peuvent inclure celles marquées comme pré-confirmation, indiquant qu'elles n'ont pas encore été publiées sur la couche 1 (L1). Comme illustré ci-dessous, la transaction avec le numéro de bloc 111526300 est marquée comme « Confirmé par le séquenceur » :

Transactions only confirmed by the Séquenceur but not yet posted to L1

Actuellement, l'explorateur semble manquer d'une définition claire pour "Confirmé par le séquenceur", suggérant que les "confirmations du séquenceur sont équivalentes à quelques confirmations de bloc sur L1." Cela implique que être "Confirmé par le séquenceur" signifie que la transaction a été publiée sur L1 et a plusieurs blocs qui la suivent :

Cependant, les transactions nouvellement apparues sont également affichées comme "Confirmé par le séquenceur," et même les transactions datant de nombreux jours auparavant, qui ont dépassé la période de défi, restent dans le statut "Confirmé par le séquenceur":

Les transactions de plusieurs jours sont toujours dans l'état "Confirmé par le séquenceur"

Note de lecture : Cette situation pourrait également être due au fait que l'Explorateur présente des indicateurs d'état différents à différents endroits : "Confirmé par le Séquenceur" à côté du numéro de bloc informe les utilisateurs que le bloc a été confirmé par le Séquenceur. Pour vérifier le statut post-L1, les utilisateurs doivent se référer à d'autres informations, telles que les détails de "Lot d'État L1" discutés ci-dessous.

De plus, comme le montre la capture d'écran ci-dessous, une transaction qui a été publiée sur L1 inclut deux informations supplémentaires : "Index du lot d'état L1" et "Hachage de transaction de soumission de racine d'état L1." Ces détails représentent dans quel lot d'état la transaction L2 est incluse et à travers quelle transaction L1 ce lot d'état a été publié sur L1 :

En cliquant sur "State Batch 3480", son statut est affiché comme finalisé, correspondant au statut finalisé sur L1 (c'est-à-dire, l'Ethereum mainnet), qui est un statut hautement sécurisé obtenu après l'accumulation de votes de validateurs sur deux époques.

△ State Batch 3480 est inclus dans le Bloc L1 18457449, et le Bloc 18457449 a été finalisé.

Source : https://etherscan.io/block/18457449

Si un lot a été publié mais pas encore finalisé sur L1, il s'affichera comme Non finalisé :

Lot d'état 3494, bien que posté à L1, est inclus dans un bloc L1 qui n'a pas été finalisé：

Comparé à l'Arbitrum Explorer, l'Optimism Explorer fournit des informations plus détaillées (State Batch) et lie directement les informations de Finalité L1 à l'Explorateur L2, permettant aux utilisateurs de savoir si un bloc L1 a été finalisé, plutôt que de baser leur propre jugement sur le nombre de confirmations de bloc pour le niveau de sécurité.

Statut des revenus de transaction StarkNet

Actuellement, lorsque les utilisateurs envoient des transactions sur StarkNet, ils peuvent rapidement interroger le reçu de la transaction. Cependant, le reçu montre souvent le statut de la transaction comme REÇU. Ce statut indique que le nœud a reçu la transaction et, après vérification, n'a trouvé aucun problème. La transaction attend d'être incluse dans un bloc L2 par le Séquenceur et exécutée. Les transactions au statut REÇU n'auront pas encore de résultats d'exécution. Les utilisateurs peuvent vérifier l'avancement de leurs transactions en consultant le statut de la transaction affiché sur l'Explorateur StarkNet.

Conseil de lecture : Si le séquenceur traite les transactions suffisamment rapidement, il peut contourner l'état REÇU et passer directement à un état traité. Pour une introduction plus détaillée au processus de transaction sur StarkNet, vous pouvez copier le lien ci-dessous dans votre navigateur pour consulter les documents officiels.

Documents officiels :Cycle de vie de la transaction StarkNet

Les transactions vues sur Starkscan, un explorateur StarkNet, incluent également des transactions de pré-confirmation. Comme le montre la transaction suivante, le statut actuel est "Accepté sur L2", ce qui indique qu'elle a été mise en file d'attente par le séquenceur dans un bloc L2 :

"Accepted on L2” signifie qu'il a été mis en file d'attente par le séquenceur dans un bloc L2, mais pas encore téléchargé sur L1.

Les deux statuts avant "Accepté sur L2" sont Reçu et En attente, représentant "la transaction a été reçue et vérifiée" et "la transaction est en cours de traitement par le Séquenceur", respectivement. Après l'exécution du traitement de la transaction est terminée, elle passera au statut "Accepté sur L2":

La transaction a été reçue et vérifiée.

La transaction est en cours de traitement par le Séquenceur.

Une fois que les données de transaction sont téléchargées sur L1, le statut passera à "Accepté sur L1", comme le montre la transaction suivante :

Les données de transaction ont été téléchargées sur L1.

Bien que les transactions StarkNet aient un ensemble plus riche de statuts pour informer les utilisateurs de l'avancement du traitement, le téléchargement des transactions sur L1 peut encore nécessiter une attente de plusieurs heures (peut-être parce que la génération de preuves de connaissance nulle prend plus de temps). Pendant ce temps, les utilisateurs s'appuient sur la Pré-confirmation du Séquenceur.

De plus, l'Explorer affiche uniquement "Accepté sur L1" pour les transactions téléchargées sur L1, sans informations accompagnantes sur la Finalité de L1 ou la Confirmation du Bloc. Cela signifie que les utilisateurs doivent vérifier eux-mêmes si le bloc L1 a suffisamment de blocs ultérieurs ou s'il a été finalisé.

Dans l'ensemble, en raison des goulots d'étranglement des performances de StarkNet, les utilisateurs doivent compter sur la pré-confirmation pendant une période prolongée, et l'Explorer ne prend pas en charge les informations de Finalité L1, ce qui entraîne une expérience utilisateur moins satisfaisante pour la confirmation des revenus de transaction. Il s'agit d'un domaine dans lequel StarkNet doit s'améliorer à l'avenir.

Statut des revenus de transaction zkSync

Tout comme StakrNet, zkSync a également un état EN ATTENTE, ce qui signifie que le nœud a reçu la transaction et qu'il n'y a aucun problème une fois la transaction vérifiée. Il attendra d'être inclus dans le bloc L2 par le Séquenceur et exécuté. Cependant, aucune transaction ne sera exécutée à l'état EN ATTENTE. le résultat de.

Les utilisateurs peuvent connaître l'avancement du traitement de leurs transactions grâce à l'état des transactions affiché sur zkSync Explorer.

Conseils de lecture : Si le Séquenceur est traité assez rapidement, il est peut-être possible de sauter directement l'état EN ATTENTE et d'entrer dans l'état où la transaction a été traitée.

Pour une introduction plus détaillée au processus de transaction de zkSync, vous pouvez copier le lien ci-dessous et le consulter dans votre navigateur :https://era.zksync.io/docs/reference/concepts/finality.html#finality-on-ethereum

Les transactions visibles sur zkSync Explorer incluront également des transactions de pré-confirmation, telles que la transaction dans la capture d'écran ci-dessous. Vous pouvez voir que le statut est actuellement traité par zkSync Era, indiquant qu'il a été mis en file d'attente dans le bloc L2 par le séquenceur:

Cette transaction a été mise en file d'attente dans le bloc L2 par le Séquenceur et attend actuellement d'être téléchargée sur L1 (Envoi Ethereum)

Après que le séquenceur a terminé le bloc L2, le bloc et les transactions qu'il contient passeront ensuite par les trois étapes de Committed, Proven et Executed, ce qui signifie respectivement que le bloc a été téléchargé sur L1 et que la validité du bloc a été prouvée. Et que l'état L2 est mis à jour sur L1 après l'exécution de la transaction dans le bloc. Les trois blocs et transactions à différents stades sont présentés ci-dessous :

Le lot 292700 a été téléchargé sur L1 et est entré dans la phase Engagée. Source: https://explorer.zksync.io/batch/292700

Le statut actuel des transactions dans le lot 292700 est passé de l'envoi d'Ethereum à la validation d'Ethereum, ce qui indique qu'il attend d'être vérifié par une preuve de connaissance nulle pour vérifier sa validité.

Passer la souris sur l'icône de validation Ethereum montrera également les différentes étapes, et le lien de transaction pour l'étape précédente (Envoi) sera également attaché :

Cette transaction est entrée dans la phase de "Validation". Le lien de transaction pour télécharger le lot vers L1 dans la phase précédente (Envoi) peut également être vu directement ici.

L'efficacité du Batch 292000 a été prouvée, il entre donc dans la phase Proven :

Après que le lot est prouvé, il entre dans l'état Prouvé, et un lien de transaction pour exécuter l'action Prouver est attaché.

Les transactions à l'intérieur entreront également dans la phase "Exécution" à partir de la phase "Validation", en attente d'exécution.

Lorsque le Batch est prouvé, il entrera ensuite dans une période d'attente (les documents officiels indiquent qu'il s'agit d'environ 21 heures) avant d'exécuter les transactions à l'intérieur et de mettre à jour le statut L2 enregistré sur L1. Cela est principalement dû à une mesure de protection qui est encore à l'étape Alpha pour garantir qu'il y a suffisamment de temps pour réagir en cas de bug. Lorsque le Batch est exécuté, il entrera dans la phase finale d'exécution :

Après l'exécution du lot, il entre dans l'état final Exécuté, et un lien de transaction pour exécuter l'action Exécuter est attaché.

Le statut de la transaction dans le lot est également mis à jour à “Exécuté”. Contrairement aux transactions StarkNet, qui sont terminées de la couche 2 (L2) à la couche 1 (L1) en une seule étape, zkSync décompose le processus des transactions de L2 à L1 en trois étapes plus détaillées : Engagé → Prouvé → Exécuté. Bien que cela prolonge le processus de transaction complet à environ un jour en tant que mesure de protection, le statut Engagé permet aux utilisateurs de savoir rapidement si leur transaction a été incluse (une fois qu'une transaction entre dans l'étape Engagé, ce n'est plus simplement une Pré-Confirmation), sans avoir continuellement recours à la confiance dans le Séquenceur. De plus, l'explorateur zkSync fournit des affichages de données complets et complets pour différentes étapes, permettant à quiconque de comprendre le dernier statut des transactions et même de vérifier personnellement l'exécution des transactions à chaque transition d'étape (par exemple, d'Engagé à Prouvé, de Prouvé à Exécuté). Cependant, il est important de noter qu'en tant que mesure de protection dans la phase Alpha, le Séquenceur zkSync peut modifier les enregistrements historiques. Cela indique que même si les transactions peuvent rapidement passer de la Pré-Confirmation à l'étape Engagé, le Séquenceur peut toujours supprimer les transactions des utilisateurs des enregistrements historiques jusqu'à ce qu'elles atteignent l'étape Exécuté. Par conséquent, les utilisateurs doivent toujours faire confiance au Séquenceur pendant environ un jour.

La couche 1 peut également prendre en charge la pré-confirmation

S'il est connu à l'avance qui est responsable de produire des blocs, alors L1 peut également prendre en charge la Pré-Confirmation. En prenant Ethereum comme exemple, le véritable producteur de blocs est le Constructeur, qui peut offrir des services de Pré-Confirmation, donnant aux utilisateurs une garantie d'inclusion de transaction. Cependant, comme le Constructeur n'a pas nécessairement le droit de produire un bloc spécifique mais doit enchérir pour avoir le droit de produire chaque bloc, l'efficacité de la Pré-Confirmation peut être plus faible. De plus, la compétitivité du Constructeur doit être prise en compte ; si un Constructeur n'est pas assez compétitif, il lui sera difficile de sécuriser le droit de produire des blocs, réduisant ainsi considérablement la fiabilité de ses services de Pré-Confirmation. Pour éviter ces problèmes, une meilleure approche consisterait à permettre aux Proposeurs de fournir des services de Pré-Confirmation, car il est généralement prédéterminé et certain quel Proposeur proposera quel bloc. Cependant, dans l'architecture actuelle du PBS, les Proposeurs ne font que proposer des blocs, et la production réelle de blocs et la prise de décision sur le contenu sont effectuées par les Constructeurs, de sorte que les Proposeurs ne peuvent pas insérer directement une transaction dans un bloc ou demander à un Constructeur de le faire. À l'avenir, si l'architecture du PBS change, par exemple, en ajoutant une Liste d'Inclusion ou en permettant aux Proposeurs de participer à la production de blocs, les Proposeurs pourraient avoir l'opportunité d'offrir des services de Pré-Confirmation. Pour plus d'informations sur le PBS, veuillez visiter le lien fourni.

Amélioration de la pré-confirmation :

La pré-confirmation n'est qu'un engagement verbal pris par les constructeurs ou les séquenceurs de niveau 2, sans obligation de tenir la promesse et sans mécanisme de pénalité en cas de non-respect. Cependant, il est possible de rendre cet engagement plus fiable en utilisant des contrats intelligents pour standardiser les constructeurs ou les séquenceurs. Ils pourraient fournir des services de pré-confirmation tout en déposant une caution dans le contrat intelligent et signer le contenu lors de la promesse d'inclusion de transaction. Si les utilisateurs constatent que les constructeurs ou les séquenceurs n'ont pas tenu leurs promesses, ils peuvent soumettre le contenu de la promesse et la signature au contrat intelligent, qui peut ensuite vérifier si la promesse a été respectée. Bien que le scénario d'application du contrat susmentionné en soit encore à l'étape de la preuve de concept, le lien ci-dessous montre une vidéo de présentation d'un tel exemple d'application de contrat.

Résumé :

Une fois que les transactions L1 sont incluses dans les blocs L1, la probabilité de réorganisation diminue et la confiance des utilisateurs dans l’inclusion des transactions augmente progressivement. Les transactions L2 ont un flux de travail supplémentaire par rapport aux transactions L1 : « Les transactions L2 sont incluses dans les blocs L2 et attendent d’être téléchargées vers L1. » Cependant, étant donné que les données n’ont pas été téléchargées vers L1 à ce stade, il existe toujours une possibilité de variance, de sorte que l’assurance que les utilisateurs peuvent obtenir sur l’inclusion de la transaction à ce stade est l’engagement verbal du séquenceur, connu sous le nom de pré-confirmation ou confirmation rapide/confirmation douce. Si le séquenceur est malveillant ou rencontre simplement un bogue, sa promesse peut être rompue, ce qui entraîne un manque de confirmation de la transaction L2 de l’utilisateur. À l’heure actuelle, la plupart des L2 affichent des statuts de transaction dans leurs explorateurs qui incluent le statut de pré-confirmation, tels que Confirmed by Sequencer d’Arbitrum/Optimism ou Accepted on L2 de StarkNet. Lorsque vous consultez de telles informations, il est important de prêter attention à l’efficacité en temps de l’assurance d’inclusion de la transaction fournie. Si les utilisateurs ne souhaitent pas se fier à la pré-confirmation du séquenceur, ils devront attendre plus longtemps et vérifier via les informations de l’explorateur L2 sur les données L2 téléchargées vers L1. La pré-confirmation peut intégrer un mécanisme d’incitation économique, tel que la pénalisation des séquenceurs par le biais de contrats intelligents lorsqu’ils ne tiennent pas leurs promesses, offrant ainsi aux utilisateurs une protection plus claire. Le tableau ci-dessous présente les garanties d’inclusion des transactions et les scénarios de risque correspondants fournis par les transactions L1 et L2 à différentes étapes du processus de transaction.

Avertissement：

1. Cet article est repris de [Gateaicoin]. Tous les droits d'auteur appartiennent à l'auteur original [Foresight News]. Si des objections sont formulées à cette réimpression, veuillez contacter le Gate Learnéquipe, et ils s'en occuperont rapidement.
2. Clause de non-responsabilité : Les points de vue et opinions exprimés dans cet article sont uniquement ceux de l'auteur et ne constituent pas des conseils en investissement.
3. Les traductions de l'article dans d'autres langues sont effectuées par l'équipe Gate Learn. Sauf mention contraire, la copie, la distribution ou le plagiat des articles traduits est interdit.