Pourquoi certaines blockchains affichent ce que vous signez (et d’autres

Niveau 1 : Transparence architecturale — l’intention de la transaction est lisible par conception

Quatre écosystèmes se distinguent : ils font de la signature claire une conséquence naturelle de leur protocole, sans dépendre d’outils externes.

XRP Ledger

XRP Ledger offre le modèle de signature claire le plus abouti parmi les blockchains majeures. Son architecture repose sur un ensemble fini d’environ 50 types de transactions énumérés (Payment, OfferCreate, TrustSet, EscrowCreate, NFTokenMint, etc.), chacun avec un schéma défini de champs nommés et typés. 

Le format binaire est auto-descriptif : un champ TransactionType rend le décodage totalement déterministe, et le schéma complet est maintenu dans le fichier de définitions du code source rippled. 

Un hardware wallet peut afficher chaque champ de chaque type de transaction connu : destinataire, montant (avec devise et émetteur pour les tokens), frais, mémos et paramètres spécifiques. Le modèle basé sur les comptes rend les montants explicites (pas de complexité UTXO) et les frais sont un champ simple, non un calcul implicite. 

Pratiquement 100 % des transactions mainnet actuelles peuvent être signées de façon claire. Le seul risque est que de nouveaux types de transactions ajoutés via des évolutions du protocole (comme Vault ou Loan) nécessitent une mise à jour du wallet ; les types inconnus retombent en signature aveugle.
 

Polkadot / Substrate

Polkadot a développé la solution de signature claire la plus sophistiquée techniquement du secteur. Son système de métadonnées d’exécution (MetadataV14/V15) fournit un registre auto-descriptif de chaque pallet (module), appel et type de données du runtime. 

Chaque transaction (extrinsic) est structurée comme pallet_index || call_index || encoded_arguments, et les métadonnées indiquent précisément la signification de ces indices et comment décoder les arguments. 

Le défi principal : les métadonnées complètes dépassent 200 Ko — bien trop pour les wallets disposant de 64 Ko de RAM. La solution, RFC-0078 (Merkleized Metadata), construit un arbre de Merkle à partir des métadonnées et ne transmet que la partie pertinente (types nécessaires pour la transaction) avec une preuve cryptographique d’inclusion. 

Le hash des métadonnées est vérifié on-chain via l’extension signée CheckMetadataHash, rendant le système sans confiance. Cela permet une application Ledger générique fonctionnant sur tous les parachains Polkadot sans mise à jour par chaîne.

L’approche gère les mises à jour du runtime de façon élégante : même si les indices changent, de nouvelles métadonnées et preuves assurent la fiabilité de la signature.

Cosmos / Tendermint

Cosmos/Tendermint bénéficie d’une architecture à messages typés : chaque transaction contient un ou plusieurs objets sdk.Msg encapsulés dans Protobuf google.protobuf.Any, qui inclut un champ type_url identifiant le type de message.
Les messages standards comme MsgSend, MsgDelegate et MsgVote ont des schémas bien connus. 

La solution dédiée à la signature claire est SIGN_MODE_TEXTUAL (ADR-050), introduite dans Cosmos SDK v0.50. Elle affiche les transactions en séquences adaptées aux petits écrans (~40 caractères), avec des value renderers qui convertissent les données brutes au format lisible : les montants s’affichent « 2 ATOM » au lieu de « 2000000uatom », les adresses utilisent bech32, les dates RFC3339. 

Les développeurs peuvent fournir des renderers personnalisés pour leurs types de messages (à condition que les fonctions de formatage et de parsing soient parfaitement réversibles). La charge signée inclut la représentation textuelle et le hash des données brutes, garantissant la sécurité.

NEAR Protocol

NEAR Protocol assure la signature claire grâce à des choix architecturaux privilégiant la lisibilité humaine. Les identifiants de compte sont des noms lisibles (ex. : « alice.near ») et non des adresses hexadécimales. 

Les transactions contiennent des enums typés Action (Transfer, Stake, FunctionCall, AddKey, etc.) toujours identifiables. Surtout, l’action FunctionCall inclut un method_name en texte clair (ex. : « transfer », « set_greeting ») et des arguments sérialisés en JSON par défaut. 

Un hardware wallet peut afficher : « Appeler la méthode ‘swap’ sur app.defi.near avec args : {amount: 1000, token: 'usdc.near'} ». C’est bien plus lisible que tout système basé sur des sélecteurs. La principale limite : certains contrats utilisent des arguments Borsh sérialisés pour gagner en efficacité, ce qui les rend opaques sans le schéma.

Niveau 2 : Signature conditionnellement claire — opérations natives lisibles, smart contracts problématiques

La signature claire fonctionne bien pour les opérations de base. Mais dès que la programmabilité générale entre en scène, la lisibilité se dégrade fortement.

Bitcoin

Bitcoin occupe une place à part : son modèle de transaction pose des défis de signature claire même sans smart contracts. Le modèle UTXO fait que les transactions brutes ne contiennent pas le montant des entrées : les inputs référencent des sorties antérieures par hash et index, mais sans préciser leur valeur. 

Sans cette information, un hardware wallet ne peut pas calculer les frais (total des entrées moins total des sorties) ni vérifier qu’il ne se fait pas piéger. PSBT (BIP 174) résout ce problème en encapsulant les transactions non signées avec les métadonnées UTXO et les chemins de dérivation BIP32 pour identifier les adresses de change. 

Ainsi, les wallets peuvent afficher clairement les adresses destinataires, montants et frais pour les paiements standards, couvrant environ 90 % des transactions courantes. La complexité augmente avec les multisigs, scripts verrouillés dans le temps, et les dépenses Taproot — P2SH et P2WSH masquent des scripts arbitraires derrière des hashes, et la structure MAST de Taproot rend invisibles les conditions alternatives tant qu’elles ne sont pas utilisées.

Aptos

Aptos bénéficie du système de types solide de Move et de la disponibilité des ABIs on-chain. Les charges de transaction contiennent des identifiants de fonction entièrement qualifiés, comme 0x1::aptos_account::transfer : l’adresse du module, son nom et le nom de la fonction sont tous visibles. 

Le SDK peut interroger les ABIs on-chain pour désérialiser les arguments BCS. Ainsi, un hardware wallet avec accès à l’ABI pourrait afficher : « Appeler 0x1::aptos_account::transfer(recipient: 0xABC..., amount: 1000) ». 

Cependant, BCS (Binary Canonical Serialization) n’est pas auto-descriptif : sans schéma ABI, les octets BCS bruts sont illisibles. Les scripts (bytecode Move arbitraire) contournent complètement le format structuré. L’application Ledger Aptos inclut un réglage explicite « Enable Blind Signing » pour les transactions complexes, ce qui confirme l’écart entre opérations simples et complexes.

Stellar

Le modèle du niveau 2 dans sa forme la plus pure. Ses 26 types d’opérations classiques (Payment, ChangeTrust, ManageSellOffer, etc.) ont des schémas fixes et sont entièrement interprétables : l’application Ledger affiche le type d’opération, le montant, la destination, l’actif, le mémo et les frais étape par étape. Environ 95 % de couverture pour les opérations classiques.

• Les smart contracts Soroban (lancés en 2024) réintroduisent le problème d’opacité d’Ethereum. Les appels arrivent sous forme d’InvokeHostFunction avec des adresses de contrat opaques et des paramètres encodés en ScVal, nécessitant une connaissance spécifique du contrat pour décoder. Pratiquement 0 % de signature claire pour les interactions Soroban brutes sans métadonnées externes.

Algorand

Sept types de transactions typées (Payment, Asset Transfer, Asset Configuration, Key Registration, Application Call, Asset Freeze, State Proof) — tous interprétables grâce à l’encodage MessagePack. La norme ARC-4 ABI fournit les signatures de méthodes, noms de paramètres et descriptions pour les smart contracts compatibles.

• Les contrats non ARC-4 ont des arguments opaques.
• Tous les smart contracts peuvent générer jusqu’à 256 transactions internes, y compris des appels imbriqués sur 8 niveaux — complètement invisibles lors de la signature.

Cardano & Tezos

Le modèle eUTXO de Cardano permet d’afficher clairement entrées, sorties, frais et valeurs multi-actifs pour les transactions simples. Mais les interactions avec les scripts Plutus impliquent des datums et redeemers, structures CBOR arbitraires sans schéma standard pour l’interprétation humaine. La CIP-21 précise que le mode Plutus « vise la flexibilité maximale au prix d’un risque de confusion pour l’utilisateur ».

Tezos a un avantage structurel : les types de paramètres de contrat sont stockés on-chain et les entrypoints utilisent des noms en clair plutôt que des sélecteurs hashés, éliminant le risque de collision. Mais l’encodage binaire Micheline nécessite tout de même le schéma de type du contrat pour un affichage complet, et l’application Ledger Tezos reconnaît sa couverture limitée des paramètres complexes.

❌ Opaque par conception — la signature claire est un défi structurel

Des choix d’architecture fondamentaux — et non un manque d’outils — rendent la signature claire intrinsèquement difficile ici. Les couches de métadonnées externes aident à la marge mais ne peuvent pas corriger l’architecture de base.

Ethereum / EVM Chains

Le cas le plus emblématique et étudié. Lorsqu’un utilisateur interagit avec un smart contract, le champ data de la transaction contient un sélecteur de fonction sur 4 octets (les 4 premiers octets du keccak256 de la signature de fonction), suivi de paramètres ABI-encodés sur des mots de 32 octets. Sans l’ABI JSON du contrat — qui n’est pas stocké on-chain — ce n’est que du bruit hexadécimal. Un hardware wallet voyant 0xa9059cbb000...03e8 ne peut pas savoir qu’il s’agit d’un « Transfer de 1000 tokens vers 0xABC... » sans métadonnées externes.

Les difficultés s’accumulent avec les schémas propres à l’EVM :

• Collisions de sélecteurs de fonction : la base 4byte.directory recense près d’un million de signatures — bien au-delà du seuil du paradoxe des anniversaires pour un espace de 32 bits. Différentes fonctions peuvent produire le même sélecteur.
• Proxy contracts : l’exécution passe par delegatecall vers des contrats d’implémentation dont l’adresse peut changer à tout moment. Le hack Bybit a précisément exploité cette faille.
• Patrons multicall : encodage récursif de calldata ABI dans des paramètres.
• EIP-712 : améliore la lisibilité des messages off-chain (permis, ordres) mais ne change rien à l’opacité des transactions on-chain.

Solana

Probablement l’architecture la plus complexe pour la signature claire. Les instructions de transaction contiennent un program_id, une liste de comptes et un tableau d’octets d’instructions opaque. Il n’existe pas d’ABI standardisé : chaque programme définit son propre format de sérialisation. Le framework Anchor propose une convention semi-standard (discriminateurs de 8 octets issus du SHA-256 du nom d’instruction), mais il s’agit d’une convention de framework, non d’une obligation protocolaire. Beaucoup de programmes n’utilisent pas Anchor et ne publient pas d’IDL.

• Les Address Lookup Tables dans les transactions versionnées compressent les adresses 32 octets en indices sur 1 octet — les wallets ne peuvent pas vérifier le contenu de la lookup table sans accès on-chain. La documentation officielle de Solana le reconnaît explicitement.
• Les chaînes Cross-Program Invocation sont invisibles lors de la signature.
• Les transferts SOL simples et opérations SPL token — Ledger sait les interpréter. Les interactions DeFi, qui représentent la majorité du volume Solana, nécessitent quasi systématiquement la signature aveugle.

TON

Combine plusieurs caractéristiques architecturales qui, prises séparément, résistent déjà à la signature claire :

• Structure cellulaire des données : toutes les données sont représentées sous forme d’arbres de cellules (jusqu’à 1023 bits et 4 références par cellule), nécessitant un parcours récursif pour décoder les messages dépassant une cellule.
• Encodage TL-B : opère au niveau du bit avec des constructeurs complexes et des références récursives — bien plus difficile à parser sur un hardware wallet que les formats alignés sur l’octet.
• Pas d’ABI universel : les op codes 32 bits sont une convention, pas une règle du protocole.
• Exécution asynchrone : une seule action utilisateur peut déclencher des messages internes en cascade sur plusieurs contrats et shards dans les blocs suivants. L’utilisateur ne signe que le message externe initial — tout ce qui suit est invisible et imprévisible au moment de la signature.

Sui (mention honorable)

Sui partage le système de types fort de Move avec Aptos, ce qui aide au niveau des instructions. Mais les Programmable Transaction Blocks de Sui peuvent contenir jusqu’à 1 024 commandes enchaînant les résultats — fractionner un coin, déposer sur un protocole DeFi, emprunter, transférer les fonds, le tout en une seule transaction atomique. Si chaque commande est bien typée, afficher une PTB multi-étapes sur l’écran d’un hardware wallet de façon intelligible reste un défi UX extrême. Comprendre l’ensemble de la transaction suppose d’analyser toute la séquence de commandes et leurs dépendances de données.