Skip to main content
هذه الصفحة مُترجَمة آليًا بواسطة الذكاء الاصطناعي. النسخة الإنجليزية هي المرجع المعتمد.عرض النسخة الإنجليزية →

ما هو IDL

برامج Anchor على Solana تنشر ملف IDL (لغة تعريف الواجهة) يصف تعليماتها وتخطيطات الحسابات وتعداد الأخطاء وأنماط الهياكل. يعتبر IDL مصدر الحقيقة لتوليد كود العميل — SDK TypeScript وصندوق Rust CPI والعملاء من جهات خارجية جميعها يتم توليدها من (أو كتابتها يدويًا ضد) IDL. تنشر Raydium IDLs لـ CPMM و CLMM و LaunchLab. AMM v4 و Stable AMM و Farm (v3 / v5 / v6) سابقة لـ Anchor أو غير موزعة عبر Anchor بطريقة أخرى — تُحتفظ بهياكل حساباتها يدويًا في SDK.

حيث تجدها

تعيش IDLs في مستودع مخصص:
الملفات الدقيقة: ملفات IDL مرقمة في سجل git للمستودع؛ ثبّت على commit محدد إذا كنت تحتاج إلى قابلية إعادة الإنتاج بدقة البايت. يمكن أيضًا سحب بعض IDLs مباشرة من mainnet:
هناك الآن آليتان على السلسلة لـ IDL، وبرامج Raydium موزعة عليهما — وهذا مهم لأن إصدار Anchor CLI معين قد يعرف واحدة فقط:
CPMM ليس لديه حساب anchor:idl قديم. تم ترحيل IDL الخاص به إلى برنامج Program Metadata، لذا فإن anchor idl fetch CPMMoo8L3F4NbTegBCKVNunggL7H1ZpdTHKxQB5qKP1C يفشل على أي Anchor CLI يتحقق فقط من PDA القديم. استخدم IDL المرسل مع SDK، أو اقرأ حساب metadata أعلاه، حتى يدعم CLI الخاص بك برنامج metadata.
جميع حسابات IDL الثلاثة القديمة قابلة للكتابة بواسطة سلطة IDL 2XVnob28A5Qnpcy95UVeHWNT6G8Poy3tpA3AFyAMoZDt، وهي منفصلة عن سلطة ترقية BPF للبرامج — لذا يمكن تحديث IDL دون إعادة نشر، ويمكن أيضًا أن يتأخر عن إعادة نشر. تعامل مع IDL على السلسلة كمجرد راحة، وليس كإثبات لشكل bytecode المنشور.

إعادة توليد عميل TypeScript

يُنتج codegen الخاص بـ Anchor عميلاً مكتوبًا من IDL:
معظم المدمجين لا يفعلون هذا — يستخدمون مساعد raydium.cpmm.swap(...) ذو المستوى الأعلى الذي يلف طرق Anchor بالإضافة إلى كل الحفظيات (إنشاء ATA، تعديل رسوم النقل، ميزانية الحساب، توجيه برنامج Token-2022). أعد التوليد فقط عندما تحتاج إلى طبقة أسفل SDK.

إعادة توليد عميل Rust (صندوق CPI)

تنشر Raydium صناديق Anchor للبرامج التي لديها IDLs:
في الكود، أشر إليها باستخدام أسماء lib الخاصة بها، raydium_cp_swap و raydium_clmm. لا يوجد صندوق يسمى raydium_amm_v3 تحت أي تهجئة. كلا المستودعين master يثبتان anchor-lang =1.0.2، لذا يشترك الصندوقان في سطر Anchor واحد ويمكنهما العيش في صندوق واحد. تكشف ميزة cpi عن هياكل حسابات cpi::accounts::<Ix> و invokers cpi::<ix>() — غلافات CPI جاهزة للاستخدام. انظر sdk-api/rust-cpi لأنماط الاستخدام. إذا كنت تفضل توليد ربطات جديدة:

إعادة توليد عميل Python

لا يوجد SDK Python رسمي لـ Raydium. تشمل المولدات من جهات خارجية:
  • anchorpy — منفذ Python لعميل Anchor TypeScript. يولد منشئي طرق مكتوبة من IDLs.
  • solders — بدائيات Solana منخفضة المستوى (معاملات، مفاتيح، pubkeys) في ربطات Rust؛ تُستخدم تحت anchorpy.
انظر sdk-api/python-integration لشرح أكثر اكتمالاً.

سياسة تغيير IDL

تتبع Raydium هذه القواعد لاستقرار IDL:
  1. مميزات التعليمات لا تتغير أبدًا. إضافة تعليمات جديدة تمدد التعداد في النهاية؛ المميزات الموجودة تبقى مستقرة.
  2. أحجام الحسابات مستقرة؛ الحقول الجديدة تأتي من الحشو المحجوز. كل هيكل حالة Raydium يحمل منطقة حشو زائدة بحجم عند الإنشاء، والحقل الجديد يُنحت من هذا الحشو بدلاً من الإضافة — لذا يبقى طول الحساب بالبايت وإزاحات جميع الحقول الموجودة مسبقًا ثابتة. النتيجة هي أن البايتات التي كنت تقرأها سابقًا كحشو يمكن أن تصبح ذات معنى، والحقل يمكن أن يتقاعد مرة أخرى إلى الحشو (كما حدث مع PlatformConfig.curve_params في إصدار 2026-08-31). أعد قراءة تعريف الهيكل بعد ترقية؛ لا تفترض أن الحشو يبقى صفرًا.
  3. أكواد تعداد الأخطاء قابلة للإضافة فقط. كود خطأ موجود يعني دائمًا نفس الشيء.
  4. التغييرات الجذرية تُشحن في برامج جديدة. عندما يكون هناك حاجة لإعادة تصميم، يقوم الفريق بنشر معرف برنامج جديد (مثل CPMM كبرنامج جديد بدلاً من ترقية AMM v4). تستمر المجموعات القديمة في التشغيل على البرنامج القديم؛ المجموعات الجديدة تذهب إلى الجديد.
تحافظ هذه السياسة على توافق العملاء المُنتجة بشكل أساسي للخلف: عميل مُنتج ضد IDL أقدم يستمر في فك تشفير الحقول التي يعرفها، بالإزاحات التي يعرفها. ما لن يراه هو حقل منحوت من ما يعتبره لا يزال حشوًا — وفي حالة التقاعد النادرة، قد لا يتم كتابة حقل يفك تشفيره. لا يرى “بايتات زائدة زائدة”: طول الحساب لا يتغير.

ماذا تفعل عندما يتغير IDL

  1. حدّث SDK. npm update @raydium-io/raydium-sdk-v2.
  2. أعد توليد كود العميل الخاص بك إذا كنت تستخدم Anchor codegen مباشرة.
  3. قارن تخطيط الحساب. الحقول الزائدة للتخطيط الجديد هي الشيء الوحيد الذي لم يره الكود الخاص بك؛ تأكد مما إذا كنت تحتاجها.
  4. لا تفترض أن مميزات التعليمات القديمة غير صالحة. وفقًا للقاعدة 1، لا تزال تعمل.
  5. أعد تشغيل اختبارات التكامل ضد devnet قبل الانتقال إلى mainnet.

استكشاف أخطاء IDL

أخطاء “Invalid discriminator”

عادة ما يعني أن عميلاً مبنيًا ضد الإصدار N من IDL يحاول استدعاء تعليمة موجودة فقط في نسخة ما قبل النشر من البرنامج. أعد سحب IDL من البرنامج المباشر:
بالنسبة لـ CPMM هذا لن يعمل — انظر جدول موقع IDL أعلاه؛ اسحب IDL المرسل مع SDK بدلاً من ذلك.

فشل فك تشفير الحساب

إذا رمى program.account.<Name>.fetch(pubkey) مع “Invalid account discriminator”، تم إنشاء الحساب بواسطة نسخة برنامج سابقة و Anchor يرفض مميز 8 بايت الخاص به. الحل هو استخدام محلل التخطيط الخام من SDK (PoolInfoLayout.decode(accountData)) الذي لا يفرض مميزات Anchor.

تعليمات مفقودة في العميل المُنتج

يولد codegen TS الخاص بـ Anchor فقط طرقًا للتعليمات التي يحتوي إدخال IDL الخاص بها على name يُحلل كمعرف صالح. جميع تعليمات Raydium تستوفي هذا، لكن إذا رأيت عدم تطابق، تحقق مما إذا كان ملف IDL من إصدار SDK الحالي.

مؤشرات

المصادر: