ملخص

• تقدم متطلبات التخزين المتزايدة تحديات كبيرة لعقد إثيريوم.
• بدأ بعض العملاء في تقليم البيانات التاريخية بسبب قيود التخزين، مما أدى إلى سلوك تخزين غير متسق بين العقد الكاملة في الشبكة.
• لضمان التوافق عبر جميع العملاء، يتم توحيد تقليم البيانات التاريخية في EIP-4444 و EIP-4844
• وبالتالي، يعتمد استعادة آخر حالة L1 أو L2 من خلال إعادة تشغيل البيانات التاريخية على خدمات مركزية خارج البروتوكول، مما يعزز استكشاف حلول أكثر لامركزية متوافقة مع إثيريوم
• شبكة بوابة إثيريوم هي شبكة ندفيعية خفيفة الوزن ولامركزية لجميع أنواع بيانات إثيريوم بما في ذلك البيانات التاريخية. تم تصميمها للأجهزة ذات الموارد المحددة وتوفر خدمة إثيريوم JSON-RPC. الشبكة التاريخية وشبكة البيكون تقريبا جاهزة للاستخدام.
• شبكة EthStorage هي شبكة تخزين مكافئة قابلة للتوسيع لـ BLOBs EIP-4844. لتخزين BLOB، يقوم المستخدم بالاتصال بعقد التخزين L1وضع()الطريقة مع تجزئة BLOB ورسوم في الايثر. سيتم توزيع الرسوم تدريجياً على مقدمي التخزين عند تقديم دليل صالح على تخزين BLOBs خارج السلسلة مع الوقت. يعمل اختبار EthStorage على شبكة اختبار Ethereum Sepolia مع مشاركين من مجتمع متعدد يثبتون بنجاح تخزينهم المحلي.
• تشمل المبادرات المستقبلية تطوير شبكة حالة مركزية، وتنفيذ دليل التخزين للبيانات ذات الحجم الديناميكي، والوصول المركزي مباشرة من المتصفحات.

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

خلفية

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

تحدي التخزين

لماذا يختار Nethermind و Besu التوقف عن تخزين البيانات التاريخية؟ ما هي المشاكل التي تكمن وراء هذا القرار؟ من وجهة نظري، هناك سببان جذريان أساسيان:

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

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

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

• متطلبات التخزين الإجمالية: 925.39 جيجابايت
• البيانات التاريخية (الكتل/الإيصالات): حوالي 628.69 غيغابايت
• الحالة في شجرة ميركل باتريشيا (MPT): حوالي 269.74 جيجابايت

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

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

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

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

مع تشغيل Ethereum DA بسعة بيانات كاملة بـ 256 BLOB لكل كتلة، من المتوقع أن تقبل شبكة Ethereum DA لمدة عام تقريبًا 80 تيرابايت من البيانات، متجاوزة قدرات تخزين معظم العقد Ethereum.

إثيريوم خريطة تخزين ونتيجة

فيتاليكتغريدةمن خريطة طريق إثيريوم، حيث يتعامل ال Purge أساسا مع التخزين.

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

1. EIP-4444: Bound Historical Data in Execution Clients: يتيح هذا الاقتراح للعميل تقليم الكتل التاريخية التي تعود إلى أكثر من عام. بافتراض حجم كتل متوسط ​​يبلغ 100K، يتم تحديد حجم بيانات الكتل التاريخية عند حوالي 250 غيغابايت (100K (3600 24 * 365) / 12, بفرض وقت الكتلة = 12 ثانية).
2. EIP-4844: تقسيم معاملات BLOB: EIP-4844 يتجاهل BLOBs الأقدم من 18 يومًا. هذا هو نهج أكثر عدوانية مقارنة بـ EIP-4444، حيث يتم وضع حد لحجم BLOB التاريخي حوالي 100 جيجابايت ((18 3600 24) 128K 6 / 12، بالنظر إلى وقت الكتلة = 12 ثانية).

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

وبالمثل ، تنطبق هذه النتيجة أيضا على جميع L2s ، أي أن العقدة الجديدة من L2 لا يمكنها إعادة تشغيل أحدث حالة بالكامل من نشأة L2 من Ethereum عن طريق إعادة تشغيل كتل L2 من تكوين L2. علاوة على ذلك ، نظرا لأن عقد L1 لا تحافظ على حالة L2 ، فإن نهج "المزامنة المفاجئة" ل L2 لا يمكن أن يشتق أحدث حالة L2 من L1 - مما يكسر افتراض L2 المهم لوراثة ضمانات أمان Ethereum. سيعتمد الحل المتوقع على خدمات الطرف الثالث مثل مشاريع Infura / Etherscan / L2 نفسها لتخزين نسخة من بيانات أو حالة L2 التاريخية ، والتي تكون مركزية مع حافز غير مباشر خارج البروتوكول.

الأسئلة الأساسية التي نطرحها هي

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

حلول

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

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

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

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

الرسم: تشغيل شبكة بوابة (ترين) مع حد تخزين بسعة 100 ميغابايت.

الحل 2: شبكة EthStorage

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

• الثقة الحدية: على عكس الحلول الحالية التي تحتاج إلى جسر بيانات مركزي، يعتمد EthStorage على اتفاقية إثيريوم ونموذج ثقة $1/m$ لمقدمي خدمات تخزين EthStorage غير المرخصين. إجراء تخزين BLOB مثل هذا: يقوم المستخدم بتوقيع معاملة تحمل BLOB التي تستدعي طريقة put(key، blob_idx) من عقد التخزين. سيقوم عقد التخزين بتسجيل تجزئة BLOB وإخطار مقدمي الخدمات التخزين بحدوث حدث. سيقوم مقدمو الخدمات التخزين، بعد استلام الحدث، بتنزيل وتخزين التجزئة BLOB مباشرة من شبكة إثيريوم DA، متجاوزين مشكلة جسر البيانات.
• موازنة تكلفة التخزين مع الحافز: عند الاتصالوضع()بالطريقة، يجب إرسال رسوم تخزين (عبر msg.value) ويتم إيداعها في العقد. يتم توزيع رسوم التخزين هذه تدريجياً على مقدمي خدمات التخزين مع مرور الوقت بعد تقديم والتحقق الناجح من دليل التخزين. بالمقارنة مع نموذج رسوم تخزين إيثيريوم الحالي الذي يدفع رسوم تخزين للمقترح مرة واحدة، تسير رسوم التخزين مع مرور الوقت وفق نموذج تدفق النقد المخفض - مع افتراض أن تكلفة التخزين تنخفض مقابل الإيثر مع مرور الوقت. هذا الابتكار الهام الذي قدمته إثيريوم تخزين يوجه الرسوم التي يدفعها المستخدمون ومساهمات مقدمي الخدمات التخزينية مع مرور الوقت.
• دليل التخزين: يستلهم دليل التخزين من أخذ العينات المتاحة للبيانات، في حين يتم أخذ العينات في EthStorage ضد BLOBs مع مرور الوقت بدلاً من تلك المقترحة للكتلة. للتحقق بكفاءة من عينات الأخذ على السلسلة، يعتمد EthStorage بشكل كبير على العقود الذكية وأحدث التطورات في تقنيات SNARK.
• الشبكة الغير محظورة: يمكن دفع أي عقد في EthStorage كمزود للتخزين طالما أنه يخزن البيانات ويقدم دليلًا على التخزين بانتظام على السلسلة الرئيسية.

من وجهة نظر تجزئة سلسلة الكتل، تعمل EthStorage كطبقة Ethereum 2، لكنها تقوم بجمع رسوم التخزين بدلاً من رسوم المعاملات. من خلال فهرسة تجزئة BLOB على السلسلة، تعد EthStorage بمثابة طبقة تخزين متجزئة Ethereum تتمتع بقدرة تخزين كبيرة وتوفير تكاليف - مستهدفة حوالي 1000 مرة.

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

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

لوحة القيادة لـ EthStorage على Ethereum Devnet

توقع المستقبل

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

• الوصول اللامركزي ذو الانخفاض في التأخير إلى حالة إثيريوم. الوصول إلى حالة إثيريوم بطريقة لامركزية وقابلة للتحقق مهمة حرجة ولكنها تحدي صعب. بالنظر إلى إعداد جدول التوزيع الهجين التقليدي، فإن استعلام حساب يتطلب عادة استعلامات متعددة للعقد الداخلية المخزنة في عقد P2P مختلفة. وهذا غالباً ما يؤدي إلى تأخير طويل جداً. كيفية استخدام هيكل شجرة الحالة لتسريع الوصول هو المفتاح، كما يتم التعامل معه من خلال شبكة الحالة القادمة لشبكة بوابة إثيريوم.
• التكامل بين شبكة بوابة وشبكة إيثستوراج: يمكن لشبكة البوابة تمديد دعمها بسهولة لتشمل BLOBs داخل الشبكة، وهو خطوة اتخذتها بالفعل فريق إيثستوراج جزئيًا. التقدم الطبيعي سيكون توحيد هذه الشبكات لتقديم شبكة JSON-RPC لامركزية قادرة على استدعاء العقود مع وصول إلى BLOBs. من خلال دمج منطق التطبيق في العقود وتخزين BLOB المُكبّر بواسطة إيثستوراج، نمكن تطبيقات dApps جديدة على إيثيريوم مثل مواقع الويب اللامركزية الديناميكية (مثل تويتر/يوتيوب/ويكيبيديا اللامركزية).
• الوصول اللامركزي من المتصفحات: تشبه بروتوكول ipfs:// المستخدم للوصول إلى البيانات في شبكة IPFS، هناك حاجة متزايدة إلى بروتوكول وصول يعتمد على إيثيريوم من المتصفحات لفتح الإمكانيات الهائلة لبيانات إيثيريوم الغنية. تتضمن هذه البيانات طيفًا واسعًا، تتراوح من ملكية الرموز والأرصدة إلى صور NFT ومواقع ويب لامركزية ديناميكية، وهذا ممكن بفضل قدرات العقود الذكية وتخزين إيثيريوم المستقبلي. في هذا النطاق، بروتوكول web3://، كما هو محدد في ERC-4804/6860، يخضع حاليًا لتطوير نشط لتحقيق هذا الغرض.
• دليل تقديمي متقدم لتخزين البيانات ذات الحجم الديناميكي: ما وراء الكتل الثابتة، استكشاف دليل تخزين متقدم يصبح أمرا ضروريا لمعالجة البيانات ذات الحجم الديناميكي، مثل الكتل التاريخية أو حتى كائنات الحالة. يمكن تطوير خوارزميات معقدة لتعزيز قدرة حلول التخزين.

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

بيان:

1. تم استنساخ هذا المقال من [ تدفق التقنية العميقة المد العميق], العنوان الأصلي هو "خريطة طريق تخزين إثيريوم: التحديات والفرص", حقوق النشر تنتمي إلى الكاتب الأصلي [EthStorage]، إذا كان لديك أي اعتراض على إعادة الطبع، يرجى التواصلفريق تعلم جيت, سيرتب الفريق الأمر في أقرب وقت ممكن وفقا للإجراءات ذات الصلة.

2. إخلاء مسؤولية: الآراء والآراء الشخصية المعبر عنها في هذه المقالة تمثل وجهات نظر الكاتب فقط ولا تشكل أي نصيحة استثمارية.

3. تتم ترجمة النسخ الأخرى من المقال بفريق Gate Learn، دون ذكربوابة.أيو, قد لا يُسمح بإعادة إنتاج أو توزيع أو سرقة المقال المترجم.