شكر خاص لفيدي، دانو فيرين، جستن دريك، لاديسلاوس، وتيم بيكو على ملاحظاتهم ومراجعتهم.

هدف إثريوم هو أن يصبح دفترًا عالميًا - منصة تحمل أصول البشر وسجلاتهم، وتعتبر الطبقة الأساسية لتطبيقات مثل الخدمات المالية، والحوكمة، والتحقق من البيانات ذات القيمة العالية. لتحقيق هذا الهدف، يجب أن يكون لديها كل من التوسعة والصمود. سيزيد خطة فوساكا للشوكة الصعبة مساحة توافر البيانات L2 بمقدار 10 مرات، بينماالخريطة الزمنية المقترحة لعام 2026تتضمن أيضًا مقياس مماثل لتوسيع بيانات L1. في الوقت نفسه، تمت ترقية 'الدمج' لإثريوم إلى آلية توافق دليل الحصة (PoS)تزايد سريع في تنوع العملاء, تقدم تواصلي (Zero-Knowledge Proof) ومقاومتها للهجمات الكمية بشكل مطرد، ونظام البيئة التطبيقية يتقدم بشكل متزايدناضجة وقوية.

الهدف من هذا المقال هو التأكيد على شيء مهم بنفس القدر ولكن غالبًا ما يُستهان بهالصمود (وفي نهاية المطاف التوسع)العناصر:
بساطة البروتوكول.

أحد أكثر الجوانب المُثناة في بيتكوين هو تصميم بروتوكوله، الذي يعتبر أنيقًا للغاية وبسيطًا:

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

الحفاظ على البروتوكول بسيط يجلب سلسلة من المزايا الرئيسية، مما قد يجعل بيتكوين وإيثيريومالحياد الموثوق بهالطبقة الأساسية للثقة العالمية:

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

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

الطبقة المبسطة للتوافق

3-slot finality（3槽终结性）مخطط محاكاة —3sf-mini

يهدف تصميم طبقة الاتفاق الجديدة (المعروفة سابقًا باسم ‘شعاع السلسلة’) إلى دمج التجربة التي اكتسبناها في نظرية الاتفاق وتطوير ZK-SNARK واقتصاد الرهان ومجالات أخرى على مدى العقد الماضي، لإنشاء طبقة اتفاق Ethereum الأمثل على المدى الطويل. من المتوقع أن تحقق هذه الطبقة الجديدة للاتفاق بساطة أعلى مقارنة بسلسلة Beacon الحالية. ويظهر ذلك بشكل خاص في:

• إعادة هيكلة النهوض النهائي 3 فتحة
  تقوم هذه التصميمات بالتخلص من التمييز بين 'الفتحة' و 'العصر'، وتبديل اللجان، وتفاصيل المواصفات الأخرى المتعلقة بهذه الآليات (مثل اللجان المتزامنة). إصدار أساسي للاستقرار بثلاث فتحات،مطلوب فقط حوالي 200 سطر من الشيفرةيمكن تحقيقه. مقارنة ببروتوكول Gasper الحالي، الذي يتمتع بثبات 3 فتحات، يكون لديه أيضًا أمان قريب من الأمان الأمثل.
• عدد المحققين النشطين قد انخفض
  يجعل من الأمر أكثر أمانًا وجدوى اعتماد قاعدة اختيار فورك أبسط.
• بروتوكول تجميع يعتمد على STARK
  يعني أن أي شخص يمكنه أن يصبح مجمع دون القلق بشأن الثقة في المجمع، الرسوم الزائدة لحقول البت المتكررة، إلخ. على الرغم من أن تشفير التجميع نفسه لديه بعض التعقيد، هذاتعقيد مغلف بشكل كبيرالمخاطرة النظامية الشاملة للبروتوكول أقل بكثير.
• النقطتان أعلاه من المحتمل أيضًا دعم بنية تحتية نظير إلى نظير (p2p) أكثر بساطة وقوة.
• لدينا الفرصة لإعادة التفكير في آليات دخول المحقق، والخروج، والسحب، وتبديل المفتاح، وعقوبة اللامبالاة، وما إلى ذلك، وتبسيطها - ليس فقط تقليل عدد الأسطر من الشفرة (LoC)، ولكن أيضًا توفير ضمانات آلية أوضح، مثل موعد 'الموضوعية الضعيفة' أكثر صرامة.

ميزة طبقة الاتفاق هي أنها مفصولة نسبيًا عن تنفيذ EVM، لذلك لدينا الكثير من المجال لمواصلة دفع هذه التحسينات للأمام.
أكثر تحديًا هو: كيفية تحقيق نفس التبسيط على مستوى التنفيذ.

تبسيط طبقة التنفيذ

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

محاولة إصلاح هذه المشاكل العملية تدريجيًا ليست ممكنة.إزالة @vbuterinتستهلك تعليمات SELFDESTRUCT كمية هائلة من الطاقة، ولكن النتائج محدودة. يظهر النقاش الأخير حول EOF (تنسيق كائن EVM) صعوبة إجراء تغييرات مماثلة على الجهاز الظاهري بوضوح أكبر.

لذلك، كبديل، قدمت مؤخرًا فكرة أكثر جذرية: بدلاً من إجراء تغييرات تدريجية (لكنها لا تزال مدمرة) لتحقيق تحسين بنسبة 1.5 مرة، فمن الأفضل الانتقال مباشرة إلى آلة افتراضية جديدة تمامًا، أفضل بكثير وأبسط، بهدف الحصول على عائد بنسبة 100 مرة. تمامًا مثل 'الدمج'، نقلل عدد التحويلات، لكن كل واحدة منها ذات أهمية كبيرة. بشكل محدد، أقترح استبدال EVM الحالي بـ RISC-V (أو آلة افتراضية أخرى ستُستخدم من قِبل منفذ ZK لإيثريوم). بهذه الطريقة، سنحقق:

• تحسين كفاءة كبير: لأن العقود الذكية يمكن أن تعمل مباشرة في البرهان دون تكلفة الجهاز المترجم. البيانات الموجزة تشير إلى أن الأداء يمكن تحسينه بأكثر من 100 مرة في العديد من السيناريوهات.
• البساطة المطلقة: مقارنة بمواصفات RISC-V بالنسبة إلى EVMبسيط للغاية. الحلول البديلة الأخرى (مثل القاهرة) موجزة بالمثل.
• ميراث الفوائد المتوقعة لـ EOF: مثل تقسيم الكود، تحليل ثابت أكثر ودية، حد أكبر لسعة الكود، إلخ.
• لدى المطورين المزيد من الخيارات: يمكن تجميع Solidity و Vyper إلى الخلفية الجديدة للجهاز الظاهري. إذا تم اختيار RISC-V، يمكن لمطوري اللغات الرئيسية أيضًا نقل كودهم بسهولة.
• تقليل بشكل كبير لحاجة البيانات المُعدّة مُسبقًا: ربما يتم الاحتفاظ بعدد قليل فقط من عمليات منحنى الكريات البيضاء المُحسنة بشكل كبير (على الرغم من أنها لن تعود موجودة بعد انتشار الحوسبة الكمية).

العيب الرئيسي لهذا النهج هو أنه، على عكس EOF (يمكن نشره على الفور)، يستغرق إنشاء الجهاز الظاهري الجديد وقتًا أطول للاستفادة منه من قبل المطورين. للتخفيف من ذلك، يمكننا أن نقدم بعض التحسينات الصغيرة ولكن ذات القيمة العالية في EVM على المدى القصير.زيادة حد حجم كود العقدزيادة تعليمات DUP/SWAP17-32، إلخ.

في نهاية المطاف، سيمنحنا هذا آلة افتراضية مبسطة للغاية. ولكن أكبر سؤال هو: ماذا عن EVM الحالي؟

استراتيجية التوافق الخلفي الانتقالية لـ VM

عند تبسيط المعنى (أو حتى تحسينه دون إضافة تعقيد) لأي جزء من آلة الإثيريوم الافتراضية (EVM)، أكبر تحدي هو: كيفية الحفاظ على التوافق مع التطبيقات الحالية مع تحقيق الهدف.

أولاً، يجب أن يكون من الواضح أنه ليس هناك طريقة واحدة لتحديد نطاق "قاعدة Ethereum" (حتى داخل نفس العميل).

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

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

الفئة الجديدة هي المنطقة الصفراء: هذا النوع من الرمز مهم جدًا لفهم وتحليل حالة السلسلة الحالية، ولبناء أفضل الكتل، لكنه ليس جزءًا من التوافق. مثال Etherscan(وبعضبناء الكتل) دعم عمليات المستخدم لـ ERC-4337. إذا استخدمنا تنفيذ RISC-V on-chain لاستبدال وظائف Ethereum الكبيرة المعينة (مثل حسابات EOA ودعمها لمختلف أنواع المعاملات القديمة) ، فإنه على الرغم من تبسيط كبير في رمز الاتفاق ، قد يستمر بعض العقد المهنية في استخدام الرمز الأصلي لتحليل هذه الوظائف.

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

نقل الرمز من المنطقة الخضراء إلى المنطقة الصفراء، هذا النهج مشابه لشركة Gate Inc.ترجمة من خلال طبقة الترجمة روزيتالضمان التوافق على المدى الطويل.

لقد اقترحت (اقترضت من@ipsilon/eof-ethereums-gateway-to-risc-v”> آراء فريق Ipsilon الأخيرة) عملية ترحيل آلة افتراضية التالية (استخدام ترحيل EVM إلى RISC-V كمثال، ولكنها قابلة أيضًا لترحيل EVM إلى Cairo، وحتى ترحيل مستقبلي إلى آلة افتراضية أكثر أمثل):

1. يجب كتابة جميع البرامج الامتيازية الجديدة بتنفيذ RISC-V القياسي على السلسلة الرئيسية، حتى يمكن للنظام البيئي أن يبدأ في التعود واستخدام RISC-V كجهاز افتراضي.
2. تقديم RISC-V كخيار لتطوير العقود بجانب EVM للمطورين. يدعم البروتوكول بشكل طبيعي كل من RISC-V و EVM، مما يتيح للعقود المكتوبة بكلا اللغتين التفاعل بحرية.
3. استبدال جميع الجاهزين (باستثناء عمليات المنحنى البيضاوي وKECCAK) بتنفيذ RISC-V. نقوم بإزالة هذه الجاهزين من خلال شوكة صعبة وفي نفس الوقت نقوم بتغيير الشيفرة في العنوان المقابل (بنمط شوكة DAO) لتكون تنفيذ RISC-V. نظرًا لأن آلة القياس RISC-V موجزة للغاية، حتى فقط فعل هذا يبسط الهيكل الكلي.
4. نفذ مُترجم EVM مكتوب بلغة RISC-V ونشِّئه كعقد ذكي على السلسلة. بعد عدة سنوات من الإصدار الأولي، ستُعالج العقود الحالية لـ EVM من خلال هذا المترجم.

بعد إكمال الخطوة 4، سيظل هناك العديد من 'تنفيذات EVM' التي ستستمر في الاستخدام لتحسين بناء الكتل، وأدوات التطوير، والتحليل على السلسلة، ولكنها لن تكون جزءًا من المواصفات الرئيسية للتوافق. في ذلك الوقت، ستفهم توافقية Ethereum 'بشكل أصلي' فقط RISC-V.

بسط من خلال مشاركة مكونات البروتوكول

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

كود موحد للمحو

نحتاج إلى تصحيح رمز الحذف في ثلاث سيناريوهات:

• عينات توافر البيانات - يتحقق العميل مما إذا تم نشر الكتلة
• بث P2P أسرع - يمكن للعقد قبول الكتل بعد استلام n/2 من n كتلة، مما يؤسس التوازن المثالي بين تقليل التأخر والتكرار.
• تخزين التاريخ الموزع - يتم تخزين كل قطعة من تاريخ الإيثريوم في العديد من الكتل، لذلك (i) يمكن التحقق من هذه الكتل بشكل مستقل، و (ii) يمكن لنصف الكتل في كل مجموعة استعادة النصف الباقي، مما يقلل بشكل كبير من مخاطر فقدان أي كتلة واحدة.

إذا استخدمنا نفس رمز المحو (سواء كان ريد-سولومون، أو رمز خطي عشوائي، أو غير ذلك) في ثلاث حالات استخدام، سنحصل على بعض المزايا الهامة:

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

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

تنسيق تسلسل موحد

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

• التجريب الشامل للتجريف (EIP-7701): ستكون الآلة الظاهرية قادرة على رؤية محتوى الصفقة الكامل
• زيادة حد الغاز: تنفيذ بيانات الكتلة يجب أن يتم تعبئتها في تجمع

في ذلك الوقت، لدينا الفرصة لتوحيد حلول التسلسل اللازمة للجوانب الثلاث الحالية: 1) طبقة التنفيذ؛ 2) طبقة الاتفاق؛ 3) واجهة ABI لاستدعاء العقود الذكية.

أقترح تبني GateSSZ(تسلسل بسيط)، لأن SSZ لديها المزايا التالية:

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

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

هيكل شجرة موحد

بمجرد أن نهاجر من EVM إلى RISC-V (أو غيرها من أجهزة الظاهرة البسيطة)، ستصبح شجرة Merkle Patricia السد الأكبر لإثبات تنفيذ الكتلة، حتى في السيناريوهات المتوسطة. الانتقال إلى وظيفة تجزئةشجرة ثنائية، سيحسن بشكل كبير كفاءة المحقق ويقلل من تكلفة البيانات للعقد الخفيفة وسيناريوهات أخرى.

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

من الآن وحتى المستقبل

التبسيط واللامركزية لهما العديد من أوجه التشابه. كلاهما من المتطلبات الأولية اللازمة لتحقيق الهدف الأسمى المتمثل في مرونة النظام. يتطلب التأكيد على التبسيط صراحة تحولا ثقافيا. غالبا ما يصعب رؤية فوائد التبسيط في المراحل المبكرة ، لكن تكاليف الفرصة البديلة وعبء العمل الإضافي لرفض تلك "الميزات الجديدة اللامعة" واضحة على الفور. ومع ذلك ، بمرور الوقت ، تصبح القيمة طويلة الأجل للتبسيط واضحة بشكل متزايد - تعد Bitcoin نفسها مثالا ممتازا.

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

تنصل:

1. أعيد طبع هذه المقالة من [vitalik]. جميع حقوق الطبع والنشر مملوكة للمؤلف الأصلي [فيتاليكالكل. إذا كان لديك أي اعتراض على هذا الإعادة، يرجى التواصلبوابة التعلمسيتولى الفريق التعامل معه في الوقت المناسب.
2. تنويه: الآراء والآراء الواردة في هذه المقالة هي فقط تلك للكاتب ولا تشكل أي نصيحة استثمارية.
3. يترجم فريق Gate Learn المقالات إلى لغات أخرى. يُحظر نسخ أو توزيع أو نسخ المقالات المترجمة دون إذن خاص.