Skip to main content
Cette page est traduite automatiquement par IA. La version anglaise fait foi.Voir la version anglaise →
Les programmes plus récents de Raydium (CPMM, CLMM, Farm v6, LaunchLab) sont écrits en Anchor — un framework Rust qui s’appuie sur le modèle natif de Solana pour fournir la validation des comptes, la gestion des erreurs et un IDL (interface description). AMM v4 et les anciennes farms sont antérieurs à Anchor. Comprendre les deux paradigmes vous aide à lire le code, générer des clients à partir de l’IDL et déboguer les erreurs inattendues.

Modèle de déploiement des programmes

Chaque programme Solana réside à une Pubkey. Le bytecode du programme est stocké dans un compte exécutable appartenant au BPF Upgradable Loader (BPFLoaderUpgradeab1e11111111111111111111111). Un déploiement de programme comprend trois comptes :
  1. Compte du programme : petit compte de métadonnées à l’ID du programme. Propriétaire : BPF Upgradable Loader.
  2. Compte ProgramData : contient le bytecode réel. Dérivé comme [program_id, "programdata"].
  3. Compte Buffer (transitoire) : contient le nouveau bytecode lors d’une mise à jour. Supprimé après la mise à jour.
Le compte ProgramData possède une autorité de mise à jour — une clé qui peut remplacer le bytecode par une nouvelle version. L’autorité de mise à jour de Raydium est un multisig derrière un timelock de 24 heures ; voir security/admin-and-multisig.

Vérifier un programme déployé

Pour confirmer que ce qui est on-chain correspond à la source approuvée par l’audit :
Les hashes correspondants prouvent que vous interagissez avec la source que vous pensez utiliser. Raydium publie les instructions de construction vérifiées dans les notes de version.

Anchor : un framework au-dessus de Solana

Les programmes Solana bruts sont des fonctions Rust avec cette signature :
Anchor enveloppe tout le code passe-partout et vous permet d’écrire :
Anchor :
  • Génère automatiquement un discriminateur déterministe de 8 octets pour chaque instruction et chaque type de compte.
  • Valide les contraintes des comptes (propriétaire, seeds, writable, signer, mint-matches, token-program-matches) avant l’exécution de votre code.
  • Génère un IDL — un fichier de description d’interface que les clients utilisent pour appeler le programme.
  • Fournit une bibliothèque client Rust, TypeScript et Python.

Le discriminateur de 8 octets

Chaque compte Anchor et chaque instruction Anchor commence par un discriminateur de 8 octets — les 8 premiers octets du SHA-256 d’une chaîne fixe :
Quand vous appelez une instruction Anchor, les 8 premiers octets des données d’instruction sont ce discriminateur ; Anchor envoie au bon gestionnaire en les recherchant. Quand vous lisez un compte Anchor, les 8 premiers octets vous indiquent son type — crucial pour les outils comme getProgramAccounts qui énumèrent tous les comptes d’un type.

Erreurs

Les programmes Anchor définissent les erreurs via #[error_code] :
Anchor attribue automatiquement ces codes numériques à partir de 6000 (0x1770). Le tableau complet des codes d’erreur de Raydium se trouve dans reference/error-codes.

L’IDL

Un fichier IDL (Interface Description Language) Anchor est une description JSON d’un programme : ses instructions, comptes, types, erreurs et événements. C’est l’équivalent d’un ABI Ethereum. Raydium publie les IDLs pour tous les programmes Anchor. Récupérez en direct depuis la chaîne :
Ou depuis la source du SDK : src/raydium/*/idl/*.json.

Structure de l’IDL

Générer un client à partir de l’IDL

La CLI anchor d’Anchor génère les types TypeScript et Rust :
Les outils tiers comme Codama peuvent générer des clients Rust, Go, Python ou JavaScript à partir d’un IDL. (Codama est le successeur de Kinobi de Metaplex, qui n’a jamais fourni qu’un générateur JavaScript.)

Quand l’IDL est votre ami

Si vous souhaitez construire une intégration personnalisée qui ne passe pas par le SDK Raydium :
  1. Récupérez l’IDL (en direct depuis la chaîne ou depuis la source du SDK).
  2. Recherchez l’instruction que vous voulez (par exemple, swap_base_input).
  3. Construisez les données d’instruction : discriminateur de 8 octets + args encodés.
  4. Passez les comptes dans l’ordre spécifié par l’IDL.
Voir sdk-api/anchor-idl pour des exemples détaillés.

Programmes pré-Anchor : AMM v4 et Farm v3/v5

Ces programmes sont antérieurs à Anchor. Ils utilisent :
  • Dispatch d’instruction manuel : une balise u8 dans instruction_data avec une instruction match.
  • Validation manuelle des comptes : if accounts[0].owner != &expected_program { ... }.
  • Args d’instruction sérialisés en Borsh : pas de discriminateur, juste instruction_data[1..].
  • Layout via #[repr(C, packed)] : disposition binaire de struct C.
Le SDK Raydium v2 fournit les layouts TypeScript pour les instructions AMM v4 non-Anchor afin que les clients puissent encoder/décoder sans Anchor :
Le modèle d’intégration est le même — vous n’obtenez simplement pas la génération automatique pilotée par l’IDL d’Anchor.

Mécaniques de mise à jour des programmes

Seule l’upgrade_authority du ProgramData peut effectuer une mise à jour. Étapes :
  1. Compilez le nouveau bytecode.
  2. Écrivez-le dans un compte buffer (solana program write-buffer).
  3. Soumettez une instruction de mise à jour : BpfLoaderUpgradeable::Upgrade { buffer, program, authority }.
  4. Le runtime remplace atomiquement le bytecode du programme par le contenu du buffer.
Raydium gère cela derrière un timelock de 24 heures implémenté dans les paramètres du multisig Squads. Une transaction de mise à jour doit attendre 24 heures après l’approbation du multisig avant l’exécution. Cela protège contre les mises à jour précipitées ou forcées. Voir security/admin-and-multisig.

Rendre un programme immuable

Une autorité de mise à jour peut être définie sur None, auquel cas le programme devient définitivement immuable. Raydium n’a pas fait cela pour aucun produit — l’équipe conserve la capacité de pousser les correctifs de sécurité. Compromis : les utilisateurs doivent faire confiance au processus multisig + timelock.

Programmes et loyer

Le déploiement d’un programme consomme des lamports exempts de loyer :
  • Un programme de 50 KB : ~0,35 SOL de loyer.
  • Un programme de 200 KB : ~1,4 SOL de loyer.
Fermer un programme (via solana program close) retourne les lamports. Les programmes Raydium restent actifs et ne sont pas programmés pour la fermeture.

Déboguer les programmes Anchor

Sortie des journaux

La macro msg! d’Anchor écrit dans le journal de la transaction. Simulez une transaction pour voir les journaux :
Les journaux incluent :
  • Invocation du programme (Program CPMMoo8... invoke [1]).
  • Appels msg! du code du programme.
  • Consommation d’unités de calcul (consumed 137842 of 400000 compute units).
  • Succès ou erreur du programme.

Codes d’erreur

Si un programme Anchor lève une exception, le journal affiche :
0x1770 = 6000 décimal = la première erreur Anchor (par exemple, SlippageExceeded). Croisez avec le tableau errors de l’IDL. Voir reference/error-codes pour le tableau complet des erreurs de Raydium.

Incompatibilités de disposition des comptes

Si vous passez le mauvais compte au mauvais emplacement, les macros de validation des comptes d’Anchor retournent des erreurs comme :
Les numéros d’erreur inférieurs à 6000 sont les erreurs intégrées d’Anchor (voir l’énumération ErrorCode d’Anchor) ; les erreurs ≥6000 sont les codes personnalisés du programme.

Pointeurs

Sources :