---
title: "الحماية من إعادة تشغيل الرسائل عبر السلاسل"
description: "تربط الحماية من إعادة التشغيل رسالة مصدر موثقة بإصدار بروتوكول واحد ونطاق وجهة واحد، ثم تسمح بإعادة المحاولة من دون السماح بأكثر من أثر اقتصادي ناجح واحد."
image: "https://wiki.fcontext.com/og.png"
---

> Documentation Index
> Fetch the complete documentation index at: https://wiki.fcontext.com/llms.txt
> Use this file to discover all available pages before exploring further.

# الحماية من إعادة تشغيل الرسائل عبر السلاسل

> لأغراض تعليمية فقط؛ لا يشكل ذلك نصيحة استثمارية أو توصية استثمارية. قد تؤدي الاستثمارات إلى خسائر.

<a id="answer"></a>

## الإجابة المباشرة

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

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

لا يوجد `messageId` موحد لكل السلاسل. تحدد مواصفات البروتوكول الدقيقة التسلسل والهوية. يربط الغلاف المتين عادة البروتوكول وإصداره، ونطاق المصدر والمرسال أو المصدر، ومرسل المصدر، والرقم الفريد أو هوية معاملة أو سجل المصدر، ونطاق الوجهة والمستلم، والقيمة، والحمولة، وأي انتهاء صلاحية. تستخدم Wormhole وCCTP وOptimism وERC-5164 حقولا وآلات حالات مختلفة، لذلك لا يمكن تبادل معرفاتها.

<a id="mechanism"></a>

## آلية العمل

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

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

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

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

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

استخدم سير العمل الآتي:

1. ثبت البروتوكول والإصدار المنشور ونطاقي المصدر والوجهة والمرسال أو المصدر الموثوق والمرسل والمستلم والقيمة والحمولة والرقم الفريد أو هوية الحدث ودلالة انتهاء الصلاحية.
2. أعد إنتاج الترميز القياسي ومتجه اختبار `messageId` حسب المواصفات؛ وارفض الربط الغامض والحقول المحذوفة والافتراضات المستعارة من جسر آخر.
3. تحقق من إدراج المصدر ومن سياسة النهائية أو التأكيد المطلوبة، ثم من جذر الإثبات الصحيح ونصاب التوقيع ومجموعة المدققين أو الحراس والإصدار.
4. تحقق بصورة مستقلة من الوجهة والمستلم ومرسل المصدر عبر النطاق والقيمة والحمولة والانتهاء؛ واعتبر المرحل الناقل وسيلة نقل لا جهة تفويض.
5. اقرأ حالة الرسالة الدائمة وانتقل إلى حالة المعالجة أو الاستهلاك قبل أي استدعاء خارجي غير موثوق، مع حماية من إعادة الدخول واختبار صريح لسلوك تراجع المعاملة.
6. عرف انتقالات النجاح والفشل وقابلية الإعادة، وسلوك الرقم المرتب أو خريطة البتات، وذرية الدفعة ومحاسبة القيمة؛ وأثبت أن التسليم المتكرر لا يكرر ورقة ناجحة.
7. اختبر الترقيات وترحيل التخزين وتعطيل نقاط الدخول القديمة وتدوير النظراء والانقسامات والاسترداد الطارئ، ثم طابق الإيصالات والأحداث وحالة المعالجة وأرصدة الوجهة.

<a id="example"></a>

## أمثلة

- **ربط نطاق الوجهة.** يحمل تعليمان الرقم الفريد `42` والقيمة `1,000`، لكن أحدهما يستهدف السلسلة `10` والآخر السلسلة `8453`. يعامل المعرف الذي يحذف الوجهة `2 messages` كمرشح تصادم واحد؛ أما الترميز القياسي الذي يربط الوجهة فينتج `2 distinct IDs`. ويجب أخذ دالة التجزئة وتمثيل النطاق الفعليين من البروتوكول.
- **خريطة بتات غير مرتبة.** للرقم `513` يكون `word = floor(513 / 256) = 2` و`bit = 513 mod 256 = 1` و`mask = 1 << 1 = 2`. يغير النجاح الأول كلمة خريطة البتات `2` من `0` إلى `2`. وتجد النسخة المكررة `2 & 2 = 2` فترفض، بينما يستخدم الرقم `512` البت `0` بصورة مستقلة.
- **إعادة المحاولة ليست أثرا ثانيا.** تسلم الرسالة الموثقة نفسها `3` مرات. يفشل استدعاءا الوجهة اللذان يستخدمان `110,000` و`125,000` وحدة غاز ويتراجعان؛ ويستخدم الثالث `140,000` وحدة وينجح مرة واحدة. إجمالي الغاز `110,000 + 125,000 + 140,000 = 375,000`؛ وعند `20 gwei` يساوي `0.0075 ETH`. عدد التسليمات `3` لكن عدد آثار العمل الناجحة `1`.
- **محاسبة الدفعة الجزئية.** تحمل أربع أوراق قابلة للتنفيذ المستقل `25 + 40 + 15 + 20 = 100` وحدة. تنجح الأوراق `0` و`1` و`3` بقيمة `25 + 40 + 20 = 85`؛ وتفشل الورقة `2` وتترك `15` معلقة. استهلاك جذر الدفعة وحده يعطل `15`؛ وإعادة الدفعة كلها بلا حالة لكل ورقة قد تكرر `85`. استخدم تراجعا ذرياً أو حالة معالجة لكل ورقة حسب المواصفات.

<a id="risks"></a>

## المخاطر

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

<a id="misconceptions"></a>

## مفاهيم خاطئة شائعة

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

<a id="related"></a>

## موضوعات ذات صلة

- [الجسر عبر السلاسل](/ar/crypto/cross-chain-bridge/)
- [الجسر المعتمد](/ar/crypto/canonical-bridge/)
- [فشل مرحل الرسائل عبر السلاسل](/ar/crypto/bridge-relayer-liveness-risk/)

<a id="sources"></a>

## المصادر

- [ERC-5164: Cross-Chain Execution](https://eips.ethereum.org/EIPS/eip-5164) - Ethereum Improvement Proposals (تاريخ الاطلاع: 2026-08-13)
- [EIP-712: Typed structured data hashing and signing](https://eips.ethereum.org/EIPS/eip-712) - Ethereum Improvement Proposals (تاريخ الاطلاع: 2026-08-13)
- [CCTP Technical Guide](https://developers.circle.com/cctp/references/technical-guide) - Circle Developers (تاريخ الاطلاع: 2026-08-13)
- [Interop message passing overview](https://docs.optimism.io/app-developers/guides/interoperability/message-passing) - Optimism Documentation (تاريخ الاطلاع: 2026-08-13)
- [VAAs](https://docs.wormhole.com/protocol/infrastructure/vaas/) - Wormhole Docs (تاريخ الاطلاع: 2026-08-13)
- [Security Considerations](https://docs.soliditylang.org/en/latest/security-considerations.html) - Solidity Documentation (تاريخ الاطلاع: 2026-08-13)
- [Proof-of-stake (PoS)](https://ethereum.org/developers/docs/consensus-mechanisms/pos/) - ethereum.org (تاريخ الاطلاع: 2026-08-13)
- [Upgrading smart contracts](https://docs.openzeppelin.com/contracts/5.x/learn/upgrading-smart-contracts) - OpenZeppelin Docs (تاريخ الاطلاع: 2026-08-13)

Source: https://wiki.fcontext.com/ar/crypto/bridge-message-replay-protection/index.mdx