هذا هو الجزء الأخير من سلسلة مقابلات "التراكمية اللامركزية". تستكشف هذه الحلقة اللامركزية التراكمية من منظور "توافر البيانات والتخزين اللامركزي". لقد قمنا بدعوة Qi Zhou ، مؤسس ** EthStorage ** ، لمناقشة كيف يمكن لـ DA إعادة استخدام سمات الأمان لشبكة Ethereum mainnet و EIP-4844 و danksharding والمقارنة الأمنية لنماذج DA المختلفة. قدم المعلم Zhou أيضًا كيف يمكن دمج EthStorage مع EIP-4844 في ترقية Ethereum التالية.
** مقدمة الضيف **
يسعدني جدًا أن أشارككم بعضًا من أفكارنا حول تقنية Ethereum DA بأكملها والتخزين اللامركزي الذي قمنا به عليها. انضممت إلى صناعة Web3 بدوام كامل في عام 2018. كنت أعمل مهندسًا في شركات كبيرة مثل جوجل وفيسبوك. وحاصل على درجة الدكتوراه من معهد جورجيا للتكنولوجيا. منذ عام 2018 ، أتابع وأعمل على البنية التحتية للويب 3. السبب الرئيسي هو أنني قمت بذلك أيضًا في المصانع الكبيرة من قبل ، بما في ذلك الأنظمة الموزعة والتخزين الموزع. بالإضافة إلى ذلك ، أعتقد أيضًا أنه لا يزال هناك مجال كبير للتحسين في هذا الجانب من blockchain بأكمله. بغض النظر عما فعلناه في البداية ، مثل التقنية التي تسمى تجزئة التنفيذ. إذن هذا هو الإصدار 1.0 من Ethereum ، والآن تسمى التكنولوجيا تجزئة البيانات لتجزئة Ethereum 2.0 ، وتوافر البيانات اللاحقة. في الواقع ، كلها عبارة عن بعض الابتكارات والأعمال التي تم إثباتها حول البنية التحتية Web3 بالكامل.
لذلك نحن نتابع عن كثب خارطة طريق Ethereum ، وندرس ونبحث ، ونشارك ونحسن بهذه الطريقة المجتمعية. في نهاية العام الماضي ، تشرفنا جدًا بتلقي الدعم من مؤسسة Ethereum لبحثنا حول "عينات توفر البيانات". ساعد مؤسسة Ethereum في القيام ببعض الأعمال النظرية ، وبعض الأعمال البحثية حول danksharding ، بما في ذلك كيفية استعادة البيانات بشكل فعال. في الوقت نفسه ، نقوم أيضًا بتطوير EthStorage ، وهي طبقة بيانات Ethereum تعتمد على تقنية DA الخاصة بـ Ethereum. يمكننا استخدام عقود Ethereum الذكية للتحقق من تخزين البيانات خارج السلسلة على نطاق واسع. هذا أيضًا مفيد جدًا لـ Ethereum. لذلك يسعدني جدًا أن أشارككم اليوم ، بما في ذلك كيفية قيام EthStorage ببناء شبكة من طبقات تخزين البيانات بشكل أفضل استنادًا إلى تقنية DA.
** قسم المقابلة **
** الجزء 1: مناقشة حول تعريف DA **
كيف يحافظ توفر البيانات (DA) على أمان التجميعات
بادئ ذي بدء ، في عملية البحث عن DA ، وجدت أيضًا أن العديد من الأشخاص لا يفهمون تعريف DA. أنا أيضًا سعيد جدًا بمناقشته اليوم.قبل ذلك ، ناقشت أيضًا DA مع العديد من أعضاء مؤسسة Ethereum ، مثل Dankrad Feist ، والدور المهم الذي تلعبه DA في Ethereum L2 بالكامل.
لقد ذكرت بعض آليات العمل الأساسية لمجموعة Ethereum rollup ، وكيفية نقل هذه المعاملات على السلسلة إلى خارج السلسلة ، ثم استخدام سلسلة من طرق الإثبات (إثبات الغش وإثبات الصلاحية) لإخبار العقد الذكي L1 بأن نتائج التنفيذ هذه مقبولة - اثبتوا صحتها بهذه البراهين.
ومن ثم فإن الجوهر المهم للغاية هو أنهم يأملون في إعادة استخدام أمان شبكة Ethereum نفسها ، ولكن في نفس الوقت يكونون قادرين على توسيع قوة الحوسبة الكاملة لـ Ethereum بشكل كبير. لقد قلت الآن أن التوسع في قوة الحوسبة يضع الحساب في السلسلة خارج السلسلة ، فكيف يمكن تحقيق أمان Ethereum في نفس الوقت.
على سبيل المثال ، في حالة Optimistic Rollup ، كيف يمكن التأكد من أن شخصًا ما يمكنه تحدي منظم التسلسل للقيام بأشياء ضارة؟ من المهم جدًا معرفة شكل المعاملة الأصلية المحددة ضمن السلسلة. إذا كانت المعاملات الأصلية المحددة خارج السلسلة غير متوفرة ، فلا يمكنني العثور على سجلات المعاملات الأصلية لتحدي جهاز التسلسل في السلسلة. لذلك ، يمكن أن تضمن DA الأمان لأنها تحتاج إلى السماح ببيانات التعريف الخاصة بكل معاملة خارج السلسلة لتكون متاحة في السلسلة.
** توسيع مساحة الكتلة **
نظرًا لأنه يجب تحميل جميع بيانات المعاملات الخاصة بنا إلى السلسلة ، حتى إذا لم تكن هناك حاجة إلى أي حساب ، فسنستمر في إنشاء بيانات ضخمة للمعاملات. ثم المشكلة الأساسية التي يجب حلها ، يمكن للجميع أن يفهم أنها تقنية فعالة للغاية لتوسيع مساحة الكتلة. إذا كان لديك فهم جيد لهيكل blockchain بأكمله ، فإن كل كتلة تحتوي على الكثير من محتوى المعاملات. الكتلة نفسها لهذه المعاملة ، نسميها مساحة الكتلة.
حاليًا ، تبلغ مساحة كل كتلة في Ethereum حوالي 2300 كيلوبايت. لكن من الواضح أن هذا الرقم غير قادر على تلبية احتياجات التوسع التالي في Ethereum. يمكن إجراء عملية حسابية سريعة جدًا هنا: قسّم مساحة 200 كيلو بايت على رقم كل معاملة حوالي 100 بايت ، واحصل على عدد 2000 معاملة. قسّم 2000 معاملة على وقت كتلة Ethereum 12 ، مما يعني أن الحد الأعلى لـ TPS من Ethereum يقتصر على حوالي 100. حسنًا ، هذا في الواقع رقم صغير جدًا لخطة توسيع Ethereum بأكملها.
لذلك ، ما يهتم به Ethereum L2 هو كيفية ضمان الأمان وكيفية وضع كمية كبيرة من بيانات الكتلة في مساحة الكتلة. بعد ذلك ، سواء كان إثباتًا للاحتيال أو إثبات صحة ، يمكن إعادة استخدام البيانات الموجودة في مساحة كتلة Ethereum لإجراء عمليات التحقق المقابلة. أخيرًا ، يمكن ضمان أمان نتائج حساب المعاملات خارج السلسلة بواسطة Ethereum. إذن هذه هي العلاقة بين DA وأمن Ethereum.
** فهم DA من منظور تكلفة النطاق الترددي للشبكة وتكلفة التخزين **
التكلفة الرئيسية لـ DA هي جانبان ، أحدهما يسمى تكلفة النطاق الترددي للشبكة ، والآخر هو تكلفة التخزين.
فيما يتعلق بتكلفة عرض النطاق الترددي للشبكة ، على سبيل المثال ، في شبكة P2P ، فإن طريقة البث الحالية للبيتكوين والإيثريوم هي إرسال جميع عقد P2P من خلال ثرثرة (البث) لإخبار الجميع بأن لدي كتلة جديدة. مثل هذا. تتمثل ميزة نهج الشبكة هذا في أنه آمن للغاية ، وستتلقى جميع عقد الشبكة في النهاية نسخة احتياطية.
الجانب السلبي هو أن لديها حمل كبير على النطاق الترددي للشبكة والكمون. نحن نعلم أن Ethereum ينتج كتلة في 12 ثانية ، بعد ترقية POS. لذلك إذا كانت الكتلة كبيرة جدًا وقد تستغرق أكثر من 12 ثانية ، فلا يمكن إنشاء عدد كبير من الكتل ، وفي النهاية سينخفض النطاق الترددي للشبكة بالكامل إلى مستوى غير مقبول. لذلك يمكنك التفكير في DA كحل لمشكلة النطاق الترددي لكمية كبيرة من البيانات على blockchain.
ثم الثاني هو تكلفة التخزين ، في الواقع ، لدى مؤسسة Ethereum الكثير من المناقشات حول هذا الجانب. في تصميم الحل الأساسي ، لن يسمح بحفظ بيانات الكتلة التي تم تحميلها بواسطة DA بالكامل طوال الوقت.
هذا يقود إلى سؤال آخر. عندما يكون لدي الكثير من البيانات على السلسلة ، ولكن بعد أسبوع أو أسبوعين ، سيتم التخلص منها بواسطة بروتوكول Ethereum. إذن في هذه العملية ، هل لدينا بعض الحلول اللامركزية الأفضل لحفظ بيانات DA هذه.
هذا أيضًا أحد نوايانا الأصلية عند تصميم EthStorage. أولاً ، تحتاج العديد من القوائم التجميعية إلى حفظ البيانات لفترة زمنية أطول. على الجانب الثاني ، باستخدام هذه البيانات ، يمكنني بالفعل استخدام DA لإكمال بعض تطبيقات السلسلة الكاملة بشكل أفضل. على سبيل المثال ، NFT للسلسلة بأكملها ، أو الواجهة الأمامية للعديد من DApps ، بما في ذلك عدد كبير من المقالات أو التعليقات التي كتبها الجميع في الشبكات الاجتماعية. ثم يمكن تحميلها على blockchain بالكامل من خلال شبكة DA بتكلفة أقل ، ويمكن الحصول على نفس الأمان مثل Ethereum L1.
هذا بعد أن بحثنا في التكنولوجيا الكاملة لـ Ethereum DA ، بما في ذلك المناقشة مع العديد من الموظفين الأساسيين في Ethereum ، وجدنا أنه في هذا الصدد ، يجب أن يكون لدى Ethereum طبقة تخزين ، وهي طبقة لامركزية لا تحتاج إلى أن تكون مسؤولة عن Ethereum نفسه: طبقة تخزين تعمل على ترقية البروتوكول ، أو ما نسميه طبقة التخزين المعيارية ، لحل مشكلة تخزين البيانات على المدى الطويل.
** الجزء الثاني: مناقشة حول مخططات DA المختلفة **
العلاقة بين EIP-4844 و Danksharding ، ولماذا يجب نشر EIP-4844
يُطلق على Proto-danksharding أيضًا اسم EIP-4844 ، والذي أعتقد أنه يمكن اعتباره الترقية الرئيسية التالية لـ Ethereum. هناك سبب مهم جدًا لإجراء 4844. عندما يقدر Ethereum Gene مسار الترقية لتجزئة Ethereum ، أي وقت Danksharding ، يعتقدون أن وقت الترقية بأكمله طويل جدًا ، على سبيل المثال ، قد يستغرق الأمر ثلاث سنوات خمس سنوات. كان ذلك في عام 2021 ، 2020.
ثم في هذه العملية ، يتوقعون أنه سيكون هناك الكثير من Rollup قيد التشغيل على Ethereum قريبًا ، ولكن بسبب Danksharding ، تختلف واجهة البيانات التي توفرها تمامًا عن واجهة بيانات Calldata المستخدمة حاليًا بواسطة Rollup. سيؤدي هذا إلى عدم قدرة عدد كبير من تطبيقات Ethereum على الترقية بسرعة بسبب الواجهة الجديدة ، ويمكنها بسهولة الحصول على الفوائد التي يجلبها لهم Danksharding.
عندما ذهبت إلى Devcon العام الماضي ، ذكر فيتاليك أيضًا أنه يأمل أن تتمكن Ethereum من تقديم خدمة أفضل لهذه الطبقة 2 ، حتى يتمكنوا من تطوير عقودهم أثناء استخدام نفس واجهة Danksharding. عند ترقية Danksharding ، يمكنهم أن يرثوا المزايا الجديدة التي تقدمها Danksharding مباشرة دون الحاجة إلى ترقية عقودهم الحالية والمختبرة.
لذا فإن EIP-4844 هو في الواقع نسخة مبسطة للغاية من Danksharding ، والتي توفر نفس واجهة التطبيق مثل Danksharding ، بما في ذلك كود تشغيل جديد يسمى Data Hash ؛ وكائن بيانات جديد يسمى Binary Large Objects ، وهو Blob.
تم تصميم كائنات البيانات هذه لجعل التجميع متوافقًا مع بنية البيانات التي توفرها Danksharding مسبقًا ، أي أن Danksharding ستوفر مفاهيم مماثلة مثل تجزئة البيانات نفسها و Blob. ولكن من خلال EIP-4844 ، قاموا بتطبيق هذه الأفكار في التحديث التالي لـ Ethereum مقدمًا. لذلك ، في وظيفة التصميم الكاملة لـ EIP-4844 ، يمكنك إلقاء نظرة على واجهاتهم ، وعلى سبيل المثال ، الترجمة المسبقة والتعليمات المضافة حديثًا ، ثم يمكنك بالفعل رؤية مستقبل Danksharding بأكمله ، وكيفية تطبيقه على Ethereum عملية تفاعل الطبقة.
في هذا الصدد ، تعتقد Ethereum أيضًا من وجهة نظر التطبيق ، كيف يمكن إجراء بعض الترقيات مقدمًا للسماح للتطبيقات بالاستمتاع بشكل أفضل بتقنيات التوسع المختلفة على Ethereum ، وليست هناك حاجة لتكاليف ترقية إضافية.
ولكن هناك مشكلة تتمثل في أن EIP-4844 لا يحل مشكلة توسيع مساحة الكتلة بالكامل ، ويمكن لـ Danksharding حلها. تبلغ مساحة كتلة Ethereum الحالية حوالي 200 كيلوبايت. بعد Danksharding ، الحجم المخطط في المواصفات هو 32 ميغا بايت ، أي ما يقرب من 100 ضعف. لذا فإن EIP-4844 الحالي لا يحل فعليًا مشكلة النطاق الترددي لـ blockchain على الكتلة.
** كيف يحل Danksharding مشكلة توسيع مساحة الكتلة **
تحت تصميم 4844 ، أثناء عملية بث البيانات على السلسلة ، لا تزال تستخدم نفس طريقة بيانات الاتصال السابقة ، وتقوم بالبث عبر شبكة P2P. ثم سيتم تقييد طريقة البث هذه في النهاية بسبب الاختناق المادي لعرض النطاق الترددي لشبكة P2P بالكامل. لقد غيرت طريقة تصميم Danksharding بث شبكة P2P ، ومن ثم من خلال تقنية أخذ عينات البيانات ، بحيث لا يحتاج الجميع إلى تنزيل جميع بيانات الكتلة ، ولكنهم يعلمون أيضًا أنه يمكن تنزيل بيانات الكتلة هذه.
في الواقع ، يشبه إلى حد ما طريقة ZK. من خلال أخذ عينات البيانات ، أعلم أن الشبكة تحتوي على بيانات كتلة (32 ميغا بايت / كتلة) جلبتها Danksharding. لكني لست بحاجة إلى تنزيل كل 32 ميغا بايت من البيانات لحفظها محليًا. يمكن القيام بذلك أيضًا إذا كان هناك ما يكفي من عرض النطاق الترددي للجهاز وأداء مساحة تخزين كافية ، ولكن بالنسبة لمدقق عادي ، لا يحتاج إلى تنزيل كل 32 ميغا بايت من البيانات.
** بعض التطوير والخبرة في اختبار EIP-4844 **
لقد قمنا مؤخرًا بتشغيل شبكة اختبار EIP-4844 الداخلية الخاصة بنا ، ونشرنا العقد المقابل للاختبار ، بما في ذلك تحميل بيانات blob ومكالمات العقد والتحقق من البيانات ، وقد مررنا جميعًا. لذلك بمجرد أن يصبح EIP-4844 متصلاً بالإنترنت ، يمكننا نشر عقودنا في أقرب وقت ممكن.
في الوقت نفسه ، نأمل أيضًا أنه من خلال تعاوننا الحالي مع بعض مطوري Ethereum ، بالإضافة إلى بعض عقودنا المطورة ، يمكننا توفير الوقت لتطوير مجموعات مختلفة في Ethereum ، بالإضافة إلى التعلم والأدوات المختلفة.
لذلك قدمنا مؤخرًا الكثير من التعليمات البرمجية إلى Ethereum ، الأداة المحددة لـ EIP-4844 ، بما في ذلك العقود الذكية الجديدة لدعم كود التشغيل ، لأن الصلابة لا تزال غير قادرة على دعم كود التشغيل لتجزئة البيانات. إذن كل العمل ، نقوم بالفعل بالمزامنة مع بعض مطوري مؤسسة Ethereum.
** تطبيقات وقيود لجنة توافر البيانات (DAC) **
نظرًا لأن أكثر من 90٪ من النفقات التي يدفعها مستخدمو L2 يتم دفعها مقابل توفر البيانات. ومن أجل تقليل تكلفة تحميل البيانات بشكل أفضل ، أطلقت العديد من مشاريع L2 ، بما في ذلك ZKSync ، ZKPorter و Arbitrum Made Arbitrum Nova. أنها توفر طبقة البيانات الخاصة بهم من خلال توفير لجنة توافر البيانات DAC الخاصة بهم.
ستجلب لجنة البيانات هذه بعض الثقة الإضافية لتحقيق نفس المستوى الإضافي من الأمان مثل Ethereum. لذلك ، عندما يختارون لجنة البيانات ، فإنهم عادةً ما يختارون بعض مزودي خدمات البيانات ذات الأسماء الكبيرة ، أو الشركات ذات الأسماء الكبيرة للمشاركة في حفظ هذه البيانات. لكن في الحقيقة سيكون هناك العديد من التحديات والشكوك ، لأن الجميع يعتقد أن هذا في الواقع انتهاك لمبدأ عدم الوصول إلى اللامركزية ، مما يعني أنه يمكن للجميع المشاركة. لكن الوضع الحالي هو أن معظم لجان البيانات عبارة عن عدد قليل من المنظمات القريبة جدًا من مجموعة مشروع Layer2.
مثل Arbitrum Nova ، في المرة الأخيرة التي نظرت فيها ، ربما كان هناك ستة أو سبعة من هذه العقد. على سبيل المثال ، يمكن لعقد لجنة البيانات التي تعمل على سحابة Google أو سحابة Amazon حفظ هذه البيانات ، ويمكنها توفير جميع تكاليف التنفيذ على Arbitrum Nova. ميزة هذا هو أن تكلفة التنفيذ الحالية الخاصة به تبلغ حوالي واحد في الألف من تكلفة Ethereum. لأنه لا يحتاج إلى كتابة جميع البيانات إلى الطبقة الأولى من Ethereum. لكنها الآن لا تزال مركزية نسبيًا ، لذلك سيكون هناك المزيد من المخاوف بشأن التطبيقات عالية القيمة نسبيًا ، لأنه إذا كان هناك مبلغ كبير من الأموال ، عشرات الملايين أو مئات الملايين من الأموال ، فيجب عليه أن يعتقد أن بيانات لجنة البيانات قابلة للاستخدام.
لذلك عندما قمنا بتصميم EthStorage ، لم يكن لدينا في الواقع أي مفهوم للجنة البيانات. أثناء عملية التصميم ، نأمل أن يتمكن الجميع من المشاركة وأن يصبح مزودًا للبيانات. ويستخدمون البراهين المشفرة لإثبات أنهم قاموا بالفعل بتخزين هذه البيانات. بسبب هذا النموذج من لجنة البيانات من الناحية النظرية ، على الرغم من أنني قلت أن لدي سبع وثمانية عقد للجنة البيانات ، في الواقع ، يمكنني حفظ جزء واحد فقط من البيانات المادية ، لكن يمكنني إظهار أن لدي سبعة أو ثمانية عناوين. تقديم هذه البيانات.
ثم كيفية إثبات أن بياناتي بها نسخ مادية كافية لضمان أمان البيانات. في الواقع ، إنه ابتكار مهم للغاية عندما نقوم بتطبيق EthStorage ، وهو أيضًا ما نؤكده عندما نذهب إلى Ethereum Foundation ESP (برنامج الدعم البيئي) للتبشير. نحن نستخدم تقنية تشفير ZK التي تستخدمها EthStorage لحماية العقد التي توفرها بيانات Layer2. يمكنهم الانضمام دون إذن ويمكنهم إثبات أن لديهم العديد من نسخ التخزين ، ويمكنهم ضمان أمان البيانات بشكل أفضل.
لذلك أعتقد أن DAC هو بالفعل حل مؤقت للغاية لتكلفة تحميل البيانات إلى Layer1. نعتقد أنه يمكننا توفير حل أفضل لتخزين البيانات من خلال بعض تقنيات التشفير الخاصة بـ EthStorage ، إلى جانب بعض طرق التحقق من الإثبات على عقود الطبقة الأولى القائمة على Ethereum. بعد ذلك ، مع إطلاق Ethereum 4844 ، سنأخذ زمام المبادرة لمشاركة هذا المحتوى المبتكر ونتائج تشغيله على الشبكة معك.
** الفرق بين EthStorage و DAC **
EthStorage هو في الواقع مجموعة تخزين Ethereum ، تخزين تراكمي. ثم يمكننا أن نفترض أن الطبقة الثانية ليست تطبيقًا لـ Ethereum EVM ، ولكنها قاعدة بيانات كبيرة جدًا ، أو قاعدة بيانات ذات قيمة أساسية. يمكن أن يصل إلى 10 تيرابايت أو مئات السل أو حتى الآلاف ، وهي قاعدة بيانات على مستوى PB.
ثم كيفية التأكد من أن البيانات الموجودة في قاعدة البيانات الخاصة بي يمكن أن تحصل على نفس الأمان مثل Ethereum. بادئ ذي بدء ، الخطوة الأولى هي أننا نحتاج إلى نشر كل هذه البيانات واسعة النطاق في قاعدة البيانات إلى الطبقة الأولى من Ethereum من خلال DA ، بحيث يمكن للجميع رؤية أن هذه البيانات متاحة في طبقة DA بأكملها من Ethereum. لكن لا يمكننا ضمان إمكانية الحصول عليها بشكل دائم ، لأن Ethereum DA سيتجاهل البيانات في غضون أسبوعين أو أربعة أسابيع تقريبًا.
الخطوة الثانية هي بعد تحميل البيانات ، ثم حفظها على عقدنا من الطبقة الثانية. على عكس DAC ، فإن عقد تخزين البيانات الخاصة بنا غير مسموح بها ويمكن لأي شخص المشاركة. ويثبت تخزينه ، ثم يحصل على المكافأة المقابلة. تتم هذه الطريقة من خلال مجموعة من آليات إثبات التخزين التي أنشأناها. وبالطبع ، فإن آلية إثبات التخزين هذه مستوحاة أيضًا من بعض مخططات تصميم أنظمة إثبات التخزين مثل Filecoin و Arweave. ومع ذلك ، فنحن بحاجة إلى شبكة ونظام إثبات لإطار عمل DA الخاص بـ Ethereum وعقود Ethereum الذكية للقيام بإثباتات التخزين المقابلة. لذلك في هذا الصدد ، نعتقد أن لدينا مساهمة فريدة للغاية في بيئة Ethereum بأكملها ، وحتى التخزين اللامركزي بأكمله.
** آلية إثبات التخزين **
في الأساس ، تحتاج جميع آليات إثبات التخزين ، بما في ذلك Filecoin و Arweave ، إلى تشفير البيانات الوصفية للمستخدم أولاً. لكن عملية التشفير هذه تحتاج إلى أن يتم ترميزها وفقًا لعنوان مزود البيانات ، أي أن كل مزود بيانات يحتاج إلى عنوان مختلف خاص به ، ثم تشفيره وفقًا لعنوانه وبياناته الوصفية لحفظ نسخة متماثلة فريدة (فقط). نسخ) الاشياء. على سبيل المثال ، يمكن تخزين بيانات hello world في أربعة أو خمسة أجهزة فعلية مختلفة في قاعدة بيانات مركزية تقليدية أو في نظام توزيع تقليدي ، كل منها عبارة عن hello world. لكن في EthStorage ، يحفظ أربعة أو خمسة أو عشرة أو عشرين ، وسيتم ترميز عالم الترحيب الخاص به في بيانات مختلفة وفقًا لعنوان كل مزود بيانات ، ثم يتم تخزينه في أماكن مختلفة.
ميزة هذا هو أنه يمكننا استخدام آليات التشفير لإثبات وجود العديد من العناوين المختلفة ، والتي تمثل موفري تخزين مختلفين. قاموا بتشفير البيانات وعملوا أدلة تخزين مقابلة بناءً على البيانات المشفرة. في الأساس ، يشبه Filecoin و Arweave هذا. لكنها مخصصة فقط للبيانات الثابتة ، ونحن الآن نستهدف البيانات الساخنة لـ Ethereum DA. ويمكن التحقق من وجود العديد من النسخ المادية لهذه البيانات من خلال عقد Ethereum الذكي. وهذا يعني أنه بالنسبة لكل بيانات مشفرة ، سنثبت أن هذه البيانات المشفرة مخزنة في هذه الشبكة ، وأن البيانات المقابلة لكل بيانات مشفرة مختلفة ، لأنها مشفرة بواسطة عناوين مزودي التخزين المختلفين من.
لذلك نقوم بشكل أساسي بتحسين وتحسين بعض أفكار التخزين اللامركزية الحالية أثناء عملية التصميم. ولكن في الوقت نفسه ، نحتاج أيضًا إلى إجراء الكثير من التحسين على حل DA الخاص بـ Ethereum ، بما في ذلك تعديل البيانات الديناميكية ، وكيفية إثبات نفقات الغاز على عقود Ethereum وتحسينها بشكل فعال. لذلك هناك الكثير من التقنيات المتطورة والأبحاث التي يجب القيام بها.
** كيف تحتفظ EthStorage بإثبات التخزين بدون إذن **
يوجد نوع من العقدة في Ethereum يسمى عقدة الأرشيف ، والذي سيحفظ السجلات التاريخية لجميع المعاملات في Ethereum ، بما في ذلك حالة العالم. ولكن بعد ذلك ، يتمثل التحدي الكبير في Danksharding في أن خطة Danksharding ستولد حوالي 80 تيرابايت من البيانات سنويًا. لذا ، بافتراض أن Ethereum كان يعمل لمدة ثلاث إلى أربع سنوات ، فإنه سيولد 200 إلى 300 تيرابايت من البيانات ، وسيستمر في الزيادة. حسنًا ، سيشكل هذا في الواقع الكثير من التحديات لعقدة الأرشيف ، لأنه في عملية تشغيل عقدة الأرشيف ، لا تحتوي على اقتصاد رمزي إضافي لتحفيز الجميع على حفظ هذه البيانات.
يحتاج EthStorage أولاً إلى حل مشكلة الحوافز الرمزية للتخزين الدائم للبيانات. في هذا الصدد ، اعتمدنا بالفعل نموذج التدفق النقدي المخصوم لشركة Arweave لتحقيق الحوافز. وفي الوقت نفسه ، من الفعال جدًا السماح لها بتنفيذ العقد الذكي بالكامل.
والثاني هو نهجها غير المصرح به. لأن تصميم الحوافز لدينا يشجع 10 أو 50 أو حتى 100 عقدة لحفظ البيانات في الشبكة. لذلك بالنسبة لأي عقدة ، يمكنها الاتصال بأي منها ، ومزامنة البيانات المقابلة ، ومن ثم يمكن أن تصبح طرفًا لتخزين البيانات. قد يكون هناك أيضًا بعض التصميمات المحسّنة لمزيد من حوافز البيانات.
ثالثًا ، نظرًا لأن عقدة التخزين تحتاج إلى حفظ جميع البيانات في وقت واحد ، فقد تكون مئات تيرابايت أو حتى مستوى PB من البيانات على المدى الطويل. لذلك بالنسبة لعقدة واحدة ، فإن التكلفة مرتفعة للغاية. لذلك قمنا بعمل شيء آخر يسمى تقسيم البيانات هنا. بهذه الطريقة ، بالنسبة للعقد العادية ، تحتاج فقط إلى مساحة بسعة 4 تيرابايت (تصميمنا الحالي هو 4 تيرابايت ، بالطبع ، يمكن ترقيته إلى 8 تيرابايت في المستقبل) ، ويمكنه توفير جزء من الأرشيف البيانات في الشبكة ، لكننا نستخدم بعض آليات الحوافز أيضًا لضمان أنه بعد أن يقوم الجميع في النهاية بتجميع كل هذه البيانات معًا ، يمكن حفظها جميعًا في شبكة layer2 الخاصة بنا.
إذن ، هناك العديد من المشكلات هنا ، مثل مشكلة البيانات الزائدة عن الحد التي تسببها عقد الأرشفة ؛ ومشكلة الحوافز الخاصة بالرموز ؛ ومشكلة الوصول اللامركزي ... يمكننا حل هذه المشكلات من خلال Ethereum يتم نشر العقد الذكي على layer1 إلى أدرك ذلك تلقائيًا. لذلك بالنسبة لنا ، نحن نوفر فقط شبكة بيانات ، بحيث يمكن للجميع تنزيل البيانات وإنشاء شهادة تخزين طالما لديهم تكاليف بيانات كافية ، وإرسالها إلى شبكة Ethereum ، ثم تحقيق العائد المقابل. تم تصميم عقدنا بالكامل بشكل أساسي ، وقد بدأنا في تصحيح الأخطاء على 4844 Devnet من Ethereum.
شاهد النسخة الأصلية
قد تحتوي هذه الصفحة على محتوى من جهات خارجية، يتم تقديمه لأغراض إعلامية فقط (وليس كإقرارات/ضمانات)، ولا ينبغي اعتباره موافقة على آرائه من قبل Gate، ولا بمثابة نصيحة مالية أو مهنية. انظر إلى إخلاء المسؤولية للحصول على التفاصيل.
مؤسس EthStorage: توافر البيانات والتخزين اللامركزي
مقدمة
هذا هو الجزء الأخير من سلسلة مقابلات "التراكمية اللامركزية". تستكشف هذه الحلقة اللامركزية التراكمية من منظور "توافر البيانات والتخزين اللامركزي". لقد قمنا بدعوة Qi Zhou ، مؤسس ** EthStorage ** ، لمناقشة كيف يمكن لـ DA إعادة استخدام سمات الأمان لشبكة Ethereum mainnet و EIP-4844 و danksharding والمقارنة الأمنية لنماذج DA المختلفة. قدم المعلم Zhou أيضًا كيف يمكن دمج EthStorage مع EIP-4844 في ترقية Ethereum التالية.
** مقدمة الضيف **
يسعدني جدًا أن أشارككم بعضًا من أفكارنا حول تقنية Ethereum DA بأكملها والتخزين اللامركزي الذي قمنا به عليها. انضممت إلى صناعة Web3 بدوام كامل في عام 2018. كنت أعمل مهندسًا في شركات كبيرة مثل جوجل وفيسبوك. وحاصل على درجة الدكتوراه من معهد جورجيا للتكنولوجيا. منذ عام 2018 ، أتابع وأعمل على البنية التحتية للويب 3. السبب الرئيسي هو أنني قمت بذلك أيضًا في المصانع الكبيرة من قبل ، بما في ذلك الأنظمة الموزعة والتخزين الموزع. بالإضافة إلى ذلك ، أعتقد أيضًا أنه لا يزال هناك مجال كبير للتحسين في هذا الجانب من blockchain بأكمله. بغض النظر عما فعلناه في البداية ، مثل التقنية التي تسمى تجزئة التنفيذ. إذن هذا هو الإصدار 1.0 من Ethereum ، والآن تسمى التكنولوجيا تجزئة البيانات لتجزئة Ethereum 2.0 ، وتوافر البيانات اللاحقة. في الواقع ، كلها عبارة عن بعض الابتكارات والأعمال التي تم إثباتها حول البنية التحتية Web3 بالكامل.
لذلك نحن نتابع عن كثب خارطة طريق Ethereum ، وندرس ونبحث ، ونشارك ونحسن بهذه الطريقة المجتمعية. في نهاية العام الماضي ، تشرفنا جدًا بتلقي الدعم من مؤسسة Ethereum لبحثنا حول "عينات توفر البيانات". ساعد مؤسسة Ethereum في القيام ببعض الأعمال النظرية ، وبعض الأعمال البحثية حول danksharding ، بما في ذلك كيفية استعادة البيانات بشكل فعال. في الوقت نفسه ، نقوم أيضًا بتطوير EthStorage ، وهي طبقة بيانات Ethereum تعتمد على تقنية DA الخاصة بـ Ethereum. يمكننا استخدام عقود Ethereum الذكية للتحقق من تخزين البيانات خارج السلسلة على نطاق واسع. هذا أيضًا مفيد جدًا لـ Ethereum. لذلك يسعدني جدًا أن أشارككم اليوم ، بما في ذلك كيفية قيام EthStorage ببناء شبكة من طبقات تخزين البيانات بشكل أفضل استنادًا إلى تقنية DA.
** قسم المقابلة **
** الجزء 1: مناقشة حول تعريف DA **
كيف يحافظ توفر البيانات (DA) على أمان التجميعات
بادئ ذي بدء ، في عملية البحث عن DA ، وجدت أيضًا أن العديد من الأشخاص لا يفهمون تعريف DA. أنا أيضًا سعيد جدًا بمناقشته اليوم.قبل ذلك ، ناقشت أيضًا DA مع العديد من أعضاء مؤسسة Ethereum ، مثل Dankrad Feist ، والدور المهم الذي تلعبه DA في Ethereum L2 بالكامل.
لقد ذكرت بعض آليات العمل الأساسية لمجموعة Ethereum rollup ، وكيفية نقل هذه المعاملات على السلسلة إلى خارج السلسلة ، ثم استخدام سلسلة من طرق الإثبات (إثبات الغش وإثبات الصلاحية) لإخبار العقد الذكي L1 بأن نتائج التنفيذ هذه مقبولة - اثبتوا صحتها بهذه البراهين.
ومن ثم فإن الجوهر المهم للغاية هو أنهم يأملون في إعادة استخدام أمان شبكة Ethereum نفسها ، ولكن في نفس الوقت يكونون قادرين على توسيع قوة الحوسبة الكاملة لـ Ethereum بشكل كبير. لقد قلت الآن أن التوسع في قوة الحوسبة يضع الحساب في السلسلة خارج السلسلة ، فكيف يمكن تحقيق أمان Ethereum في نفس الوقت.
على سبيل المثال ، في حالة Optimistic Rollup ، كيف يمكن التأكد من أن شخصًا ما يمكنه تحدي منظم التسلسل للقيام بأشياء ضارة؟ من المهم جدًا معرفة شكل المعاملة الأصلية المحددة ضمن السلسلة. إذا كانت المعاملات الأصلية المحددة خارج السلسلة غير متوفرة ، فلا يمكنني العثور على سجلات المعاملات الأصلية لتحدي جهاز التسلسل في السلسلة. لذلك ، يمكن أن تضمن DA الأمان لأنها تحتاج إلى السماح ببيانات التعريف الخاصة بكل معاملة خارج السلسلة لتكون متاحة في السلسلة.
** توسيع مساحة الكتلة **
نظرًا لأنه يجب تحميل جميع بيانات المعاملات الخاصة بنا إلى السلسلة ، حتى إذا لم تكن هناك حاجة إلى أي حساب ، فسنستمر في إنشاء بيانات ضخمة للمعاملات. ثم المشكلة الأساسية التي يجب حلها ، يمكن للجميع أن يفهم أنها تقنية فعالة للغاية لتوسيع مساحة الكتلة. إذا كان لديك فهم جيد لهيكل blockchain بأكمله ، فإن كل كتلة تحتوي على الكثير من محتوى المعاملات. الكتلة نفسها لهذه المعاملة ، نسميها مساحة الكتلة.
حاليًا ، تبلغ مساحة كل كتلة في Ethereum حوالي 2300 كيلوبايت. لكن من الواضح أن هذا الرقم غير قادر على تلبية احتياجات التوسع التالي في Ethereum. يمكن إجراء عملية حسابية سريعة جدًا هنا: قسّم مساحة 200 كيلو بايت على رقم كل معاملة حوالي 100 بايت ، واحصل على عدد 2000 معاملة. قسّم 2000 معاملة على وقت كتلة Ethereum 12 ، مما يعني أن الحد الأعلى لـ TPS من Ethereum يقتصر على حوالي 100. حسنًا ، هذا في الواقع رقم صغير جدًا لخطة توسيع Ethereum بأكملها.
لذلك ، ما يهتم به Ethereum L2 هو كيفية ضمان الأمان وكيفية وضع كمية كبيرة من بيانات الكتلة في مساحة الكتلة. بعد ذلك ، سواء كان إثباتًا للاحتيال أو إثبات صحة ، يمكن إعادة استخدام البيانات الموجودة في مساحة كتلة Ethereum لإجراء عمليات التحقق المقابلة. أخيرًا ، يمكن ضمان أمان نتائج حساب المعاملات خارج السلسلة بواسطة Ethereum. إذن هذه هي العلاقة بين DA وأمن Ethereum.
** فهم DA من منظور تكلفة النطاق الترددي للشبكة وتكلفة التخزين **
التكلفة الرئيسية لـ DA هي جانبان ، أحدهما يسمى تكلفة النطاق الترددي للشبكة ، والآخر هو تكلفة التخزين.
فيما يتعلق بتكلفة عرض النطاق الترددي للشبكة ، على سبيل المثال ، في شبكة P2P ، فإن طريقة البث الحالية للبيتكوين والإيثريوم هي إرسال جميع عقد P2P من خلال ثرثرة (البث) لإخبار الجميع بأن لدي كتلة جديدة. مثل هذا. تتمثل ميزة نهج الشبكة هذا في أنه آمن للغاية ، وستتلقى جميع عقد الشبكة في النهاية نسخة احتياطية.
الجانب السلبي هو أن لديها حمل كبير على النطاق الترددي للشبكة والكمون. نحن نعلم أن Ethereum ينتج كتلة في 12 ثانية ، بعد ترقية POS. لذلك إذا كانت الكتلة كبيرة جدًا وقد تستغرق أكثر من 12 ثانية ، فلا يمكن إنشاء عدد كبير من الكتل ، وفي النهاية سينخفض النطاق الترددي للشبكة بالكامل إلى مستوى غير مقبول. لذلك يمكنك التفكير في DA كحل لمشكلة النطاق الترددي لكمية كبيرة من البيانات على blockchain.
ثم الثاني هو تكلفة التخزين ، في الواقع ، لدى مؤسسة Ethereum الكثير من المناقشات حول هذا الجانب. في تصميم الحل الأساسي ، لن يسمح بحفظ بيانات الكتلة التي تم تحميلها بواسطة DA بالكامل طوال الوقت.
هذا يقود إلى سؤال آخر. عندما يكون لدي الكثير من البيانات على السلسلة ، ولكن بعد أسبوع أو أسبوعين ، سيتم التخلص منها بواسطة بروتوكول Ethereum. إذن في هذه العملية ، هل لدينا بعض الحلول اللامركزية الأفضل لحفظ بيانات DA هذه.
هذا أيضًا أحد نوايانا الأصلية عند تصميم EthStorage. أولاً ، تحتاج العديد من القوائم التجميعية إلى حفظ البيانات لفترة زمنية أطول. على الجانب الثاني ، باستخدام هذه البيانات ، يمكنني بالفعل استخدام DA لإكمال بعض تطبيقات السلسلة الكاملة بشكل أفضل. على سبيل المثال ، NFT للسلسلة بأكملها ، أو الواجهة الأمامية للعديد من DApps ، بما في ذلك عدد كبير من المقالات أو التعليقات التي كتبها الجميع في الشبكات الاجتماعية. ثم يمكن تحميلها على blockchain بالكامل من خلال شبكة DA بتكلفة أقل ، ويمكن الحصول على نفس الأمان مثل Ethereum L1.
هذا بعد أن بحثنا في التكنولوجيا الكاملة لـ Ethereum DA ، بما في ذلك المناقشة مع العديد من الموظفين الأساسيين في Ethereum ، وجدنا أنه في هذا الصدد ، يجب أن يكون لدى Ethereum طبقة تخزين ، وهي طبقة لامركزية لا تحتاج إلى أن تكون مسؤولة عن Ethereum نفسه: طبقة تخزين تعمل على ترقية البروتوكول ، أو ما نسميه طبقة التخزين المعيارية ، لحل مشكلة تخزين البيانات على المدى الطويل.
** الجزء الثاني: مناقشة حول مخططات DA المختلفة **
العلاقة بين EIP-4844 و Danksharding ، ولماذا يجب نشر EIP-4844
يُطلق على Proto-danksharding أيضًا اسم EIP-4844 ، والذي أعتقد أنه يمكن اعتباره الترقية الرئيسية التالية لـ Ethereum. هناك سبب مهم جدًا لإجراء 4844. عندما يقدر Ethereum Gene مسار الترقية لتجزئة Ethereum ، أي وقت Danksharding ، يعتقدون أن وقت الترقية بأكمله طويل جدًا ، على سبيل المثال ، قد يستغرق الأمر ثلاث سنوات خمس سنوات. كان ذلك في عام 2021 ، 2020.
ثم في هذه العملية ، يتوقعون أنه سيكون هناك الكثير من Rollup قيد التشغيل على Ethereum قريبًا ، ولكن بسبب Danksharding ، تختلف واجهة البيانات التي توفرها تمامًا عن واجهة بيانات Calldata المستخدمة حاليًا بواسطة Rollup. سيؤدي هذا إلى عدم قدرة عدد كبير من تطبيقات Ethereum على الترقية بسرعة بسبب الواجهة الجديدة ، ويمكنها بسهولة الحصول على الفوائد التي يجلبها لهم Danksharding.
عندما ذهبت إلى Devcon العام الماضي ، ذكر فيتاليك أيضًا أنه يأمل أن تتمكن Ethereum من تقديم خدمة أفضل لهذه الطبقة 2 ، حتى يتمكنوا من تطوير عقودهم أثناء استخدام نفس واجهة Danksharding. عند ترقية Danksharding ، يمكنهم أن يرثوا المزايا الجديدة التي تقدمها Danksharding مباشرة دون الحاجة إلى ترقية عقودهم الحالية والمختبرة.
لذا فإن EIP-4844 هو في الواقع نسخة مبسطة للغاية من Danksharding ، والتي توفر نفس واجهة التطبيق مثل Danksharding ، بما في ذلك كود تشغيل جديد يسمى Data Hash ؛ وكائن بيانات جديد يسمى Binary Large Objects ، وهو Blob.
تم تصميم كائنات البيانات هذه لجعل التجميع متوافقًا مع بنية البيانات التي توفرها Danksharding مسبقًا ، أي أن Danksharding ستوفر مفاهيم مماثلة مثل تجزئة البيانات نفسها و Blob. ولكن من خلال EIP-4844 ، قاموا بتطبيق هذه الأفكار في التحديث التالي لـ Ethereum مقدمًا. لذلك ، في وظيفة التصميم الكاملة لـ EIP-4844 ، يمكنك إلقاء نظرة على واجهاتهم ، وعلى سبيل المثال ، الترجمة المسبقة والتعليمات المضافة حديثًا ، ثم يمكنك بالفعل رؤية مستقبل Danksharding بأكمله ، وكيفية تطبيقه على Ethereum عملية تفاعل الطبقة.
في هذا الصدد ، تعتقد Ethereum أيضًا من وجهة نظر التطبيق ، كيف يمكن إجراء بعض الترقيات مقدمًا للسماح للتطبيقات بالاستمتاع بشكل أفضل بتقنيات التوسع المختلفة على Ethereum ، وليست هناك حاجة لتكاليف ترقية إضافية.
ولكن هناك مشكلة تتمثل في أن EIP-4844 لا يحل مشكلة توسيع مساحة الكتلة بالكامل ، ويمكن لـ Danksharding حلها. تبلغ مساحة كتلة Ethereum الحالية حوالي 200 كيلوبايت. بعد Danksharding ، الحجم المخطط في المواصفات هو 32 ميغا بايت ، أي ما يقرب من 100 ضعف. لذا فإن EIP-4844 الحالي لا يحل فعليًا مشكلة النطاق الترددي لـ blockchain على الكتلة.
** كيف يحل Danksharding مشكلة توسيع مساحة الكتلة **
تحت تصميم 4844 ، أثناء عملية بث البيانات على السلسلة ، لا تزال تستخدم نفس طريقة بيانات الاتصال السابقة ، وتقوم بالبث عبر شبكة P2P. ثم سيتم تقييد طريقة البث هذه في النهاية بسبب الاختناق المادي لعرض النطاق الترددي لشبكة P2P بالكامل. لقد غيرت طريقة تصميم Danksharding بث شبكة P2P ، ومن ثم من خلال تقنية أخذ عينات البيانات ، بحيث لا يحتاج الجميع إلى تنزيل جميع بيانات الكتلة ، ولكنهم يعلمون أيضًا أنه يمكن تنزيل بيانات الكتلة هذه.
في الواقع ، يشبه إلى حد ما طريقة ZK. من خلال أخذ عينات البيانات ، أعلم أن الشبكة تحتوي على بيانات كتلة (32 ميغا بايت / كتلة) جلبتها Danksharding. لكني لست بحاجة إلى تنزيل كل 32 ميغا بايت من البيانات لحفظها محليًا. يمكن القيام بذلك أيضًا إذا كان هناك ما يكفي من عرض النطاق الترددي للجهاز وأداء مساحة تخزين كافية ، ولكن بالنسبة لمدقق عادي ، لا يحتاج إلى تنزيل كل 32 ميغا بايت من البيانات.
** بعض التطوير والخبرة في اختبار EIP-4844 **
لقد قمنا مؤخرًا بتشغيل شبكة اختبار EIP-4844 الداخلية الخاصة بنا ، ونشرنا العقد المقابل للاختبار ، بما في ذلك تحميل بيانات blob ومكالمات العقد والتحقق من البيانات ، وقد مررنا جميعًا. لذلك بمجرد أن يصبح EIP-4844 متصلاً بالإنترنت ، يمكننا نشر عقودنا في أقرب وقت ممكن.
في الوقت نفسه ، نأمل أيضًا أنه من خلال تعاوننا الحالي مع بعض مطوري Ethereum ، بالإضافة إلى بعض عقودنا المطورة ، يمكننا توفير الوقت لتطوير مجموعات مختلفة في Ethereum ، بالإضافة إلى التعلم والأدوات المختلفة.
لذلك قدمنا مؤخرًا الكثير من التعليمات البرمجية إلى Ethereum ، الأداة المحددة لـ EIP-4844 ، بما في ذلك العقود الذكية الجديدة لدعم كود التشغيل ، لأن الصلابة لا تزال غير قادرة على دعم كود التشغيل لتجزئة البيانات. إذن كل العمل ، نقوم بالفعل بالمزامنة مع بعض مطوري مؤسسة Ethereum.
** تطبيقات وقيود لجنة توافر البيانات (DAC) **
نظرًا لأن أكثر من 90٪ من النفقات التي يدفعها مستخدمو L2 يتم دفعها مقابل توفر البيانات. ومن أجل تقليل تكلفة تحميل البيانات بشكل أفضل ، أطلقت العديد من مشاريع L2 ، بما في ذلك ZKSync ، ZKPorter و Arbitrum Made Arbitrum Nova. أنها توفر طبقة البيانات الخاصة بهم من خلال توفير لجنة توافر البيانات DAC الخاصة بهم.
ستجلب لجنة البيانات هذه بعض الثقة الإضافية لتحقيق نفس المستوى الإضافي من الأمان مثل Ethereum. لذلك ، عندما يختارون لجنة البيانات ، فإنهم عادةً ما يختارون بعض مزودي خدمات البيانات ذات الأسماء الكبيرة ، أو الشركات ذات الأسماء الكبيرة للمشاركة في حفظ هذه البيانات. لكن في الحقيقة سيكون هناك العديد من التحديات والشكوك ، لأن الجميع يعتقد أن هذا في الواقع انتهاك لمبدأ عدم الوصول إلى اللامركزية ، مما يعني أنه يمكن للجميع المشاركة. لكن الوضع الحالي هو أن معظم لجان البيانات عبارة عن عدد قليل من المنظمات القريبة جدًا من مجموعة مشروع Layer2.
مثل Arbitrum Nova ، في المرة الأخيرة التي نظرت فيها ، ربما كان هناك ستة أو سبعة من هذه العقد. على سبيل المثال ، يمكن لعقد لجنة البيانات التي تعمل على سحابة Google أو سحابة Amazon حفظ هذه البيانات ، ويمكنها توفير جميع تكاليف التنفيذ على Arbitrum Nova. ميزة هذا هو أن تكلفة التنفيذ الحالية الخاصة به تبلغ حوالي واحد في الألف من تكلفة Ethereum. لأنه لا يحتاج إلى كتابة جميع البيانات إلى الطبقة الأولى من Ethereum. لكنها الآن لا تزال مركزية نسبيًا ، لذلك سيكون هناك المزيد من المخاوف بشأن التطبيقات عالية القيمة نسبيًا ، لأنه إذا كان هناك مبلغ كبير من الأموال ، عشرات الملايين أو مئات الملايين من الأموال ، فيجب عليه أن يعتقد أن بيانات لجنة البيانات قابلة للاستخدام.
لذلك عندما قمنا بتصميم EthStorage ، لم يكن لدينا في الواقع أي مفهوم للجنة البيانات. أثناء عملية التصميم ، نأمل أن يتمكن الجميع من المشاركة وأن يصبح مزودًا للبيانات. ويستخدمون البراهين المشفرة لإثبات أنهم قاموا بالفعل بتخزين هذه البيانات. بسبب هذا النموذج من لجنة البيانات من الناحية النظرية ، على الرغم من أنني قلت أن لدي سبع وثمانية عقد للجنة البيانات ، في الواقع ، يمكنني حفظ جزء واحد فقط من البيانات المادية ، لكن يمكنني إظهار أن لدي سبعة أو ثمانية عناوين. تقديم هذه البيانات.
ثم كيفية إثبات أن بياناتي بها نسخ مادية كافية لضمان أمان البيانات. في الواقع ، إنه ابتكار مهم للغاية عندما نقوم بتطبيق EthStorage ، وهو أيضًا ما نؤكده عندما نذهب إلى Ethereum Foundation ESP (برنامج الدعم البيئي) للتبشير. نحن نستخدم تقنية تشفير ZK التي تستخدمها EthStorage لحماية العقد التي توفرها بيانات Layer2. يمكنهم الانضمام دون إذن ويمكنهم إثبات أن لديهم العديد من نسخ التخزين ، ويمكنهم ضمان أمان البيانات بشكل أفضل.
لذلك أعتقد أن DAC هو بالفعل حل مؤقت للغاية لتكلفة تحميل البيانات إلى Layer1. نعتقد أنه يمكننا توفير حل أفضل لتخزين البيانات من خلال بعض تقنيات التشفير الخاصة بـ EthStorage ، إلى جانب بعض طرق التحقق من الإثبات على عقود الطبقة الأولى القائمة على Ethereum. بعد ذلك ، مع إطلاق Ethereum 4844 ، سنأخذ زمام المبادرة لمشاركة هذا المحتوى المبتكر ونتائج تشغيله على الشبكة معك.
** الفرق بين EthStorage و DAC **
EthStorage هو في الواقع مجموعة تخزين Ethereum ، تخزين تراكمي. ثم يمكننا أن نفترض أن الطبقة الثانية ليست تطبيقًا لـ Ethereum EVM ، ولكنها قاعدة بيانات كبيرة جدًا ، أو قاعدة بيانات ذات قيمة أساسية. يمكن أن يصل إلى 10 تيرابايت أو مئات السل أو حتى الآلاف ، وهي قاعدة بيانات على مستوى PB.
ثم كيفية التأكد من أن البيانات الموجودة في قاعدة البيانات الخاصة بي يمكن أن تحصل على نفس الأمان مثل Ethereum. بادئ ذي بدء ، الخطوة الأولى هي أننا نحتاج إلى نشر كل هذه البيانات واسعة النطاق في قاعدة البيانات إلى الطبقة الأولى من Ethereum من خلال DA ، بحيث يمكن للجميع رؤية أن هذه البيانات متاحة في طبقة DA بأكملها من Ethereum. لكن لا يمكننا ضمان إمكانية الحصول عليها بشكل دائم ، لأن Ethereum DA سيتجاهل البيانات في غضون أسبوعين أو أربعة أسابيع تقريبًا.
الخطوة الثانية هي بعد تحميل البيانات ، ثم حفظها على عقدنا من الطبقة الثانية. على عكس DAC ، فإن عقد تخزين البيانات الخاصة بنا غير مسموح بها ويمكن لأي شخص المشاركة. ويثبت تخزينه ، ثم يحصل على المكافأة المقابلة. تتم هذه الطريقة من خلال مجموعة من آليات إثبات التخزين التي أنشأناها. وبالطبع ، فإن آلية إثبات التخزين هذه مستوحاة أيضًا من بعض مخططات تصميم أنظمة إثبات التخزين مثل Filecoin و Arweave. ومع ذلك ، فنحن بحاجة إلى شبكة ونظام إثبات لإطار عمل DA الخاص بـ Ethereum وعقود Ethereum الذكية للقيام بإثباتات التخزين المقابلة. لذلك في هذا الصدد ، نعتقد أن لدينا مساهمة فريدة للغاية في بيئة Ethereum بأكملها ، وحتى التخزين اللامركزي بأكمله.
** آلية إثبات التخزين **
في الأساس ، تحتاج جميع آليات إثبات التخزين ، بما في ذلك Filecoin و Arweave ، إلى تشفير البيانات الوصفية للمستخدم أولاً. لكن عملية التشفير هذه تحتاج إلى أن يتم ترميزها وفقًا لعنوان مزود البيانات ، أي أن كل مزود بيانات يحتاج إلى عنوان مختلف خاص به ، ثم تشفيره وفقًا لعنوانه وبياناته الوصفية لحفظ نسخة متماثلة فريدة (فقط). نسخ) الاشياء. على سبيل المثال ، يمكن تخزين بيانات hello world في أربعة أو خمسة أجهزة فعلية مختلفة في قاعدة بيانات مركزية تقليدية أو في نظام توزيع تقليدي ، كل منها عبارة عن hello world. لكن في EthStorage ، يحفظ أربعة أو خمسة أو عشرة أو عشرين ، وسيتم ترميز عالم الترحيب الخاص به في بيانات مختلفة وفقًا لعنوان كل مزود بيانات ، ثم يتم تخزينه في أماكن مختلفة.
ميزة هذا هو أنه يمكننا استخدام آليات التشفير لإثبات وجود العديد من العناوين المختلفة ، والتي تمثل موفري تخزين مختلفين. قاموا بتشفير البيانات وعملوا أدلة تخزين مقابلة بناءً على البيانات المشفرة. في الأساس ، يشبه Filecoin و Arweave هذا. لكنها مخصصة فقط للبيانات الثابتة ، ونحن الآن نستهدف البيانات الساخنة لـ Ethereum DA. ويمكن التحقق من وجود العديد من النسخ المادية لهذه البيانات من خلال عقد Ethereum الذكي. وهذا يعني أنه بالنسبة لكل بيانات مشفرة ، سنثبت أن هذه البيانات المشفرة مخزنة في هذه الشبكة ، وأن البيانات المقابلة لكل بيانات مشفرة مختلفة ، لأنها مشفرة بواسطة عناوين مزودي التخزين المختلفين من.
لذلك نقوم بشكل أساسي بتحسين وتحسين بعض أفكار التخزين اللامركزية الحالية أثناء عملية التصميم. ولكن في الوقت نفسه ، نحتاج أيضًا إلى إجراء الكثير من التحسين على حل DA الخاص بـ Ethereum ، بما في ذلك تعديل البيانات الديناميكية ، وكيفية إثبات نفقات الغاز على عقود Ethereum وتحسينها بشكل فعال. لذلك هناك الكثير من التقنيات المتطورة والأبحاث التي يجب القيام بها.
** كيف تحتفظ EthStorage بإثبات التخزين بدون إذن **
يوجد نوع من العقدة في Ethereum يسمى عقدة الأرشيف ، والذي سيحفظ السجلات التاريخية لجميع المعاملات في Ethereum ، بما في ذلك حالة العالم. ولكن بعد ذلك ، يتمثل التحدي الكبير في Danksharding في أن خطة Danksharding ستولد حوالي 80 تيرابايت من البيانات سنويًا. لذا ، بافتراض أن Ethereum كان يعمل لمدة ثلاث إلى أربع سنوات ، فإنه سيولد 200 إلى 300 تيرابايت من البيانات ، وسيستمر في الزيادة. حسنًا ، سيشكل هذا في الواقع الكثير من التحديات لعقدة الأرشيف ، لأنه في عملية تشغيل عقدة الأرشيف ، لا تحتوي على اقتصاد رمزي إضافي لتحفيز الجميع على حفظ هذه البيانات.
يحتاج EthStorage أولاً إلى حل مشكلة الحوافز الرمزية للتخزين الدائم للبيانات. في هذا الصدد ، اعتمدنا بالفعل نموذج التدفق النقدي المخصوم لشركة Arweave لتحقيق الحوافز. وفي الوقت نفسه ، من الفعال جدًا السماح لها بتنفيذ العقد الذكي بالكامل.
والثاني هو نهجها غير المصرح به. لأن تصميم الحوافز لدينا يشجع 10 أو 50 أو حتى 100 عقدة لحفظ البيانات في الشبكة. لذلك بالنسبة لأي عقدة ، يمكنها الاتصال بأي منها ، ومزامنة البيانات المقابلة ، ومن ثم يمكن أن تصبح طرفًا لتخزين البيانات. قد يكون هناك أيضًا بعض التصميمات المحسّنة لمزيد من حوافز البيانات.
ثالثًا ، نظرًا لأن عقدة التخزين تحتاج إلى حفظ جميع البيانات في وقت واحد ، فقد تكون مئات تيرابايت أو حتى مستوى PB من البيانات على المدى الطويل. لذلك بالنسبة لعقدة واحدة ، فإن التكلفة مرتفعة للغاية. لذلك قمنا بعمل شيء آخر يسمى تقسيم البيانات هنا. بهذه الطريقة ، بالنسبة للعقد العادية ، تحتاج فقط إلى مساحة بسعة 4 تيرابايت (تصميمنا الحالي هو 4 تيرابايت ، بالطبع ، يمكن ترقيته إلى 8 تيرابايت في المستقبل) ، ويمكنه توفير جزء من الأرشيف البيانات في الشبكة ، لكننا نستخدم بعض آليات الحوافز أيضًا لضمان أنه بعد أن يقوم الجميع في النهاية بتجميع كل هذه البيانات معًا ، يمكن حفظها جميعًا في شبكة layer2 الخاصة بنا.
إذن ، هناك العديد من المشكلات هنا ، مثل مشكلة البيانات الزائدة عن الحد التي تسببها عقد الأرشفة ؛ ومشكلة الحوافز الخاصة بالرموز ؛ ومشكلة الوصول اللامركزي ... يمكننا حل هذه المشكلات من خلال Ethereum يتم نشر العقد الذكي على layer1 إلى أدرك ذلك تلقائيًا. لذلك بالنسبة لنا ، نحن نوفر فقط شبكة بيانات ، بحيث يمكن للجميع تنزيل البيانات وإنشاء شهادة تخزين طالما لديهم تكاليف بيانات كافية ، وإرسالها إلى شبكة Ethereum ، ثم تحقيق العائد المقابل. تم تصميم عقدنا بالكامل بشكل أساسي ، وقد بدأنا في تصحيح الأخطاء على 4844 Devnet من Ethereum.