Aller au contenu
Financial Context Wiki

Preuve de faute (preuve de fraude)

Guide propre au déploiement sur les preuves de faute optimistes, claims contestés, bissection de traces, vérification en une étape, horloges, cautions, disponibilité des données, finalité des retraits et vérification opérationnelle.

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

Une preuve de faute, souvent appelée preuve de fraude, est le processus protocolaire permettant de contester un claim optimiste sur un calcul ou un état. Le proposant ne prouve pas chaque transition avant acceptation : un challenger éligible peut présenter une trace contradictoire dans les délais impartis, puis le contrat de règlement tranche avec un vérificateur défini. De nombreux dispositifs interactifs réduisent successivement une longue trace à une instruction litigieuse et exécutent ce cas de base on-chain.

Le nom ne prouve pas qu’un déploiement soit permissionless, disponible ou sûr. Il faut les données exactes de dérivation, au moins un challenger correct capable de reconstruire le claim et d’agir à temps, un accès et du gas suffisants sur la chaîne de règlement, des programmes et contrats corrects et une gouvernance qui ne puisse contourner l’issue. Un claim qui survit à son jeu peut autoriser un retrait selon ces règles ; il ne prouve pas rétroactivement toute transaction L2 ni tout résultat économique.

1
Séquence

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

Fonctionnement

  1. Figer le déploiement : identifiants L1/L2, versions, hashes, factory, portal ou bridge, programme de preuve, VM, type de jeu, implémentations et administrateurs, permissions, cautions, profondeur, horloges, délais, pause et finalité. fraud proof n’est pas une spécification commune aux rollups.
  2. Reconstruire le claim depuis des entrées authentifiées : état d’ancrage, tête L1, bloc L2 ou output root contesté, données de batch et blobs, configuration, pré-état, racine des retraits et règles de dérivation. Une racine d’état ne suffit pas ; des données indisponibles peuvent neutraliser une contestation ouverte.
  3. Vérifier que le jeu existe et peut affecter l’objet visé : root claim, proposant, bloc et heure, type, statut respecté ou blacklisté, caution, éligibilité et règle réelle du portal. Séparer claim pending, issue du jeu et output utilisable pour un retrait.
  4. Réexécuter avec un nœud et une implémentation indépendants. Comparer la trace correcte et conserver préimages, témoins et versions. Dans un jeu interactif, attaquer ou défendre le bon intervalle jusqu’à isoler une instruction, puis soumettre le témoin de base au vérificateur VM on-chain.
  5. Suivre l’horloge de chaque équipe et chaque transaction : temps restant, extensions, inclusion et réorganisation L1, calldata, gas, remplacement, caution, claims parallèles et responsable de la réponse. La durée n’est pas toujours un compte à rebours unique ; une position correcte peut perdre par retard ou censure.
  6. Relier la résolution à ses conséquences : claims réfutés, équipe gagnante, distribution des cautions et coûts, exclusion d’un output invalide et reconstruction des outputs, preuves ou retraits dépendants. Une caution confisquée incite, mais n’indemnise pas toutes les pertes d’un bridge.
  7. Rapprocher séparément finalité et retraits : résolution, délais de maturité et post-résolution, type respecté, blacklist et pause, preuve d’inclusion, reçu de finalisation et finalité L1. Archiver les preuves et répéter contestation, inclusion forcée, nouvelle preuve et sortie d’urgence.

Exemples détaillés

  • Bissection de trace. Une trace pédagogique compte 1,048,576 = 2^20 instructions. Si chaque tour incontesté divise l’intervalle par deux, 20 bisections isolent une instruction car 2^20 / 2^20 = 1. Les jeux réels peuvent séparer plusieurs traces, former un DAG ou imposer des coups supplémentaires ; ce n’est pas un nombre universel de tours.
  • Horloges indépendantes. Un jeu hypothétique accorde 84 hours à chaque équipe. Le défenseur consomme 30 hours et le challenger 22 hours, laissant respectivement 54 hours et 62 hours. Le temps écoulé n’est pas simplement 84 hours : seule l’horloge applicable avance, et extensions, délais d’inclusion et claims parallèles modifient l’échéance.
  • Registre de caution et de gas. Selon une règle explicitement hypothétique, une racine invalide porte une caution de 2 ETH. Le gagnant a déposé 0.5 ETH, récupère ce principal plus 1.4 ETH, après 0.08 ETH de gas L1 ; 0.6 ETH va à la trésorerie. Gain net : 1.4 - 0.08 = 1.32 ETH ; les 0.5 ETH rendus ne sont pas un bénéfice et 1.4 + 0.6 = 2 ETH. Les bénéficiaires et règles anti-opportunistes dépendent du contrat.
  • Horloges de retrait. Preuve le 2026-08-01 12:00 UTC, maturité de 7 days, résolution le 2026-08-06 18:00 UTC, délai post-résolution de 1 day. Les deux seuils prennent fin le 2026-08-08 12:00 UTC et le 2026-08-07 18:00 UTC ; le premier instant qui satisfait les deux est 2026-08-08 12:00 UTC. Avec 20 minutes de finalité L1, l’achèvement économique intervient à 2026-08-08 12:20 UTC, hors pause, blacklist, nouvelle preuve ou réorganisation.

Risques

  • Auditer la mauvaise L1, L2, version, implantation ou type de jeu.
  • Reconstruire depuis un ancrage ou une tête L1 périmés ou non canoniques.
  • Manquer batch, blob, préimage, témoin d’état ou configuration.
  • Assimiler engagement ou entrée disponible à toutes les données de dérivation.
  • Obtenir une autre trace correcte à cause d’un bug du client challenger.
  • Bugs du programme, de la VM, de l’oracle de préimages ou du vérificateur.
  • Proposant, challenger ou création permissionnés indisponibles ou capturés.
  • Aucun observateur honnête n’ouvre de contestation avant l’échéance.
  • Censure, congestion, réorganisation ou gas L1 empêchent un coup à temps.
  • Mal lire horloges, extensions, profondeur ou temps d’inclusion.
  • Attaquer ou défendre le mauvais claim, intervalle, emplacement ou pas.
  • Cautions ou fonds de roulement rendent la participation impraticable.
  • Distribution, opportunistes ou incitations divergent des hypothèses.
  • Jeux multiples, claims dupliqués ou implémentations contradictoires.
  • Gouvernance modifie type respecté, vérificateur, seuil ou délai.
  • Pause ou blacklist du Guardian bloque des retraits valides.
  • Confondre résolution du jeu et finalité immédiate du retrait.
  • Prouver contre un jeu invalidé sans produire une nouvelle preuve.
  • Croire que rejeter un output répare tous les effets en aval.
  • Extrapoler le modèle d’un rollup optimiste à un autre.

Idées reçues

  • Un claim optimiste non contesté a été prouvé cryptographiquement.
  • Chacun peut contester tout déploiement sans permission, capital ni infrastructure.
  • Une preuve de faute fonctionne sans données de dérivation disponibles.
  • Gagner finalise instantanément tout retrait et rembourse toute perte.
  • Sept jours, jeu binaire et un observateur honnête sont des constantes universelles.

Sujets connexes

Sources

Navigation

Rechercher dans le wiki...