Exécution et finalité sur Ethereum

Version source EN · P02-L02 · 30 minutes estimées · 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 éléments visuels sont des spécifications, pas des composants déployés.

Réussite et finalité répondent à des questions différentes. Les confondre peut faire paraître réussie une transaction échouée, ou présenter une transaction incluse comme davantage réglée que ne le permettent les preuves.

Deux axes, et non une seule échelle de statuts

Un reçu décrit l’exécution. L’exécution Ethereum s’effectue sur l’Ethereum Virtual Machine (EVM), l’environnement qui applique ses règles d’exécution. Les informations de consensus décrivent si le bloc qui contient la transaction appartient à un historique présentant un statut de règlement donné. La preuve d’enjeu Ethereum utilise des points de contrôle et les votes de validateurs pour la finalité ; un validateur est un participant au protocole dont le rôle de vote repose sur des ETH mis en jeu [POS]. Une exécution réussie dans un bloc récent peut ne pas encore être finalisée.

Inversement, une exécution échouée peut appartenir à un historique finalisé. La finalité ne réécrit pas son résultat. Un échec inclus peut tout de même entraîner des frais [GAS]. Ne résumez pas ces deux axes à un seul badge vert « terminé ».

Relier le reçu à son bloc

Conservez ensemble l’empreinte de la transaction et celle du bloc. Un point de contrôle finalisé à une hauteur ultérieure ne suffit pas à lui seul, sauf si le bloc du reçu est établi comme son ancêtre dans la même chaîne. L’exercice fournit explicitement cette filiation là où elle est nécessaire ; ne l’inventez pas dans un rapport réel.

Un statut de reçu égal à zéro étaye un échec dans ce contexte d’exécution [RPC]. Sans données supplémentaires, il n’en identifie pas la cause. Une explication d’erreur absente reste UNKNOWN ; ne diagnostiquez pas un manque de gas simplement parce que cette erreur est familière.

Séparer mesure et interprétation

La valeur de statut fournie est OBSERVED dans le dossier. Appliquer la filiation stipulée pour classifier le règlement est une conclusion INFERRED sous cette hypothèse. Le simple fait de lire le dossier aujourd’hui ne constitue pas une observation de l’état réel actuel.

Utiliser une matrice de résultats

Créez des lignes pour réussite incluse/non finalisée, échec inclus/finalisé et enregistrement indisponible. Cela empêche un vocabulaire de statut unique de masquer les données manquantes. Un résultat finalisé n’établit toujours pas la légitimité d’un token, le consentement éclairé d’une personne ou la sécurité d’une autre interaction.

Classification des états de preuve

OBSERVED dans l’exercice : les statuts des reçus, les frais fournis et la filiation stipulée du point de contrôle. INFERRED : l’exécution échouée de A appartient à la filiation finalisée indiquée. UNKNOWN : la finalité de B et la cause de l’échec de A. INSUFFICIENT EVIDENCE : la réussite de l’exécution seule établit la finalité du consensus ou la sécurité du token.

• Statut d’exécution : réussite ou échec de l’exécution d’une transaction.
• Finalité : propriété de règlement par consensus de l’historique des blocs.
• Filiation : relation entre blocs d’une même chaîne.
• Contexte du reçu : transaction et bloc qui la contient.

ILLUSTRATIVE. R-A : SIM-TX-A, BLOCK-100, statut0, frais de gas0.001 ETH simulés. R-B : SIM-TX-B, BLOCK-103, statut1. Le point de contrôle BLOCK-102 est stipulé finalisé et descend de BLOCK-100. Aucune affirmation de finalité n’est fournie pour103.

Panneau de preuves à deux axes : A échec/finalisé sous hypothèse ; B réussite/finalité inconnue. Texte alternatif : la finalité ne transforme pas une exécution échouée en réussite.

Les classifications selon les deux axes sous la filiation explicitement fournie.

Une validation indépendante du consensus, un diagnostic d’échec, la sécurité ou l’état actuel du réseau.

• Finalisé signifie réussi.
• Le statut1 signifie finalisé.
• Deviner la filiation à partir de la seule hauteur.

Classifiez chaque transaction selon les deux axes. Les frais de A disparaissent-ils ? Quel enregistrement manquant permettrait de résoudre le contexte de règlement de B ?

Présenter un court tableau des éléments de preuve et le raisonnement, uniquement à partir du matériel fourni. Répartition suggérée : étude 12 min, inspection/calcul 8 min, correction/quiz 10 min.

• Résultat du reçu.
• Empreinte du bloc.
• Preuves de consensus et de filiation.
• Frais séparés.
• Les causes d’échec inconnues restent inconnues.

Réussite et finalité répondent à des questions différentes. Les confondre peut faire paraître réussie une transaction échouée, ou présenter une transaction incluse comme davantage réglée que ne le permettent les preuves. Le matériel fourni permet les classifications selon les deux axes sous la filiation explicitement fournie. Il n’établit ni une validation indépendante du consensus, ni un diagnostic d’échec, ni la sécurité, ni l’état actuel du réseau.

• Séparer le résultat d’exécution du contexte de consensus.
• Expliquer une exécution échouée dont le bloc est finalisé.
• Lire les hypothèses de filiation des blocs.

P02-L03 après examen de cet exercice et de ses prérequis.

NONE. Le catalogue de référence n’exige aucun accès au produit pour cette leçon. Utiliser le matériel figé/hors ligne.

• [RPC] Ethereum JSON-RPC — Statut du reçu, contexte du bloc et résultats d’API dans le périmètre du réseau. Vérifié 2026-10-01.
• [POS] Preuve d’enjeu Ethereum — Points de contrôle du consensus et séparation entre exécution et consensus. Vérifié 2026-10-01.
• [GAS] Gas et frais Ethereum — Gas utilisé multiplié par le prix effectif et coûts d’un échec inclus dans un bloc. Vérifié 2026-10-01.

Les valeurs synthétiques sont des données d’entrée d’exercice créées par l’auteur. Les valeurs historiques éventuelles doivent utiliser le jeu de données lié et sa provenance plus restreinte. L’inspection des sources ne constitue pas une acceptation éditoriale indépendante.