Chaîne de blocs et transactions

Source de référence EN · P01-L01 · durée estimée : 30 minutes · needs_review

Étude en lecture seule. Aucune connexion de portefeuille, aucun argent réel, aucune phrase de récupération, clé privée, signature ou transaction de marché en direct. La durée est une estimation éditoriale ; les visuels sont des spécifications, pas des composants déployés.

Une capture d’écran indiquant « envoyé » peut décrire une action de l’application plutôt qu’un événement accepté dans le registre. La recherche commence par déterminer à quelle affirmation le document disponible permet réellement de répondre.

Un registre est un relevé au périmètre défini

Une chaîne de blocs ordonne les enregistrements selon les règles de validation et de consensus d’un réseau. La validation vérifie qu’un enregistrement respecte les règles du réseau ; le consensus détermine quel historique valide le réseau accepte. Une transaction propose des modifications ; sa diffusion n’équivaut pas à son inclusion. Bitcoin enregistre la dépense de sorties de transaction jusque-là non dépensées (UTXO), c’est-à-dire des montants créés par des transactions antérieures, tandis que les transactions Ethereum portent des instructions signées. Ces modèles comptables sont différents [BTC, TX]. Cette leçon utilise un registre fictif volontairement simplifié pour travailler cette distinction, sans reproduire le format complet de l’un ou l’autre réseau.

Poser une question plus limitée

« Le transfert T apparaît-il dans le bloc B du réseau N ? » peut recevoir une réponse à partir d’un enregistrement dont la source est appropriée. « La personne Alice a-t-elle payé Bob pour des marchandises ? » ajoute plusieurs affirmations : qui contrôle chaque adresse, si le transfert était un paiement et quel accord existait. Aucune ne découle de la seule présence d’une paire d’adresses. Un nom familier placé à côté d’une adresse reste une annotation tant que son fondement n’est pas établi.

Conservez ensemble l’identifiant de transaction, le réseau et le contexte de l’enregistrement. Un hash copié sans indication de réseau peut conduire à une recherche sans rapport. Une hauteur de bloc seule peut ne pas identifier un bloc de façon unique lors d’une bifurcation. Une capture d’écran peut omettre les deux et ne laisser qu’une affirmation sur ce que l’écran affichait.

Séparer les étapes

Utilisez trois colonnes : soumis, inclus et interprété. Le fait qu’un nœud accepte une requête vous renseigne sur ce nœud à cet instant. Un enregistrement d’inclusion conservé ajoute le contexte du registre. Le récit expliquant pourquoi la transaction a eu lieu appartient à une colonne d’interprétation, avec sa propre justification. Ne comblez pas une étape manquante sans le signaler simplement parce qu’une capture ultérieure paraît plausible.

Les quatre états des éléments de preuve de cette leçon s’appliquent à une affirmation précise. OBSERVED (OBSERVÉ) signifie directement visible dans le document fourni. INFERRED (INFÉRÉ) désigne une conclusion accompagnée d’hypothèses explicites. UNKNOWN (INCONNU) indique un fait indisponible. INSUFFICIENT EVIDENCE (ÉLÉMENTS DE PREUVE INSUFFISANTS) répond à une affirmation examinée que le matériel ne permet pas d’établir. Dans un exercice fictif, OBSERVED (OBSERVÉ) concerne toujours l’exercice, jamais une chaîne réelle.

Construire une phrase reproductible

Utilisez ce modèle : « Dans l’enregistrement R, le réseau N montre l’événement E dans le contexte C ; l’identité et l’objet ne sont pas établis. » Un autre lecteur doit pouvoir retrouver R et vérifier E. Si l’enregistrement ne montre qu’une requête, remplacez « montre l’événement » par « signale la soumission ». La précision est plus utile qu’un ton assuré.

• Registre : enregistrements et état du réseau régis par des règles de validation.
• Hash : empreinte cryptographique servant à identifier un enregistrement ; elle n’identifie pas une personne.
• Transaction : instruction proposée ou enregistrement d’une dépense.
• Inclusion : présence dans un bloc spécifié.
• Attribution : mise en relation du rôle d’un compte avec une entité.

Cartes conceptuelles ILLUSTRATIVE, et non captures d’une chaîne de blocs. R1 : SIM-NET, SIM-TX-A soumis à T0. R2 : même SIM-TX-A inclus dans SIM-BLOCK-40 à T1, transférant 7 unités SIM de ACCOUNT-A vers ACCOUNT-B. R3 : une légende non vérifiée appelle ACCOUNT-A « Alice ». T0/T1 sont des repères d’ordre fictifs.

Chronologie de transaction : R1 à T0, R2 à T1 ; piste distincte pour la légende R3, sans lien de propriété. Légende : étapes fictives, sans attribution à une personne. Texte alternatif : la soumission précède l’inclusion stipulée ; l’étiquette portant un nom n’est pas vérifiée.

Les cartes fournies distinguent une requête d’un mouvement inclus.

Un événement sur une chaîne réelle, la propriété effective, l’intention, la livraison de marchandises ou la sûreté d’un actif.

• Assimiler « soumis » à un règlement effectué.
• Présenter une étiquette d’explorateur comme une personne vérifiée.
• Raconter une opération commerciale à partir d’un seul transfert.

Construisez un tableau des éléments de preuve à trois lignes : soumission, inclusion et identité humaine. Évaluez ensuite la phrase « Alice a acheté des marchandises à Bob ». Nommez deux faits manquants et reformulez la phrase.

Remettez un court tableau des éléments de preuve et votre raisonnement, en utilisant uniquement le matériel fourni. Répartition suggérée : étude 12 min, inspection/calcul 8 min, correction/quiz 10 min.

• Nommer le réseau et le repère complet de l’enregistrement.
• Identifier l’étape effectivement montrée.
• Distinguer les rôles des adresses des personnes.
• Associer les limites au constat.

Une capture d’écran indiquant « envoyé » peut décrire une action de l’application plutôt qu’un événement accepté dans le registre. La recherche commence par déterminer à quelle affirmation le document disponible permet réellement de répondre. Les cartes fournies permettent de distinguer une requête d’un mouvement inclus. Elles n’établissent pas un événement sur une chaîne réelle, la propriété effective, l’intention, la livraison de marchandises ou la sûreté d’un actif.

• Séparer la soumission, l’inclusion et l’interprétation.
• Décrire un fait du registre sans inventer une personne.

P01-L02 après avoir revu cet exercice et ses prérequis.

NONE. Le catalogue de référence ne requiert aucun accès à un produit pour cette leçon. Utilisez le matériel figé/hors ligne.

• [BTC] Guide du développeur Bitcoin — Chaîne de blocs — Blocs valides, UTXO, travail et bifurcations ; pas d’authentification historique du jeu pédagogique. Vérifié le 2026-10-01.
• [TX] Transactions Ethereum — Instructions signées et exécution ; l’inclusion se distingue de la diffusion. Vérifié le 2026-10-01.

Les valeurs synthétiques sont des données d’exercice créées par l’auteur. Les valeurs historiques, s’il y en a, doivent utiliser le jeu de données lié et respecter sa provenance plus limitée. L’inspection d’une source ne constitue pas une acceptation éditoriale indépendante.