---
title: "مخاطر لجنة توافر البيانات (DAC)"
description: "دليل يبدأ بالتحقق من تصديقات DAC وقواعد قبول q-of-n والحيازة والاسترجاع الفعليين للبيانات ومجالات الفشل المترابطة وتدوير المفاتيح والاحتفاظ والرجوع والخروج."
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.

# مخاطر لجنة توافر البيانات (DAC)

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

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

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

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

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

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

## آلية العمل

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

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

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

- **حيوية العتبة وسلامتها ليستا الشيء نفسه.** في لجنة توضيحية `5-of-7`، يترك عضوان غير متاحين `5` موقّعين فتظل الشهادة الجديدة ممكنة؛ ويترك ثلاثة أعضاء `4`، لذلك `4 < 5` ويتوقف إنتاج الشهادات ما لم ينطبق رجوع موثق. وفي المقابل، قد تفي السيطرة على `5` مفاتيح مقبولة بقاعدة العتبة؛ لكن الشهادة لا تثبت استرجاع البايتات حاليًا أو صحة التنفيذ.
- **نموذج الاستقلال والاتصال.** افترض، كنموذج IID توضيحي فقط، أن كلًا من `7` أعضاء متاح مستقلًا باحتمال `0.95` وأن الشهادة تحتاج إلى `5` على الأقل. عندئذ `P(quorum) = sum(C(7,k) * 0.95^k * 0.05^(7-k), k=5..7) = 0.9962429570`، واحتمال التوقف في النموذج `1 - 0.9962429570 = 0.0037570430`. تبطل تبعيات السحابة أو البرامج أو المشغل أو القانون أو المفاتيح المشتركة هذا التقدير الثنائي.
- **نسخ التخزين والخدمة منفصلتان.** حجم الدفعة `120 MB`. تخزن سبع نسخ مستقلة كاملة `120 * 7 = 840 MB`؛ وإذا كان ثلاثة أعضاء فقط يحفظونها فعليًا فالبايتات المخزنة `120 * 3 = 360 MB` حتى إن وقعت خمسة مفاتيح. إرسال الكائن مرة إلى `100 clients` ينقل `120 * 100 = 12,000 MB`، لذا لا يمثل عدد التوقيعات عدد النسخ ولا مقياس سعة الإرسال.
- **عتبة إعادة البناء.** يحتوي كائن توضيحي على `1,024 records` مقسمة إلى `16 chunks` من `64 records`، وعتبة التعافي المعلنة `12 chunks`. تكشف إحدى عشرة قطعة `11 * 64 = 704 records`، لكن `11 < 12` فلا يمكن إعادة بناء الكائن وفق القاعدة. لا تعوض شهادة لجنة صالحة القطعة المفقودة ولا تغير عتبة التعافي.

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

## المخاطر

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

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

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

- زيادة أعضاء اللجنة تعني تلقائيًا زيادة مجالات الفشل المستقلة.
- تثبت توقيعات `q` وجود `q` نسخ كاملة دائمة وقابلة للاسترجاع علنًا.
- يلغي إثبات الصحة الحاجة إلى التحقق من توافر بيانات DAC.
- تضمن شهادة قديمة صالحة الاسترجاع الحالي والأرشفة الدائمة.
- يضمن عضو واحد صادق أو رسمي قدرة كل مستخدم على الخروج دائمًا.

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

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

- [توافر البيانات](/ar/crypto/data-availability/)
- [التجميع](/ar/crypto/rollup/)
- [النهائية](/ar/crypto/finality/)

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

## المصادر

- [Data availability](https://ethereum.org/developers/docs/data-availability/) - Ethereum.org (تاريخ الوصول: 2026-08-13)
- [Validium](https://ethereum.org/developers/docs/scaling/validium/) - Ethereum.org (تاريخ الوصول: 2026-08-13)
- [EIP-7594: PeerDAS - Peer Data Availability Sampling](https://eips.ethereum.org/EIPS/eip-7594) - Ethereum Improvement Proposals (تاريخ الوصول: 2026-08-13)
- [EIP-4844: Shard Blob Transactions](https://eips.ethereum.org/EIPS/eip-4844) - Ethereum Improvement Proposals (تاريخ الوصول: 2026-08-13)
- [Data availability](https://docs.starkware.co/starkex/con_data_availability.html) - StarkEx Documentation (تاريخ الوصول: 2026-08-13)
- [starkex-data-availability-committee](https://github.com/starkware-libs/starkex-data-availability-committee) - StarkWare Industries Ltd. (تاريخ الوصول: 2026-08-13)
- [Arbitrum Nitro: A Second-Generation Optimistic Rollup](https://docs.arbitrum.io/nitro-whitepaper.pdf) - Offchain Labs (تاريخ الوصول: 2026-08-13)
- [SequencerInbox.sol](https://github.com/OffchainLabs/nitro-contracts/blob/main/src/bridge/SequencerInbox.sol) - Offchain Labs (تاريخ الوصول: 2026-08-13)

Source: https://wiki.fcontext.com/ar/crypto/data-availability-committee-risk/index.mdx