تصميم بروتوكول إثيريوم يحتوي على العديد من "التفاصيل" التي تعتبر حاسمة لنجاحه. حوالي نصف المحتوى يتعلق بأنواع مختلفة من تحسينات EVM، بينما يتكون الجزء المتبقي من مواضيع متخصصة متنوعة، وهذا هو معنى "الازدهار".
الازدهار: الهدف الرئيسي
تحويل EVM إلى "الحالة النهائية" عالية الأداء ومستقرة
إدخال تجريد الحسابات في البروتوكول، مما يسمح لجميع المستخدمين بالتمتع بحسابات أكثر أمانًا وملاءمة
تحسين الاقتصاد في تكاليف التداول، وزيادة القابلية للتوسع مع تقليل المخاطر
استكشاف التشفير المتقدم، مما يجعل إثيريوم يتحسن بشكل ملحوظ على المدى الطويل
تحسين EVM
ما هي المشكلة التي تم حلها؟
من الصعب حاليًا إجراء تحليل ثابت لـ EVM، مما يجعل من الصعب إنشاء تنفيذ فعال، والتحقق الرسمي من التعليمات البرمجية، وإجراء المزيد من التوسع. بالإضافة إلى ذلك، فإن كفاءة EVM منخفضة، مما يجعل من الصعب تنفيذ العديد من أشكال التشفير المتقدم، إلا من خلال دعم مسبق التجميع بشكل صريح.
ما هو، كيف يعمل؟
الخطوة الأولى في خارطة طريق تحسين EVM الحالية هي تنسيق كائن EVM (EOF)، والذي من المقرر دمجه في الشوكة الصلبة التالية. EOF هو مجموعة من EIP، يحدد إصدار جديد من كود EVM، يتمتع بالعديد من الميزات الفريدة، وأبرزها:
الشيفرة ( قابلة للتنفيذ، لكن لا يمكن قراءة ) من EVM والفصل بين البيانات ( قابلة للقراءة، لكن لا يمكن تنفيذ )
يمنع الانتقال الديناميكي، يُسمح فقط بالانتقال الثابت
لا يمكن لمコード EVM مراقبة المعلومات المتعلقة بالوقود
أضيفت آلية جديدة لإجراء فرعي صريح
ستظل العقود القديمة موجودة ويمكن إنشاؤها، على الرغم من أنه قد يتم التخلي عن العقود القديمة ( تدريجياً وقد يتم تحويلها قسراً إلى كود EOF ). ستستفيد العقود الجديدة من التحسينات في الكفاءة التي توفرها EOF - أولاً من خلال كود بايت أصغر قليلاً بفضل ميزات الروتين الفرعي، ثم من خلال ميزات جديدة أو تقليل تكاليف الغاز المحددة لـ EOF.
بعد إدخال EOF، أصبحت الترقيات الإضافية أسهل بكثير، وأفضل تطوير حتى الآن هو توسيع العمليات الحسابية لوحدة EVM ( EVM-MAX ). أنشأ EVM-MAX مجموعة من العمليات الجديدة المصممة خصيصًا للعمليات المودولية، ووضعها في مساحة ذاكرة جديدة لا يمكن الوصول إليها من خلال رموز العمليات الأخرى، مما يجعل من الممكن استخدام تحسينات مثل ضرب مونتغومري.
فكرة جديدة نسبياً هي دمج EVM-MAX مع خصائص التعليمات المتعددة (SIMD)، حيث أن SIMD كفكرة في إثيريوم موجودة منذ فترة طويلة، وقد تم اقتراحها لأول مرة من قبل Greg Colvin في EIP-616. يمكن استخدام SIMD لتسريع العديد من أشكال التشفير، بما في ذلك دوال التجزئة، و32 بت STARKs، والتشفير القائم على الشبكات، مما يجعل دمج EVM-MAX وSIMD زوجًا طبيعيًا من التوسعات الموجهة نحو الأداء.
حاليًا، تخطط EOF للتضمين في الانقسام الصلب التالي. على الرغم من أنه دائمًا ما يكون من الممكن إزالته في اللحظة الأخيرة - حيث تم إزالة ميزات مؤقتًا في الانقسامات الصلبة السابقة، إلا أن القيام بذلك سيواجه تحديات كبيرة. إزالة EOF تعني أن أي ترقية مستقبلية لـ EVM ستحتاج إلى أن تتم بدون EOF، على الرغم من أنه يمكن القيام بذلك، إلا أنه قد يكون أكثر صعوبة.
التوازن الرئيسي في EVM هو تعقيد L1 وتعقيد البنية التحتية، EOF هو كمية كبيرة من التعليمات البرمجية التي تحتاج إلى إضافتها إلى تنفيذ EVM، كما أن فحص التعليمات البرمجية الثابتة معقد نسبيًا. ومع ذلك، كتعويض، يمكننا تبسيط اللغات عالية المستوى، وتبسيط تنفيذ EVM والفوائد الأخرى. يمكن القول إن إعطاء الأولوية لخارطة الطريق لتحسينات Ethereum L1 المستمرة يجب أن يتضمن ويعتمد على EOF.
هناك عمل مهم يجب القيام به وهو تحقيق وظائف مشابهة لـ EVM-MAX مع SIMD، وإجراء اختبارات مرجعية لاستهلاك الغاز لمختلف العمليات المشفرة.
كيف تتفاعل مع الأجزاء الأخرى من خريطة الطريق؟
تقوم L1 بتعديل EVM الخاص بها بحيث يمكن لـ L2 أيضًا إجراء التعديلات المناسبة بسهولة أكبر، وإذا لم يتم إجراء تعديلات متزامنة بينهما، فقد يؤدي ذلك إلى عدم التوافق، مما يسبب آثارًا سلبية. بالإضافة إلى ذلك، يمكن لـ EVM-MAX و SIMD تقليل تكاليف الغاز للعديد من أنظمة الإثبات، مما يجعل L2 أكثر كفاءة. كما أنه يسهل استبدال المزيد من التعليمات البرمجية المسبقة التي يمكنها تنفيذ نفس المهام بشفرة EVM، مما قد لا يؤثر بشكل كبير على الكفاءة.
تجريد الحساب
ماذا تم حلّه؟
حالياً، يمكن التحقق من المعاملات فقط من خلال طريقة واحدة: توقيع ECDSA. في البداية، كان الهدف من تجريد الحسابات هو تجاوز ذلك، مما يسمح للمنطق التحقق من الحسابات بأن يكون عشوائياً من كود EVM. يمكن أن يتيح هذا مجموعة من التطبيقات:
التحويل إلى التشفير المقاوم للكمبيوتر الكمي
تبديل المفتاح القديم ( يُعتبر ممارسة أمان موصى بها على نطاق واسع )
محفظة متعددة التوقيع ومحفظة استرداد اجتماعي
استخدم مفتاحًا واحدًا لإجراء عمليات ذات قيمة منخفضة، واستخدم مفتاحًا آخر ( أو مجموعة مفاتيح ) لإجراء عمليات ذات قيمة عالية
يسمح لبروتوكول الخصوصية بالعمل بدون وسطاء، مما يقلل بشكل كبير من تعقيده ويزيل نقطة اعتماد مركزية رئيسية.
منذ أن تم اقتراح تجريد الحسابات في عام 2015، توسعت أهدافها لتشمل العديد من "أهداف الراحة"، على سبيل المثال، يمكن لحساب لا يحتوي على ETH ولكنه يمتلك بعض ERC20 دفع الغاز باستخدام ERC20.
MPC( الحوسبة متعددة الأطراف) هي تقنية موجودة منذ 40 عامًا، تُستخدم لتقسيم المفاتيح إلى أجزاء متعددة وتخزينها على أجهزة متعددة، باستخدام تقنيات التشفير لإنشاء توقيعات، دون الحاجة إلى تجميع هذه الأجزاء من المفاتيح مباشرة.
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 كائنًا يسمى عملية المستخدم، بدلاً من المعاملات العادية. ومع ذلك، أدركنا مؤخرًا الحاجة إلى كتابة جزء من المحتوى على الأقل في البروتوكول.
السببين الرئيسيين هما كما يلي:
EntryPoint ككفاءة متأصلة للعقد: كل حزمة تحمل تكلفة ثابتة تبلغ حوالي 100,000 غاز، بالإضافة إلى آلاف الغاز الإضافية لكل عملية مستخدم.
التأكد من ضرورة خصائص إثيريوم: مثل قائمة المحتوى التي تم إنشاؤها والتي تتطلب ضمانات تحتاج إلى التحويل إلى حسابات المستخدمين المجردة.
بالإضافة إلى ذلك، وسع ERC-4337 وظيفتين:
وكيل الدفع (Paymasters): يتيح حسابًا واحدًا لتمثيل حساب آخر في دفع الرسوم، مما يتعارض مع قاعدة أن مرحلة التحقق يمكنها الوصول فقط إلى حساب المرسل نفسه، وبالتالي تم إدخال معالجة خاصة لضمان أمان آلية وكيل الدفع.
المجمعات ( Aggregators ): تدعم وظيفة تجميع التوقيعات، مثل تجميع BLS أو التجميع القائم على SNARK. هذا ضروري لتحقيق أعلى كفاءة بيانات على Rollup.
الروابط البحثية الحالية
حول تاريخ التجريد الحسابي:
ERC-4337:
EIP-7702:
كود BLSWallet ( يستخدم وظيفة التجميع ):
EIP-7562( كتابة بروتوكول حسابات مجمعة ):
بروتوكول الكتابة المستند إلى EOF لحسابات التجريد (
)# العمل المتبقي والتوازن
المشكلة الرئيسية التي تحتاج إلى حلها حالياً هي كيفية إدخال تجريد الحساب بشكل كامل في البروتوكول، والاقتراح الشائع مؤخراً هو اقتراح تجريد الحساب EIP-7701، الذي يحقق تجريد الحساب فوق EOF. يمكن أن يمتلك الحساب جزءاً من الشفرة منفصل للتحقق، وإذا تم إعداد هذا الجزء من الشفرة في الحساب، فسيتم تنفيذ هذا الشيفرة في خطوة التحقق من المعاملات القادمة من هذا الحساب.
تكمن جاذبية هذه الطريقة في أنها توضح بوضوح وجهتي نظر مكافئتين لتجريد الحسابات المحلية:
استخدم EIP-4337 كجزء من البروتوكول
نوع جديد من EOA ، حيث خوارزمية التوقيع هي تنفيذ كود EVM
إذا بدأنا من وضع حدود صارمة لتعقيد الشيفرة القابلة للتنفيذ خلال فترة التحقق--- لا يُسمح بالوصول إلى الحالة الخارجية، حتى أن الحد الأدنى المحدد من الغاز في البداية منخفض لدرجة أنه غير فعال لتطبيقات مقاومة الكم أو حماية الخصوصية--- فإن أمان هذه الطريقة يصبح واضحًا للغاية: مجرد استبدال تحقق ECDSA بتنفيذ شيفرة EVM يحتاج إلى وقت مشابه.
ومع مرور الوقت، نحتاج إلى تخفيف هذه الحدود، لأن السماح لتطبيقات حماية الخصوصية بالعمل بدون وسطاء، بالإضافة إلى مقاومة الكم، كلها أمور مهمة جداً. لذلك، نحتاج إلى إيجاد طرق أكثر مرونة للتعامل مع مخاطر رفض الخدمة ###DoS( دون الحاجة إلى أن تكون خطوات التحقق بسيطة للغاية.
يبدو أن المقايضة الرئيسية هي "كتابة خطة ترضي عددًا أقل من الأشخاص بسرعة" مقابل "الانتظار لفترة أطول، ربما للحصول على حل أكثر مثالية"، والطريقة المثالية قد تكون نوعًا من الطرق المختلطة. إحدى الطرق المختلطة هي كتابة بعض حالات الاستخدام بشكل أسرع، وترك المزيد من الوقت لاستكشاف حالات استخدام أخرى. طريقة أخرى هي نشر نسخة أكثر طموحًا من التجريد الحسابي على L2 أولاً. ومع ذلك، فإن التحدي الذي تواجهه هو أن فريق L2 يحتاج إلى الثقة الكاملة في العمل المعتمد من الاقتراح ليكون مستعدًا للتنفيذ، خاصةً لضمان أن L1 و/أو L2 الأخرى في المستقبل يمكن أن تعتمد الحلول المتوافقة.
نحتاج أيضًا إلى النظر في تطبيق آخر وهو حسابات تخزين المفاتيح، حيث تقوم هذه الحسابات بتخزين الحالة المرتبطة بالحسابات على L1 أو L2 مخصص، ولكن يمكن أن تعمل على L1 وأي
قد تحتوي هذه الصفحة على محتوى من جهات خارجية، يتم تقديمه لأغراض إعلامية فقط (وليس كإقرارات/ضمانات)، ولا ينبغي اعتباره موافقة على آرائه من قبل Gate، ولا بمثابة نصيحة مالية أو مهنية. انظر إلى إخلاء المسؤولية للحصول على التفاصيل.
خريطة طريق ازدهار إثيريوم: ترقية EVM، تجريد الحساب وتحسين EIP-1559
مستقبل إمكانيات بروتوكول إثيريوم: ازدهار
تصميم بروتوكول إثيريوم يحتوي على العديد من "التفاصيل" التي تعتبر حاسمة لنجاحه. حوالي نصف المحتوى يتعلق بأنواع مختلفة من تحسينات EVM، بينما يتكون الجزء المتبقي من مواضيع متخصصة متنوعة، وهذا هو معنى "الازدهار".
الازدهار: الهدف الرئيسي
تحسين EVM
ما هي المشكلة التي تم حلها؟
من الصعب حاليًا إجراء تحليل ثابت لـ EVM، مما يجعل من الصعب إنشاء تنفيذ فعال، والتحقق الرسمي من التعليمات البرمجية، وإجراء المزيد من التوسع. بالإضافة إلى ذلك، فإن كفاءة EVM منخفضة، مما يجعل من الصعب تنفيذ العديد من أشكال التشفير المتقدم، إلا من خلال دعم مسبق التجميع بشكل صريح.
ما هو، كيف يعمل؟
الخطوة الأولى في خارطة طريق تحسين EVM الحالية هي تنسيق كائن EVM (EOF)، والذي من المقرر دمجه في الشوكة الصلبة التالية. EOF هو مجموعة من EIP، يحدد إصدار جديد من كود EVM، يتمتع بالعديد من الميزات الفريدة، وأبرزها:
ستظل العقود القديمة موجودة ويمكن إنشاؤها، على الرغم من أنه قد يتم التخلي عن العقود القديمة ( تدريجياً وقد يتم تحويلها قسراً إلى كود EOF ). ستستفيد العقود الجديدة من التحسينات في الكفاءة التي توفرها EOF - أولاً من خلال كود بايت أصغر قليلاً بفضل ميزات الروتين الفرعي، ثم من خلال ميزات جديدة أو تقليل تكاليف الغاز المحددة لـ EOF.
بعد إدخال EOF، أصبحت الترقيات الإضافية أسهل بكثير، وأفضل تطوير حتى الآن هو توسيع العمليات الحسابية لوحدة EVM ( EVM-MAX ). أنشأ EVM-MAX مجموعة من العمليات الجديدة المصممة خصيصًا للعمليات المودولية، ووضعها في مساحة ذاكرة جديدة لا يمكن الوصول إليها من خلال رموز العمليات الأخرى، مما يجعل من الممكن استخدام تحسينات مثل ضرب مونتغومري.
فكرة جديدة نسبياً هي دمج EVM-MAX مع خصائص التعليمات المتعددة (SIMD)، حيث أن SIMD كفكرة في إثيريوم موجودة منذ فترة طويلة، وقد تم اقتراحها لأول مرة من قبل Greg Colvin في EIP-616. يمكن استخدام SIMD لتسريع العديد من أشكال التشفير، بما في ذلك دوال التجزئة، و32 بت STARKs، والتشفير القائم على الشبكات، مما يجعل دمج EVM-MAX وSIMD زوجًا طبيعيًا من التوسعات الموجهة نحو الأداء.
! فيتاليك حول المستقبل المحتمل ل Ethereum (6): التفاخر
روابط الأبحاث الحالية
العمل المتبقي والموازنة
حاليًا، تخطط EOF للتضمين في الانقسام الصلب التالي. على الرغم من أنه دائمًا ما يكون من الممكن إزالته في اللحظة الأخيرة - حيث تم إزالة ميزات مؤقتًا في الانقسامات الصلبة السابقة، إلا أن القيام بذلك سيواجه تحديات كبيرة. إزالة EOF تعني أن أي ترقية مستقبلية لـ EVM ستحتاج إلى أن تتم بدون EOF، على الرغم من أنه يمكن القيام بذلك، إلا أنه قد يكون أكثر صعوبة.
التوازن الرئيسي في EVM هو تعقيد L1 وتعقيد البنية التحتية، EOF هو كمية كبيرة من التعليمات البرمجية التي تحتاج إلى إضافتها إلى تنفيذ EVM، كما أن فحص التعليمات البرمجية الثابتة معقد نسبيًا. ومع ذلك، كتعويض، يمكننا تبسيط اللغات عالية المستوى، وتبسيط تنفيذ EVM والفوائد الأخرى. يمكن القول إن إعطاء الأولوية لخارطة الطريق لتحسينات Ethereum L1 المستمرة يجب أن يتضمن ويعتمد على EOF.
هناك عمل مهم يجب القيام به وهو تحقيق وظائف مشابهة لـ EVM-MAX مع SIMD، وإجراء اختبارات مرجعية لاستهلاك الغاز لمختلف العمليات المشفرة.
كيف تتفاعل مع الأجزاء الأخرى من خريطة الطريق؟
تقوم L1 بتعديل EVM الخاص بها بحيث يمكن لـ L2 أيضًا إجراء التعديلات المناسبة بسهولة أكبر، وإذا لم يتم إجراء تعديلات متزامنة بينهما، فقد يؤدي ذلك إلى عدم التوافق، مما يسبب آثارًا سلبية. بالإضافة إلى ذلك، يمكن لـ EVM-MAX و SIMD تقليل تكاليف الغاز للعديد من أنظمة الإثبات، مما يجعل L2 أكثر كفاءة. كما أنه يسهل استبدال المزيد من التعليمات البرمجية المسبقة التي يمكنها تنفيذ نفس المهام بشفرة EVM، مما قد لا يؤثر بشكل كبير على الكفاءة.
تجريد الحساب
ماذا تم حلّه؟
حالياً، يمكن التحقق من المعاملات فقط من خلال طريقة واحدة: توقيع ECDSA. في البداية، كان الهدف من تجريد الحسابات هو تجاوز ذلك، مما يسمح للمنطق التحقق من الحسابات بأن يكون عشوائياً من كود EVM. يمكن أن يتيح هذا مجموعة من التطبيقات:
يسمح لبروتوكول الخصوصية بالعمل بدون وسطاء، مما يقلل بشكل كبير من تعقيده ويزيل نقطة اعتماد مركزية رئيسية.
منذ أن تم اقتراح تجريد الحسابات في عام 2015، توسعت أهدافها لتشمل العديد من "أهداف الراحة"، على سبيل المثال، يمكن لحساب لا يحتوي على ETH ولكنه يمتلك بعض ERC20 دفع الغاز باستخدام ERC20.
MPC( الحوسبة متعددة الأطراف) هي تقنية موجودة منذ 40 عامًا، تُستخدم لتقسيم المفاتيح إلى أجزاء متعددة وتخزينها على أجهزة متعددة، باستخدام تقنيات التشفير لإنشاء توقيعات، دون الحاجة إلى تجميع هذه الأجزاء من المفاتيح مباشرة.
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 كائنًا يسمى عملية المستخدم، بدلاً من المعاملات العادية. ومع ذلك، أدركنا مؤخرًا الحاجة إلى كتابة جزء من المحتوى على الأقل في البروتوكول.
السببين الرئيسيين هما كما يلي:
بالإضافة إلى ذلك، وسع ERC-4337 وظيفتين:
الروابط البحثية الحالية
)# العمل المتبقي والتوازن
المشكلة الرئيسية التي تحتاج إلى حلها حالياً هي كيفية إدخال تجريد الحساب بشكل كامل في البروتوكول، والاقتراح الشائع مؤخراً هو اقتراح تجريد الحساب EIP-7701، الذي يحقق تجريد الحساب فوق EOF. يمكن أن يمتلك الحساب جزءاً من الشفرة منفصل للتحقق، وإذا تم إعداد هذا الجزء من الشفرة في الحساب، فسيتم تنفيذ هذا الشيفرة في خطوة التحقق من المعاملات القادمة من هذا الحساب.
تكمن جاذبية هذه الطريقة في أنها توضح بوضوح وجهتي نظر مكافئتين لتجريد الحسابات المحلية:
إذا بدأنا من وضع حدود صارمة لتعقيد الشيفرة القابلة للتنفيذ خلال فترة التحقق--- لا يُسمح بالوصول إلى الحالة الخارجية، حتى أن الحد الأدنى المحدد من الغاز في البداية منخفض لدرجة أنه غير فعال لتطبيقات مقاومة الكم أو حماية الخصوصية--- فإن أمان هذه الطريقة يصبح واضحًا للغاية: مجرد استبدال تحقق ECDSA بتنفيذ شيفرة EVM يحتاج إلى وقت مشابه.
ومع مرور الوقت، نحتاج إلى تخفيف هذه الحدود، لأن السماح لتطبيقات حماية الخصوصية بالعمل بدون وسطاء، بالإضافة إلى مقاومة الكم، كلها أمور مهمة جداً. لذلك، نحتاج إلى إيجاد طرق أكثر مرونة للتعامل مع مخاطر رفض الخدمة ###DoS( دون الحاجة إلى أن تكون خطوات التحقق بسيطة للغاية.
يبدو أن المقايضة الرئيسية هي "كتابة خطة ترضي عددًا أقل من الأشخاص بسرعة" مقابل "الانتظار لفترة أطول، ربما للحصول على حل أكثر مثالية"، والطريقة المثالية قد تكون نوعًا من الطرق المختلطة. إحدى الطرق المختلطة هي كتابة بعض حالات الاستخدام بشكل أسرع، وترك المزيد من الوقت لاستكشاف حالات استخدام أخرى. طريقة أخرى هي نشر نسخة أكثر طموحًا من التجريد الحسابي على L2 أولاً. ومع ذلك، فإن التحدي الذي تواجهه هو أن فريق L2 يحتاج إلى الثقة الكاملة في العمل المعتمد من الاقتراح ليكون مستعدًا للتنفيذ، خاصةً لضمان أن L1 و/أو L2 الأخرى في المستقبل يمكن أن تعتمد الحلول المتوافقة.
نحتاج أيضًا إلى النظر في تطبيق آخر وهو حسابات تخزين المفاتيح، حيث تقوم هذه الحسابات بتخزين الحالة المرتبطة بالحسابات على L1 أو L2 مخصص، ولكن يمكن أن تعمل على L1 وأي