Interprétation des différentes étapes de reconnaissance des revenus des transactions L2
TechFlow SélectionTechFlow Sélection
Interprétation des différentes étapes de reconnaissance des revenus des transactions L2
Présenter l'ensemble du processus de mise en œuvre des transactions L2 et analyser la sécurité à chaque étape du flux transactionnel.
Dédié à des analyses Web3 approfondiesRédaction : Nic @imToken Labs
À quel moment peut-on être certain qu'une transaction L2 (Layer 2) sera incluse dans un bloc ? À quel moment peut-on être sûr que les revenus provenant d'une transaction L2 ne seront pas annulés à cause d’un réorganisme (Re-org) ?
Cet article présente aux lecteurs l'ensemble du processus de réalisation d'une transaction L2 et analyse la sécurité à chaque étape du flux transactionnel.
Prérequis :
-
Le processus complet d’une transaction L1 (Layer 1)
-
Les causes et impacts des réorganisations (Re-org)
-
Comprendre les rôles et le fonctionnement de l’architecture PBS actuelle sur Ethereum
-
Connaître la différence entre Optimistic Rollup et Validity Rollup (ZK Rollup)
Comprendre les transactions L1
Flux de transaction
Après avoir signé une transaction, l'utilisateur l'envoie au réseau P2P, en attendant qu'un mineur sous consensus PoW ou un proposant (proposer) sous consensus PoS l'inclue dans un bloc. Même lorsque la transaction apparaît dans le dernier bloc, on ne peut pas encore être totalement certain qu'elle restera inscrite définitivement dans l'historique de la chaîne, car une « réorganisation » (Re-org) est possible. L’utilisateur doit donc patienter jusqu’à ce que la probabilité d’un Re-org devienne suffisamment faible pour considérer sa transaction comme finalisée (finalized).
Schéma du processus d'une transaction L1
Même après inclusion dans un bloc, une transaction L1 reste exposée à un risque de Re-org. On ne peut être certain de sa finalisation qu’une fois que la probabilité d’un Re-org devient négligeable.
La probabilité et le coût d’un Re-org varient selon l’algorithme de consensus et la capitalisation du jeton de la chaîne ; ici, nous n’aborderons pas le calcul précis de ce coût.
Comprendre les transactions L2
Flux de transaction
Après avoir signé une transaction, un utilisateur L2 l'envoie généralement directement au Sequencer chargé de l'ordonnancement. Ce dernier inclut la transaction dans un bloc L2. Ensuite, lorsque le Sequencer écrit les données du bloc L2 via une transaction L1, l'utilisateur voit alors sa transaction incluse dans le dernier bloc L2.
Toutefois, il faut noter que ces données L2 étant transférées via une transaction L1, elles restent soumises au risque de Re-org sur L1, ce qui équivaut à un Re-org L2. Ainsi, l’utilisateur doit attendre que la probabilité d’un Re-org L1 devienne suffisamment faible avant de pouvoir considérer sa transaction comme définitivement enregistrée.
Schéma du processus d'une transaction L2
L’utilisateur attend d’abord que sa transaction soit incluse dans un bloc L2, puis que ce bloc soit envoyé sur L1 via une transaction L1, et enfin que cette dernière soit finalisée sur L1.
Bien que par rapport à une transaction L1, la transaction L2 implique un temps d’attente supplémentaire pour son inclusion dans un bloc L2, en pratique, si la capacité du bloc L2 est suffisante et la vitesse de production élevée, ce délai est négligeable. La majorité du temps d’attente provient surtout de la confirmation sur L1. Par conséquent, l’expérience utilisateur entre L1 et L2 est globalement similaire.
Mais si l’utilisateur accepte certains compromis, peut-il améliorer son expérience ?
Pre-Confirmation / Fast Confirmation / Soft Confirmation
Un utilisateur ne devrait faire confiance à l’inclusion de sa transaction L2 qu’en voyant visuellement que le bloc L2 contenant sa transaction a été inclus dans un bloc L1, et même alors, seulement après que le risque de Re-org devienne très faible.
Mais que se passe-t-il si l’utilisateur fait confiance au Sequencer ? Peut-être que celui-ci est exploité par l’équipe de développement du L2 ou par une institution reconnue. Si, dès réception de la transaction, le Sequencer garantit qu’elle sera incluse immédiatement ou au bloc X, alors pour un utilisateur qui lui fait confiance, cette promesse peut suffire. Comme un utilisateur faisant confiance à son portefeuille, il n’a pas besoin de vérifier constamment sur Etherscan après que son portefeuille a confirmé la transaction.
Cette garantie fournie par le Sequencer est appelée Pre-Confirmation, Fast Confirmation ou Soft Confirmation — une assurance « anticipée » ou « douce » d’inclusion. Elle ne nécessite pas d’attendre que la transaction L2 soit écrite sur L1, mais repose uniquement sur une promesse verbale du Sequencer. Celui-ci pourrait oublier sa promesse à cause d’un bug, ou un Sequencer malveillant pourrait la violer délibérément, entraînant au mieux une perte de temps, au pire une attaque par double dépense.
Nous allons maintenant présenter différentes manières dont les états d’inclusion des transactions L2 sont affichés.
État d’inclusion des transactions sur Arbitrum/Optimism
Actuellement, lorsqu’un utilisateur envoie une transaction sur Arbitrum ou Optimism, il reçoit presque immédiatement un reçu (transaction receipt), indiquant le résultat de l’exécution. Cela signifie que le Sequencer a déjà ordonné la transaction localement et simulé son exécution. Ce reçu constitue une Pre-Confirmation pour l’utilisateur.
Pour plus de détails sur le cycle de vie des transactions sur Arbitrum, copiez le lien suivant dans votre navigateur : https://docs.arbitrum.io/tx-lifecycle
Pour Optimism, consultez : https://community.optimism.io/docs/protocol/txn-flow/#posting-to-l1
Vérifier l’état d’inclusion sur Arbitrum
Sur Arbitrum Explorer, les transactions affichées peuvent être celles avec Pre-Confirmation, c’est-à-dire non encore envoyées sur L1. Par exemple, dans l’image ci-dessous, on voit la mention « Confirmed by Sequencer » à côté du numéro de bloc 145353000 :
Cette transaction n’a été confirmée que par le Sequencer, pas encore envoyée sur L1
Pour une transaction déjà envoyée sur L1 comme ci-dessous, l’état indique « 69 L1 Block Confirmations », signifiant que le bloc L1 contenant les données de la transaction a été suivi par 69 nouveaux blocs :
Le bloc L1 contenant les données a été suivi par 69 blocs. Plus il y a de blocs, plus la transaction est sécurisée.
Ou comme dans la capture ci-dessous, où 6174 blocs ont été ajoutés après le bloc contenant les données — un niveau de sécurité très élevé.
Cependant, une amélioration possible serait d’intégrer les informations de finalité L1.
Indiquer simplement le nombre de confirmations L1 n’est pas très utile, car l’utilisateur doit interpréter seul ce que cela signifie en termes de sécurité. Étant donné que Layer 1 (Ethereum) dispose déjà d’un mécanisme de finalité comme Casper FFG, l’explorateur pourrait directement indiquer si le bloc L1 correspondant est finalisé. Actuellement, l’explorateur d’Optimism intègre déjà cette fonctionnalité.
Vérifier l’état d’inclusion sur Optimism
Sur Optimism Explorer, les transactions avec Pre-Confirmation sont également affichées. Par exemple, ci-dessous, la transaction affiche « Confirmed by Sequencer » à côté du bloc 111526300 :
Transaction confirmée par le Sequencer mais pas encore envoyée sur L1
Toutefois, l’explorateur ne définit pas clairement la signification de « Confirmed by Sequencer ». Il indique que « les confirmations du Sequencer équivalent à quelques confirmations de blocs L1 », suggérant que la donnée a été envoyée sur L1 et suivie par plusieurs blocs :
Or, les transactions récentes montrent aussi cet état, et même des transactions datant de plusieurs dizaines de jours, largement passées la période de contestation, restent marquées « Confirmed by Sequencer » :
L’état d’une transaction vieille de plusieurs dizaines de jours reste « Confirmed by Sequencer »
Note : Cette situation pourrait résulter d’une distinction dans l’affichage des états : « Confirmed by Sequencer » à côté du numéro de bloc indique que le bloc est confirmé par le Sequencer, tandis que l’état postérieur à l’envoi sur L1 doit être vérifié via d'autres indicateurs, comme l’information « L1 State Batch » mentionnée ci-dessous.
Par ailleurs, pour une transaction déjà envoyée sur L1 comme ci-dessous, deux informations supplémentaires sont affichées : « L1 State Batch Index » et « L1 State Root Submission Tx Hash ». Elles indiquent dans quel lot (batch) d’état la transaction L2 a été incluse, et quelle transaction L1 a permis cet envoi :
En cliquant sur le lot « 3480 », on voit son état marqué Finalized. Ce statut correspond à la finalité sur L1 (le réseau principal Ethereum), indiquant que deux epochs complets de votes de validateurs ont été accumulés — un état extrêmement sûr.
△ Le lot 3480 a été inclus dans le bloc L1 18457449, qui est lui-même Finalized.
Source : https://etherscan.io/block/18457449
Si le lot est envoyé mais pas encore Finalized sur L1, il apparaît comme Unfinalized :
Le lot 3494 est envoyé sur L1, mais le bloc L1 qui l’a inclus n’est pas encore Finalized.
Comparé à Arbitrum Explorer, Optimism Explorer fournit davantage d’informations (comme les State Batches) et intègre directement la finalité L1, permettant à l’utilisateur de savoir immédiatement si le bloc L1 est finalisé, sans avoir à interpréter le nombre de confirmations.
État d’inclusion des transactions sur StarkNet
Actuellement, sur StarkNet, bien qu’un utilisateur puisse rapidement consulter le reçu de sa transaction, celui-ci affiche souvent l’état RECEIVED, signifiant que le nœud a reçu la transaction, l’a validée, et qu’elle attend d’être incluse et exécutée par le Sequencer. À cet état, aucun résultat d’exécution n’est encore disponible. L’utilisateur peut suivre l’avancement via l’état affiché sur StarkNet Explorer.
Note : Si le Sequencer est assez rapide, l’état RECEIVED peut être ignoré, et la transaction passer directement à l’état traité. Pour plus de détails, consultez le document officiel : https://docs.starknet.io/documentation/architecture_and_concepts/Network_Architecture/transaction-life-cycle/
Sur Starkscan, l’explorateur StarkNet, les transactions avec Pre-Confirmation sont affichées. Par exemple, ci-dessous, l’état est « Accepted on L2 », signifiant que la transaction a été incluse dans un bloc L2 par le Sequencer :
« Accepted on L2 » signifie que la transaction est incluse dans un bloc L2, mais pas encore envoyée sur L1
Avant « Accepted on L2 », les deux états précédents sont Received et Pending, indiquant respectivement « transaction reçue et validée » et « transaction en cours de traitement par le Sequencer ». Après exécution, elle passe à « Accepted on L2 » :
Transaction reçue et validée
Transaction en cours de traitement par le Sequencer
Une fois les données envoyées sur L1, l’état devient « Accepted on L1 », comme ci-dessous :
Données de transaction envoyées sur L1
Bien que StarkNet offre des états plus détaillés pour suivre l’avancement, l’envoi des données sur L1 peut prendre 4 à 5 heures (probablement en raison du temps nécessaire pour générer les preuves ZK). Pendant cette période, l’utilisateur dépend entièrement de la Pre-Confirmation du Sequencer.
De plus, l’explorateur affiche seulement « Accepted on L1 » pour les transactions envoyées, sans indiquer la finalité L1 ni le nombre de confirmations, obligeant l’utilisateur à vérifier manuellement si le bloc L1 est suffisamment sécurisé.
Globalement, en raison des goulots d’étranglement techniques de StarkNet et du manque d’intégration de la finalité L1 dans l’explorateur, l’expérience utilisateur concernant la confirmation d’inclusion reste médiocre — un point à améliorer à l’avenir.
État d’inclusion des transactions sur zkSync
Similaire à StarkNet, zkSync possède un état PENDING, indiquant que le nœud a reçu et validé la transaction, qui attend maintenant d’être incluse et exécutée par le Sequencer. À cet état, aucun résultat d’exécution n’est disponible.
L’utilisateur peut suivre l’avancement via l’état affiché sur zkSync Explorer.
Note : Si le Sequencer est rapide, l’état PENDING peut être ignoré.
Pour plus de détails, consultez : https://era.zksync.io/docs/reference/concepts/finality.html#finality-on-ethereum
Sur zkSync Explorer, les transactions avec Pre-Confirmation sont affichées. Par exemple, ci-dessous, l’état est « zkSync Era Processed », signifiant que la transaction a été incluse dans un bloc L2 :
Transaction incluse dans un bloc L2, en attente d’envoi sur L1 (Ethereum Sending)
Après création du bloc L2, les transactions passent par trois phases : Committed → Proven → Executed, signifiant respectivement « bloc envoyé sur L1 », « validité prouvée » et « état L2 mis à jour sur L1 ». Voici des exemples à différents stades :
Lot 292700 envoyé sur L1, phase Committed. Source : https://explorer.zksync.io/batch/292700
Transactions du lot passent de Ethereum Sending à Ethereum Validating : en attente de preuve ZK.
En survolant l’icône Ethereum Validating, les sous-étapes apparaissent, avec liens vers les transactions précédentes :
Transaction en phase « Validating », lien vers la transaction d’envoi du lot.
Le lot 292000 a eu sa validité prouvée, passant à l’état Proven :
Après preuve, état Proven, avec lien vers la transaction de preuve.
Transactions passent de « Validating » à « Executing », en attente d’exécution.
Après la preuve, une période d’attente (environ 21 heures selon la documentation) précède l’exécution finale et la mise à jour de l’état L2 sur L1. C’est une mesure de protection temporaire en phase Alpha, permettant de réagir à d’éventuels bugs. Une fois exécuté, le lot atteint l’état final Executed :
Après exécution, état final Executed, avec lien vers la transaction d’exécution.
États des transactions du lot mis à jour en « Executed »
Contrairement à StarkNet où l’envoi L2→L1 est un seul pas, zkSync divise ce processus en trois phases détaillées : Committed → Proven → Executed.
Bien que rallongé à environ un jour à cause de la mesure de protection, l’état Committed permet à l’utilisateur de savoir rapidement si sa transaction est incluse (passant au-delà de la simple Pre-Confirmation), réduisant ainsi la dépendance au Sequencer.
De plus, zkSync Explorer fournit des données complètes à chaque étape, permettant à tout un chacun de suivre l’état et même de vérifier personnellement chaque transition.
Toutefois, en phase Alpha, le Sequencer zkSync peut modifier l’historique.
Cela signifie qu’avant l’état Executed, le Sequencer peut toujours supprimer une transaction de l’historique. L’utilisateur doit donc continuer de lui faire confiance pendant près d’un jour.
Le L1 peut aussi supporter la Pre-Confirmation
Si l’on connaît à l’avance qui produira le bloc, le L1 peut aussi offrir une Pre-Confirmation.
Sur Ethereum, le Builder produit effectivement le bloc et pourrait fournir une Pre-Confirmation. Mais comme le Builder ne garantit pas systématiquement le droit de construire un bloc (il doit le remporter par enchères), cette garantie est moins fiable. De plus, sa crédibilité dépend de sa force compétitive : un Builder faible aura peu de chances de remporter des blocs, affaiblissant ainsi sa Pre-Confirmation.
Pour éviter cela, il serait préférable que le Proposer fournisse la Pre-Confirmation, car l’identité du Proposer pour chaque bloc est généralement déterminée à l’avance.
Toutefois, dans l’architecture PBS actuelle, le Proposer ne fait que proposer le bloc ; le Builder décide du contenu. Le Proposer ne peut donc ni insérer directement une transaction, ni imposer au Builder de le faire. Seulement si l’architecture évolue (ajout de listes d’inclusion, participation du Proposer à la construction), le Proposer pourra potentiellement offrir une Pre-Confirmation.
Note : Pour en savoir plus sur PBS, consultez : https://mirror.xyz/0x347c9872A2a1dE370D798f9FE96341A9A0E05af8/oG_4j_-TweXHX_LMag656k_pAyJWIBXpEDrzpUfVsss
Améliorer la Pre-Confirmation
La Pre-Confirmation n’est qu’une promesse verbale du Builder ou du Sequencer L2, sans obligation ni mécanisme de sanction en cas de non-respect.
Peut-on renforcer cette garantie ? Oui, car tant l’identité du producteur de bloc que la promesse (ex. « inclure la transaction au bloc 1350000 ») peuvent être formalisées. On peut utiliser un contrat intelligent exigeant du Builder ou du Sequencer de déposer une caution, de signer leur promesse, et permettant à l’utilisateur de soumettre la preuve de non-respect au contrat, qui vérifiera automatiquement si la promesse a été tenue.
Bien que ces contrats soient encore à l’étape de concept, une démonstration vidéo en présente un exemple : https://www.youtube.com/watch?v=Uw5HxSYXwYo
Résumé
-
Une fois incluse dans un bloc L1, la probabilité de Re-org diminue progressivement, renforçant la confiance de l’utilisateur.
-
La transaction L2 ajoute une étape : « inclusion dans un bloc L2, puis attente d’envoi sur L1 ».
-
Durant cette étape supplémentaire, les données n’étant pas encore sur L1, la seule garantie d’inclusion est la promesse verbale du Sequencer, appelée Pre-Confirmation, Fast Confirmation ou Soft Confirmation.
-
Si le Sequencer est malveillant ou rencontre un bug, il peut rompre sa promesse, empêchant la confirmation de la transaction L2.
-
Actuellement, la plupart des explorateurs L2 affichent des états de Pre-Confirmation, comme « Confirmed by Sequencer » sur Arbitrum/Optimism ou « Accepted on L2 » sur StarkNet. Attention à la durée de validité de ces garanties.
-
Si l’on ne fait pas confiance à la Pre-Confirmation, il faut patienter et utiliser les informations fournies par l’explorateur L2 (envoi sur L1) pour vérifier soi-même.
-
La Pre-Confirmation peut être renforcée par des incitations économiques, par exemple via un contrat intelligent punissant le Sequencer en cas de violation, offrant ainsi une meilleure garantie à l’utilisateur.
Le tableau ci-dessous résume les garanties d’inclusion et les risques associés aux différentes étapes du processus de transaction L1 et L2 :
Bienvenue dans la communauté officielle TechFlow
Groupe Telegram :https://t.me/TechFlowDaily
Compte Twitter officiel :https://x.com/TechFlowPost
Compte Twitter anglais :https://x.com/BlockFlow_News
@imTokenOfficial
