Interprétation de l’ensemble du processus de mise en œuvre d’une transaction L2 : quelles sont les performances de sécurité de chaque étape ?

Auteur : Nic@ imToken Labs

Quand puis-je être sûr qu’une transaction L2 sera incluse dans un bloc ? Quand puis-je être sûr que les revenus d’une transaction L2 ne seront pas supprimés en raison de la réorganisation ?

Cet article présente l’ensemble du processus de mise en œuvre de la transaction L2 et analyse les performances de sécurité de chaque étape du processus de transaction.

Conditions préalables:

• L’ensemble du processus des transactions L1 (couche 1)
• Causes et effets de la réorganisation
• Comprendre le rôle actuel d’Ethereum dans l’architecture PBS et son fonctionnement
• Comprendre les différences entre les cumuls optimistes et les cumuls de validité (ZK)

En savoir plus sur les transactions L1

PROCESSUS DE TRANSACTION

Diagramme du flux de transactions L1

La réorganisation est toujours possible après le blocage des revenus de la transaction, et il est nécessaire d’attendre qu’il soit peu probable que la réorganisation se produise pour être sûr que la transaction a été finalisée.

La probabilité et le coût de la réorganisation varieront en fonction de l’algorithme de consensus d’une chaîne et de la capitalisation boursière de l’actif, et le calcul du coût de la réorganisation ne sera pas introduit ici.

En savoir plus sur les transactions L2

PROCESSUS DE TRANSACTION

Une fois que l’utilisateur L2 a généré et signé la transaction, celle-ci est généralement envoyée directement au séquenceur responsable du tri de la transaction, et le séquenceur collecte sa transaction dans le bloc L2. Ensuite, lorsque le séquenceur réécrit les données du bloc L2 dans L1 par le biais d’une transaction L1, l’utilisateur peut voir que sa transaction est incluse dans le dernier bloc L2.

Cependant, il convient de noter qu’étant donné que les données du bloc L2 sont téléchargées vers L1 via des transactions L1, il est toujours possible de rencontrer une situation où la réorganisation L1 se produit, ce qui fait que le bloc L2 n’est pas écrit dans l’historique de la blockchain à la fin, c’est-à-dire équivalent à la réorganisation L2, de sorte que l’utilisateur doit encore attendre que la probabilité de réorganisation L1 soit suffisamment faible pour être sûr que sa transaction sera inscrite dans l’historique de la blockchain.

Diagramme du flux de transactions L2

L’utilisateur attend d’abord que la transaction soit incluse dans le bloc L2, puis attend que le bloc L2 soit téléchargé vers L1 via une transaction L1, et enfin attend que la transaction L1 soit finalisée.

Bien que par rapport aux transactions L1, les transactions L2 ont une période de temps supplémentaire pour attendre que les transactions L2 soient incluses dans les blocs L2 par Sequencer, mais en fait, lorsque la taille du bloc L2 est suffisamment grande et que la vitesse de production des blocs est suffisamment rapide, ce temps d’attente ne prendra pas beaucoup de temps, car le temps d’attente consacrera principalement les transactions L1 à la comptabilisation des revenus, donc dans l’ensemble, l’expérience des transactions L1 et des transactions L2 est similaire.

Mais si l’utilisateur est prêt à faire des sacrifices, peut-il être échangé contre une meilleure expérience ?

Pré-confirmation/Confirmation rapide/Confirmation douce

L’utilisateur doit voir le bloc L2 (contenant les transactions L2) être inclus dans le bloc L1, et même attendre que la probabilité d’occurrence de la réorganisation soit suffisamment faible pour croire que sa transaction L2 a été gagnée.

Mais que se passe-t-il si l’utilisateur est prêt à faire confiance à Sequencer ? Peut-être que Sequencer est géré par l’équipe de développement L2, gérée par une organisation réputée, et si Sequencer assure à l’utilisateur que sa transaction sera payée immédiatement, au Xème Bloc, alors cette garantie est suffisante pour l’utilisateur qui est prêt à faire confiance à Sequencer. Tout comme si un utilisateur fait confiance au portefeuille qu’il utilise, il n’ira pas de manière suspecte à Etherscan pour vérifier après que le portefeuille l’ait averti que la transaction a été payée.

La garantie de revenu de transaction fournie par ce séquenceur est appelée pré-confirmation, confirmation rapide ou confirmation logicielle, qui peut être comprise comme une garantie de revenus de transaction « anticipée » ou « douce ». Il n’est pas nécessaire d’attendre que les transactions L2 soient incluses dans le bloc L1, mais il ne s’agit que d’une promesse verbale donnée par Sequencer, et Sequencer peut oublier la promesse d’origine en raison de bogues ou Sequencer malveillant violera directement la promesse, ce qui peut faire perdre du temps à l’utilisateur ou être une « Double Spend Attack ».

Ensuite, nous examinerons quelques-unes des différentes façons dont le statut de revenu des transactions L2 est présenté.

Statut des revenus de transaction d’Arbitrum/Optimism

À l’heure actuelle, les utilisateurs qui envoient une transaction sur Arbitrum ou Optimism peuvent obtenir presque immédiatement un reçu de transaction, qui sera le résultat de l’exécution de la transaction. Cela signifie que Sequencer a déjà séquencé et simulé l’exécution des transactions localement, et que cette réception de transaction est la pré-confirmation pour l’utilisateur.

Pour en savoir plus sur Arbitrum, une description plus détaillée du cycle de vie des transactions peut être copiée sur le lien suivant vers le document officiel de référence du navigateur :

Pour une introduction plus détaillée au cycle de vie des transactions d’Optimism, veuillez copier le lien suivant vers le document officiel de référence du navigateur :

Vérifier l’état des revenus des transactions sur Arbitrum

Les transactions que vous voyez sur l’Explorateur Arbitrum contiendront des transactions de pré-confirmation, c’est-à-dire des transactions qui n’ont pas encore été téléchargées vers L1, comme le montre la figure suivante, vous pouvez voir qu’il y a un indicateur Confirmé par le séquenceur à côté du numéro de bloc 145353000 :

L’image ci-dessus montre les transactions qui n’ont été confirmées que par Sequencer mais qui n’ont pas encore été téléchargées vers L1

Si la transaction a été téléchargée vers L1 comme indiqué dans la figure ci-dessous, son état est passé à 69 confirmations de bloc L1, ce qui signifie qu’elle a été téléchargée vers L1 et qu’elle contient le bloc de données de transaction et qu’il y a 69 blocs derrière elle :

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

Ou la transaction montrée dans la capture d’écran ci-dessous, le bloc L1 contenant ces données de transaction a 6174 blocs derrière lui, ce qui est déjà très sécurisé.

Mais ce qui peut être mieux fait ici, c’est de combiner les informations de finalité L1.

Le simple fait d’indiquer à l’utilisateur le nombre de confirmations de blocage L1 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 blocage. Et comme la couche 1 (c’est-à-dire Ethereum) dispose déjà d’un mécanisme de finalité tel que Casper FFG, l’explorateur peut en fait montrer directement si le bloc de couche 1 est actuellement finalisé dans la couche 1. Actuellement, l’explorateur d’Optimism a implémenté une telle fonctionnalité.

Vérifier l’état des revenus des transactions sur Optimism

Les transactions que nous voyons sur l’Explorateur Optimism incluront également les transactions de pré-confirmation, c’est-à-dire les transactions qui n’ont pas encore été téléchargées vers L1, comme le montre la figure suivante, nous pouvons voir qu’il y a un symbole Confirmé par le séquenceur à côté du numéro de bloc 111526300 :

Transactions qui n’ont été confirmées que par Sequencer mais qui n’ont pas encore été téléchargées vers L1

Cependant, l’Explorateur ne semble pas avoir de spécification claire de ce que signifie Confirmé par le séquenceur, disant « Les confirmations du séquenceur sont équivalentes à quelques confirmations de bloc sur L1. », indiquant que Confirmé par le séquenceur représente un certain nombre de blocs qui ont été téléchargés sur L1 et ont été suivis de plusieurs :

Mais en fait, la dernière transaction est également affichée comme confirmée par Sequencer, et même il y a des dizaines de jours, le statut de la transaction qui a dépassé la période de défi est toujours Confirmé par Sequencer :

Il y a des dizaines de jours, l’état de la transaction était toujours bloqué à « Confirmé par Sequencer »

Conseil de lecture : La situation ci-dessus peut également être que l’explorateur marque différents états à différents endroits : le séquenceur confirmé par après le numéro de bloc indique à l’utilisateur que le bloc a été confirmé par le séquenceur, et l’utilisateur doit confirmer l’état après le téléchargement sur L1 via d’autres informations, telles que les informations « L1 State Batch » mentionnées ci-dessous.

En outre, la transaction qui a été téléchargée vers L1, comme indiqué dans la capture d’écran ci-dessous, contient deux informations supplémentaires : « L1 State Batch Index » et « L1 State Root Submission Tx Hash ». Ces deux éléments d’information représentent le lot d’état dans lequel la transaction L2 a été incluse et la transaction L1 par le biais de laquelle le lot d’état a été téléchargé vers L1 :

Cliquez sur le lot d’état « 3480 », vous pouvez voir que son état est Finalisé, ce qui correspond à l’état Finalisé de L1 (c’est-à-dire le réseau principal Ethereum), qui est un état très sécurisé qui a réussi à accumuler les votes de deux validateurs d’époque.

△ Le lot d’État 3480 a été acquis dans le bloc L1 18457449 et le bloc 18457449 a été finalisé.

Source:

Si le lot a été téléchargé mais n’a pas été finalisé dans L1, il s’affichera comme Non finalisé :

Bien que le lot d’État 3494 ait été téléchargé vers L1, le bloc L1 inclus dans le lot n’a pas encore été finalisé.

Par rapport à l’Explorateur Arbitrum, l’Explorateur Optimism fournit plus d’informations (lot d’état) pour les transactions, et il reliera directement les informations de finalité L1 à l’Explorateur L2, afin que l’utilisateur puisse savoir directement si le bloc L1 a été finalisé, plutôt que de juger du degré de sécurité correspondant au nombre de confirmations de bloc.

Statut des résultats de trading de StarkNet

À l’heure actuelle, après l’envoi d’une transaction par l’utilisateur sur StarkNet, bien que la réception de la transaction puisse être interrogée rapidement, l’état de la transaction affiché dans le reçu sera généralement à l’état RECEIVED, ce qui signifie que le nœud a reçu la transaction et qu’il n’y a pas de problème après la vérification de la transaction, et attendra que la transaction soit reçue par le bloc L2 du séquenceur et exécutée, tandis que la transaction à l’état RECEIVED n’aura aucun résultat d’exécution de transaction. Les utilisateurs peuvent vérifier la progression de leurs transactions grâce à l’état de la transaction affiché sur StarkNet Explorer.

Conseil de lecture : Si le séquenceur traite assez rapidement, il est possible d’ignorer l’état RECEIVED et d’aller à l’état où la transaction a déjà été traitée. Pour une introduction plus détaillée au processus de trading de StarkNet, vous pouvez copier le lien ci-dessous pour afficher les documents officiels dans votre navigateur.

Documents officiels : _and_concepts/network_Architecture/transaction-life-cycle/

Les transactions vues sur Starkscan, l’explorateur StarkNet, incluront également les transactions de pré-confirmation, comme le montre la figure suivante, vous pouvez voir que le statut est actuellement accepté sur L2, ce qui signifie qu’il a été classé dans le bloc L2 par le séquenceur :

« Accepté sur L2 » signifie qu’il a été placé dans un bloc L2 par Sequencer, mais qu’il n’a pas encore été téléchargé sur L1

Les deux premiers états de Accepté sur L2 sont Reçu et En attente, ce qui signifie que « la transaction a été reçue et vérifiée » et « la transaction est en cours de traitement par Sequencer », et la transaction entrera dans l’état Accepté sur L2 après l’exécution de la transaction :

La transaction est reçue et vérifiée

La transaction est en cours de traitement par Sequencer

Une fois les données de transaction téléchargées vers L1, l’état passe à Accepté sur L1, comme illustré dans la figure suivante :

Les données transactionnelles ont été téléchargées dans L1

Bien que les transactions de StarkNet aient un état plus riche qui permet aux utilisateurs de connaître la progression de la transaction, cela peut prendre quatre ou cinq heures pour que la transaction soit téléchargée vers L1 (probablement parce qu’il faut beaucoup de temps pour générer une preuve à divulgation nulle de connaissance), de sorte que les utilisateurs pendant ce temps s’appuient sur la pré-confirmation de Sequencer.

De plus, l’Explorateur n’affiche que Accepté sur L1 pour les transactions téléchargées vers L1, et ne dispose pas des informations de Finalité ou de Confirmation de blocage avec L1, ce qui signifie que les utilisateurs doivent vérifier s’il y a suffisamment de Bloc dans le Bloc L1 ou s’ils ont été finalisés.

Dans l’ensemble, en raison du goulot d’étranglement des performances de StarkNet lui-même, les utilisateurs doivent compter sur la pré-confirmation pendant une longue période, et Explorer ne prend pas en charge les informations de finalité L1, ce qui entraîne une mauvaise expérience de la reconnaissance des revenus des transactions StarkNet, c’est là que StarkNet doit être amélioré à l’avenir.

Statut des revenus de transaction de zkSync

Semblable à StakrNet, zkSync a également un état PENDING, ce qui signifie que Node a reçu la transaction et que la transaction a été vérifiée sans problème, il attendra que la transaction soit bloquée et exécutée par le séquenceur L2, tandis que la transaction dans l’état PENDING n’aura aucun résultat d’exécution de transaction.

Les utilisateurs peuvent connaître la progression de leurs transactions grâce à l’état de la transaction affiché sur l’explorateur zkSync.

Conseil de lecture : Si le séquenceur traite assez rapidement, il est possible d’ignorer l’état PENDING et d’aller à l’état où la transaction a déjà été traitée.

Pour une introduction plus détaillée au processus de transaction de zkSync, vous pouvez copier le lien suivant pour l’afficher dans votre navigateur :

Les transactions que vous voyez sur l’explorateur zkSync incluront également les transactions de pré-confirmation, comme celle de la capture d’écran ci-dessous, vous pouvez voir que le statut est actuellement zkSync Era Traité, ce qui signifie qu’il a été classé dans le bloc L2 par le séquenceur :

Cette transaction a été placée dans le bloc L2 par Sequencer et attend actuellement d’être téléchargée sur L1 (Ethereum Sending)

Une fois que le séquenceur a créé un bloc L2, le bloc et les transactions qu’il contient passent par trois phases en séquence : Validé, Prouvé et utilisé, indiquant que « Le bloc a été téléchargé vers L1 », « La validité du bloc a été prouvée » et « L2 l’état a été mis à jour à L1 après l’exécution de la transaction de bloc ». Le bloc et la transaction à différentes étapes sont indiqués ci-dessous :

Le lot 292700 a été téléchargé vers L1 et est en phase de validation. Source:

L’état actuel de la transaction dans le lot 292700 est passé de Envoi Ethereum à Validation Ethereum, ce qui indique qu’elle attend d’être vérifiée par Zero-Knowledge Proof.

En déplaçant la flèche sur l’icône de validation d’Ethereum, vous verrez également les différentes étapes, et le lien de transaction de l’étape précédente (Envoi) sera également joint :

Cette transaction entre dans l’étape « Validation », et le lien vers la transaction qui a téléchargé Batch vers L1 à l’étape précédente (Envoi) peut également être consulté ici.

L’efficacité du lot 292000 a été prouvée, alors entrez dans la phase éprouvée :

Une fois le lot prouvé, il passe à l’état Prouvé avec un lien vers la transaction qui exécute l’action Prouver.

La transaction passera également de « validation » à « utilisation », c’est-à-dire en attente d’exécution.

Lorsque le lot est prouvé, il entre alors dans une période d’attente (environ 21 heures dans les documents officiels) avant que la transaction à l’intérieur ne soit exécutée et que l’état L2 enregistré sur L1 ne soit mis à jour. Cela est principalement dû à une sauvegarde qui a été ajoutée dans la phase alpha pour s’assurer qu’il y a suffisamment de temps pour réagir aux bugs qui surviennent. Lorsque le lot est exécuté, il entre dans la phase finale d’utilisation :

Une fois le lot exécuté, il entre dans l’état final avec un lien de transaction qui exécute l’action ute.

L’état de la transaction dans Batch a également été mis à jour à « uted »

Contrairement à StarkNet, où les transactions L2 à L1 sont effectuées en une seule étape, le processus de zkSync pour passer de L2 à L1 est décomposé en trois étapes plus détaillées : Committed → Proven → uted.

Alors que l’ensemble du processus de transaction est étendu à environ un jour par mesure de sécurité, l’état Validé permet aux utilisateurs de savoir rapidement si une transaction a été gagnée (et n’est plus seulement une pré-confirmation une fois que la transaction entre Validée) sans avoir à compter sur la confiance dans Sequencer sur une base continue.

De plus, zkSync Explorer fournit un affichage riche et complet des données pour les différentes étapes, de sorte que n’importe qui peut saisir le dernier état des transactions via l’explorateur, et même être en mesure de vérifier personnellement l’exécution de la transaction de chaque transition d’étape (par exemple, de Committed à Prouvé, de Proven à uted).

Cependant, il convient de noter qu’à titre de mesure de protection pour la phase alpha, l’historique peut être modifié par zkSync Sequencer à ce moment-là.

Cela suggère que même si une transaction peut rapidement passer de la phase de pré-confirmation à la phase de validation, Sequencer peut en fait supprimer une transaction utilisateur de l’historique avant que la transaction n’entre dans la phase d’utilisation. Par conséquent, les consommateurs doivent toujours faire confiance à Sequencer jusqu’à une journée.

L1 peut également prendre en charge la pré-confirmation

Si vous pouvez savoir à l’avance qui est responsable de la production des blocs, L1 peut également prendre en charge la pré-confirmation.

Si l’on prend l’exemple d’Ethereum, la personne qui produit réellement des blocs est le constructeur, et le constructeur peut fournir des services de pré-confirmation pour donner aux utilisateurs une garantie de revenu de transaction. Mais parce que le Constructeur n’obtient pas nécessairement le droit à une certaine sortie et à un certain Bloc, mais doit enchérir pour le droit à chaque Bloc de sortie, de sorte que l’efficacité de cette Pré-Confirmation sera relativement faible, et que la force du Constructeur doit être prise en compte, si le Constructeur n’est pas assez compétitif, alors il est difficile pour le Constructeur d’obtenir le droit de produire des Blocs, de sorte que la Pré-Confirmation fournie par le Constructeur Le service sera grandement compromis.

Si vous voulez éviter les problèmes ci-dessus, il est préférable que le Proposant fournisse le service de Pré-Confirmation, car le « quel Proposant proposera le premier Bloc » est généralement une situation pré-calculée et déterministe.

Cependant, étant donné que dans l’architecture PBS actuelle, le Proposant ne propose que le rôle de Bloc, et que le rôle de créer un Bloc et de déterminer le contenu du Bloc est le Constructeur, de sorte que le Proposant ne peut pas directement insérer une transaction dans un Bloc ou demander au Constructeur de bourrer une transaction. Lorsque l’architecture PBS changera à l’avenir, par exemple en ajoutant une liste d’inclusion ou en permettant aux soumissionnaires de participer à la production de blocs, le soumissionnaire aura la possibilité de fournir des services de pré-confirmation.

Conseil de lecture > : Pour plus d’informations sur PBS, veuillez copier le lien ci-dessous pour lire dans votre navigateur : _4j_-TweXHX_LMag656k_pAyJWIBXpEDrzpUfVsss.

Améliorer la pré-confirmation

La pré-confirmation n’est qu’une promesse verbale du constructeur ou du séquenceur L2, et l’autre partie n’a aucune obligation de remplir la promesse, et il n’y a pas de mécanisme de pénalité en cas de non-exécution.

Est-il possible de rendre cette promesse plus assurée ? En fait, oui, parce que la personne responsable de la production du bloc et le contenu de sa promesse (par exemple, « dans le bloc 1 350 000 la transaction de revenus ») peuvent être écrits comme un contrôle de condition. Par conséquent, nous pouvons utiliser le contrat intelligent pour réguler le Builder ou le Séquenceur, leur demander de fournir des services de pré-confirmation lors de la garantie du dépôt dans le Smart Contract, et signer le contenu lors de la promesse de revenus de transaction, lorsque l’utilisateur constate que le Builder ou le Séquenceur n’a pas rempli l’engagement, le contenu promis et la signature de l’autre partie peuvent être envoyés au Smart Contract, et le Smart Contract peut vérifier si l’engagement a été respecté (par exemple, « dans le premier 1 350 000 Block Revenue pour cette transaction »).

Bien que le scénario d’application du contrat ci-dessus soit encore au stade de la preuve de concept, la vidéo de présentation présentée dans le lien ci-dessous donne un exemple de l’une des demandes de contrat, veuillez copier le lien ci-dessous pour afficher les détails dans votre navigateur :

Résumé

• Une fois que les transactions L1 sont incluses dans les blocs L1, la probabilité de réorganisation diminuera progressivement et la confiance des utilisateurs dans les revenus des transactions augmentera progressivement.
• Un flux de travail de transaction de plus pour les transactions L2 que pour les transactions L1 est l’étape où les transactions L2 sont incluses dans les blocs L2 et attendent d’être téléchargées vers L1.
• Cependant, dans le flux de travail transactionnel où les transactions L2 sont plus que les transactions L1, parce que les données n’ont pas encore été téléchargées vers L1 à ce stade, il y a toujours la possibilité de variables, de sorte que la garantie de revenu de transaction que les utilisateurs peuvent obtenir à ce stade est la promesse verbale de Sequencer, qui est appelée Pre-Confirmation ou Fast Confirmation, Soft Confirmation.
• Si Sequencer est malveillant, ou s’il y a un simple bogue, alors la promesse faite par Sequencer peut être violée, ce qui n’entraîne aucune reconnaissance des revenus pour les transactions L2 de l’utilisateur.
• Actuellement, la plupart des statuts de transaction L2 dans leur Explorateur incluent un statut de pré-confirmation, tel que Confirmé par Sequencer pour Arbitrum/Optimism ou Accepté sur L2 pour StarkNet. Lorsque vous voyez de telles informations, veuillez prêter attention à la validité temporelle de la garantie de revenus de transaction fournie par ces informations.
• Si vous ne souhaitez pas faire confiance à la pré-confirmation fournie par Sequencer, vous devrez attendre un peu plus longtemps et vérifier avec les informations fournies par l’explorateur L2 que les données L2 sont téléchargées vers L1.
• La pré-confirmation peut être couplée à la conception d’incitations économiques, telles que des pénalités par le biais d’un contrat intelligent lorsque Sequencer viole les engagements, afin que les utilisateurs puissent obtenir une protection plus claire.

Le tableau ci-dessous illustre la garantie de revenus de transaction et les scénarios de risque correspondants fournis par les transactions de niveau 1 et les transactions de niveau 2 à différentes étapes du processus de transaction :