قام نموذج أولي لإيثريوم يوزّع مهام استعادة بيانات “البلوب” بين العقد، بخفض حجم العمل الحسابي المطلوب لإعادة البناء بنسبة تتراوح بين 11 و18 ضعفًا، وذلك وفقًا لعمليات محاكاة شملت 1000 عقدة. وتشير النتائج إلى أن مشغلي الشبكة يمكنهم تقليل العمل المكرر من خلال تعديل أصغر من المقترح الكامل المعروف باسم “RowDAS”.
ما هي مشكلة استعادة بيانات البلوب في إيثريوم؟
البلوبات (Blobs) هي حزم بيانات تستخدمها شبكات الطبقة الثانية (Layer-2) مثل حلول التوسع. وللتأكد من توفر هذه البيانات، يستخدم إيثريوم نظامًا يُسمى “PeerDAS” يسمح للعقد بتحميل جزء فقط من البيانات بدلًا من كل شيء. بعض العقد تحتفظ بـ64 عمودًا من أصل 128 عمودًا للبيانات، وهو ما يكفي لإعادة بناء أي بيانات مفقودة، بينما تحتفظ “العقد الفائقة” بكل الأعمدة الـ128.
المشكلة أن العديد من هذه العقد يقوم بنفس عملية إعادة البناء بشكل مكرر، مما يهدر موارد الحوسبة. التصميم الجديد المختصر يحل هذه المشكلة بتوزيع مهام محددة لإعادة البناء على عقد معينة أولًا، بحيث تستقبل العقد الأخرى البيانات المعاد بناؤها بدلًا من إعادة بنائها بنفسها.
ماذا أظهرت نتائج المحاكاة؟
في أحد السيناريوهات التي تضمنت 4 بلوبات و10% من العقد الفائقة، انخفضت تكلفة إعادة البناء على مستوى الشبكة من 48.6 ثانية معالجة تحت نظام PeerDAS الحالي إلى 2.75 ثانية فقط مع التصميم المخفّض. وعند رفع نسبة العقد الفائقة إلى 20%، انخفض الرقم من 91 إلى 6.6 ثانية معالجة.
وتشير هذه الأرقام إلى إجمالي العمل الحسابي المتراكم عبر الشبكة، وليس الوقت الفعلي المستغرق في الاستعادة. وقد تم حساب التكلفة بناءً على قياس فعلي بلغ 162 ميلي ثانية لكل عملية استعادة بلوب على معالج من نوع “Ryzen 9 8945HS”. ولم تشمل القياسات سرعات المعاملات أو توفير الرسوم.
كيف يعمل التصميم المخفّض؟
الجدير بالذكر أن نظام PeerDAS الأساسي يحتوي أصلًا على آليات تأخير عشوائي وفحوصات تقلل من عمليات إعادة البناء المكررة. التصميم المخفّض يبني على هذه الميزة، حيث تشارك العقد المكلفة البيانات المعاد بناؤها عبر قنوات توزيع الأعمدة الموجودة أصلًا، مع بقاء العقد الفائقة كخط دفاع أخير لأي بيانات ما تزال مفقودة.
أما مقترح RowDAS الكامل، المحدد في المسودة EIP-8371، فيضيف مسارًا إضافيًا للاستعادة عبر قنوات صفوف جديدة تسمح للعقد الأصغر بتجميع بياناتها وإعادة البناء بشكل جماعي. التصميم المخفّض لا يوفر هذه الميزة الإضافية، لأنه يبقى معتمدًا على العقد الفائقة كما هو الحال اليوم.
ما هي حدود هذه النتائج؟
القياسات ما تزال محدودة بشبكات محاكاة داخلية تستخدم تشفيرًا حقيقيًا، ولم يتم الإبلاغ عن أي نتائج من شبكات تجريبية (Devnet). كما أن تكوين الـ128 صفًا في التصميم الكامل يبقى استقراءً من أعداد أصغر. وما تزال عمليات محاكاة أكبر واختبارات على شبكات حقيقية خطوات قادمة مطلوبة.
الفرصة الحالية المباشرة تتمثل في تقليل عمل المعالجة المطلوب لاستعادة البيانات، بينما الفوائد الأوسع في المرونة تعتمد على تطبيق طبقة الصفوف لاحقًا. ولم يتم بعد دمج الفصل بين توزيع المهام وشبكات الصفوف في نص المسودة الرسمية EIP-8371.
الأسئلة الشائعة
ما الفرق بين PeerDAS والتصميم المخفّض الجديد؟
PeerDAS يسمح للعقد بتحميل جزء من بيانات البلوب فقط، لكن العديد من العقد قد تقوم بنفس عملية إعادة البناء بشكل مكرر. التصميم الجديد يوزع مهام إعادة البناء على عقد محددة أولًا، بحيث تستقبل العقد الأخرى البيانات الجاهزة بدلًا من إعادة بنائها، مما يقلل العمل الحسابي بنسبة تصل إلى 18 ضعفًا.
هل يمكن تطبيق التصميم المخفّض الآن؟
التصميم المخفّض لا يزال في مرحلة البحث والمحاكاة فقط، ولم يتم اختباره على شبكات حقيقية بعد. لكنه يُعتبر خطوة أولى عملية نحو تطبيق نظام RowDAS الكامل، حيث يقدم تحسينًا ملموسًا بتغيير أصغر وأقل تعقيدًا من المقترح الشامل.
ما هي ميزة RowDAS الكامل التي لا يوفرها التصميم المخفّض؟
RowDAS الكامل (EIP-8371) يضيف قنوات صفوف جديدة تسمح للعقد الأصغر بتجميع بياناتها معًا وإعادة البناء بشكل جماعي، مما يوفر مرونة إضافية في الشبكة. أما التصميم المخفّض فيبقى معتمدًا على العقد الفائقة مثل النظام الحالي، ولا يحل مشكلة الاعتماد المركزي على هذه العقد.
