هذه الصفحة مُترجَمة آليًا بواسطة الذكاء الاصطناعي. النسخة الإنجليزية هي المرجع المعتمد.عرض النسخة الإنجليزية →
تشريح المعاملة
لمعاملة Solana ثلاثة مكوّنات أساسية:- الرسالة (Message): القائمة المرتّبة للتعليمات والحسابات التي تشير إليها، و blockhash الحديث.
- التوقيعات (Signatures): واحد لكل موقّع، يثبت أن المعاملة مُرخّصة.
- blockhash الحديث: يثبت أن المعاملة حديثة؛ المعاملات ذات blockhashes القديمة (أقدم من 150 فتحة) مرفوضة.
التعليمات
تحدّد التعليمة:program_id— البرنامج المراد استدعاؤه.accounts— الحسابات (وأعلامها القابلة للكتابة/الموقّع) التي قد يلمسها البرنامج.data— بايتات معتّمة يفسّرها البرنامج.
ComputeBudget::SetComputeUnitLimit— رفع حد CU الافتراضي.ComputeBudget::SetComputeUnitPrice— تعيين رسم الأولوية.CreateAssociatedTokenAccountاختياري — إنشاء ATA الإخراج إذا لم يكن لدى المستخدم واحد.Raydium::SwapBaseInput— تنفيذ المبادلة.CloseAccountاختياري — إغلاق wrapped-SOL ATA.
raydium.trade.swap().
الحسابات في المعاملات
يجب إدراج كل حساب يمسّه أي تعليمة في المعاملة في مفاتيح حساب المعاملة. كل حساب مُعلَّم:- موقّع / غير موقّع: هل يجب على صاحب الحساب توقيع المعاملة؟
- قابل للكتابة / للقراءة فقط: هل يمكن للمعاملة تعديل الحساب؟
solana-fundamentals/account-model). مبادلات CLMM ذات عمليات عبور tick array متعددة قد تحتوي على 20+.
حد حجم المعاملة
Solana تحد المعاملات عند 1232 بايت بما في ذلك التوقيعات والرسالة والرؤوس. هذا هو أكثر عائق شائع للمعاملات المعقدة — CLMM من Raydium مع التوجيه متعدد المسارات ينطلق بانتظام ضد هذا الحد. تفصيل مبادلة Raydium نموذجية بحجم ~1000 بايت:| المكون | الحجم |
|---|---|
| التوقيع | 64 B |
| عدد التوقيعات | 1 B |
| رأس الرسالة | 3 B |
| Blockhash | 32 B |
| مفاتيح الحسابات (13 × 32 B) | 416 B |
| التعليمات (4 × ~100-150 B) | 400–600 B |
| الإجمالي | ~900–1100 B |
جداول البحث عن العناوين (ALTs)
ALTs تسمح للمعاملة بالإشارة إلى الحسابات من خلال فهرس 1 بايت في جدول منشور بدلاً من مفتاح عام 32 بايت كامل. هذا يضغط المعاملة بشكل كبير:- معاملة تشير إلى 20 حساب مباشرة: ~640 B من المفاتيح العمومية.
- نفس المعاملة باستخدام ALTs: ~20 B من الفهارس + مراجع ALT.
ميزانية الحساب
لكل معاملة ميزانية وحدة الحساب (CU). تجاوزها ينهي التنفيذ ويفشل المعاملة.- الافتراضي: 200,000 CU لكل معاملة.
- الحد الأقصى: 1,400,000 CU لكل معاملة (مرفوع عبر
ComputeBudget::SetComputeUnitLimit). - سقف لكل كتلة: 48M CU لكل كتلة (مستوى البروتوكول).
integration-guides/priority-fee-tuning للجدول الكامل):
| التعليمة | CU |
|---|---|
| مبادلة CPMM | ~140,000 |
| مبادلة CLMM (بدون عمليات عبور tick) | ~170,000 |
| مبادلة CLMM (4 عمليات عبور tick) | ~320,000 |
| Farm v6 stake | ~130,000 |
| إنشاء pool CPMM | ~250,000 |
ComputeBudget؛ وإلاّ ستحصل على الافتراضي 200k، وهو منخفض جدًا لمعظم تعليمات Raydium.
رسوم الأولوية
بما يتجاوز رسم المعاملة الأساسي (5000 lamports لكل توقيع)، يولي الموثقون بشكل متزايد الأولوية للمعاملات التي تدفع رسوم أولوية: نصيحة لكل CU بالمايكروlamports.integration-guides/priority-fee-tuning لكيفية تحديد حجم هذا ديناميكيًا.
حدود عدد التعليمات وعدد الحسابات
وراء حد 1232 بايت الكلي:- حد أقصى من الحسابات لكل معاملة: 128.
- حد أقصى من الحسابات لكل تعليمة (CPI): 64.
- حد أقصى من التعليمات لكل معاملة: لا يوجد حد صارم، محصور فقط بحد الحجم.
- حد أقصى من عمق CPI: 4 (برنامج قد يستدعي آخر، الذي قد يستدعي آخر، 4 مستويات عميقة).
فئات الرسوم في مبادلة Raydium
معاملة مستخدم تدفع رسوم في فئتين:رسوم شبكة Solana
المدفوعة للموثقين بـ SOL.- رسم التوقيع الأساسي: 5000 lamports لكل توقيع. تقريبًا دائمًا 1 توقيع = 0.000005 SOL.
- رسم الأولوية: CU-price × CU-limit بالمايكروlamports. يتغيّر مع الاختناق؛ انظر
integration-guides/priority-fee-tuning.
رسوم بروتوكول Raydium
مخصومة من مبلغ المبادلة.- رسم المبادلة: نسبة مئوية من المدخل (CPMM 0.25% نموذجي، CLMM 0.01%–1% لكل طبقة). مقسمة بين LPs والوجهات البروتوكول. انظر
ray/protocol-fees.
مثال: $1000 USDC → SOL عبر CPMM 0.25% tier
| فئة الرسم | المبلغ | يذهب إلى |
|---|---|---|
| رسم التوقيع الأساسي | 0.000005 SOL (~$0.0007) | الموثق |
| رسم الأولوية (10k µL × 300k CU) | 0.003 SOL (~$0.45) | الموثق |
| رسم مبادلة CPMM (0.25%) | $2.50 | LPs + protocol |
| التكلفة الإجمالية للمستخدم | ~$2.95 |
المعاملات المُصدّرة
Solana لديها صيغتا معاملة:- Legacy: الصيغة الأصلية، بدون دعم ALT.
- v0 (المُصدّرة): تدعم ALTs، قابلة للتوسع للإصدارات المستقبلية.
حداثة Blockhash
يجب أن تتضمن معاملة blockhash من ضمن آخر ~150 فتحة (~60 ثانية). بعد تلك النافذة، الموثقون يرفضونها. لحلقات إعادة المحاولة، احصل على blockhash جديد في كل محاولة:integration-guides/priority-fee-tuning لنمط إعادة المحاولة الكامل مع تصعيد الرسوم.
التنفيذ المتوازي
Solana تنفذ معاملات غير متضاربة بشكل متوازي على موثقي متعدد الأنوية. معاملتان تتضارب إذا كتابتا نفس الحساب. الآثار على Raydium:- مبادلتان على نفس pool لا يمكن أن تنفذا بالتوازي — كلاهما يكتب حالة pool.
- مبادلة على Pool A ومبادلة على Pool B تنفذان بالتوازي إذا لم تتداخل قوائم الحسابات.
- معاملة للقراءة فقط لا تحجز كاتبًا على نفس الحساب (القراءة فقط متزامنة مع نفسها لكن ليس مع الكتابات).
مستويات تأكيد المعاملات
عند إرسال معاملة تختار مستوى التأكيد:| المستوى | الانتظار | الشمولية |
|---|---|---|
processed | ~400 ms | غير نهائي؛ قد يتراجع |
confirmed | ~1 s | صوتت الأغلبية العظمى |
finalized | ~13 s | أرسخت الأغلبية العظمى |
confirmed معياري. للعمليات التي تتعامل مع قيمة كبيرة (إنشاء pool، تعبئة المكافآت)، finalized أأمن.
المحاكاة
Solana تدعم محاكاة معاملة قبل الإرسال:getBestSwapInfo للتحقق من أن المسار المختار ينجح فعلاً. المحاكاة ليست مجانية — تستهلك سعة RPC — لكنها تلتقط الأخطاء قبل الدفع مقابلها.
مؤشرات
solana-fundamentals/account-model— الحسابات في المعاملات.solana-fundamentals/pdas-and-cpis— كيف تستدعي البرامج بعضها.integration-guides/priority-fee-tuning— تحديد حجم حدود CU ورسوم الأولوية.ray/protocol-fees— هيكل رسوم بروتوكول Raydium.

