---
title: "مسار الهروب في Rollup"
description: "دليل يراعي اختلاف البروتوكولات لمسارات الهروب في Rollup: الآليات المختلفة التي يشملها المصطلح وضماناتها واعتمادياتها وكيفية التحقق من مسار الخروج."
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.

# مسار الهروب في Rollup

> لأغراض تعليمية فقط، وليس نصيحة مالية أو أمنية. تختلف آليات الخروج والمدد والرسوم وصلاحيات العقود وافتراضات توافر البيانات باختلاف L2، وقد تتغير بعد الترقيات.

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

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

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

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

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

## آلية العمل

- **حدد الآلية الأساسية.** يعالج الإدراج القسري والسحب القسري ووضع الهروب مشكلات مختلفة. يتجاوز الإدراج القسري منسقًا يفرض الرقابة أو لا يعمل. ويلزم طلب السحب القسري البروتوكول أو المشغل بتنفيذ الخروج أو إثبات بطلانه. أما وضع الهروب فعادة ما يكون الملاذ الأخير، إذ تتوقف التحديثات العادية ويسحب المستخدمون بواسطة براهين الحالة.
- **ادخل عبر L1.** يرسل المستخدم معاملة إلى صندوق الوارد أو البوابة أو عقد التسوية على L1 المحدد في وثائق البروتوكول. في OP Stack تُشتق إيداعات L1 إلى كتل L2 ضمن نافذة الترتيب. وفي Arbitrum Nitro يمكن إدخال الرسالة إلى Delayed Inbox ثم فرض إدراجها في صندوق الوارد الرئيسي بعد المهلة المضبوطة إذا لم يدرجها المنسق.
- **انتظر معالجة البروتوكول.** تأكيد L1 هو نقطة الفحص الأولى فقط. قد يلزم أن يدخل الطلب سلسلة L2 الرسمية وينفذ بنجاح ويظهر في حالة مثبتة أو مؤكدة ويمر بفترة اعتراض أو سماح ثم تتم تسويته على L1. وحتى المعاملة القسرية قد ترتد بسبب nonce خاطئ أو Gas غير كاف أو calldata خاطئة أو قيود الرمز أو تغير حالة L2.
- **استوف شروط الخروج.** يقدم StarkEx Spot مثالًا حقيقيًا للسحب القسري والهروب. يرسل المستخدم `fullWithdrawalRequest`؛ وعلى التطبيق تنفيذ الطلب أو إثبات بطلانه. وإذا بقي معلقًا بعد `FREEZE_GRACE_PERIOD` فيمكن طلب التجميد. ثم يتطلب الهروب مسار Merkle إلى جذر الخزنة المجمد، والتحقق من البرهان، واستدعاء `escape`، ثم استدعاء `withdraw` العادي على السلسلة.
- **تحقق من توافر البيانات.** جذر الحالة التزام مشفر، وليس الأرصدة أو مسارات Merkle الكامنة نفسها. إذا نُشرت على L1 البيانات اللازمة لإعادة بناء الحالة، يستطيع طرف مستقل من حيث المبدأ إنشاء برهان خروج. أما في Validium أو تصاميم توافر البيانات خارج السلسلة فقد يعتمد المستخدم على لجنة أو مشغل لنشر البيانات. صحة البرهان وتوافر البيانات ضمانان منفصلان.
- **تحقق من التحكم والأدوات.** راجع صلاحيات الإيقاف والتجميد والترقية والحوكمة، وعناوين العقود الدقيقة وتنفيذات الوكيل، والأصول المدعومة، والمفاتيح المطلوبة، وGas على L1 وL2، وبرمجيات إنشاء البراهين، ووجود واجهة مستقلة. قد تكون الآلية صحيحة نظريًا ولكنها غير عملية لمن يفتقر إلى البيانات أو الأدوات أو رصيد L1 الكافي.

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

## مثال

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

يختلف التسلسل في نظام على غرار StarkEx: أرسل الطلب القسري الموثق، وانتظر فترة السماح المضبوطة، وتحقق مما إذا نُفذ الطلب أو ثبت بطلانه، ولا تستخدم التجميد والهروب إلا عند استيفاء شروط العقد. يجب أن يتطابق معرف الخزنة والمفتاح ومسار Merkle مع الحالة المجمدة. ومن الخطأ نسخ إجراء Arbitrum أو OP Stack إلى هذا النظام حتى إن وُصفت جميعها أحيانًا بأنها «سحوبات قسرية».

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

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

## المخاطر

- يوفر البروتوكول إدراجًا قسريًا ولكن لا يوفر دالة سحب قسري مباشرة.
- تأكد طلب L1 لكن استدعاء L2 ارتد أو لم ينفذ بعد.
- تؤخر فترة الاعتراض أو البرهان أو السماح أو التسوية الوصول إلى الأموال.
- لا تتوافر بيانات الحالة أو مسار Merkle، خصوصًا مع البيانات خارج السلسلة.
- استُخدمت سلسلة أو عقد أو تنفيذ وكيل أو دالة أو معرف خزنة خاطئ.
- عقد الخروج متوقف أو تمت ترقيته أو تجميده خطأ أو تأثر بعيب.
- تستطيع الحوكمة أو لجنة أمنية أو جهة ذات صلاحية تغيير مسار الخروج.
- الأصل غير مدعوم أو غير قياسي أو ضعيف السيولة أو خاضع لقواعد هامش.
- تمنع قفزة Gas على L1 أو قلة العملة الأصلية الإرسال أو التسوية.
- لا تتوافر الواجهات أو RPC أو المفهرسات أو أدوات البرهان عند الحاجة.
- تسرق واجهة مزيفة أو إعلان بحث أو رسالة دعم بيانات الاعتماد أو الأموال.
- قد تنخفض القيمة السوقية أثناء التأخير؛ قابلية الخروج لا تحمي السعر.

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

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

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

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

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

- [الجسر الرسمي](/ar/crypto/canonical-bridge/)
- [التجميع التفاؤلي](/ar/crypto/optimistic-rollup/)
- [السحب القسري من L2](/ar/crypto/l2-forced-withdrawal/)
- [المنسق](/ar/crypto/sequencer/)
- [ZK Rollup](/ar/crypto/zk-rollup/)

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

## المصادر

- [نظرة عامة على بروتوكول OP Stack](https://specs.optimism.io/protocol/overview.html) - OP Stack Specification (تاريخ الاطلاع: 2026-08-21)
- [Arbitrum Nitro: تجميع تفاؤلي من الجيل الثاني](https://docs.arbitrum.io/nitro-whitepaper.pdf) - Offchain Labs (تاريخ الاطلاع: 2026-08-21)
- [السحب والهروب من دون موافقة التطبيق](https://docs.starkware.co/starkex/spot/withdrawing_and_escaping_without_app_approval.html) - StarkEx Documentation (تاريخ الاطلاع: 2026-08-21)
- [توافر البيانات](https://docs.starkware.co/starkex/con_data_availability.html) - StarkEx Documentation (تاريخ الاطلاع: 2026-08-21)

Source: https://wiki.fcontext.com/ar/crypto/rollup-escape-hatch/index.mdx