لماذا تفشل معاملات Solana: 5 إصلاحات

يركز هذا الدليل العملي على خمسة إصلاحات عملية لمعاملات Solana الفاشلة والخطوات التي قد تمنع تكرار الفشل.

تفشل معاملات Solana لخمسة أسباب:

1. انتهت صلاحية Blockhash قبل أن تؤكد الشبكة المعاملة
2. كانت رسوم الأولوية منخفضة جداً بالنسبة لطلب الشبكة الحالي
3. تم خرق تحمل الانزلاق السعري في عملية تبديل تمويل لامركزي
4. نفدت ميزانية وحدة الحوسبة في منتصف التنفيذ
5. كانت عقدة RPC التي تربط محفظتك بالشبكة محملة بشكل زائد

✅ أموالك في أمان

معاملة Solana الفاشلة لا تخصم الرموز من محفظتك. يظل الرصيد من SOL والرموز الخاصة بك كما هو تماماً. على الأكثر، قد تفقد رسوم شبكة أساسية صغيرة، عادة ما تكون أقل من 0.001 دولار. لم يتم خصم مبلغ التبديل أو مبلغ التحويل أو سعر صك NFT.

في هذه الصفحة:

• لماذا تفشل معاملات Solana: ماذا يحدث
• الأسباب الجذرية الـ 5 لفشل معاملات Solana
• فك تشفير رسائل خطأ Solana
• كيفية إصلاح معاملة Solana فاشلة
• إخفاقات خاصة بالمنصات
• هل Solana متوقفة؟ كيفية التحقق من حالة الشبكة
• هل لا تزال تدفع رسوماً مقابل المعاملات الفاشلة؟
• قائمة التحقق قبل المعاملة
• الأسئلة الشائعة
• ملخص: طابق خطأك مع الإصلاح الصحيح

لماذا تفشل معاملات Solana: ماذا يحدث

إن مشاهدة معاملة Solana تفشل بينما تتكشف حركة السعر أمر محبط، خاصة عندما لا تخبرك رسالة الخطأ بأي شيء مفيد. إذا فشلت عملية التبديل أو الصك أو التحويل الخاصة بك على Jupiter أو Raydium أو Orca أو Magic Eden، فإن السبب دائماً ما يكون واحداً من خمسة أشياء، ولكل منها إصلاح محدد.

عبر منظومة التمويل اللامركزي (DeFi) في Solana، بما في ذلك تبديل الرموز وتوفير السيولة وبروتوكولات الإقراض وصك الرموز غير القابلة للاستبدال (NFTs)، فإن فشل المعاملات يحمل عواقب مالية حقيقية لأن الأسعار تتحرك في أجزاء من الثانية. إن بنية Solana تجعلها أسرع وأرخص من معظم سلاسل الكتل، ولكنها تخلق أيضاً أنماط فشل لن يتوقعها المستخدمون المعتادون على Ethereum أو سلاسل أخرى. وعلى عكس الشبكات التي تنتظر فيها المعاملات البطيئة في طابور، تستخدم Solana بروتوكول إعادة توجيه معاملات يسمى Gulf Stream، والذي يسقط المعاملات التي لا يمكنه معالجتها على الفور. لا يوجد طابور. تتطلب المعاملات الفاشلة إعادة إرسال نشطة بالإعدادات الصحيحة.

يغطي هذا الدليل الإخفاقات عبر محفظة العملات الرقمية الخاصة بك (مثل Phantom أو Backpack)، وJupiter، وRaydium، وOrca، وMagic Eden. إذا كنت تشك في أن Solana نفسها تواجه مشكلات اليوم، فانتقل إلى قسم حالة الشبكة قبل استكشاف إعداداتك وإصلاحها.

الأسباب الجذرية الـ 5 لفشل معاملات Solana

تنقسم إخفاقات معاملات Solana إلى فئتين: إخفاقات على مستوى الشبكة (انتهاء صلاحية blockhash، الازدحام، عقد RPC المحملة بشكل زائد) وعمليات رفض على مستوى البرنامج من العقد ذكي، أو البرنامج، الذي يشغل التطبيق الذي تستخدمه. أخطاء تحمل الانزلاق السعري وأخطاء ميزانية الحوسبة هي عمليات رفض على مستوى البرنامج؛ أما انتهاء صلاحية blockhash ورسوم الأولوية غير الكافية فهي على مستوى الشبكة. يعتمد الإصلاح على النوع الذي تواجهه.

تستخدم Solana نظام ضبط وقت يسمى إثبات التاريخ (Proof of History)، والذي يولد تسلسلاً تشفيرياً يستخدمه المصدقون للاتفاق على الوقت دون إرسال طوابع زمنية لبعضهم البعض. تنتج كل خانة في هذا التسلسل blockhash، وهو رمز يشبه الطابع الزمني مدمج في كل معاملة لإثبات أن المعاملة حديثة. تخلق هذه البنية القائمة على الخانات نوافذ انتهاء صلاحية فريدة لـ Solana وهي ما يميز أنماط فشلها عن سلاسل الكتل الأخرى.

السبب 1: انتهاء صلاحية Blockhash

تحمل كل معاملة Solana رمز blockhash، والذي يثبت أن المعاملة تم إنشاؤها مؤخراً. إذا انتهت صلاحية هذا الـ blockhash قبل أن تؤكد الشبكة المعاملة، فإن Solana تسقطها تماماً.

كل blockhash صالح لحوالي 150 خانة زمنية، وهو ما يعادل تقريباً 60 إلى 90 ثانية في الظروف العادية. أثناء ازدحام الشبكة، يتأخر المصدقون في المعالجة، مما يعني أن المعاملات تنتهي صلاحيتها بشكل أسرع من الناحية النسبية. رسائل الخطأ التي ستراها هي Blockhash not found أو Transaction expired.

تستخدم Solana نظام Gulf Stream بدلاً من طابور المعاملات التقليدي، مما يعني أن المعاملة التي تم إسقاطها لا تعود إلى الطابور وتنتظر. بل تختفي. يجب عليك إعادة الإرسال بنشاط عن طريق بدء المعاملة مرة أخرى من محفظتك أو واجهة التمويل اللامركزي. تجلب المحفظة تلقائياً blockhash جديداً عند الإرسال الجديد. للحصول على إجراء إعادة الإرسال، راجع الإصلاح 3: إعادة الإرسال باستخدام Blockhash جديد.

⚠️ ملاحظة للمطورين

قم دائماً بجلب blockhash جديد باستخدام connection.getLatestBlockhash('confirmed') في كل محاولة إعادة تجربة. لا تقم أبداً بإعادة استخدام blockhash عبر محاولات إعادة التجربة. استخدم مستويات التزام confirmed أو finalized في بيئات الإنتاج، وليس processed لتجنب الحالة القديمة. اكتشف ما إذا كان قد تم إسقاط المعاملة أو معالجتها عن طريق استدعاء getSignatureStatuses قبل كل إعادة تجربة.

السبب 2: رسوم الأولوية منخفضة جداً

أثناء ازدحام الشبكة، يختار مصدقو Solana، وهي أجهزة الكمبيوتر التي تعالج معاملاتك، المعاملات التي سيتم التعامل معها أولاً بناءً على مستويات رسوم الأولوية.

تُعد رسوم الأولوية إكرامية اختيارية تُدفع للمصدقين، وتُقاس بـ micro-lamports لكل وحدة حوسبة. واحد lamport يساوي 0.000000001 SOL؛ وواحد micro-lamport هو جزء من مليون من الـ lamport. خلال فترات حركة المرور العالية مثل إطلاق NFT الشهيرة أو تحركات السوق الحادة، يعالج المصدقون المعاملات ذات رسوم الأولوية الأعلى أولاً. يتم إسقاط المعاملات ذات رسوم الأولوية الصفرية أو غير الكافية بدلاً من وضعها في طابور الانتظار.

سبب ذو صلة بأخطاء عدم كفاية SOL: تتطلب Solana من كل حساب الحفاظ على حد أدنى من الرصيد يسمى حد الإعفاء من الإيجار للبقاء نشطاً على الشبكة. إذا انخفض رصيد محفظتك عن هذا الحد بعد دفع الرسوم، أو إذا كانت المعاملة ستنشئ حساب رمز مميز جديداً بدون ما يكفي من SOL لتمويله، فسترى خطأ Insufficient funds حتى عندما يبدو أن لديك ما يكفي من SOL للتداول نفسه. احتفظ بهامش قدره 0.05 SOL فوق مبلغ معاملتك.

هذا هو السبب في أن إعادة إرسال نفس المعاملة دون تغيير الإعدادات غالباً ما يفشل مرة أخرى. للحصول على إرشادات حول تحديد مستوى الرسوم الصحيح، راجع الإصلاح 1: زيادة رسوم الأولوية الخاصة بك.

⚠️ ملاحظة للمطورين

أضف ComputeBudgetProgram.setComputeUnitPrice(microLamports) كأول تعليمات في معاملتك. استعلم عن getRecentPrioritizationFees() للتقدير الديناميكي بدلاً من استخدام مضاعف ثابت. تتغير مستويات الرسوم مع طلب الشبكة، لذا تصبح القيم الثابتة غير موثوقة أثناء طفرات الازدحام. اكتشف محفزات تجاوز الفشل من خلال مراقبة أخطاء HTTP 429 (حد المعدل)، و503 (الخدمة غير متوفرة)، وأخطاء مهلة الاتصال.

السبب 3: تجاوز ميزانية الحوسبة

كل معاملة Solana تعمل على ميزانية معالجة تسمى وحدات الحوسبة، والتي تقيس مقدار العمل الحسابي الذي تتطلبه المعاملة. تستهلك التحويلات البسيطة القليل جداً من هذه الميزانية. أما العمليات المعقدة، مثل تبديل التمويل اللامركزي متعدد الخطوات الذي يمر عبر ثلاثة أو أربعة مجمعات سيولة، فتستهلك أكثر بكثير.

إذا نفدت ميزانية وحدات الحوسبة الخاصة بمعاملتك قبل انتهائها، فإن سولانا تلغيها. الأخطاء التي ستراها هي تجاوزت ميزانية الحوسبة أو فشل البرنامج في الإكمال.

قبل إرسال معاملتك، تجري Phantom والمحافظ الأخرى فحصًا مبدئيًا يسمى محاكاة المعاملة، والذي ينفذ المعاملة مقابل حالة البلوكتشين الحالية دون إرسالها فعليًا. إذا اكتشفت المحاكاة أنه سيتم استنفاد وحدات الحوسبة، فإنها تمنع المعاملة وتعرض فشلت محاكاة المعاملة. تشير معظم حالات فشل المحاكاة إلى مشكلة حقيقية في المعاملة، على الرغم من أن بيانات الحالة القديمة قد تسبب أحيانًا فشلاً خاطئًا لمعاملة كانت ستنجح بخلاف ذلك.

بالنسبة لمعظم المستخدمين على واجهات DEX الحديثة، يتم تعيين حدود وحدات الحوسبة تلقائيًا. إذا رأيت خطأ في ميزانية الحوسبة، فاستخدم زر إعادة المحاولة المدمج في DEX قبل محاولة إجراء تعديلات يدوية. للحصول على خطوات مفصلة، راجع الإصلاح 5: ضبط ميزانية وحدات الحوسبة.

⚠️ ملاحظة للمطورين

أضف ComputeBudgetProgram.setComputeUnitLimit(units) كأول تعليمات في المعاملة. قم بتشغيل simulateTransaction() أولاً لقياس استهلاك وحدات الحوسبة الفعلي، ثم اضبط الحد على الاستهلاك الفعلي مضروبًا في 1.1 كعامل تآكل بنسبة 10%. يؤدي تعيين الحد المنخفض جدًا إلى فشل InstructionError؛ ويؤدي تعيينه المرتفع جدًا إلى إهدار ميزانية الرسوم ولكنه لا يسبب فشلاً.

السبب 4: تجاوزت حدود الانزلاق السعري

حدود الانزلاق السعري هي حماية تضعها المنصات اللامركزية الخاصة بك (DEX، وهي منصة يمكنك فيها استبدال العملات مباشرة من محفظتك) نيابة عنك. إذا تحرك سعر عملة ما بما يتجاوز الحد الذي حددته بين لحظة طلبك للاستبدال ولحظة تنفيذه، فإن العقد الذكي يلغي المعاملة لحمايتك من سعر أسوأ من المتوقع.

هذا فشل وقائي، وليس خسارة. رأس مالك آمن؛ لم يتم تنفيذ عملية الاستبدال. الخطأ الذي ستراه هو تجاوزت حدود الانزلاق السعري.

تحدث حالات فشل الانزلاق السعري في معظم الأحيان مع العملات المتقلبة، وأزواج التداول ذات السيولة المنخفضة، وخلال فترات الازدحام الشديد عندما يكون هناك تأخير أطول بين عرض السعر وتنفيذه. إذا كانت مجموعة السيولة تحتوي على احتياطيات منخفضة جدًا، فقد لا يكون حد الانزلاق السعري بنسبة 5% كافياً لأن المجموعة لا تستطيع استيعاب حجم تداولك بأي سعر معقول. في هذه الحالة، حاول تقليل مبلغ الاستبدال الخاص بك أو التبديل إلى زوج تداول مختلف.

Jupiter و Raydium و Orca هي المنصات اللامركزية التي يُصادف فيها هذا الفشل بشكل شائع. للحصول على تعليمات مفصلة للضبط، راجع الإصلاح 2: ضبط حدود الانزلاق السعري.

السبب 5: عقدة RPC مثقلة بالأعباء

تتصل محفظة Solana الخاصة بك بخادم يسمى عقدة RPC لإرسال المعاملات. فكر في الأمر على أنه مكتب البريد الذي يمرر معاملتك إلى شبكة المدققين. في كل مرة تنقر فيها على تأكيد في Phantom أو Backpack، ترسل المحفظة معاملتك إلى عقدة RPC، التي تقوم بإعادة توجيهها إلى المدققين.

نقطة نهاية RPC العامة المجانية الخاصة بـ Solana محدودة المعدل وغالبًا ما تكون مثقلة بالأعباء خلال فترات الطلب المرتفع. خلال إطلاق NFT شهير أو حركة سوق حادة، تتلقى عقد RPC العامة عددًا أكبر بكثير من الإرسالات التي يمكنها معالجتها، وتقوم بإسقاط المعاملات قبل وصول تلك المعاملات إلى المدققين. عندما يحدث هذا، قد ترى فشل تأكيد المعاملة أو تواجه فشلاً صامتًا بدون رسالة خطأ على الإطلاق.

التبديل إلى مزود RPC مخصص، مثل Helius أو QuickNode، وكلاهما يقدم مستويات مجانية، يمنح معاملاتك مسارًا أكثر موثوقية إلى الشبكة. للحصول على خطوات للتبديل إلى RPC الخاص بك، راجع الإصلاح 4: التبديل إلى نقطة نهاية RPC أفضل.

⚠️ ملاحظة للمطورين

احتفظ بقائمة بعقد RPC احتياطية في تكوين التطبيق الخاص بك. قم بتطبيق منطق الفشل التلقائي عند إرجاع نقطة النهاية الأساسية أخطاء أو انتهاء مهلتها. استخدم WebSocket signatureSubscribe لمراقبة تأكيد المعاملة بدلاً من الاستقصاء عبر HTTP باستخدام getSignatureStatuses، حيث أن اشتراكات WebSocket أسرع وأكثر موثوقية تحت الحمل.

فك رموز رسائل خطأ Solana: ما يعنيه كل منها

تظهر رسائل الخطأ من معاملات Solana الفاشلة في سجل نشاط محفظتك (Phantom أو Solflare)، أو على Solana Explorer (explorer.solana.com)، أو على Solana FM (solana.fm). للبحث عن معاملة فاشلة محددة، انسخ توقيع المعاملة من سجل المعاملات الخاص بمحفظتك والصقه في أي مستكشف. تظهر المعاملة الفاشلة حالة خطأ حمراء مع رمز الخطأ المحدد.

قبل إرسال أي معاملة، تجري Phantom محاكاة للتنبؤ بما إذا كانت ستنجح. إذا فشل هذا الفحص الأولي، تعرض Phantom فشلت محاكاة المعاملة وتمنع الإرسال. تشير معظم حالات فشل المحاكاة إلى مشكلة حقيقية في إعداداتك، ولكن البيانات القديمة تسبب أحيانًا فشلاً خاطئًا. في هذه الحالة، يعد تحديث الصفحة وإعادة الإرسال مرة واحدة أمرًا مناسبًا.

كيفية إصلاح معاملة Solana فاشلة

قائمة التحقق السريعة للإصلاح (ابدأ بالإصلاح 1 إذا لم تكن متأكدًا من أي إصلاح ينطبق):

1. قم بزيادة رسوم الأولوية الخاصة بك إلى سريع أو توربو وأعد الإرسال
2. قم بزيادة حدود الانزلاق السعري بنسبة 0.5% إلى 1% وأعد الإرسال
3. أعد الإرسال باستخدام بلوكهاش جديد (انتظر 5 ثوانٍ، ثم ابدأ من DEX مرة أخرى)
4. قم بالتبديل إلى نقطة نهاية RPC مخصصة في إعدادات محفظتك
5. تحقق من حالة شبكة Solana على status.solana.com قبل إعادة المحاولة إذا كنت تشك في وجود ازدحام

تتسبب رسوم الأولوية غير الكافية في غالبية المعاملات الفاشلة خلال فترات التداول النشطة، لذا فإن الإصلاح 1 هو نقطة البداية الصحيحة عندما تكون غير متأكد.

الإصلاح 1: زيادة رسوم الأولوية الخاصة بك

زيادة رسوم الأولوية الخاصة بك هي الحل الأكثر فعالية للمعاملات الفاشلة خلال فترات الازدحام. إنها تشير إلى المدققين لمعالجة معاملتك قبل الإرسالات ذات الرسوم الأقل.

تختلف مستويات الرسوم حسب طلب الشبكة. استخدم ميزة التقدير التلقائي لمحفظتك أو تحقق من Solana Beach لمعرفة ظروف الشبكة الحالية. لا تعتمد على قيم لامبورت محددة، لأنها تتغير بسرعة.

مرجع فئات رسوم الأولوية:

لزيادة رسوم الأولوية في Jupiter (قد تختلف الواجهة حسب الإصدار):

1. افتح Jupiter على jup.ag
2. انقر على أيقونة ترس الإعدادات في لوحة التبديل
3. حدد رسوم الأولوية
4. اختر سريع أو توربو، أو أدخل قيمة مخصصة
5. أعد إرسال التبديل الخاص بك

لزيادة رسوم الأولوية في Phantom:

1. افتح محفظة Phantom
2. انتقل إلى الإعدادات
3. حدد المعاملات
4. اضبط سرعة المعاملة على عالٍ أو مخصص
5. ارجع إلى DEX الخاص بك وأعد الإرسال

بالنسبة لـ Raydium، انقر على ترس الإعدادات في واجهة التبديل، وحدد رسوم الأولوية، واختر فئة أعلى، وأعد الإرسال. يعرض جدول فشل المنصَّة المحدد المسار الدقيق للتنقل لكل منصة.

⚠️ ملاحظة للمطور:> أضف ComputeBudgetProgram.setComputeUnitPrice(microLamports) كأول تعليمات في معاملتك. استدعِ getRecentPrioritizationFees() للحصول على نسب الرسوم الحالية للشبكة بدلاً من استخدام مضاعف ثابت. الإفراط في الدفع يهدر SOL ولكنه لا يسبب فشل المعاملات.

الإصلاح 2: اضبط تحمل الانزلاق السعري الخاص بك

إذا فشل التبديل الخاص بك بخطأ في تحمل الانزلاق السعري، فإن الحل هو توسيع نطاق السعر المقبول، ولكن حجم توسيعه مهم.

⚠️ تحذير هام>

ضبط الانزلاق السعري فوق 3% إلى 5% على أزواج الرموز ذات السيولة المنخفضة يعرضك لهجمات الساندويتش MEV، حيث تكتشف الروبوتات معاملتك المعلقة وتسبقها لاستخراج القيمة. قم بزيادة الانزلاق السعري بشكل تدريجي، وليس دفعة واحدة.

لضبط الانزلاق السعري في Jupiter (قد تختلف الواجهة حسب الإصدار):

1. افتح Jupiter وانقر على أيقونة ترس الإعدادات
2. حدد تحمل الانزلاق السعري
3. زد إعدادك الحالي بنسبة 0.5% إلى 1% (على سبيل المثال، من 0.5% إلى 1.5%)
4. أعد إرسال التبديل الخاص بك

بالنسبة لـ Raydium: انقر على ترس الإعدادات، وحدد الانزلاق السعري، وأدخل النسبة المئوية المعدلة، وأعد الإرسال. بالنسبة لـ Orca: انقر على الإعدادات، واضبط تحمل الانزلاق السعري، وأعد الإرسال. يعرض جدول فشل المنصَّة المحدد المسار الدقيق للتنقل لكل DEX.

إذا كنت تستخدم Jupiter، فتحقق مما إذا كانت ميزة الانزلاق السعري الديناميكي متاحة في واجهتك. هذه الميزة تحسب تلقائيًا الانزلاق السعري الأمثل لكل صفقة بناءً على ظروف السوق الحالية.

إذا استمر رمز مميز في الفشل حتى عند انزلاق سعري بنسبة 5%، فالمشكلة على الأرجح هي نقص السيولة في المجمع بدلاً من حركة السعر. حاول تقليل مبلغ التبديل الخاص بك أو تقسيم الصفقة إلى معاملات أصغر.

الإصلاح 3: أعد الإرسال باستخدام Blockhash جديد

يتم إصلاح انتهاء صلاحية Blockhash عن طريق إعادة الإرسال، ولكن لا يمكنك إعادة إرسال نفس كائن المعاملة. تتطلب Solana Blockhash جديدًا في كل إرسال.

نظرًا لأن Solana تستخدم Gulf Stream بدلاً من قائمة انتظار المعاملات التقليدية، فلا يمكن "فك تعليق" معاملة تم إسقاطها. المعاملة ذهبت. يجب إنشاء معاملة جديدة من الصفر.

للمستخدمين العاديين (Phantom، Jupiter، Raydium):

1. انتظر من 5 إلى 10 ثوانٍ بعد الفشل
2. لا تنقر على إرسال مرة أخرى على نفس شاشة التأكيد
3. ارجع إلى واجهة التبديل وابدأ المعاملة مرة أخرى من البداية
4. تقوم محفظتك تلقائيًا بجلب Blockhash جديد عند إعادة الإرسال

قبل إعادة الإرسال: تحقق من Solana Explorer (explorer.solana.com) للتأكد من أن المعاملة لم تنجح بالفعل. الصق توقيع معاملتك في شريط البحث. إذا ظهرت المعاملة على أنها مؤكدة، فلا تقم بإعادة الإرسال.

⚠️ ملاحظة للمطور:> احصل على Blockhash جديد باستخدام connection.getLatestBlockhash('confirmed') قبل كل محاولة إعادة محاولة. قم بتطبيق تراجع أسي: انتظر 1 ثانية قبل المحاولة الأولى، 2 ثانية قبل الثانية، 4 ثوانٍ قبل الثالثة. قم بتعيين عدد أقصى لمحاولات إعادة المحاولة يبلغ 5 محاولات قبل عرض خطأ للمستخدم. استخدم مستويات التزام 'confirmed' أو 'finalized'، وليس 'processed'، عند جلب Blockhashes في بيئات الإنتاج.

نقطة النهاية المجانية العامة لـ RPC الخاصة بـ Solana (api.mainnet-beta.solana.com) مقيدة بمعدل وغالبًا ما تكون محمّلة بشكل زائد خلال فترات الطلب المرتفع، مما يجعل المعاملات المرسلة أكثر عرضة للسقوط قبل وصولها إلى المدققين.

عادةً ما توفر مقدمو خدمات RPC المخصصون مثل Helius و QuickNode موثوقية أعلى من نقطة النهاية العامة لـ Solana mainnet أثناء الازدحام. يقدم كلا المزودين مستويات مجانية مناسبة للمستخدمين الأفراد.

للتبديل إلى RPC في Phantom (قد تختلف الواجهة حسب الإصدار):

1. افتح محفظة Phantom
2. انتقل إلى الإعدادات
3. حدد إعدادات المطور
4. اختر تغيير نقطة نهاية RPC
5. أدخل عنوان URL لنقطة النهاية الخاصة بـ Helius أو QuickNode
6. قم بتأكيد وإعادة إرسال معاملتك

للتبديل إلى RPC في Solflare:

1. افتح محفظة Solflare
2. انتقل إلى الإعدادات
3. حدد الشبكة
4. اختر RPC مخصص وأدخل عنوان URL لنقطة النهاية الخاصة بك
5. احفظ وأعد إرسال معاملتك

⚠️ ملاحظة للمطور:> احتفظ بقائمة بنقاط نهاية RPC احتياطية في تكوين تطبيقك. قم بتطبيق منطق فشل تلقائي بحيث يتحول تطبيقك إلى نقطة احتياطية عندما تعود النقطة الأساسية بأخطاء أو تنتهي مهلتها. استخدم WebSocket signatureSubscribe لمراقبة تأكيد المعاملة بدلاً من الاستقصاء باستخدام getSignatureStatuses، حيث أن اتصالات WebSocket أسرع تحت الحمل الثقيل.

بالنسبة للمستخدمين العاديين، تقوم معظم واجهات DEX الحديثة، بما في ذلك Jupiter و Raydium، بتعيين حدود وحدات الحوسبة تلقائيًا. إذا رأيت خطأ "Compute budget exceeded" (تجاوزت ميزانية الحوسبة)، فاستخدم وظيفة إعادة المحاولة أو التحديث المدمجة في DEX بدلاً من تعديل الإعدادات يدويًا.

إذا استمر الخطأ، فحاول تبسيط مسار التبديل الخاص بك. يستخدم المسار المباشر عبر مجمع واحد وحدات حوسبة أقل من المسار المعقد متعدد الخطوات عبر أربعة أو خمسة مجمعات. في Jupiter، ابحث عن خيار "Direct Route Only" (مسار مباشر فقط) في إعدادات التوجيه.

إذا فشل التبديل الخاص بك باستمرار على زوج معين، فقد يكون ذلك مسارًا ذا طلب مرتفع بشكل مؤقت. غالبًا ما يؤدي الانتظار لبضع دقائق وإعادة الإرسال إلى حل المشكلة دون أي تغييرات في الإعدادات.

⚠️ ملاحظة للمطور:> أضف ComputeBudgetProgram.setComputeUnitLimit(units) كأول تعليمات في المعاملة. قم بتشغيل simulateTransaction() أولاً لقياس استهلاك وحدات الحوسبة الفعلي، ثم اضبط الحد على الاستهلاك الفعلي مضروبًا في 1.1 كـ 10% هامش أمان. يؤدي تعيين الحد المنخفض جدًا إلى فشل InstructionError؛ يؤدي تعيينه مرتفعًا جدًا إلى إهدار ميزانية الرسوم دون التسبب في فشل.

فشل المنصَّة المحدد: Phantom، Jupiter، Raydium، و Magic Eden

تتطور سيناريوهات فشل Solana الأكثر شيوعًا بشكل مختلف اعتمادًا على المنصة التي تستخدمها. تحقق من جدول المقارنة أدناه للعثور على المنصة الخاصة بك، ثم اقرأ القسم الفرعي ذي الصلة للحصول على التفاصيل.

فشل التبادل في Jupiter

يرسل التوجيه متعدد القفزات في Jupiter عملية التبادل الخاصة بك عبر عدة أحواض سيولة للعثور على أفضل سعر. تزيد كل قفزة إضافية من استهلاك وحدة الحساب وتخلق نقطة أخرى حيث يمكن أن تؤدي حركة السعر إلى تجاوز تحمل الانزلاق السعري.

أكثر حالتي فشل خاصتين بـ Jupiter هما تجاوز تحمل الانزلاق السعري على أزواج الرموز المتقلبة، وفشل محاكاة المعاملة (Transaction simulation failed) بسبب رسوم أولوية غير كافية. يتم إصلاح كليهما عن طريق ضبط الإعدادات في قائمة أيقونة الترس في Jupiter قبل إعادة الإرسال.

يوفر محدد رسوم الأولوية المدمج في Jupiter خيارات عادي وسريع وتيربو ومخصص. خلال أي جلسة تداول نشطة، يكون الخيار "سريع" هو الحد الأدنى الموصى به للإعداد. أثناء إطلاق NFT أو تحرك حاد في السوق، استخدم خيار "تيربو".

بعض المحافظ القديمة لا تدعم تنسيق المعاملات المحددة الإصدار الخاص بـ Jupiter. إذا رأيت خطأ في تنسيق المعاملة بدلاً من خطأ في الانزلاق السعري أو الرسوم، فقم بالتأكد من أن برنامج محفظتك محدث.

فشل التبادل في Raydium وOrca

غالباً ما تأتي حالات فشل صانع السوق الآلي (AMM) في Raydium وOrca من تأثير السعر المرتفع على الأحواض ذات السيولة المحدودة. لا يمكن للحوض استيعاب حجم تداولك بسعر معقول، حتى مع إعدادات الانزلاق السعري السخية.

قبل تأكيد أي عملية تبادل على Raydium أو Orca، تحقق من نسبة تأثير السعر الموضحة في الواجهة. إذا تجاوز تأثير السعر 2% إلى 3%، فإن حجم التداول كبير جداً بالنسبة للسيولة المتاحة في ذلك الحوض. قلل مبلغ التبادل أو قسم المعاملة إلى عمليتي تبادل أو ثلاث عمليات أصغر يتم إرسالها بالتتابع.

بالنسبة لمراكز السيولة المركزة في Whirlpool التابعة لـ Orca، يمكن أن يكون الانزلاق السعري حساساً بشكل خاص. إذا تحرك حوض مركز خارج نطاق سعره النشط، فستفشل المعاملات بغض النظر عن إعداد الانزلاق السعري الخاص بك. في هذه الحالة، جرب حوضاً مختلفاً أو التوجيه عبر مجمّع Jupiter، الذي يجد تلقائياً مسارات بديلة.

فشل Magic Eden وسك رموز NFT

تختلف إخفاقات سك رموز NFT على Magic Eden عن إخفاقات DEX الروتينية لأن المشكلة ليست في إعداداتك. المشكلة هي الإرسال المتزامن لآلاف المعاملات خلال نافذة إطلاق ضيقة، مما يثقل كاهل الشبكة ويؤدي إلى قيام أدوات التحقق من الصحة بإسقاط المعاملات ذات رسوم الأولوية المنخفضة قبل معالجتها.

تؤدي عمليات السك عالية الطلب التي تستخدم برامج Candy Machine إلى منافسة شديدة. ترسل البوتات مئات المعاملات في الثانية، مما يؤدي إلى إشباع كل من RPC العام وزمام انتظار أدوات التحقق.

بروتوكول من ثلاث خطوات لسك ناجح خلال إطلاق عالي الطلب:

1. قبل فتح نافذة السك، اضبط رسوم الأولوية على "تيربو" أو أقصى إعداد متاح في محفظتك
2. انتقل من RPC العام لـ Solana إلى مزود مخصص مثل Helius أو QuickNode (الفئات المجانية كافية)
3. تأكد من تحميل صفحة السك بالكامل والموافقة المسبقة على اتصال محفظتك؛ أرسل المعاملة فور فتح السك، وليس بعد تحديث الصفحة

يتم إرجاع أصل عملات SOL الخاصة بك تلقائياً إذا فشلت معاملة السك. يتم استهلاك رسوم الشبكة الصغيرة فقط، والتي تبلغ حوالي 0.000005 SOL. تستخدم بعض المشاريع أيضاً آليات قائمة السماح وCandy Guards، لذا إذا فشلت المعاملات باستمرار حتى مع الإعدادات الصحيحة، فتأكد من أنك مؤهل لمرحلة السك الحالية.

هل Solana متوقفة؟ كيفية التحقق من حالة الشبكة

معظم إخفاقات معاملات Solana لا تنتج عن انقطاع الشبكة، بل تنتج عن إعدادات جانب المستخدم أو ازدحام الشبكة المؤقت. إن حالات الانقطاع الحقيقية، حيث تتوقف الشبكة تماماً، نادرة ويتم الإعلان عنها رسمياً.

فحص الحالة المكون من ثلاث خطوات:

1. انتقل إلى status.solana.com، صفحة حالة الشبكة الرسمية لـ Solana، وتحقق من وجود أي تقارير عن حوادث نشطة من مؤسسة Solana.
2. انتقل إلى Solana Beach وتحقق من رقم المعاملات في الثانية (TPS) في الوقت الفعلي ومتوسط وقت التأكيد. تشير معدلات الفشل المرتفعة خلال نشاط TPS إلى ازدحام الشبكة، وليس انقطاعها.
3. تحقق من r/solana أو Discord الخاص بـ Solana. إذا كان العديد من المستخدمين يبلغون عن حالات فشل في وقت واحد، فإن الشبكة تعاني من الازدحام. أما إذا كان القليل منهم فقط يفعل ذلك، فمن المرجح أن المشكلة من جانبك.

هل لا تزال تدفع رسوماً على معاملة Solana فاشلة؟

نعم، تفرض Solana رسوم معاملة أساسية صغيرة حتى عندما تفشل المعاملة، ولكن لا يتم خصم رموزك المميزة والمبلغ الأصلي للتبادل أو التحويل أو السك من محفظتك.

رموزك في أمان. فشلت المعاملة قبل تنفيذ أي عملية تبادل أو تحويل.

الرسوم الأساسية هي حوالي 0.000005 SOL لكل توقيع، وهو ما يعادل جزءاً بسيطاً من السنت في معظم مستويات أسعار SOL. تعوض هذه الرسوم أدوات التحقق من الصحة عن معالجة محاولة المعاملة حتى عندما لا تنجح. إذا قمت بتضمين رسوم أولوية، فسيتم استهلاك هذا المبلغ أيضاً. لم يتم خصم مبلغ الرمز المميز الذي كنت تحاول مبادلته، أو SOL الذي كنت تحاول إرساله، أو سعر NFT الذي كنت تحاول دفعه على الإطلاق.

لا تفرض أي رسوم على الإطلاق على المعاملة التي يتم إسقاطها بصمت بواسطة عقدة RPC مثقلة بالأعباء قبل أن تصل إلى أدوات التحقق من الصحة، وذلك لعدم وجود سجل لها داخل الكتلة.

للتحقق بدقة من مقدار الرسوم التي تم فرضها على أي معاملة فاشلة:

1. انسخ توقيع المعاملة من سجل معاملات محفظتك
2. الصقه في Solana Explorer أو Solana FM
3. حدد موقع المعاملة الفاشلة، والتي تظهر حالة خطأ باللون الأحمر
4. تحقق من حقل الرسوم لرؤية مبلغ SOL الدقيق الذي تم فرضه

قائمة التحقق قبل المعاملة: كيفية منع فشل معاملات Solana

يستغرق استعراض قائمة التحقق هذه قبل أي معاملة حساسة للوقت أقل من 60 ثانية ويقضي على الأسباب الأكثر شيوعاً للفشل.

1. تحقق من status.solana.com لمعرفة الحوادث النشطة قبل أي معاملة أثناء ظروف السوق المتقلبة
2. اضبط رسوم الأولوية الخاصة بك على خيار "سريع" على الأقل لأي معاملة خلال ساعات التداول النشطة؛ استخدم خيار "تيربو" للمداولات الحساسة للوقت أو عمليات سك رموز NFT
3. تحقق من أن تحمل الانزلاق السعري الخاص بك يتوافق مع تقلبات زوج الرموز المميزة: 0.5% للأزواج المستقرة مثل USDC/USDT، و1% إلى 2% للرموز متوسطة القيمة السوقية، وتصل إلى 3% للرموز الصغيرة المتقلبة
4. تأكد من أن الرصيد الخاص بك من عملة SOL يغطي مبلغ المعاملة بالإضافة إلى الرسوم بالإضافة إلى احتياطي قدره 0.05 SOL لعتبات الإعفاء من الإيجار
5. بالنسبة للمعاملات الحساسة للوقت أو عالية القيمة، انتقل من RPC العام الخاص بـ Solana إلى مزود مخصص مثل Helius أو QuickNode (كلاهما يقدم فئات مجانية)
6. لعمليات سك رموز NFT: قم بتهيئة رسوم الأولوية وRPC الخاص بك قبل فتح نافذة السك، وليس خلالها
7. لعمليات تبادل DEX الكبيرة: تحقق من نسبة تأثير السعر قبل التأكيد؛ إذا تجاوز تأثير السعر 2% إلى 3%، فقم بتقليل مبلغ التبادل أو قسمه إلى معاملات أصغر
8. ثق بأداة تحسين الرسوم المدمجة في DEX الخاصة بك عندما تكون متاحة؛ تقدم كل من Jupiter وRaydium وOrca توصيات تلقائية للرسوم تتكيف مع ظروف الشبكة الحالية

⚠️ ملاحظة للمطور

في التطبيقات اللامركزية (dApps) ببيئة الإنتاج، قم بتطبيق تقدير وحدات الحوسبة القائم على المحاكاة بدلاً من الحدود الثابتة. استعلم عن getRecentPrioritizationFees() بشكل ديناميكي وحدّث توصية الرسوم الخاصة بك عند كل عملية إرسال معاملة. قم بتنفيذ تجاوز الفشل لـ RPC بحيث ينتقل تطبيقك إلى نقطة نهاية احتياطية تلقائياً. لا تقم أبداً بإعادة استخدام علامات تجزئة الكتل (blockhashes) عبر محاولات إعادة المحاولة.

الأسئلة الشائعة: خمس إصلاحات لمعاملات سولانا الفاشلة

كل إجابة أدناه قائمة بذاتها. لست بحاجة لقراءة بقية هذا الدليل لاستخدام الأسئلة الشائعة.

ما الذي يسبب فشل معاملة سولانا؟

تفشل معاملات سولانا لخمسة أسباب: انتهاء صلاحية علامة تجزئة الكتلة (blockhash)، أو عدم كفاية رسوم الأولوية، أو استنفاد ميزانية وحدات الحوسبة، أو تجاوز حد تحمل الانزلاق السعري، أو زيادة الحمل على عقدة RPC. تتطلب الإخفاقات على مستوى الشبكة زيادة رسوم الأولوية وإعادة الإرسال. تتطلب عمليات الرفض على مستوى البرنامج تعديل معلمات المعاملة مثل حد تحمل الانزلاق السعري أو مبلغ المبادلة. راجع الأسباب الجذرية الخمسة للحصول على شرح كامل لكل منها.

نعم. تفرض سولانا رسوم معاملة أساسية صغيرة، تبلغ حوالي 0.000005 SOL، حتى عندما تفشل المعاملة، ولكن لا يتم خصم رموزك المميزة أو أصل المبادلة الخاص بك. المعاملات التي يتم إسقاطها بصمت بواسطة عقدة RPC محملة بشكل زائد قبل الوصول إلى الشبكة لا تفرض أي رسوم على الإطلاق، لأنها لا تترك أي سجل داخل الكتلة. راجع هل ما زلت تدفع الرسوم للحصول على تعليمات التحقق.

تنتهي صلاحية معاملة سولانا بعد حوالي 150 خانة (slot)، وهو ما يقارب 60 إلى 90 ثانية في ظروف الشبكة العادية. أثناء الازدحام، قد يبدو وقت انتهاء الصلاحية الفعلي أقصر لأن المدققين يتأخرون في المعالجة. بعد انتهاء الصلاحية، يتم إسقاط المعاملة نهائياً ويجب إعادة إرسالها من الصفر.

علامة تجزئة الكتلة (blockhash) هي رمز يشبه الطابع الزمني مضمن في كل معاملة سولانا يثبت أن المعاملة قد أُنشئت مؤخراً. يستخدمها المدققون للتحقق من أن المعاملة حديثة ولم يتم تكرارها من جلسة سابقة. تنتهي صلاحية علامات تجزئة الكتل بعد 150 خانة تقريباً؛ بعد ذلك، يتم رفض المعاملة مع خطأ Blockhash not found أو Transaction expired.

وحدات الحوسبة هي مقياس سولانا لموارد المعالجة التي تستهلكها المعاملة. تستخدم التحويلات البسيطة كمية صغيرة؛ بينما تستخدم مبادلات DEX المعقدة متعددة القفزات قدراً أكبر بكثير. إذا استنفدت معاملة ما ميزانية وحدات الحوسبة الخاصة بها قبل اكتمالها، تقوم سولانا بإلغائها وإرجاع الخطأ Compute budget exceeded. تقوم واجهات DEX الحديثة بتعيين حدود وحدات الحوسبة تلقائياً لمعظم المستخدمين.

رسوم الأولوية هي بقشيش اختياري يُدفع للمدققين بوحدة micro-lamports لكل وحدة حوسبة لتقديم معاملتك على عمليات الإرسال ذات الرسوم الأقل أثناء الازدحام. الرسوم الأساسية للمعاملة في سولانا ثابتة وصغيرة؛ رسوم الأولوية هي المكون المتغير الذي يحدد مدى سرعة معالجة معاملتك. تختلف مستويات الرسوم حسب الطلب على الشبكة، لذا استخدم ميزة التقدير التلقائي لمحفظتك أو واجهة برمجة تطبيقات رسوم الأولوية من Helius للقيم الحالية.

قم بنسخ توقيع المعاملة من سجل معاملات محفظتك والصقه في Solana Explorer أو Solana FM. تظهر المعاملات الفاشلة بحالة خطأ حمراء مع رمز الخطأ المحدد. تظهر المعاملات المؤكدة بحالة نجاح خضراء. تحقق دائماً قبل إعادة الإرسال لتجنب إرسال معاملة مكررة.

لا تحتاج أموالك إلى استرداد لأنها لم تُرسل أصلاً. معاملة سولانا الفاشلة لا تخصم رموزك المميزة أو مبلغ المبادلة من محفظتك. لقد فشلت المعاملة قبل التنفيذ، لذا فإن الرصيد في محفظتك لم يتغير باستثناء الرسوم الأساسية الصغيرة. أصل أموالك في أمان.

تستخدم سولانا بروتوكول توجيه معاملات يسمى Gulf Stream بدلاً من طابور المعاملات التقليدي. يقوم Gulf Stream بتوجيه المعاملات مباشرة إلى المدقق التالي المتوقع قبل انتهاء الكتلة الحالية. المعاملات التي لا يمكن معالجتها فوراً يتم إسقاطها بدلاً من الاحتفاظ بها في طابور انتظار. يتيح هذا التصميم إنتاجية سولانا العالية ولكن هذا يعني أن المعاملات الفاشلة تتطلب إعادة إرسال نشطة بدلاً من الانتظار السلبي.

فشل محاكاة المعاملة (Transaction simulation failed) يعني أن Phantom قد أجرت اختباراً مسبقاً على معاملتك وتوقعت أنها لن تنجح. تمنع Phantom الإرسال لمنعك من إهدار رسوم على معاملة ستفشل. تشير معظم إخفاقات المحاكاة إلى مشكلة حقيقية في إعداداتك، مثل عدم كفاية الانزلاق السعري، أو انخفاض رصيد SOL، أو رفض البرنامج. في بعض الأحيان، تسبب بيانات الحالة القديمة فشلاً كاذباً؛ وفي هذه الحالة يكون تحديث الصفحة وإعادة الإرسال مرة واحدة أمراً مناسباً.

أضف SOL إلى محفظتك وتأكد من أن الرصيد يتجاوز مبلغ المعاملة بالإضافة إلى الرسوم بالإضافة إلى احتياطي قدره 0.05 SOL. لا يعني خطأ نقص الأموال في سولانا دائماً أنك تفتقر إلى SOL للرسوم وحدها. في بعض الأحيان يعني ذلك أنك تفتقر إلى ما يكفي من SOL لتغطية حد الإعفاء من الإيجار المطلوب لإنشاء حساب رمز مميز جديد عند استلام رمز مميز لأول مرة.

أصل أموالك في أمان. الرموز المميزة أو عملات SOL التي كنت تحاول إرسالها أو مبادلتها تظل في محفظتك تماماً كما كانت. معاملة سولانا الفاشلة لا تنفذ التحويل أو المبادلة أو السك، لذا فإن الرصيد لم يتغير. قد يكون قد تم خصم رسوم معاملة أساسية صغيرة فقط، وعادة ما تكون أقل من 0.001 دولار.

تشير المعاملات التي تفشل بشكل متكرر عادةً إلى إعادة إرسال نفس الإعداد غير الصحيح دون تعديل. حدد خطأك: إذا كان Slippage tolerance exceeded (تجاوز حد تحمل الانزلاق السعري)، فقم بزيادة حد تحمل الانزلاق السعري وأعد الإرسال. إذا كانت المعاملات تسقط بصمت دون رسالة خطأ، فإن رسوم الأولوية الخاصة بك منخفضة جداً. إذا أظهرت صفحة status.solana.com حادثة نشطة، فانتظر حتى تتعافى الشبكة قبل إعادة الإرسال.

تحدث إخفاقات سك رموز NFT لأن آلاف المستخدمين والروبوتات يرسلون المعاملات في وقت واحد خلال نافذة إطلاق ضيقة، مما يؤدي إلى إشباع كل من نقاط نهاية RPC العامة وطابور المدققين. يقوم المدققون بإسقاط المعاملات ذات رسوم الأولوية المنخفضة لإدارة الحمل. إن ضبط رسوم الأولوية على وضع "Turbo" والتبديل إلى مزود RPC مخصص قبل فتح نافذة السك يحسن معدلات النجاح بشكل كبير. راجع Magic Eden وإخفاقات سك رموز NFT لبروتوكول التحضير الكامل.

تحمل الانزلاق السعري هو أقصى حركة سعر تقبلها بين وقت طلب المبادلة ووقت تنفيذها. إذا تحرك سعر الرمز المميز خارج هذا الحد، يقوم العقد الذكي بإلغاء المبادلة تلقائياً لحمايتك من الحصول على سعر أسوأ بكثير مما هو معروض. تتراوح الإعدادات النموذجية من 0.5% لأزواج الرموز المستقرة إلى 2% أو 3% للأصول المتقلبة. يؤدي ضبطه فوق 3% إلى 5% على الأزواج ذات السيولة المنخفضة إلى زيادة التعرض لهجمات MEV sandwich.

استكشف SOL على Bybit

استخدم صفحة سعر سولانا) لمراجعة بيانات سوق SOL الحالية، أو الوصول إلى سوق التداول الفوري SOL/USDT) إذا كان التداوُل الفوري يتناسب مع أهدافك. نشاط التداول في Bybit ليس مثل إرسال معاملة داخل الكتلة على سولانا؛ قد لا تزال تُطبق رسوم الشبكة عند إيداع أو سحب SOL على شبكة سولانا.

كل فشل في معاملة سولانا يعود إلى واحد من خمسة أسباب جذرية، ولكل منها إصلاح محدد.

أموالك الأساسية آمنة في كل هذه السيناريوهات. لا تُفقد الرموز المميزة بشكل دائم في معاملات Solana الفاشلة؛ فقط يتم استهلاك حد أدنى من الرسوم الأساسية. لتجنب الفشل المتكرر، قم بالمرور عبر قائمة التحقق قبل المعاملة قبل عملية المبادلة أو الإنشاء التي تتطلب وقتًا في المرة القادمة.

مسارات الإعدادات المشار إليها في هذا الدليل دقيقة اعتبارًا من تاريخ النشر وقد تختلف حسب إصدار المحفظة أو DEX. تختلف مستويات الرسوم مع طلب الشبكة؛ استخدم ميزة التقدير التلقائي لمحفظتك أو واجهة برمجة تطبيقات Helius Priority Fee API للقيم الحالية. يتم تقديم مراجع الأدوات (Helius، QuickNode، Solana Beach) كخيارات، وليس كتأييدات.