Explication de l'adresse de portefeuille Solana : Format, sécurité et erreurs courantes

Une adresse de portefeuille Solana est une valeur de 32 octets affichée sous forme de chaîne encodée en base58 que les utilisateurs copient dans les portefeuilles et les explorateurs pour envoyer ou recevoir du SOL et des tokens.

Les bases du format d'adresse Solana

Les adresses de compte Solana sont des valeurs de 32 octets affichées sous forme de chaînes encodées en base58. Ces chaînes ne comportent aucun préfixe fixe et ne contiennent pas de somme de contrôle intégrée, ce qui distingue le format de nombreux autres schémas d'adresses blockchain.

L'encodage base58 sur Solana utilise un alphabet qui exclut délibérément les caractères 0, O, I et l. Cette omission réduit l'ambiguïté visuelle lors de la lecture ou de la copie des adresses. Comme la longueur de l'encodage varie selon le contenu des octets, les chaînes valides vont de 32 à 44 caractères, bien que la grande majorité des adresses mesurent 43 ou 44 caractères.

La représentation compacte prend en charge à la fois les clés publiques on-curve dérivées des paires de clés Ed25519 et les adresses dérivées de programmes off-curve. Dans les deux cas, les mêmes règles base58 s'appliquent, de sorte que les utilisateurs ne voient que la chaîne encodée finale, quelle que soit la manière dont les 32 octets sous-jacents ont été générés. Cette présentation uniforme assure la cohérence des interfaces de portefeuille et des explorateurs de blocs sur l'ensemble du réseau.

En l'absence de somme de contrôle, chaque caractère compte. Une seule substitution ou omission produit une adresse entièrement différente qui semble valide et peut appartenir à un autre compte. La plage de longueurs et les restrictions de l'alphabet constituent donc les principaux repères visuels sur lesquels les utilisateurs s'appuient pour vérifier les adresses avant d'envoyer des fonds.

Clés publiques on-curve et adresses dérivées de programmes

Les adresses de paires de clés Ed25519 sur Solana proviennent de paires de clés cryptographiques standard. Ces adresses on-curve permettent un contrôle direct par clé privée, permettant aux utilisateurs de signer eux-mêmes les transactions et de gérer leurs actifs via des portefeuilles ordinaires.

Les adresses dérivées de programmes (PDA) suivent un modèle différent. Elles sont générées de manière déterministe à partir d'un identifiant de programme et d'un ensemble de seeds, les plaçant hors de la courbe Ed25519. Aucune clé privée n'existe pour une PDA, le contrôle revient donc entièrement au programme qui l'a créée.

Cette différence de contrôle influence les usages. Les adresses on-curve conviennent aux avoirs personnels où un propriétaire doit conserver l'autorité de signature. Les PDA servent aux fonctions contractuelles telles que les séquestres ou les comptes de tokens, où le programme applique la logique et signe sans exposer les clés à des tiers.

Les portefeuilles rejettent les importations de PDA car aucune paire de clés ne correspond à l'adresse. Les développeurs choisissent donc des adresses on-curve pour les fonds des utilisateurs et des PDA lorsque l'autorité programmatique est requise, évitant ainsi les actifs bloqués ou les échecs de signature dus à des types d'adresses incompatibles.

Génération et validation des adresses Solana

Les adresses Solana se forment de manière déterministe à partir de paires de clés Ed25519 ou de seeds. Un portefeuille crée une paire de clés et encode sa clé publique de 32 octets en base58, produisant la chaîne d'adresse finale. Les phrases de seed suivent des chemins de dérivation standard pour recréer la même paire de clés et la même adresse sur tout appareil compatible.

L'encodage base58 utilise l'alphabet 123456789ABCDEFGHJKLMNPQRSTUVWXYZabcdefghijkmnopqrstuvwxyz. Cet ensemble exclut 0, O, I et l afin de limiter la confusion visuelle. Les adresses encodées valides vont de 32 à 44 caractères, 43–44 étant les plus courantes.

La validation nécessite deux vérifications. Premièrement, confirmer que chaque caractère appartient à l'alphabet base58. Deuxièmement, décoder la chaîne et vérifier que le résultat fait exactement 32 octets. Comme les adresses Solana ne comportent pas de somme de contrôle intégrée, ces étapes seules confirment la correction structurelle avant toute utilisation on-chain.

Attaques par empoisonnement d'adresse et erreurs utilisateur

Les attaques par empoisonnement d'adresse fonctionnent en insérant des adresses visuellement similaires dans l'historique de transactions d'un utilisateur. Les attaquants génèrent des adresses Solana qui correspondent aux quatre à six premiers caractères ou aux quatre à six derniers caractères d'un destinataire connu, puis initient de petits transferts ou interactions qui placent l'entrée empoisonnée juste au-dessus ou en dessous des enregistrements légitimes.

Comme les adresses Solana sont de longues chaînes base58 sans sommes de contrôle intégrées, de nombreux utilisateurs ne consultent que le préfixe ou le suffixe visible lors de la confirmation d'une destination. Cette habitude de correspondance partielle permet à un seul caractère différent au milieu de la chaîne de passer inaperçu, acheminant les fonds vers l'attaquant à la place.

Des habitudes de vérification concrètes éliminent la dépendance aux correspondances partielles. Copiez toujours l'adresse complète depuis une source vérifiée et collez-la dans un champ de texte distinct pour une comparaison côte à côte. Étiquetez les contacts récurrents dans le portefeuille afin que les futures sélections affichent un nom plutôt que des caractères bruts. Pour les transferts supérieurs à un seuil personnel, envoyez d'abord un montant de test minimal et confirmez la réception sur un explorateur avant de libérer la somme totale. Lorsque la partie recevant fournit un code QR, scannez-le directement plutôt que de transcrire les caractères manuellement. Les portefeuilles matériels qui affichent l'adresse complète sur leur écran offrent une couche de vérification indépendante qui contourne le presse-papiers de l'appareil hôte.

Ces étapes allongent le processus de confirmation de quelques secondes seulement, mais ferment le vecteur principal utilisé par les attaquants. Une vérification cohérente de la chaîne complète prévient les pertes dues au format d'adresse de Solana et aux raccourcis basés sur l'historique.

Frais, limites de transaction et comparaison des adresses

Chaque transaction Solana entraîne des frais de base fixes de 5 000 lamports par signature, dont la moitié est brûlée et l'autre moitié versée au leader du bloc, plus tout frais de priorisation optionnel. Cette structure par signature affecte directement la manière dont les adresses on-curve et les adresses dérivées de programmes sont utilisées au sein d'une même transaction.

Le format de transaction V1 a porté la taille sérialisée maximale à 4 096 octets. Cette limite plus élevée permet d'inclure jusqu'à 64 comptes dans certains cas et intègre directement les unités de calcul et les détails des frais dans le message, réduisant le nombre de signatures requises pour les opérations complexes qui nécessitaient auparavant plusieurs transactions.

Comme les PDA ne peuvent pas signer, les développeurs les font souvent passer par des signataires on-curve. La limite de 4 096 octets de V1 permet d'intégrer davantage de comptes dans une seule transaction, réduisant le nombre total de signatures et donc les frais de base agrégés lorsque les deux types d'adresses apparaissent ensemble.

FAQ

Quelle doit être la longueur d'une adresse Solana pour être valide ?

Les adresses Solana encodées en base58 vont de 32 à 44 caractères, bien que 43–44 caractères soient les plus courants pour les clés publiques et PDA de 32 octets.

Une adresse dérivée de programme peut-elle recevoir des tokens comme un portefeuille normal ?

Les PDA fonctionnent comme des comptes mais n'ont pas de clés privées, elles ne peuvent donc pas signer de transferts ; les programmes les contrôlent de manière déterministe à la place.

Comment les utilisateurs repèrent-ils les attaques par empoisonnement d'adresse sur Solana ?

Vérifiez toujours l'intégralité de la chaîne d'adresse plutôt que de ne faire correspondre que les premiers ou derniers caractères affichés dans l'historique des transactions.

Quel frais s'applique à chaque transaction Solana ?

Des frais de base de exactement 5 000 lamports sont facturés par signature, dont 50 % sont brûlés et 50 % versés au leader du bloc.

Quelle est la taille maximale des données pour un compte Solana ?

Les comptes prennent en charge jusqu'à 10 Mio de données selon les spécifications actuelles du réseau.

Quand une vérification d'identité peut-elle s'appliquer lors d'un swap Solana ?

Xgram ne nécessite pas de KYC pour la plupart des swaps ; cependant, les transactions signalées par les procédures de conformité peuvent déclencher un examen supplémentaire et une vérification d'identité.