ما هي data availability؟
Data availability هو التأكيد على أن البيانات الكاملة وراء الكتلة المقترحة قد تم نشرها على الشبكة، بحيث يمكن لأي مشارك تنزيلها والتحقق منها أو إعادة بناء حالة السلسلة بشكل مستقل. ويهتم المفهوم بشكل كبير بـ رول أب، والتي تنفذ المعاملات بعيداً عن سلسلتها الأصلية ويجب عليها نشر البيانات الأساسية في مكان قابل للتحقق.
المشكلة التي تحلها data availability هي حجب البيانات. يمكن لمنتج الكتل نشر رأس يبدو صالحاً بينما يخفي المعاملات بداخله، مما يترك الشبكة غير قادرة على إثبات وجود خطأ لأن الدليل مفقود. ضمان نشر البيانات، ولو لفترة وجيزة، يغلق تلك الثغرة الأمنية ويسمح لبراهين الاحتيال وإعادة بناء الحالة بالعمل.
بيانات data availability مؤقتة بطبيعتها. تحتاجي الشبكات إلى الاحتفاظ بالبيانات لفترة كافية فقط لمرور فترات التحقق وفض النزاعات، وبعد ذلك يمكن حذفها. تتخلص Ethereum من بيانات blobs بعد حوالي 18 يوماً، وخفضت Celestia الحد الأدنى لفترة الاحتفاظ إلى ما يزيد قليلاً عن 7 أيام، مما يحافظ على استقرار متطلبات تخزين العقد مع نمو الإنتاجية.
يعد نشر البيانات أكبر تكلفة تشغيلية منفردة لمعظم Layer 2 networks، لذا فإن سعر وقسوة data availability يحددان مباشرة رسوم rollup. لقد تحولت data availability إلى سوق تنافسية حيث تبيع كل من Ethereum وCelestia وEigenDA وAvail مساحة blobs لنفس العملاء.

كيف تعمل Data Availability؟
تجمع أنظمة data availability الحديثة بين التشفير التصحيحي، والالتزامات المشفرة، وأخذ العينات العشوائية للسماح للعقد الصغيرة الرخيصة بالتحقق من وجود كميات هائلة من البيانات دون تنزيل أي منها.
1. التشفير التصحيحي (Erasure Coding)
يعمل التشفير التصحيحي على توسيع بيانات الكتلة لتصبح مجموعة أكبر من الأجزاء الزائدة، وغالباً ما يستخدم تشفير ريد-سولومون، بحيث يمكن إعادة بناء البيانات الأصلية من جزء فقط من القطع. إذا نجا نصف البيانات الموسعة، فإن مجموعة البيانات بأكملها تنجو.
تلك الخاصية تحول مشكلة حجب البيانات. بدون التشفير، تعني إخفاء معاملة واحدة قمع جزء صغير جداً، وهو ما لن تكتشفه الفحوصات العشوائية تقريباً أبداً. ومع التشفير، تعني إخفاء أي شيء قمع جزء كبير من البيانات الموسعة لدرجة أن حفنة من العينات تكتشف الفجوة بيقين شبه تام.
تربط الالتزامات الأجزاء برأس الكتلة حتى تتمكن العقد من فحص كل عينة مقابل بصمة الإصبع. ترتب Celestia بياناتها المشفرة في مربع ثنائي الأبعاد مع namespaced Merkle trees، بينما تلتزم Ethereum وAvail ببيانات blob باستخدام التزامات متعددة الحدود KZG، والتي تثبت أن الجزء ينتمي إلى المجموعة دون الكشف عن الباقي.
2. أخذ عينات توفر البيانات (DAS)
أخذ العينات هو تقنية التحقق المبنية فوق التشفير. بدلاً من تنزيل كتلة، يطلب العقد الخفيف بضع عينات عشوائية ويتحقق منها مقابل الالتزامات. كل عينة ناجحة ترفع بشكل حاد احتمالية وجود جميع البيانات هناك، وبضع عشرات من العينات تدفع الثقة إلى ما فوق 99.99%.
الأمان يرتفع مع زيادة المشاركة. يقوم كل عقد عينات إضافي بالاستعلام عن إحداثيات عشوائية مختلفة، لذا فإن الآلاف من العملاء الخفيفين يغطون مجتمعين مجموعة البيانات بأكملها على الرغم من عدم وجود جهاز واحد يحتفظ بها وحدها. تفشل البيانات المحجوبة في اجتياز العينات بسرعة، وترفض العقد الصادقة الكتلة قبل أن تصبح نهائية.
تصبح الكتل الكبيرة آمنة بسبب أخذ العينات. يمكن لسلسلة رفع سعة بياناتها بنسبة كبيرة دون إجبار كل عقد على شراء المزيد من النطاق الترددي، لأن تكلفة التحقق تظل ثابتة تقريباً. هذه هي الآلية الكامنة وراء كل من PeerDAS في Ethereum وشبكة العقد الخفيفة في Celestia.
3. العقد الكاملة، العقد الخفيفة، وإعادة البناء
تقسّم شبكات الـ data availability مهام التحقق عبر أنواع مختلفة من العقد. تقوم العقد الكاملة بتنزيل وتخزين الكتل الكاملة أو أجزاء مخصصة منها، وتزويد شبكات العقد الأخرى بالعينات، وإعادة بناء البيانات المفقودة من القطع المشفرة برموز التصحيح عندما يحجب منتج الكتل جزءاً منها.
تقوم العقد الخفيفة بأخذ العينات. فهي تحتفظ فقط برؤوس الكتل والالتزامات، وتعمل على أجهزة اللابتوب أو الهواتف، ومع ذلك تحصل على ضمانات قوية بوجود البيانات. في تصميم PeerDAS التابع لـ Ethereum، لم يعد حتى المدققون يقومون بتخزين كل blob، نظراً لأن كل عقدة تحتفظ بشريحة مخصصة من البيانات المشفرة وتأخذ عينات من الباقي من النظراء.
إعادة البناء هي شبكة الأمان التي تربط الاثنين ببعضهما البعض. إذا كانت عقد صادقة كافية تحتفظ بقطع كافية فيما بينها، فيمكن دائماً إعادة بناء مجموعة البيانات الكاملة وإعادة نشرها، لذا تحتاج شبكات أخذ العينات إلى الحد الأدنى من العدد الصادق، بينما تعمل الأعداد الأكبر على تعزيز الشبكة بدلاً من إثقال كاهلها.
4. لجان الـ data availability (DACs)
لا تدفع كل شبكة مقابل الحصول على ضمانات كاملة لـ data availability. تعد لجنة الـ data availability مجموعة ثابتة من المشغلين المعروفين الذين يحتفظون ببيانات الـ rollup خارج الشبكة الأصلية ويوقعون على إقرارات بوجودها. تستخدم شبكات Validiums وoptimiums هذا النموذج لخفض التكاليف إلى ما يقرب من الصفر، مع قبول حقيقة أن المستخدمين يجب أن يثقوا في اللجنة بدلاً من التحقق المفتوح.
إذا تواطأت لجنة ما أو فشلت، فقد يواجه المستخدمون صعوبة في إثبات أرصدتهم أو الخروج من الشبكة، وهو خطر تزيله الأنظمة القائمة على أخذ العينات من خلال السماح لأي شخص بالتحقق من البيانات مباشرة. تتتبع L2BEAT الشبكات التي تعتمد على اللجان مقابل طبقات الـ data availability القابلة للتحقق، ولا تزال نسبة كبيرة من الشبكات الخاصة بالتطبيقات تختار نموذج اللجنة نظراً لسعره.
تحاول التصاميم الهجينة تضييق الفجوة. تنشر بعض اللجان التزامات تشفيرية على الشبكة الأصلية، وتضيف staking وعقوبات (slashing) لمعاقبة السلوك السيئ، أو تعود إلى النشر الكامل على السلسلة إذا توقف وصول الإقرارات.

الـ data availability على Ethereum: الـ blobs وPeerDAS
حولَت Ethereum الـ data availability إلى منتج أساسي من خلال ترقية Dencun في مارس 2024، والتي أدخلت الـ blobs عبر EIP-4844. الـ blobs هي حزم بيانات بحجم 128 كيلوبايت تُرفقها الـ rollups بالكتل، وتُسعَّر بواسطة سوق رسوم منفصل ويتم تقليمها بعد نحو 18 يوماً.
ارتفعت السعة على خطوات منذ الإطلاق. بدأت ترقية Dencun بهدف 3 blobs لكل كتلة، وضاعفت ترقية Pectra هذا العدد ليصل إلى 6، ثم قامت ترقية Fusaka بتفعيل PeerDAS، وهو بروتوكول أخذ العينات الذي يتيح للعقد التحقق من الـ blobs دون تنزيلها جميعاً. كما أضافت Fusaka تفرعات تخصيص معاملات الـ blob فقط (Blob Parameter Only forks)، وهي ترقيات صغيرة مجدولة مسبقاً ترفع حدود الـ blob دون الحاجة إلى تفرع صلب (hard fork) كامل.
تبع ذلك تفرعان لـ BPO في غضون أسابيع. رفعت ترقية BPO الثانية الهدف إلى 14 blob لكل كتلة بحد أقصى 21، أي ما يقرب من 2.7 ميجابايت من البيانات لكل كتلة، واحتفظ المطورون الأساسيون بزيادات إضافية كاحتياطي حتى يملأ الطلب المساحة الجديدة. تتجه خارطة الطريق نحو الـ danksharding الكامل، حيث يدعم أخذ العينات ثنائي الأبعاد أعداداً أكبر بكثير من الـ blobs، وستقوم ترقية Glamsterdam القادمة بإعادة هيكلة انتشار الكتل لفتح الخطوة التالية.
التسعير مهم تماماً مثل السعة. تتحرك رسوم الـ blob في مزادها الخاص، لذا تدفع الـ rollups القليل جداً عندما تكون مساحة الـ blob واسعة وترتفع معاً عندما تتشبع، وهي دورة تتكشف عندما يلحق الطلب بحدود ترقية Pectra قبل أن تعيد Fusaka ضبط المساحة المتاحة.

Ethereum Blobs مقابل Celestia مقابل EigenDA مقابل Avail
تختار رول أب الآن بين مساحة blobs الأصلية في Ethereum وشبكات DA المخصصة، ويشكل هذا القرار تكلفة قاعدة بياناتها، وسقف الإنتاجية، وافتراضات الأمان. توفر Ethereum أعلى مستوى من الأمان وتحافظ على التحقق من البيانات داخل نفس مجموعة المدققين التي تقوم بتسوية رول أب، بينما تبيع البدائل نطاق ترددي خام أكبر بكثير وبتكلفة أقل.
Celestia هي أكبر شبكة DA مصممة لهذا الغرض، وهي سلسلة إثبات حصة لا تفعل شيئًا سوى ترتيب ونشر blobs البيانات التي يتم التحقق منها عن طريق أخذ عينات العقدة الخفيفة. أدى تحديث Matcha الخاص بها إلى زيادة الحد الأقصى للكتل من 8 ميجابايت إلى 128 ميجابايت وتخفيض التضخم إلى النصف، وهو جزء من خارطة طريق تستهدف 1 جيجابايت في الثانية من الإنتاجية. تقوم رول أب المستقلة والسلاسل عالية الحجم مثل Eclipse بالنشر هناك نظراً للتكلفة والمساحة المتاحة.
EigenDA تسلك مسارًا مختلفًا، حيث تعمل كخدمة مؤمنة بواسطة ETH المستثمر مرة أخرى من خلال EigenLayer بدلاً من تشغيل سلسلتها الخاصة. وصل إصدارها الثاني إلى 100 ميجابايت في الثانية على mainnet، وهي أعلى إنتاجية مباشرة لأي نظام DA، ولهذا السبب تبني عليها السلاسل التي تركز على الأداء مثل MegaETH. المقايضة هي نموذج توزيع أقرب إلى لجنة لامركزية مقارنة بسلسلة يتم أخذ عينات منها علنًا.
Avail تقع بين الاثنين، وهي سلسلة DA مستقلة تستخدم نفس التزامات KZG وتصميم أخذ العينات مثل خارطة طريق danksharding الخاصة بـ Ethereum. وهي تشغل كتل بحجم 4 ميجابايت اليوم مع مسار محدد نحو سعة متعددة الجيجابايت، وتجمع طبقة DA مع Nexus، وهو نظام تنسيق cross-chain متاح الآن على mainnet.
إليك كيفية مقارنة الخيارات الرئيسية:
توفير البيانات مقابل تخزين البيانات
تُجيب data availability والتخزين على أسئلة مختلفة. يثبت التوفر أن البيانات قد نُشرت وكان من الممكن التحقق منها في لحظة إنتاج الكتلة، وهو ما تتطلبه آليات الإجماع وإثباتات الاحتيال. يحافظ التخزين على إمكانية استرجاع البيانات لفترة طويلة بعد ذلك، وهو ما يتطلبه المستكشفون، والفهارس، والمستخدمون الذين يعيدون تشغيل السجل.
تفرض شبكات البلوكتشين الأولى فقط. بمجرد انقضاء نافذة الـ blobs في Ethereum التي تبلغ حوالي 18 يوماً أو نافذة التقليم في Celestia، لا يقدم البروتوكول أي وعد بأن البيانات لا تزال موجودة، وينتقل حافز الاحتفاظ بها إلى الأطراف التي تحتاج إلى السجل، بما في ذلك فرق رول أب، وعقد الأرشيف، والمستكشفون، والفهارس.
تؤدي شبكات التخزين الدائم الدور الثاني. تدفع أنظمة مثل Arweave وFilecoin للعقد مقابل الاحتفاظ بالبيانات إلى أجل غير مسمى، وتقوم بعض شبكات رول أب بأرشفة سجل الـ blobs المقلم هناك. إن الخلط بين الاثنين يؤدي إلى مفهوم خاطئ شائع مفاده أن التقليم يجعل شبكات رول أب غير آمنة، في حين أن النافذة ذات الصلة بالأمان قد أغلقت بالفعل بحلول الوقت الذي تنتهي فيه صلاحية البيانات.

لماذا تُعد data availability مهمة لشبكات رول أب
يختزل أمان كل شبكة رول أب في ادعاء بأن الأطراف الخارجية يمكنها التحقق من حالتها، ويفشل هذا الادعاء بدون البيانات المنشورة. تحتاج شبكات Optimistic rollups إلى البيانات لتمكين المُعترضين من رصد حالة جذر غير صالحة وتقديم إثبات احتيال خلال نافذة النزاع. إذا استطاع المُسلسل إخفاء المعاملات، فلن يتمكن أحد من بناء الإثبات، وسوف تتم تسوية السرقة دون تحدٍ.
تحتاج ZK rollups إليها لسبب مختلف. يضمن إثبات الصلاحية مسبقاً أن انتقال الحالة قد تم حسابه بشكل صحيح، ولكن المستخدمين ما زالوا بحاجة إلى البيانات الأساسية لمعرفة أرصدتهم الخاصة وللخروج من رول أب إذا اختفى مشغلوها. ترك الإثباتات بدون بيانات السلسلة صحيحة ولكن غير قابلة للاستخدام، ولهذا السبب تتعامل كلتا عائلات رول أب مع data availability كأمر غير قابل للتفاوض بينما تقبل شبكات validiums ضمانات لجان أضعف لخفض التكاليف.
تحد سعة data availability أيضاً من أداء رول أب. لا يمكن للشبكة معالجة المعاملات إلا بالسرعة التي يمكنها بها نشر البيانات الكامنة وراءها، لذا فإن حدود الـ blobs ونطاق ترددي data availability تحدد أسقف الإنتاجية ومستويات الرسوم عبر نظام Layer 2 البيئي. هذا الارتباط هو السبب وراء كون كل ترقية رئيسية للتوسيع في العامين الماضيين، بدءاً من Dencun مروراً بـ Fusaka وصولاً إلى Matcha الخاصة بـ Celestia، ترقية لـ data availability أولاً.

تحديات ضمان data availability
يظل حجب البيانات هو الهجوم الأساسي. العينة الإحصائية تبطل ذلك، لكن الضمانات تعتمد على افتراضات يجب أن تتحقق في الواقع، بما في ذلك وجود ما يكفي من عقد أخذ العينات الصادقة، وطلبات عينات غير متوقعة، وإعادة بناء فعالة عندما تفقد الاجزاء. لا يزال بروتوكول إعادة بناء الكتل الخاص بـ Celestia لأعداد العقد الخفيفة الحد الأدنى قيد التطوير النشط، وقد تم طرح PeerDAS على الشبكة الرئيسية لـ Ethereum منذ بالكاد نصف عام.
تخلق الاقتصاديات مجموعة ثانية من الضغوط. تضع طبقات data availability المخصصة أسعاراً لمساحة الـ blobs رخيصة لدرجة أن إيرادات الرسوم تظل ضئيلة، مما يثير تساؤلات حول كيفية تمويل مجموعات المُدققين الخاصة بهم على المدى الطويل، بينما تواجه Ethereum التوتر المعاكس لأن دفع البيانات إلى طبقات خارجية ينقل دخل الرسوم بعيداً عن مُدقيقيها. ترث الأنظمة القائمة على اللجان مخاطر مركزية مألوفة، نظراً لأن مجموعة صغيرة من المشغلين يمكنها الرقابة، أو التواطؤ، أو ببساطة الخروج عن الخدمة.
يضيف التوسع مخاطر هندسية خاصة به. إن نشر كتل بحجم 128 ميغابايت أو 100 ميغابايت في الثانية من البيانات الموزعة يدفع حدود الشبكات، ويجب على كل قفزة في السعة الحفاظ على خاصية أن اتصال المنزل المتواضع لا يزال بإمكانه التحقق من الشبكة. تستهدف أهداف خريطة طريق القطاع، مثل الكتل بحجم جيجابايت وما بعده، استمرار أخذ العينات في الصمود مع نمو مجموعات البيانات بأوامر من الحجم.
الأفكار الأخيرة
بدأت data availability كزاوية غامضة في تصميم رول أب وأصبحت المحور الذي تدور حوله مناقشة التوسيع بأكملها. من يشر البيانات يحدد أمان الشبكة المبنية على القمة، ومن يضع سعرها يحدد الرسوم التي يدفعها المستخدمون.
توحّد المجال حول أخذ العينات. تتقارب PeerDAS الخاصة بـ Ethereum، والعقد الخفيفة لـ Celestia، وتصميم KZG الخاص بـ Avail على نفس الرؤية، وهي أن الفحوصات العشوائية على البيانات المشفرة ضد الأخطاء تتيح للآلات الصغيرة التحقق من الكتل الضخمة، بينما يُظهر EigenDA مقدار النطاق الترددي الخام الذي يمكن لمجموعة مشغلين مُعاد تخزينهم تقديمه اليوم.
نتوقع أن تقرر الطلب المرحلة القادمة. تتجاوز سعة الـ blobs الاستخدام على Ethereum، وتحتفظ Celestia بهامش 16 ضعفاً فوق حدودها القديمة، والسؤال المفتوح هو التطبيقات التي ستنمو في المساحة التي بنيت من أجلها، بدءاً من شبكات تداول الترددات العالية وصولاً إلى ألعاب onchain.






.webp)