Aller au contenu
Financial Context Wiki

Optimistic rollups

Guide propre à chaque déploiement sur les reçus du séquenceur, les données de dérivation L1, les têtes unsafe/safe/finalized, les jeux de fault proofs, les retraits canoniques, la gouvernance et les sorties rapides.

Mis à jour

À des fins éducatives uniquement ; ne constitue ni un conseil en investissement ni une recommandation d’investissement. Les investissements peuvent entraîner des pertes.

Réponse directe

Un optimistic rollup exécute un flux ordonné de transactions et publie les données de dérivation et state claims définis par le protocole, sans joindre une preuve de validité à chaque lot. « Optimistic » signifie qu’un claim admissible peut progresser selon les règles déployées, sauf si une contestation par fault proof aboutit et établit qu’il est erroné. Cela ne signifie ni qu’un message du séquenceur prouve la correction, ni que toute implémentation propose des contestations permissionless ou le même délai de retrait.

Les nœuds du rollup dérivent indépendamment les blocs L2 à partir des entrées L1 canoniques et de la configuration exacte du protocole. Le chemin de sécurité comprend donc la disponibilité des données, une dérivation et une exécution correctes, un système de fault proof actif et fiable, l’accès à L1 et sa finalité, la gouvernance et les contrats du bridge. Une state root seule ne suffit pas à reconstruire la chaîne ni à contester une transition invalide.

1
Séquence

Le séquenceur ordonne les transactions L2 et publie les données de transaction ou les engagements.

Fonctionnement

  1. Identifiez le déploiement : chain IDs L1 et L2, configuration et fork du rollup, contrats inbox et bridge, format des lots et mode de DA, contrats de state claim et de jeu de contestation, version du portal, administrateurs, guardians et bloc d’observation. La documentation d’une stack ne prouve pas que chaque fonction est active sur une chaîne donnée.
  2. Classez l’état observé. Un reçu du séquenceur ou bloc unsafe est un engagement local et rapide sur l’ordre ; un lot publié sur L1 peut étayer une tête dérivée safe ; la finalité de L1 peut étayer une tête dérivée finalized. Un state ou output claim, une contestation résolue et un retrait exécutable sont des objets et des délais distincts.
  3. Reconstruisez la dérivation de L1 vers L2. Vérifiez les dépôts et entrées séquencées, canaux et lots, origines L1, changements de configuration et transitions d’état à partir des données L1 canoniques. Pour les données portées par des blobs, distinguez leur disponibilité pendant la fenêtre du protocole de leur récupération archivistique ultérieure.
  4. Cartographiez la vivacité et le contrôle. Séparez séquenceur, batcher, proposer, challenger, relayer, guardian et autorité d’upgrade ; vérifiez l’existence des voies forced inclusion ou delayed inbox, leurs délais et conditions de pause, ainsi que les logiciels effectivement utilisables par les utilisateurs ordinaires.
  5. Vérifiez le chemin de fault proof déployé. Relevez le type de jeu respecté, les autorisations du proposer et du challenger, les bonds, le prestate absolu, le programme de preuve et la VM, le preimage oracle, la profondeur des claims, les horloges et extensions, les règles de résolution, les pouvoirs de blacklist ou de pause et le délai d’upgrade. Ne transposez pas les mécanismes d’OP Stack à Arbitrum ou à un autre rollup.
  6. Suivez séparément les retraits et leur économie. Retracez l’initiation sur L2, la preuve sur L1, la dépendance au claim ou au jeu, les délais de maturité et de finalité, la nouvelle preuve éventuelle, les contrôles du portal et l’exécution sur L1. Une sortie rapide est une opération de liquidité ou de crédit tarifée avec une contrepartie propre, et non un raccourcissement du délai canonique de contestation.
  7. Réconciliez en continu. Comparez les hash des blocs unsafe, safe et finalized, les transactions de lot L1, les state claims, les résultats des jeux, les messages du bridge, les reçus, les contrats de tokens et les soldes finaux. Reprenez l’analyse après une réorganisation L1 ou L2, un lot manquant, une contestation, une pause, un upgrade de contrat ou une migration de DA.

Exemples détaillés

  • Payload de dérivation. Un lot contient 10,000 transactions, 1,200 KB d’entrées brutes du protocole et 300 KB après compression. Le ratio est 1,200 / 300 = 4.0x, la réduction est 1 - 300 / 1,200 = 75% et la moyenne décimale est 300,000 / 10,000 = 30 bytes/tx. Ces chiffres ne décrivent que le payload d’entrée encodé, pas le gas L1, la correction de l’exécution, la taille de l’état ni les garanties d’archivage.
  • Contribution avant les coûts omis. Les utilisateurs paient 2.4 ETH ; l’exécution L2 mesurée coûte 0.3 ETH ; la DA sur L1 coûte 1.2 ETH. Le résidu est 2.4 - 0.3 - 1.2 = 0.9 ETH, soit 0.9 / 10,000 = 0.00009 ETH/tx. Ce n’est pas un bénéfice net car l’infrastructure de l’opérateur, l’exécution L1, les jeux de preuve, les remboursements, le capital, les défaillances et les impôts sont omis.
  • Localisation de la contestation. Une trace pédagogique d’exécution compte 2^20 = 1,048,576 étapes. Un resserrement binaire idéal exige log2(2^20) = 20 choix pour isoler une étape. Si chaque manche pédagogique avait un maximum distinct de 3-hour, une borne séquentielle naïve serait 20 * 3 = 60 hours ; les protocoles réels utilisent leurs propres horloges d’échecs, la concurrence, des extensions et un calendrier de transactions.
  • Délais de retrait et liquidité rapide. Un lot pédagogique atteint L1 après 10 minutes, un claim reconnu apparaît 30 minutes plus tard, une période hypothétique de contestation dure 7 days et le relay final prend 2 hours. Le temps séquentiel est 10 + 30 + 10,080 + 120 = 10,240 minutes = 7 days 2 hours 40 minutes. Un bridge de liquidité qui avance 4.97 ETH sur un claim de 5 ETH facture 0.03 ETH, soit 0.03 / 5 = 0.6%, tandis que le claim canonique reste soumis à ses délais et risques d’origine.

Risques

  • L1, L2, chain IDs, configuration du rollup ou contrats de déploiement erronés.
  • Assimiler un reçu unsafe du séquenceur à un état safe ou final.
  • Équivocation, censure, réordonnancement ou panne du séquenceur.
  • Publication L1 du lot retardée, manquante, malformée ou invalide.
  • Données de blobs ou d’une DA alternative indisponibles ou non archivées.
  • Divergence du client de dérivation, de la configuration ou du fork.
  • Réorganisation L1 invalidant des entrées de dérivation auparavant safe.
  • Panne du batcher, du state proposer ou d’un participant à la preuve.
  • Voie forced inclusion ou delayed inbox absente, en pause ou mal comprise.
  • Fault proofs non déployés, inactifs ou associés au mauvais type de jeu.
  • Rôles du proposer ou du challenger permissionnés ou sur allowlist.
  • Challenger hors ligne, censuré, sous-financé ou hors délai.
  • Bug du programme de preuve, de la VM, du prestate absolu, de l’oracle ou du verifier.
  • Erreur d’horloge, d’extension, de position du claim, de bond ou de comptabilisation de la résolution.
  • Intervention du guardian, du conseil de sécurité, d’une pause ou d’une blacklist.
  • Upgrade immédiat, timelock court ou clés administratives compromises.
  • Vulnérabilité du bridge canonique, du messenger, du replay ou du mapping d’actifs.
  • Échec de preuve, maturité, nouvelle preuve, finalisation ou relay du retrait.
  • Risque de liquidité, prix, routage, insolvabilité ou contrepartie de la sortie rapide.
  • Confusion entre finalité L1, finalité L2 dérivée, résolution du claim et réception de l’actif.

Idées reçues

  • Optimistic signifie que les utilisateurs font une confiance inconditionnelle au résultat affiché par le séquenceur.
  • Publier une state root seule fournit la disponibilité des données et une dérivation indépendante.
  • Tout optimistic rollup dispose de fault proofs permissionless actifs et d’un délai universel de sept jours.
  • Un bloc L2 safe ou finalized signifie que son retrait de L2 vers L1 est déjà exécutable.
  • Un bridge rapide raccourcit la période canonique de contestation ou ne porte que le risque du rollup.

Sujets connexes

Sources

Navigation

Rechercher dans le wiki...