--- title: "Blockchain : état, consensus et vérification" description: "Une blockchain est un protocole versionné permettant d'ordonner et de valider les transitions d'état entre les répliques. Les liens de hachage ne sont qu’un composant ; la confiance dépend du consensus, des autorisations, de la vérification indépendante, de la disponibilité des données, de la gouvernance et de la récupération." image: "https://wiki.fcontext.com/og.png" --- > Documentation Index > Fetch the complete documentation index at: https://wiki.fcontext.com/llms.txt > Use this file to discover all available pages before exploring further. # Blockchain : état, consensus et vérification > À 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 blockchain est un protocole versionné qui permet à plusieurs répliques d'ordonner les transactions proposées, de valider les transitions d'état et de converger vers un historique accepté selon un consensus énoncé et des hypothèses de réseau. Un bloc est un conteneur défini par un protocole contenant des transactions ou d'autres données ainsi que des engagements sur l'historique antérieur et l'état résultant ; la chaîne ou l'historique dirigé relie les conteneurs acceptés via des engagements cryptographiques. Les liens de hachage permettent de détecter les modifications historiques non autorisées, mais ils ne rendent pas indépendamment un système décentralisé, immuable ou correct. Ces propriétés dépendent de qui peut proposer et valider, si les utilisateurs peuvent vérifier de manière indépendante, les règles de choix et de finalité, la disponibilité des données, la diversité des clients, la gouvernance, le contrôle des clés, les incitations et les procédures de récupération. Les blockchains peuvent utiliser des modèles d'état spécifiques à UTXO, à un compte, à un objet ou à une application ; preuve de travail, preuve d'enjeu, vote tolérant aux fautes byzantines ou consensus autorisé ; et la finalité probabiliste ou basée sur des points de contrôle. Le mot « blockchain » désigne donc une large famille d’architectures, et non une seule garantie de sécurité ou un seul produit de base de données. ## Comment ça marche 1. Déterminez précisément la chaîne, le réseau, la version du protocole, le modèle d'autorisation, le modèle d'état et l'affirmation à vérifier. Consignez la genèse ou le point de contrôle de confiance, l'identifiant de chaîne, l'implémentation du client et l'autorité de mise à niveau. 2. Construisez les octets exacts de la transaction et de son autorisation. Avant la diffusion, vérifiez la propriété de l'expéditeur ou des entrées, le nonce ou les références aux sorties non dépensées, le montant, la destination, les limites de frais, la fenêtre de validité, les signatures et les appels de l'application. 3. Propagez la transaction via des pairs ou des passerelles. Distinguer la politique d'admission locale et de mempool de la validité consensuelle ; un nœud peut rejeter, retarder, remplacer ou ne jamais recevoir une transaction qui pourrait être valide dans un bloc. 4. Un proposant sélectionne et ordonne les transactions dans un bloc candidat et s'engage sur des champs du protocole tels que le bloc parent et les racines de transactions, de reçus, d'état ou de données. L'ordre peut affecter les résultats d'exécution, les frais, les liquidations et la valeur extractible. 5. Les nœuds indépendants désérialisent le bloc, vérifient l'autorisation consensuelle et chaque transition d'état requise, recalculent les engagements et rejettent les entrées invalides ou indisponibles conformément à leurs règles. Les signatures du producteur ou la preuve de travail ne remplacent pas l’échec de la validation. 6. La règle de choix de fork sélectionne un historique parmi plusieurs historiques valides concurrents, tandis que les confirmations, votes ou points de contrôle font évoluer le risque de réorganisation. « Inclus », « sûr » et « finalisé » désignent des états différents qui restent propres au protocole. 7. Rapprochez l'état du protocole de l'intention de l'application, de la conservation, de la comptabilité du bridge ou de la plateforme et des exigences d'archivage. Conservez les octets de transaction, le hachage du bloc, la hauteur ou le slot, le reçu, les journaux, la preuve d'état, le statut de finalité, la version du client et les preuves issues d'un point de terminaison indépendant. ## Exemples travaillés - **Rapprochement de l'état du compte.** Un compte commence avec `10 ETH` et un nonce de `41`. Une transaction valide utilisant le nonce `41` transfère `2 ETH` et consomme `0.00042 ETH` de frais ; l'état suivant simplifié est donc `10 - 2 - 0.00042 = 7.99958 ETH`, le destinataire reçoit `2 ETH` et le nonce de l'expéditeur passe à `42`. Une signature valide, à elle seule, ne prouverait ni le solde antérieur ni la réussite de l'exécution. - **Conservation UTXO.** Une transaction dépense des entrées de `0.80 BTC` et `0.35 BTC`, pour un total de `1.15 BTC`. Les sorties de `1.00 BTC` et `0.1496 BTC` totalisent `1.1496 BTC` ; la différence de `1.15 - 1.1496 = 0.0004 BTC` correspond aux frais. Les nœuds doivent aussi vérifier que chaque sortie référencée existe, n'a pas été dépensée et satisfait ses conditions de dépense. - **Taille de preuve d'engagement.** Dans un arbre Merkle binaire équilibré illustratif avec `8 leaves`, un chemin d'inclusion a besoin de `log2(8) = 3 sibling hashes`. Avec les hachages `256-bit = 32-byte`, ces frères et sœurs occupent `3 * 32 = 96 bytes` avant les index et l'encodage. La preuve lie une feuille à une racine revendiquée ; cela ne prouve pas que les données sources sont véridiques ou actuellement disponibles. - **Le poids n'est pas le nombre de nœuds.** Dans un protocole de vote illustratif dont la règle de finalité déclarée est `>= 2/3` de poids, les validateurs détiennent `30%, 25%, 20%, 15%, 10%`. Les trois premiers totalisent `30 + 25 + 20 = 75%` et franchissent la règle, tandis que les deux premiers totalisent `55%` et ne le font pas. Les véritables seuils, corrélations, équivoques et règles de récupération doivent provenir du protocole nommé. ## Risques - Utilisation d'une chaîne, d'un réseau, d'un fork, d'un point de contrôle ou d'un identifiant de chaîne incorrects. - Traiter un nom de marque comme un protocole complet ou une spécification de modèle de confiance. - En supposant que la liaison de hachage empêche à elle seule les réécritures autorisées ou approuvées par consensus. - Confondre la proposition de bloc d'un producteur avec la validation d'un nœud indépendant. - Traiter l'acceptation, la diffusion, l'inclusion, le succès de l'exécution et la finalité du pool de mémoire comme un seul état. - Signature d'octets, de domaines ou de destinations différents de ce que l'interface affiche. - Réutiliser des nonces, dépenser des UTXO obsolètes ou mal calculer les frais et la monnaie rendue. - Faire confiance aux symboles de jetons, aux étiquettes, aux événements ou aux interprétations de l'explorateur au lieu des identifiants et de l'état du protocole. - Traiter les entrées signées d'oracle, de pont ou de document comme preuve que les affirmations hors chaîne sont vraies. - Ignorer l'ordre des transactions, la censure, le front-running et la concentration des proposants ou des constructeurs. - Compter les nœuds ou les validateurs sans résoudre les opérateurs, poids et infrastructures communs. - Ignorer la concentration des clients, du cloud, de la géographie, de la gouvernance, des clés et de la chaîne d'approvisionnement logicielle. - En supposant que tous les modèles de consensus ont les mêmes seuils de faute ou sémantique de finalité. - Ignorer les partitions, la finalité différée, les réorganisations, les équivoques et les procédures de redressement. - Accepter des en-têtes de bloc ou des preuves sans les hypothèses requises en matière de disponibilité des données. - En fonction d'un RPC, d'un explorateur, d'un portefeuille, d'un indexeur ou d'une plateforme de conservation comme source de vérité. - Confondre la possession ou le contrôle protocolaire avec le titre légal, le recours ou la récupérabilité. - Sous-estimation de la croissance de l'état, de la perte d'archives, des coûts de synchronisation et des barrières matérielles. - Ignorer les clés de mise à niveau, les pauses d'urgence, la récupération sociale et les forks controversés. - Déduire la confidentialité, l'évolutivité, la valeur d'investissement ou la sécurité des applications à partir du label blockchain. ## Idées fausses courantes - **Chaque blockchain est décentralisée et immuable.** L'autorisation, l'indépendance de l'opérateur, le choix du fork, la gouvernance et la récupération déterminent qui peut modifier ou rejeter l'historique. - **Les données enregistrées en chaîne doivent être vraies.** Un consensus peut s'entendre sur l'enregistrement fidèle d'un faux prix, d'un faux document ou d'une entrée d'application malveillante. - **Une transaction valide prouve le résultat escompté.** Elle peut cibler une mauvaise adresse, revenir en arrière après avoir consommé des frais, émettre des événements trompeurs ou dépendre d'étapes ultérieures de pont et de garde. - **Plus de répliques améliorent toujours la sécurité.** Les répliques sous un même opérateur, client, cloud ou clé peuvent échouer ensemble et ne pas fournir de vérification indépendante. - **Une blockchain est toujours meilleure qu'une base de données conventionnelle.** Un opérateur de confiance, une suppression requise, un débit élevé ou une simple résolution des litiges peuvent rendre un système conventionnel plus approprié. ## Sujets connexes - [Mécanisme de consensus](/fr/crypto/consensus-mechanism/) - [Hachage cryptographique](/fr/crypto/cryptographic-hash/) - [Nœud complet](/fr/crypto/full-node/) ## Sources faisant autorite - [Présentation de la technologie Blockchain](https://doi.org/10.6028/NIST.IR.8202) - NIST (consulté : 18 août 2026) - [Bitcoin : un système de paiement électronique peer-to-peer](https://bitcoin.org/bitcoin.pdf) - Bitcoin.org (consulté : 18 août 2026) - [Chaîne de blocs](https://developer.bitcoin.org/devguide/block_chain.html) - Bitcoin.org (consulté : 18 août 2026) - [Blocs](https://ethereum.org/developers/docs/blocks/) - Ethereum.org (consulté : 18 août 2026) - [Transactions](https://ethereum.org/developers/docs/transactions/) - Ethereum.org (consulté : 18 août 2026) - [Nœuds et clients](https://ethereum.org/developers/docs/nodes-and-clients/) - Ethereum.org (consulté : 18 août 2026) - [Mécanismes de consensus](https://ethereum.org/developers/docs/consensus-mechanisms/) - Ethereum.org (consulté : 18 août 2026) - [Finalité](https://ethereum.org/developers/docs/consensus-mechanisms/pos/finality/) - Ethereum.org (consulté : 18 août 2026) Source: https://wiki.fcontext.com/fr/crypto/blockchain/index.mdx