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

حدد مرحلة الفشل قبل البحث عن سببه
افتح سجل المحفظة وافحص هل توجد معاملة أُدرجت في كتلة، أم مجرد رفض في الواجهة أو المحاكاة أو الإرسال. قد تستخدم البرامج كلمة فشل لتلخيص أكثر من مرحلة. وجود رسالة خطأ لا يثبت وحده دفع رسم شبكة، وغياب النتيجة المطلوبة لا يثبت أن المعاملة لم تُعالج. الإيصال والحالة والكتلة والمعرف تساعد على الفصل.
تشرح وثائق الغاز الرسمية في إيثريوم الفرق بين موارد التنفيذ والحدود وبعض صور الفشل. إذا كان الإعداد غير صالح من البداية، فقد يُرفض قبل الإدراج. أما المعاملة التي بدأت تنفيذًا داخل كتلة ثم لم تتمه، فتحتاج إلى قراءة استهلاكها وحالة أثرها. لا تجمع الحالتين تحت وصف واحد مثل «الغاز ضاع» دون بيانات.
يمكن استخدام مساعد مشكلات التحويل لتحديد هل العملية معلقة أو مرفوضة أو مدرجة وفاشلة أو ناجحة مع مشكلة قيد. لا تحاول تسريع معاملة انتهى تنفيذها بالفشل كما لو كانت تنتظر الإدراج، ولا تنشئ دفعة جديدة لإصلاح نقص عرض في محفظة قبل التأكد من الحالة الفعلية.
نفاد الغاز: الكمية المسموحة لم تكفِ للمسار
كمية الغاز تقيس ميزانية تنفيذ ضمن قواعد الشبكة ونوع العملية، وهي تختلف عن سعر الوحدة الذي تدفعه. إذا نفدت الكمية أثناء التنفيذ، فإن رفع سعر كل وحدة وحده لا يضيف وحدات إلى الحد. والعكس صحيح: زيادة حد الكمية لا تعالج تلقائيًا سعرًا لا يتيح الإدراج أو شرطًا منطقيًا يرفضه العقد.
لا تنقل حدًا من عملية بسيطة إلى عقد مختلف ثم تفترض أنه مناسب. قد تختلف التعليمات والمدخلات والحالة ومسار التنفيذ، وقد تكون هناك خطوات فرعية لا تظهر في أول شاشة. استخدم تقدير البرنامج الموثوق وتوثيق التطبيق، واقرأ سبب التحذير بدل وضع رقم كبير عشوائيًا لإسكاته. الحد الأعلى ليس علاجًا عامًا ولا معيارًا لسلامة التفاعل.
وقد تساعد مقارنة الغاز المستخدم بالحد على بناء فرضية، لكنها ليست إثباتًا منفردًا لكل سبب. قد يفشل استدعاء داخلي أو تتغير طريقة معالجة الخطأ، وقد تعرض الواجهة معلومات مختصرة. إذا كانت الرسالة أو البيانات لا تكفي، فاطلب تفسيرًا مرتبطًا بالعقد والعملية من مصدر موثوق بدل اتخاذ قرار مكلف اعتمادًا على نسبة استهلاك واحدة.
رفض العقد: شرط لم يتحقق
قد يتراجع العقد لأن كمية أو صلاحية أو موعدًا أو حالة لازمة غير مناسبة. لا يصبح الشرط صحيحًا بمجرد إعطاء التنفيذ كمية غاز أكبر. مثال ذلك عملية لا تقبل نتيجة أقل من حد حددته، ثم تتغير الحالة قبل التنفيذ. زيادة ميزانية الموارد لا تغير بحد ذاتها أقل كمية وافقت على استلامها أو الموعد الذي انتهى.
توضح مواصفة REVERT في EIP-140 إمكان إيقاف التنفيذ وإرجاع تغييرات الحالة مع الحفاظ على ما لم يُستهلك من الغاز وفق المسار. لهذا قد تفشل عملية دون استهلاك الحد كله. لكن الرسالة المعروضة قد تكون مختصرة أو تحتاج إلى تفسير من توثيق العقد، ولا تضمن وحدها أن واجهة عامة تشرح كل ما حدث بدقة.
وإذا كان الخطأ من خطوة داخل مسار أكبر، فافهم هل فشل الاستدعاء الأعلى كله أم عولج الفشل ضمن تنفيذ نجح في جوانب أخرى. حالة النجاح العامة لا تشرح دائمًا تحقق كل غرض كنت تقصده. طابق الناتج والسجلات والأصل والكمية، ولا تجعل اسم خطأ داخلي أو لون حالة بديلًا عن قراءة نتيجة العملية الكاملة.
جدول تشخيص قبل تغيير الإعدادات
| ما وجدته | ما قد تحتاج إلى فحصه | تعديل لا يعالج السبب وحده |
|---|---|---|
| رفض قبل الإدراج | صلاحية الإعداد والرصيد والرسالة | افتراض أن رسم تنفيذ مدرج دُفع |
| نفاد موارد أثناء التنفيذ | الحد والتقدير ومسار العقد | رفع سعر الوحدة دون معالجة الكمية |
| تراجع بسبب شرط كمية | المدخلات والحد المقبول والحالة وقت التنفيذ | زيادة حد الغاز فقط |
| موعد أو عرض قديم | صلاحية البيانات وتحديث المسار | إعادة توقيع الطلب القديم نفسه |
| موافقة أو صلاحية غير مناسبة | الجهة والكمية والنوع والمعاملة المرتبطة | منح صلاحية أوسع عشوائيًا |
الجدول لا يقدم تشخيصًا تلقائيًا لكل رسالة. استخدمه لترتيب الأسئلة، ثم طابقها بما يعرضه البرنامج وتوثيق العملية. قد تتشابه كلمات الخطأ بين تطبيقين بينما تختلف الأسباب، وقد تظهر رسالة عامة عندما لا يستطيع المصدر فك بيانات تفصيلية. سجل ما تعرفه وما لا تعرفه بدل ملء الفراغ بتخمين ثم تكرار دفع الرسوم لاختباره.
مثالان يوضحان الفرق في القرار
نفترض حالة تعليمية بحد 100000 واستهلاك 50000 وحالة فشل، مع تفسير موثوق يشير إلى عدم تحقق أقل كمية ناتجة. لا يبدو رفع الحد إلى 200000 علاجًا لذلك الشرط بحد ذاته. راجع هل ما زلت تريد العملية عند الشروط المقبولة لك، وما الحالة الحالية، بدل اعتبار كل رفض دعوة إلى توسيع الحدود حتى يمر التوقيع.
وفي حالة تعليمية أخرى، يظهر حد 100000 واستهلاك قريب منه مع فشل ورسالة عن نفاد موارد التنفيذ. هذه قرائن تستحق فحص التقدير والمسار، لكنها لا تكفي لتحديد رقم جديد من مقال عام. افهم العملية والتوثيق وميزانيتك، ثم قارن ما يسمح به التعديل وما قد تدفعه إذا انتهت محاولة أخرى بالفشل.
والأرقام لا تصف رسومًا حالية ولا حدودًا مقترحة. إذا كان السعر الفعلي افتراضيًا 20 gwei واستهلكت معاملة مدرجة 50000 وحدة، فتكلفة التنفيذ 0.001 ETH ضمن هذا المثال. لا تستخدم الحد وحده بدل الاستهلاك الفعلي، ولا تجعل كمية الرمز الذي كنت تريد مبادلته جزءًا من هذا الضرب. افصل الأصول ووحدات الرسوم قبل حساب الإجمالي.
المحاكاة مفيدة ولكنها تصف سياقًا
قد تنفذ الواجهة تقديرًا أو محاكاة باستخدام حالة متاحة قبل البث، ثم تتغير أسعار أو سيولة أو موافقات أو بيانات أخرى قبل الإدراج. وقد يكون للطلب موعد أو عرض يحتاج إلى تحديث. لذلك تعامل مع المحاكاة كأداة لكشف مشكلات محتملة، لا ضمانًا بأن كل شروط التنفيذ المستقبلية ستظل مطابقة لما فُحص أولًا.
تؤكد الأسئلة التقنية لـUniswap عن تنفيذ المبادلات أن المحاكاة لا تضمن نجاح التنفيذ على السلسلة إذا تغيرت عوامل بين المرحلتين. استخدم التوثيق المناسب لمنتجك ولا تعمم حدًا زمنيًا أو نسبة أو حلًا برمجيًا من مسار آخر. وإذا عرضت الواجهة تحذيرًا بأن العملية ستفشل، فاقرأ سببه بدل تجاوزه لمجرد أنك تريد إكمال الطلب.
ولا تعدل البيانات المشفرة للعملية أو تنسخ قيمًا من محادثة لا تعرف كيف أنتجتها. قد تغير وظيفة العقد أو وجهة المال أو الكمية أو الصلاحية. إذا لم تستطع تفسير ما سيُوقع، فهذه مشكلة فهم للمسار قبل أن تكون مشكلة غاز. يمكن أن يساعد مساعد اختيار المحفظة على تقييم قدرة إعدادك على عرض تفاصيل التوقيع والتحكم.
الموافقات السابقة قد تكون عملية مستقلة
قد ينجح طلب موافقة على إنفاق رمز ثم يفشل الإجراء التالي. لا يعني فشل الثاني أن أثر الأول أُلغي تلقائيًا، خصوصًا عندما كانا معاملتين مستقلتين لكل منهما معرفها. افتح السجل وحدد ما أُدرج وما سمح به، بدل الاعتماد على وصف رحلة كاملة في تطبيق يقول إن «المبادلة فشلت».
تشرح مواصفة ERC-20 بعض وظائف الرمز والموافقات. بالنسبة للمراجعة، افحص الجهة المخولة والكمية والنوع وفق المسار الذي تستخدمه. لا تجعل علاج رسالة صلاحية هو منح حد غير محدود لموقع مجهول، ولا تشارك عبارة الاستعادة أو المفتاح الخاص مع شخص يقول إنه يحتاج إليهما لقراءة سبب فشل عام.
وإذا احتجت إلى مراجعة أو تغيير صلاحية، استخدم أدوات وتوثيقًا تعرف مصدرهما وافهم التكلفة والأثر قبل التوقيع. هذه خطوة مختلفة عن متابعة إيصال أو تحديث سعر. فصل الأفعال يحمي سجلك من الخلط بين رسوم الموافقة ورسوم المحاولة وبين سلطة أنشأتها سابقًا ونتيجة لم تكتمل بعدها.
ضع ميزانية للمحاولات قبل تكرارها
قد تدفع رسم محاولة مدرجة فاشلة ثم رسم محاولة لاحقة مستقلة. لا تعتبر كل ضغط زر تكلفة فعلية، لكن لا تعتبر الفشل سببًا لاسترداد كل ما استُهلك تلقائيًا. راجع الإيصالات وحالات الإدراج والعلاقات بين المعاملات، ثم احسب ما حدث فعلًا. المعاملات البديلة المتعارضة تختلف عن محاولات متتالية يمكن أن تُدرج كل منها.
يمكن استخدام أداة مقارنة تكلفة التحويل لتنظيم الرسوم ومبلغ العملية والخطوات الأخرى. وقبل محاولة جديدة، اكتب ما تغير ولماذا تتوقع أن يعالج السبب. إذا لم تستطع تحديد فرق ذي معنى، فقد تكون تعيد الشروط نفسها وتشتري نتيجة الفشل مرة أخرى بدل حلها. ولا تدفع لموقع يَعِد بإصلاح كل عقد أو استرجاع كل رسم بلا تفسير.
قائمة مراجعة عملية
- حدد الشبكة والمعرف ومرحلة الفشل، ثم افتح الإيصال والرسالة والغاز المستخدم والحد وفق المسار.
- افصل كمية الموارد من سعر الوحدة، وميز نفاد التنفيذ من رفض شرط أو بيانات قديمة أو مشكلة صلاحية.
- راجع المدخلات والوجهة والأصل والكمية والتوثيق الحالي، دون استخدام نسبة الاستهلاك وحدها برهانًا نهائيًا.
- حدد أثر التعديل في التكلفة والنتيجة والصلاحيات، ثم أعد تقدير الحالة قبل أي توقيع جديد.
- احتفظ بمعرفات الموافقات والمحاولات ونتائجها، وشارك مع الدعم البيانات العامة اللازمة فقط.
وإذا كنت تنقل تفسيرًا من شبكة إلى أخرى، فراجع مقارنة بيتكوين وإيثريوم أولًا. آلية رسوم أو فشل في نظام لا تمنح حلًا عامًا لكل نظام، والهدف أن تعرف أي شرط أو مورد توقف عنده مسارك المحدد قبل أن تختار ما ستغيره في المحاولة التالية.