Portefeuilles et signature

Curiosité

1. Pourquoi une transaction Solana possède-t-elle une date d’expiration ?
2. Qu’est-ce qui est exactement approuvé lorsqu’un utilisateur signe une transaction versionnée ?
3. Comment une seule transaction peut-elle faire référence à bien plus de comptes qu’elle n’en énumère en entier ?

Explorer

1. Les clés Solana sont des paires de clés ed25519. La plupart des portefeuilles les dérivent d’une phrase de récupération BIP39 selon le chemin de dérivation m/44'/501'/0'/0'. Cette norme permet aux utilisateurs de restaurer l’intégralité de leur identité dans différents logiciels compatibles, à condition de conserver la phrase mnémonique d’origine de douze ou vingt-quatre mots. La clé privée reste en local ; la clé publique sert, on-chain, d’adresse au compte.
2. Une transaction énumère des instructions précises et les comptes que ces instructions touchent. Point crucial, elle inclut un blockhash récent. Ce hash sert de mécanisme d’expiration : si la transaction n’est pas traitée dans un délai d’environ 150 blocs, soit à peu près 60 à 90 secondes, le blockhash devient obsolète et le réseau rejette la transaction. Les nonces durables (durable nonces) permettent de signer des transactions qui restent valides plus longtemps, en utilisant une valeur stockée dans un compte nonce spécial à la place d’un blockhash récent.
3. La signature approuve chacune des instructions contenues dans la transaction. Un payload malveillant peut transférer des comptes de token ou modifier leurs paramètres d’autorité sans que l’utilisateur ait explicitement conscience de ces sous-instructions. Des portefeuilles comme Phantom, Solflare et Backpack simulent ces transactions pour fournir des aperçus lisibles par un humain. Les utilisateurs peuvent cependant encore approuver des instructions nuisibles par « blind signing » (signature à l’aveugle), où les données brutes sont acceptées sans vérification de leur intention.
4. Les transactions versionnées introduisent les tables de correspondance d’adresses (address lookup tables), qui permettent à une seule transaction de référencer de nombreux comptes par leur indice plutôt que d’énumérer chaque adresse complète. Cette optimisation réduit la taille en octets des opérations complexes qui touchent de nombreux mints de tokens ou positions. Le revers est la complexité : comprendre les adresses résolues exige de décoder les indices de la table à partir de l’état actuel du compte référencé.
5. Les portefeuilles matériels offrent un environnement isolé pour signer, en se connectant via USB ou des codes QR, afin de protéger les clés contre les logiciels malveillants du système hôte. Cependant, la sécurité dépend de l’intégrité de l’application hôte qui crée et affiche les données de la transaction. Si le système hôte est compromis, il peut présenter des informations malveillantes tandis que l’utilisateur signe ce qui semble légitime. Vérifier tous les paramètres directement sur l’écran du dispositif matériel atténue ce vecteur d’attaque spécifique.
6. Pour examiner la structure d’une transaction, ouvrez un explorateur de blocs Solana et sélectionnez n’importe quelle transaction récente impliquant une opération en plusieurs étapes. Développez la section « Instructions » pour voir chaque appel de programme. Examinez ensuite l’onglet « Accounts » pour voir quels comptes chaque instruction a lus ou modifiés. Recoupez ces informations avec les données brutes pour comprendre comment l’aperçu simulé correspond aux changements d’état réels.

Faits clés

Exercice neuf, six, trois, un

Vérification des faits

Les dates, les chiffres et les affirmations ont été vérifiés à l’aide des sources publiées listées ci-dessous.

• Solana Documentation: Transactions and Durable Nonces
• Phantom Developer Documentation: Signing and Simulation
• BIP39: Mnemonic Code for Generating Deterministic Keys
• Solana Documentation: Versioned Transactions and Address Lookup Tables