التحدي المهم الذي يواجه إثيريوم هو كيفية تقليل التعقيد ومتطلبات التخزين على المدى الطويل، مع الحفاظ على استمرارية السلسلة ولامركزيتها. لكي يتمكن إثيريوم من الاستمرار على المدى الطويل، نحتاج إلى فرض ضغط مضاد قوي على التعقيد والتضخم، وتقليل التعقيد والتضخم بمرور الوقت. ولكن في الوقت نفسه، نحتاج إلى الاحتفاظ بهذه الخاصية الأساسية لاستمرارية blockchain.
الأهداف الرئيسية للتنقية تشمل:
تقليل متطلبات تخزين العميل عن طريق تقليل أو القضاء على الحاجة إلى تخزين كل عقدة لجميع السجلات التاريخية حتى الحالة النهائية.
تقليل تعقيد البروتوكول من خلال إزالة الوظائف غير الضرورية.
انتهاء سجل التاريخ
ماذا يحل؟
حتى الآن، تحتاج عقدة إثيريوم المتزامنة بالكامل إلى حوالي 1.1 تيرابايت من مساحة القرص لتشغيل العميل، بالإضافة إلى مئات الجيجابايت لعميل الإجماع. معظم هذه البيانات هي بيانات تاريخية، حتى مع بقاء حجم الكتلة ثابتًا، ستستمر حجم العقدة في الزيادة بمئات الجيجابايت سنويًا.
ما هو، كيف يعمل؟
تتمثل إحدى الميزات الأساسية لتبسيط مشكلة التخزين التاريخي في أنه نظرًا لأن كل كتلة مرتبطة بالكتلة السابقة من خلال التجزئة، فإن الوصول إلى توافق حالي يكفي لتحقيق توافق تاريخي. وهذا يوفر لنا العديد من الخيارات حول كيفية تخزين السجلات التاريخية. أحد الخيارات الطبيعية هو شبكة حيث يحتفظ كل عقدة بجزء صغير فقط من البيانات.
الآن، بدأ إثيريوم في التخلص من نموذج تخزين كل التاريخ بشكل دائم على جميع العقد. يتم تخزين كتل الإجماع لمدة حوالي 6 أشهر. يتم تخزين Blob لمدة حوالي 18 يومًا. يهدف EIP-4444 إلى إدخال فترة تخزين لمدة عام للكتل التاريخية والإيصالات. الهدف طويل الأمد هو إنشاء فترة موحدة ( قد تكون حوالي 18 يومًا )، خلال هذه الفترة، ستكون كل عقدة مسؤولة عن تخزين كل المحتوى، ثم إنشاء شبكة نظير إلى نظير تتكون من عقد إثيريوم، حيث يتم تخزين البيانات القديمة بطريقة موزعة.
ماذا يجب أن نفعل بعد؟ ماذا يجب أن نزن؟
تشمل الأعمال الرئيسية المتبقية بناء ودمج حل موزع محدد لتخزين السجلات التاريخية. أبسط حل هو إدخال مكتبات التورنت الحالية أو ما يسمى بحل إثيريوم الأصلي المعروف بشبكة البوابة. تتعلق المقايضات الرئيسية بكيفية سعيينا لتقديم بيانات تاريخية "قديمة". أبسط حل هو التوقف عن تخزين التاريخ القديم غدًا، والاعتماد على العقد الأرشيفية الحالية ومزودي الخدمة المركزيين المختلفين للنسخ. الطريقة الأكثر صعوبة ولكن الأكثر أمانًا هي أولاً بناء ودمج شبكة التورنت، لتخزين السجلات التاريخية بطريقة موزعة.
كيف تتفاعل مع الأجزاء الأخرى من الخارطة?
إذا أردنا جعل تشغيل العقد أو بدءها سهلاً للغاية، فيمكن القول إن تقليل متطلبات تخزين التاريخ أكثر أهمية من عدم الحالة. فقط من خلال تحقيق عدم الحالة وEIP-4444 يمكن تحقيق الرؤية لتشغيل عقد إيثريوم على ساعة ذكية وإعدادها في بضع دقائق.
انتهاء الحالة
ماذا يحل؟
حتى لو قمنا بإزالة الحاجة إلى تخزين سجل العميل, فإن الحاجة لتخزين العميل ستستمر في النمو, بحوالي 50 جيجابايت سنويًا, لأن الحالة تستمر في النمو. يمكن للمستخدمين دفع رسوم لمرة واحدة, مما يثقل كاهل العملاء الحاليين والمستقبليين لإثيريوم.
ما هو ، كيف يعمل؟
اليوم، عند إنشاء كائن حالة جديدة، يبقى هذا الكائن في تلك الحالة إلى الأبد. على العكس، ما نريده هو أن تنتهي صلاحية الكائن تلقائيًا مع مرور الوقت. التحدي الرئيسي هو القيام بذلك بطريقة تحقق الكفاءة، وسهولة الاستخدام، وودية للمطورين.
يوجد حاليًا فئتان من "أسوأ الحلول المعروفة":
حلول انتهاء بعض الحالات
اقتراح انتهاء الحالة بناءً على دورة العنوان
بعض مقترحات انتهاء الحالة تقسم الحالة إلى كتل. يقوم الجميع بتخزين "الخريطة العلوية" بشكل دائم، حيث تكون الكتل فارغة أو غير فارغة. سيتم تخزين البيانات في كل كتلة فقط عندما تم الوصول إلى تلك البيانات مؤخرًا. هناك آلية "إعادة الحياة"، إذا لم يعد يتم تخزين البيانات.
تصميم قائم على دورة العنوان يستخدم قائمة شجرة حالة متزايدة باستمرار، وأي حالة تتم قراءتها أو كتابتها تُخزن في أحدث شجرة حالة. كل فترة ( على سبيل المثال: يتم إضافة شجرة حالة فارغة جديدة مرة واحدة سنويًا ). الأشجار القديمة تتجمد. العقد الكاملة تخزن فقط أحدث شجرتين.
ماذا يجب أن نفعل بعد؟ ماذا يجب أن نزن؟
أعتقد أن هناك أربع طرق قابلة للتطبيق في المستقبل:
نحن نعمل بدون حالة، ولا نقدم أبداً حالة منتهية.
نحن نقوم بإنهاء حالة جزئية، ونقبل معدل نمو حالة دائم أقل بكثير ولكنه لا يزال غير صفري.
نحن نقوم بتمديد الحالة من خلال توسيع مساحة العنوان.
نحن نقوم بإنهاء الحالة من خلال تقليص مساحة العنوان.
النقطة المهمة هي أنه يجب في النهاية حل مشكلة توسيع وتقليص مساحة العنوان، سواء تم تنفيذ خطة انتهاء الصلاحية المعتمدة على تغيير تنسيق العنوان أم لا.
تنظيف الوظائف
ما هي المشكلة التي تحلها؟
أحد الشروط الأساسية للأمان، وإمكانية الوصول، والحيادية الموثوقة هو البساطة. إذا كانت البروتوكولات جميلة وبسيطة، فإنها تقلل من احتمال حدوث الأخطاء. إنها تزيد من فرص مشاركة المطورين الجدد في أي جزء منها. من المحتمل أن تكون أكثر عدلاً، وأيضاً من الأسهل مقاومة المصالح الخاصة. وللأسف، فإن البروتوكولات، مثل أي نظام اجتماعي، تميل افتراضياً إلى أن تصبح أكثر تعقيداً مع مرور الوقت.
ما هو ، كيف يعمل؟
لا توجد إصلاحات رئيسية واحدة يمكن أن تقلل من تعقيد البروتوكول؛ طبيعة هذه المشكلة هي وجود العديد من الحلول الصغيرة. تشمل بعض الأمثلة الرئيسية:
تحويل RLP → SSZ
حذف نوع المعاملة القديم
إصلاح LOG
حذف آلية لجنة تزامن سلسلة الإشارة نهائياً
تنسيق البيانات موحد
حذف لجنة سلسلة الإشارات
إزالة ترتيب البايت المختلط
تبسيط آلية الغاز
حذف الترجمة المسبقة
إزالة قابلية ملاحظة الغاز
تحسين التحليل الثابت
ماذا تحتاج للقيام به، وما الذي يجب مراعاته؟
التوازن الرئيسي الذي يتم اتخاذه في تبسيط هذه الوظيفة هو مستوى و سرعة التبسيط مقابل التوافق مع الإصدارات السابقة. القضية الأوسع في المجتمع هي إنشاء قناة موحدة لإجراء تغييرات تدمر التوافق مع الإصدارات السابقة بشكل غير عاجل.
تنسيق كائن EVM ( EOF ) هو مجموعة من التغييرات الرئيسية المقترحة على EVM. من مزاياه أنه أنشأ مسارًا طبيعيًا لإضافة ميزات جديدة إلى EVM ، ويشجع على الانتقال إلى EVM الأكثر صرامة مع ضمانات أقوى. ومن عيوبه أنه يزيد بشكل كبير من تعقيد البروتوكول، ما لم نجد طريقة للتخلي في النهاية عن EVM القديم وحذفه.
استراتيجية أكثر جذرية لتبسيط إثيريوم هي الحفاظ على البروتوكول كما هو، ولكن نقل معظم وظائف البروتوكول إلى كود العقد. النسخة الأكثر تطرفًا هي أن تجعل إثيريوم L1 "تقنيًا" مجرد سلسلة منارة، وإدخال آلة افتراضية صغيرة تسمح للآخرين بإنشاء ملخصاتهم الخاصة. ثم ستصبح EVM أول هذه الملخصات.
قد تحتوي هذه الصفحة على محتوى من جهات خارجية، يتم تقديمه لأغراض إعلامية فقط (وليس كإقرارات/ضمانات)، ولا ينبغي اعتباره موافقة على آرائه من قبل Gate، ولا بمثابة نصيحة مالية أو مهنية. انظر إلى إخلاء المسؤولية للحصول على التفاصيل.
إثيريوم净化之路：اسقاط复杂性与存储需求的长期挑战
مستقبل إثيريوم المحتمل: التنقية
التحدي المهم الذي يواجه إثيريوم هو كيفية تقليل التعقيد ومتطلبات التخزين على المدى الطويل، مع الحفاظ على استمرارية السلسلة ولامركزيتها. لكي يتمكن إثيريوم من الاستمرار على المدى الطويل، نحتاج إلى فرض ضغط مضاد قوي على التعقيد والتضخم، وتقليل التعقيد والتضخم بمرور الوقت. ولكن في الوقت نفسه، نحتاج إلى الاحتفاظ بهذه الخاصية الأساسية لاستمرارية blockchain.
الأهداف الرئيسية للتنقية تشمل:
تقليل متطلبات تخزين العميل عن طريق تقليل أو القضاء على الحاجة إلى تخزين كل عقدة لجميع السجلات التاريخية حتى الحالة النهائية.
تقليل تعقيد البروتوكول من خلال إزالة الوظائف غير الضرورية.
انتهاء سجل التاريخ
ماذا يحل؟
حتى الآن، تحتاج عقدة إثيريوم المتزامنة بالكامل إلى حوالي 1.1 تيرابايت من مساحة القرص لتشغيل العميل، بالإضافة إلى مئات الجيجابايت لعميل الإجماع. معظم هذه البيانات هي بيانات تاريخية، حتى مع بقاء حجم الكتلة ثابتًا، ستستمر حجم العقدة في الزيادة بمئات الجيجابايت سنويًا.
ما هو، كيف يعمل؟
تتمثل إحدى الميزات الأساسية لتبسيط مشكلة التخزين التاريخي في أنه نظرًا لأن كل كتلة مرتبطة بالكتلة السابقة من خلال التجزئة، فإن الوصول إلى توافق حالي يكفي لتحقيق توافق تاريخي. وهذا يوفر لنا العديد من الخيارات حول كيفية تخزين السجلات التاريخية. أحد الخيارات الطبيعية هو شبكة حيث يحتفظ كل عقدة بجزء صغير فقط من البيانات.
الآن، بدأ إثيريوم في التخلص من نموذج تخزين كل التاريخ بشكل دائم على جميع العقد. يتم تخزين كتل الإجماع لمدة حوالي 6 أشهر. يتم تخزين Blob لمدة حوالي 18 يومًا. يهدف EIP-4444 إلى إدخال فترة تخزين لمدة عام للكتل التاريخية والإيصالات. الهدف طويل الأمد هو إنشاء فترة موحدة ( قد تكون حوالي 18 يومًا )، خلال هذه الفترة، ستكون كل عقدة مسؤولة عن تخزين كل المحتوى، ثم إنشاء شبكة نظير إلى نظير تتكون من عقد إثيريوم، حيث يتم تخزين البيانات القديمة بطريقة موزعة.
ماذا يجب أن نفعل بعد؟ ماذا يجب أن نزن؟
تشمل الأعمال الرئيسية المتبقية بناء ودمج حل موزع محدد لتخزين السجلات التاريخية. أبسط حل هو إدخال مكتبات التورنت الحالية أو ما يسمى بحل إثيريوم الأصلي المعروف بشبكة البوابة. تتعلق المقايضات الرئيسية بكيفية سعيينا لتقديم بيانات تاريخية "قديمة". أبسط حل هو التوقف عن تخزين التاريخ القديم غدًا، والاعتماد على العقد الأرشيفية الحالية ومزودي الخدمة المركزيين المختلفين للنسخ. الطريقة الأكثر صعوبة ولكن الأكثر أمانًا هي أولاً بناء ودمج شبكة التورنت، لتخزين السجلات التاريخية بطريقة موزعة.
كيف تتفاعل مع الأجزاء الأخرى من الخارطة?
إذا أردنا جعل تشغيل العقد أو بدءها سهلاً للغاية، فيمكن القول إن تقليل متطلبات تخزين التاريخ أكثر أهمية من عدم الحالة. فقط من خلال تحقيق عدم الحالة وEIP-4444 يمكن تحقيق الرؤية لتشغيل عقد إيثريوم على ساعة ذكية وإعدادها في بضع دقائق.
انتهاء الحالة
ماذا يحل؟
حتى لو قمنا بإزالة الحاجة إلى تخزين سجل العميل, فإن الحاجة لتخزين العميل ستستمر في النمو, بحوالي 50 جيجابايت سنويًا, لأن الحالة تستمر في النمو. يمكن للمستخدمين دفع رسوم لمرة واحدة, مما يثقل كاهل العملاء الحاليين والمستقبليين لإثيريوم.
ما هو ، كيف يعمل؟
اليوم، عند إنشاء كائن حالة جديدة، يبقى هذا الكائن في تلك الحالة إلى الأبد. على العكس، ما نريده هو أن تنتهي صلاحية الكائن تلقائيًا مع مرور الوقت. التحدي الرئيسي هو القيام بذلك بطريقة تحقق الكفاءة، وسهولة الاستخدام، وودية للمطورين.
يوجد حاليًا فئتان من "أسوأ الحلول المعروفة":
بعض مقترحات انتهاء الحالة تقسم الحالة إلى كتل. يقوم الجميع بتخزين "الخريطة العلوية" بشكل دائم، حيث تكون الكتل فارغة أو غير فارغة. سيتم تخزين البيانات في كل كتلة فقط عندما تم الوصول إلى تلك البيانات مؤخرًا. هناك آلية "إعادة الحياة"، إذا لم يعد يتم تخزين البيانات.
تصميم قائم على دورة العنوان يستخدم قائمة شجرة حالة متزايدة باستمرار، وأي حالة تتم قراءتها أو كتابتها تُخزن في أحدث شجرة حالة. كل فترة ( على سبيل المثال: يتم إضافة شجرة حالة فارغة جديدة مرة واحدة سنويًا ). الأشجار القديمة تتجمد. العقد الكاملة تخزن فقط أحدث شجرتين.
ماذا يجب أن نفعل بعد؟ ماذا يجب أن نزن؟
أعتقد أن هناك أربع طرق قابلة للتطبيق في المستقبل:
النقطة المهمة هي أنه يجب في النهاية حل مشكلة توسيع وتقليص مساحة العنوان، سواء تم تنفيذ خطة انتهاء الصلاحية المعتمدة على تغيير تنسيق العنوان أم لا.
تنظيف الوظائف
ما هي المشكلة التي تحلها؟
أحد الشروط الأساسية للأمان، وإمكانية الوصول، والحيادية الموثوقة هو البساطة. إذا كانت البروتوكولات جميلة وبسيطة، فإنها تقلل من احتمال حدوث الأخطاء. إنها تزيد من فرص مشاركة المطورين الجدد في أي جزء منها. من المحتمل أن تكون أكثر عدلاً، وأيضاً من الأسهل مقاومة المصالح الخاصة. وللأسف، فإن البروتوكولات، مثل أي نظام اجتماعي، تميل افتراضياً إلى أن تصبح أكثر تعقيداً مع مرور الوقت.
ما هو ، كيف يعمل؟
لا توجد إصلاحات رئيسية واحدة يمكن أن تقلل من تعقيد البروتوكول؛ طبيعة هذه المشكلة هي وجود العديد من الحلول الصغيرة. تشمل بعض الأمثلة الرئيسية:
ماذا تحتاج للقيام به، وما الذي يجب مراعاته؟
التوازن الرئيسي الذي يتم اتخاذه في تبسيط هذه الوظيفة هو مستوى و سرعة التبسيط مقابل التوافق مع الإصدارات السابقة. القضية الأوسع في المجتمع هي إنشاء قناة موحدة لإجراء تغييرات تدمر التوافق مع الإصدارات السابقة بشكل غير عاجل.
تنسيق كائن EVM ( EOF ) هو مجموعة من التغييرات الرئيسية المقترحة على EVM. من مزاياه أنه أنشأ مسارًا طبيعيًا لإضافة ميزات جديدة إلى EVM ، ويشجع على الانتقال إلى EVM الأكثر صرامة مع ضمانات أقوى. ومن عيوبه أنه يزيد بشكل كبير من تعقيد البروتوكول، ما لم نجد طريقة للتخلي في النهاية عن EVM القديم وحذفه.
استراتيجية أكثر جذرية لتبسيط إثيريوم هي الحفاظ على البروتوكول كما هو، ولكن نقل معظم وظائف البروتوكول إلى كود العقد. النسخة الأكثر تطرفًا هي أن تجعل إثيريوم L1 "تقنيًا" مجرد سلسلة منارة، وإدخال آلة افتراضية صغيرة تسمح للآخرين بإنشاء ملخصاتهم الخاصة. ثم ستصبح EVM أول هذه الملخصات.