تصميم بروتوكول إثيريوم يحتوي على العديد من "التفاصيل" التي تعتبر حاسمة لنجاحه. في الواقع، حوالي نصف المحتوى يتعلق بأنواع مختلفة من تحسينات 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 يجعل من هذين التوسيعين القائمين على الأداء pairing طبيعي.
تصميم تقريبي لمجموعة 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 للانضمام في الانقسام الصعب التالي. على الرغم من أنه دائماً ممكن إزالته في اللحظة الأخيرة - فقد تم إزالة وظائف في الانقسامات الصعبة السابقة بشكل مؤقت، إلا أن القيام بذلك سيواجه تحديات كبيرة. إزالة EOF تعني أن أي ترقية مستقبلية لـ EVM يجب أن تتم دون EOF، على الرغم من أنه يمكن القيام بذلك، إلا أنه قد يكون أكثر صعوبة.
تتمثل الموازنة الرئيسية في EVM في تعقيد L1 وتعقيد البنية التحتية، حيث أن EOF هو كمية كبيرة من الشيفرة التي تحتاج إلى إضافتها إلى تنفيذ EVM، كما أن فحص الشيفرة الثابتة معقد نسبيًا. ومع ذلك، كتعويض، يمكننا تبسيط اللغات العالية المستوى، وتبسيط تنفيذ EVM، وغيرها من الفوائد. يمكن القول إن إعطاء الأولوية لخريطة الطريق لتحسينات Ethereum L1 المستمرة يجب أن يتضمن ويعتمد على EOF.
تتمثل إحدى المهام المهمة التي يجب القيام بها في تحقيق وظائف مشابهة لـ EVM-MAX مع SIMD، وإجراء اختبارات مرجعية لاستهلاك الغاز لمختلف العمليات المشفرة.
)# كيف تتفاعل مع أجزاء أخرى من خارطة الطريق؟
تقوم L1 بضبط EVM الخاص بها بحيث يمكن لـ L2 أيضًا إجراء التعديلات المناسبة بشكل أسهل، وإذا لم يتم إجراء التعديلات المتزامنة بين الطرفين، فقد يؤدي ذلك إلى عدم التوافق، مما يسبب تأثيرات سلبية. بالإضافة إلى ذلك، يمكن أن يقلل EVM-MAX و SIMD من تكاليف الغاز للعديد من أنظمة الإثبات، مما يجعل L2 أكثر كفاءة. كما أنه يسهل استبدال المزيد من التعليمات المسبقة بكود EVM يمكنه تنفيذ نفس المهام، مما قد لا يؤثر بشكل كبير على الكفاءة.
![فيتالك حول مستقبل إثيريوم المحتمل (6): The Splurge]###https://img-cdn.gateio.im/webp-social/moments-ec1638a809393a6ed42724fb08f534da.webp###
( تجريد الحساب
)# ماذا حلت المشكلة؟
حاليًا، يمكن التحقق من المعاملات بطريقة واحدة فقط: توقيع ECDSA. في الأصل، كان الهدف من تجريد الحسابات هو تجاوز ذلك، مما يسمح لمنطق التحقق من الحسابات بأن يكون لأي كود EVM. وهذا يمكن أن يمكّن مجموعة من التطبيقات:
التبديل إلى تشفير مقاوم الكم
تبديل المفتاح القديم ### يُعتبر على نطاق واسع ممارسة أمان موصى بها ###
محفظة متعددة التوقيع ومحفظة استعادة اجتماعية
استخدم مفتاحًا واحدًا للعمليات ذات القيمة المنخفضة، واستخدم مفتاحًا آخر ( أو مجموعة مفاتيح ) للعمليات ذات القيمة العالية
يسمح لبروتوكول الخصوصية بالعمل بدون وسطاء، مما يقلل بشكل كبير من تعقيدها، ويزيل نقطة اعتماد مركزية رئيسية.
منذ أن تم طرح مفهوم تجريد الحسابات في عام 2015، توسعت أهدافه لتشمل العديد من "أهداف الراحة"، مثل، حساب لا يمتلك ETH ولكن لديه بعض ERC20 يمكنه استخدام ERC20 لدفع رسوم الغاز.
MPC( الحوسبة متعددة الأطراف ) هي تقنية تعود إلى 40 عامًا، تُستخدم لتقسيم المفاتيح إلى أجزاء متعددة وتخزينها على أجهزة متعددة، باستخدام تقنيات التشفير لتوليد التوقيعات، دون الحاجة إلى دمج هذه الأجزاء من المفاتيح مباشرة.
EIP-7702 هي اقتراح مخطط لإدخاله في الشوكة الصلبة القادمة، EIP-7702 هو نتيجة الوعي المتزايد بتوفير سهولة التجريد الحسابي لفائدة جميع المستخدمين ( بما في ذلك مستخدمي EOA )، يهدف إلى تحسين تجربة جميع المستخدمين على المدى القصير، وتجنب الانقسام إلى نظامين بيئيين.
بدأ هذا العمل في EIP-3074، وانتهى في EIP-7702. يوفر EIP-7702 "وظائف الراحة" المتعلقة بالتجريد الحسابي لجميع المستخدمين، بما في ذلك الحسابات الخارجية EOA( اليوم، أي الحسابات التي يتم التحكم فيها بواسطة توقيع ECDSA ).
على الرغم من أن بعض التحديات (، وخاصة "تحدي الراحة" )، يمكن حلها من خلال تقنيات تدريجية مثل الحوسبة متعددة الأطراف أو EIP-7702، إلا أن الهدف الأمني الرئيسي من اقتراح تجريد الحسابات الذي تم تقديمه في البداية لا يمكن تحقيقه إلا من خلال العودة وحل المشكلة الأصلية: السماح لشفرة العقود الذكية بالتحكم في التحقق من المعاملات. السبب وراء عدم تحقيق ذلك حتى الآن هو التنفيذ الآمن، وهو تحدٍ.
(# ما هو، وكيف يعمل؟
الجوهر الأساسي لتجريد الحسابات بسيط: السماح للعقود الذكية بإجراء المعاملات، وليس فقط الحسابات العادية. تأتي كل التعقيدات من تنفيذ ذلك بطريقة تحافظ على شبكة لامركزية وتقاوم هجمات حجب الخدمة.
تحدي رئيسي نموذجي هو مشكلة الفشل المتعدد:
إذا كانت هناك دالة تحقق لـ 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.
(# العمل المتبقي والموازنة
الشيء الرئيسي الذي يحتاج إلى حل في الوقت الحالي هو كيفية إدخال التجريد الكامل للحسابات في البروتوكول. البروتوكول الشهير مؤخراً لتجريد الحسابات هو EIP-7701، الذي ينفذ تجريد الحسابات فوق EOF. يمكن أن يمتلك الحساب جزءاً منفصلاً من الشيفرة للتحقق، وإذا تم تعيين هذا الجزء من الشيفرة للحساب، فسيتم تنفيذ هذا الشيفرة في خطوة التحقق من المعاملات القادمة من ذلك الحساب.
تتمثل جاذبية هذه الطريقة في أنها توضح بوضوح وجهتي نظر مكافئتين لتجريد الحسابات المحلية:
ادراج EIP-4337 كجزء من البروتوكول
نوع جديد من EOA، حيث خوارزمية التوقيع هي تنفيذ كود EVM
إذا بدأنا بوضع حدود صارمة لتعقيد التعليمات البرمجية القابلة للتنفيذ أثناء فترة التحقق - عدم السماح بالوصول إلى الحالة الخارجية، حتى أن حدود الغاز المحددة في البداية منخفضة لدرجة أنها غير فعالة لتطبيقات مقاومة الكم أو حماية الخصوصية - فإن أمان هذه الطريقة يصبح واضحًا للغاية: مجرد استبدال تحقق ECDSA بتنفيذ كود EVM يحتاج إلى زمن مشابه.
ومع مرور الوقت، نحتاج إلى تخفيف هذه الحدود، لأن السماح لتطبيقات حماية الخصوصية بالعمل بدون وسطاء، ومقاومة الكم، هما أمران مهمان للغاية. لهذا الغرض، نحتاج إلى إيجاد طرق أكثر مرونة لمعالجة مخاطر رفض الخدمة ) DoS ###، دون الحاجة إلى خطوات التحقق التي يجب أن تكون صارمة للغاية.
قد تحتوي هذه الصفحة على محتوى من جهات خارجية، يتم تقديمه لأغراض إعلامية فقط (وليس كإقرارات/ضمانات)، ولا ينبغي اعتباره موافقة على آرائه من قبل Gate، ولا بمثابة نصيحة مالية أو مهنية. انظر إلى إخلاء المسؤولية للحصول على التفاصيل.
تسجيلات الإعجاب 8
أعجبني
8
8
مشاركة
تعليق
0/400
StakeOrRegret
· 07-08 09:26
evm太الارتفاع了 迟早被干趴
شاهد النسخة الأصليةرد0
LiquidityOracle
· 07-08 00:32
متى ستكتمل ترقية evm؟
شاهد النسخة الأصليةرد0
AlphaLeaker
· 07-07 10:28
ليس سيئًا، يجب أن نخفض الغاز مرة أخرى!
شاهد النسخة الأصليةرد0
ChainChef
· 07-07 10:23
يبدو أن الإيثريوم يقوم بإعداد بعض تحديثات البروتوكول اللذيذة... تحسين EVM هو الصلصة السرية التي كنا ننتظرها بصراحة
شاهد النسخة الأصليةرد0
DisillusiionOracle
· 07-07 10:16
هذا هو EVM، إذا كان جيدًا حقًا، لكان قد تم تغييره بالفعل.
شاهد النسخة الأصليةرد0
Web3Educator
· 07-07 10:15
*يعدل النظارات* همم... يحتاج 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 لتسريع العديد من أشكال التشفير، بما في ذلك دوال التجزئة، و32 بت STARKs، والتشفير القائم على الشبكات. إن دمج EVM-MAX و SIMD يجعل من هذين التوسيعين القائمين على الأداء pairing طبيعي.
تصميم تقريبي لمجموعة EIP سيبدأ من EIP-6690، ثم:
بايثون بالنسبة لأنا في range(count): mem[z_start + z_skip * العدد] = op( mem [x_start + x_skip * عدد] ، [y_start + y_skip * عدد] )
في الواقع، سيتم معالجة هذا بطريقة متوازية.
(# العمل المتبقي والموازنة
حالياً، تخطط EOF للانضمام في الانقسام الصعب التالي. على الرغم من أنه دائماً ممكن إزالته في اللحظة الأخيرة - فقد تم إزالة وظائف في الانقسامات الصعبة السابقة بشكل مؤقت، إلا أن القيام بذلك سيواجه تحديات كبيرة. إزالة EOF تعني أن أي ترقية مستقبلية لـ EVM يجب أن تتم دون EOF، على الرغم من أنه يمكن القيام بذلك، إلا أنه قد يكون أكثر صعوبة.
تتمثل الموازنة الرئيسية في EVM في تعقيد L1 وتعقيد البنية التحتية، حيث أن EOF هو كمية كبيرة من الشيفرة التي تحتاج إلى إضافتها إلى تنفيذ EVM، كما أن فحص الشيفرة الثابتة معقد نسبيًا. ومع ذلك، كتعويض، يمكننا تبسيط اللغات العالية المستوى، وتبسيط تنفيذ EVM، وغيرها من الفوائد. يمكن القول إن إعطاء الأولوية لخريطة الطريق لتحسينات Ethereum L1 المستمرة يجب أن يتضمن ويعتمد على EOF.
تتمثل إحدى المهام المهمة التي يجب القيام بها في تحقيق وظائف مشابهة لـ EVM-MAX مع SIMD، وإجراء اختبارات مرجعية لاستهلاك الغاز لمختلف العمليات المشفرة.
)# كيف تتفاعل مع أجزاء أخرى من خارطة الطريق؟
تقوم L1 بضبط EVM الخاص بها بحيث يمكن لـ L2 أيضًا إجراء التعديلات المناسبة بشكل أسهل، وإذا لم يتم إجراء التعديلات المتزامنة بين الطرفين، فقد يؤدي ذلك إلى عدم التوافق، مما يسبب تأثيرات سلبية. بالإضافة إلى ذلك، يمكن أن يقلل EVM-MAX و SIMD من تكاليف الغاز للعديد من أنظمة الإثبات، مما يجعل L2 أكثر كفاءة. كما أنه يسهل استبدال المزيد من التعليمات المسبقة بكود EVM يمكنه تنفيذ نفس المهام، مما قد لا يؤثر بشكل كبير على الكفاءة.
![فيتالك حول مستقبل إثيريوم المحتمل (6): The Splurge]###https://img-cdn.gateio.im/webp-social/moments-ec1638a809393a6ed42724fb08f534da.webp###
( تجريد الحساب
)# ماذا حلت المشكلة؟
حاليًا، يمكن التحقق من المعاملات بطريقة واحدة فقط: توقيع ECDSA. في الأصل، كان الهدف من تجريد الحسابات هو تجاوز ذلك، مما يسمح لمنطق التحقق من الحسابات بأن يكون لأي كود EVM. وهذا يمكن أن يمكّن مجموعة من التطبيقات:
يسمح لبروتوكول الخصوصية بالعمل بدون وسطاء، مما يقلل بشكل كبير من تعقيدها، ويزيل نقطة اعتماد مركزية رئيسية.
منذ أن تم طرح مفهوم تجريد الحسابات في عام 2015، توسعت أهدافه لتشمل العديد من "أهداف الراحة"، مثل، حساب لا يمتلك ETH ولكن لديه بعض ERC20 يمكنه استخدام ERC20 لدفع رسوم الغاز.
MPC( الحوسبة متعددة الأطراف ) هي تقنية تعود إلى 40 عامًا، تُستخدم لتقسيم المفاتيح إلى أجزاء متعددة وتخزينها على أجهزة متعددة، باستخدام تقنيات التشفير لتوليد التوقيعات، دون الحاجة إلى دمج هذه الأجزاء من المفاتيح مباشرة.
EIP-7702 هي اقتراح مخطط لإدخاله في الشوكة الصلبة القادمة، EIP-7702 هو نتيجة الوعي المتزايد بتوفير سهولة التجريد الحسابي لفائدة جميع المستخدمين ( بما في ذلك مستخدمي EOA )، يهدف إلى تحسين تجربة جميع المستخدمين على المدى القصير، وتجنب الانقسام إلى نظامين بيئيين.
بدأ هذا العمل في EIP-3074، وانتهى في EIP-7702. يوفر EIP-7702 "وظائف الراحة" المتعلقة بالتجريد الحسابي لجميع المستخدمين، بما في ذلك الحسابات الخارجية EOA( اليوم، أي الحسابات التي يتم التحكم فيها بواسطة توقيع ECDSA ).
على الرغم من أن بعض التحديات (، وخاصة "تحدي الراحة" )، يمكن حلها من خلال تقنيات تدريجية مثل الحوسبة متعددة الأطراف أو EIP-7702، إلا أن الهدف الأمني الرئيسي من اقتراح تجريد الحسابات الذي تم تقديمه في البداية لا يمكن تحقيقه إلا من خلال العودة وحل المشكلة الأصلية: السماح لشفرة العقود الذكية بالتحكم في التحقق من المعاملات. السبب وراء عدم تحقيق ذلك حتى الآن هو التنفيذ الآمن، وهو تحدٍ.
(# ما هو، وكيف يعمل؟
الجوهر الأساسي لتجريد الحسابات بسيط: السماح للعقود الذكية بإجراء المعاملات، وليس فقط الحسابات العادية. تأتي كل التعقيدات من تنفيذ ذلك بطريقة تحافظ على شبكة لامركزية وتقاوم هجمات حجب الخدمة.
تحدي رئيسي نموذجي هو مشكلة الفشل المتعدد:
إذا كانت هناك دالة تحقق لـ 1000 حساب تعتمد على قيمة واحدة معينة S، وكانت القيمة الحالية S تجعل المعاملات في ذاكرة التخزين المؤقت كلها صالحة، فإن وجود معاملة واحدة تغير قيمة S قد يؤدي إلى إبطال جميع المعاملات الأخرى في ذاكرة التخزين المؤقت. وهذا يمكّن المهاجم من إرسال معاملات غير مرغوب فيها إلى ذاكرة التخزين المؤقت بتكلفة منخفضة جدًا، مما يؤدي إلى إعاقة موارد عقد الشبكة.
بعد سنوات من الجهود، التي تهدف إلى توسيع الوظائف مع الحد من مخاطر هجوم رفض الخدمة )DoS###، تم التوصل أخيرًا إلى حل لتحقيق "تجريد الحساب المثالي": ERC-4337.
آلية عمل ERC-4337 هي تقسيم معالجة عمليات المستخدم إلى مرحلتين: التحقق والتنفيذ. تتم معالجة جميع عمليات التحقق أولاً ، ثم تتم معالجة جميع عمليات التنفيذ بعد ذلك. في تجمع الذاكرة ، سيتم قبول عمليات المستخدم فقط عندما تتعلق مرحلة التحقق من العملية بحساب المستخدم فقط ولا تقرأ المتغيرات البيئية. هذا يمكن أن يمنع هجمات الفشل المتعدد. بالإضافة إلى ذلك ، يتم فرض حدود صارمة على الغاز في خطوة التحقق.
تم تصميم ERC-4337 كمعيار بروتوكول إضافي ( ERC )، لأنه في ذلك الوقت كان مطورو عميل إثيريوم يركزون على الدمج ( Merge )، ولم يكن لديهم طاقة إضافية للتعامل مع ميزات أخرى. لهذا السبب استخدم ERC-4337 كائنًا يسمى عملية المستخدم، بدلاً من المعاملات العادية. ومع ذلك، أدركنا مؤخرًا الحاجة إلى كتابة جزء على الأقل من ذلك في البروتوكول.
السببين الرئيسيين هما كما يلي:
بالإضافة إلى ذلك، قام ERC-4337 بتوسيع وظيفتين:
(# العمل المتبقي والموازنة
الشيء الرئيسي الذي يحتاج إلى حل في الوقت الحالي هو كيفية إدخال التجريد الكامل للحسابات في البروتوكول. البروتوكول الشهير مؤخراً لتجريد الحسابات هو EIP-7701، الذي ينفذ تجريد الحسابات فوق EOF. يمكن أن يمتلك الحساب جزءاً منفصلاً من الشيفرة للتحقق، وإذا تم تعيين هذا الجزء من الشيفرة للحساب، فسيتم تنفيذ هذا الشيفرة في خطوة التحقق من المعاملات القادمة من ذلك الحساب.
تتمثل جاذبية هذه الطريقة في أنها توضح بوضوح وجهتي نظر مكافئتين لتجريد الحسابات المحلية:
إذا بدأنا بوضع حدود صارمة لتعقيد التعليمات البرمجية القابلة للتنفيذ أثناء فترة التحقق - عدم السماح بالوصول إلى الحالة الخارجية، حتى أن حدود الغاز المحددة في البداية منخفضة لدرجة أنها غير فعالة لتطبيقات مقاومة الكم أو حماية الخصوصية - فإن أمان هذه الطريقة يصبح واضحًا للغاية: مجرد استبدال تحقق ECDSA بتنفيذ كود EVM يحتاج إلى زمن مشابه.
ومع مرور الوقت، نحتاج إلى تخفيف هذه الحدود، لأن السماح لتطبيقات حماية الخصوصية بالعمل بدون وسطاء، ومقاومة الكم، هما أمران مهمان للغاية. لهذا الغرض، نحتاج إلى إيجاد طرق أكثر مرونة لمعالجة مخاطر رفض الخدمة ) DoS ###، دون الحاجة إلى خطوات التحقق التي يجب أن تكون صارمة للغاية.