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

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

Connaissances préalables :

1. L’ensemble du processus des transactions L1 (couche 1)

2. Les causes et les impacts des réorganisations

3. Comprendre les rôles et les méthodes de fonctionnement de l'architecture actuelle de PBS d'Ethereum

4. Comprendre les différences entre l'Optimistic Rollup et le Validity (ZK) Rollup

Comprendre les transactions L1

Processus de transaction

Une fois qu’un utilisateur a émis et signé une transaction, celle-ci est envoyée au réseau peer-to-peer et attend qu’un mineur sous le mécanisme de consensus PoW ou un proposant sous le mécanisme de consensus PoS l’inclue dans un bloc. Lorsqu’un utilisateur constate que sa transaction a été incluse dans le dernier bloc, il ne peut pas être sûr à 100 % que la transaction sera enregistrée de manière permanente dans l’historique de cette blockchain. Cela est dû à la possibilité d’un événement blockchain connu sous le nom de « Re-org ». Les utilisateurs doivent attendre que la probabilité qu’une réorganisation se produise dans un certain bloc soit suffisamment faible pour être sûrs que leur transaction sera enregistrée dans l’historique de la blockchain.

Illustration du processus de transaction L1

Même après qu'une transaction ait été incluse dans un bloc, une réorganisation pourrait encore se produire. Il faut attendre que la probabilité d'une réorganisation soit faible pour être sûr que la transaction a été finalisée.

La probabilité et le coût d'une réorganisation varient en fonction de l'algorithme de consensus d'une chaîne et de la valeur marchande de ses actifs. La méthode de calcul du coût d'une réorganisation ne sera pas discutée en détail ici.

Comprendre les transactions de niveau 2

Processus de transaction

Après qu'un utilisateur L2 génère et signe une transaction, elle est généralement envoyée directement à un Séquenceur responsable de l'ordonnancement des transactions. Le Séquenceur inclut ensuite cette transaction dans un bloc L2. Par la suite, lorsque le Séquenceur écrit les données du bloc L2 sur L1 via une transaction L1, les utilisateurs peuvent voir leur transaction incluse dans le dernier bloc L2. Il est cependant important de noter que puisque les données du bloc L2 sont téléchargées sur L1 via une transaction L1, il existe toujours une possibilité de rencontrer un Re-org L1. Ce scénario pourrait entraîner le fait que le bloc L2 ne soit pas inclus dans l'historique de la blockchain, entraînant ainsi un Re-org L2. Par conséquent, les utilisateurs doivent attendre que la probabilité d'un Re-org L1 soit suffisamment faible avant de pouvoir être sûrs que leur transaction sera enregistrée dans l'historique de la blockchain.

Illustration du processus de transaction L2

Les utilisateurs attendent d'abord que leur transaction soit incluse dans un bloc L2, puis attendent que le bloc L2 soit téléchargé sur L1 via une transaction L1, et enfin attendent que la transaction L1 soit finalisée. Bien que l'attente d'une transaction L2 soit incluse dans un bloc L2 par un Séquenceur ajoute une étape par rapport aux transactions L1, cette période d'attente n'est généralement pas significative si la capacité du bloc L2 est grande et que la vitesse de génération du bloc est rapide. La plupart du temps d'attente est en fait consacré à la confirmation de la transaction L1. Ainsi, dans l'ensemble, l'expérience utilisateur pour les transactions L1 et L2 est similaire. Mais les utilisateurs peuvent-ils faire des concessions pour une meilleure expérience?

Pré-confirmation/Confirmation rapide/Confirmation souple

Idéalement, les utilisateurs devraient voir leurs transactions L2 (incluses dans les blocs L2) être incluses dans les blocs L1, et même attendre que la probabilité d’une réorganisation soit suffisamment faible, avant d’être sûrs que leurs transactions L2 ont été incluses. Mais que se passe-t-il si les utilisateurs sont prêts à faire confiance au séquenceur ? Supposons que le séquenceur soit exploité par l’équipe de développement L2 ou une institution réputée. Si le séquenceur assure aux utilisateurs à la réception de leurs transactions qu’ils seront inclus immédiatement ou dans le Xème bloc, cette assurance peut être suffisante pour ceux qui sont prêts à faire confiance au séquenceur. C’est un peu comme si un utilisateur qui faisait confiance à son application de portefeuille ne vérifiait pas à plusieurs reprises Etherscan pour la confirmation de la transaction après que le portefeuille l’ait informé de l’inclusion.

Cette assurance fournie par le Séquenceur est appelée Pré-confirmation, Confirmation Rapide ou Confirmation Douce. Ces termes peuvent être compris comme des assurances d'inclusion de transaction "prématurées" ou "douces". Elles ne nécessitent pas d'attendre que la transaction L2 soit incluse dans un bloc L1, mais ce ne sont que des engagements verbaux du Séquenceur. Le Séquenceur pourrait oublier sa promesse en raison d'un bug ou un Séquenceur malveillant pourrait rompre sa promesse, entraînant une perte de temps pour l'utilisateur ou, dans le pire des cas, une exposition à une "attaque de double dépense".

Ensuite, nous présenterons plusieurs façons différentes de présenter l’état de l’inclusion des transactions L2.

Statut d'inclusion de transaction sur Arbitrum/Optimism

Actuellement, lorsque les utilisateurs exécutent des transactions sur Arbitrum ou Optimism, ils reçoivent presque immédiatement un reçu de transaction, qui inclut le résultat de l'exécution de la transaction. Cela indique que le Séquenceur a déjà ordonné et simulé l'exécution de la transaction localement, et le reçu de transaction sert de pré-confirmation pour l'utilisateur.

Pour plus d'informations sur le cycle de vie détaillé des transactions sur Arbitrum, vous pouvez consulter le document officiel à :https://docs.arbitrum.io/tx-lifecycle

Pour une explication plus détaillée du cycle de vie de la transaction sur Optimism, veuillez consulter le document officiel à :https://community.optimism.io/docs/protocol/txn-flow/#posting-to-l1

Vérification du statut d'inclusion de la transaction sur Arbitrum

Les transactions affichées sur l'explorateur d'Arbitrum incluent celles avec une pré-confirmation, c'est-à-dire des transactions qui ne sont pas encore téléchargées sur L1. Comme le montre l'image suivante, une transaction avec le numéro de bloc 145353000 est marquée comme « Confirmée par le Séquenceur », ce qui indique qu'elle a été confirmée par le séquenceur mais n'a pas encore été téléchargée sur L1:

[Image montre une transaction confirmée par le Séquenceur mais non téléchargée sur L1]

En revanche, l'image suivante montre une transaction qui a déjà été téléchargée sur L1, avec un statut de « 69 confirmations de blocs L1 ». Cela signifie que le bloc L1 contenant ces données de transaction a 69 blocs qui le suivent, ce qui indique un niveau de sécurité plus élevé :

[L’image montre une transaction sur L1 avec 69 confirmations de blocs]

Un autre exemple est une transaction avec 6174 confirmations de bloc L1, comme le montre ci-dessous, ce qui est considéré comme très sécuritaire.

Cependant, il serait préférable que les informations L1 Finality soient intégrées dans cet affichage. Le simple fait d’indiquer aux utilisateurs le nombre de confirmations de blocage L1 est d’une aide limitée, car ils doivent comprendre et calculer le niveau de sécurité que ce nombre représente. Étant donné que la couche 1 (Ethereum) a un mécanisme de finalité comme Casper FFG, l’explorateur peut afficher directement si le bloc de couche 1 a été finalisé. Actuellement, l’explorateur d’Optimism a implémenté cette fonctionnalité.

Vérification du statut d'inclusion de la transaction sur Optimism

Les transactions affichées sur l'Optimism Explorer incluent également celles avec une pré-confirmation, c'est-à-dire des transactions pas encore téléchargées sur L1. Comme le montre l'image suivante, une transaction avec le numéro de bloc 111526300 est marquée comme "Confirmée par le séquenceur":

[L'image montre une transaction confirmée uniquement par le Séquenceur mais non téléchargée sur L1]

Cependant, l'Explorer ne définit pas clairement la signification de "Confirmé par le Séquenceur". Il indique que les confirmations du séquenceur sont équivalentes à quelques confirmations de blocs sur L1, ce qui suggère qu'une transaction marquée comme "Confirmé par le Séquenceur" a été téléchargée sur L1 et est suivie par plusieurs blocs.

[Image shows recent transactions marked as “Confirmed by Sequencer”]

Les transactions de plusieurs jours auparavant, même celles passées la période de défi, affichent toujours le statut "Confirmé par le Séquenceur":

[Image montre des transactions de jours passés toujours marquées comme "Confirmé par le Séquenceur"]

Note : L'Explorer peut afficher des statuts différents à différents endroits : "Confirmé par le séquenceur" à côté du numéro de bloc indique que le bloc a été confirmé par le séquenceur. Pour vérifier le statut après avoir été téléchargé sur L1, les utilisateurs doivent chercher d'autres informations, telles que le "Lot d'état L1" mentionné ci-dessous.

Comme le montre la capture d'écran suivante, une transaction déjà téléchargée sur L1 inclut des informations supplémentaires : "Index de lot d'état L1" et "Hachage de transaction de soumission de racine d'état L1". Ces détails indiquent dans quel lot d'état la transaction L2 est incluse et quelle transaction L1 a téléchargé ce lot d'état sur L1 :

[Image montre une transaction avec les informations de lot d'état L1]

En cliquant sur l'état du lot "3480", on découvre que son statut est finalisé. Ce statut finalisé correspond au mainnet d'Ethereum et indique un état très sécurisé, ayant accumulé avec succès deux epochs de votes de validateurs.

[Image shows State Batch 3480 finalized in L1 Block 18457449]

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

Si un lot a été téléchargé mais pas encore finalisé sur L1, il sera affiché comme Non finalisé :

[Image shows a State Batch uploaded to L1 but not yet finalized]

Par rapport à l'Arbitrum Explorer, l'Optimism Explorer fournit plus d'informations (State Batch) et intègre directement les informations de Finalité L1 dans l'Explorateur L2, permettant aux utilisateurs de savoir si le bloc L1 a été finalisé sans avoir à interpréter le nombre de confirmations de bloc pour la sécurité.

Statut des revenus de transaction StarkNet

Actuellement, lorsque les utilisateurs envoient des transactions sur StarkNet, ils peuvent rapidement accéder au reçu de la transaction. Cependant, le statut souvent affiché sur le reçu est REÇU, indiquant que le nœud a reçu et validé la transaction sans erreur. Il attendra ensuite l'inclusion et l'exécution dans un bloc L2 par le Séquenceur. Les transactions en statut REÇU n'ont pas encore de résultats d'exécution. Les utilisateurs peuvent suivre la progression de leurs transactions via le statut affiché sur l'Explorateur StarkNet.

Note : Si le séquenceur traite les transactions assez rapidement, il pourrait sauter l'état REÇU et passer directement à un état traité. Pour une introduction plus détaillée au processus de transaction de StarkNet, veuillez vous référer au document officiel sur https://docs.starknet.io/documentation/architecture_and_concepts/Network_Architecture/transaction-life-cycle/

Sur Starkscan, un explorateur StarkNet, les transactions incluant la pré-confirmation sont affichées. Par exemple, une transaction indiquée comme "Acceptée sur L2" signifie qu'elle a été séquencée dans un bloc L2 :

"Accepté sur L2" signifie que la transaction a été séquencée dans un bloc L2 mais n'a pas encore été téléchargée sur L1.

Les deux statuts précédents, Reçu et En attente, représentent « transaction reçue et validée » et « transaction en cours de traitement par le Séquenceur ». Après traitement, le statut passe à Accepté sur L2.

Transaction reçue et vérifiée

La transaction est en cours de traitement par le séquenceur

Après que les données de transaction sont téléchargées sur L1, le statut changera en Accepté sur L1, comme indiqué dans la figure ci-dessous pour cette transaction :

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, permettant aux utilisateurs de connaître la progression de leurs transactions, le téléchargement vers L1 peut prendre plusieurs heures, principalement en raison du temps nécessaire pour générer des preuves à divulgation nulle de connaissance. Par conséquent, les utilisateurs comptent sur la pré-confirmation de Sequencer pendant cette période.

L'explorateur StarkNet ne montre que l'état Accepté sur L1 sans informations accompagnantes sur la Finalité L1 ou la Confirmation de bloc. Les utilisateurs doivent vérifier si suffisamment de blocs ont été ajoutés après leur transaction sur L1 ou si elle a été finalisée.

En raison des limitations de performance de StarkNet, de la longue dépendance à la pré-confirmation et du manque de prise en charge des informations de finalité L1 dans l'explorateur, l'expérience utilisateur pour la confirmation de l'inclusion de transaction sur StarkNet doit être améliorée.

État d’inclusion de la transaction zkSync

Tout comme StarkNet, zkSync a également un statut EN ATTENTE, ce qui indique que le nœud a reçu et vérifié la transaction sans aucun problème. La transaction attendra alors d'être incluse et exécutée dans un bloc L2 par le Séquenceur. Les transactions en statut EN ATTENTE n'ont pas encore de résultats d'exécution.

Les utilisateurs peuvent suivre l'avancement de leurs transactions grâce à l'état affiché sur l'explorateur zkSync.

Conseil de lecture : Si le séquenceur traite les transactions assez rapidement, il pourrait contourner l'état EN ATTENTE et passer directement à un état où la transaction a déjà été traitée.

Pour une introduction plus détaillée au processus de transaction de zkSync, suivez ce lien :https://era.zksync.io/docs/reference/concepts/finality.html#finality-on-ethereum

Les transactions consultées sur l'explorateur zkSync incluent également des transactions de pré-confirmation, telles que celle figurant dans la capture d'écran ci-dessous. Le statut est actuellement "Traitement de l'ère zkSync", ce qui indique qu'elle a été organisée dans un bloc L2 par le Séquenceur :

La transaction a été organisée dans un 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 complété un bloc L2, le bloc et ses transactions passent par trois étapes : Engagée, Prouvée et Exécutée. Celles-ci indiquent respectivement que "le bloc est téléchargé sur L1", "la validité du bloc est prouvée", et "l'état L2 après exécution des transactions dans le bloc est mis à jour vers L1." Voici des exemples de blocs et de transactions à ces différentes étapes :

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 des transactions dans le lot 292700 passe de l'envoi d'Ethereum à la validation d'Ethereum, ce qui indique qu'elles attendent la validation de la preuve de connaissance nulle de leur validité.

En déplaçant la flèche sur l'icône de validation d'Ethereum, les différentes étapes seront également affichées, 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éverser le lot à L1 dans la phase précédente (Envoi) peut également être vu directement ici.

Le lot 292000 a vu sa validité prouvée, il entre donc dans la phase de validation :

Après qu'un lot a été prouvé, il entre dans l'état Proven, avec un lien vers la transaction exécutant l'action Prove.

Les transactions passent alors de « Validation » à « En cours d’exécution », ce qui signifie qu’elles attendent d’être exécutées.

Après qu'un lot est prouvé, il y a une période d'attente (environ 21 heures selon la documentation officielle) avant d'exécuter les transactions qui s'y trouvent et de mettre à jour l'état L2 enregistré sur L1. Il s'agit d'une mesure de protection dans la phase Alpha pour garantir un temps de réaction suffisant en cas de bugs. Une fois que le lot est exécuté, il entre dans la phase finale Exécutée :

Après l'exécution, le Batch entre dans l'état final Exécuté, avec un lien vers la transaction exécutant l'action Exécuter.

Le statut des transactions au sein du Batch est également mis à jour pour “Exécuté.”

Par rapport à StarkNet, où les transactions passent de la L2 à la L1 en une seule étape, zkSync décompose le processus de la L2 à la L1 en trois étapes plus détaillées : Engagé → Prouvé → Exécuté. Bien que, par mesure de protection, l'ensemble du processus de transaction prenne environ une journée, le statut Engagé permet aux utilisateurs de savoir rapidement si leur transaction a été incluse (après l'engagement, ce n'est pas seulement la pré-confirmation) sans se fier uniquement à la confiance dans le Séquenceur. De plus, zkSync Explorer fournit des données complètes pour chaque étape, permettant à quiconque de suivre le dernier statut des transactions et même de vérifier les transitions entre les étapes (par exemple, de 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 actuellement modifier les enregistrements historiques. Cela signifie que même si les transactions peuvent rapidement passer de la pré-confirmation à l'étape Confirmée, le Séquenceur peut toujours supprimer les transactions des utilisateurs de l'historique jusqu'à ce qu'elles atteignent l'étape Exécutée. Par conséquent, les utilisateurs doivent encore faire confiance au Séquenceur pendant un jour.

L1 Peut Également Soutenir la Pré-Confirmation

S'il est possible de savoir à l'avance qui est responsable de la production de blocs, L1 peut également prendre en charge la pré-confirmation. En prenant Ethereum comme exemple, le producteur de blocs réel est le Builder, qui peut offrir des services de pré-confirmation en fournissant aux utilisateurs une garantie d'inclusion de transaction. Cependant, étant donné que le Builder n'a pas le droit garanti de produire un bloc particulier mais doit enchérir pour le droit de produire chaque bloc, l'efficacité de cette pré-confirmation est relativement faible. De plus, la force du Builder doit être prise en compte ; si un Builder manque de force compétitive, il lui sera difficile de remporter le droit de produire des blocs, ce qui diminue la valeur de son service de pré-confirmation.

Une meilleure solution pour éviter ces problèmes serait que le Proposer propose des services de pré-confirmation, car il est généralement prédéterminé et certain quel Proposer proposera quel bloc. Cependant, dans l'architecture actuelle de PBS (Proposer-Builder Separation), le Proposer est uniquement responsable de proposer des blocs, tandis que le Builder décide du contenu du bloc. Par conséquent, le Proposer ne peut pas insérer directement une transaction dans un bloc ou demander au Builder de le faire. Cette situation pourrait changer avec les modifications futures de l'architecture PBS, comme l'ajout d'une liste d'inclusion ou la possibilité pour les Proposers de participer à la production de blocs, ce qui leur permettrait de proposer des services de pré-confirmation.

Conseil de lecture : Pour plus d’informations sur PBS, veuillez copier le lien ci-dessous dans votre navigateur pour lire : https://mirror.xyz/0x347c9872A2a1dE370D798f9FE96341A9A0E05af8/oG_4j_-TweXHX_LMag656k_pAyJWIBXpEDrzpUfVsss.

Amélioration de la pré-confirmation

La pré-confirmation n'est qu'une promesse verbale d'un constructeur ou d'un séquenceur L2, sans obligation de la respecter et sans mécanisme de punition en cas de non-respect. Cette promesse peut-elle être rendue plus fiable ? Oui, car le contenu de l'engagement (par exemple, "inclure cette transaction dans le bloc 1350000") fait par la personne responsable de la production des blocs peut être écrit comme une vérification conditionnelle. Ainsi, nous pouvons utiliser des contrats intelligents pour réglementer les constructeurs ou les séquenceurs, en leur demandant de déposer des garanties dans le contrat intelligent lorsqu'ils offrent des services de pré-confirmation et de signer le contenu de l'engagement. Si les utilisateurs constatent que les constructeurs ou les séquenceurs n'ont pas tenu leurs promesses, ils peuvent soumettre l'engagement et la signature au contrat intelligent pour vérification.

Bien que l'application de tels contrats en soit encore au stade de la preuve de concept, le lien suivant vers une vidéo de présentation présente un exemple d'application de contrat :

https://www.youtube.com/watch?v=Uw5HxSYXwYo

Résumé

Après qu'une transaction L1 est incluse dans un bloc L1, la probabilité d'un Re-org diminue progressivement et la confiance des utilisateurs dans l'inclusion de leur transaction augmente.

Les transactions L2 ont un flux de travail supplémentaire par rapport aux transactions L1 : la phase de “l'inclusion de la transaction L2 dans un bloc L2 et en attente d'être téléchargée sur L1.” Pendant cette phase, puisque les données ne sont pas encore téléchargées sur L1, il y a encore une possibilité de changements, et donc la seule assurance dont disposent les utilisateurs concernant l'inclusion de leur transaction est l'engagement verbal du Séquenceur, connu sous le nom de Pré-Confirmation, Confirmation Rapide, ou Confirmation Douce.

Si le Séquenceur est malveillant ou rencontre un bug, leurs engagements pourraient être rompus, ce qui pourrait potentiellement entraîner un manque de confirmation pour la transaction L2 de l'utilisateur.

Actuellement, la plupart des L2 affichent l'état de la transaction dans leurs Explorers, y compris l'état de pré-confirmation, comme le statut "Confirmé par le séquenceur" d'Arbitrum/Optimism ou le statut "Accepté sur L2" de StarkNet. Les utilisateurs doivent être conscients de la validité temporelle de l'assurance d'inclusion de la transaction fournie par ces statuts.

Si les utilisateurs ne veulent pas faire confiance à la Pré-Confirmation du Séquenceur, ils devront attendre plus longtemps et valider les informations fournies par l'Explorateur L2 concernant les données L2 téléchargées sur L1.

La pré-confirmation peut inclure un mécanisme d'incitation économique, tel que des pénalités via des contrats intelligents pour les séquenceurs qui rompent leurs promesses, offrant une protection plus claire aux utilisateurs.

Le tableau ci-dessous montre les garanties d'inclusion des transactions et les scénarios de risque correspondants pour les différentes étapes des transactions L1 et L2 : [Veuillez noter que le tableau n'est pas fourni dans la traduction.]

Avertissement：

1. Cet article est repris de [GateimToken Labs]. Tous les droits d'auteur appartiennent à l'auteur original [Nic]. Si vous avez des objections à cette réimpression, veuillez contacter le Porte Apprendreéquipe, et ils s'en chargeront 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 en aucun cas un conseil 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 interdite.