توفر الواجهة وصولًا إلى عقدة أو خدمة لها حدود واعتماديات خاصة. في Ethereum يختلف الاستعلام أو محاكاة الحالة عن نشر معاملة. تصف الأمثلة Ethereum، لا جميع سلاسل الكتل.
آثار القراءة والإرسال مختلفة
في Ethereum ينفذ eth_call استدعاءً دون إنشاء معاملة على السلسلة؛ وقد يفرض مزود RPC رسوم خدمة. يرسل eth_sendRawTransaction معاملة موقعة مسبقًا. استلام معرّف لا يثبت الإدراج أو النجاح. تحقّق من الإيصال والحالة والكتلة ثم نهائية المعاملة المناسبة للشبكة.
ضبط الاعتماديات والأخطاء
تحقق من الشبكة وعنوان العقد وواجهته ومعاملاته قبل التوقيع. لا تضمن المحاكاة نتيجة تنفيذ لاحق إذا تغيرت الحالة. قد تستهلك معاملة منفذة فاشلة gas رغم فشلها. العقد الذكي برنامج؛ لا يضمن الاسم خلوه من العيوب أو الصلاحية القانونية للاتفاق.
ضوابط يجب تحديدها
- تحديد صلاحيات التوقيع وحدود الإنفاق وإدارة المفاتيح.
- التمييز بين تعطل RPC ومعاملة معلقة أو فاشلة أو أعيد تنظيم كتلتها.
- إذا قدم أوراكل حقائق خارجية، فتُقيّم مصادره وحوكمته وأخطاؤه المحتملة.
المصادر
- Ethereum · JSON-RPC API
- Ethereum · Transactions
- Ethereum · Gas and fees
- Ethereum · Smart contracts
- Ethereum · Oracles
المراجعة التحريرية: 31 أكتوبر 2026.
فصل المعاملات المُرسلة، والمُضمنة، والمُفسَّرة.
لا يُحدد مُعرِّف المعاملة التأثير المقصود. تحقق من الشبكة، والإيصال، والتضمين، والحالة، والحدث التجاري ذي الصلة. حدد سياسة التأكيد والاسترداد للسلسلة المُستخدمة؛ يجب ألا تُعلن الواجهة عن نجاح العملية بينما تظل النتائج غير مؤكدة.
- تحقق من الشبكة والمُعرِّف المُستعلم عنهما.
- فصل التأثيرات المُعلقة، والتنفيذ الفاشل، والمؤكدة.
- اختبار الإشعارات المُتكررة دون إعادة تنفيذ الإجراءات التجارية.
هل تعني قيمة التجزئة المُعادة انتهاء العملية؟
لا، إنها تُحدد معاملة مُرسلة. يتطلب تتبع النتائج وتفسيرها عمليات تدقيق مُلائمة للسلسلة والعقد؛ لا تُعيد إرسال عملية غامضة دون تدقيق.
المصدر الأساسي: Ethereum — JSON-RPC and transaction receipts. المنهج المرتبط: اقرأ الدليل العملي.
حصص API وحدود الطلبات
تؤثر الحدود في السعة والمحاولات والتوزيع بين العملاء.
- سجّل هل الحصة تخص الحساب أو المفتاح أو المورد، وعدد العمليات المتزامنة المسموح بها للعميل. قد يرهق طابور غير محدود الخدمة حتى لو كان متوسط الطلبات منخفضاً.
- عند 429 فسّر Retry-After إن وُجد وانتظر قبل طلب آخر. اجمع الانتظار المتزايد وتوزيع توقيت العملاء مع حد للمحاولات ومدة إجمالية.
- عند فقد رد عملية كتابة افحص الحالة قبل التكرار. في المحاكاة اجمع الحصص والردود المتأخرة والإلغاء؛ يجب أن ينتهي الطابور بلا آثار مكررة.
حالة قبول قابلة للتكرار
مثال افتراضي: البيانات لا تصف عميلاً أو نتيجة مرصودة.
عرض بيانات الحالة
{
"http_status": 429,
"retry_after_seconds": 30,
"workers": 20,
"retry_budget": 3,
"retry_budget_scope": "per_worker_retries_excluding_initial_request",
"scheduling_example": {
"response_received_at_seconds": 0,
"illustrative_retry_seconds": [
30,
31,
32,
33,
34
],
"workers_per_second": 4,
"alternative_deadline_seconds": 25,
"total_attempts_if_all_retries_used": 80
}
}القرار المتوقع
احترم انتظار 30 ثانية ووزّع محاولات العمال العشرين وحدد سقفاً للتكرار.
عشرون عميلًا: توزيع المحاولات وحسابها
مثال افتراضي: يتلقى 20 عاملًا عند +0 s ردًا 429 مع Retry-After: 30. الأوقات توزيع ممكن وليست ضمانًا لسعة الخادم. لكل عامل 3 محاولات إعادة إضافة إلى طلبه الأول.
| السياسة | الحساب أو التوقيت | الأثر |
|---|---|---|
| إعادة متزامنة | 20 × 1 = 20 @ +30 s | انتظار 30 ثانية يحترم المهلة، لكن الطلبات العشرين تعود معًا وقد تتكرر طفرة الحمل. |
| إعادة موزعة | 4 × 5 = 20 @ +30…+34 s | أربعة طلبات في الثانية لمدة خمس ثوانٍ توزع المحاولات العشرين دون تقليل عددها. الجدول التوضيحي لا يستبدل سياسة انتظار متزايد بتفاوت عشوائي. |
| مهلة 25 ثانية | 25 s < 30 s → 0 | إذا كان الوقت المتبقي أقل من الثلاثين ثانية المطلوبة، أوقف الطلب أو أجّله وفق العقد. لا تختصر الانتظار للالتزام بالمهلة. |
| الحد الأقصى للمحاولات | 20 × (1 + 3) = 80 | استخدام كل المحاولات يعني 20 طلبًا أوليًا و60 إعادة، أي 80 طلبًا. الحد لا يضمن النجاح أو سلامة التكرار. |
إجراء التحقق
- سجّل نطاق الحصة وميزانية التكرار.
- استنفد الحصة فقط في اختبار مأذون.
- احتفظ بـ 429 وRetry-After وتسلسل محدود. ميّز الحد التقني عن نتيجة العملية؛ فلا ينبغي تحويل نفاد الحصة إلى استجابة تفيد بانعدام المخزون.
- حاكِ دون حمل خارجي أربع طبقات بثلاثة طلبات إجمالية لكل منها واحسب المحاولات.
- أنه مهلة مهمة افتراضية في الطابور وتحقق من عدم بدء عملية جديدة.
- أعد العمل المصرح تدريجياً بعد عطل محاكى واحفظ الطلبات والمهل والنتائج الفريدة.
هل يثبت 429 أن كتابة سابقة لم تنفّذ؟
لا. تحتاج العملية التي فُقد ردها إلى مطابقة مستقلة؛ لا تستنتج حالتها من رد محاولة أخرى.
المصدر الأساسي: IETF — RFC 6585, HTTP 429. المنهج المرتبط: اقرأ الدليل العملي.
API: منع تضاعف المحاولات بين الطبقات
قد يعيد التطبيق وSDK والوكيل والخدمة الطلب نفسه. أربع طبقات افتراضية بثلاث محاولات إجمالية لكل منها تنتج حتى 81 طلباً للتبعية المعطلة. أضف ميزانية مشتركة ومهلة مفيدة إلى حدود الحصة.
- ارسم محاولات التطبيق وSDK والوكيل والتبعيات التلقائية. اختر طبقة مسؤولة وعطل أو نسق الإعادات الأخرى وفق العقد. احسب المحاولة الأولى في الميزانية. احفظ معرّف العملية وافحص الآثار غير المؤكدة قبل تكرار إجراء غير آمن للتكرار.
- حدّد مهلة شاملة للانتظار والاتصال والمعالجة وفق حدود العميل الفعلية. ارفض المهام المنتهية قبل دخول الطابور. الإلغاء المحلي لا يثبت توقف الخادم؛ طابق حالته. أعد الحركة تدريجياً دون تشغيل كل الطوابير معاً.
هل ثلاث محاولات لكل طبقة تعني ثلاثاً إجمالاً؟
لا. أربع طبقات افتراضية بثلاث محاولات إجمالية تعطي حتى 3⁴ = 81 طلباً أخيراً.
هل انتهاء المهمة يلغي أثرها البعيد؟
ليس بالضرورة. يمنع عملاً جديداً متقادماً؛ العملية المبدوءة تحتاج فحص الحالة وتعويضاً إن أمكن.
المصدر الأساسي: AWS — Timeouts, retries, and backoff with jitter. المنهج المرتبط: اقرأ الدليل العملي.