مؤسسة إيثيريوم: مسار تطور حالة إيثيريوم والتحديات المستقبلية

المؤلفون: وي هان نغ، كارلوس بيريز، فريق أبحاث الإجماع عديم الحالة؛ الترجمة: @jinsecaijingxiaozou

تطورت إيثيريوم من شبكة تجريبية صغيرة إلى عنصر أساسي في البنية التحتية العالمية. فهي تُجري معاملات بمليارات الدولارات يوميًا، وتُنسق آلاف التطبيقات، وتُشكل أساس النظام البيئي لشبكة الطبقة الثانية (L2) بأكملها.

يعتمد كل هذا في النهاية على عنصر أساسي: الحالة.

1، ما هي "الحالة" وأهميتها؟

لا يتم تخزين رصيد المستخدم في محفظته، بل يُخزن في حالة إيثيريوم.

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

2، L1يؤدي التوسع إلى عواقب مماثلة

عملت إيثيريوم باستمرار على توسيع شبكتها لسنوات عديدة: من خلال شبكات الطبقة الثانية، وEIP-4844، وزيادة حد الغاز، وإعادة تسعير رسوم الغاز، وآلية الفصل المدمجة بين المُقترح والمُنشئ. وقد حسّنت كل خطوة من قدرة معالجة الشبكة، ولكنها جلبت معها أيضًا تحديات جديدة.

التحدي 1: التوسع المستمر في حالة الشبكة

يزداد حجم حالة إيثيريوم باستمرار. كل حساب جديد، وعملية تخزين، وكتابة رمز بايت، تزيد بشكل دائم من كمية البيانات التي يجب على الشبكة تخزينها. وهذا يترتب عليه تكاليف محددة: يجب على المدققين والعُقد الكاملة تخزين المزيد من البيانات. ومع زيادة حجم الحالة، تحتاج قاعدة البيانات إلى التعامل مع عبء عمل إضافي، مما يؤدي إلى انخفاض الكفاءة تبعًا لذلك. يحتاج موفرو خدمة RPC إلى الحفاظ على إمكانية الوصول الكاملة إلى الحالة، مما يضمن إمكانية الاستعلام عن أي حساب أو بيانات مخزنة في أي وقت. يؤدي نمو الحالة إلى إبطاء مزامنة العُقد وانخفاض الاستقرار. كما أن زيادة حد الغاز يُفاقم تضخم الحالة لأن كل كتلة يمكن أن تستوعب المزيد من عمليات الكتابة. وقد حدثت هذه المشكلة بالفعل على سلاسل عامة أخرى. مع زيادة حجم الحالة، يصبح من الصعب على المستخدمين العاديين تشغيل العُقد الكاملة، مما يؤدي إلى تركيز بيانات الحالة في أيدي عدد قليل من موفري الخدمات الكبار. في إيثيريوم، يتم إنتاج معظم الكتل بالفعل بواسطة بناة محترفين. يتمثل أحد الشواغل الرئيسية في عدد الكيانات المستقلة القادرة على إتمام عملية بناء الكتل من البداية إلى النهاية في اللحظات الحرجة. فإذا اقتصر تخزين الحالة الكاملة وتوفيرها على عدد قليل جدًا من المشاركين، فسيتأثر كل من مقاومة الرقابة وحيادية الثقة، نظرًا لقلة الكيانات القادرة على بناء كتل تحتوي على معاملات خاضعة للرقابة. ومن الجوانب الإيجابية أن آليات مثل FOCIL وVOPS مصممة لضمان مقاومة الرقابة ضمن بيئة بناء احترافية. ومع ذلك، لا تزال فعاليتها تعتمد على بيئة عقد سليمة، حيث يمكن للعقد الوصول إلى بيانات الحالة وتخزينها وتوفيرها بتكلفة معقولة. لذا، يُعد التحكم في نمو الحالة شرطًا أساسيًا، وليس تحسينًا اختياريًا. ولتحديد نقطة التحول، نجري حاليًا اختبارات ضغط مكثفة: متى يصبح نمو الحالة عائقًا أمام قابلية التوسع؟ متى يصبح حجم الحالة كبيرًا لدرجة يصعب معها على العقد متابعة رأس السلسلة؟ متى يفشل تطبيق العميل في ظل أحجام حالة مفرطة؟ التحدي الثاني: في بنية لا تعتمد على الحالة، من المسؤول عن تخزين الحالة وتوفيرها؟ حتى لو حافظت إيثيريوم على حدّها الحالي للغاز بشكل دائم، فسنواجه في نهاية المطاف مشكلة تضخم حالة البيانات. في الوقت نفسه، يتوقع المجتمع بوضوح معدل نقل بيانات أعلى. تُزيل الحلول عديمة الحالة قيدًا رئيسيًا: لا يحتاج المدققون إلى الاحتفاظ بحالة البيانات الكاملة للتحقق من الكتل، بل يكفيهم إثبات صحة البيانات. يُعدّ هذا اختراقًا هامًا في قابلية التوسع، إذ يُلبي طلب المجتمع على معدل نقل بيانات أعلى، ويكشف حقيقة كانت ضمنية سابقًا، وهي أن تخزين حالة البيانات يمكن أن يتطور إلى وظيفة مستقلة وأكثر تخصصًا، بدلًا من أن يكون مرتبطًا بكل مدقق على حدة. في ذلك الوقت، قد يتم تخزين معظم حالة البيانات فقط بواسطة: بناة الكتل؛ ومقدمي خدمات RPC؛ وغيرهم من المشغلين المتخصصين (مثل باحثي MEV ومستكشفي الكتل). بعبارة أخرى، ستصبح حالة البيانات أكثر مركزية. سيؤدي هذا إلى عواقب متعددة: زيادة صعوبة المزامنة: قد يبدأ مقدمو الخدمات المركزيون في تقييد الوصول إلى حالة البيانات، مما يُصعّب على مقدمي الخدمات الجدد إطلاق خدماتهم؛ ضعف ​​مقاومة الرقابة: إذا تعذّر الحصول على بيانات حالة البيانات الخاضعة للرقابة، فقد تفشل آليات مقاومة الرقابة مثل FOCIL. مخاطر مرونة النظام: إذا اقتصر تخزين الحالة الكاملة وتوفيرها على عدد قليل من الكيانات، فإن انقطاعات الخدمة أو الضغوط الخارجية ستؤدي سريعًا إلى قطع الوصول إلى معظم مكونات النظام البيئي. حتى مع تخزين العديد من الكيانات للحالة، هناك نقص في الطرق الفعالة للتحقق من تقديمها للخدمات فعليًا، والحوافز الحالية غير كافية. يدعم النظام مزامنة اللقطات بشكل افتراضي، لكن هذا لا ينطبق على خدمات RPC. إذا لم يتم تخفيض تكلفة خدمات الحالة وزيادة جاذبيتها العامة، فستقتصر قدرة الشبكة على الوصول إلى حالتها على عدد قليل من مزودي الخدمة. تؤثر هذه المشكلة أيضًا على شبكات الطبقة الثانية. تعتمد قدرة المستخدمين على فرض تجميع المعاملات على الوصول الموثوق إلى حالة عقد التجميع على الطبقة الأولى. إذا أصبح الوصول إلى حالة الطبقة الأولى هشًا أو مركزيًا للغاية، فسيكون من الصعب تشغيل آليات صمام الأمان هذه عمليًا.

3، الاتجاهات الرئيسية الثلاثة التي نراها

(1) فترة صلاحية الحالة

لا تتمتع جميع بيانات الحالة بنفس الأهمية الدائمة. يُظهر تحليلنا الأخير أن حوالي 80% من بيانات الحالة لم يتم الوصول إليها لأكثر من عام. ومع ذلك، لا تزال العقد تتحمل تكلفة تخزين هذه الحالات بشكل دائم.

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

باختصار، يمكن تقسيمها إلى فئتين رئيسيتين: الفئة الأولى: الوسم، والإبطال، والإحياء. بدلاً من التعامل مع جميع الحالات على أنها نشطة بشكل دائم، يُعلّم البروتوكول الحالات قليلة الاستخدام على أنها غير نشطة، ويزيلها من مجموعة الحالات النشطة التي تحتفظ بها كل عقدة، مع السماح باستعادتها في المستقبل من خلال إثبات وجودها التاريخي. والنتيجة العملية هي أن العقود والأرصدة المستخدمة بكثرة تظل نشطة بتكاليف وصول منخفضة، بينما لا تحتاج الحالات المنسية منذ فترة طويلة إلى صيانة مستمرة من قبل كل عقدة، ويمكن استدعاؤها عند الحاجة. الفئة الثانية: آلية إبطال متعددة الفترات. في تصميم متعدد الفترات، لا نُحدد إبطالًا للإدخالات الفردية، بل نقسم الحالات دوريًا إلى فترات (على سبيل المثال، فترة واحدة = سنة واحدة). الفترة الحالية أصغر حجمًا ونشطة بالكامل، بينما تُجمّد الفترات الأقدم من منظور التنفيذ في الوقت الفعلي، وتُكتب الحالات الجديدة في الفترة الحالية. لا يمكن استعادة الحالات القديمة إلا من خلال إثبات وجودها في الفترات السابقة. عادةً ما تكون آلية وضع العلامات والإبطال والإحياء أكثر دقة، وتكون عملية الإحياء أكثر مباشرة، لكن عملية وضع العلامات تتطلب تخزين بيانات وصفية إضافية. يُعدّ إبطال الصلاحية متعدد الدورات أبسط من الناحية المفاهيمية وأكثر اندماجًا مع آليات الأرشفة، لكن إثباتات الإحياء غالبًا ما تكون أكثر تعقيدًا وضخامة. في النهاية، يشترك كلا النوعين من الحلول في الهدف نفسه، وهو الحفاظ على حالة النشاط مُبسطة عن طريق إزالة الأجزاء غير النشطة مؤقتًا مع توفير مسار للإحياء، لكنهما يُقدمان مفاضلات مختلفة من حيث التعقيد وتجربة المستخدم وتوزيع عبء العمل على العملاء والبنية التحتية. (2) أرشفة الحالة: تُصنّف أرشفة الحالة الحالات إلى حالات باردة وحالات ساخنة. الحالات الساخنة هي أجزاء الشبكة التي يجب الوصول إليها بشكل متكرر؛ أما الحالات الباردة فهي الأجزاء التي لا تزال مهمة للسجلات التاريخية وإمكانية التحقق ولكن نادرًا ما يتم استخدامها. في تصميم أرشفة الحالة، تُخزّن العُقد صراحةً الحالات الساخنة المستخدمة بشكل متكرر والبيانات التاريخية بشكل منفصل. حتى مع استمرار نمو الحالة الإجمالية، يمكن أن يظل الجزء الذي يحتاج إلى الوصول إليه بسرعة (مجموعات البيانات الساخنة) محدود الحجم. في الواقع، هذا يعني أن أداء العقدة، وخاصة تكلفة الإدخال/الإخراج للوصول إلى الحالة، يمكن أن يظل مستقرًا بشكل أساسي بمرور الوقت، دون أن يتراجع مع تقدم عمر السلسلة. (3) تيسير الوصول إلى خدمات تخزين البيانات. يتبادر إلى الذهن سؤال بديهي: هل يُمكننا تحقيق هدفنا بتقليل حجم البيانات المخزنة؟ بعبارة أخرى، هل يُمكننا تصميم عُقد ومحافظ لا تحتاج إلى تخزين الحالة الكاملة بشكل دائم، مع الحفاظ على فعاليتها؟ يتمثل أحد التوجهات الواعدة في حلول شبه عديمة الحالة: حيث تقوم العُقد بتخزين وتوفير جزء من الحالة فقط (مثل البيانات المتعلقة بمستخدم أو تطبيق مُحدد)؛ وتضطلع المحافظ والعملاء الخفيفون بدور أكثر استباقية في تخزين وتخزين أجزاء الحالة الضرورية مؤقتًا، بدلًا من الاعتماد كليًا على عدد قليل من مُزودي خدمات RPC الكبار. إذا أمكن توزيع التخزين بشكل آمن عبر المحافظ والعُقد المتخصصة، سيخف العبء على المُشغلين الأفراد، وسيزداد تنوع مجتمع حاملي البيانات. يتمثل توجه آخر في تيسير الوصول إلى بنية تحتية مفيدة: تبسيط عملية نشر عُقد RPC التي تُقدم جزءًا من الحالة فقط؛ وتصميم بروتوكولات وأدوات تُمكّن المحافظ والتطبيقات من اكتشاف ودمج مصادر بيانات جزئية متعددة، بدلًا من الاعتماد على نقطة نهاية RPC كاملة واحدة.

4، التوجهات المستقبلية

أصبحت حالة إيثيريوم، بهدوء، عنصرًا أساسيًا في العديد من القضايا الجوهرية لمستقبل البروتوكول:

إلى أي مدى سيشكل حجم الحالة عائقًا أمام المشاركة؟

عندما يتمكن المدققون من التحقق من صحة الكتل بشكل آمن دون الحاجة إلى حالة، فمن سيقوم بتخزين الحالة؟

من سيقدم خدمات الحالة للمستخدمين؟

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

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