تحدي توافر البيانات (DA Challenge)

ما هو تحدي توافر البيانات؟

تحدي توافر البيانات (DA Challenge)، اختصارًا لـ Data Availability Challenge، هو آلية في عالم الكريبتو تتيح للمستخدمين أو مشغلي العقد الاعتراض على مدى توافر البيانات التي تستند إليها كتلة أو دفعة أو التزام في شبكة Rollup.

ببساطة، يطرح تحدي توافر البيانات سؤالًا واحدًا: إذا قال مُسلسِل أو مزود بيانات إن بيانات المعاملات موجودة، فهل يستطيع الآخرون استرجاعها والتحقق من السلسلة فعليًا؟

تكمن أهمية ذلك في أن شبكات Rollup وسلاسل البلوكشين المعيارية تنشر غالبًا التزامات أو قيم هاش أو براهين أو بيانات مضغوطة بدلًا من وضع كل معاملة كاملة مباشرةً على الطبقة الأساسية.

إذا كانت بيانات المعاملات الكاملة مفقودة، فقد يتعذر على المستخدمين التحقق من حالة Rollup أو إعادة بناء السلسلة أو إنشاء براهين الاحتيال أو الخروج بأمان.

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

يصف مواصفات Alt-DA في OP Stack عقدًا لتحدي توافر البيانات، يمكن للمستخدمين من خلاله الاعتراض على التزام خلال فترة تحدٍ محددة، ويمكن لحائزي البيانات حسم التحدي بإرسال البيانات المطلوبة.

تكتسب تحديات توافر البيانات أهمية خاصة في الأنظمة التي تستخدم توافر البيانات البديل، المعروف أيضًا باسم Alt-DA، لأن بيانات المعاملات قد تُخزَّن خارج طبقة التسوية الرئيسية.

وتكتسب أهمية أيضًا في الأنظمة الشبيهة بـ Plasma، وOptimiums، والتصميمات الشبيهة بـ Validium، وهياكل Rollup التي تؤدي فيها خفض تكاليف البيانات إلى افتراضات ثقة إضافية.

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

بل هو آلية دفاع تحاول الحد من مخاطر البيانات المخفية أو المحتجزة أو غير المتاحة.

أهمية تحديات توافر البيانات في الكريبتو

تكتسب تحديات توافر البيانات أهميتها لأن توافر البيانات أحد متطلبات الأمان الأساسية لشبكات Rollup وأنظمة البلوكشين المعيارية.

توضح وثائق Ethereum حول توافر البيانات أن المستخدمين يحتاجون إلى الثقة بإمكانية وصول المشاركين في الشبكة إلى البيانات اللازمة للتحقق من الكتلة.

لا يمكن التحقق من البلوكشين أو Rollup بصورة مستقلة إلا إذا أمكن الوصول إلى بيانات المعاملات ذات الصلة.

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

وهذا يخلق وضعًا خطيرًا قد تبدو فيه السلسلة عاملة بينما يتعذر على المشاركين النزيهين التحقق منها بالكامل.

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

وتوضح وثائق Ethereum حول Optimistic Rollup أن توافر البيانات ضروري، إذ لا يستطيع المعترضون إنشاء براهين احتيال من دون الوصول إلى بيانات الحالة.

أما في شبكات ZK-Rollup، فيظل توافر البيانات مهمًا حتى عندما تؤكد براهين الصلاحية صحة الحسابات، لأن المستخدمين يحتاجون إلى البيانات لمعرفة أرصدتهم وتحديث الحالة المحلية والتفاعل بأمان.

في أنظمة Alt-DA، تُعد تحديات توافر البيانات إحدى وسائل تعزيز المساءلة عندما تُخزَّن البيانات خارج طبقة التسوية الرئيسية.

لذلك، لا تقتصر تحديات توافر البيانات على كونها تفصيلًا تقنيًا يهم المطورين.

فهي تؤثر في سلامة المستخدمين، وضمانات السحب، ونهائية Rollup، وافتراضات الثقة التي تقوم عليها معاملات البلوكشين الأقل تكلفة.

آلية عمل تحدي توافر البيانات

يبدأ تحدي توافر البيانات عادةً عندما يرسل المُسلسِل أو ناشر الدفعات التزامًا ببيانات المعاملات.

قد يكون الالتزام قيمة هاش أو مرجعًا إلى Blob أو جذر Merkle أو شهادة من طبقة توافر البيانات أو تمثيلًا موجزًا آخر للبيانات.

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

إذا تعذر على مستخدم أو عقدة أو جهة مراقبة استرجاع البيانات الأساسية، فقد يبدأ تحدي توافر البيانات.

في تصميم Alt-DA ضمن OP Stack، يُرسل التحدي إلى عقد DataAvailabilityChallenge على Layer 1 خلال فترة تحدٍ محددة.

بعد بدء التحدي، تُمنح جهة أخرى فترة للحسم كي ترسل البيانات المفقودة أو تثبت صحة الالتزام.

إذا أُرسلت البيانات بنجاح، يُحسم التحدي ويمكن للسلسلة مواصلة استخدام الالتزام.

أما إذا لم تُقدَّم البيانات قبل انتهاء فترة الحسم، فقد يُعد الالتزام المتأثر غير صالح، أو قد تحتاج Rollup إلى إعادة تنظيم السلسلة بدءًا من النقطة المتأثرة.

تدفع هذه العملية مزودي البيانات والمسلسِلات إلى إتاحة البيانات.

كما تمنح المشاركين النزيهين وسيلة للتعامل مع اعتماد النظام على بيانات يتعذر جلبها.

تحدي توافر البيانات مقابل توافر البيانات

توافر البيانات هو الضمان العام بأن البيانات اللازمة للتحقق من كتلة أو دفعة أو تحديث حالة قد نُشرت ويمكن استرجاعها.

أما تحدي توافر البيانات فهو آلية محددة لاختبار هذا الضمان أو الاعتراض عليه أو إنفاذه.

وهذا اختلاف مهم.

توافر البيانات هو الهدف.

وتحدي توافر البيانات إحدى الأدوات التي تساعد على حماية هذا الهدف عندما يكون التوافر موضع شك.

قد تعتمد Rollup التي تنشر جميع بيانات المعاملات مباشرةً في calldata أو blobs على Ethereum بدرجة أكبر على ضمانات توافر البيانات التي توفرها Ethereum.

أما Rollup التي تخزن البيانات على طبقة خارجية لتوافر البيانات، فقد تحتاج إلى آليات إضافية لإثبات أن البيانات الخارجية متاحة فعلًا.

يمكن لتحدي توافر البيانات المساعدة في سد هذه الفجوة، إذ يتيح للمستخدمين الاعتراض على الالتزامات التي يتعذر تحويلها إلى بيانات فعلية.

لكن قوة التحدي تعتمد على تصميمه المحدد.

قد يكون نظام التحدي الضعيف مكلفًا للغاية أو بطيئًا أو مركزيًا أو صعب الاستخدام على المستخدمين العاديين.

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

تحدي توافر البيانات مقابل برهان الاحتيال

تحدي توافر البيانات ليس هو نفسه برهان الاحتيال.

يعترض برهان الاحتيال على صحة انتقال الحالة أو نتيجة الحساب.

أما تحدي توافر البيانات فيعترض على توافر البيانات اللازمة للتحقق من تلك النتيجة.

في Rollup المتفائلة، تفترض براهين الاحتيال عادةً أن المعترضين يستطيعون الوصول إلى بيانات المعاملات.

إذا لم تكن بيانات المعاملات متاحة، فقد يتعذر على المعترض حتى إنشاء برهان الاحتيال.

وهذا يعني أن توافر البيانات شرط مسبق في العديد من أنظمة براهين الاحتيال.

يركز تحدي توافر البيانات على مشكلة البيانات المفقودة قبل أن يتمكن النظام أصلًا من مناقشة صحة التنفيذ.

على سبيل المثال، قد ينشر مُسلسِل التزامًا بالحالة يبدو طبيعيًا، بينما تكون بيانات المعاملات الفعلية التي يستند إليها هذا الالتزام غير متاحة.

قد يحتاج برهان الاحتيال إلى بيانات المعاملات لإثبات خطأ الالتزام بالحالة.

أما تحدي توافر البيانات، فيطلب من المُسلسِل أو مزود البيانات كشف البيانات أو مواجهة العواقب.

لذلك، يرتبط تحدي توافر البيانات وبراهين الاحتيال بأمان Rollup، لكنهما يظلان عنصرين منفصلين.

تحدي توافر البيانات مقابل فترة التحدي

قد يُخلط بين مصطلح تحدي توافر البيانات وفترة التحدي العامة المستخدمة في شبكات Rollup المتفائلة.

فترة التحدي هي نافذة زمنية يمكن للمشاركين خلالها الاعتراض على ادعاء متعلق بـ Rollup، عادةً عبر براهين الاحتيال أو آليات ذات صلة.

أما تحدي توافر البيانات فهو أكثر تحديدًا، لأنه يتعلق بتوافر البيانات.

يتضمن إعداد OP Stack حقولًا مثل DAChallengeWindow وDAResolveWindow وDABondSize وDAChallengeProxy لوضع Alt-DA، وذلك ضمن إعداد نشر Rollup.

تشير DAChallengeWindow إلى فترة الكتل التي يمكن خلالها الاعتراض على توافر التزام البيانات.

وتشير DAResolveWindow إلى فترة الكتل التي يمكن خلالها حسم تحدي توافر البيانات.

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

ينبغي للمستخدمين مراجعة الوثائق الدقيقة لشبكة Rollup أو السلسلة التي يستخدمونها.

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

تحدي توافر البيانات وAlt-DA

يشير Alt-DA إلى توافر البيانات البديل.

ويقصد به عادةً تخزين بيانات معاملات Rollup في مكان آخر غير سلسلة التسوية الرئيسية.

تذكر وثيقة شرح وضع Alt-DA في OP Stack أن وضع Alt-DA يتيح لسلاسل OP Stack دمج طبقات مختلفة لتوافر البيانات بهدف خفض تكاليف البيانات.

قد يؤدي انخفاض تكاليف البيانات إلى جعل السلسلة أقل تكلفة للمستخدمين والمشغلين.

لكن انخفاض التكلفة غالبًا ما يأتي مع افتراضات ثقة إضافية.

وتحذر وثائق OP Stack نفسها من أن وضع Alt-DA ينطوي على افتراضات ثقة أكثر من نشر البيانات مباشرةً على Ethereum Layer 1.

يهدف تحدي توافر البيانات إلى الحد من هذه المشكلة بمنح المستخدمين وسيلة للاعتراض على التزام بالبيانات عندما يتعذر الوصول إليها.

على سبيل المثال، إذا أرسل مُسلسِل التزامًا إلى Layer 1 لكنه لم يتيح البيانات الأساسية عبر مزود توافر البيانات، فقد تبدأ عقدة نزيهة تحديًا.

إذا لم يُحسم التحدي، فقد يرفض النظام الالتزام المتأثر أو يعيد تنظيمه.

يساعد ذلك على جعل Alt-DA أكثر أمانًا، لكنه لا يزيل جميع المخاطر.

يظل المستخدمون معتمدين على طبقة توافر البيانات، ومنطق الجسر، وقواعد التحدي، وجهات مراقبة البيانات، والحوافز الاقتصادية التي تحافظ على نشاط المعترضين.

تحدي توافر البيانات وEthereum Blobs

قدمت Ethereum معاملات تحمل Blobs عبر EIP-4844، المعروف أيضًا باسم Proto-Danksharding.

تذكر مواصفات EIP-4844 الرسمية أن معاملات Shard Blob توسع نطاق توافر البيانات في Ethereum بطريقة بسيطة ومتوافقة مع التحديثات المستقبلية.

توفر Blobs لشبكات Rollup وسيلة أقل تكلفة لنشر بيانات المعاملات على Ethereum مقارنةً بالتصميمات الأقدم التي تعتمد بكثافة على calldata.

وتوضح وثائق Dencun في Ethereum أن تحديث Dencun فعّل Proto-Danksharding وقدم Blobs مؤقتة للبيانات بهدف خفض تكاليف تخزين Rollup.

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

هذا لا يعادل نظام تحدي Alt-DA، لكنه جزء من النقاش الأوسع نفسه حول توافر البيانات.

تعتمد شبكات Rollup التي تستخدم Ethereum Blobs على ضمانات التوافر على مستوى بروتوكول Ethereum خلال نافذة توافر Blob.

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

يكمن الاختلاف الأساسي في مكان نشر البيانات والجهة التي تضمن إمكانية استرجاعها.

يصبح تحدي توافر البيانات مهمًا على نحو خاص عندما يتعذر على النظام الاعتماد ببساطة على توافر Blob الأصلي في Ethereum للبيانات المعنية.

تحدي توافر البيانات وهجمات حجب البيانات

يحدث هجوم حجب البيانات عندما ينشر طرف التزامًا ببيانات لكنه لا يكشف البيانات نفسها.

وهذا أحد المخاطر الرئيسية التي صُممت تحديات توافر البيانات لمعالجتها.

قد يحاول مُسلسِل خبيث نشر التزام يسمح للسلسلة بالتقدم، مع منع العقد النزيهة من إعادة بناء الحالة.

إذا تعذر على العقد النزيهة الوصول إلى البيانات، فقد لا تتمكن من معرفة ما إذا كانت السلسلة صالحة.

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

يوفر تحدي توافر البيانات مسارًا علنيًا للاعتراض.

يعلن المعترض أن البيانات التي يستند إليها الالتزام غير متاحة.

وعندئذ، يتعين على مزود البيانات أو المُسلسِل أو مشارك آخر كشف البيانات أو إثبات إمكانية استرجاعها من الالتزام.

إذا ظلت البيانات غير متاحة، يمكن للنظام اعتبار الالتزام غير آمن أو غير صالح وفق قواعده.

لا يجعل ذلك حجب البيانات مستحيلًا، لكنه يجعل الهجوم أكثر وضوحًا وأعلى كلفة.

تعتمد فعالية الآلية على وجود جهات مراقبة، ومعقولية تكلفة التحدي، واستجابة البروتوكول الصحيحة عند عدم حسم توافر البيانات.

تحدي توافر البيانات ونهائية Rollup

قد تصبح نهائية Rollup أكثر تعقيدًا عندما يعتمد توافر البيانات على أنظمة خارجية.

قد تبدو الكتلة آمنة بسبب نشر التزام، لكن ذلك لا يعني دائمًا أن البيانات الأساسية آمنة بشكل دائم.

توضح مواصفات Alt-DA في OP Stack أن الكتل المشتقة من بيانات إدخال مرتبطة بالتزامات قد توصف بأنها آمنة، لكنها تظل معرضة لإعادة التنظيم إذا تعطل مزود توافر البيانات؛ لذلك ينبغي للمستخدمين الاعتماد على حالة «نهائي» للحصول على ضمانات أقوى.

هذا التمييز مهم للمستخدمين والتطبيقات.

إذا أمكن إعادة تنظيم السلسلة بعد عدم حسم تحدي توافر البيانات، فقد تُزال لاحقًا من السلسلة المعتمدة معاملة بدت مقبولة.

ينبغي ألا تفترض التطبيقات أن كل كتلة مشتقة حديثًا نهائية بالطريقة نفسها.

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

والخلاصة البسيطة للمستخدمين هي أن السلاسل الأسرع والأقل تكلفة قد تنطوي على افتراضات نهائية أكثر تعقيدًا.

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

ضمانات تحدي توافر البيانات

تستخدم أنظمة كثيرة لتحدي توافر البيانات ضمانات لمنع الرسائل غير المرغوب فيها وهجمات حجب الخدمة.

والضمان مبلغ من القيمة يتعين على المعترض إيداعه عند بدء التحدي.

يثني الضمان المستخدمين عن الاعتراض على كل التزام دون سبب.

تنص مواصفات Alt-DA في OP Stack على أن عقد تحدي توافر البيانات يمكن أن يشترط ضمانًا قابلًا للدفع، بحيث تكون كلفة التحدي مساوية على الأقل لكلفة إرسال البيانات على السلسلة لحسمه.

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

لكن الضمانات تنطوي أيضًا على مفاضلة.

إذا كان الضمان منخفضًا جدًا، فقد يصبح النظام عرضة للرسائل غير المرغوب فيها.

وإذا كان مرتفعًا جدًا، فقد يعجز المعترضون النزيهون عن تحمل تكلفة الاعتراض على البيانات غير المتاحة.

يجب أن يوازن نظام تحدي توافر البيانات بين الأمان الاقتصادي وسهولة الوصول.

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

حسم تحدي توافر البيانات

الحسم هو عملية الرد على تحدي توافر البيانات.

في تصميم بسيط، يرسل الطرف الذي يحسم التحدي البيانات المفقودة مباشرةً على السلسلة بصيغة calldata.

بعد ذلك، يمكن للعقد التحقق من مطابقة البيانات المرسلة للالتزام الأصلي.

إذا تطابقت، يُحسم التحدي.

أما إذا لم تتطابق، أو لم تُرسل بيانات صالحة في الوقت المحدد، فقد تنتهي فترة التحدي من دون حسم.

يمكن لبعض التصميمات استخدام أنظمة براهين أكثر تقدمًا بدلًا من نشر جميع البيانات مباشرةً على السلسلة.

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

تصف مقالة ZK DA Bridge من Eclipse تصميمًا يفصل براهين توافر البيانات عن براهين الاحتيال ويتولى معالجتها نظام فرعي لتحدي توافر البيانات.

يوضح ذلك كيف يمكن أن يصبح تصميم تحديات توافر البيانات معياريًا.

ويظل الهدف الأساسي واحدًا: إثبات توافر البيانات أو إثبات عدم وجوب الوثوق بالتزام ما.

تحدي توافر البيانات وجهات المراقبة

جهة المراقبة هي مشارك يراقب السلسلة بحثًا عن بيانات مفقودة أو التزامات غير صالحة أو سلوك مريب أو تحديات لم تُحسم.

تعتمد تحديات توافر البيانات بدرجة كبيرة على جهات المراقبة، إذ يجب أن يلاحظ أحدهم عدم توافر البيانات ويبدأ التحدي.

إذا لم يراقب أحد السلسلة، فقد توجد آلية التحدي نظريًا لكنها تفشل عمليًا.

يشبه ذلك افتراض وجود معترض نزيه واحد في بعض الأنظمة المتفائلة، لكن اقتصاديات تحديات توافر البيانات قد تختلف.

تناقش مقالة Universal Plasma and DA challenges على Ethereum Research أهمية المعترضين النزيهين على توافر البيانات وتكلفتهم في الأنظمة الشبيهة بـ Plasma.

قد تكون جهات المراقبة مستخدمين مستقلين أو مشغلي عقد أو فرق بنية تحتية أو باحثين في الأمن أو مؤسسات أو خدمات مراقبة متخصصة.

ينبغي لنظام تحدي توافر البيانات السليم أن يتيح عمليًا لأكثر من طرف مراقبة السلسلة.

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

لا يقتصر السؤال الأساسي للمستخدمين على وجود عقد لتحدي توافر البيانات.

بل يتمثل السؤال في امتلاك الجهات المراقبة النزيهة الأدوات والحوافز والأموال اللازمة لاستخدامه عند الحاجة.

تحدي توافر البيانات والمسلسِلات

المُسلسِل هو المكوّن الذي يرتب المعاملات وينتج دفعات في العديد من أنظمة Rollup.

وتكمن أهميته في تحديد المعاملات التي تدخل Rollup والترتيب الذي تُدرج به.

عندما تستخدم Rollup توافر بيانات خارجيًا، قد يرسل المُسلسِل أو ناشر الدفعات التزامًا ببيانات المعاملات بدلًا من وضع جميع البيانات كاملةً مباشرةً على سلسلة التسوية.

إذا تصرف المُسلسِل بأمانة، فإنه يتيح البيانات عبر طبقة توافر البيانات أو الخادم المتوقع.

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

يمثل تحدي توافر البيانات وسيلة للتحقق من هذا السلوك.

فهو يتيح للمستخدمين الاعتراض على أن التزام المُسلسِل غير كافٍ، لأن استرجاع البيانات الفعلية غير ممكن.

وقد يحمي ذلك السلسلة من التقدم اعتمادًا على بيانات غير متاحة.

لكن تحدي توافر البيانات لا يعالج جميع مخاطر المُسلسِل.

فقد تظل هناك مخاطر الرقابة وترتيب المعاملات والتوقف ومخاوف MEV، وفقًا لتصميم النظام.

تحدي توافر البيانات ولجان توافر البيانات

تستخدم بعض أنظمة التوسع لجنة لتوافر البيانات، يُشار إليها غالبًا باسم DAC.

وهي مجموعة من الأطراف تتعهد بتخزين بيانات المعاملات أو توفيرها.

يمكن للجان توافر البيانات خفض التكاليف، إذ لا يلزم نشر البيانات كاملةً على طبقة التسوية.

لكنها تضيف افتراضات ثقة، لأن المستخدمين يعتمدون على أعضاء اللجنة للحفاظ على توافر البيانات.

يمكن استخدام تحدي توافر البيانات كإحدى وسائل مساءلة اللجنة أو مزود البيانات.

إذا ادعت اللجنة أن البيانات متاحة بينما يتعذر على المستخدمين استرجاعها، فيمكن للتحدي كشف هذا الإخفاق.

يدرس بحث حديث حول المسلسِلات الآمنة ولجان توافر البيانات لشبكات Rollup آليات براهين الاحتيال في مواجهة سلوك المسلسِلات ولجان توافر البيانات غير النزيه.

ويكتسب هذا الاتجاه البحثي أهمية لأن العديد من تصميمات Rollup تتجه إلى أنظمة بيانات أقل تكلفة ذات افتراضات أمان أكثر تعقيدًا.

قد تكون لجنة توافر البيانات مفيدة، لكن ينبغي للمستخدمين السؤال عن هوية أعضائها، وعدد الأعضاء الذين يجب أن يكونوا نزيهين، وطريقة التحقق من البيانات، ووجود تحدٍ لتوافر البيانات.

تحدي توافر البيانات وValidium

Validium تصميم للتوسع يستخدم براهين الصلاحية، لكنه يحتفظ ببيانات المعاملات خارج طبقة التسوية.

قد يجعل ذلك Validium أقل تكلفة من شبكات Rollup التي تنشر جميع بيانات المعاملات على طبقة أساسية.

لكن توافر البيانات خارج السلسلة يؤدي إلى نمط مختلف من المخاطر.

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

يمكن لتحدي توافر البيانات دعم الأنظمة الشبيهة بـ Validium عبر توفير وسيلة للاعتراض على البيانات المفقودة.

ولا يغير التحدي حقيقة وجود البيانات خارج السلسلة.

بل يضيف آلية يمكنها فرض الكشف عن البيانات أو إبطال الالتزامات غير المتاحة أو تفعيل قواعد بديلة.

ينبغي للمستخدمين إدراك أن Validium وOptimium والسلاسل الشبيهة بـ Plasma وشبكات Rollup التي تستخدم Alt-DA قد توفر ضمانات مختلفة لتوافر البيانات.

ولا يكفي اسم التصميم وحده.

السؤال الفعلي هو كيفية إتاحة البيانات وما الذي يحدث عند تعذر ذلك.

تحدي توافر البيانات وOptimium

يُستخدم مصطلح Optimium غالبًا لوصف نظام شبيه بـ Rollup متفائلة يستخدم توافر بيانات خارج السلسلة أو بديلًا عنه، بدلًا من نشر جميع البيانات مباشرةً على طبقة التسوية.

قد تخفض Optimium التكاليف، لكنها قد تعتمد على مزودي توافر البيانات أو اللجان أو أنظمة التحدي لضمان التوافر.

يكتسب تحدي توافر البيانات أهمية في التصميمات الشبيهة بـ Optimium، لأن براهين الاحتيال لا تعمل إلا عندما تكون البيانات اللازمة للبرهان متاحة.

إذا حُجبت البيانات، فقد يتعذر على نظام براهين الاحتيال اكتشاف المشكلة أو إثباتها.

يحاول تحدي توافر البيانات معالجة مشكلة البيانات المفقودة قبل أن تقوض أمان Rollup.

لكن ينبغي للمستخدمين توخي الحذر عند تقييم Optimium، لأن نموذج الأمان فيها لا يماثل نموذج Rollup التي تنشر جميع بياناتها على Ethereum.

قد تكون الرسوم المنخفضة جذابة، لكن ينبغي موازنتها بمخاطر توافر البيانات وافتراضات الجسر وحوافز التحدي وسلوك النهائية.

تحدي توافر البيانات والأنظمة الشبيهة بـ Plasma

تُبقي الأنظمة الشبيهة بـ Plasma قدرًا أكبر من البيانات خارج السلسلة وتعتمد على آليات الخروج أو التحدي أو البراهين لحماية المستخدمين.

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

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

تشير مناقشة Ethereum Research حول Universal Plasma وتحديات توافر البيانات إلى أن هذه الأنظمة قد تتطلب وجود معترض نشط واحد على الأقل على توافر البيانات في أي وقت.

ويُعد شرط وجود جهة مراقبة نشطة مهمًا لسلامة المستخدمين.

قد يبدو النظام الشبيه بـ Plasma سريعًا ومنخفض التكلفة، لكن على المستخدمين فهم ما يحدث إذا اختفت البيانات.

إذا لم يتمكن المعترضون النزيهون من تحمل تكلفة مواصلة الاعتراض، أو لم يكن المستخدمون متصلين خلال نوافذ الخروج، فقد يضعف نموذج الأمان.

لهذا السبب، تُناقش تحديات توافر البيانات بوصفها آلية تقنية واقتصادية في آن واحد.

يجب أن يكون النظام صحيحًا من الناحية التقنية وقابلًا للاستخدام من الناحية الاقتصادية.

تحدي توافر البيانات وعمليات سحب المستخدمين

قد يتأثر السحب بتوافر البيانات.

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

وهذا أحد أسباب أهمية تحديات توافر البيانات لحماية المستخدمين.

يمكن لتحدي توافر البيانات منع Rollup أو نظام شبيه بـ Plasma من اعتماد بيانات غير متاحة قد تجعل عمليات السحب غير آمنة.

لكن تأثير ذلك في السحب يعتمد على تصميم السلسلة.

قد تتيح بعض الأنظمة عمليات خروج طارئة.

وقد تعيد أنظمة أخرى تنظيم السلسلة بدءًا من الالتزام غير المتاح.

وقد تشترط أنظمة أخرى انتظار انتهاء نافذة التحدي.

وقد تعتمد بعض الأنظمة على لجنة توافر بيانات أو جسر أو نظام براهين لتأكيد التوافر.

ينبغي للمستخدمين قراءة وثائق السحب الخاصة بالسلسلة قبل افتراض أن جميع عمليات السحب من Layer 2 توفر ضمانات السلامة نفسها.

تحدي توافر البيانات وإعادة تنظيم L2

تحدث إعادة التنظيم (reorg) عندما تستبدل السلسلة جزءًا من سجلها المقبول سابقًا بسجل معتمد مختلف.

في نظام تحدي توافر البيانات، قد يؤدي تحدٍ لم يُحسم إلى رفض الكتل المشتقة من بيانات غير متاحة أو إعادة تنظيمها.

توضح مواصفات Alt-DA في OP Stack أن انتهاء تحدٍ دون حسم قد يؤدي إلى إعادة تنظيم سلسلة L2 المعتمدة بدءًا من أول كتلة مشتقة من بيانات الإدخال التي خضعت للتحدي.

وهذه استجابة قوية، لأنها تمنع السلسلة من البناء بشكل دائم على بيانات تعذر على المشاركين النزيهين التحقق منها.

لكن إعادة التنظيم قد تؤثر أيضًا في التطبيقات والمستخدمين.

فقد تختفي معاملة بدت مدرجة إذا كانت ضمن النطاق المتأثر.

وقد تحتاج التطبيقات إلى انتظار مستوى أقوى من النهائية قبل إضافة الأرصدة أو معالجة عمليات السحب أو تنفيذ إجراءات عالية القيمة.

لذلك، يجب أن تفهم المحافظ والجسور ومستكشفات البلوكشين والمطورون أنظمة تحدي توافر البيانات بوضوح.

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

تحدي توافر البيانات ومخاطر حجب الخدمة

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

قد يغرق المهاجم النظام بتحديات لإجبار مزودي البيانات أو المسلسِلات أو العقود على استهلاك الموارد.

لهذا السبب، تكتسب ضمانات التحدي وتكاليف الحسم أهمية.

تناقش مواصفات Alt-DA في OP Stack فرض ضمان قابل للدفع للحد من مخاطر حجب الخدمة.

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

من الصعب تحديد قيمة الضمان لأن رسوم البلوكشين تتغير بمرور الوقت.

إذا ارتفعت الرسوم، فقد يصبح الضمان المعقول سابقًا منخفضًا جدًا أو مرتفعًا جدًا.

إذا تطلب التحدي إرسال كمية كبيرة من calldata، فقد يصبح الحسم مكلفًا خلال فترات ارتفاع الرسوم.

يجب أن يراعي التصميم الجيد تقلب الرسوم والحد الأقصى لأحجام الإدخال وقواعد استرداد الأموال والحوافز الاقتصادية.

لا يقتصر الأمان هنا على علم التشفير.

بل يتعلق أيضًا بملاءمة الجوانب الاقتصادية في الظروف الضاغطة.

تحدي توافر البيانات وتكاليف السلسلة

قد تترتب على تحديات توافر البيانات تكاليف على السلسلة، لأن التحدي وحسمه قد يتطلبان معاملات على Layer 1.

إذا وجب إرسال البيانات المفقودة مباشرةً بصيغة calldata، فقد يدفع الطرف الذي يحسم التحدي رسوم غاز كبيرة.

وهذا أحد أسباب استكشاف بعض الأنظمة جسور توافر البيانات أو الشهادات أو براهين المعرفة الصفرية لخفض تكاليف الحسم على السلسلة.

يناقش تصميم ZK DA Bridge من Eclipse استخدام أنظمة البراهين لخفض تكاليف التحقق عند فحص توافر البيانات عبر الأنظمة.

النقطة المهمة للمستخدمين هي أن أمان توافر البيانات له تكلفة.

فنشر جميع البيانات مباشرةً على طبقة أساسية آمنة مكلف.

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

لا يوجد تصميم بلا تكلفة.

يختار كل نظام موضع التكلفة: تكاليف نشر البيانات أو تكاليف المراقبة أو التحدي أو تعقيد الجسور أو افتراضات الثقة الإضافية.

تحدي توافر البيانات وأخذ عينات توافر البيانات

أخذ عينات توافر البيانات (DAS) وسيلة أخرى لتعزيز الثقة بتوافر البيانات من دون أن تضطر كل عقدة إلى تنزيلها بالكامل.

توضح خارطة طريق Danksharding في Ethereum أن أخذ عينات توافر البيانات ضروري لتمكين المدققين من التحقق من بيانات Blob بكفاءة.

يرتبط DAS بتحديات توافر البيانات، لكنهما ليسا الشيء نفسه.

يساعد DAS المشاركين على التحقق من التوافر عبر أخذ عينات عشوائية.

أما تحدي توافر البيانات فهو عملية نزاع تُستخدم عند ظهور مؤشرات على عدم توافر البيانات أو تعذر استرجاعها.

قد تجمع بعض الأنظمة المستقبلية بين أخذ العينات والالتزامات والبراهين والجسور والتحديات.

والهدف هو خفض تكاليف البيانات من دون إجبار المستخدمين على الوثوق بمُسلسِل أو مزود بيانات واحد.

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

يمكن لكلتا الآليتين دعم توسيع أكثر أمانًا إذا صُممتا جيدًا.

فوائد تحدي توافر البيانات

الفائدة الأولى لتحدي توافر البيانات هي تعزيز المساءلة.

فهو يمنح المستخدمين وسيلة للاعتراض على التزام بالبيانات بدلًا من الثقة العمياء بالمُسلسِل أو مزود توافر البيانات.

والفائدة الثانية هي تعزيز سلامة Rollup.

إذا أمكن أن يؤدي عدم توافر البيانات إلى الرفض أو إعادة التنظيم، تقل احتمالية اعتماد السلسلة سجلًا لا يمكن التحقق منه.

والفائدة الثالثة هي التوسع بتكلفة أقل.

يمكن لتحدي توافر البيانات دعم تصميمات Alt-DA التي تخفض تكاليف نشر البيانات مع إضافة آلية للنزاع.

والفائدة الرابعة هي التصميم المعياري.

يمكن فصل مسائل توافر البيانات عن منطق التنفيذ وبراهين الاحتيال، بما يسمح بتخصص كل جزء من النظام.

والفائدة الخامسة هي تحسين الشفافية.

يمكن فحص عقود التحدي ونوافذه وضماناته وعمليات حسمه على السلسلة عندما يعتمد النظام على عقود علنية.

والفائدة السادسة هي حماية المستخدمين.

عندما تعمل الآلية كما ينبغي، تساعد على منع احتجاز المستخدمين في حالة سلسلة يتعذر التحقق منها.

مخاطر تحدي توافر البيانات

الخطر الأول هو إخفاق جهات المراقبة.

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

والخطر الثاني هو ارتفاع تكلفة التحدي.

إذا كان الاعتراض مكلفًا للغاية، فقد يتعذر على المستخدمين العاديين استخدام النظام.

والخطر الثالث هو الرسائل غير المرغوب فيها أو حجب الخدمة.

إذا كانت تكلفة التحدي منخفضة جدًا، فقد يغرق المهاجمون النظام بتحديات زائفة.

والخطر الرابع هو استمرار الاعتماد على البيانات الخارجية.

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

والخطر الخامس هو تعقيد النهائية.

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

والخطر السادس هو حالة التنفيذ.

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

والخطر السابع هو سيطرة الحوكمة.

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

كيفية تقييم المستخدمين لنظام تحدي توافر البيانات

ينبغي للمستخدمين أولًا التحقق مما إذا كانت السلسلة تستخدم بيانات Ethereum أو طبقة خارجية لتوافر البيانات أو لجنة لتوافر البيانات أو نظامًا آخر للبيانات.

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

كما ينبغي التحقق من نافذة التحدي ونافذة الحسم.

وينبغي معرفة الجهات التي تستطيع بدء التحدي.

ويجب التحقق مما إذا كانت التحديات تتطلب ضمانًا وقيمة هذا الضمان.

كما ينبغي التحقق مما يحدث عند حسم التحدي.

ويجب معرفة ما يحدث عند انتهاء التحدي دون حسم.

وينبغي التحقق مما إذا كان النظام يستطيع إعادة تنظيم كتل L2 بعد اكتشاف بيانات غير متاحة.

كما يجب التأكد من أن المحافظ والجسور والتطبيقات تنتظر مستوى النهائية المناسب.

وينبغي التحقق مما إذا كانت جهات مراقبة مستقلة أو مشغلو عقد يراقبون السلسلة فعلًا.

لا يكون تحدي توافر البيانات مفيدًا إلا إذا كان النظام المحيط به عمليًا وتتم مراقبته وإنفاذ قواعده.

كيف ينبغي للمطورين التفكير في تحديات توافر البيانات

ينبغي للمطورين اعتبار تحديات توافر البيانات جزءًا من نموذج أمان التطبيق.

إذا كان تطبيق لامركزي (DApp) يعمل على سلسلة تستخدم Alt-DA، فعلى المطور فهم ضمانات توافر البيانات في تلك السلسلة.

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

على بروتوكول DeFi مراعاة ما إذا كانت عمليات إعادة التنظيم الناجمة عن إخفاقات توافر البيانات قد تؤثر في الإيداعات أو التداولات أو القروض أو التصفية.

قد يتحمل تطبيق ألعاب أو تطبيق اجتماعي نهائية أكثر مرونة مقارنةً بسوق إقراض عالي القيمة.

وينبغي للمطورين أيضًا معرفة قدرة بنيتهم التحتية على التعامل مع الأحداث المرتبطة بالتحديات.

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

ينبغي ألا تتعامل التطبيقات مع كل سلسلة منخفضة التكلفة كما لو كانت تملك خصائص الأمان نفسها التي تتمتع بها Rollup تنشر بياناتها مباشرةً على Ethereum.

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

مفاهيم خاطئة شائعة حول تحديات توافر البيانات

من المفاهيم الخاطئة أن تحدي توافر البيانات يثبت صحة كل معاملة.

وهذا غير صحيح.

فهو يتناول فقط مدى توافر البيانات التي يستند إليها الالتزام.

ومن المفاهيم الخاطئة أيضًا أن تحدي توافر البيانات هو نفسه برهان الاحتيال.

يعترض برهان الاحتيال على صحة التنفيذ، بينما يعترض تحدي توافر البيانات على توافر البيانات.

وثمة مفهوم خاطئ ثالث مفاده أن أي سلسلة تستخدم تحدي توافر البيانات تتمتع بأمان سلسلة تنشر جميع بياناتها على Ethereum.

وهذا غير صحيح، لأن أنظمة Alt-DA تظل تضيف افتراضات ثقة تتعلق بطبقة توافر البيانات والجسر وعملية التحدي وجهات المراقبة.

ومن المفاهيم الخاطئة الرابعة أن توافر البيانات يعني تخزينها إلى الأبد.

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

والمفهوم الخاطئ الخامس هو أن المستخدمين لا يحتاجون إلى الاهتمام بتحديات توافر البيانات.

ينبغي للمستخدمين الاهتمام بها، لأن إخفاقات توافر البيانات قد تؤثر في السحب والنهائية والتحقق وسلامة الأصول.

تحدي توافر البيانات والتخزين طويل الأجل

تحدي توافر البيانات ليس نظامًا للأرشفة طويلة الأجل.

فهو يركز على ما إذا كانت البيانات متاحة عند حاجة النظام إليها للتحقق والسلامة.

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

وهذا التمييز مهم لشبكات Rollup وسلاسل Alt-DA.

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

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

ولا يحل تحدي توافر البيانات وحده دائمًا مشكلة استرجاع البيانات على المدى الطويل.

ينبغي للمطورين التخطيط للتخزين التاريخي بصورة منفصلة.

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

تحدي توافر البيانات ونية البحث عبر AEO

غالبًا ما يرغب الباحثون عن تحدي توافر البيانات في فهم مخاطر توافر البيانات في شبكات Rollup وأنظمة Alt-DA وسلاسل البلوكشين المعيارية.

والإجابة المختصرة هي أن تحدي توافر البيانات وسيلة للاعتراض على مدى توافر بيانات Rollup التي يستند إليها التزام ما.

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

تشمل المصطلحات ذات الصلة: توافر البيانات، وAlt-DA، وRollup، والمُسلسِل، وبرهان الاحتيال، وValidium، وOptimium، وهجوم حجب البيانات، ونافذة التحدي، ونافذة الحسم، وأخذ عينات توافر البيانات.

يساعد الفهم الجيد لتحديات توافر البيانات المستخدمين على مقارنة أمان أنظمة Layer 2 والبلوكشين المعيارية المختلفة.

كما يساعد المطورين على تحديد ما إذا كانت الرسوم الأقل في سلسلة ما تستحق المفاضلات المتعلقة بتوافر البيانات.

تكتسب تحديات توافر البيانات أهميتها لأن توسيع نطاق البلوكشين لم يعد يقتصر على تسريع التنفيذ.

بل يتعلق أيضًا بضمان بقاء البيانات التي يستند إليها التنفيذ قابلة للتحقق.

الأسئلة الشائعة

ماذا يعني تحدي توافر البيانات؟

تحدي توافر البيانات هو آلية للاعتراض على مدى توافر البيانات التي يستند إليها التزام في بلوكشين أو Rollup.

لماذا يُعد تحدي توافر البيانات مهمًا؟

هو مهم لأن المستخدمين والعقد يحتاجون إلى بيانات المعاملات للتحقق من حالة Rollup، وإنشاء براهين الاحتيال، والتفاعل مع السلسلة بأمان.

هل تحدي توافر البيانات هو نفسه برهان الاحتيال؟

لا. يعترض تحدي توافر البيانات على توافر البيانات، بينما يعترض برهان الاحتيال على صحة انتقال الحالة أو الحساب.

من يستطيع بدء تحدي توافر البيانات؟

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

ما نافذة تحدي توافر البيانات؟

هي الفترة الزمنية أو فترة الكتل التي يمكن خلالها الاعتراض على التزام بالبيانات.

ما نافذة حسم تحدي توافر البيانات؟

هي الفترة الزمنية أو فترة الكتل التي يجب خلالها إرسال البيانات المفقودة أو البرهان لحسم التحدي.

ماذا يحدث إذا لم يُحسم تحدي توافر البيانات؟

بحسب النظام، قد يُرفض الالتزام المتأثر أو تعيد السلسلة تنظيم نفسها أو تُعد البيانات غير متاحة وفق قواعد البروتوكول.

هل يجعل تحدي توافر البيانات أنظمة Alt-DA خالية من المخاطر؟

لا. قد يحد تحدي توافر البيانات من المخاطر، لكن أنظمة Alt-DA تظل تنطوي على افتراضات إضافية تتعلق بطبقة توافر البيانات والجسر وجهات المراقبة والجوانب الاقتصادية والتنفيذ.

ما ضمان تحدي توافر البيانات؟

هو قيمة يودعها المعترض للحد من الرسائل غير المرغوب فيها وجعل التحديات غير الضرورية مكلفة.

هل يمكن أن تؤثر تحديات توافر البيانات في عمليات السحب؟

نعم. قد تؤثر فيها إذا منعت البيانات المفقودة المستخدمين أو التطبيقات من التحقق من حالة السلسلة اللازمة للخروج بأمان.

هل تحديات توافر البيانات مفعلة في جميع شبكات Rollup؟

لا. يعتمد دعمها على تصميم السلسلة والبنية والإعداد وحالة التنفيذ الحالية.

ما الذي ينبغي للمستخدمين التحقق منه قبل استخدام سلسلة تتضمن تحديات توافر البيانات؟

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

الخلاصة

يُعد تحدي توافر البيانات آلية أمان أساسية في شبكات Rollup الحديثة وأنظمة Alt-DA وتصميمات البلوكشين المعيارية.

فهو يتيح للمستخدمين أو مشغلي العقد الاعتراض على مدى توافر البيانات التي يستند إليها التزام ما.

وتكمن أهمية ذلك في أن توافر البيانات ضروري للتحقق وبراهين الاحتيال والسحب الآمن والمزامنة النزيهة ونهائية Rollup.

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

وتتمثل الفائدة في إتاحة التوسع الأقل تكلفة مع إضافة آلية للنزاع.

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

لا ينبغي الخلط بين تحدي توافر البيانات وبرهان الاحتيال أو فترة التحدي العامة أو تخزين البيانات على المدى الطويل.

فهو يتعلق تحديدًا بإثبات إمكانية الوصول إلى البيانات اللازمة للتحقق أو الاعتراض على ذلك.

والدرس الأهم للمستخدمين هو النظر إلى ما وراء الرسوم المنخفضة والسؤال عن كيفية ضمان السلسلة لتوافر البيانات.

أما الدرس الأهم للمطورين فهو التعامل مع افتراضات توافر البيانات كجزء من نموذج أمان التطبيق.

ومع استمرار توجه التوسع في الكريبتو نحو شبكات Rollup وBlobs وAlt-DA والبلوكشين المعياري وأخذ عينات توافر البيانات، ستظل تحديات توافر البيانات مفهومًا مهمًا لفهم أمان أنظمة Layer 2 والتنفيذ خارج السلسلة.