خارطة طريق حل تخزين الإيثريوم: التحديات والفرص تتعايش

المصدر: GeekWeb3

الملخص:

· تتزايد بيانات شبكة إيثريوم منذ EIP-4844، حيث تتزايد الإنتاجية وضغط التخزين. يومًا بعد يوم، جلبت متطلبات التخزين المتزايدة تحديات هائلة لعقد إيثريوم. من أجل تقليل ضغط التخزين، يقوم بعض عملاء Ethereum بحذف بيانات Ethereum التاريخية المخزنة محليًا، ويتم تفكيك الاتساق في سلوك التخزين للعقد الكاملة المختلفة تدريجيًا.

· للتأكد من أن جميع عملاء Ethereum يمكنهم تحقيق سلوك متسق، سيقوم EIP-4444 وEIP-4844 بحذف البيانات التاريخية السلوكموحد وسيصبح قياسيًا لعقد إيثريوم في المستقبل.

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

· شبكة بوابة Ethereum هي شبكة P2P خفيفة الوزن ولامركزية لجميع أنواع بيانات Ethereum بما في ذلك البيانات التاريخية. إنه مصمم للأجهزة ذات الموارد المحدودة ويوفر خدمات Ethereum JSON-RPC. شبكة التاريخ وشبكة Beacon Chain جاهزة تقريبًا.

· EthStorage عبارة عن شبكة تخزين معيارية محفزة لبيانات EIP-4844 BLOBs. من أجل تخزين BLOB، يمكن للمستخدمين الاتصال بعقد التخزين على L1، واستخدام ETH كرسوم تخزين، وتسجيل قيمة التجزئة لـ BLOB على السلسلة. بمرور الوقت، سيتم توزيع رسوم التخزين تدريجيًا على موفري خدمات التخزين الذين يقدمون دليلاً على تخزين BLOB خارج السلسلة.

·  يتم تشغيل شبكة اختبار EthStorage حاليًا على شبكة اختبار Ethereum Sepolia، وقد نجح العديد من المشاركين في المجتمع في إثبات حالة التخزين المحلية الخاصة بهم. تتضمن الخطط المستقبلية تطوير شبكة دولة إيثريوم لامركزية، وتمكين إثبات التخزين للبيانات ذات الحجم الديناميكي، وتمكين الوصول اللامركزي إلى شبكة EthStorage مباشرة من المتصفح.

شكر وتقدير: شكرًا لـ Piper Merriam من مؤسسة Ethereum، وKarthik Raju من Polychain، وQiang Zhu من EthStorage لتقديم تعليقات حول هذه المقالة.

الخلفية:

في 22 أكتوبر 2023، أعرب قائد تطوير Go-Ethereum (Geth) الشهير Péter Szilágyi على Twitter عن مخاوفه حول حل تخزين البيانات في Ethereum. وأشار إلى أنه بينما يحتفظ عميل Geth بجميع البيانات التاريخية، يمكن تكوين أنواع أخرى من عملاء Ethereum، مثل Nethermind وBesu، لحذف بعض البيانات التاريخية الخاصة بـ Ethereum (مثل الكتل التاريخية). سيؤدي هذا إلى تصرف بعض عقد العميل بشكل غير متسق مع العملاء الآخرين، وهو أمر غير عادل لمشغلي عملاء Geth. أثار الموضوع أعلاه على الفور نقاشًا ساخنًا حول حل التخزين في خارطة طريق إيثريوم.

تحديات التخزين

لماذا يسمح Nethermind وBesu لمشغلي العملاء بحذف البيانات التاريخية المحلية؟ ما هي القضايا التي يعكسها هذا القرار؟

من وجهة نظرنا هناك سببان رئيسيان:

• متطلبات التخزين من عملاء Ethereum يرتفعون أكثر فأكثر.

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

ينبع السبب الأول من احتياجات التخزين المتزايدة لعملاء Ethereum. يوضح المخطط الدائري أدناه توزيع التخزين لعقدة Geth الجديدة اعتبارًا من 13 ديسمبر 2023، بارتفاع كتلة يبلغ 18,779,761.

كما هو موضح في الصورة:

• إجمالي حجم التخزين: 925.39 جيجابايت

• البيانات التاريخية (الكتلة/استلام المعاملة): 628.69 جيجابايت تقريبًا< /p>

• بيانات الحالة في Merkle Patricia Trie (MPT): حوالي 269.74 جيجابايت

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

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

لذلك، عندما تصبح تكاليف التخزين عبئًا كبيرًا على العقد، فليس من المستغرب أن يختار بعض مشغلي العقد حذف البيانات التاريخية. في غياب البيانات التاريخية، يمكن لعميل العقدة تقليل تكاليف التخزين بشكل كبير، مما يقلل مساحة التخزين المشغولة من حوالي 1 تيرابايت إلى حوالي 300 جيجابايت.

رسم توضيحي: يقوم التكوين Nethermined بتشغيل عقدة بدون كتل تاريخية - مما يوفر حاليًا حوالي 460 جيجابايت من تكاليف التخزين

مع إتاحة بيانات Ethereum As (DA) القادمة إذا تصاعدت، ستشتد تحديات التخزين. يبدأ الطريق إلى توسيع نطاق Ethereum DA بشكل كامل مع EIP-4844 في ترقية DenCun، والذي يقدم كائنًا ثنائيًا كبيرًا ثابت الحجم (BLOB)، ونموذج رسوم مستقل يسمى blobGasPrice. يتم تعيين كل كائن تخزين البيانات الثنائية الكبيرة (BLOB) على 128 كيلو بايت بعد تنفيذ EIP-4844، تحتوي كل كتلة على ما يصل إلى 6 كائنات تخزين كبيرة كبيرة الحجم (BLOBs). من أجل توسيع إنتاجية البيانات، تخطط إيثريوم لاستخدام تشفير محو 1D Reed-Solomon، مما يسمح في البداية بـ 32 BLOBs لكل كتلة، والوصول إلى مستوى 256 BLOBs لكل كتلة عند توسيعها بالكامل.

إذا تم تشغيل Ethereum DA بكامل طاقته (256 BLOBs لكل كتلة)، فمن المتوقع أن تتلقى شبكة Ethereum DA ما يقرب من 80 تيرابايت من بيانات DA سنويًا، وهو رقم يتجاوز بكثير معظم قدرات تخزين العقد .

خريطة طريق تخزين الإيثريوم وعواقبها< /h2 >

ذكرت تغريدة خارطة طريق Ethereum التي نشرها Vitalik أن عملية التطهير تتضمن بشكل أساسي التخزين.

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

· EIP-4444: الحد من البيانات التاريخية في عملاء التنفيذ: يسمح هذا الاقتراح للعملاء بحذف المناطق السابقة التي مضى عليها أكثر من عام واحد. بافتراض أن متوسط ​​حجم الكتلة يبلغ 100 ألف، فإن الحد الأقصى لبيانات الكتلة التاريخية يبلغ حوالي 250 جيجابايت (100 ألف * (3600 * 24 * 365) / 12، بافتراض أن وقت الكتلة = 12 ثانية).

· EIP-4844: معاملات BLOB المشتركة: تجاهل بيانات BLOB الأقدم من 18 يومًا. بالمقارنة مع EIP-4444، يعد هذا نهجًا أكثر عدوانية، حيث يحد من حجم BLOB التاريخي بحوالي 100 جيجابايت ((18 * 3600 * 24) * 128 كيلو * 6/12، بافتراض أن وقت الكتلة = 12 ثانية).

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

سيؤدي حذف البيانات التاريخية لشبكة Ethereum الرئيسية بواسطة عقدة أيضًا إلى حدوث مشكلات في Ethereum L2، أي أن عقد Layer2 المضافة حديثًا لا يمكنها إعادة تشغيل جميع البيانات التاريخية لـ Layer2. المزامنة مع أحدث حالة حالية. بالإضافة إلى ذلك، نظرًا لأن عقد L1 لا تحتفظ بحالة L2، فإن طريقة "مزامنة المزامنة" الخاصة بـ L2 لا يمكنها اشتقاق أحدث حالة Layer2 مباشرةً استنادًا إلى كتل Layer1، وهو ما ينتهك الافتراض المهم المطلوب لـ Layer2 لوراثة أمان Ethereum.

سيعتمد الحل المتوقع على خدمات الطرف الثالث لمشروع Infura/Etherscan/L2 نفسه لتخزين البيانات التاريخية للطبقة الثانية أو نسخ الحالة، وهو حل مركزي يتم تحقيقه من خلال حوافز غير مباشرة خارج البروتوكول .

المشكلة الأساسية التي نريد مناقشتها هي:

• هل يمكننا تحسين التخزين والوصول؟ العثور على حل لامركزي أفضل؟

• هل من الممكن إيجاد حل يمنح حوافز مباشرة للعقد وتضمنه شبكة Ethereum نفسها (على سبيل المثال، يتم تنفيذها بواسطة عقود L1)؟

• مع أخذ كل هذا في الاعتبار، هل يمكننا توفير حل لامركزي بالكامل ومحفز بشكل مباشر ضمن البروتوكول الخاص بمسار تخزين Ethereum؟

الحل

الحل 1: شبكة بوابة إيثريوم

شبكة بوابة Ethereum عبارة عن شبكة لامركزية خفيفة الوزن للاتصال ببروتوكول Ethereum. يوفر واجهات Ethereum JSON-RPC مثل eth_call وeth_getBlockByNumber وما إلى ذلك، والتي تحول طلبات JSON-RPC إلى طلبات P2P لجداول التجزئة الموزعة (DHT)، على غرار شبكة IPFS. على عكس IPFS، الذي يسمح بتخزين أي نوع من البيانات وهو عرضة للبيانات غير المرغوب فيها، تستضيف شبكة Portal P2P حصريًا بيانات Ethereum، مثل رؤوس الكتل التاريخية وبيانات المعاملات، من خلال تقنية التحقق من العميل الخفيفة المضمنة في شبكة Portal.

من الميزات المهمة لشبكة البوابة الإلكترونية. تصميمه التشغيلي خفيف الوزن وتوافقه مع الأجهزة المحدودة الموارد. يمكن تشغيله على العقد التي تحتوي على عدد قليل من ميغابايت من التخزين وذاكرة منخفضة، وبالتالي تعزيز اللامركزية. حتى الهاتف المحمول أو جهاز Raspberry Pi لديه القدرة على الانضمام إلى الشبكة والمساهمة في حل مشكلة Ethereum DA.

تم تطوير شبكة البوابة بما يتماشى مع فلسفة تنوع عملاء Ethereum، مع عملاء مكتوبين بلغات Rust وJavaScript وNim. شبكة المنارة وشبكة التاريخ متاحة بالفعل، في حين أن شبكة الدولة قيد التطوير النشط. ومن الجدير بالذكر أن شبكة البوابة لا تقدم حوافز مباشرة لتخزين البيانات.

رسم توضيحي: عميل Rust لشبكة البوابة الإلكترونية (Trin) مع حد تخزين يبلغ 100 ميجابايت قيد التنفيذ

الحل 2: شبكة EthStorage

strong>

EthStorage Network عبارة عن شبكة تخزين محفزة لامركزية مخصصة لتخزين EIP-4844 BLOBs ويتم تمويلها من قبل مشروع ESP.

· الحد الأدنى من الثقة: على عكس الحلول الحالية التي تتطلب جسر بيانات مركزيًا، يعتمد EthStorage على إجماع Ethereum ونموذج ثقة EthStorage 1/m غير المسموح به للتخزين. العقد. تتم عملية تخزين BLOB كما يلي: يقوم المستخدم بتوقيع معاملة تحمل BLOB ويستدعي طريقة put(key, blob_idx) لعقد التخزين. سيقوم عقد التخزين بعد ذلك بتسجيل تجزئة BLOB على السلسلة. سيقوم موفر التخزين بعد ذلك بتنزيل وتخزين BLOB مباشرةً من شبكة Ethereum DA، وبالتالي تجاوز مشكلة جسر البيانات.

· تتوافق تكاليف التخزين مع الحوافز: عند استدعاء طريقة put()، يجب أن ترسل المعاملة رسوم التخزين (عبر رسالة .القيمة) وإيداعها في العقد. بعد أن تقوم عقدة تخزين خارج السلسلة بإرسال إثبات التخزين والتحقق منه، سيتم توزيع رسوم التخزين هذه تدريجيًا على عقدة التخزين بمرور الوقت. بالمقارنة مع نموذج رسوم تخزين إيثريوم الحالي المتمثل في دفع رسوم تخزين لمرة واحدة إلى منتج الكتلة (المقترح)، تتبع رسوم التخزين المدفوعة بمرور الوقت نموذج التدفق النقدي المخصوم - على افتراض أنه بمرور الوقت، سيتم تخفيض تكلفة التخزين مقارنة بما سعر الإثيريوم. يعمل هذا الابتكار الرئيسي الذي قدمته EthStorage على مواءمة الرسوم ومساهمات التخزين لعقد التخزين.

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

· عملية بدون إذن: يمكن لأي عقدة تخزين في EthStorage الحصول على أموال طالما أنها تخزن البيانات وتقدم شهادات تخزين على السلسلة بانتظام. .

من منظور blockchain المعياري، تعمل EthStorage بمثابة وحدة تخزين Ethereum L2، ولكنها تفرض رسوم تخزين بدلاً من رسوم المعاملات. EthStorage عبارة عن طبقة تخزين معيارية لـ Ethereum تعمل على تحسين قابلية التوسع في التخزين وتقليل التكاليف (استهداف ~1000x) عن طريق فهرسة تجزئات BLOB على السلسلة.

على الجانب التطويري، تم دمج EthStorage مع EIP-4844 على شبكة اختبار Ethereum Sepolia. لقد قمنا باختبار EthStorage وشبكة اختبار Ethereum Sepolia، بما في ذلك كتابة ما يقرب من مئات الجيجابايت من BLOBs إلى EthStorage. انضم أكثر من 100 مشارك من المجتمع إلى الشبكة وأثبتوا بنجاح سعة التخزين المحلية الخاصة بهم.

تتمثل الميزة الرئيسية لشبكة EthStorage في توفير حوافز مباشرة لامركزية بالإضافة إلى Ethereum - وهي ميزة رائدة وفقًا لمعرفتنا الحالية. ومع ذلك، يتمثل أحد قيود هذه الشبكة في أنها مصممة خصيصًا لكائنات تخزين البيانات كبيرة الحجم (BLOBs) ذات الحجم الثابت.

مجلس اختبار Ethereum Sepolia على EthStorage

التطلع إلى المستقبل

على الرغم من أن تخزين Ethereum لم تحظى باهتمام كبير حتى الآن، ولكن لها أهمية مهمة في النظام البيئي للإيثريوم. مع النمو السريع لشبكة إيثريوم، أصبح تخزين بيانات إيثريوم وإمكانية الوصول إليها من التحديات الرئيسية. لا تزال شبكة البوابة وشبكة EthStorage في مراحلها الأولى، وهناك العديد من اتجاهات التطوير المهمة طويلة المدى التي يجب الانتباه إليها:

شبكة بيانات حالة الإيثريوم اللامركزية مع وصول منخفض الكمون: يعد الوصول إلى حالة Ethereum بطريقة لا مركزية ويمكن التحقق منها مهمة حرجة ولكنها صعبة. باستخدام نموذج شبكة DHT التقليدية، غالبًا ما يتطلب الاستعلام عن معلومات الحساب استعلامات متعددة لمحاولة داخلية من العقد المخزنة في عقد P2P مختلفة. وهذا غالبا ما يؤدي إلى تأخيرات كبيرة. إن كيفية استخدام بنية شجرة الحالة لتسريع الوصول هي المفتاح. تهدف شبكة الدولة القادمة لشبكة بوابة Ethereum إلى حل هذه المشكلة.

تكامل شبكة البوابة الإلكترونية مع شبكة EthStorage: يمكن توسيع شبكة البوابة الإلكترونية بسلاسة لدعم بيانات BLOB. قام فريق EthStorage بتنفيذ هذه الوظيفة جزئيًا. والخطوة التالية للأمام هي توحيد هذه الشبكات وتوفير شبكة JSON-RPC لا مركزية يمكنها توفير وصول قابل للبرمجة إلى BLOBs من خلال العقود. من خلال الجمع بين منطق التطبيق في العقود مع سعة تخزين BLOB الموسعة التي توفرها EthStorage، يمكننا تمكين تطبيقات dApps جديدة على Ethereum، مثل مواقع الويب اللامركزية الديناميكية (مثل Twitter/YouTube/Wikipedia اللامركزية، وما إلى ذلك).

الوصول اللامركزي للمتصفحات: على غرار بروتوكول ipfs:// للوصول إلى البيانات في شبكة IPFS، تحتاج صناعة web3 إلى بروتوكول وصول أصلي لـ Ethereum لدعم تصفح الوصول المباشر إلى الخادم لفتح الإمكانات الهائلة لبيانات Ethereum الغنية. تغطي البيانات مجموعة واسعة من المجالات، بدءًا من ملكية الرمز المميز وأرصدة الحسابات إلى صور NFT والمواقع اللامركزية الديناميكية، وكلها ممكنة بفضل إمكانات العقود الذكية وتخزين Ethereum المستقبلي. في هذا المجال، يتم حاليًا تطوير وتعزيز بروتوكول web3:// المحدد بواسطة ERC-4804/6860 لتحقيق هذا الهدف.

إثباتات التخزين المتقدمة للبيانات ذات الحجم الديناميكي: بالإضافة إلى كائنات تخزين البيانات كبيرة الحجم الثابتة، يعد استكشاف أدلة التخزين المتقدمة أمرًا ضروريًا أيضًا لحل البيانات ذات الحجم الديناميكي (مثل الكتل التاريخية وحتى كائنات الحالة، إلخ) يجب القيام به. يمكن أن يؤدي تطوير خوارزميات متطورة إلى تعزيز قدرة حلول التخزين على التكيف.

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