Analyse du processus d'exécution des transactions Layer 2 : évaluation de la sécurité à chaque étape
La technologie Layer 2(L2) a apporté une plus grande évolutivité à Ethereum, mais a également augmenté la complexité de la confirmation des transactions. Cet article décrira en détail le processus d'exécution complet des transactions L2 et analysera la sécurité à chaque étape.
Revue du processus de transaction L1
Après que l'utilisateur a envoyé la transaction, il doit attendre que les mineurs ou les validateurs l'incorporent dans un bloc. Même si la transaction a été incluse, il faut encore attendre un certain nombre de blocs de confirmation pour réduire le risque de réorganisation (Re-org). Ce n'est que lorsque la probabilité de réorganisation est suffisamment faible que la transaction peut être considérée comme définitivement confirmée.
Détails du processus de transaction L2
Le processus de transaction L2 par rapport à L1 a un élément supplémentaire :
L'utilisateur envoie une transaction au Séquenceur
Le séquenceur regroupe les transactions dans un bloc L2
Le séquenceur soumet les données de bloc L2 à L1
Attendre la confirmation L1
Les étapes 2 et 3 sont spécifiques au L2. À ce stade, la transaction n'est pas encore sur la blockchain, et les utilisateurs doivent se fier à la promesse du Séquenceur, ce qui est appelé "pré-confirmation" ( Pre-Confirmation ).
Mécanisme de confirmation des transactions des solutions L2 mainstream
Arbitrum/Optimism
Les reçus de transaction peuvent être obtenus presque instantanément, c'est la pré-confirmation du Sequencer.
Explorer affichera l'état de la transaction, y compris "Confirmé par le séquenceur" et le nombre de confirmations L1.
Optimism affichera également l'état de finalité L1
StarkNet
L'état de la transaction comprend Reçu, En attente, Accepté sur L2, Accepté sur L1
Le temps de confirmation de L2 à L1 est relativement long, environ 4 à 5 heures.
L'explorateur n'affiche pas les informations de finalité L1
zkSync
Les statuts de transaction incluent Pending, zkSync Era Processed, Committed, Proven, Executed
Divisez le processus de L2 à L1 en trois étapes
L'Explorer fournit des informations détaillées à chaque étape.
Mécanisme de préconfirmation L1
Si l'on pouvait connaître à l'avance le producteur de blocs, L1 pourrait également prendre en charge la préconfirmation. Dans l'architecture PBS, le Builder peut fournir un service de préconfirmation, mais son efficacité est relativement faible. À l'avenir, si le Proposer peut participer à la création de blocs, le mécanisme de préconfirmation pourrait devenir plus fiable.
Améliorer le mécanisme de pré-confirmation
Il est possible de permettre au Builder ou au Sequencer de déposer une caution via un contrat intelligent et de signer le contenu de l'engagement. En cas de violation de l'engagement, l'utilisateur peut soumettre des preuves et punir l'autre partie, augmentant ainsi la crédibilité de la pré-confirmation.
Résumé
Les transactions L2 ont une étape supplémentaire d'attente pour être téléchargées sur L1 par rapport aux transactions L1.
Avant de télécharger L1, les utilisateurs ne peuvent compter que sur la pré-confirmation du Sequencer.
La plupart des explorateurs L2 afficheront l'état de pré-confirmation.
Attendre le téléchargement des données L2 sur L1 est la meilleure pratique en matière de sécurité.
Il est possible d'améliorer la fiabilité des pré-confirmations grâce à des mécanismes d'incitation économique.
Le tableau ci-dessous résume les garanties de confirmation et les risques des transactions L1 et L2 à chaque étape :
| Phase | Transactions L1 | Transactions L2 |
|------|--------|--------|
| Envoyer la transaction | Sans garantie | Sans garantie |
| Pré-confirmation | Builder s'engage ( à un avenir potentiel ) | Sequencer s'engage |
| Bloc de packaging | Garantie élevée | Garantie moyenne ( dépend de Sequencer ) |
| Télécharger L1 | - | Haute garantie |
| Plusieurs confirmations | Garantie très élevée | Garantie très élevée |
| Confirmation finale | Garantie maximale | Garantie maximale |
Cette page peut inclure du contenu de tiers fourni à des fins d'information uniquement. Gate ne garantit ni l'exactitude ni la validité de ces contenus, n’endosse pas les opinions exprimées, et ne fournit aucun conseil financier ou professionnel à travers ces informations. Voir la section Avertissement pour plus de détails.
Analyse de la sécurité du processus d'exécution complet du trading L2 : de la pré-confirmation à la confirmation finale.
Analyse du processus d'exécution des transactions Layer 2 : évaluation de la sécurité à chaque étape
La technologie Layer 2(L2) a apporté une plus grande évolutivité à Ethereum, mais a également augmenté la complexité de la confirmation des transactions. Cet article décrira en détail le processus d'exécution complet des transactions L2 et analysera la sécurité à chaque étape.
Revue du processus de transaction L1
Après que l'utilisateur a envoyé la transaction, il doit attendre que les mineurs ou les validateurs l'incorporent dans un bloc. Même si la transaction a été incluse, il faut encore attendre un certain nombre de blocs de confirmation pour réduire le risque de réorganisation (Re-org). Ce n'est que lorsque la probabilité de réorganisation est suffisamment faible que la transaction peut être considérée comme définitivement confirmée.
Détails du processus de transaction L2
Le processus de transaction L2 par rapport à L1 a un élément supplémentaire :
Les étapes 2 et 3 sont spécifiques au L2. À ce stade, la transaction n'est pas encore sur la blockchain, et les utilisateurs doivent se fier à la promesse du Séquenceur, ce qui est appelé "pré-confirmation" ( Pre-Confirmation ).
Mécanisme de confirmation des transactions des solutions L2 mainstream
Arbitrum/Optimism
StarkNet
zkSync
Mécanisme de préconfirmation L1
Si l'on pouvait connaître à l'avance le producteur de blocs, L1 pourrait également prendre en charge la préconfirmation. Dans l'architecture PBS, le Builder peut fournir un service de préconfirmation, mais son efficacité est relativement faible. À l'avenir, si le Proposer peut participer à la création de blocs, le mécanisme de préconfirmation pourrait devenir plus fiable.
Améliorer le mécanisme de pré-confirmation
Il est possible de permettre au Builder ou au Sequencer de déposer une caution via un contrat intelligent et de signer le contenu de l'engagement. En cas de violation de l'engagement, l'utilisateur peut soumettre des preuves et punir l'autre partie, augmentant ainsi la crédibilité de la pré-confirmation.
Résumé
Le tableau ci-dessous résume les garanties de confirmation et les risques des transactions L1 et L2 à chaque étape :
| Phase | Transactions L1 | Transactions L2 | |------|--------|--------| | Envoyer la transaction | Sans garantie | Sans garantie | | Pré-confirmation | Builder s'engage ( à un avenir potentiel ) | Sequencer s'engage | | Bloc de packaging | Garantie élevée | Garantie moyenne ( dépend de Sequencer ) | | Télécharger L1 | - | Haute garantie | | Plusieurs confirmations | Garantie très élevée | Garantie très élevée | | Confirmation finale | Garantie maximale | Garantie maximale |