Vous réglez un dîner de 30 dollars avec un billet de 50 et le serveur vous rend 20. Vous payez par carte et la banque retire 30 à un chiffre de votre compte. Bitcoin fonctionne comme le billet, Ethereum comme la carte. Ce choix de conception, le modèle UTXO face au modèle par comptes, explique pourquoi un portefeuille Bitcoin vous renvoie une partie de chaque paiement, pourquoi un paiement assemblé à partir de nombreux petits montants reçus coûte plus cher, et pourquoi une seule transaction Ethereum bloquée gèle toutes celles que vous envoyez après elle.
Le plus souvent, la différence reste cachée derrière l’application. Elle apparaît quand un paiement Bitcoin coûte quatre fois ce qu’un ami a payé pour envoyer la même somme, quand une adresse que vous n’avez jamais vue surgit dans votre propre transaction, ou quand un virement reste « en attente » pendant une heure et retient les trois suivants. Ce cours démonte les deux registres, ajoute Cardano et Solana, qui ont chacun plié l’un des modèles à leur manière, et se termine sur un écho que peu de gens attendent : les règles fiscales qui disent quelles unités vous avez vendues.
blockchain that runs exactly as written when it is called, holding and moving funds according to its code, without an intermediary able to change the outcome.">smart contract holding reserves of two or more tokens, supplied by users, that a decentralized exchange uses to execute trades automatically at a price set by a formula.">pool diverge, compared with simply holding the same tokens in a wallet. It becomes permanent when the provider withdraws.">Il prolonge la leçon précédente du parcours, le fonctionnement du mempool et la fixation des frais de transaction. Un seul point à retenir : les transactions attendent dans le mempool de chaque nœud et sont choisies selon leur taux de frais, compté en satoshis par octet virtuel (sat/vB). Gardez cette unité en tête. Dans le modèle UTXO, c’est elle qui transforme un portefeuille rempli de petites pièces en facture.
UTXO, c’est quoi ? Deux façons de tenir un registre : des pièces ou des comptes
Toute blockchain doit répondre à une question pour chaque transaction : l’expéditeur possède-t-il vraiment ce qu’il dépense ? Il existe deux manières de conserver la réponse.
Dans le modèle UTXO (de l’anglais unspent transaction output, soit « sortie de transaction non dépensée »), le registre est un tas de morceaux de valeur distincts, chacun verrouillé par une condition, le plus souvent « une signature valide de cette clé ». Aucun solde n’est écrit nulle part sur la chaîne. Votre portefeuille cherche les morceaux qu’il sait déverrouiller et les additionne : le chiffre affiché à l’écran est une somme calculée par l’application.
Le modèle par comptes tient à la place un tableau de comptes. Chaque ligne porte un solde enregistré, et une transaction retire une somme à une ligne pour l’ajouter à une autre. Un nœud Ethereum conserve ce nombre tel quel, prêt à être lu.
Les deux enregistrent qui possède quoi. La différence tient à ce que pointe une transaction. Une transaction Bitcoin désigne les sorties antérieures qu’elle consomme. Une transaction Ethereum désigne un compte et un compteur. Presque tout ce qui suit en découle.
Le modèle UTXO de Bitcoin
Une sortie se dépense en entier, et la monnaie revient
Une transaction Bitcoin comporte des entrées et des sorties. Chaque entrée pointe vers une sortie d’une transaction antérieure (son identifiant et sa position) et fournit la preuve, en général une signature, qui la déverrouille. Chaque sortie porte un montant et un script de verrouillage qui dit qui pourra la dépenser ensuite. Une fois créée, une sortie attend qu’une entrée ultérieure la consomme, puis elle disparaît pour de bon. Le guide du développeur Bitcoin (en anglais) pose la règle clairement : la valeur entière des sorties que vous dépensez doit aller quelque part, soit dans de nouvelles sorties, soit chez le mineur sous forme de frais.
Satoshi Nakamoto a décrit la forme habituelle à la section 9 du livre blanc de 2008 (en anglais) : une transaction comporte normalement « au plus deux sorties : l’une pour le paiement, l’autre pour rendre la monnaie, s’il y en a, à l’expéditeur » (traduction libre).
Voici un exemple aux chiffres ronds. Votre portefeuille détient une sortie de 0,05 BTC sur une adresse SegWit native, et vous payez un commerçant 0,03 BTC. La transaction dépense les 0,05 BTC en entier et crée deux sorties : 0,03 BTC pour le commerçant et 0,01999718 BTC vers une nouvelle adresse de votre propre portefeuille. Les 282 satoshis qui manquent sont les frais, pour une transaction d’environ 141 octets virtuels à 2 sat/vB. Aucune sortie n’est étiquetée « frais » : le mineur empoche simplement ce que les sorties laissent sans destinataire.
Cette règle joue dans les deux sens. Un portefeuille ajoute pour vous la sortie de monnaie rendue ; celui qui construit une transaction à la main et l’oublie offre toute la différence au mineur.
Pourquoi votre portefeuille Bitcoin contient plusieurs « pièces »
Chaque paiement reçu crée une nouvelle sortie. Dix paiements font dix sorties, même si tous sont arrivés à la même adresse. Votre solde en est le total. Certains portefeuilles affichent la liste dans un onglet « coins » ou « UTXO », avec une option de contrôle des pièces (coin control) qui permet de choisir les sorties qu’un paiement dépensera.
La monnaie rendue explique une énigme qui inquiète beaucoup d’utilisateurs. Ouvrez l’un de vos paiements dans un explorateur de blocs et vous verrez souvent une adresse inconnue recevoir une partie de l’argent. Dans la plupart des cas, c’est votre adresse de change, dérivée de la même phrase de récupération que le reste du portefeuille. Le guide du développeur recommande d’envoyer la monnaie vers une adresse neuve, et la section 10 du livre blanc conseillait déjà une nouvelle paire de clés pour chaque transaction. Les formats d’adresse et les risques de leur réutilisation sont traités dans notre guide des adresses crypto.
Avant de soupçonner un vol, vérifiez donc deux choses : que le montant correspond à ce que vous attendiez en retour, et que votre portefeuille compte cette sortie parmi vos pièces.
La sélection des pièces : quelles sorties le portefeuille dépense-t-il ?
Admettons que vous payiez 0,03 BTC depuis un portefeuille qui contient douze sorties de tailles diverses. Le logiciel doit choisir, et ce choix s’appelle la sélection des pièces (coin selection). Ses objectifs tirent dans des directions différentes. Moins d’entrées rendent la transaction du jour moins chère. Un paiement qui n’a pas besoin de sortie de monnaie rendue économise quelques octets et laisse filtrer moins d’informations. Dépenser les petites sorties quand les frais sont bas évite de les payer plus cher plus tard.
Le code du portefeuille de Bitcoin Core (en anglais) énumère les méthodes disponibles : Branch and Bound, qui cherche un ensemble d’entrées assez proche du montant pour se passer de sortie de monnaie rendue ; Knapsack ; Single Random Draw ; CoinGrinder, qui cherche l’ensemble d’entrées le plus léger ; et la sélection manuelle par l’utilisateur. Chaque solution candidate reçoit un score de « gaspillage » (waste) qui compare le coût des entrées au taux de frais du jour à un taux de long terme, et ajoute le coût d’une éventuelle monnaie rendue ou d’un excédent. D’autres portefeuilles appliquent leurs propres règles, ce qui explique en partie que deux applications facturent des frais différents pour le même paiement depuis la même phrase de récupération.
Poussière, consolidation d’UTXO et frais qui augmentent avec les entrées
Les frais Bitcoin se paient à la taille, en octets virtuels, et non au montant. Déplacer 1 BTC logé dans une seule sortie coûte moins cher que déplacer 0,01 BTC ramassé dans quarante. Chaque entrée transporte sa référence à une sortie antérieure et ses données de signature, et c’est là que se concentre l’essentiel du poids d’une transaction. Les tailles approximatives pour les trois types d’adresse courants :
| Type d’adresse | Entrée (vB, environ) | Sortie (vB, environ) |
|---|---|---|
| Historique P2PKH (commence par 1) | 148 | 34 |
| SegWit natif P2WPKH (bc1q…) | 68 | 31 |
| Taproot P2TR, chemin par clé (bc1p…) | 57,5 | 43 |
Les tailles de sortie historique et SegWit natif, 34 et 31 octets, sont celles que le code de Bitcoin Core utilise lui-même pour la poussière, tout comme l’entrée historique de 148 octets ; pour une entrée SegWit native, le code arrondit à 67. Les chiffres de Taproot sont approximatifs, calculés d’après la structure en octets d’une dépense par chemin de clé, qui ne porte qu’une signature Schnorr de 64 octets. Ajoutez environ 10,5 vB de frais fixes par transaction SegWit. Les tailles réelles varient d’un octet environ selon la signature.
Le même calcul définit la poussière (dust). Dans la politique de relais de Bitcoin Core (en anglais), un commentaire résume l’idée en une ligne (traduction libre) : si dépenser quelque chose coûte plus cher en frais que la valeur de la sortie, on la considère comme de la poussière. Au taux de relais de poussière par défaut de 3 sat/vB, les commentaires du code donnent 546 satoshis pour une sortie historique et 294 pour une sortie SegWit native. Taproot n’est pas listé : la même formule, appliquée à sa sortie de 43 octets, place la limite vers 330 satoshis, car les développeurs ont conservé volontairement la taille d’entrée SegWit plutôt que d’abaisser le seuil. Il s’agit d’une politique de relais, pas d’une règle de consensus : une sortie sous la limite reste valide dans un bloc, mais les nœuds aux réglages par défaut ne relaient pas une transaction qui en crée une.
La consolidation répond au portefeuille rempli de petites sorties : vous les envoyez toutes vers une adresse à vous pendant que les frais sont bas. Prenons 50 entrées SegWit natives et une sortie, soit environ 3 440 vB au total. Le coût ne dépend que du taux de frais (exemple, avec un bitcoin à 76 015 dollars selon Blockchair, le 7 novembre 2026 à 09:55 UTC) :
| Taux de frais | Frais (satoshis) | Frais (dollars) |
|---|---|---|
| 1 sat/vB | environ 3 440 | environ 2,60 |
| 10 sat/vB | environ 34 400 | environ 26 |
| 50 sat/vB | environ 172 000 | environ 131 |
Ces 50 entrées pèsent le même nombre d’octets, que vous les consolidiez maintenant ou que vous les dépensiez plus tard dans un paiement. Ce que vous choisissez, c’est le taux de frais auquel vous les payez. Le 7 novembre 2026 à 09:53 UTC, l’API de frais de mempool.space recommandait 3 sat/vB pour le prochain bloc et 1 sat/vB pour une confirmation dans l’heure, tout près du plancher, et Blockchair situait les frais médians des 24 dernières heures à 330 satoshis, soit environ 25 centimes de dollar.
La consolidation a deux coûts en plus des frais. Elle relie toutes ces sorties sur le registre public, ce que la section sur la confidentialité détaille plus bas. Et c’est une opération pour votre propre portefeuille : aucun site, aucun outil de « déblocage d’UTXO », aucun conseiller de support n’a jamais besoin de votre phrase de récupération pour fusionner vos pièces.
L’UTXO set que chaque nœud complet conserve
Chaque nœud complet détient la liste de toutes les sorties non encore dépensées, appelée UTXO set, ou ensemble des UTXO (le dossier chainstate dans Bitcoin Core). Valider une nouvelle transaction revient pour l’essentiel à la comparer à cette liste : chaque entrée pointe-t-elle vers une sortie qui existe et n’a pas été dépensée ? Si oui, et si les signatures tiennent, les sorties dépensées quittent l’ensemble et les nouvelles y entrent.
Le rapport de mempool.space sur l’UTXO set (en anglais) comptait environ 173 millions de sorties non dépensées au bloc 892 385 (14 avril 2025), occupant environ 11 Go sur le disque avec les réglages par défaut. Cet instantané, publié en mai 2025, reste le décompte public le plus détaillé du contenu de l’ensemble ; celui-ci a continué d’évoluer depuis. Pour l’échelle, Blockchair dénombrait 4 006 954 560 sorties créées depuis 2009 au bloc 974 916, le 7 novembre 2026 : la grande majorité de tout ce qui a été créé a déjà été dépensée.
Cet ensemble compte parce que chaque nœud doit le stocker et le parcourir vite. Une minuscule sortie que personne ne dépensera jamais, parce qu’elle vaut moins que les frais pour la déplacer, y reste définitivement. Les règles sur la poussière existent en partie pour l’empêcher d’enfler.
Comme chaque entrée renvoie à une sortie précise et n’a besoin de rien d’autre, les entrées se vérifient indépendamment les unes des autres, et l’ordre de deux paiements sans rapport n’a pas d’importance. La validation se répartit donc facilement sur plusieurs cœurs de processeur. Cela ne fait pas de Bitcoin un ordinateur parallèle au sens où Solana l’entend, comme le montre la section sur Solana.
Ce que révèlent les sorties : les heuristiques de confidentialité
La section 10 du livre blanc admet la principale faiblesse : « Un certain rapprochement reste inévitable avec les transactions à entrées multiples, qui révèlent nécessairement que leurs entrées appartenaient au même propriétaire » (traduction libre). Les analystes de chaîne appellent cela l’heuristique de propriété commune des entrées, et c’est la première qu’ils appliquent.
La deuxième est la détection de la monnaie rendue : deviner quelle sortie est revenue à l’expéditeur. La page du wiki Bitcoin sur la confidentialité (en anglais) liste les indices habituels. Un montant rond est probablement le paiement, et le montant tordu la monnaie rendue. Une sortie du même type de script que les entrées est probablement la monnaie rendue. Si une seule entrée aurait suffi à couvrir la plus petite sortie, un portefeuille qui en a quand même ajouté une seconde payait probablement la plus grande. Dans une hausse de frais, la sortie qui rétrécit est la monnaie rendue. La réutilisation d’adresse facilite tout cela.
Le CoinJoin, où plusieurs personnes versent leurs entrées dans une même transaction, existe pour casser la première heuristique. Le contrôle des pièces aide plus discrètement : garder séparées les sorties de provenances différentes évite qu’un paiement ne les relie. La consolidation fait l’inverse et colle 50 historiques en un seul.
Le modèle par comptes part plus faible. Une adresse Ethereum rassemble tous les paiements qu’elle a reçus et envoyés, et quiconque la connaît lit tout l’historique et le solde sur une seule page.
L’UTXO étendu de Cardano
Cardano a gardé les sorties mais leur a donné plus à transporter, une conception qu’il appelle UTXO étendu (eUTXO). Selon la documentation de Cardano (en anglais), une sortie peut contenir des données presque arbitraires à côté de son adresse et de sa valeur, et peut être verrouillée par un script plutôt que par une seule clé. Celui qui dépense fournit, pour chaque entrée, des données supplémentaires appelées redeemer, et le script lit les données de la sortie, le redeemer et la transaction entière avant de répondre oui ou non.
Comme une transaction liste exactement ce qu’elle consomme et ce qu’elle crée, la documentation indique que les frais d’une transaction valide peuvent être connus avec précision avant son envoi. C’est différent d’Ethereum, où le résultat dépend de l’état au moment de l’exécution et où une transaction peut échouer après avoir payé le gaz consommé.
Le prix à payer est la concurrence. Si deux utilisateurs construisent des transactions qui attendent toutes deux la même sortie, par exemple l’état d’une application partagée, seule la première arrivée peut réussir ; la documentation précise qu’une transaction échoue quand une autre a déjà consommé une entrée dont elle avait besoin. Les développeurs répartissent l’état de leur application sur de nombreuses sorties pour éviter la file d’attente.
Le modèle par comptes d’Ethereum
Quatre champs par compte
La documentation d’ethereum.org (en anglais) décrit deux sortes de comptes. Un compte externe (EOA, externally owned account) est contrôlé par celui qui détient sa clé privée et peut lancer des transactions. Un compte de contrat est un contrat intelligent déployé sur le réseau : il possède du code, pas de clé, et n’agit que lorsqu’une transaction l’atteint. Les deux portent les mêmes quatre champs :
| Champ | Ce qu’il contient |
|---|---|
| nonce | Nombre de transactions envoyées par un compte externe, ou de contrats créés par un compte de contrat |
| balance | Ether détenus, en wei (1 ETH = 1018 wei) |
| codeHash | Empreinte du code du compte ; pour un compte externe, l’empreinte d’une chaîne vide. Elle ne peut pas changer |
| storageRoot | Empreinte racine d’un arbre de Merkle Patricia qui encode le stockage du compte ; vide par défaut |
La frontière entre les deux sortes s’est brouillée avec la mise à jour Pectra, entrée en service le 7 mai 2025. Son EIP-7702 permet à un compte externe de pointer vers du code de contrat et de se comporter comme un portefeuille de contrat intelligent, selon la page d’ethereum.org sur Pectra (en anglais). Les quatre champs restent les mêmes. Pour une vue d’ensemble du réseau, voyez notre guide d’Ethereum.
Le nonce Ethereum : un compteur qui ordonne tout
Le nonce compte les transactions qu’un compte a envoyées, et chaque nouvelle transaction doit porter exactement le numéro suivant : 0, puis 1, puis 2. Selon ethereum.org (traduction libre), une seule transaction portant un nonce donné peut être exécutée pour chaque compte. Une fois le nonce 7 utilisé, une copie de la même transaction signée, diffusée à nouveau, est tout simplement invalide. C’est la protection d’Ethereum contre le rejeu sur sa propre chaîne.
Une seconde couche couvre les autres chaînes. L’EIP-155, intitulée « Simple replay attack protection » (protection simple contre les attaques par rejeu), a été rédigée par Vitalik Buterin en octobre 2016 et activée au bloc 2 675 000 avec la mise à jour Spurious Dragon. Elle permet au portefeuille d’inclure un identifiant de chaîne dans ce que l’utilisateur signe (1 pour le réseau principal d’Ethereum), de sorte qu’une transaction signée ainsi pour une chaîne ne peut pas être rejouée sur une autre chaîne qui partage le même format.
Bitcoin n’a besoin ni de l’un ni de l’autre. Une sortie ne se dépense qu’une fois ; ensuite, elle n’est plus dans l’UTXO set, et une transaction rejouée pointe vers quelque chose qui n’existe plus.
Pourquoi une transaction bloquée retient toutes les suivantes
Imaginons que vous envoyiez une transaction avec le nonce 41 et des frais qui se révèlent trop bas. Vous envoyez ensuite le nonce 42, puis le 43. Le nonce 41 attend. Les nonces 42 et 43 ne peuvent entrer dans aucun bloc avant le 41, quels que soient leurs frais, car le compteur doit avancer d’un pas à la fois.
Les nœuds distinguent les deux cas. Les transactions portant le nonce suivant sont exécutables (« pending ») ; celles qui suivent un trou sont « queued », en file. Le code source de Geth (en anglais), toujours le client d’exécution Ethereum le plus utilisé, fixe les valeurs par défaut : un remplacement doit payer au moins 10 % de plus que la transaction qu’il remplace, chaque compte dispose de 64 places en file au plus, et les transactions en file sont abandonnées au bout de 3 heures. Les autres clients utilisent leurs propres valeurs.
La solution consiste à combler ou remplacer le nonce qui bloque. Pour accélérer, vous renvoyez la même transaction avec le nonce 41 et des frais plus élevés. Pour annuler, vous envoyez 0 ETH à vous-même avec le nonce 41 et des frais plus élevés : le numéro est utilisé et la transaction d’origine devient invalide. Les boutons « accélérer » et « annuler » des portefeuilles font exactement cela, et ne fonctionnent que tant que la transaction d’origine attend encore. Les étapes sont décrites dans notre guide du fonctionnement des transactions crypto.
Bitcoin n’a pas de file de ce genre. Deux paiements qui dépensent des sorties sans lien ne s’attendent pas. Seul un paiement qui dépense la monnaie rendue d’un paiement non confirmé lui est enchaîné.
Le stockage des contrats et le poids de l’état
Vos jetons ne sont pas dans votre compte. Un solde ERC-20 est une ligne dans le stockage du contrat du jeton, classée sous votre adresse, tandis que votre propre storageRoot reste vide. C’est pourquoi les autorisations de jetons (approvals) existent : vous autorisez un contrat à modifier des lignes détenues par un autre.
Tout ce qui est écrit dans l’état y reste jusqu’à son effacement : chaque compte, chaque emplacement de stockage, chaque contrat. L’EIP-8037 (en anglais), une proposition au statut Last Call en novembre 2026 qui augmente le coût en gaz de la création d’état, indique qu’en janvier 2026 la base de données qu’un nœud Geth consacre à l’état pesait environ 390 Gio. C’est l’état actuel seul, pas l’historique de la chaîne. Le but affiché de la proposition est de maintenir la croissance de l’état autour de 120 Gio par an pour une limite de gaz de référence de 150 millions.
La comparaison avec les 11 Go de Bitcoin n’est pas à armes égales : l’état d’Ethereum contient du code et des données de contrats, alors que l’ensemble de Bitcoin ne contient que des pièces. Elle montre en revanche de quel côté penche chaque conception. Un registre UTXO stocke peu et demande aux transactions d’apporter leurs preuves ; un registre par comptes garde davantage en mémoire pour que les contrats puissent le lire à tout moment.
Solana : des comptes que chaque transaction doit déclarer
Solana utilise aussi des comptes, construits autrement. Sur Solana, tout est compte : portefeuilles, programmes et soldes de jetons. La documentation de Solana (en anglais) en donne cinq champs à chacun : lamports (le solde ; 1 SOL vaut un milliard de lamports), data, owner, executable, et rent_epoch, désormais marqué comme obsolète. Un compte peut contenir jusqu’à 10 Mio de données. Seul le programme propriétaire d’un compte peut modifier ses données ou en retirer des lamports.
Chaque compte doit conserver un solde minimal remboursable, longtemps appelé le minimum exempté de loyer (rent-exempt minimum). La formule est (taille du compte + 128) octets x 3 480 lamports par octet-année x 2 ans. Un compte sans données exige 890 880 lamports. Un compte de jeton standard, de 165 octets d’après le code source du programme SPL Token (en anglais), exige 2 039 280 lamports, soit environ 0,00204 SOL. L’argent revient à la fermeture du compte, d’où les portefeuilles qui proposent de fermer les comptes de jetons vides.
La différence la plus importante se joue dans la transaction. Chaque instruction liste tous les comptes qu’elle va toucher et marque chacun comme signataire ou non, modifiable ou en lecture seule. La documentation sur les instructions (en anglais) dit ce que cela rapporte (traduction libre) : le validateur utilise ces métadonnées pour déterminer quelles transactions peuvent s’exécuter en parallèle, et celles qui écrivent dans des comptes différents le peuvent.
Le revers découle de la même règle. Les transactions qui écrivent dans le même compte doivent s’exécuter l’une après l’autre, si bien qu’un compte très sollicité, comme un pool d’échange très actif, devient une file d’attente à lui seul. Dans la machine virtuelle d’Ethereum (EVM), en revanche, les transactions d’un bloc sont définies pour s’exécuter l’une après l’autre.
Solana n’utilise pas de nonce de compte contre le rejeu. Une transaction porte un blockhash récent, valable 150 slots, et est rejetée passé ce délai ; des nonces durables existent pour les transactions signées hors ligne. Ses frais se composent d’une base de 5 000 lamports par signature, dont la moitié est brûlée, plus des frais de priorité facultatifs, d’après la documentation des frais (en anglais).
Modèle UTXO et modèle par comptes côte à côte
| UTXO (Bitcoin) | Comptes (Ethereum) | Comptes (Solana) | |
|---|---|---|---|
| Unité d’état | Sortie non dépensée | Compte : nonce, solde, code, stockage | Compte : lamports, données, propriétaire, exécutable |
| Solde | Somme des sorties, calculée par le portefeuille | Nombre enregistré | Nombre enregistré (lamports) |
| Dépenser une partie | Non : on dépense des sorties entières, la monnaie revient | Oui : on soustrait | Oui : on soustrait |
| Protection contre le rejeu | Une sortie ne se dépense qu’une fois | Nonce, plus identifiant de chaîne (EIP-155) | Blockhash récent (150 slots) ou nonce durable |
| Ordre | Les sorties sans lien sont indépendantes | Ordre strict des nonces par compte | Conflits seulement sur les comptes partagés modifiables |
| Ce qui détermine les frais | Taille en vB : plus d’entrées, plus de frais | Gaz consommé par l’exécution | 5 000 lamports par signature, plus frais de priorité |
| Traitement en parallèle | Entrées vérifiées indépendamment | Transactions exécutées en séquence | Les comptes déclarés permettent l’exécution parallèle |
| Confidentialité par défaut | Une nouvelle adresse par paiement, mais des heuristiques | Une adresse porte tout l’historique | Une adresse porte tout l’historique |
| Programmabilité | Scripts limités (Cardano : UTXO étendu) | Contrats intelligents complets | Les programmes possèdent des comptes de données |
| Poids de l’état (daté) | Environ 173 millions de sorties, environ 11 Go (avril 2025, mempool.space) | Environ 390 Gio dans un nœud Geth (janvier 2026, EIP-8037) | Comptes adossés à un solde minimal remboursable |
Aucun des deux modèles ne l’emporte. Le côté UTXO apporte des vérifications locales à chaque transaction et une réponse simple au rejeu, au prix de contrats intelligents malcommodes et de frais qui augmentent avec chaque petit montant reçu. Le côté comptes offre aux programmes une mémoire commune qu’ils peuvent lire et modifier, au prix d’un ordre strict et d’un état qui ne cesse de grossir. Les comptes déclarés de Solana et les sorties étendues de Cardano sont deux tentatives pour emprunter une partie de chacun.
Ce que cela change concrètement pour vous
Quelques habitudes découlent directement des deux conceptions.
- Si vous recevez de nombreux petits paiements en Bitcoin, chacun coûtera le prix d’une entrée en frais le jour où vous le dépenserez. Consolider quand les frais avoisinent 1 sat/vB revient moins cher que pendant un pic de frais, mais cela relie ces paiements entre eux sur la chaîne.
- Une adresse inconnue qui reçoit une partie de votre paiement Bitcoin est normalement votre monnaie rendue. Vérifiez le montant et la liste de pièces de votre portefeuille.
- Le contrôle des pièces, quand votre portefeuille le propose, permet de garder séparées les pièces de provenances différentes et de choisir ce que chaque paiement révèle.
- Sur Ethereum et les autres chaînes EVM, une transaction en attente aux frais trop bas retient toutes les suivantes du même compte. Remplacez-la avec le même nonce et des frais plus élevés, ou annulez-la, plutôt que d’en envoyer d’autres.
- Vos jetons Ethereum sont des lignes dans les contrats de jetons. Les autorisations donnent à d’autres contrats le droit de les déplacer : passez en revue celles que vous n’utilisez plus.
- Sur Solana, chaque compte de jeton vide garde environ 0,002 SOL bloqués comme solde minimal ; le fermer rend les lamports.
- Dans tous les modèles, aucun outil légitime n’a besoin de votre phrase de récupération pour consolider, débloquer ou accélérer quoi que ce soit.
Pièces et moyennes : les règles fiscales qui font écho aux deux modèles
Les administrations fiscales posent la question que pose le modèle UTXO : quelles unités avez-vous vendues ? Ces lignes donnent une information générale, pas un conseil fiscal, et les unités en question sont des unités d’un actif, pas des sorties Bitcoin : une sortie de votre portefeuille n’est pas un lot fiscal à elle seule.
En France, la réponse ressemble à un compte, pas à un tas de pièces. Selon l’article 150 VH bis du code général des impôts, la plus-value d’une cession est le prix de cession diminué du prix total d’acquisition de l’ensemble du portefeuille d’actifs numériques, multiplié par le prix de cession et divisé par la valeur globale du portefeuille au moment de la cession. Peu importe quelles unités ont quitté le portefeuille : une seule formule couvre tout, et c’est le contraire d’un choix de lots. Les plus-values de 2026 sont imposées au prélèvement forfaitaire unique de 31,4 % (12,8 % d’impôt sur le revenu plus 18,6 % de prélèvements sociaux), sauf option du contribuable pour le barème progressif, et rien n’est dû quand le total des prix de cession de l’année ne dépasse pas 305 euros, d’après les explications de l’administration fiscale mises à jour le 17 juillet 2026. Le guide de la fiscalité crypto en France et l’explication du calcul des plus-values crypto détaillent la déclaration.
Pour comparaison, d’autres pays posent la question des unités plus directement. Aux États-Unis, la base de coût est suivie portefeuille par portefeuille, ou compte par compte, pour les acquisitions et ventes à partir du 1er janvier 2025, en vertu des règlements définitifs, section 1.1012-1 du Treasury Regulation. La procédure fiscale 2024-28 de l’IRS (en anglais) a prévu un régime transitoire : les contribuables pouvaient répartir leur base inutilisée (traduction libre) entre les actifs numériques détenus dans chaque portefeuille ou compte au 1er janvier 2025. Dans un portefeuille, on peut identifier les unités précises vendues ; à défaut, les plus anciennes sont réputées vendues les premières (premier entré, premier sorti). Les unités détenues chez un courtier peuvent être identifiées par un ordre permanent. Le détail figure dans le guide de la fiscalité crypto aux États-Unis. L’Italie a sa propre règle : la circulaire 30/E de l’Agenzia delle Entrate du 27 octobre 2023 impose le LIFO (dernier entré, premier sorti) (en italien) pour les crypto-actifs de même nom, et les plus-values réalisées à partir du 1er janvier 2026 y sont imposées à 33 %.
| Pays | Unités considérées comme vendues | Source |
|---|---|---|
| France | Aucune unité : une formule pour tout le portefeuille | Code général des impôts, art. 150 VH bis |
| États-Unis | Par portefeuille ou compte depuis le 1er janvier 2025 ; identification précise, sinon premier entré, premier sorti | Treas. Reg. 1.1012-1 ; IRS Rev. Proc. 2024-28 |
| Italie | Dernier entré, premier sorti, pour les crypto-actifs de même nom | Agenzia delle Entrate, circulaire 30/E de 2023 |
La leçon suivante du parcours reprend la question à laquelle tout registre sert de réponse, quel que soit son modèle : comment un réseau empêche que la même pièce soit dépensée deux fois.
