فيتاليك: كيف نجعل الإيثريوم بسيطًا مثل البيتكوين في خمس سنوات

المؤلف: فيتاليك بوتيرين؛ المترجم: غاري ما وو يتحدث عن تقنية البلوك تشين

ملخص

يهدف الإيثريوم إلى أن يصبح دفتر حسابات عالمي، وهو ما يتطلب القدرة على التوسع والمرونة. تسلط هذه المقالة الضوء على أهمية بساطة البروتوكول وتقترح تقليل التعقيد وتكاليف التطوير ومخاطر الأخطاء وأسطح الهجوم بشكل كبير من خلال تبسيط طبقة الإجماع (النهائية ثلاثية الفتحات، وتجميع STARK) وطبقة التنفيذ (استبدال EVM بـ RISC-V أو آلات افتراضية مماثلة). يوصى بتسهيل الانتقال من خلال استراتيجيات متوافقة مع الإصدارات السابقة (مثل مفسر EVM على السلسلة)، وتوحيد رموز المسح، وتنسيقات التسلسل (SSZ)، وهياكل الشجرة لمزيد من التبسيط. الهدف هو جعل كود Ethereum الحاسم للإجماع قريبًا من بساطة Bitcoin، وتحسين المرونة والمشاركة، ويتطلب ثقافة تقدر البساطة وتحدد هدفًا أقصى لسطر من الكود.

الهدف من الإيثريوم هو أن يصبح دفترًا عالميًا: منصة لتخزين الأصول وسجلات الحضارة الإنسانية، وخدمة مجالات التمويل والحوكمة ومصادقة البيانات عالية القيمة. ويتطلب هذا الدعم في جانبين: القدرة على التوسع والمرونة. تخطط شوكة Fusaka الصلبة لزيادة المساحة المتاحة لبيانات L2 بمقدار 10 مرات، وتخطط خريطة الطريق الحالية المقترحة لعام 2026 أيضًا لإدخال تحسينات كبيرة مماثلة على طبقة L1. في الوقت نفسه، أكملت Ethereum انتقالها إلى Proof of Stake (PoS)، وزاد تنوع العملاء بسرعة، كما يتقدم التحقق من المعرفة الصفرية (ZK) وأبحاث المقاومة الكمومية بشكل مطرد، وأصبح نظام التطبيق قويًا بشكل متزايد.

تهدف هذه المقالة إلى التركيز على عامل مهم بنفس القدر ولكنه غير مقدر من حيث المرونة (وحتى قابلية التوسع):

بساطة البروتوكول.

الشيء الأكثر إثارة للدهشة في بروتوكول البيتكوين هو بساطته الأنيقة:

1. هناك سلسلة من الكتل، كل كتلة متصلة بالكتلة السابقة من خلال التجزئة.

2. يتم التحقق من صحة الكتلة من خلال إثبات العمل (PoW)، وهو التحقق مما إذا كانت الأرقام القليلة الأولى من قيمة التجزئة تساوي صفرًا.

3. تحتوي كل كتلة على معاملات، والعملات المعدنية التي يتم إنفاقها في المعاملات تأتي إما من مكافآت التعدين أو من مخرجات المعاملات السابقة.

هذا كل شيء! حتى طالب المدرسة الثانوية الذكي يمكنه أن يفهم تمامًا كيفية عمل بروتوكول Bitcoin، ويمكن للمبرمج أيضًا أن يكتب عميلًا كمشروع جانبي.

إن بساطة البروتوكول تجلب العديد من المزايا الرئيسية إلى Bitcoin (وEthereum) باعتبارها طبقة أساسية عالمية محايدة وموثوقة:

1. سهولة الفهم: يقلل من تعقيد البروتوكول، مما يسمح لمزيد من الأشخاص بالمشاركة في أبحاث البروتوكول وتطويره وحوكمته، ويقلل من خطر هيمنة النخبة التقنية.

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

3. تقليل عبء الصيانة: تقليل تكلفة صيانة الاتفاقية طويلة الأمد. 4. تقليل مخاطر الأخطاء: تقليل احتمالية حدوث أخطاء كارثية في مواصفات البروتوكول وتنفيذاته، وتسهيل التحقق من عدم وجود مثل هذه الأخطاء.

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

طبقة إجماع مبسطة

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

2. تقليل عدد المحققين النشطين: يسمح باستخدام تنفيذات قواعد اختيار الشوكة الأكثر بساطة ويعزز الأمان.

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

4. تبسيط بنية شبكة نظير إلى نظير:قد تدعم العوامل المذكورة أعلاه بنية شبكة نظير إلى نظير أبسط وأكثر قوة.

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

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

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

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

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

1. تم تحسين الكفاءة بشكل كبير: لا يتطلب تنفيذ العقد الذكي (في المُثبِّت) تكلفة إضافية للمترجم ويتم تشغيله مباشرة. تظهر بيانات Succinct أنه من الممكن تحسين الأداء بما يزيد عن 100 مرة في العديد من السيناريوهات.

2. تحسن كبير في البساطة: مواصفات RISC-V بسيطة للغاية مقارنة بـ EVM، والبدائل (مثل القاهرة) بسيطة بنفس القدر.

3. دوافع دعم EOF: مثل تقسيم الكود، والتحليل الثابت الأكثر سهولة، وحد أقصى لحجم الكود، وما إلى ذلك. 4. مزيد من خيارات المطورين: يمكن لـ Solidity و Vyper إضافة واجهات خلفية للتجميع إلى آلات افتراضية جديدة. إذا اخترت RISC-V، فيمكن لمطوري اللغات السائدة أيضًا نقل الكود الخاص بهم بسهولة إلى هذه الآلة الافتراضية. 5. إزالة معظم التجميع المسبق: ربما سيتم الاحتفاظ فقط بعمليات المنحنى الإهليلجي المحسّنة للغاية (حتى هذه العمليات سوف تختفي بعد أن تصبح أجهزة الكمبيوتر الكمومية شائعة). العيب الرئيسي هو أنه على عكس EOF الجاهز للاستخدام، فإن فوائد VM الجديدة تستغرق وقتًا أطول حتى تصل إلى المطورين. يمكننا التخفيف من حدة هذه المشكلة من خلال تنفيذ تحسينات EVM عالية القيمة على المدى القصير (مثل زيادة حدود حجم رمز العقد ودعم DUP/SWAP17–32).

سيؤدي هذا إلى إنشاء آلة افتراضية أبسط. التحدي الأساسي هو: كيفية التعامل مع آلة التصويت الإلكترونية الحالية؟

استراتيجية التوافق مع الإصدارات السابقة للانتقال إلى الآلة الافتراضية

إن التحدي الأكبر في تبسيط (أو تحسين دون زيادة التعقيد) الآلة الافتراضية هو كيفية موازنة التنفيذ المستهدف مع التوافق مع الإصدارات السابقة للتطبيقات الحالية.

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

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

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

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

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

إن فكرة نقل الكود من المنطقة الخضراء إلى المنطقة الصفراء تشبه استراتيجية Apple في ضمان التوافق مع الإصدارات السابقة على المدى الطويل من خلال طبقة الترجمة Rosetta.

مستوحاة من المقالة الأخيرة لفريق Ipsilon، أقترح عملية تغيير الآلة الافتراضية التالية (أخذ EVM إلى RISC-V كمثال، ولكن يمكن استخدامها أيضًا لـ EVM إلى Cairo أو RISC-V إلى آلة افتراضية أفضل):

1. تتطلب التجميع المسبق الجديد لتوفير تنفيذ RISC-V على السلسلة: دع النظام البيئي يتكيف تدريجيًا مع الآلة الافتراضية RISC-V.

2. تقديم RISC-V كخيار للمطور: يدعم البروتوكول كل من RISC-V وEVM، ويمكن لعقود الآلتين الظاهريتين التفاعل بحرية.

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

4. تنفيذ مفسّر EVM في RISC-V: على السلسلة كعقد ذكي (تم ذلك بالفعل بسبب متطلبات ZK Prover). بعد عدة سنوات من الإصدار الأولي، يتم تشغيل عقود EVM الموجودة من خلال هذا المترجم.

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

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

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

رمز مسح موحد

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

1. أخذ العينات من توفر البيانات: يتحقق العميل من نشر الكتلة.

2. بث أسرع من نظير إلى نظير: يمكن للعقدة قبول كتلة بعد تلقي n/2 قطعة، مما يحقق التوازن بين زمن الوصول والتكرار.

3. التخزين التاريخي الموزع: يتم تخزين بيانات الإيثريوم التاريخية في شظايا، ويمكن لكل مجموعة من n/2 شظايا استعادة الشظايا المتبقية، مما يقلل من خطر فقدان شظية واحدة.

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

1. تقليل كمية الكود : تقليل العدد الإجمالي لأسطر الكود.

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

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

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

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

2. حد غاز أعلى: يجب وضع بيانات طبقة التنفيذ في كتل البيانات (الكتل). بحلول ذلك الوقت، سوف تتاح لنا الفرصة لتوحيد تنسيقات التسلسل للمستويات الثلاثة من Ethereum: طبقة التنفيذ، وطبقة الإجماع، وواجهة ABI لاستدعاء العقد الذكي.

أقترح استخدام  SSZلأن SSZ:

1. سهل فك التشفير: مضمن في العقود الذكية (بسبب تصميمه القائم على 4 بايت وحالات الحافة الأقل).

2. لقد تم استخدامه على نطاق واسع في طبقة الإجماع.

3. مشابه إلى حد كبير لـ ABI الحالي: يعد تكييف الأداة بسيطًا نسبيًا.

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

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

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

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

من الآن إلى المستقبل

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