P10-L08 · P10 · P10-M02
Auditer un autre rapport pour sa reproductibilité et ses limites probantes
Prérequis: P10-L07
Objectifs pédagogiques
- Auditer un autre rapport pour sa reproductibilité et ses limites probantes
- Examiner un rapport affirmation par affirmation et séparer les défauts de reproductibilité des preuves non résolues.
Pourquoi ce sujet compte
La revue par les pairs doit rendre un rapport plus vérifiable, pas récompenser son récit le plus assuré. Un dossier soigné peut encore cacher un lien d’identité non étayé ou une source manquante.
Explication
Examinez indépendamment quatre couches : périmètre, enregistrements sauvegardés, transformations et conclusions. Recalculez depuis les entiers bruts, vérifiez les identifiants sur le réseau nommé et reliez chaque affirmation substantielle à un localisateur. Un lien source cassé est un défaut de reproductibilité même si l’affirmation peut être vraie. Un graphe entièrement reproductible peut rester insuffisant pour une attribution humaine. La finition visuelle ne répare aucun de ces défauts.
Rédigez un constat pour chaque phrase contestée : enregistrement de soutien, opération exacte, état probant, interprétation concurrente et correction demandée. Préférez des modifications limitées aux verdicts globaux. Si un reçu prouve un transfert sans lien de contrôle, conservez l’observation de transfert et retirez la conclusion sur le contrôleur nommé. Consignez les lacunes irréductibles plutôt que de demander à l’auteur de les cacher.
Un Diagnostic Passport est le contexte d’un instantané borné, pas un certificat d’adéquation à l’investissement, de fraude ni d’identité. La date de revue et celle d’observation de la source restent distinctes. Cette évaluation ne crée ni Passport réel ni runtime de certification. Le rôle du réviseur est de tester si un autre lecteur peut reproduire ce que le dossier affirme réellement.
Terminologie
Défaut de reproductibilité : localisateur, octets ou méthode nécessaires pour répéter un résultat manquants.
Défaut probant : conclusion dépassant ce que les enregistrements disponibles étayent.
Constat de revue : correction précise avec justification probante.
Exemple historique
Le rapport ILLUSTRATIVE R dit : « A a envoyé 40unités à B ; donc A et B ont un même propriétaire et B est sûr. » Le reçu fictif sauvegardé étaye40unités, mais R omet son bloc du tableau de sources. Une légende de graphe assimile contrepartie partagée et contrôleur commun. Le réviseur n’a aucune preuve d’identité ou d’évaluation de sécurité.
Spécifications visuelles
Panneau de preuves de revue par les pairs avec colonnes phrase, source, transformation, limite et correction. Conservez l’observation de 40 unités ; signalez identité et sécurité insuffisamment étayées, sans score de fraude.
Légende : La revue fictive audite les limites des affirmations plutôt que de délivrer un certificat de sécurité.
SPECIFICATION_ONLY — le visuel rendu n’a pas été produit ni examiné indépendamment.
Ce que les preuves établissent
Le reçu stipulé étaye un transfert de 40 unités. La revue peut identifier le localisateur de bloc manquant et deux extensions non étayées sans nier le transfert sous-jacent.
Ce que les preuves n’établissent pas
Cela ne prouve ni identité, intention bénigne, sécurité globale ni véritable BlockAssay Passport. Une correction éditoriale n’est pas une nouvelle preuve de chaîne.
Erreurs fréquentes
Accepter tout le rapport parce que l’arithmétique est correcte ; rejeter toute observation parce qu’une conclusion est fausse ; prendre un badge Passport pour une garantie ; remplacer la critique par des accusations sur l’auteur.
Exercice pratique
Produisez trois constats de revue pour R. Séparez une correction de reproductibilité des corrections de limites probantes, puis rédigez une conclusion révisée acceptable et une demande de preuves restantes.
Afficher la correction détaillée
Constat1 : ajoutez le localisateur exact de réseau/bloc/reçu et la provenance pour rendre l’observation de 40 unités reproductible. Constat2 : supprimez l’inférence de propriétaire commun sauf lien de contrôle admissible distinct ; une relation de transaction partagée est insuffisante. Constat3 : retirez « sûr », car un transfert et un graphe n’évaluent pas tous les risques. Conclusion révisée : « Le reçu fictif fourni enregistre40unités de A vers B ; identité, contrôle commun et sécurité ne sont pas établis. » Demandez d’abord le localisateur manquant, puis des preuves de contrôle clairement bornées seulement si cette affirmation reste nécessaire.
Liste de contrôle
- Refaites les calculs d’unités compatibles.
- Reliez chaque conclusion substantielle à un localisateur.
- Séparez le défaut de reproductibilité de la surinterprétation.
- Conservez les observations limitées valides en corrigeant les extensions non étayées.
Résumé
Une bonne revue conserve les observations étayées et rend explicites les extensions non étayées et les lacunes de reproductibilité.
Résumé
- L’arithmétique correcte ne valide pas l’attribution.
- Un localisateur manquant et une conclusion excessive sont des constats différents.
- La revue ne fabrique ni preuves ni certification.
Leçon suivante
Programme terminé ; aucun nouveau runtime, certification ni action financière n’est impliqué.
Outils
Utilisez l’outil BlockAssay nommé uniquement comme contexte de lecture des preuves. Cette leçon ne crée aucune sortie d’outil, session de compte ni droit d’accès. Exercice hors ligne ; ne signez, ne déployez, n’approuvez et ne financez rien.
Sources et limites des affirmations
- BTC: Guide développeur Bitcoin — transactions — Les références des entrées identifient les sorties de transactions antérieures ; les scripts n’identifient pas un humain. Limite : Documentation du mécanisme uniquement ; les valeurs illustratives originales sont stipulées, pas observées. Les enregistrements historiques disposent d’une provenance figée séparément et de lacunes de collecte explicites.
- API: Spécification de l’API publique Esplora — Routes GET, satoshis entiers et champs indexés de confirmation et de dépense des sorties. Limite : Documentation du mécanisme uniquement ; les valeurs illustratives originales sont stipulées, pas observées. Les enregistrements historiques disposent d’une provenance figée séparément et de lacunes de collecte explicites.
Classification des preuves
ILLUSTRATIVE — entrées hors ligne entièrement fictives ; aucune observation actuelle.
Date d’observation
null — aucune observation réelle
Version du contenu
1
Date de révision
null
Statut de révision
needs_review
Spécifications visuelles
P10-L08-V01
Auditer un autre rapport pour sa reproductibilité et ses limites probantes
La revue fictive audite les limites des affirmations plutôt que de délivrer un certificat de sécurité.
Panneau de preuves de revue par les pairs avec colonnes phrase, source, transformation, limite et correction. Conservez l’observation de 40 unités ; signalez identité et sécurité insuffisamment étayées, sans score de fraude.
Panneau de preuves de revue par les pairs avec colonnes phrase, source, transformation, limite et correction. Conservez l’observation de 40 unités ; signalez identité et sécurité insuffisamment étayées, sans score de fraude.
À 390 px, empilez observations, hypothèses, lacunes et conclusion ; conservez les IDs complets et un équivalent textuel intégral. Tout tableau large défile localement.
La prose peut suivre RTL ; les IDs, quantités et axes temporels restent LTR. Préservez le sens des dépendances.
P10-L08-ILLUSTRATIVE-v1
Sources et limites des affirmations
BTC · PRIMARY_DOCUMENTATION
Guide développeur Bitcoin — transactions
- Affirmation étayée
- Les références des entrées identifient les sorties de transactions antérieures ; les scripts n’identifient pas un humain.
- Limite de vérification
- Documentation du mécanisme uniquement ; les valeurs illustratives originales sont stipulées, pas observées. Les enregistrements historiques disposent d’une provenance figée séparément et de lacunes de collecte explicites.
- Date de vérification
- 2026-10-02
https://developer.bitcoin.org/devguide/transactions.html
API · PRIMARY_DOCUMENTATION
Spécification de l’API publique Esplora
- Affirmation étayée
- Routes GET, satoshis entiers et champs indexés de confirmation et de dépense des sorties.
- Limite de vérification
- Documentation du mécanisme uniquement ; les valeurs illustratives originales sont stipulées, pas observées. Les enregistrements historiques disposent d’une provenance figée séparément et de lacunes de collecte explicites.
- Date de vérification
- 2026-10-02
https://github.com/Blockstream/esplora/blob/master/API.md
Provenance des données
id: P10-L08-ILLUSTRATIVE-v1
dataStatus: ILLUSTRATIVE
observedAt: null
source: Original offline scenario in realOrHistoricalExample
scope: Fictional stipulated labels and values. No wallet, deployment, transaction, token launch or production observation.