---
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>

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

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

افصل هذه المراحل والمطالبات:

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

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

تلك الملصقات Ethereum ليست عالمية. في سلسلة Cosmos SDK، يؤدي إلغاء التفويض من قبل المفوّض إلى إنشاء إدخال غير مربوط مع وقت إكمال مكوَّن من السلسلة، ويمكن للوحدات الخارجية وضع إلغاء الربط في الانتظار. في Solana، تقوم سلطة حساب الحصة بإلغاء التفويض، وتبرد الحصة عبر حدود الحقبة، ويمكن لسلطة السحب سحب الحصة غير النشطة مع مراعاة أي قفل. يمكن لعقود إعادة الاستفادة إضافة سحب آخر في الطابور ونافذة قابلية للخصم. تحقق دائمًا من الشبكة والإصدار والوحدة والعقد وشروط الخدمة الدقيقة.

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

## كيفية تحليل توقيت الخروج والانسحاب

### 1. حدد الموقع وقواعد اللعبة

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

### 2. تحقق من السلطة واطلب القبول

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

### 3. أعد بناء آلة الحالة

اكتب كل حالة وانتقال بدلاً من تاريخ واحد مُقدّر. مسار المدقق التوضيحي هو `active -> exit_requested -> exit_scheduled -> exited -> withdrawable -> withdrawal_processed -> wallet_credited`. قد ينتقل المفوض بدلاً من ذلك عبر `bonded -> unbonding -> matured -> transferred`، في حين قد يكون حساب الرهن `active -> deactivating -> inactive -> withdrawn`. سجّل أي الانتقالات تلقائية وأيها تتطلب معاملة أخرى أو إجراء خدمة.

### 4. قم بقياس كل عنق زجاجة

افصل حدود استقبال الطلبات، ومعدل خروج المدققين، والتأخيرات الثابتة، وقدرة مسح السحب، وطوابير العقود، وتجميع المزود، والنهائية أو التأكيد. حدد ما إذا كانت السعة تُقاس بسجلات المدققين، أو الرهن الفعال، أو الرصيد، أو الطلبات، أو الغاز، أو الوقت المنقضي. استفسر عن `queue_ahead`، و`capacity_per_interval`، وحجم أو رصيد المجموعة النشطة، وأي حدود عند نقطة الملاحظة النهائية نفسها. لا يصلح التقدير البسيط `ceil((work_ahead + own_work) / capacity)` إلا عند تحقق فرضيات الترتيب والسعة.

### 5. حدد الواجبات والمكافآت وإمكانية التخفيض

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

### 6. تتبع طبقات الأصل والمطالبة

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

### 7. تحقق من الاكتمال وخطط للسيولة

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

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

## أمثلة محلولة

### حساب التوقيت متعدد المراحل

ضع في اعتبارك بروتوكولًا توضيحيًا مع `block_time = 12 seconds` و `epoch = 30 blocks = 6 minutes`. يستغرق الطلب `4 blocks` للوصول إلى نقطة التأكيد المختارة، وينتظر `72 epochs` لسعة الخروج، ثم يكون لديه تأخير مسؤولية `8 epochs` و `12 blocks` متوقع حتى معالجة النقل:

`4 * 12 = 48 seconds`.

`72 * 6 = 432 minutes`.

`8 * 6 = 48 minutes`.

`12 * 12 = 144 seconds = 2.4 minutes`.

الوقت الإجمالي التوضيحي هو `48 seconds + 432 minutes + 48 minutes + 2.4 minutes = 483.2 minutes = 8.0533 hours`. المراحل تُضاف لأنها متتابعة. هذا ليس توقعًا من نوع Ethereum: القواعد الحقيقية يمكن أن تستخدم فترات مختلفة، تقلبات تعتمد على الحالة، تأخيرات دنيا، خوارزميات التمشيط، وافتراضات الحسم.

### الصف القائم على الوزن بسعة متغيرة

افترض وحدات فعالة `work_ahead = 50,000`، يمثل هذا الخروج `own_work = 320`، و`capacity_per_epoch = 640` الأولية. مع القدرة الثابتة:

`ceil((50,000 + 320) / 640) = ceil(78.625) = 79 epochs`.

في `6 minutes` لكل عصر، أي `79 * 6 = 474 minutes = 7.9 hours`. لكن افترض أن القدرة تنخفض إلى `512` بعد العصر 30. تعالج العصور 30 الأولى `30 * 640 = 19,200`، تاركة `50,320 - 19,200 = 31,120`. الباقي يستغرق `ceil(31,120 / 512) = 61 epochs`، لذا فإن الإجمالي المعدل هو `30 + 61 = 91 epochs = 9.1 hours`. يجب أن تعيد التقديرات الحية حساب القدرة والترتيب بدلاً من تثبيت معدل لوحة بيانات واحدة.

### تسوية الرصيد من خلال الخروج

يبدأ المحقق التوضيحي بوحدات `32`، ويكسب `0.40` قبل انتهاء الرسوم، ويتكبد `0.05` من العقوبات العادية، ولاحقًا يحصل على تخفيض قدره `1.20` يُعزى إلى نافذة التعرض الخاصة بالبروتوكول. المبلغ المتاح قبل أي رسوم مزود أو ضريبة هو:

`32 + 0.40 - 0.05 - 1.20 = 31.15 units`.

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

### مطالبة سائلة مقابل الاسترداد في الطابور

افترض أن رموز التخزين السائل `100` يمكن بيعها الآن بوحدات أصلية `0.965` لكل منها، مما يحقق:

`100 * 0.965 = 96.5 units`.

يقوم مزود بدلاً من ذلك بعرض الاسترداد بوحدة أصلية واحدة لكل رمز بعد قائمة انتظار مع رسوم `0.2%`، أو `100 * (1 - 0.002) = 99.8 units`. الفرق هو `99.8 - 96.5 = 3.3 units`، والخصم للبيع الفوري مقارنة بالعائدات المدرجة في قائمة الانتظار هو `3.3 / 99.8 = 3.3066%`. تعوض الفجوة بوحدة 3.3 عن الوقت وعدم اليقين والسيولة فقط في هذه اللقطة؛ يمكن أن يؤدي التخفيض، أو تغييرات سعر الصرف، أو فقدان العقد، أو توقف قائمة الانتظار إلى تغيير العائدات لاحقًا.

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

## المخاطر وفشل المراجعة

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

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

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

### هل يعني تقديم الخروج أن مهام المدقق تتوقف فورًا؟

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

### هل يعني القابل للسحب أن المحفظة المستهدفة قد تم إضافة الرصيد إليها؟

لا. عادةً ما يصف `withdrawable` الأهلية. قد يحتاج البروتوكول لا يزال إلى مسح المدقق، قد يحتاج المستخدم إلى المطالبة، قد يحتاج الحساب إلى سحب صريح، أو قد يحتاج المزود إلى الإفراج عن مسئوليته. تحقق من رصيد الوجهة.

### هل يمكن لطول الطابور مقسومًا على معدل اليوم أن يعطي تاريخًا دقيقًا؟

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

### هل يؤدي بيع رمز الستاكينغ السائل إلى تجاوز طابور الخروج؟

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

### هل الفترة المعلنة للفك أو السحب مضمونة كحد أقصى؟

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

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

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

- [المدقق](/ar/crypto/validator/)
- [القطع](/ar/crypto/slashing/)
- [التخزين بالتثبيت](/ar/crypto/staking/)
- [التخزين السائل](/ar/crypto/liquid-staking/)
- [إعادة الرهن](/ar/crypto/restaking/)

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

## المصادر

- [سحوبات الرهن](https://ethereum.org/staking/withdrawals/) - Ethereum.org (تم الوصول إليه: 2026-08-19)
- [مواصفات الإجماع Ethereum: سلسلة المنارة](https://github.com/ethereum/consensus-specs/blob/master/specs/phase0/beacon-chain.md) - Ethereum Foundation (تم الوصول إليه: 2026-08-19)
- [مواصفات الإجماع Ethereum: كابيلا](https://github.com/ethereum/consensus-specs/blob/master/specs/capella/beacon-chain.md) - Ethereum Foundation (تم الوصول إليه: 2026-08-19)
- [مواصفات اتفاقية Ethereum: إليكترا](https://github.com/ethereum/consensus-specs/blob/master/specs/electra/beacon-chain.md) - Ethereum Foundation (تم الوصول إليه: 2026-08-19)
- [EIP-7002: عمليات السحب القابلة للتنفيذ من طبقة التنفيذ](https://eips.ethereum.org/EIPS/eip-7002) - Ethereum Improvement Proposals (تم الوصول إليه: 2026-08-19)
- [Cosmos SDK وحدة x/التخزين](https://docs.cosmos.network/sdk/v0.50/build/modules/staking/README) - Cosmos SDK (تم الوصول إليه: 2026-08-19)
- [Stake Accounts](https://solana.com/docs/references/staking/stake-accounts) - Solana Foundation (تم الوصول إليه: 2026-08-19)
- [EigenLayer مدير التفويض](https://github.com/Layr-Labs/eigenlayer-contracts/blob/main/docs/core/DelegationManager.md) - Eigen Labs (تم الوصول إليه: 2026-08-19)

Source: https://wiki.fcontext.com/ar/crypto/validator-exit-withdrawal-queue/index.mdx