Skip to main content
هذه الصفحة مُترجَمة آليًا بواسطة الذكاء الاصطناعي. النسخة الإنجليزية هي المرجع المعتمد.عرض النسخة الإنجليزية →
sdk-api/rust-cpi يغطي الآليات منخفضة المستوى لاستدعاء كل برنامج Raydium. هذه الصفحة هي الرفيقة عالية المستوى: لماذا ستؤلف Raydium في برنامجك الخاص، أي نمط يناسب حالتك الاستخدامية، والمادة اللاصقة الكاملة التي تحتاجها من البداية إلى النهاية.

متى يكون CPI هو الأداة الصحيحة

يكون البرنامج المخصص منطقياً عندما تحتاج المبادلة إلى الحدوث بشكل ذري مع تغييرات الحالة الأخرى على السلسلة التي يمكن لبرنامجك فقط أن يقوم بها. الحالات الشائعة:
  • برامج الضمان / أوامر الحد — يودع المستخدم mint في ضمانك، يراقب برنامجك حالة السعر، وعندما تنشط، يقوم برنامجك بمبادلة ذرية عبر Raydium وينسب حساب المستخدم.
  • وكلاء المجمع — تعليمة واحدة توجه المبادلة عبر Raydium وواحد أو أكثر من DEXes الأخرى، مع جميع القفزات تحت فحص انزلاق واحد يملكه برنامجك.
  • خزائن المركبات التلقائية — إيداع LP أو حصة المزرعة في خزانتك، تحصد الخزانة المكافآت على جدول زمني، وتعيد توريد السيولة، وتصدر رموز الأسهم.
  • خزائن الاستراتيجية — مراكز LP ذات الرافعة المالية التي تعيد التوازن بالمبادلة عبر CLMM؛ المصفيات التي تغلق المراكز وتبادل الضمانات في معاملة واحدة.
  • منصات إطلاق الرموز مع الاستحقاق المخصص — يحتفظ برنامجك برموز الاستحقاق ويطلقها في مجموعة Raydium على جدول زمني.
إذا كنت تريد فقط إرسال مبادلة من كود خارج السلسلة، فإن CPI مبالغ فيه — استخدم SDK. يكسب CPI تعقيده فقط عندما تكون الذرية مع حالتك الخاصة هي المتطلب.

أنماط التكوين

النمط 1: وكيل رقيق

يكشف برنامجك عن تعليمة واحدة تتحقق من بعض السياسات (على سبيل المثال، أزواج mint المدرجة في القائمة البيضاء، خصم الرسوم للمستخدمين المتحققين) ثم تحويل إلى Raydium.
تعيش الحالة في ATAs المستخدم. برنامجك لا يملك أي رموز. بصمة ثقة ضئيلة.

النمط 2: الضمان

يملك برنامجك PDA يحتفظ بـ mint الإدخال للمستخدم. عند التشغيل، يوقع PDA CPI إلى Raydium لمبادلة رصيده الخاص.
التفاصيل الحرجة: يوقع PDA عبر CpiContext::new_with_signer. انظر بذور موقع PDA.

النمط 3: متعدد القفزات المركب

يصدر برنامجك عدة CPIs في تعليمة واحدة، مع فرض حد انزلاق واحد عبر جميعها. تحتوي تعليمات مبادلة Raydium على minimum_amount_out الخاصة بها، لكنك تعيينها إلى 0 (أو حد أدنى جداً) وتفرض حد أدنى صارم بعد القفزة الأخيرة بنفسك.
هذا يعطيك بوابة عكسية واحدة للمسار بأكمله. استخدم هذا النمط فقط عندما تثق بأن كل قفزة آمنة من الانزلاق؛ وإلا، دع كل قفزة تفرض الحد الأدنى الخاص بها.

النمط 4: الخزانة / الاستراتيجية

يحتفظ برنامجك برموز LP أو حصة المزرعة في PDA. يستدعي حارس (أو المستخدم) compound()، الذي:
  1. يحصد المكافآت من المزرعة.
  2. يبادل المكافآت برموز المجموعة (CPI إلى CPMM أو CLMM).
  3. يودع العائدات مرة أخرى في LP (CPI آخر).
  4. يراهن على LP الجديد (CPI آخر).
كل ذلك في معاملة واحدة بحيث تتحرك NAV الخزانة بشكل ذري. عادة ما تكون ميزانية الحساب الحسابي 600k–1M CU؛ جداول البحث عن العناوين إلزامية.

بناء قائمة الحسابات

يعكس هيكل Accounts للبرنامج الاستدعاء ترتيب حساب برنامج Raydium، لكن معظم حسابات جانب Raydium هي UncheckedAccount لأن Raydium يتحقق منها بنفسه. تضيف فقط قيود على الحسابات التي تملكها:
عدم التماثل — التحقق الصارم من حساباتك، UncheckedAccount على حسابات Raydium — ليس كسلاً. يتحقق المستقبل من حسابه الخاص؛ التحقق المزدوج في المستدعي يحرق فقط CU ويخاطر بالخروج عن المزامنة عندما تشحن Raydium حقل تخطيط هيكل جديد.

استدعاء CPI نفسه

بذور موقع PDA

ينجح CPI فقط إذا كان PDA الذي تم تمريره كـ authority يطابق الاشتقاق الذي يدعيه المستدعي. يجب أن يتفق الاثنان على:
  1. تسلسل البايت البذري (هنا [b"escrow", user.key().as_ref()]).
  2. الارتفاع.
  3. معرف البرنامج الاستدعاء (برنامجك، وليس Raydium).
لاحظ ما الذي يجب أن يطابقه PDA. خانة authority في CPMM هي PDA خزانته الخاصة — حساب ثابت على مستوى البرنامج يشتقه ويوقّع به بنفسه، ولا يتحكم به برنامجك ولا يستبدله. الحساب الذي يجب أن تتوافق معه بذور PDA الخاصة بك هو payer: يحدث التحقق داخل مساعد CPMM نفسه transfer_from_user_to_pool_vault، الذي يشترط أن يكون الحساب المُمرَّر كـ payer هو مالك input_token_account. الخطأ الشائع: تمرير user كـ payer في حين أن escrow_input_ata مملوك لـ escrow PDA. يرفض برنامج SPL Token مع owner mismatch. اجعل دائماً payer هو مالك ATA — ووقّع له بـ new_with_signer عندما يكون ذلك المالك PDA.

الحسابات المتبقية

تأخذ عدة تعليمات Raydium قائمة بطول متغير من الحسابات المضافة بعد الحسابات الثابتة — الحسابات المتبقية.
  • CLMM SwapV2: 1–8 حسابات TickArrayState لمصفوفات التجزئة التي قد تعبرها المبادلة، في اتجاه المبادلة.
  • Farm v6 Deposit / Harvest / Withdraw: أزواج (reward_vault, user_reward_ata)، زوج واحد لكل فتحة مكافأة نشطة.
  • رموز Token-2022 transfer-hook: برنامج transfer-hook بالإضافة إلى أي حسابات يحتاجها الخطاف.
لا تتحقق مساعدات Anchor CPI من نوع الحسابات المتبقية. مررها:
الترتيب مهم. بالنسبة إلى CLMM:
بالنسبة إلى farm v6 harvest:
يجب أن يمرر برنامجك الاستدعاء الحسابات المتبقية التي يتلقاها من العميل دون تغيير. لا تحاول تصفيتها أو إعادة ترتيبها.

ميزانية الحساب الحسابي للاستدعاءات المركبة

يكلف CPI حوالي 1,500 CU لإطار الاستدعاء نفسه؛ استخدام CU الخاص بالمستقبل يتراكم في الأعلى. أرقام المستقبِل أدناه مقيسة من معاملات فعلية على الشبكة الرئيسية على تجمعات عالية الحجم في 2026-09-09، مقروءة من سطر السجل Program <id> consumed N of M compute units الخاص باستدعاء برنامج Raydium نفسه (لذا فهي تتضمن استدعاءات CPI الداخلية لبرنامج الرموز): أضف حوالي 1,500 لكل إطار CPI بالإضافة إلى نفقات برنامجك الخاص. تتناسب تكلفة مبادلة CLMM مع عدد عبور التيكات، لذا اعتبر رقمها حداً أدنى. تضيف رموز Token-2022 تكلفة معالجة الامتدادات للنقل نفسه؛ قِسها لرموزك الخاصة بدلاً من تطبيق مُضاعِف ثابت.
حملت المراجعات السابقة لهذه الصفحة تقديرات أعلى بـ 5–7× (مبادلة CPMM بـ 150,000 CU، و180,000 لـ CLMM). تلك الأرقام لم تُقَس أبداً. ضع ميزانيتك من قراءة computeUnitsConsumed الخاصة بك، لا من رقم موثّق — ولاحظ أن المعاملة الكاملة تكلف أكثر من تعليمة Raydium وحدها بعد حساب إنشاء ATA وتغليف wSOL وتعليمات ميزانية الحوسبة.
اضبط دائماً ComputeBudgetProgram::set_compute_unit_limit صريح:
سيستنزف سقف 200k CU الافتراضي بصمت قبل وقت طويل من اكتمال استدعاء مركب.

انتشار الخطأ

تعيد برامج Raydium أخطاء Anchor مع رموز خطأ مستقرة. يرى برنامجك الاستدعاء لها كـ Err(ProgramError::Custom(code)). فقاعة من خلال بشكل افتراضي:
أو اعترض لرموز محددة:
لاحظ الحد ERROR_CODE_OFFSET: تُصدَر متغيرات #[error_code] بدءاً من 6000، لذا فإن المقارنة مع مميِّز التعداد المجرد لا تتطابق أبداً. (لا يوجد مساعد is_err في anchor-lang ولا في raydium_cp_swap — استخدمت مراجعات سابقة لهذه الصفحة مساعداً غير موجود.) تعيين رمز الخطأ إلى المعنى مستقر لكل سياسة IDL (sdk-api/anchor-idl)؛ الرموز الجديدة تُلحق في النهاية، الرموز الموجودة لا تغير المعنى أبداً.

مثال عملي كامل: escrow أوامر الحد

التدفق:
  1. open_order — يودع المستخدم amount_in من input_mint في escrow PDA؛ سجل min_amount_out والانتهاء المستهدف.
  2. execute_order — أي شخص (حارس) يستدعي مع حسابات المجموعة الحالية. يتحقق البرنامج من أن الاقتباس الحالي ≥ min_amount_out، ثم يقوم بـ CPI مبادلة Raydium ويحتفظ بالإخراج في escrow.
  3. claim — يسحب المستخدم mint الإخراج من escrow.
يدفع الحارس رسم المعاملة (يحصل على رسم حارس في مكان آخر — غير مبين). يوقّع order PDA على CPI بصفته payer، لأنه يملك ATA الإدخال الخاص بالـ escrow؛ لذا يحتاج ExecuteOrder أيضاً إلى حقل pool_authority: UncheckedAccount<'info> من أجل PDA خزانة CPMM الخاصة. كل من فحص الانزلاق من جانب Raydium و فحص دلتا escrow الخاص به يفرضان الحد الأدنى — حزام وحمالات.

الاختبار

سحب برامج Raydium إلى محقق محلي لاختبارات التكامل (من Anchor.toml):
استنسخ حسابات حالة المجموعة أيضاً بحيث يمكن لاختباراتك فعلاً تنفيذ المبادلات؛ anchor test يجلبها من mainnet عند بدء التشغيل. انظر sdk-api/rust-cpi.

الأخطاء المحددة للتكوين

إعادة الدخول

Solana ليس لديها إعادة دخول حقيقية — لا يمكن لـ CPI استدعاء البرنامج الأصلي مرة أخرى في نفس الاستدعاء. لكن يمكنك بناء نفسك في إعادة دخول منطقية: CPI يقرأ حالتك، ثم يقرأ الكود الخاص بك مرة أخرى بافتراض أن CPI لم يغيره. بالنسبة إلى Raydium، لا تلمس CPIs حالتك، لذا هذا أقل قلقاً من على سبيل المثال سياقات القروض الفورية. لكن إذا ركبت Raydium مع بروتوكول الإقراض، كن على علم.

انجراف قابلية الحساب

إذا مرر برنامجك حساباً كـ mut لكن Raydium يتوقع قراءة فقط (أو العكس)، يرفض وقت التشغيل الاستدعاء مع InvalidAccountData. تحقق دائماً من قابلية التغيير المتوقعة لتعليمة Raydium في IDL؛ تضبط raydium_cp_swap::cpi::accounts::Swap قابلية تغيير كل حساب من أجلك، انطلاقاً من علامات #[account(mut)] على بنية Swap الخاصة بـ CPMM — الحقول المولّدة كلها من نوع AccountInfo<'info> البسيط، لذا فإن تنفيذ ToAccountMetas المشتق، وليس أنواع الحقول، هو ما يحمل الأعلام.

حقل برنامج Token-2022

قد تكون رموز الإدخال والإخراج تحت برامج رموز مختلفة — واحد SPL Token، واحد Token-2022. يحتوي CPI على حقول input_token_program و output_token_program منفصلة لهذا السبب. تحقق دائماً من حقل owner لكل mint وأرسل البرنامج الصحيح إلى كل فتحة.

معاملات مصدرة

معاملة مركبة تقوم بـ 2+ Raydium CPIs بالإضافة إلى إنشاء ATA نادراً ما تناسب معاملة قديمة (v0-without-LUT). استخدم V0 مع جداول البحث عن العناوين؛ اسحب LUTs العام من Raydium عبر raydium.getRaydiumLutAddresses().

المؤشرات

المصادر: