Comptes, transactions et frais

Une question d'espèces

Pensez à votre porte-monnaie. Soit vous avez des billets et des pièces : pour payer 60, vous donnez un billet de 50 et un de 20, et on vous rend 10 de monnaie. Soit vous avez un solde sur un compte de monnaie mobile : pour payer 60, le solde baisse de 60. Les blockchains ont fait les deux choix.

• Modèle UTXO (unspent transaction output, « sortie de transaction non dépensée »). L'état est un ensemble de « sorties » indivisibles, chacune verrouillée pour un propriétaire. Bitcoin fonctionne ainsi.
• Modèle à comptes. L'état est une table : pour chaque compte, un solde et un compteur (le nonce, leçon 2). Ethereum, les chaînes bâties avec le Cosmos SDK et les chaînes Substrate/Polkadot fonctionnent ainsi.

Le même transfert dans les deux modèles (chiffres fictifs)

Awa possède 80 unités et veut en payer 60 à Bineta, avec 2 unités de frais.

En UTXO. Awa possède deux sorties : une de 50 et une de 30. Aucune ne suffit seule, donc la transaction les consomme toutes les deux comme entrées (50 + 30 = 80) et crée de nouvelles sorties :

Une sortie ne se dépense jamais en partie : elle est consommée en entier, et la monnaie est une nouvelle sortie que l'on se renvoie. Les frais ne sont écrits nulle part : c'est la différence entre entrées et sorties. Une fois consommées, les sorties de 50 et 30 disparaissent de l'ensemble.

En comptes. Le solde d'Awa passe de 80 à 80 − 60 − 2 = 18. Celui de Bineta augmente de 60. Dans cet exemple simplifié, les 2 de frais vont au proposant. Le nonce d'Awa augmente de 1.

Comment chacun empêche la double dépense

• UTXO : une sortie ne peut être consommée qu'une fois. Une seconde transaction qui la consomme est invalide, car la sortie n'existe plus dans l'ensemble.
• Comptes : on vérifie que le solde suffit au moment de l'exécution, et le nonce impose un ordre strict aux transactions d'un compte (leçon 2).

Comparaison honnête

Ce que cela ne garantit PAS

• Le modèle UTXO n'est pas automatiquement « anonyme » : réutiliser une adresse ou fusionner des entrées relie des sorties entre elles.
• Le modèle à comptes n'est pas « moins sûr » : le nonce et la vérification du solde y jouent le rôle que l'unicité de consommation joue en UTXO.
• Aucun des deux modèles ne protège contre l'envoi à la mauvaise adresse.

À retenir

UTXO : consommer des sorties entières et en créer de nouvelles ; frais = entrées − sorties. Comptes : modifier des soldes ; frais explicites ; le nonce ordonne.

Le problème : une signature valide reste valide

Awa signe « payer 50 à Bineta ». Cette signature ne dépend que du message. Si un tiers copie la transaction signée et la diffuse une seconde fois, la signature est toujours valide. Sans protection, Bineta recevrait 50 de plus à chaque copie. C'est un rejeu (replay). La signature seule ne dit pas « une seule fois ».

Le nonce : un compteur par compte

Le nonce (« number used once », ici un numéro d'ordre) est un compteur attaché à chaque compte. Il fait partie du message signé. La règle : une transaction n'est valide que si son nonce est exactement le prochain nonce du compte.

Exemple : le prochain nonce d'Awa est 7.

Dans les vrais clients Ethereum, une transaction en avance peut être conservée en attente jusqu'à ce que les nonces manquants arrivent, au lieu d'être rejetée immédiatement. Le réseau d'entraînement de la BAC, plus strict, la rejette. Le nonce donne aussi un ordre : deux paiements du même compte s'exécutent dans l'ordre des nonces.

L'identifiant de chaîne : empêcher le rejeu entre réseaux

Supposons qu'Awa utilise la même paire de clés sur un réseau de test et sur un réseau réel. Si le message signé ne contient pas l'identité du réseau, une transaction signée pour l'un est valide sur l'autre, avec le même compte et le même nonce. Un tiers peut la copier d'un réseau à l'autre : c'est le rejeu inter-chaînes. La parade : inclure un identifiant de chaîne (chain id) dans le message signé. Un nœud du réseau 42 rejette une transaction signée pour le réseau 77, car la signature couvre un autre message ; et si l'identifiant est modifié après coup, la signature ne correspond plus. Ethereum a ajouté une protection de ce type après coup (EIP-155).

Le réseau d'entraînement

Dans l'exercice de ce cours, on signe le texte bac-practice|chain=<id>|to=<destinataire>|amount=<montant>|fee=<frais>|nonce=<nonce>. Chaque champ qui compte est dans le message signé : changer un seul caractère invalide la signature (avalanche, atelier 104). L'outil sign de la page fonctionne avec ECDSA sur la courbe P-256 parce que le navigateur la propose nativement ; les vraies chaînes utilisent surtout d'autres courbes ou schémas (par exemple secp256k1 pour Bitcoin et Ethereum, ed25519 ou sr25519 ailleurs). C'est une simplification de l'exercice, pas une règle du domaine.

Ce que cela ne garantit PAS

• Le nonce n'est pas un horodatage : il ne dit pas quand la transaction a été signée.
• Il n'empêche ni la censure ni le front-running (un tiers qui passe devant votre transaction en payant plus de frais).
• Il protège l'ordre d'un compte, pas contre quelqu'un qui possède votre clé privée : cet acteur signe des nonces valides.
• Le modèle UTXO n'a pas de nonce : sur un même réseau, le rejeu y est impossible parce que les sorties consommées n'existent plus. Entre deux chaînes qui partagent un historique (après une scission), une même sortie existe des deux côtés et une transaction peut être valide sur les deux : il faut alors un marqueur propre à chaque chaîne dans la signature.

À retenir

Nonce exact = une seule exécution et un ordre. Identifiant de chaîne dans le message signé = pas de rejeu d'un réseau à l'autre.

Pourquoi des frais ?

Un bloc a une taille limitée : l'espace est rare. Sans prix, n'importe qui pourrait le saturer avec des milliers de transactions inutiles (spam) et personne ne payerait le travail du proposant. Les frais remplissent deux rôles : rationner l'espace en faveur de ceux qui y accordent le plus de valeur, et rendre le spam coûteux.

Bitcoin : un prix par taille

Dans Bitcoin, comme vu en leçon 1, les frais sont implicites : entrées − sorties. Le proposant classe en général les transactions par frais par unité de taille (frais divisés par la taille de la transaction), pas par frais total. Une transaction qui fusionne beaucoup d'entrées est plus volumineuse, donc plus chère pour le même débit par unité.

Chaînes à comptes avec gaz : un prix par travail

Sur les chaînes de type Ethereum, le travail de calcul est mesuré en gaz (unité de travail). Une transaction fixe une limite de gaz (le maximum qu'elle accepte de consommer) et le calcul réel consomme le gaz utilisé. Depuis la mise à jour dite EIP-1559, le prix par unité de gaz se décompose en :

• frais de base (base fee) : fixé par le protocole selon le remplissage des blocs récents, identique pour toutes les transactions d'un bloc, et brûlé (détruit) ;
• pourboire (priority fee, tip) : un supplément versé au proposant ; dans la transaction, c'est un pourboire maximal que l'émetteur accepte de verser (champ maxPriorityFeePerGas dans Ethereum) ;
• prix maximal (max fee) : le plafond par unité de gaz que l'émetteur accepte de payer.

Le prix effectif est min(prix maximal, frais de base + pourboire). Le coût final est gaz utilisé × prix effectif. Sur Ethereum, à la soumission, le réseau réserve limite de gaz × prix maximal ; la différence avec le coût final est remboursée (ce n'est pas le cas partout : voir plus bas).

Exemple détaillé (unités arbitraires, chiffres fictifs)

Limite de gaz 60 000 ; gaz utilisé 48 000 ; frais de base 20 ; pourboire 3 ; prix maximal 30.

1. Prix effectif : min(30, 20 + 3) = 23.
2. Coût final : 48 000 × 23 = 1 104 000.
3. Réservé : 60 000 × 30 = 1 800 000.
4. Remboursement : 1 800 000 − 1 104 000 = 696 000.

Autre cas : frais de base 28, pourboire 3, prix maximal 30. Le prix effectif est min(30, 31) = 30 : le plafond coupe le pourboire, qui n'est plus que de 2 par unité. Si les frais de base montaient au-dessus de 30, la transaction ne serait plus incluse tant qu'ils resteraient supérieurs à son plafond.

Dans le protocole d'Ethereum, les frais de base varient d'un bloc à l'autre (d'au plus 12,5 % environ par bloc) selon que les blocs récents ont été plus ou moins pleins que la cible. Les autres chaînes ont d'autres mécanismes : prix minimal de gaz fixé par chaque validateur dans le Cosmos SDK, par exemple, et, par défaut dans le Cosmos SDK à notre connaissance, des frais déclarés prélevés en entier, sans remboursement de ce qui n'a pas été consommé. Lisez la documentation de la chaîne ciblée.

Ce que cela ne garantit PAS

• Des frais élevés ne garantissent pas l'inclusion dans le bloc suivant (un proposant peut censurer ; le réseau peut être saturé).
• Des frais bas ne sont pas « gratuits » en cas d'échec : une transaction qui échoue à l'exécution est quand même facturée. Après un échec explicite du contrat (REVERT), c'est le gaz utilisé jusque-là ; après une panne de gaz ou une instruction invalide, c'est toute la limite de gaz qui est consommée (sur Ethereum et les chaînes qui l'imitent).
• Sur Ethereum et les chaînes qui l'imitent, la limite de gaz n'est pas le coût : seul le gaz réellement utilisé est facturé. Sur d'autres chaînes (Cosmos SDK par défaut, à notre connaissance), les frais déclarés sont prélevés en entier : lisez la documentation.
• Les frais ne protègent pas contre la manipulation : un attaquant fortuné peut payer pour monopoliser l'espace.

À retenir

Prix effectif = min(plafond, base + pourboire). Coût = gaz utilisé × prix effectif. Sur Ethereum, réservé − coût = remboursé ; ailleurs, vérifiez.

Quand le portefeuille dit « échec »

Une transaction rejetée n'est pas un mystère : un nœud applique une suite de règles et s'arrête à la première violée. Savoir lire ce message évite les mauvaises réparations (augmenter les frais quand c'est le nonce qui est faux). Voici les six causes que le réseau d'entraînement de la BAC simule, dans l'ordre où il vérifie les règles.

Les vrais nœuds utilisent d'autres messages et d'autres ordres de vérification. L'idée à retenir : un message d'erreur désigne une règle précise ; la réparation dépend de la règle.

Exemple détaillé

Réseau : identifiant 42, frais minimum 5, prochain nonce d'Awa 12, solde d'Awa 1 000. Awa envoie : chaîne 42, montant 990, frais 15, nonce 12.

1. L'empreinte du message correspond à ce qui a été signé : règle 1 satisfaite.
2. Chaîne 42 : règle 2 satisfaite.
3. Nonce 12 : règle 3 satisfaite.
4. Frais 15 ≥ 5 : règle 4 satisfaite.
5. Montant + frais = 990 + 15 = 1 005 > 1 000 : INSUFFICIENT_BALANCE, il manque 5.

Réparation : ramener le montant à 985 (985 + 15 = 1 000) ou alimenter le compte. Augmenter les frais empirerait le déséquilibre.

Autre exemple : message modifié en route

Le serveur reçoit un message affiché « montant = 120 » dont l'empreinte signée correspond à « montant = 100 ». Il calcule l'empreinte SHA-256 de la chaîne canonique « chaîne|émetteur|destinataire|montant|frais|nonce » du message reçu et la compare à l'empreinte signée : les deux diffèrent. Aucune autre règle n'est examinée : PAYLOAD_TAMPERED. C'est pour cela que la signature protège l'intégrité d'une transaction en transit.

Deux simplifications de l'exercice

Dans l'exercice, la vérification de la signature est simulée : le serveur compare l'empreinte du message reçu à l'empreinte que la signature couvre. Une empreinte seule ne prouve rien, car n'importe qui peut la recalculer ; c'est la signature de cette empreinte, vérifiée avec la clé publique, qui prouve l'origine. Ensuite, l'atelier emploie deux textes différents : l'exercice de diagnostic utilise la chaîne canonique chaîne|émetteur|destinataire|montant|frais|nonce, alors que l'exercice « construire, signer et soumettre » utilise le texte bac-practice|chain=… de la leçon 2. Ne réutilisez pas l'un à la place de l'autre.

Ce que cela ne garantit PAS

• Une transaction qui passe toutes les règles est valide, mais pas forcément voulue : elle peut avoir été signée par erreur ou sous contrainte.
• Un rejet par un nœud n'est pas un rejet par le réseau : un autre nœud avec d'autres règles de relais (frais minimum différent, par exemple) peut l'accepter.
• Réussir sur un réseau d'entraînement ne prouve pas que votre code fonctionne sur un vrai réseau : les formats, courbes et règles diffèrent.

À retenir

Un rejet = une règle précise. Lisez l'ordre des vérifications, repérez la première règle violée, réparez cette règle et rien d'autre.