Nous remercions tout particulièrement Jon Charbonneau et Conor McMenamin pour la relecture de cet article.

À ce stade, nous devrions tous savoir que ce sont les règles de confirmation qui assurent la sécurité, et non les rollups eux-mêmes. Lorsque nous disons que les rollups héritent de la "sécurité Ethereum" ou qu'ils sont "trust-minimized", ce que nous voulons dire en réalité, c'est qu'il est possible d'utiliser sur les rollups des règles de confirmation qui ont à peu près la même sécurité que les règles de confirmation Ethereum. Les explorateurs de blocs, quant à eux, se contentent d'afficher un badge vert sans entrer dans les détails de la règle de confirmation à laquelle ils se réfèrent ou des propriétés de sécurité qu'ils offrent.

Chez L2BEAT, nous voulons nous attaquer à ce problème et le rendre accessible à tous. En particulier, nous voulons nous concentrer sur la finalité, la règle de confirmation la plus forte contre les attaques par double dépense.

Règles de confirmation : cohérence ou disponibilité

Les règles de confirmation sont des algorithmes qui, selon des hypothèses spécifiques, indiquent quand un bloc est confirmé et peu susceptible d'être reformé. Une fois qu'un bloc est confirmé, les actions liées à ses transactions peuvent être entreprises. Il peut s'agir, par exemple, de remettre un café à un client ou de livrer une voiture à son acheteur.

Différentes règles de confirmation offrent aux utilisateurs des garanties de sécurité différentes. La sécurité d'une règle de confirmation comprend la cohérence et la disponibilité et dépend fortement des algorithmes de consensus sous-jacents :

• Cohérence (sécurité) : la vue de deux nœuds quelconques est cohérente en cas de partition du réseau.
• Disponibilité (liveness) : les transactions continuent d'être incluses dans le grand livre dans un certain délai, même après qu'une fraction substantielle des nœuds a cessé de participer au protocole.

Le théorème CAP nous indique qu'il n'est pas possible de concevoir un algorithme de consensus qui reste à la fois cohérent en cas de partition du réseau et disponible en cas de participation dynamique : si une partition sérieuse du réseau se produit, les nœuds peuvent soit décider de continuer à produire des blocs et perdre leur cohérence, soit s'arrêter et perdre leur disponibilité. Les nœuds n'ont aucun moyen de distinguer les autres nœuds qui sont simplement hors ligne (participation dynamique) ou qui sont actifs mais injoignables (partitions du réseau) et il n'est donc pas possible d'agir différemment.

Eve ne peut pas savoir si Bob est simplement hors ligne ou s'il se trouve sur une autre partition du réseau.

Les chaînes de blocs comme Bitcoin, qui utilisent un consensus de type Nakamoto, favorisent la permanence, ce qui signifie que lors d'une division du réseau, les deux parties continueront à produire des blocs et finiront par se réorganiser si la partition est résolue, tandis que d'autres chaînes comme Cosmos, qui utilisent un consensus de type PBFT, s'arrêtent en cas de division du réseau afin de préserver la cohérence.

Règles de confirmation sur Ethereum

Ethereum donne la priorité à la disponibilité dans les partitions du réseau à l'aide de l'algorithme LMD GHOST. Cette approche signifie que des nœuds honnêtes peuvent avoir des points de vue différents sur l'extrémité de la chaîne et peuvent confirmer des blocs différents pour la même hauteur, ce qui peut conduire à des réorganisations.

Dans des conditions de réseau favorables, Ethereum vise également à fournir des garanties de cohérence par le biais de la finalité, en utilisant le protocole Casper FFG. La finalité est la règle de confirmation la plus forte possible, les nœuds ayant une règle codée en dur pour ne jamais réorganiser les blocs finalisés.

Le grand livre finalisé (vert) est toujours un préfixe du grand livre en cours (bleu).

Les garanties de finalité sont compromises si deux blocs conflictuels sont finalisés, ce qui peut se produire si plus d'un tiers des validateurs agissent de manière malveillante. Cependant, sur Ethereum, de telles actions s'accompagnent d'une pénalité importante, à savoir la perte de leur mise.

Les utilisateurs peuvent choisir d'utiliser le Casper FFG comme règle de confirmation la plus sûre ou de se fier au LMD GHOST. Les règles de confirmation pour LMD GHOST, à l'instar de la règle de confirmation k dans Bitcoin, peuvent être plus sophistiquées que le simple fait de vérifier si la transaction est incluse dans le grand livre, comme le prévoit la règle de confirmation Safe Block.

Règles de confirmation pour les rollups

Les rollups peuvent, en principe, utiliser les mêmes règles de confirmation que celles disponibles sur Ethereum. Si vous envoyez une transaction sur un rollup et que vous voyez plus tard la même transaction affichée sur L1 dans un bloc finalisé, vous pouvez également considérer la transaction L2 comme finale. Il s'avère que l'histoire est beaucoup plus complexe que cela.

Rollups de données de transaction

Sur Ethereum, les blocs comprennent à la fois la liste des transactions et la racine d'état proposée dans l'en-tête du bloc. Si l'exécution des transactions ne conduit pas à l'état que représente la racine, le bloc entier est rejeté, y compris les transactions qui peuvent être ajoutées ultérieurement à d'autres blocs dans un ordre différent.

Sur les rollups, comme les actions de publication des données et des racines sont découplées, les transactions n'ont pas besoin d'être rejetées en fonction de la validité des racines d'état correspondantes. Compte tenu de cette séparation, il suffit de vérifier si les transactions sont finalisées sans attendre la finalisation de la racine de l'état, en contournant les délais supplémentaires tels que la période de contestation de 7 jours dans les rollups optimistes.

rollup des diffs d'état

Les différences d'état sont des sorties d'une fonction de transition d'état, et pour valider qu'elles sont effectivement valides, il faut attendre une preuve ZK. La génération de preuves ZK prend du temps et, en outre, il existe une incitation à retarder davantage pour inclure plus de transactions dans une seule preuve afin de mieux amortir les coûts de la génération et de la vérification des preuves.

Les techniques d'agrégation de preuves offrent une solution à ce compromis entre les délais de confirmation et l'amortissement des coûts : même si un rollup connaît une activité minimale, il peut toujours bénéficier de l'amortissement en incluant dans la même preuve des transactions provenant de rollups plus actifs. Un exemple de cette approche est SHARP de Starkware, qui regroupe actuellement des preuves provenant de Starknet, Paradex et StarkEx, ainsi que des rollups comme dYdX et même Validiums.

Là où les choses se compliquent

Spécification de dérivation du rollup

Si un rollup n'est pas basé, l'ordre de dérivation des lots peut être défini par le séquenceur du rollup, qui peut les publier dans un ordre différent sur L1.

À titre d'exemple, les chaînes OP Stack publient des lots sur L1 qui sont liés à l'aide des hachages du lot précédent. Ces lots ne doivent pas nécessairement être publiés dans l'ordre chronologique, ce qui entraîne une fenêtre de séquençage de 12 heures pendant laquelle les nœuds attendent les transactions potentiellement manquantes. Les transactions ne doivent pas être considérées comme incluses simplement parce qu'elles sont publiées sur L1 : si un lot n'est pas encore connecté à la chaîne canonique des lots, il y a un risque qu'une fourche alternative avec un ordre différent ou un ensemble de transactions soit construite.

Sur les chaînes OP Stack, le temps de blocage est de 2 secondes, ce qui donne 6 blocs dans chaque bloc Ethereum. Ce regroupement de 6 blocs entre les blocs Ethereum est appelé "époque". Les messages L1 à L2 soumis via L1 sont inclus dans la première partie du premier bloc de l'époque correspondante pour le bloc L1 donné. Bien que ces transactions puissent être considérées comme confirmées sans attendre la fin de la fenêtre de séquençage, étant donné que leur ordre dans le grand livre L2 au moment de la dérivation est connu, il est important de noter que les nœuds ne commenceront pas à calculer les blocs contenant ces messages si un lot précédent est manquant. En effet, l'état ne peut être calculé sans la séquence complète et, par conséquent, les racines de l'état ne seront pas non plus publiées sur L1.

Il en résulte que le simple examen des données de la chaîne est insuffisant pour suivre les délais de confirmation de la L1. Il est également nécessaire de comprendre comment les blocs L2 sont dérivés des données L1 en examinant le logiciel du nœud de rollup lui-même.

Fonctions autorisées

Scroll est un rollup ZK qui affiche les données de la transaction, ce qui signifie qu'en principe, il n'est pas nécessaire d'attendre une preuve ZK pour considérer que la transaction est définitive. Cela aurait été vrai s'ils n'avaient pas mis en place une fonction pour supprimer les lots qui n'ont pas encore été prouvés.

https://etherscan.io/address/0x2e07f0fba71709bb5e1f045b02152e45b451d75f#code#F1#L260

Il en va de même pour les rollups qui affichent des différences d'état : zkSync Era et zkSync Lite ont un processus en trois étapes pour afficher des différences d'état : d'abord, ils engagent les données sans aucune preuve, ensuite ils fournissent une preuve pour ces données, et enfin, après un délai de 24 heures, la racine devient disponible pour être exécutée afin de traiter les retraits. En théorie, lorsqu'une preuve est fournie, l'ordre des transactions est fixé, de sorte qu'il n'est pas nécessaire d'attendre que le délai d'exécution soit écoulé. Sauf que zkSync peut inverser ces blocs :

https://etherscan.io/address/0x7Ed066718Dfb1b2B04D94780Eca92b67ECF3330b#code#F10#L425

Alors que pour zkSync Era aucun bloc n'a jamais été annulé, cela s'est produit 8 fois pour zkSync Lite.

Finalité observabilité

Étant donné que les différences d'état des rollups n'affichent pas les données de transaction, comment pouvons-nous vérifier qu'une transaction a bien été incluse ? Oui, nous pourrions suivre les effets, comme les nonces de compte, mais le cas général devient délicat. Il y a un mois, j'ai posé la question suivante :

Jetons un coup d'œil à quelques-unes des réponses :

Cette solution fonctionne si le séquenceur est disposé à vous répondre et si vous lui faites confiance. Et si ce n'est pas le cas ? Ou, si c'est le cas, mais que vous ne lui faites pas confiance ? Comment vérifiez-vous que la demande est correcte ?

Ma réponse préférée.

Une solution qui fonctionne réellement a été proposée ici :

Bien que cela fonctionne, cela signifie que la décision technique d'utiliser les différences d'état s'infiltre dans la logique de l'application, ce qui signifie que même si un rollup est équivalent à l'EVM, les projets doivent adapter leur contrat à cette considération.

Une solution partielle consiste à afficher une racine de transactions et à vérifier leur validité à l'intérieur de la preuve ZK. Même dans ce cas, il faut compter sur le séquenceur pour obtenir le chemin de Merkle nécessaire, ce qui peut être raisonnable avec des séquenceurs centralisés réputés, mais devient plus délicat dans un environnement sans autorisation.

Métriques de concordance

En guise de première étape vers le suivi des délais de finalisation des transactions de rollup, nous avons commencé à suivre sur L2BEAT les métriques de vivacité, en particulier les intervalles entre les lots de transactions (le cas échéant) et les racines d'état. En effet, si un rollup n'interagit avec L1 qu'une fois par mois, par exemple, les utilisateurs ne peuvent pas s'attendre à ce que le délai de finalisation soit de l'ordre de quelques minutes. Les mesures d'actualité peuvent être considérées comme un indicateur de la limite inférieure du délai de finalisation : si un rollup de données de transaction enregistre des lots toutes les deux minutes, et en supposant que la distribution des transactions L2 est uniforme, le délai de finalisation attendu n'est pas inférieur à une minute.

Voici quelques exemples de données que nous suivons pour zkSync Era (mises à jour de l'état) et OP Mainnet (lots tx) :

zkSync Era a réalisé des mesures de vivacité pour le mois de septembre.

OP Mainnet liveness metrics pour le mois de septembre.

Comme prévu, étant donné que les preuves ZK prennent du temps à être générées et qu'il y a une incitation à inclure plus de transactions dans une seule preuve, zkSync Era a de moins bonnes mesures de vivacité qu'OP Mainnet. Il est important de garder à l'esprit que, comme nous l'avons vu dans les sections précédentes, les mesures de vivacité ne se traduisent pas directement par des considérations de finalité : dans le pire des cas, l'OP Mainnet a en fait un temps de finalité plus élevé en raison de sa fenêtre de séquençage.

Vous pouvez maintenant explorer les métriques de vivacité pour la plupart des rollups sur L2BEAT:

Limites de la traçabilité

Si le caractère permanent peut être considéré comme un indicateur de la limite inférieure de la finalité, il peut parfois s'agir d'un très mauvais indicateur. Imaginez un rollup avec un temps de blocage de 4 secondes, ce qui signifie que pour chaque bloc Ethereum, il y a 3 blocs de rollup. Si l'opérateur du rollup n'affiche que deux blocs L2 par bloc L1, même si, du point de vue d'Ethereum, le rollup est très actif, il prendra de plus en plus de retard par rapport aux confirmations douces L2 et le délai de finalisation se dégradera de plus en plus. Bien qu'il s'agisse d'un scénario extrême, c'est un élément dont les rollups doivent tenir compte.

Un exemple pratique est celui de Starknet : bien que nous observions une moyenne de 32 secondes entre les mises à jour de l'état, le temps nécessaire pour atteindre la finalité est en fait proche de 6 heures :

Source : starkscan.co

En effet, Starknet publie une mise à jour de l'état de la racine pour chaque bloc L2 sur L1. Toutefois, pour ce faire, ils doivent se référer à une preuve SHARP, qui est généralement affichée toutes les 30 minutes environ. En outre, ces preuves ont environ 6 heures de retard sur l'extrémité de la chaîne de confirmation souple L2.

Confirmations en douceur

Les confirmations douces sont des règles de confirmation utilisées pour raccourcir les délais de confirmation en L2 au détriment des garanties de sécurité. Actuellement, dans tous les cas, les soft confirmations impliquent de faire confiance à l'opérateur centralisé pour qu'il n'affiche pas différents tx sur L1. Les confirmations logicielles incorrectes sont des fautes attribuables, c'est pourquoi des mécanismes de suivi de la réputation des séquenceurs hors chaîne ou dans la chaîne peuvent être mis en œuvre. En collaboration avec Nethermind, nous prévoyons d'estimer ces propriétés de sécurité et de suivre le montant de la valeur à risque à tout moment.

A gauche : garanties économiques sur Starknet s'ils avaient des confirmations douces sécurisées par un mécanisme d'abattage. À droite : valeur totale risquant d'être réorganisée au fil du temps.

Aller de l'avant

Le suivi du temps écoulé jusqu'à la fin de la procédure est une tâche complexe. Notre première étape consiste à contrôler les intervalles entre les soumissions de preuves pour les rollups ZK, qui imposent une limite inférieure plus élevée sur le temps de finalité par rapport aux intervalles entre les soumissions de racines d'état. Ensuite, nous prévoyons d'introduire des graphiques affichant des données historiques pour chaque projet. Par la suite, notre recherche se concentrera sur tous les mécanismes supplémentaires qui doivent être pris en compte pour parvenir à des mesures en temps réel du délai d'exécution. Restez à l'écoute !

Clause de non-responsabilité：

1. Cet article est repris de[medium]. Tous les droits d'auteur appartiennent à l'auteur original[Luca Donno]. Si vous avez des objections à cette réimpression, veuillez contacter l'équipe de Gate Learn, qui s'en chargera rapidement.
2. Clause de non-responsabilité : Les points de vue et les opinions exprimés dans cet article sont uniquement ceux de l'auteur et ne constituent pas un conseil en investissement.
3. Les traductions de l'article dans d'autres langues sont effectuées par l'équipe de Gate Learn. Sauf mention contraire, il est interdit de copier, distribuer ou plagier les articles traduits.