jakiro
المؤلف: وي هان إنج، كارلوس بيريز، فريق البحث المتفق عليه حول عديمي الجنسية؛ الترجمة: @bitchainvisionxiaozou
لقد نمت Ethereum من شبكة تجريبية صغيرة إلى مكون حاسم في البنية التحتية العالمية.فهو يقوم بتسوية مليارات الدولارات من قيمة التسوية اليومية، وينسق آلاف التطبيقات، ويدعم النظام البيئي لشبكة الطبقة الثانية (L2) بالكامل.
يعتمد كل ذلك في النهاية على مكون أساسي واحد: الحالة (<ب>الدولة).
<ب>1ما هو<ب>“الحالة<ب>“وأهميته
لا يتم تخزين رصيد المستخدم في محفظته، ولكن في حالة الايثيريوم.يمكن فهم الحالة تقريبًا على أنها “كل ما تعرفه Ethereum حاليًا”: الحسابات، وتخزين العقود (جميع البيانات المكتوبة بموجب العقد)، والرمز الثانوي (المنطق الذي يتم تشغيله عند استخدام العقود الذكية).
الحالة هي الأساس لجميع الوظائف تقريبًا:
تعتمد عليها المحافظ لعرض الأرصدة وسجلات العمليات السابقة؛
تستعلم عنه التطبيقات اللامركزية (Dapps) للتعرف على المواقف أو الطلبات أو الرسائل الموجودة؛
تقوم البنية التحتية (مستكشفات الكتل، والجسور عبر السلاسل، والمفهرسات، وما إلى ذلك) بقراءة الحالة باستمرار لتقديم الخدمات فوقها.
إذا أصبحت الدولة كبيرة جدًا، أو شديدة المركزية، أو يصعب خدمتها، فإن جميع الطبقات المذكورة أعلاه تصبح أكثر هشاشة، وأكثر تكلفة، وأكثر صعوبة في اللامركزية.
<ب>2,<ب>L1التوسع له عواقب
استمرت إيثريوم في العمل على توسيع الشبكة لسنوات عديدة: من خلال شبكة الطبقة الثانية، EIP-4844، وزيادة حد الغاز، وإعادة تسعير رسوم الغاز، وآلية الفصل المدمجة بين مقدم العرض والباني.أدت كل خطوة إلى تحسين قدرات معالجة الشبكة، ولكنها جلبت أيضًا تحديات جديدة.
<ب>التحدي 1: الحالة مستمرة في التوسع
حجم حالة Ethereum آخذ في الازدياد.كل حساب جديد، وعملية تخزين، وكتابة كود ثانوي يزيد بشكل دائم من كمية البيانات التي يجب أن تحتفظ بها الشبكة.
وينتج عن ذلك تكاليف محددة:
يجب أن تقوم أدوات التحقق من الصحة والعقد الكاملة بتخزين المزيد من البيانات.مع زيادة مقياس الحالة، تحتاج قاعدة البيانات إلى التعامل مع عبء العمل الإضافي وتقل الكفاءة.
يحتاج موفر خدمة RPC إلى أن يظل متاحًا بشكل كامل وأن يضمن إمكانية الاستعلام عن أي حساب أو بيانات مخزنة في أي وقت.
يؤدي نمو الحالة إلى مزامنة العقدة بشكل أبطأ وتقليل الاستقرار.
تؤدي زيادة حد الغاز إلى زيادة انتفاخ الحالة لأن كل كتلة يمكنها استيعاب المزيد من عمليات الكتابة.لقد حدثت هذه المشكلة بالفعل في سلاسل عامة أخرى.مع توسع نطاق الولاية، يصعب على المستخدمين العاديين تشغيل العقد الكاملة، مما يؤدي إلى تركيز بيانات الحالة في أيدي عدد قليل من مقدمي الخدمات الكبار.
في إيثريوم، تم إنتاج معظم الكتل بواسطة بناة محترفين.القلق الأساسي هو عدد الكيانات المستقلة التي لا يزال بإمكانها إكمال بناء الكتل الشاملة في اللحظة الحرجة.إذا تمكن عدد قليل جدًا من المشاركين من تخزين الحالة الكاملة وتوفيرها، فسوف تتعرض مقاومة الرقابة والحياد الموثوق به للخطر – لأنه سيكون هناك عدد أقل من المديرين القادرين على إنشاء كتل تحتوي على معاملات خاضعة للرقابة.
جزء من العامل الإيجابي هو أن آليات مثل FOCIL وVOPS مصممة لضمان مقاومة الرقابة في النظام البيئي للبناء الاحترافي.لكن فعاليتها لا تزال تعتمد على نظام بيئي صحي من العقد التي يمكنها الوصول إلى بيانات الدولة وتخزينها وتوفيرها بتكلفة معقولة. لذلك، فإن التحكم في نمو الدولة هو شرط أساسي وليس تحسينًا اختياريًا.
لتحديد النقطة الحرجة للمشكلة، نقوم بإجراء اختبارات التحمل بشكل فعال:
متى يصبح نمو الدولة بمثابة عنق الزجاجة؟
متى يجعل حجم الحالة من الصعب على العقد أن تتبع رأس السلسلة؛
عندما تفشل تطبيقات العميل على مقاييس الحالة المتطرفة.
<ب>التحدي الثاني: في البنية عديمة الجنسية، من المسؤول عن تخزين الحالة وتوفيرها؟
حتى لو حافظت إيثريوم على الحد الأقصى الحالي للغاز بشكل دائم، فسنواجه في النهاية مشكلة تضخم الدولة. وفي الوقت نفسه، من الواضح أن المجتمع يتوقع إنتاجية أعلى.
تزيل المخططات عديمة الجنسية قيدًا كبيرًا: لا يحتاج المدققون إلى الاحتفاظ بالحالة الكاملة للتحقق من صحة الكتل، بل يحتاجون فقط إلى البراهين.يعد هذا إنجازًا مهمًا في قابلية التوسع يلبي حاجة المجتمع إلى إنتاجية أعلى ويكشف عن حقيقة كانت مخفية في السابق وهي أن تخزين الحالة يمكن أن يتطور إلى وظيفة مستقلة وأكثر تخصصًا، بدلاً من ربطه بكل أداة تحقق.
عند هذه النقطة، قد يتم تخزين معظم الحالة فقط من خلال:
منشئ الكتلة؛
مزود خدمة RPC؛
مشغلون محترفون آخرون (مثل باحثي MEV ومستكشفي الكتل).
بمعنى آخر، ستصبح الدولة أكثر مركزية.
وهذا له عواقب متعددة:
زيادة صعوبة المزامنة: قد يبدأ مقدمو الخدمة المركزيون في تقييد الوصول إلى الحالة، مما يجعل من الصعب على مقدمي الخدمة الجدد البدء؛
ضعف مقاومة الرقابة: إذا لم يكن من الممكن الحصول على بيانات الحالة الخاضعة للرقابة، فقد تفشل آليات مكافحة الرقابة مثل FOCIL؛
خطر مرونة النظام: إذا قام عدد قليل من الكيانات فقط بتخزين الحالة الكاملة وتوفيرها، فإن انقطاع الخدمة أو الضغط الخارجي سيؤدي بسرعة إلى قطع الوصول إلى معظم مكونات النظام البيئي.
على الرغم من أن العديد من الكيانات تخزن الحالة، فلا توجد طريقة فعالة للتحقق من أنها تقدم الخدمات بالفعل، كما أن الحوافز الحالية غير كافية.يتم دعم مزامنة اللقطات على نطاق واسع بشكل افتراضي، ولكن خدمات RPC ليست كذلك.وبدون تخفيض تكلفة خدمات الدولة وزيادة جاذبيتها العالمية، فإن قدرة الشبكة على الوصول إلى حالتها الخاصة سوف تقتصر على عدد صغير من مقدمي الخدمة.
تؤثر هذه المشكلة أيضًا على شبكات الطبقة الثانية.تعتمد قدرة المستخدمين على فرض المعاملات المجمعة على الوصول الموثوق إلى حالة العقد المجمع على L1.إذا أصبح الوصول إلى حالة L1 هشًا أو شديد المركزية، فسيكون من الصعب تشغيل آليات صمام الأمان هذه في التطبيقات العملية.
<ب>3، الاتجاهات الثلاثة الرئيسية التي نراها
<ب>(1) فترة صلاحية الحالة
ليست كل بيانات الدولة ذات أهمية دائمة متساوية.يُظهر تحليلنا الأخير أنه لم يتم الوصول إلى ما يقرب من 80% من بيانات الدولة منذ أكثر من عام.ومع ذلك، لا تزال العقد تتحمل تكلفة تخزين هذه الحالة إلى الأبد.
الفكرة الأساسية لآلية صحة الحالة هي إزالة الحالة غير النشطة مؤقتًا من “المجموعة النشطة” ثم استعادتها من خلال شكل من أشكال الإثبات عند الضرورة.وبشكل عام، يمكن تقسيمهم إلى فئتين رئيسيتين:
<ب>الفئة 1: العلامة، البطلان، القيامة
بدلاً من التعامل مع جميع الحالات على أنها نشطة بشكل دائم، يضع البروتوكول الحالات التي نادرًا ما تستخدم على أنها غير نشطة بحيث لا تستمر في المجموعة النشطة التي تحتفظ بها كل عقدة، مع السماح باستعادتها في المستقبل من خلال إثبات تاريخي للوجود.التأثير العملي هو أن العقود والأرصدة شائعة الاستخدام تظل نشطة ولها تكاليف وصول منخفضة، في حين أن الحالات المنسية منذ فترة طويلة لا تحتاج إلى أن يتم حملها بشكل مستمر بواسطة كل عقدة ولا يزال من الممكن استرجاعها عندما يحتاجها شخص ما مرة أخرى.
<ب>الفئة 2: آلية الفشل متعدد الدورات
في التصميم متعدد الفترات، لا نبطل الإدخالات الفردية، ولكن نقسم الحالة بشكل دوري إلى فترات (على سبيل المثال، فترة واحدة = سنة واحدة).الدورة الحالية أصغر حجمًا ونشطة بالكامل، ويتم تجميد الدورة القديمة من منظور التنفيذ في الوقت الفعلي، ويتم كتابة الحالة الجديدة في الدورة الحالية.ولا يمكن استعادة الحالة القديمة إلا بإثبات وجودها في الدورة السابقة.
عادةً ما تكون آلية إبطال العلامة وإعادة البعث أكثر تعقيدًا وعملية الإعادة أكثر وضوحًا، لكن عملية وضع العلامات تتطلب تخزين بيانات وصفية إضافية.تعتبر حالات الفشل متعددة الدورات أبسط من الناحية المفاهيمية وأكثر تكاملاً بشكل طبيعي مع آليات الأرشفة، لكن إثباتات البعث تميل إلى أن تكون أكثر تعقيدًا وأكبر.
في نهاية المطاف، يشترك هذان النهجان في نفس الهدف – الحفاظ على مرونة الحالة النشطة عن طريق إزالة الأجزاء غير النشطة مؤقتًا مع توفير طريق إلى البعث – لكنهما يقومان بمقايضات مختلفة في التعقيد، وتجربة المستخدم، وتخصيص العمل للعملاء والبنية التحتية.
<ب>(2) أرشيف الحالة
يقوم أرشيف الحالة بتقسيم الحالة إلى حالة باردة وساخنة.
الحالات الساخنة هي أجزاء من الشبكة تتطلب الوصول المتكرر؛
الحالة الباردة هي الجزء الذي لا يزال مهمًا للتاريخ وقابلية التحقق ولكن نادرًا ما يتم التطرق إليه.
في تصميم أرشيف الحالة، ستقوم العقد بشكل صريح بتخزين الحالات الساخنة المستخدمة بشكل متكرر والبيانات التاريخية بشكل منفصل.وحتى مع استمرار نمو الحالة العامة، فإن الأجزاء التي يجب الوصول إليها بسرعة (مجموعات البيانات الساخنة) يمكن أن تظل محدودة الحجم.من الناحية العملية، هذا يعني أن أداء تنفيذ العقدة – وخاصة تكلفة الإدخال/الإخراج للوصول إلى الحالة – يمكن أن يظل مستقرًا بشكل أساسي بمرور الوقت، دون أن ينخفض مع تقدم السلسلة.
<ب>(3) خفض عتبة تخزين الدولة والخدمات
والسؤال الواضح هو: هل يمكننا تحقيق أهدافنا مع الاحتفاظ ببيانات أقل؟ بمعنى آخر، هل يمكن تصميم العقد والمحافظ بحيث لا تتطلب تخزينًا دائمًا للحالة الكاملة ولا تزال تعمل كمشاركين صالحين؟
أحد الاتجاهات الواعدة هو الحلول عديمة الجنسية جزئيًا:
تقوم العقد بتخزين وتوفير حالة جزئية فقط (مثل البيانات المتعلقة بمستخدم أو تطبيق معين)؛
تلعب المحافظ والعملاء الخفيفون دورًا أكثر نشاطًا في تخزين أجزاء الحالة المطلوبة وتخزينها مؤقتًا، بدلاً من الاعتماد بشكل كامل على عدد قليل من موفري خدمة RPC الكبار.إذا كان من الممكن توزيع التخزين بشكل آمن على المحافظ والعقد “المتخصصة”، فسيتم تقليل العبء الواقع على المشغلين الأفراد، وستصبح مجموعة أصحاب الدولة أكثر تنوعًا.
الاتجاه الآخر هو تقليل العوائق التي تحول دون تشغيل البنية التحتية المفيدة:
تبسيط عملية نشر عقد RPC التي تخدم جزءًا من الحالة فقط؛
تصميم البروتوكولات والأدوات التي تمكن المحافظ والتطبيقات من اكتشاف ودمج مصادر بيانات محلية متعددة بدلاً من الاعتماد على نقطة نهاية RPC كاملة واحدة.
<ب>4، الاتجاه المستقبلي
أصبحت حالة Ethereum بهدوء هي المفتاح للعديد من القضايا الأساسية لمستقبل البروتوكول:
إلى أي مدى يصبح زيادة حجم الدولة عائقًا أمام المشاركة؟
عندما يتمكن المدققون من التحقق من صحة الكتل بأمان دون الحاجة إلى حالة، فمن الذي سيقوم بتخزين الحالة؟
من سيقدم خدمات الحالة للمستخدمين؟ما هو الحافز؟
لم يتم تحديد بعض المشكلات بعد، ولكن الاتجاه واضح: تقليل القيود التي تفرضها الحالة على الأداء، وتقليل تكاليف التخزين، وتحسين إمكانية الوصول إلى الخدمة.
ينصب تركيزنا الحالي على تطوير العمل منخفض المخاطر والعائد المرتفع:
<ب>مخطط الأرشفة
نحن نحاول استخدام حلول خارج البروتوكول للتحكم في حجم الحالة النشطة مع الاعتماد على حلول الأرشفة لتخزين البيانات التاريخية.سيوفر هذا بيانات واقعية عن الأداء وتجربة المستخدم والتعقيد التشغيلي.إذا كان التحقق صالحًا، فيمكن ترقيته إلى ترقية داخل البروتوكول إذا لزم الأمر.
<ب>بعض العقد عديمة الحالة وتحسينات RPC
يتفاعل معظم المستخدمين والتطبيقات مع Ethereum من خلال موفري خدمة RPC المركزيين.نحن نعمل على التحسينات التالية:
تقليل صعوبة وتكلفة تشغيل العقد، حتى لو كانت العقد لا تخزن كل الحالة؛
السماح للعقد المتعددة بالتعاون لتقديم خدمات الحالة الكاملة؛
قم بزيادة تنوع موفري خدمة RPC وتجنب الاختناقات ذات النقاط الفردية.
لقد تم اختيار هذه المشاريع بعناية لفائدتها الفورية وتوافقها مع التطلعات المستقبلية: فهي ستعمل على تعزيز صحة Ethereum الحالية وتضع الأساس لإجراء ترقيات أعمق للبروتوكول في المستقبل.
