Skip to main content
本頁內容由 AI 自動翻譯,所有內容以英文版本為準。查看英文版 →

IDL 是什麼

Solana 上的 Anchor 程式發佈 IDL(介面定義語言)檔案,描述其指令、帳戶配置、錯誤列舉和結構綱要。IDL 是用戶端程式碼產生的真實來源——TS SDK、Rust CPI crate 和第三方用戶端都是從中產生(或手寫)的。 Raydium 為 CPMM、CLMM 和 LaunchLab 發佈 IDL。AMM v4、Stable AMM 和 Farm(v3 / v5 / v6)早於 Anchor 或以其他方式不是 Anchor 發佈的——其帳戶結構在 SDK 中手動維護。

在哪裡找到它們

IDL 位於專用儲存庫中:
確切的檔案: IDL 檔案在儲存庫的 git 歷史中進行版本控制;如果需要位元組對位元組的可重現性,請固定到特定提交。 某些 IDL 也可以直接從主網拉取:
現在有兩個鏈上 IDL 機制,Raydium 的程式分散在它們之間——這很重要,因為給定的 Anchor CLI 版本可能只知道其中一個:
CPMM 沒有舊版 anchor:idl 帳戶。 其 IDL 已遷移到程式元資料程式,因此 anchor idl fetch CPMMoo8L3F4NbTegBCKVNunggL7H1ZpdTHKxQB5qKP1C 在任何只檢查舊版 PDA 的 Anchor CLI 上都會失敗。使用 SDK 附帶的 IDL,或讀取上面的元資料帳戶,直到你的 CLI 支援元資料程式。
所有三個舊版 IDL 帳戶都可由 IDL 授權 2XVnob28A5Qnpcy95UVeHWNT6G8Poy3tpA3AFyAMoZDt 寫入,該授權與程式的 BPF 升級授權分開——因此可以在不重新部署的情況下刷新 IDL,也可以滯後於重新部署。將鏈上 IDL 視為便利,而不是已部署位元組碼形狀的證明。

重新產生 TypeScript 用戶端

Anchor 的程式碼產生從 IDL 產生類型化用戶端:
大多數整合者不這樣做——他們使用更高級的 raydium.cpmm.swap(...) 幫助程式,它包裝 Anchor 方法加上所有簿記(ATA 建立、轉帳費用調整、計算預算、Token-2022 程式路由)。只有在需要 SDK 下方的層時才重新產生。

重新產生 Rust 用戶端(CPI crate)

Raydium 為具有 IDL 的程式發佈 Anchor crate:
在程式碼中,按其庫名稱 raydium_cp_swap 和 raydium_clmm 引用它們。沒有任何拼寫的 raydium_amm_v3 crate。注意分支不同:raydium-cp-swap 的 master 仍然固定 anchor-lang 0.32.1,因此 Anchor-1.0 整合需要 chore/upgrade-anchor;CLMM 無論哪種方式都在 0.32.1 上,這就是為什麼兩者不能共享 crate。 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(例如 CPMM 作為新程式而不是升級 AMM v4)。舊池繼續在舊程式上執行;新池進入新程式。
此政策使重新產生的用戶端大多向後相容:針對舊版 IDL 產生的用戶端繼續解碼它知道的欄位,在它知道的偏移處。它不會看到的是從它仍然視為填充的內容中雕刻出來的欄位——在罕見的退休情況下,它解碼的欄位可能不再被寫入。它不會看到「額外的尾部位元組」:帳戶長度不會改變。

IDL 變更時該怎麼辦

  1. 更新 SDK。 npm update @raydium-io/raydium-sdk-v2。
  2. 重新產生你的用戶端程式碼,如果你直接使用 Anchor 程式碼產生。
  3. 比較帳戶配置。 新配置的尾部欄位是你的程式碼尚未看到的唯一內容;確認你是否需要它們。
  4. 不要假設舊指令判別器無效。 根據規則 1,它們仍然有效。
  5. 在推出到主網之前,針對 devnet 重新執行整合測試。

IDL 故障排除

「無效判別器」錯誤

通常意味著針對 IDL 版本 N 建構的用戶端正在嘗試呼叫僅在程式的預部署版本中存在的指令。從實時程式重新拉取 IDL:
對於 CPMM,這不會起作用——參見上面的 IDL 位置表;改為拉取 SDK 的捆綁 IDL。

帳戶解碼失敗

如果 program.account.<Name>.fetch(pubkey) 拋出「無效帳戶判別器」,帳戶是由先前的程式版本建立的,Anchor 正在拒絕其 8 位元組判別器。修復是使用 SDK 中的原始配置解析器(PoolInfoLayout.decode(accountData)),它不強制執行 Anchor 判別器。

產生的用戶端中缺少指令

Anchor 的 TS 程式碼產生只為 IDL 條目具有可解析為有效識別碼的 name 的指令產生方法。Raydium 的指令都滿足此條件,但如果你看到不匹配,請檢查 IDL 檔案是否來自當前 SDK 版本。

指標

來源: