Aller au contenu
Financial Context Wiki

Preuve de validité

Guide axé sur la vérification des preuves de validité, entrées publiques, témoins, hypothèses du système de preuve, transitions d’état des rollups, disponibilité des données, finalité et défaillances opérationnelles.

Mis à jour

À des fins éducatives uniquement ; ne constitue pas un conseil en investissement ou en sécurité. Une preuve de validité dépend de son énoncé, de la liaison des entrées publiques, du système de preuve, du vérificateur, de la disponibilité des données, des contrats, opérateurs, de la gouvernance et de la chaîne de règlement.

Réponse directe

Une preuve de validité est un élément cryptographique montrant qu’un calcul annoncé satisfait une relation précisément définie. Un vérificateur contrôle la preuve avec une clé de vérification et des entrées publiques. Dans un rollup, celles-ci lient souvent une ancienne racine d’état, une nouvelle racine proposée et les engagements d’un lot de transactions. Si la vérification réussit, le contrat de règlement peut accepter la nouvelle racine sans réexécuter chaque transaction.

La garantie est plus étroite que « le système est correct ». Elle dépend d’une cryptographie saine, du programme ou circuit prévu, du bon encodage des entrées, d’une clé authentique et de contrats corrects. La vérification seule ne prouve ni l’accès aux données, ni la disponibilité du prouveur, ni la finalité du bloc, ni l’innocuité d’une mise à niveau, ni le fonctionnement d’un retrait. Une preuve peut être à divulgation nulle, mais validité ne signifie pas confidentialité.

1
Exécuter

Le prouveur exécute un lot ou un calcul et enregistre la transition d'état résultante.

Fonctionnement

  1. Identifier le déploiement exact : ID L1 et L2, version, contrat d’état, adresse et bytecode du vérificateur, hash de clé, système, circuit ou programme, mode de disponibilité, pouvoirs administratifs, pause et politique de finalité. validity proof n’est pas une spécification universelle.
  2. Définir la relation avant d’interpréter. Sous les hypothèses de solidité, Verify(vk, x, proof) = 1 doit impliquer l’existence d’un témoin w tel que R(x, w) = 1. vk est la clé, x l’entrée publique complète et R les règles encodées. La preuve ne couvre que cette relation.
  3. Reconstruire indépendamment les entrées publiques. Confirmer l’ancienne racine acceptée ; dériver engagement du lot ou des données, identifiants, nouvelle racine, racines de messages ou retraits et paramètres à partir de données canoniques. Une preuve liée au mauvais objet prouve la mauvaise affirmation.
  4. Vérifier la preuve et le parcours contractuel. Exécuter un vérificateur indépendant, puis inspecter appel onchain, reçu, événement, numéro de lot et stockage. Confirmer que le contrat a appelé le vérificateur prévu sans contourner, simuler ou remplacer le résultat par mise à niveau ou branche privilégiée.
  5. Vérifier séparément la disponibilité des données. Récupérer transactions, différences d’état, blob sidecars ou données attestées exigées ; contrôler les engagements et reproduire transition ou témoin de sortie. Une preuve valide peut coexister avec des données indisponibles, notamment en validium.
  6. Séparer les états : générée, soumise, incluse, preuve vérifiée, état accepté, règlement sûr, finalisé et retrait achevé. Mesurer arriéré, coûts, disponibilité du séquenceur et du prouveur, inclusion L1, réorganisations, délais du pont, inclusion forcée et échappement.
  7. Conserver des preuves reproductibles : adresses et hashes de code, hashes de clé et programme, entrées complètes, octets de preuve ou référence durable, données du lot, commande et version, reçu, bloc finalisé et test de sortie réussi. Recontrôler après chaque mise à niveau.

Exemples chiffrés

  • Affirmation de lot. Un rollup traite 8,192 transfers. La preuve lie R0, R1 et B7. La réussite soutient : « un témoin satisfait ce circuit de R0 à R1 pour B7 ». Elle ne prouve ni l’accès aux octets de B7, ni toute inclusion, ni la finalité de R1.
  • Agrégation récursive. Un agrégateur vérifie 16 child proofs dans un circuit parent et soumet une preuve parente. Il faut encore contrôler chaque enfant, l’ordre et la correspondance des entrées publiques ; le nombre de preuves ne crée pas cette liaison.
  • Registre de gas hypothétique. Réexécuter coûterait 24,000,000 gas, vérifier 600,000 gas et publier les données 180,000 gas. Total : 600,000 + 180,000 = 780,000 gas, réduction modélisée de (24,000,000 - 780,000) / 24,000,000 = 96.75%. Matériel, agrégation, échecs, stockage, pont et conservation sont exclus.

Risques

  • Vérifier la mauvaise chaîne, le mauvais déploiement, lot, vérificateur, clé ou circuit.
  • Un système sain prouve fidèlement un circuit incomplet ou erroné.
  • Les entrées publiques omettent ou encodent mal ID, racine, lot, domaine de message ou paramètre.
  • Défaut du vérificateur, précompilé, bibliothèque non sûre ou implémentation incompatible.
  • Matériel de configuration compromis ou hypothèses cryptographiques invalidées.
  • Contrats évolutifs ou gouvernance remplacent vérificateur, clé, programme ou règle.
  • Contournements privilégiés, urgence, pauses ou listes blanches affaiblissent le parcours.
  • Bogue de génération, non-déterminisme ou témoins divergents entre clients.
  • Centralisation, censure, panne, arriéré ou matériel du prouveur bloque les mises à jour.
  • Transactions, différences d’état, blobs, préimages ou archives manquants.
  • Confondre signatures de comité ou engagement avec récupération actuelle des données.
  • Accepter une preuve issue d’un bloc non sûr, réorganisé ou non canonique.
  • Confondre acceptation de preuve avec retrait immédiat ou finalité économique.
  • Ne pas reproduire indépendamment transition, solde, message ou témoin de sortie.
  • Sous-estimer gas, frais de données, latence, délais du pont ou coûts de reprise.
  • Appliquer le modèle de preuve, disponibilité et mise à niveau d’un rollup à un autre.

Idées reçues

  • Une preuve vérifiée garantit tous les détails d’implémentation et soldes affichés.
  • Toute preuve de validité est à divulgation nulle et masque les transactions.
  • Les preuves éliminent les risques de données, de disponibilité du séquenceur et de censure.
  • La vérification rend immédiatement le règlement final et retirable.
  • Une preuve plus petite ou un vérificateur plus rapide rend automatiquement le système plus sûr ou moins cher.

Sujets connexes

Sources

Navigation

Rechercher dans le wiki...