إثيريوم المستقبل: ترقية EVM وتجريد الحساب يقودان ازدهار البروتوكول

مستقبل بروتوكول إثيريوم المحتمل (6): الازدهار

كتبه: فيتاليك بوتيرين

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

الازدهار: الهدف الرئيسي

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

فيتالك حول إثيريوم المحتمل في المستقبل (6): الازدهار

تحسين EVM

ماذا حلت هذه المشكلة؟

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

ما هو، وكيف يعمل؟

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

  • فصل بين الكود (قابل للتنفيذ، ولكن لا يمكن قراءته من EVM) والبيانات (يمكن قراءتها، ولكن لا يمكن تنفيذها)
  • يمنع الانتقال الديناميكي، يُسمح فقط بالانتقال الثابت
  • لا يمكن لرمز EVM مراقبة المعلومات المتعلقة بالوقود
  • تم إضافة آلية جديدة صريحة لروتينات فرعية

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

فيتاليك حول إثيريوم المحتمل في المستقبل (6): The Splurge

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

فكرة جديدة نسبياً هي دمج EVM-MAX مع خاصية التعليمات المتعددة (SIMD) ، وقد كانت SIMD كفكرة في إثيريوم موجودة منذ فترة طويلة ، حيث اقترحها Greg Colvin في EIP-616. يمكن استخدام SIMD لتسريع العديد من أشكال التشفير ، بما في ذلك دوال التجزئة و 32 بت STARKs والتشفير القائم على الشبكات ، إن دمج EVM-MAX و SIMD يجعل من هذين التوسعين المدفوعين بالأداء ثنائياً طبيعياً.

تصميم تقريبي لمجموعة EIP سيبدأ من EIP-6690 ثم:

  • يسمح (i) بأي عدد فردي أو (ii) أي قوة من 2 لا تتجاوز 2768 كعدد مودي
  • بالنسبة لكل عملية EVM-MAX (الجمع، الطرح، الضرب)، أضف إصدارًا لا يستخدم 3 ثوابت فورية x، y، z، بل يستخدم 7 ثوابت فورية: x_start، x_skip، y_start، y_skip، z_start، z_skip، count. في كود بايثون، تعمل هذه العمليات كالتالي:

بالنسبة لأنا في range(count): mem[z_start + z_skip * العدد] = op( mem [x_start + x_skip * عدد] ، [y_start + y_skip * عدد] )

في التطبيق العملي، سيتم معالجة ذلك بطريقة متوازية.

  • من الممكن إضافة XOR و AND و OR و NOT و SHIFT (بما في ذلك الدوران وغير الدوراني) ، على الأقل لنمط 2. في نفس الوقت ، إضافة ISZERO (الذي سيدفع الإخراج إلى مكدس EVM الرئيسي) ، سيكون هذا قويًا بما يكفي لتنفيذ التشفير باستخدام منحنيات إهليلجية ، والتشفير في المجالات الصغيرة (مثل Poseidon و Circle STARKs) ، ودوال التجزئة التقليدية (مثل SHA256 و KECCAK و BLAKE) ، والتشفير القائم على الشبكات. قد يتم تنفيذ ترقيات أخرى لـ EVM أيضًا ، ولكن حتى الآن كانت أقل اهتمامًا.

روابط الأبحاث الحالية

  • EOF:
  • EVM-MAX:
  • SIMD:

العمل المتبقي والتوازن

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

الاعتبارات الرئيسية لـ EVM هي تعقيد L1 وتعقيد البنية التحتية، EOF هو كمية كبيرة من الشيفرة التي تحتاج إلى إضافتها إلى تنفيذ EVM، كما أن فحص الشيفرة الثابتة معقد نسبيًا. ومع ذلك، كتعويض، يمكننا تبسيط اللغات العالية المستوى، تبسيط تنفيذ EVM وغيرها من الفوائد. يمكن القول إن الأولويات في خريطة طريق التحسين المستمر لـ إثيريوم L1 يجب أن تشمل وتبنى على EOF.

تتمثل إحدى المهام المهمة في تحقيق وظائف مشابهة لـ EVM-MAX مع SIMD، وإجراء اختبارات مرجعية لاستهلاك الغاز لعمليات التشفير المختلفة.

كيف تتفاعل مع الأجزاء الأخرى من خريطة الطريق؟

تقوم L1 بتعديل EVM الخاص بها مما يتيح لـ L2 إجراء تعديلات مناسبة بشكل أسهل، وإذا لم يتم إجراء تعديلات متزامنة بين الطرفين، فقد يؤدي ذلك إلى عدم التوافق مما يسبب آثار سلبية. بالإضافة إلى ذلك، يمكن أن تقلل EVM-MAX و SIMD من تكاليف الغاز للعديد من أنظمة الإثبات، مما يجعل L2 أكثر كفاءة. كما أنه يجعل من الأسهل استبدال المزيد من الترجمة المسبقة بكود EVM يمكنه تنفيذ نفس المهام، مما قد لا يؤثر بشكل كبير على الكفاءة.

فيتاليك حول مستقبل إثيريوم المحتمل (6): The Splurge

تجريد الحساب

ما هي المشكلة التي تم حلها؟

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

  • التبديل إلى تشفير مقاوم للكم
  • استبدال المفاتيح القديمة (يعتبر على نطاق واسع ممارسة أمان موصى بها)
  • محفظة متعددة التوقيعات ومحفظة استرداد اجتماعي
  • استخدم مفتاحًا واحدًا للعمليات منخفضة القيمة ، واستخدم مفتاحًا آخر (أو مجموعة من المفاتيح) للعمليات عالية القيمة

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

منذ طرح فكرة تجريد الحسابات في عام 2015، توسعت أهدافها لتشمل العديد من "أهداف الراحة"، على سبيل المثال، يمكن لحساب لا يحتوي على ETH ولكنه يملك بعض ERC20 دفع رسوم الغاز باستخدام ERC20. فيما يلي ملخص لهذه الأهداف:

فيتاليك حول مستقبل إثيريوم المحتمل (ستة): The Splurge

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

EIP-7702 هو اقتراح مخطط لإدخاله في الانقسام الصعب التالي، EIP-7702 هو نتيجة للاعتراف المتزايد بتوفير سهولة تجريد الحسابات لصالح جميع المستخدمين (بما في ذلك مستخدمي EOA)، ويهدف إلى تحسين تجربة جميع المستخدمين على المدى القصير وتجنب الانقسام إلى نظامين بيئيين.

بدأ هذا العمل في EIP-3074 وأدى في النهاية إلى تشكيل EIP-7702. يوفر EIP-7702 "وظائف الراحة" للتجريد الحسابي لجميع المستخدمين، بما في ذلك حسابات EOA (الحسابات المملوكة خارجيًا، أي الحسابات التي يتم التحكم فيها بواسطة توقيع ECDSA).

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

ما هو، كيف يعمل؟

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

تحدي رئيسي نموذجي هو مشكلة الفشل المتعدد:

إذا كانت هناك 1000 دالة تحقق للحسابات تعتمد على قيمة واحدة معينة S، وحاليًا القيمة S تجعل المعاملات في مجموعة الذاكرة صالحة، فإن وجود معاملة واحدة تقلب قيمة S قد يجعل جميع المعاملات الأخرى في مجموعة الذاكرة غير صالحة. وهذا يمكّن المهاجمين من إرسال معاملات غير مجدية إلى مجموعة الذاكرة بتكلفة منخفضة جدًا، مما يؤدي إلى انسداد موارد عقد الشبكة.

بعد سنوات من الجهود، تهدف إلى توسيع الوظائف مع تقييد مخاطر رفض الخدمة (DoS)، تم التوصل في النهاية إلى حل لتحقيق "تجريد الحساب المثالي": ERC-4337.

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

تم تصميم ERC-4337 كمعيار بروتوكول إضافي (ERC) ، لأن مطوري عملاء إيثريوم في ذلك الوقت كانوا يركزون على الدمج (Merge) ، ولم يكن لديهم طاقة إضافية للتعامل مع وظائف أخرى. لذلك ، استخدم ERC-4337 كائنات تُسمى "عمليات المستخدم" بدلاً من المعاملات العادية. ومع ذلك ، أدركنا مؤخرًا الحاجة إلى كتابة جزء من هذا المحتوى على الأقل في البروتوكول.

السببين الرئيسيين هما كما يلي:

  1. EntryPoint ككفاءة منخفضة متأصلة في العقد: كل حزمة تحمل تكلفة ثابتة تبلغ حوالي 100,000 غاز، بالإضافة إلى آلاف الغاز الإضافية لكل عملية مستخدم.
  2. تأكد من ضرورة خصائص إثيريوم: مثل قائمة التأمين التي تم إنشاؤها والتي تحتاج إلى التحويل إلى حساب المستخدم المجرد.

بالإضافة إلى ذلك، قام ERC-4337 بتوسيع وظيفتين:

  • وكلاء الدفع (Paymasters): يسمح لحساب واحد بتمثيل حساب آخر لدفع الرسوم، وهذا يتعارض مع القاعدة التي تنص على أن مرحلة التحقق يمكن أن تصل فقط إلى حساب المرسل نفسه، لذا تم إدخال معالجات خاصة لضمان أمان آلية وكلاء الدفع.
  • المجمعات (Aggregators): تدعم وظيفة تجميع التوقيعات، مثل التجميع باستخدام BLS أو التجميع القائم على SNARK. هذا ضروري لتحقيق أعلى كفاءة بيانات على Rollup.

فيتاليك حول مستقبل إثيريوم المحتمل (6): The Splurge

روابط البحث الحالية

  • حديث عن تاريخ تجريد الحسابات:
  • ERC-4337:
  • EIP-7702:
  • رمز BLSWallet (باستخدام ميزة التجميع):
  • EIP-7562 (كتابة بروتوكول الحساب المجرد):
  • EIP-7701 (بروتوكول حساب التجريد للكتابة المعتمد على EOF):

شاهد النسخة الأصلية
قد تحتوي هذه الصفحة على محتوى من جهات خارجية، يتم تقديمه لأغراض إعلامية فقط (وليس كإقرارات/ضمانات)، ولا ينبغي اعتباره موافقة على آرائه من قبل Gate، ولا بمثابة نصيحة مالية أو مهنية. انظر إلى إخلاء المسؤولية للحصول على التفاصيل.
  • أعجبني
  • 8
  • مشاركة
تعليق
0/400
GreenCandleCollectorvip
· 07-15 02:02
Vitalik Buterin قام بالفعل مما يدل على وجود شيء جيد.
شاهد النسخة الأصليةرد0
GateUser-9ad11037vip
· 07-14 15:00
فيتاليك بوتيرين أصدر عملاً جديداً~ التفاصيل تحدد النجاح أو الفشل
شاهد النسخة الأصليةرد0
NightAirdroppervip
· 07-14 04:50
لا بد من أن تستمر EVM في المنافسة.
شاهد النسخة الأصليةرد0
StealthDeployervip
· 07-14 04:47
ماذا يفعل V مرة أخرى في العبث بالكود
شاهد النسخة الأصليةرد0
WhaleWatchervip
· 07-14 04:45
من الصعب تجاوز هذه العقبات التكنولوجية بعد ترقية واهو塔.
شاهد النسخة الأصليةرد0
MidnightGenesisvip
· 07-14 04:44
تكرار الكود غير عادي ، وهناك خطة نشر في الليل مرة أخرى.
شاهد النسخة الأصليةرد0
TokenSherpavip
· 07-14 04:25
في الحقيقة، *تنهد* هذا الاقتراح يفتقر إلى السياق التاريخي المناسب... دعني أوضح لماذا كانت EVM 1.0 معيبة منذ اليوم الأول
شاهد النسخة الأصليةرد0
OnChainArchaeologistvip
· 07-14 04:24
ادخل مركز فقط انظر إلى وجه V 神
شاهد النسخة الأصليةرد0
  • تثبيت