Skip to main content
このページは AI による自動翻訳です。すべての内容は英語版を正とします。英語版を表示 →

IDL とは

Solana 上の Anchor プログラムは、命令、アカウントレイアウト、エラー列挙型、構造体スキーマを記述する IDL(Interface Definition Language)ファイルを公開します。IDL はクライアントコード生成の信頼できる情報源です。TS SDK、Rust CPI クレート、サードパーティ製クライアントはすべて IDL から生成されるか、それに対して手書きされます。 Raydium は CPMM、CLMM、LaunchLab の IDL を公開しています。AMM v4、Stable AMM、Farm(v3 / v5 / v6)は Anchor より前のものであるか、Anchor で配布されていません。これらのアカウント構造は SDK で手動で保守されています。

IDL の場所

IDL は専用リポジトリに保存されています:
具体的なファイル: IDL ファイルはリポジトリの git 履歴でバージョン管理されています。バイト単位での再現性が必要な場合は、特定のコミットにピンしてください。 一部の IDL はメインネットから直接取得することもできます:
現在、2 つのオンチェーン IDL メカニズムがあり、Raydium のプログラムはそれらに分散しています。これは重要です。特定の Anchor CLI バージョンは 1 つだけを認識する可能性があるためです:
CPMM にはレガシー anchor:idl アカウントがありません。 その IDL は Program Metadata プログラムに移行されたため、anchor idl fetch CPMMoo8L3F4NbTegBCKVNunggL7H1ZpdTHKxQB5qKP1C はレガシー PDA のみをチェックする Anchor CLI では失敗します。CLI がメタデータプログラムをサポートするまで、SDK に付属の IDL を使用するか、上記のメタデータアカウントを読み取ってください。
3 つのレガシー IDL アカウントはすべて、IDL 権限 2XVnob28A5Qnpcy95UVeHWNT6G8Poy3tpA3AFyAMoZDt によって書き込み可能です。これはプログラムの BPF アップグレード権限とは別です。したがって、IDL は再デプロイなしで更新でき、再デプロイより遅れることもあります。オンチェーン IDL を便利なものとして扱い、デプロイされたバイトコードの形状の証明として扱わないでください。

TypeScript クライアントの再生成

Anchor のコード生成は IDL から型付きクライアントを生成します:
ほとんどの統合者はこれを行いません。代わりに、より高レベルの raydium.cpmm.swap(...) ヘルパーを使用します。これは Anchor メソッドとすべてのブックキーピング(ATA 作成、転送手数料調整、計算予算、Token-2022 プログラムルーティング)をラップします。SDK の下のレイヤーが必要な場合にのみ再生成してください。

Rust クライアント(CPI クレート)の再生成

Raydium は IDL を持つプログラムの Anchor クレートを公開しています:
コード内では、lib 名 raydium_cp_swap と raydium_clmm で参照してください。raydium_amm_v3 という名前のクレートはどのスペルでも存在しません。ブランチが異なることに注意してください。raydium-cp-swap の master はまだ anchor-lang 0.32.1 をピンしているため、Anchor-1.0 統合には chore/upgrade-anchor が必要です。CLMM はどちらの方法でも 0.32.1 にあるため、2 つはクレートを共有できません。 cpi フィーチャーは cpi::accounts::<Ix> アカウント構造体と cpi::<ix>() インボーカーを公開します。すぐに使用できる CPI ラッパーです。使用パターンについては sdk-api/rust-cpi を参照してください。 新しいバインディングを生成する場合:

Python クライアントの再生成

公式の Raydium Python SDK はありません。サードパーティ製ジェネレータには以下が含まれます:
  • anchorpy — Anchor の TypeScript クライアントの Python ポート。IDL から型付きメソッドビルダーを生成します。
  • solders — 低レベルの Solana プリミティブ(トランザクション、キーペア、パブキー)の Rust バインディング。anchorpy の下で使用されます。
より詳細なウォークスルーについては sdk-api/python-integration を参照してください。

IDL 変更ポリシー

Raydium は IDL の安定性について以下のルールに従います:
  1. 命令ディスクリミネータは変わりません。 新しい命令を追加すると列挙型の末尾が拡張されます。既存のディスクリミネータは安定したままです。
  2. アカウントサイズは安定しており、新しいフィールドは予約済みパディングから取得されます。 すべての Raydium 状態構造体は作成時にサイズ設定された末尾パディング領域を持ち、新しいフィールドは追加されるのではなくそのパディングから取得されます。したがって、アカウントのバイト長とすべての既存フィールドのオフセットは固定されたままです。その結果、以前パディングとして読み取ったバイトが意味を持つようになり、フィールドはパディングに戻すことができます(2026-08-31 リリースで PlatformConfig.curve_params が行ったように)。アップグレード後に構造体定義を再度読み取ってください。パディングがゼロのままであると仮定しないでください。
  3. エラー列挙型コードは追加のみです。 既存のエラーコードは常に同じことを意味します。
  4. 破壊的な変更は新しいプログラムで提供されます。 再設計が必要な場合、チームは新しいプログラム ID をデプロイします(例:AMM v4 をアップグレードするのではなく、新しいプログラムとしての CPMM)。古いプールは古いプログラムで実行され続けます。新しいプールは新しいプログラムに移動します。
このポリシーは、再生成されたクライアントをほぼ後方互換に保ちます。古い IDL に対して生成されたクライアントは、それが知っているフィールドを、それが知っているオフセットでデコードし続けます。それが見ないのは、それがまだパディングとして扱うものから取得されたフィールドです。また、まれな廃止の場合、デコードするフィールドはもう書き込まれないかもしれません。「余分な末尾バイト」は見ません。アカウント長は変わりません。

IDL が変更されたときの対応

  1. SDK を更新します。 npm update @raydium-io/raydium-sdk-v2。
  2. クライアントコードを再生成します(Anchor コード生成を直接使用する場合)。
  3. アカウントレイアウトを比較します。 新しいレイアウトの末尾フィールドは、コードが見ていない唯一のものです。それらが必要かどうかを確認してください。
  4. 古い命令ディスクリミネータが無効であると仮定しないでください。 ルール 1 に従い、それらはまだ機能します。
  5. メインネットにロールアウトする前に、devnet に対して統合テストを再実行します。

IDL トラブルシューティング

「Invalid discriminator」エラー

通常、IDL のバージョン N に対して構築されたクライアントが、プログラムのデプロイ前バージョンにのみ存在した命令を呼び出そうとしていることを意味します。ライブプログラムから IDL を再度取得してください:
CPMM の場合、これは機能しません。上記の IDL ロケーションテーブルを参照してください。代わりに SDK のバンドルされた IDL を取得してください。

アカウントデコード失敗

program.account.<Name>.fetch(pubkey) が「Invalid account discriminator」でスローされる場合、アカウントは以前のプログラムバージョンで作成され、Anchor はその 8 バイトディスクリミネータを拒否しています。修正は、SDK からの生のレイアウトパーサー(PoolInfoLayout.decode(accountData))を使用することです。これは Anchor ディスクリミネータを強制しません。

生成されたクライアントに命令がない

Anchor の TS コード生成は、IDL エントリに有効な識別子として解析される name を持つ命令に対してのみメソッドを生成します。Raydium の命令はすべてこれを満たしていますが、不一致が見られる場合は、IDL ファイルが現在の SDK リリースからのものであるかどうかを確認してください。

ポインタ

ソース: