Interprétation du processus complet de transaction Layer 2 : analyse des performances de sécurité à chaque étape

Layer 2(L2) transactions, compared to Layer 1(L1) transactions, include an additional phase waiting to be uploaded to L1. During this phase, users can only rely on the pre-confirmation provided by the Sequencer (Pre-Confirmation), which carries certain risks. This article will analyze the entire process of L2 transactions in detail and explore the security performance at each stage.

Revue du processus de transaction L1

Après qu'un utilisateur ait émis une transaction, il doit attendre qu'elle soit intégrée dans un bloc par des mineurs/validateurs. Même si la transaction a été incluse dans le dernier bloc, il faut attendre un nombre suffisant de confirmations pour réduire le risque de reconfiguration (Re-org). Ce n'est que lorsque la probabilité de reconfiguration est suffisamment faible qu'on peut être sûr que la transaction sera finalement inscrite dans l'historique de la blockchain.

Analyse du processus de transaction L2

Après qu'un utilisateur L2 ait émis une transaction, c'est généralement le Sequencer qui est responsable du tri et de l'emballage dans le bloc L2. Lorsque le Sequencer écrit les données du bloc L2 dans une transaction L1, l'utilisateur peut voir sa transaction incluse dans le dernier bloc L2.

Mais à ce stade, il existe toujours un risque de réorganisation de L1, ce qui pourrait entraîner le fait que ce bloc L2 ne soit finalement pas inscrit dans l'historique de la blockchain. Par conséquent, les utilisateurs doivent également attendre que la probabilité de réorganisation de L1 soit suffisamment faible pour être certains que la transaction sera finalement confirmée.

mécanisme de pré-confirmation

Pour améliorer l'expérience utilisateur, certaines L2 ont introduit le mécanisme de pré-confirmation ( Pre-Confirmation ). Le séquenceur, lorsqu'il reçoit une transaction utilisateur, s'engage à traiter cette transaction dans les plus brefs délais.

Pour les utilisateurs prêts à croire au Sequencer, cette promesse peut suffire. Cependant, la préconfirmation n'est qu'une promesse verbale du Sequencer, elle n'a pas de force juridique et comporte un risque de violation.

Affichage de l'état de confirmation des transactions des solutions L2 principales

Arbitrum/Optimism

Les transactions Arbitrum et Optimism reçoivent presque immédiatement un reçu après leur émission, c'est ce que fournit le Sequencer en tant que pré-confirmation.

L'explorateur Arbitrum affiche l'état "Confirmé par Sequencer" des transactions, ainsi que le nombre de confirmations L1.

Optimism Explorer en plus d'afficher l'état "Confirmé par Sequencer", fournit plus d'informations :

• L1 State Batch Index: numéro de State Batch dans lequel se trouve l'échange
• L1 State Root Submission Tx Hash: le hash de transaction de ce Batch téléchargé sur L1

Optimism a également montré directement les informations de finalité de L1, permettant aux utilisateurs de savoir clairement si le bloc L1 a été définitivement confirmé.

StarkNet

L'état des transactions de StarkNet est plus riche, incluant :

• Reçu : Transaction reçue et vérifiée
• En attente : la transaction est en cours de traitement par le Sequencer
• Accepté sur L2 : La transaction a été intégrée dans le bloc L2.
• Accepté sur L1 : les données de transaction ont été téléchargées sur L1

Mais StarkNet prend plus de temps pour télécharger les transactions sur L1, ( de 4 à 5 heures ), les utilisateurs doivent compter sur des pré-confirmations à long terme. De plus, l'Explorer ne fournit pas d'informations sur la finalité L1, l'expérience utilisateur doit être améliorée.

zkSync

zkSync divise le processus de transaction de L2 à L1 en 3 étapes :

1. Committed : Le bloc a été téléchargé sur L1
2. Proven : la validité du bloc a été prouvée
3. Exécuté : Exécution des transactions dans le bloc terminée, l'état de L2 a été mis à jour vers L1

zkSync Explorer fournit une présentation détaillée des données pour chaque étape, y compris les liens vers les transactions L1 pertinentes, etc.

Mais il convient de noter qu'en tant que mesure de protection de la phase Alpha, le Sequencer peut modifier l'historique jusqu'à la phase Executed, et les utilisateurs doivent toujours faire confiance au Sequencer pendant environ un jour.

Améliorer le mécanisme de pré-confirmation

La pré-confirmation n'est actuellement qu'un engagement verbal, sans force contraignante. Il serait envisageable d'introduire un mécanisme de contrat intelligent :

• Exiger que le Sequencer/Builder fournisse un dépôt de garantie pour la préconfirmation.
• Le Séquenceur/Constructeur doit signer le contenu de l'engagement.
• Les utilisateurs peuvent soumettre des preuves lorsqu'ils constatent qu'un engagement n'a pas été respecté.
• Les contrats intelligents vérifient et exécutent automatiquement les pénalités

Ce mécanisme peut offrir aux utilisateurs une protection plus claire, mais il est actuellement encore au stade de la validation du concept.

Résumé

Les transactions L2 ajoutent une étape d'attente pour être téléchargées sur L1, durant laquelle les utilisateurs ne peuvent se fier qu'à la pré-confirmation. Chaque solution L2 affiche l'état de pré-confirmation dans l'Explorer, mais leur fiabilité et leur rapidité varient.

Les utilisateurs doivent être conscients des limites de la pré-confirmation et, si nécessaire, attendre que la transaction soit téléchargée sur L1 et qu'un nombre suffisant de confirmations soit obtenu. À l'avenir, des mécanismes tels que les contrats intelligents pourraient être utilisés pour améliorer la fiabilité de la pré-confirmation et offrir une meilleure protection aux utilisateurs.