تصميم بروتوكول إثيريوم يحتوي على العديد من "التفاصيل" التي هي حاسمة لنجاحه. حوالي نصف المحتوى يتعلق بأنواع مختلفة من تحسينات 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 لتسريع العديد من أشكال التشفير، بما في ذلك دوال التجزئة، وSTARKs بـ 32 بت، والتشفير القائم على الشبكات، يجمع دمج 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 يمكنه تنفيذ نفس المهام، مما قد لا يؤثر بشكل كبير على الكفاءة.
تجريد الحساب
ما هي المشكلة التي تم حلها؟
حاليًا، يمكن التحقق من المعاملات بطريقة واحدة فقط: توقيع ECDSA. في البداية، تم تصميم تجريد الحساب لتجاوز ذلك، مما يسمح لطقوس التحقق من الحساب بأن تكون أي كود EVM. يمكن أن يمكّن ذلك مجموعة من التطبيقات:
التبديل إلى التشفير المقاوم للكم
تبديل المفتاح القديم ( يُعتبر بشكل واسع ممارسة أمان موصى بها )
محفظة متعددة التوقيع ومحفظة استعادة اجتماعية
استخدم مفتاحًا واحدًا للعمليات ذات القيمة المنخفضة، واستخدم مفتاحًا آخر ( أو مجموعة مفاتيح ) للعمليات ذات القيمة العالية.
يسمح بروتوكول الخصوصية بالعمل دون الحاجة إلى وسطاء، مما يقلل بشكل كبير من تعقيده، ويزيل نقطة اعتماد مركزية رئيسية.
منذ أن تم اقتراح تجريد الحساب في عام 2015، تم توسيع هدفه ليشمل العديد من "أهداف الراحة"، على سبيل المثال، يمكن لحساب لا يحتوي على إيثر ولكن لديه بعض 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): يسمح لوكالة واحدة بتمثيل حساب آخر لدفع الرسوم، مما ينتهك قاعدة أنه يمكن الوصول فقط إلى حساب المُرسل نفسه خلال مرحلة التحقق، لذلك تم إدخال معالجة خاصة لضمان أمان آلية وكلاء الدفع.
المجمعات (: تدعم وظيفة تجميع التوقيعات، مثل التجميع باستخدام BLS أو التجميع القائم على SNARK. هذا ضروري لتحقيق أعلى كفاءة بيانات على Rollup.
)# الأعمال المتبقية والتوازن
الشيء الرئيسي الذي يجب حله الآن هو كيفية إدخال التجريد الكامل للحسابات في البروتوكول. البروتوكول الذي لاقى شعبية مؤخرًا حول التجريد للحسابات هو EIP-7701، والذي ينفذ التجريد للحسابات فوق EOF. يمكن أن يمتلك الحساب جزءًا منفصلًا من الشيفرة للتحقق، وإذا تم إعداد هذا الجزء من الشيفرة للحساب، فسيتم تنفيذ هذا الشيفرة في خطوات التحقق من المعاملات القادمة من ذلك الحساب.
تتمثل魅力 في هذه الطريقة في أنها توضح بوضوح وجهتي نظر معادلتين لتجريد الحسابات المحلية:
استخدم EIP-4337 كجزء من البروتوكول
نوع جديد من EOA، حيث تكون خوارزمية التوقيع لتنفيذ كود EVM
إذا بدأنا بوضع حدود صارمة لتعقيد الكود القابل للتنفيذ خلال فترة التحقق - لا يُسمح بالوصول إلى الحالة الخارجية، حتى أن الحد الأقصى للغاز الذي تم تعيينه في البداية منخفض لدرجة أنه غير فعال للتطبيقات المقاومة للكمبيوتر أو حماية الخصوصية - فإن أمان هذه الطريقة يصبح واضحًا جدًا: مجرد استبدال التحقق من ECDSA بتنفيذ كود EVM يحتاج إلى وقت مشابه.
ومع مرور الوقت، نحتاج إلى تخفيف هذه الحدود، لأن السماح لتطبيقات حماية الخصوصية بالعمل دون وسطاء، وكذلك المقاومة الكمية، هما أمران في غاية الأهمية. لتحقيق ذلك، نحتاج إلى إيجاد طرق أكثر مرونة لمعالجة مخاطر رفض الخدمة ###DoS(، دون الحاجة إلى أن تكون خطوات التحقق بسيطة للغاية.
يبدو أن الموازنة الرئيسية هي "كتابة حل يرضي عددًا أقل من الناس بسرعة" مقابل "الانتظار لفترة أطول، قد نحصل على حل أكثر مثالية"، قد تكون الطريقة المثالية هي نوع من الأسلوب المدمج. أحد الأساليب المدمجة هو كتابة بعض حالات الاستخدام بشكل أسرع، وترك مزيد من الوقت لاستكشاف حالات الاستخدام الأخرى. والطريقة الأخرى هي نشر نسخة أكثر طموحًا من تجريد الحسابات على المستوى الثاني أولاً. ومع ذلك، فإن التحدي الذي يواجهه هذا هو أن فريق المستوى الثاني يحتاج إلى أن يكون واثقًا في العمل على اقتراح الاعتماد حتى يكونوا راغبين في التنفيذ، خاصة لضمان أن المستوى الأول و/أو مستويات أخرى في المستقبل يمكن أن تعتمد حلول متوافقة.
![فيتالك حول مستقبل إثيريوم المحتمل (6): The Splurge])https://img-cdn.gateio.im/webp-social/moments-66bd22f0b53601d0976aa3a2b701c981.webp(
هناك تطبيق آخر نحتاج إلى التفكير فيه بوضوح وهو حسابات تخزين المفاتيح، حيث تخزن هذه الحسابات الحالة المرتبطة بالحساب على L1 أو L2 مخصص، ولكن يمكن استخدامها على L1 وأي L2 متوافق. قد يتطلب تحقيق ذلك بشكل فعال دعم L2 لعمليات مثل L1SLOAD أو REMOTESTATICCALL، ولكن هذا يتطلب أيضًا دعم تنفيذ تجريد الحسابات على L2 لهذه العمليات.
)# كيف يتفاعل مع الأجزاء الأخرى من خارطة الطريق؟
تشمل القائمة الحاجة لدعم معاملات تجريد الحساب، وفي الممارسة العملية، فإن احتياجات القائمة المتضمنة تشبه فعليًا احتياجات تجمع الذاكرة اللامركزية، على الرغم من أن قائمة الشمولية تتمتع بمرونة أكبر قليلاً. علاوة على ذلك، يجب أن يتم تنفيذ تجريد الحساب بأكبر قدر ممكن من التنسيق بين L1 و L2. إذا كنا نتوقع في المستقبل أن معظم المستخدمين سيستخدمون تخزين المفاتيح Rollup، يجب أن يكون تصميم تجريد الحساب
قد تحتوي هذه الصفحة على محتوى من جهات خارجية، يتم تقديمه لأغراض إعلامية فقط (وليس كإقرارات/ضمانات)، ولا ينبغي اعتباره موافقة على آرائه من قبل Gate، ولا بمثابة نصيحة مالية أو مهنية. انظر إلى إخلاء المسؤولية للحصول على التفاصيل.
تسجيلات الإعجاب 10
أعجبني
10
6
مشاركة
تعليق
0/400
AirdropLicker
· منذ 17 س
وداعًا، الارتفاع Gas来了
شاهد النسخة الأصليةرد0
ChainWanderingPoet
· منذ 21 س
الرسوم تحتاج إلى تحسين، لا يمكن التعامل مع BTC.
شاهد النسخة الأصليةرد0
LeverageAddict
· 08-03 22:13
shitcoin قد انتقل إلى evm، بينما لا يزال ايثر يعاني من البطء
إثيريوم بروتوكول المستقبل: ترقية EVM، تجريد الحساب وتحسين غسيل الأموال
مستقبل بروتوكول إثيريوم ( ٦ ): ازدهار
تصميم بروتوكول إثيريوم يحتوي على العديد من "التفاصيل" التي هي حاسمة لنجاحه. حوالي نصف المحتوى يتعلق بأنواع مختلفة من تحسينات 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 لتسريع العديد من أشكال التشفير، بما في ذلك دوال التجزئة، وSTARKs بـ 32 بت، والتشفير القائم على الشبكات، يجمع دمج 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 يمكنه تنفيذ نفس المهام، مما قد لا يؤثر بشكل كبير على الكفاءة.
تجريد الحساب
ما هي المشكلة التي تم حلها؟
حاليًا، يمكن التحقق من المعاملات بطريقة واحدة فقط: توقيع ECDSA. في البداية، تم تصميم تجريد الحساب لتجاوز ذلك، مما يسمح لطقوس التحقق من الحساب بأن تكون أي كود EVM. يمكن أن يمكّن ذلك مجموعة من التطبيقات:
يسمح بروتوكول الخصوصية بالعمل دون الحاجة إلى وسطاء، مما يقلل بشكل كبير من تعقيده، ويزيل نقطة اعتماد مركزية رئيسية.
منذ أن تم اقتراح تجريد الحساب في عام 2015، تم توسيع هدفه ليشمل العديد من "أهداف الراحة"، على سبيل المثال، يمكن لحساب لا يحتوي على إيثر ولكن لديه بعض 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(، دون الحاجة إلى أن تكون خطوات التحقق بسيطة للغاية.
يبدو أن الموازنة الرئيسية هي "كتابة حل يرضي عددًا أقل من الناس بسرعة" مقابل "الانتظار لفترة أطول، قد نحصل على حل أكثر مثالية"، قد تكون الطريقة المثالية هي نوع من الأسلوب المدمج. أحد الأساليب المدمجة هو كتابة بعض حالات الاستخدام بشكل أسرع، وترك مزيد من الوقت لاستكشاف حالات الاستخدام الأخرى. والطريقة الأخرى هي نشر نسخة أكثر طموحًا من تجريد الحسابات على المستوى الثاني أولاً. ومع ذلك، فإن التحدي الذي يواجهه هذا هو أن فريق المستوى الثاني يحتاج إلى أن يكون واثقًا في العمل على اقتراح الاعتماد حتى يكونوا راغبين في التنفيذ، خاصة لضمان أن المستوى الأول و/أو مستويات أخرى في المستقبل يمكن أن تعتمد حلول متوافقة.
![فيتالك حول مستقبل إثيريوم المحتمل (6): The Splurge])https://img-cdn.gateio.im/webp-social/moments-66bd22f0b53601d0976aa3a2b701c981.webp(
هناك تطبيق آخر نحتاج إلى التفكير فيه بوضوح وهو حسابات تخزين المفاتيح، حيث تخزن هذه الحسابات الحالة المرتبطة بالحساب على L1 أو L2 مخصص، ولكن يمكن استخدامها على L1 وأي L2 متوافق. قد يتطلب تحقيق ذلك بشكل فعال دعم L2 لعمليات مثل L1SLOAD أو REMOTESTATICCALL، ولكن هذا يتطلب أيضًا دعم تنفيذ تجريد الحسابات على L2 لهذه العمليات.
)# كيف يتفاعل مع الأجزاء الأخرى من خارطة الطريق؟
تشمل القائمة الحاجة لدعم معاملات تجريد الحساب، وفي الممارسة العملية، فإن احتياجات القائمة المتضمنة تشبه فعليًا احتياجات تجمع الذاكرة اللامركزية، على الرغم من أن قائمة الشمولية تتمتع بمرونة أكبر قليلاً. علاوة على ذلك، يجب أن يتم تنفيذ تجريد الحساب بأكبر قدر ممكن من التنسيق بين L1 و L2. إذا كنا نتوقع في المستقبل أن معظم المستخدمين سيستخدمون تخزين المفاتيح Rollup، يجب أن يكون تصميم تجريد الحساب