Champs de Compte Solana

Dans Solana, presque tout l'état on-chain est représenté par des comptes. Contrairement aux architectures blockchain traditionnelles qui lient étroitement le code et le stockage, Solana sépare les programmes exécutables du stockage d'état. Ce design fait du modèle de compte Solana l'un des concepts les plus importants pour les développeurs construisant sur le réseau.

Comprendre les champs de compte est essentiel lorsque vous travaillez avec des portefeuilles, des tokens SPL, des NFTs, des PDAs ou des protocoles DeFi.

La Structure Principale d'un Compte Solana

Un compte Solana est généralement représenté en interne comme :

pub struct Account {
    pub lamports: u64,
    pub data: Vec<u8>,
    pub owner: Pubkey,
    pub executable: bool,
    pub rent_epoch: Epoch,
}

Chaque champ a un but différent dans l'environnement d'exécution de Solana.

Lamports

Le champ lamports stocke le solde de SOL associé au compte.

pub lamports: u64

Les lamports sont la plus petite unité de SOL.

1 SOL = 1 000 000 000 lamports

Conceptuellement, cela est similaire à :

• Wei dans Ethereum
• Satoshi dans Bitcoin

Les lamports sont utilisés pour :

• Les frais de transaction
• L'exemption de loyer
• Conserver des soldes de SOL
• Financer de nouveaux comptes

Par exemple :

5 SOL = 5 000 000 000 lamports

lamports

Chaque compte sur Solana doit maintenir un certain solde pour rester actif sur la chaîne.

Données

Le champ data stocke des données binaires arbitraires.

pub data: Vec<u8>

C'est ici que l'état de l'application est stocké.

Dans Solana, les programmes sont des exécutables sans état, tandis que les comptes de données conservent l'état mutable séparément. À cause de cette architecture, presque chaque application décentralisée s'appuie fortement sur les mises en page des données des comptes.

Des exemples de données stockées incluent :

Comptes de jetons SPL

Un compte de jeton stocke généralement :

• Adresse de génération
• Adresse du propriétaire
• Montant du jeton
• Délégation information
• État du compte

Métadonnées NFT

Les comptes de métadonnées NFT peuvent contenir :

• Nom
• Symbole
• URI des métadonnées
• Configuration des redevances
• Adresses des créateurs

Protocoles DeFi

Les pools de liquidité et les AMMs stockent souvent :

• Réserves du pool
• Structures de frais
• Offre LP
• Paramètres administratifs

La plupart des programmes Solana sérialisent les données des comptes en utilisant des formats tels que :

• Borsh
• Sérialisation Anchor
• Agencements de bytes bruts

Propriétaire

Le champ owner spécifie quel programme contrôle le compte.

pub owner: Pubkey

C'est un

des mécanismes de sécurité les plus importants dans Solana.

Seul le programme propriétaire est autorisé à modifier le champ de données du compte.

Par exemple :

Programme Système

11111111111111111111111111111111

Le Programme Système possède des comptes de portefeuille SOL standard.

Programme de Token SPL

Le Programme de Token SPL possède :

• Des comptes de tokens
• Des comptes de mint

Programmes Personnalisés

Si un développeur crée un compte PDA pour un protocole personnalisé, le champ propriétaire est généralement défini sur l'ID du programme du projet.

Ce modèle de propriété crée des limites d'exécution strictes entre les programmes et empêche les modifications d'état non autorisées.

Exécutable

Le champ executable détermine si le compte contient du code exécutable.

pub executable: bool

Si la valeur est :

true

le compte est traité comme un compte de programme.

Les comptes de programme stockent du bytecode BPF compilé qui peut être exécuté par l'environnement d'exécution Solana.

Des exemples typiques incluent :

Type de compteexécutableCompte WalletfalseCompte TokenfalseCompte PDAfalseCompte Programmetrue

La plupart des comptes sur Solana sont des comptes de données non exécutables.

Époque de loyer

Le champ rent_epoch est lié au système de loyer de Solana.

pub rent_epoch: Époque

Parce que le stockage sur la chaîne consomme des ressources des validateurs, Solana a initialement introduit la location pour empêcher une croissance illimitée du stockage.

Les comptes avec des soldes insuffisants pourraient éventuellement être récupérés par le réseau.

Aujourd'hui, la plupart des applications évitent complètement la collecte des frais de location en rendant les comptes exonérés de location.

Les développeurs calculent généralement le solde minimum requis en utilisant :

getMinimumBalanceForRentExemption(espace)

Une fois qu'un compte détient suffisamment de lamports pour satisfaire aux exigences d'exemption de location, il peut rester actif de manière permanente.

Adresses de compte et clés publiques

Lors de l'utilisation des API RPC, les développeurs voient couramment un supplémentaire

champ :

{
  "pubkey": "...",
  "account": {
    "lamports": 123,
    "owner": "...",
    "data": "...",
    "executable": false,
    "rentEpoch": 123
  }
}

Le pubkey est l'adresse du compte.

Il est intéressant de noter que la clé publique n'est pas stockée à l'intérieur de la structure de compte elle-même. Au lieu de cela, Solana associe en interne les adresses aux structures de données de compte.

Conceptuellement, cela ressemble à :

HashMap<Pubkey, Account>

Pourquoi Solana Utilise Cette Architecture

Le modèle de compte est l'une des raisons pour lesquelles Solana atteint un débit extrêmement élevé.

Avant d'exécuter une transaction, Solana exige que la transaction soit

déclare quels comptes seront lus ou écrits.

Cela permet au runtime de déterminer :

• Quelles transactions sont en conflit
• Quelles transactions peuvent s'exécuter en parallèle
• Quels accès à l'état sont isolés

En conséquence, Solana peut traiter de nombreuses transactions indépendantes simultanément plutôt que d'exécuter tout séquentiellement.

Ce modèle d'exécution parallèle est fondamentalement différent de nombreux blockchains traditionnels.