ظهرت مشاكل نزاع الحوكمة الأكثر تعقيدًا في ترقية Pectra. بعد إدراج EIP3074 في ترقية Pectra، حدث جدل كبير، خاصة من فريق ERC4337.
EIP3074 وقع في مأزق، ولم تتمكن عملية الحوكمة من الاستمرار. حتى اقترح فيتالك EIP7702 لإنهاء تساؤلات فريق ERC4337 حول EIP3074.
وجدت GCC Research أن هناك نقاشًا قليلاً حول قضايا الحوكمة المتعلقة بـ EIP3074 و ERC7702 في ترقية Pectra في العالم الناطق بالصينية. لكن هذه القضايا الحوكمة تعكس أيضًا مشكلة عميقة في حوكمة الإيثيريوم، وهي: من يمكنه التحكم في المحتوى المحدد للكود في ظل مبدأ "الكود هو القانون". يمكن أن توفر لنا قضايا الحوكمة المتعلقة بـ EIP3074 و ERC7702 منظورًا جيدًا لمراقبة العملية الحقيقية للحوكمة داخل الإيثيريوم.
الاستنتاج النهائي من هذه المقالة مستمد من التعليق الذي نشره ZeroDev، والذي يشير إلى أن نظام حوكمة الإيثريوم هو نموذج VVRC، ويجب أن يتوافق أي اقتراح يتم إدخاله أولاً مع قيم الإيثريوم (Value)، ثم يجب أن يعكس الاقتراح الرؤية التي صممها فيتالك (Vision)، وأخيرًا يجب أن ينعكس الاقتراح في خارطة الطريق (Roadmap)، وأخيرًا بعد مناقشة المطورين الرئيسيين، سيتم تضمينه في تنفيذ العميل (Client).
أشار بحث GCC في المقالة السابقة إلى أن EIP2537 واجهت مشاكل في التنفيذ على مستوى العميل مما أدى إلى تأخير انضمامه إلى التجزئة الصلبة، بينما لم يتم تضمين EIP3074 في النهاية بسبب مشاكل في الرؤية وخطة الطريق، حيث اختار مطورو إيثيريوم الأساسيون مباشرة EIP7702 الذي كتبه فيتاليك كاقتراح نهائي لتجريد الحساب.
ملخص محتوى الاقتراح
قبل تقديم تفاصيل عملية الحوكمة المحددة، نحتاج أولاً إلى تقديم مقدمة بسيطة حول المحتوى المحدد للبيانات EIP3074 و EIP7702 و ERC4337 التي يتناولها هذا المقال.
EIP3074 هو اقتراح على مستوى التنفيذ، ويتطلب تنفيذ هذا الاقتراح ترقية برامج العقد. الهدف الرئيسي من EIP3074 هو تحقيق وظيفة رعاية الغاز والمعاملات الجماعية. ما يسمى برعاية الغاز يعني أن المستخدم يمكنه استخدام أي رمز لدفع رسوم الغاز، أو يمكن للمستخدم دفع رسوم الغاز في وضع عدم الاتصال. ولكن يجب أن نلاحظ أنه بالمقارنة مع اقتراحات تجريد الحسابات الأخرى التي تسمح بتغيير خوارزمية التحقق من التوقيع، فإن EIP3074 لا يسمح للمستخدمين باستخدام أي خوارزمية توقيع بخلاف secp256k1. بعبارة أخرى، EIP3074 ليس اقتراحًا يلبي جميع وظائف تجريد الحسابات. هذه هي النقطة التي تم انتقاد EIP3074 بسببها.
لتحقيق الأهداف المتوقعة، قدم EIP3074 عمليتي رمز تشغيل، وهما AUTH و AUTHCALL. يمكن لرمز التشغيل AUTH التحقق من التوقيع، وعندما ينجح التحقق من التوقيع، سيتم تكوين authorized في سياق EVM الحالي ليكون عنوان الموقع. بعد تكوين authorized في السياق، يمكن لـ AUTHCALL استخدام عنوان authorized كمصدر للمسافة msg.sender لإجراء المعاملة. إلى حد ما، يمكن للمستخدمين من خلال التوقيع تفويض حساباتهم لاستخدامها من قبل عقد ذكي في معاملة واحدة. عادة ما نسمي هذا العقد الذكي المفوض من قبل المستخدم بعقد invoker.
ما هو محتوى توقيع المستخدم المحدد؟ يحتاج المستخدم إلى توقيع المحتوى التالي:
العنوان المستدعي المذكور في المحتوى أعلاه يشير إلى عنوان عقد المستدعي الذي يرغب المستخدم في تفويضه، ستتحقق EVM من محتوى توقيع المستخدم وما إذا كان يتطابق مع العقد الذي يتحقق فعليًا من التوقيع، لتجنب استخدام محتوى توقيع AUTH الخاص بالمستخدم من قبل عقود أخرى.
nonce هو معرف يمنع إعادة تشغيل المعاملات. ولكن يجب الانتباه إلى أن عملية AUTH ستتحقق من تطابق nonce في التوقيع مع nonce EOA الحالي للتوقيع. نظريًا، طالما أن المستخدم لا يستخدم حساب EOA لبدء المعاملات لزيادة قيمة nonce، فإن توقيع AUTH الذي يرسله المستخدم يمكن أن يستمر في استخدامه من قبل عقد invoker. هذه ثغرة أمان هائلة، مما يعني أن المستخدمين الذين يستخدمون EIP3074 يجب أن يثقوا في مزودي خدمات الوساطة الذين يحصلون على التوقيع. إذا كان مزود خدمة الوساطة الذي يحصل على توقيع المستخدم خبيثًا، فقد يقوم في وقت ما بإعادة تشغيل توقيع AUTH الخاص بالمستخدم وسرقة أصوله.
تعتبر حقل commit من الأمور التي تعاني من مشاكل أمنية. يتم استخدام حقل commit لضمان بعض العمليات، حيث يمكن للمستخدم التحكم بدقة في صلاحيات توقيعه داخل commit، مثل كتابة محتوى معين داخل commit لتجنب استخدام محتوى توقيعه في تحويلات ETH. في وثيقة EIP3074، قدم المقترح سلسلة من الأمثلة لاستخدام حقل commit. لكن المشكلة تكمن في أن وظيفة commit تعتمد تمامًا على تعريف العقود الذكية، وهي في جوهرها محتوى اختياري. قد تكون تفسيرات محتوى commit مختلفة تمامًا بين العقود الذكية المختلفة، وحتى قد لا تقرأ بعض العقود محتوى commit على الإطلاق. إذا كان المستخدم يرغب في استخدام EIP3074 بشكل آمن، يجب عليه مراجعة العقود الذكية ببساطة.
أخيرًا، نقدم تأثير EIP3074 على تجمع ذاكرة المعاملات الحالي في إيثيريوم. بعد إدخال EIP3074، قد تظهر طريقة هجوم على تجمع الذاكرة، حيث يمكن للقراصنة استخدام عدد كبير من الحسابات لبدء المعاملات، ثم عند اقتراب حزم المعاملة، يستخدمون EIP3074 لسحب كل ETH من هذه الحسابات دفعة واحدة، مما يؤدي إلى فشل جميع المعاملات التي تم بدءها سابقًا. ستؤثر هذه الطريقة الهجومية بشكل كبير على عقد الطبقة التنفيذية، فهي في جوهرها هجوم DoS. ولكن من المهم ملاحظة أن EIP7702، الذي تم اقتراحه كبديل لـ EIP3074، قد واجه أيضًا هذه المشكلة، ولكن EIP7702 أدخل بعض القيود لتجنب ظهور هذه المشكلة، وسنناقش ذلك لاحقًا.
بالإضافة إلى المشاكل الموجودة في EIP3074 المذكورة أعلاه، قدم مؤلف ERC4337 Yova في مقال بعنوان "Implications of EIP-3074 inclusion" مزيدًا من الاعتراضات. ببساطة، تشمل هذه الاعتراضات بشكل رئيسي:
مخاطر المركزية. بسبب الخصائص الخاصة لتوقيع AUTH، يجب على المستخدمين الثقة بالكامل بمزودي الخدمة الوسيطة لـ EIP3074 والبنية التحتية الأساسية. وفي الوقت الحالي، فإن البنية التحتية التي تم بناؤها بواسطة بروتوكولات تجريد الحسابات مثل ERC4337 غير متوافقة تمامًا مع EIP3074.
أمان المستخدم. كما ذُكر أعلاه، فإن EIP3074 لا يحتوي على طريقة موحدة للتحكم في الأذونات، كما أن تصميم توقيع nonce يحمل مخاطر أمنية، مما قد يؤدي إلى ظهور مشاكل أمنية خطيرة.
وظيفة تجريد الحسابات غير المكتملة. مقارنةً بمقترحات تجريد الحسابات الأخرى، فإن EIP3074 غير مكتمل، ولا يمكنه تنفيذ وظائف مثل تغيير خوارزمية توقيع المستخدم.
توجد مشاكل في تجربة المستخدم. عندما يحتاج المستخدم إلى تفويض حسابه لعقد ذكي، يحتاج المستخدم إلى إجراء توقيع AUTH واحد، ثم نشر الاستدعاء الذي يحتوي على توقيع AUTH على السلسلة. يحتاج المستخدم إلى إجراء توقيعين.
EIP7702 هو اقتراح قدمه فيتاليك لاستبدال EIP3074. لم يقدم هذا الاقتراح رموز عمليات جديدة لـ EVM، بل قدم نوعًا جديدًا من المعاملات يُعرف باسم SET_CODE_TX_TYPE. بمجرد أن يبدأ المستخدم معاملة من نوع EIP7702، يمكن للمستخدم إضافة ميزات العقد الذكي إلى EOA الخاص به مع الاحتفاظ بالوظائف الأساسية لـ EOA. ببساطة، يمكن للمستخدمين الاستمرار في استخدام محافظ مثل MetaMask لبدء المعاملات، أو يمكن لمستخدمين آخرين استدعاء عنوان EOA في شكل عقد ذكي.
نقدم وظيفة EIP7702 من خلال مثال بسيط للمعاملات الجماعية. يمكن للمستخدمين استخدام EIP7702 لتفويض عنوان EOA الخاص بهم إلى عقد ذكي يمكنه تنفيذ استدعاءات جماعية، ثم يمكن للمستخدمين استدعاء عنوان EOA الخاص بهم مباشرة من خلال العقد الذكي لبدء معاملات جماعية.
وفيما يتعلق بالتنفيذ التقني، وبالمقارنة مع المعاملات التقليدية، يقدم EIP7702 قائمة بأنواع المعاملات، وهي [[سلسلة_list_id، عنوان، لا شيء، y_parity، r، s]، ...]. حيث العنوان هو عنوان العقد الذكي الذي يريد المستخدم تفويضه، و nonce هو قيمة nonce الحالية للمستخدم. ما تبقى من y \ _parity و r و s هي نتيجة توقيع المستخدم. في عملية التنفيذ المحددة ، سنقوم أولا بالتكرار من خلال كل عنصر في التفويض_list للمعالجة ، وطريقة المعالجة هي استعادة عنوان EOA من خلال معلمات التوقيع مثل y \ _parity ، ثم توجيه عنوان EOA إلى العقد الذكي مع عنوان العنوان. بعد ذلك ، يمكن لعنوان EOA قبول المكالمة لتشغيل وظيفة العقد.
إن مزايا EIP7702 واضحة للغاية، حيث أن الميزة الأساسية لها هي أنها تسمح بشكل أساسي لـ EOA بامتلاك وظائف العقود الذكية. هذا يتماشى مع القواعد الأساسية للاحتساب المجرد مثل ERC4337، مما يعني أن EIP7702 يمكن أن يستفيد من جميع الاستكشافات الحالية في مجال الحساب المجرد وإعادة استخدام البنية التحتية الموجودة، مثلما يمكن لـ EIP7702 استخدام بنية ERC4337 التحتية مباشرة. في الوقت الحالي، أطلقت ERC4337 دعمًا لاستدعاءات EIP7702 من خلال EntryPoint v0.8. من منظور إعادة استخدام البنية التحتية الحالية، تتمتع EIP7702 بنفس درجة اللامركزية مثل ERC4337.
بالطبع، لم يصل EIP7702 إلى إصلاح كامل للمشاكل التي ظهرت في EIP3074. لا تزال معظم المشاكل الموجودة في EIP3074 قائمة. يتطلب EIP7702 أن تمتلك عقود الحساب تنفيذًا آمنًا، بينما لا يضمن البروتوكول نفسه أي أمان. في المراحل المبكرة التي قدم فيها EIP7702، كان هناك بعض المطورين الذين اقترحوا توحيد nonce التوقيع لتجنب هجمات إعادة التشغيل المحتملة، لكن في النهاية لم يقبل EIP7702 هذه الاقتراحات. لذا إذا كان المستخدم يرغب في استخدام EIP7702 بأمان، فسيتعين على المستخدم مراجعة أمان العقد بنفسه.
في الوقت نفسه، ستجلب EIP7702 مجموعة من المشكلات لطبقة التنفيذ. في الفقرة السابقة، قدمنا طريقة محتملة لاستخدام EIP3074 لشن هجوم DoS على تجمع الذاكرة لطبقة التنفيذ. هذه الطريقة فعالة أيضًا في EIP7702. لذلك، توصي EIP7702 بأن تكون جميع عناوين EOA التي تستخدم EIP7702 موجودة في تجمع الذاكرة بصفقة واحدة فقط قيد المعالجة، لتجنب حدوث هجمات DoS واسعة النطاق.
بناءً على ما تقدم، فإن أكبر مشكلة في EIP3074 هي أن EIP3074 لم يحقق وظيفة التجريد الكامل للحسابات، بينما EIP7702 حقق وظيفة التجريد الكامل للحسابات. وقد حدد مؤلفو ERC4337 ما تحتويه "التجريد الكامل للحسابات". يجب أن يكون القراء الآن قادرين على فهم سبب معارضة فريق ERC4337 لـ EIP3074، وفي النهاية تم استبداله بـ EIP7702. سنقوم بتقديم عملية الحوكمة والنقاش الشاملة في النص التالي.
عملية حوكمة EIP3074 و EIP7702
تم ذكر EIP3074 في اجتماع مطوري الإيثريوم الأساسيين في وقت مبكر جداً. في اجتماع #109 بتاريخ 2 أبريل 2021، ناقش مطورون الإيثريوم الأساسيون EIP3074 بشكل بسيط. وكانت نتيجة المناقشة بسيطة جداً:
أليكسى قدم أن محتوى توقيع EIP3074 يحتوي على مخاطر أمنية، وقد يسبب خسائر أمنية خطيرة للمستخدمين، ويقترح أن يتم تنظيم محتوى توقيع AUTH بشكل أكبر في EIP3074، وقد حصل الاقتراح على دعم مارتن.
جيمس اقترح أن EIP3074 قد يجلب ثغرات محتملة في طبقة التنفيذ، مثل هجمات DoS، واقترح أن يقدم EIP3074 تحليلاً للتهديدات بشكل مكتوب.
أليكسي ومارتن اشتكوا من أن جودة وثائق EIP3074 متوسطة، وأنهم قضوا وقتًا طويلاً في القراءة والفهم
مارتن يعتقد أن جوهر EIP3074 هو التعاون والتنفيذ مع التطبيقات، وخاصة مطوري المحافظ، وأشار مؤلف EIP3074 إلى أنه قد أجرى سلسلة من المحادثات مع مطوري التطبيقات.
من المثير للاهتمام أن فيتاليك في هذا المؤتمر اعتقد أنه بغض النظر عن أي شيء، يحتاج الإيثيريوم إلى حل تقني ينتج عدة استدعاءات من معاملة مصممة لـ EOA. على الرغم من وجود مشكلات أمان محتملة في EIP3074، إلا أن EIP3074 يقدم حلاً تقنيًا محتملاً، ويحتاج المطورون إلى التقدم بناءً على EIP3074.
من الواضح أن اجتماع لندن لم يشمل EIP3074 بسبب وجود مشكلات أمان.
في اجتماع #115 بتاريخ 11 يونيو 2021، قدم مطورو EIP3074 تقريرًا حول تدقيق الأمان، حيث ناقش الاجتماع بشكل أساسي قضايا الأمان المتعلقة بـ EIP3074. الاستنتاج البسيط هو أن عقد invoker الخاص بـ EIP3074 مهم جدًا داخل النظام، لذا فإن السؤال هو ما إذا كان هناك حاجة لإدارة عقد invoker. يأمل مطورو EIP3074 في إجراء إثبات رسمي لعقد invoker بهدف زيادة الأمان.
بالطبع، هناك جزء من المناقشة حول استخدام بعض العقود msg.sender == tx.origin للتحقق مما إذا كانت عنوان الاستدعاء هو EOA، عندما تم إدخال EIP3074، فإن هذه التحليلات ستفقد فعاليتها، لكن الخلاصة هي أن فقدان فعالية هذه التحليلات لن يؤدي إلى مشاكل أمنية خطيرة. باختصار، كانت هذه الاجتماع عبارة عن تقديم من قبل مقدمي EIP3074 للمطورين الرئيسيين حول نتائج التدقيق الأمني لـ 3074. وكانت النتيجة النهائية للاجتماع هي أن 3074 لا يزال بحاجة إلى النظر في مشكلة عقد invoker، وينصح بعدم إضافتها في الشوكة الصلبة لندن.
في اجتماع #116 بتاريخ 25 يونيو 2021، قدم المؤلف الرئيسي لـ ERC4337 Yova مواد بعنوان "حالة لبديل أبسط لـ EIP 3074"، حيث أشارت المواد إلى وجود العديد من مشاكل الأمان في EIP3074، واقترحت تعديل بعض محتوياتها، مثل تقييد محتوى حقل commit في التوقيع، بحيث يصبح حقل commit في شكل {nonce,to,gas,calldata,value,chainid}. بعد استخدام هذا النمط من التوقيع، يمكن استخدام EIP3074 فقط لتنفيذ بعض المعاملات المحددة لضمان أمان المعاملات.
في هذا الاجتماع، رد مؤلف EIP3074 على المواد المقدمة من Yova:
نأمل أن يتم تضمين عنوان عقد invoker في مواصفات EIP، ثم يقوم مطورو Ethereum الأساسيون بكتابة عقد invoker آمن لتجنب مشكلات الأمان.
بخصوص محتوى commit في التوقيع، يعتقد مطورو EIP3074 أن هذه المشكلة تتعلق بالكامل بالمستخدم وبرامج محفظة العملات، ولا حاجة لوضع معايير لذلك في EIP.
اقترح فيتاليك النقاط الثلاث التالية في هذا الاجتماع:
EIP3074 لا يزال يستخدم طريقة توقيع secp256k1 التقليدية التي لا يمكن أن تحقق خصائص مقاومة الكم.
EIP3074 ليس لديه توافق مستقبلي، واستخدام EIP3074 لا يمكن أن يجعل EOA تتطور إلى حساب عقد ذكي.
EIP3074 دورة حياة محدودة. 3074 قدمت كودين مسبقين هما AUTH و AUTHCALL، ولكن وفقًا لخريطة طريق تجريد الحسابات، من الممكن أن تصبح جميع المحافظ في الإيثيريوم محفظة عقود ذكية في المستقبل، وبالتالي سيتم إلغاء كودات EIP3074 المسبقة في المستقبل.
في اجتماع #131 الذي عُقد في 4 فبراير 2022، ناقش المطورون نوع EIP الذي يجب أن يتضمنه ترقية شانغهاي. تم تضمين EIP3074 في نطاق المناقشة، لكن المطورين قاموا ببساطة بمزامنة تطورات EIP3074. من الجدير بالذكر أنه قبل بدء الاجتماع، كتبت نذرمايند مقالة بعنوان "محافظ إيثريوم اليوم وغداً - EIP-3074 مقابل ERC-4337"، ولم تتضمن المقالة أي آراء معارضة لـ EIP3074.
في اجتماع #167 بتاريخ 3 أغسطس 2023، ذكر المطورون الرئيسيون EIP3074 أثناء مناقشة EIP5806 أخرى. EIP5806 هو اقتراح يسمح لـ EOA باستدعاء العقود الخارجية أثناء عملية المعاملات باستخدام طريقة deleGate.io call. هذا الاقتراح مشابه إلى حد ما لـ EIP7702. لكن المطورين الرئيسيين أعربوا أيضًا عن شكوكهم حول أمان هذا الاقتراح، حيث أشار Ansgar إلى أن EIP3074 لم يتم تضمينه في الانقسام الصعب بسبب مشاكل الأمان المحتملة.
في اجتماع #182 الذي عقد في 29 فبراير 2024، ناقش المطورون بالتفصيل ما إذا كان ينبغي إدراج EIP3074 في ترقية Pectra. اقترح فيتاليك أن أي معيار للتجريد الحسابي يجب أن يحتوي على الوظائف الثلاث التالية:
تدوير المفاتيح
إلغاء مفاتيح
توقيع مقاوم للكم يمكن التوافق معه
قد تكون تعليقات فيتاليك على EIP5806 خيارا أفضل من EIP3074. يعتقد أندرو أن EIP3074 أكثر تنوعا من EIP5806 ويوصي باستخدام EIP3074. يرد فيتاليك على أندرو ، بحجة أن جميع المحافظ في المستقبل قد تكون محافظ عقود ذكية ، وأنه إذا حدث ذلك ، إبطال رمز التشغيل المجمع مسبقا الذي قدمته EIP3074. قدم يوآف ، مؤلف ERC4337 ، عرضا مطولا في المؤتمر ، والذي غطى الموضوعات التالية:
قد يؤدي EIP3074 إلى هجوم DoS على تجمع ذاكرة الإيثيريوم، بينما قدم ERC4337 الكثير من الدراسات ووضع بعض القواعد لتجنب الهجمات.
يتطلب EIP3074 من المستخدم توقيع المعاملات الجماعية مرتين، وهذا غير معقول.
EIP3074 يتطلب استخدام موصل مركزي
يوفا تميل أكثر إلى استخدام EIP5806 كحل للتجريد الحسابي.
في اجتماع #183 الذي عقد في 14 مارس 2024، دعا المطورون الرئيسيون دان فينلاي من ميتا ماسك لمناقشة وجهة نظر المحفظة حول EIP3074. كان دان مؤيدًا لـ EIP3074، مشيرًا إلى أن ميتا ماسك ستقدم أيضًا الدعم لاختبار EIP3074. تعتقد ميتا ماسك أن EIP3074 يمكن أن يمكّن EOA من الاستفادة من جميع وظائف تجريد الحساب. من الناحية الأمنية، يوفر EIP3074 حلاً لمزودي خدمات المحفظة، وهو فصل المفاتيح الساخنة والباردة. يمكن لمزودي خدمات المحفظة الاحتفاظ بتوقيع EIP3074 الخاص بـ EOA لبدء المعاملات، ويمكن للمستخدمين استخدام المفتاح الخاص الساخن في المعاملات العادية، ولكن يمكن الاحتفاظ بالمفتاح الخاص البارد في محفظة الأجهزة الخاصة بالمستخدم، وعندما يتم اكتشاف حالة طارئة، يمكن للمستخدم استخدام المفتاح الخاص البارد في المحفظة الباردة لإلغاء توقيع EIP3074. يوفر هذا الحل لفصل المفاتيح الساخنة والباردة مرونة لمزودي المحفظة.
أشار فيتالك في EIP3074 إلى أنه يجب على مصممي المحفظة تصميم منطق تفويض صارم لتجنب إساءة استخدام توقيع EIP3074 الخاص بالمستخدمين. ومن المثير للاهتمام، أنه خلال مناقشة دعم ميزة EIP3074 في MetaMask، أشار فيتالك إلى أنه يمكن استخدام L2 كحل انتقالي، حيث يجب أن تتم أي تعديلات جديدة على طبقة التنفيذ داخل L2 كممارسة أولية، نظرًا لأن حجم الأموال في L2 محدود، حتى لو حدثت مشاكل خطيرة، سيؤدي ذلك إلى خسائر جسيمة.
أشار درور تيروس في المناقشة إلى أن أفضل طريقة لضمان أمان EIP3074 هي أن تعطي الإيثيريوم الرسمية عقد invoker مباشرة. لكن دان فينلاي عارض رأي تقديم العقد الرسمي، حيث اعتبر دان أن عقد invoker يجب أن يحدد بالكامل من قبل المستخدم، وأن السوق في النهاية ستختار أكثر عقود invoker أمانًا.
لا يزال أنسجار يصر على أن EIP3074 توقيع واحد يجب أن يتوافق مع معاملة واحدة فقط ، ويجب على مزودي خدمة المحفظة عدم إعادة استخدام توقيعات المستخدم لبدء المعاملات ، لكن دان فينلي اعترض أيضا. يعتقد Dan Finlay أنه يجب توقيع EIP3074 بواسطة محفظة باردة ، ومن ثم يمكن لمزود خدمة المحفظة إعادة استخدام التوقيع لبدء المعاملات مباشرة للمستخدم ، وإذا طلب من المستخدم إعادة التوقيع في كل مرة ، فيمكن استخدام المفتاح الخاص البارد عدة مرات. هذا لا يتفق مع فكرة فصل المفاتيح الخاصة الساخنة والباردة.
في هذا الاجتماع، ناقش المطورون الرئيسيون موضوعًا مهمًا آخر وهو قائمة التضمين. قائمة التضمين هي وسيلة لزيادة خصائص الإيثيريوم المناهضة للرقابة. ببساطة، تسمح قائمة التضمين ببعض المعاملات بالالتزام بأن يتم تضمينها مباشرة في الكتلة التالية. لكن المطورين الرئيسيين أشاروا إلى أن EIP3074 يتعارض مع قائمة التضمين.
في اجتماع #185 الذي عُقد في 11 أبريل 2024، اتفق معظم عملاء التنفيذ الداخلي على إضافة EIP3074 إلى الانقسام الصلب لـ Pectra، لكن Geth أبدى معارضته، حيث أن EIP3074 قد يؤدي إلى مشاكل تتعلق بشجرة Verkle. لا يزال Danno يعبر عن معارضته، لأن EIP3074 قد يؤدي إلى حالات إعادة استخدام التوقيع. كما أبدى Yoav معارضته، حيث قدم Yoav خطة لاستخدام EIP3074 وهجمات Blob على تجمع الذاكرة. ببساطة، يمكن للمهاجم أن يطلق عددًا كبيرًا من معاملات Blob، تحتوي جميعها على كميات كبيرة من البيانات، ثم يستخدم EIP3074 لجعل جميع هذه المعاملات غير صالحة.
باختصار، في هذا الاجتماع، اتفق جميع مطوري العملاء على أن EIP3074 سيتم تضمينه في الترقية النهائية.
في اجتماع رقم 187 في 9 مايو 2024، ناقش المطورون الرئيسيون لأول مرة مسألة استبدال EIP7702 بـ EIP3074. وقد تم الانتهاء من EIP7702 قبل 90 دقيقة من بدء اجتماع المطورين الرئيسيين بقيادة فيتاليك. في الاجتماع، اعترف المطورون الرئيسيون أن EIP7702 هو معيار أفضل بكثير مقارنةً بـ EIP3074. لم يكن هناك أي صوت معارض لـ EIP7702 في هذا الاجتماع، ولكن كان هناك بعض الباحثين الذين يرون أن EIP7702 يحتوي أيضًا على خصائص لا يمكن التراجع عنها مشابهة لـ EIP3074، مما قد يؤدي إلى مشاكل في أمان الأموال.
في اجتماع Meeting #188 الذي عُقد في 23 مايو 2024، ناقش المطورون الرئيسيون إمكانية استبدال EIP7702 بـ EIP3074. وكانت النتيجة النهائية للاجتماع هي استخدام EIP7702 بدلاً من EIP3074 كمعيار تجريد الحسابات في الانقسام الصلب Pectra. أشار فيتاليك إلى أن EIP7702 يحتوي أيضًا على بعض الخصائص غير القابلة للإلغاء المتوافقة مع EIP3074، وقد تم مناقشة هذه الخصائص بشكل مكثف أثناء مناقشة EIP3074. ومن المثير للاهتمام أن هناك عددًا كبيرًا من ممثلي ERC4337 قد شاركوا في المناقشة.
في الواقع، كانت مناقشة استبدال EIP3074 بـ EIP7702 قد نوقشت على نطاق واسع قبل 188 اجتماعًا للمطورين الأساسيين، وكانت نتيجة المناقشة في ذلك الوقت هي أن 3074 سيتم استبداله، لذا لم يكن هناك الكثير من الجدل في اجتماع المطورين الأساسيين.
خريطة الطريق والقرارات
نشرت البنية التحتية الأساسية لواجهة الحساب Zerodev مقالًا مثيرًا للاهتمام بعد أن علمت أن EIP3074 ستتم استبداله، وكان عنوان المقال "تأملات حول حوكمة إيثريوم بعد ملحمة 3074"، وتوصلت المقالة إلى أن EIP7702 هو اقتراح جيد يمكن أن يعود بالنفع على جميع المستخدمين. لكن عملية الحوكمة التي تستبدل EIP3074 بـ EIP7702 ليست الأفضل، والأسباب تشمل:
تم مناقشة EIP3074 لفترة طويلة، وقد قدمنا في النص السابق مناقشات متعددة حول EIP3074 في اجتماع المطورين الأساسيين.
تم تحديد EIP3074 ليتم تضمينه في ترقية Pectra بعد أن تلقى معارضة كبيرة من مجتمع ERC4337. بالطبع، كما أشرنا في النص أعلاه، فإن مطور ERC4337 الرئيسي yova قد عبر عدة مرات في اجتماعات المطورين الرئيسيين عن معارضته لـ EIP3074.
تعتقد Zerodev أن أفضل مسار حوكمة يجب أن يكون من خلال مشاركة واسعة من مجتمع ERC4337 والتعبير عن آرائهم خلال المناقشات المطولة بين المطورين الأساسيين لـ EIP3074.
يعتقد مطورو EIP3074 أن ERC4337 يجب أن يتحمل مسؤولية فشل الحكم. لأن EIP3074 شارك بنشاط في الحكم خلال السنوات القليلة الماضية وتواصل عدة مرات مع مطورين رئيسيين في ERC4337 مثل yova.
تعتقد مجتمع ERC4337 أن EIP3074 يجب أن يتحمل المسؤولية الرئيسية عن فشل الحوكمة. يعتبر أعضاء مجتمع ERC4337 أن Yova، بوصفه مطورًا رئيسيًا لـ ERC4337، قد عبر في عدة اجتماعات للمطورين الرئيسيين عن معارضته لـ EIP3074، لكن المطورين الرئيسيين يبدو أنهم لم يستمعوا إلى الآراء. لم يكن معظم أعضاء المجتمع في ERC4337 مهتمين بديناميكيات الحوكمة لـ EIP3074، حيث يعتقد معظم الأعضاء أن EIP3074 هو معيار ميت. يعتقد مجتمع ERC4337 أيضًا أن المطورين الرئيسيين لم يتواصلوا بنشاط مع مجتمع ERC4337.
تعتقد EIP3074 و ERC4337 أنهما قامتا بعمل حكومي صحيح ، ويجب أن تتحمل الأخرى المسؤولية الرئيسية عن فشل الحكومة. من الواضح أن هناك سببًا أعمق يلعب دورًا في هذه العملية الحكومية.
ببساطة، السبب الأعمق هو في الواقع خارطة طريق إيثريوم. تمتلك خارطة طريق إيثريوم سلطة تفوق اجتماعات المطورين الأساسيين. خارطة طريق تجريد الحسابات تركز على ERC4337. EIP7702 متوافق تمامًا مع معيار ERC4337، ولكن EIP3074 ليس متوافقًا بالكامل مع معيار ERC4337. لذلك، من منظور خارطة طريق إيثريوم، من المؤكد أن EIP3074 سيُستبدل.
بالطبع، خريطة طريق الإيثريوم هي عرض لرؤية فيتاليك الشخصية لمستقبل الإيثريوم. إذا حدث جدل خطير أثناء عملية الحوكمة، فإن فيتاليك، باعتباره مُحدد خريطة الطريق، يمتلك السلطة النهائية في القرار. وقد أدت قرارات فيتاليك إلى استبدال EIP3074.
نموذج حوكمة الإيثريوم هو نموذج القيم ⇒ الرؤية ⇒ خرائط الطريق ⇒ العملاء، أو ما يعرف اختصارًا بنموذج VVRC. عملية الحوكمة الخاصة به هي كما يلي:
القيم ، خاصة قيم المجتمع ، تشمل قيم مجتمع الإيثيريوم اللامركزية ومقاومة الرقابة وغيرها.
الرؤية، في الواقع، هي تفكير فيتاليك الشخصي حول مستقبل الإيثيريوم.
roadmaps خرائط الطريق، يقدم الباحث بعض الاعتبارات التقنية بناءً على الرؤية لتقديم خارطة طريق تنفيذية أكثر اكتمالاً.
تنفيذ العملاء، يقوم المطورون الرئيسيون للعملاء بمناقشة خارطة الطريق باستخدام أدوات مثل اجتماعات المطورين الرئيسيين، وتنفيذ المتطلبات الموجودة في خارطة الطريق.
العملية المذكورة أعلاه هي عملية الحوكمة الحقيقية للإيثريوم. يمكننا أن نرى أن الرؤية الشخصية لـ Vitalik تقع في الجزء الأساسي من نموذج حوكمة الإيثريوم، لذا بمجرد ظهور جدل خطير في تنفيذ العميل، ستتم ممارسة الرأي الشخصي لـ Vitalik كحكم نهائي.
مصادر
مقدمة ZeroDev
لاغية
مقدمة ZeroDev
لاغية
ملاحظات حول خارطة طريق تجريد الحسابات - HackMD
ملاحظات حول خارطة طريق تجريد الحساب *شكر خاص لفيتاليك وفريق AA على الملاحظات
المحتوى هو للمرجعية فقط، وليس دعوة أو عرضًا. لا يتم تقديم أي مشورة استثمارية أو ضريبية أو قانونية. للمزيد من الإفصاحات حول المخاطر، يُرجى الاطلاع على إخلاء المسؤولية.
حرب حوكمة إثيريوم: EIP3074، ERC4337 و EIP7702
المؤلف: shew
نظرة عامة
ظهرت مشاكل نزاع الحوكمة الأكثر تعقيدًا في ترقية Pectra. بعد إدراج EIP3074 في ترقية Pectra، حدث جدل كبير، خاصة من فريق ERC4337.
EIP3074 وقع في مأزق، ولم تتمكن عملية الحوكمة من الاستمرار. حتى اقترح فيتالك EIP7702 لإنهاء تساؤلات فريق ERC4337 حول EIP3074.
وجدت GCC Research أن هناك نقاشًا قليلاً حول قضايا الحوكمة المتعلقة بـ EIP3074 و ERC7702 في ترقية Pectra في العالم الناطق بالصينية. لكن هذه القضايا الحوكمة تعكس أيضًا مشكلة عميقة في حوكمة الإيثيريوم، وهي: من يمكنه التحكم في المحتوى المحدد للكود في ظل مبدأ "الكود هو القانون". يمكن أن توفر لنا قضايا الحوكمة المتعلقة بـ EIP3074 و ERC7702 منظورًا جيدًا لمراقبة العملية الحقيقية للحوكمة داخل الإيثيريوم.
الاستنتاج النهائي من هذه المقالة مستمد من التعليق الذي نشره ZeroDev، والذي يشير إلى أن نظام حوكمة الإيثريوم هو نموذج VVRC، ويجب أن يتوافق أي اقتراح يتم إدخاله أولاً مع قيم الإيثريوم (Value)، ثم يجب أن يعكس الاقتراح الرؤية التي صممها فيتالك (Vision)، وأخيرًا يجب أن ينعكس الاقتراح في خارطة الطريق (Roadmap)، وأخيرًا بعد مناقشة المطورين الرئيسيين، سيتم تضمينه في تنفيذ العميل (Client).
أشار بحث GCC في المقالة السابقة إلى أن EIP2537 واجهت مشاكل في التنفيذ على مستوى العميل مما أدى إلى تأخير انضمامه إلى التجزئة الصلبة، بينما لم يتم تضمين EIP3074 في النهاية بسبب مشاكل في الرؤية وخطة الطريق، حيث اختار مطورو إيثيريوم الأساسيون مباشرة EIP7702 الذي كتبه فيتاليك كاقتراح نهائي لتجريد الحساب.
ملخص محتوى الاقتراح
قبل تقديم تفاصيل عملية الحوكمة المحددة، نحتاج أولاً إلى تقديم مقدمة بسيطة حول المحتوى المحدد للبيانات EIP3074 و EIP7702 و ERC4337 التي يتناولها هذا المقال.
EIP3074 هو اقتراح على مستوى التنفيذ، ويتطلب تنفيذ هذا الاقتراح ترقية برامج العقد. الهدف الرئيسي من EIP3074 هو تحقيق وظيفة رعاية الغاز والمعاملات الجماعية. ما يسمى برعاية الغاز يعني أن المستخدم يمكنه استخدام أي رمز لدفع رسوم الغاز، أو يمكن للمستخدم دفع رسوم الغاز في وضع عدم الاتصال. ولكن يجب أن نلاحظ أنه بالمقارنة مع اقتراحات تجريد الحسابات الأخرى التي تسمح بتغيير خوارزمية التحقق من التوقيع، فإن EIP3074 لا يسمح للمستخدمين باستخدام أي خوارزمية توقيع بخلاف secp256k1. بعبارة أخرى، EIP3074 ليس اقتراحًا يلبي جميع وظائف تجريد الحسابات. هذه هي النقطة التي تم انتقاد EIP3074 بسببها.
لتحقيق الأهداف المتوقعة، قدم EIP3074 عمليتي رمز تشغيل، وهما AUTH و AUTHCALL. يمكن لرمز التشغيل AUTH التحقق من التوقيع، وعندما ينجح التحقق من التوقيع، سيتم تكوين authorized في سياق EVM الحالي ليكون عنوان الموقع. بعد تكوين authorized في السياق، يمكن لـ AUTHCALL استخدام عنوان authorized كمصدر للمسافة msg.sender لإجراء المعاملة. إلى حد ما، يمكن للمستخدمين من خلال التوقيع تفويض حساباتهم لاستخدامها من قبل عقد ذكي في معاملة واحدة. عادة ما نسمي هذا العقد الذكي المفوض من قبل المستخدم بعقد invoker.
ما هو محتوى توقيع المستخدم المحدد؟ يحتاج المستخدم إلى توقيع المحتوى التالي:
! حروب حوكمة الإيثريوم: EIP3074 و ERC4337 و EIP7702
العنوان المستدعي المذكور في المحتوى أعلاه يشير إلى عنوان عقد المستدعي الذي يرغب المستخدم في تفويضه، ستتحقق EVM من محتوى توقيع المستخدم وما إذا كان يتطابق مع العقد الذي يتحقق فعليًا من التوقيع، لتجنب استخدام محتوى توقيع AUTH الخاص بالمستخدم من قبل عقود أخرى.
nonce هو معرف يمنع إعادة تشغيل المعاملات. ولكن يجب الانتباه إلى أن عملية AUTH ستتحقق من تطابق nonce في التوقيع مع nonce EOA الحالي للتوقيع. نظريًا، طالما أن المستخدم لا يستخدم حساب EOA لبدء المعاملات لزيادة قيمة nonce، فإن توقيع AUTH الذي يرسله المستخدم يمكن أن يستمر في استخدامه من قبل عقد invoker. هذه ثغرة أمان هائلة، مما يعني أن المستخدمين الذين يستخدمون EIP3074 يجب أن يثقوا في مزودي خدمات الوساطة الذين يحصلون على التوقيع. إذا كان مزود خدمة الوساطة الذي يحصل على توقيع المستخدم خبيثًا، فقد يقوم في وقت ما بإعادة تشغيل توقيع AUTH الخاص بالمستخدم وسرقة أصوله.
تعتبر حقل commit من الأمور التي تعاني من مشاكل أمنية. يتم استخدام حقل commit لضمان بعض العمليات، حيث يمكن للمستخدم التحكم بدقة في صلاحيات توقيعه داخل commit، مثل كتابة محتوى معين داخل commit لتجنب استخدام محتوى توقيعه في تحويلات ETH. في وثيقة EIP3074، قدم المقترح سلسلة من الأمثلة لاستخدام حقل commit. لكن المشكلة تكمن في أن وظيفة commit تعتمد تمامًا على تعريف العقود الذكية، وهي في جوهرها محتوى اختياري. قد تكون تفسيرات محتوى commit مختلفة تمامًا بين العقود الذكية المختلفة، وحتى قد لا تقرأ بعض العقود محتوى commit على الإطلاق. إذا كان المستخدم يرغب في استخدام EIP3074 بشكل آمن، يجب عليه مراجعة العقود الذكية ببساطة.
أخيرًا، نقدم تأثير EIP3074 على تجمع ذاكرة المعاملات الحالي في إيثيريوم. بعد إدخال EIP3074، قد تظهر طريقة هجوم على تجمع الذاكرة، حيث يمكن للقراصنة استخدام عدد كبير من الحسابات لبدء المعاملات، ثم عند اقتراب حزم المعاملة، يستخدمون EIP3074 لسحب كل ETH من هذه الحسابات دفعة واحدة، مما يؤدي إلى فشل جميع المعاملات التي تم بدءها سابقًا. ستؤثر هذه الطريقة الهجومية بشكل كبير على عقد الطبقة التنفيذية، فهي في جوهرها هجوم DoS. ولكن من المهم ملاحظة أن EIP7702، الذي تم اقتراحه كبديل لـ EIP3074، قد واجه أيضًا هذه المشكلة، ولكن EIP7702 أدخل بعض القيود لتجنب ظهور هذه المشكلة، وسنناقش ذلك لاحقًا.
بالإضافة إلى المشاكل الموجودة في EIP3074 المذكورة أعلاه، قدم مؤلف ERC4337 Yova في مقال بعنوان "Implications of EIP-3074 inclusion" مزيدًا من الاعتراضات. ببساطة، تشمل هذه الاعتراضات بشكل رئيسي:
EIP7702 هو اقتراح قدمه فيتاليك لاستبدال EIP3074. لم يقدم هذا الاقتراح رموز عمليات جديدة لـ EVM، بل قدم نوعًا جديدًا من المعاملات يُعرف باسم SET_CODE_TX_TYPE. بمجرد أن يبدأ المستخدم معاملة من نوع EIP7702، يمكن للمستخدم إضافة ميزات العقد الذكي إلى EOA الخاص به مع الاحتفاظ بالوظائف الأساسية لـ EOA. ببساطة، يمكن للمستخدمين الاستمرار في استخدام محافظ مثل MetaMask لبدء المعاملات، أو يمكن لمستخدمين آخرين استدعاء عنوان EOA في شكل عقد ذكي.
نقدم وظيفة EIP7702 من خلال مثال بسيط للمعاملات الجماعية. يمكن للمستخدمين استخدام EIP7702 لتفويض عنوان EOA الخاص بهم إلى عقد ذكي يمكنه تنفيذ استدعاءات جماعية، ثم يمكن للمستخدمين استدعاء عنوان EOA الخاص بهم مباشرة من خلال العقد الذكي لبدء معاملات جماعية.
وفيما يتعلق بالتنفيذ التقني، وبالمقارنة مع المعاملات التقليدية، يقدم EIP7702 قائمة بأنواع المعاملات، وهي [[سلسلة_list_id، عنوان، لا شيء، y_parity، r، s]، ...]. حيث العنوان هو عنوان العقد الذكي الذي يريد المستخدم تفويضه، و nonce هو قيمة nonce الحالية للمستخدم. ما تبقى من y \ _parity و r و s هي نتيجة توقيع المستخدم. في عملية التنفيذ المحددة ، سنقوم أولا بالتكرار من خلال كل عنصر في التفويض_list للمعالجة ، وطريقة المعالجة هي استعادة عنوان EOA من خلال معلمات التوقيع مثل y \ _parity ، ثم توجيه عنوان EOA إلى العقد الذكي مع عنوان العنوان. بعد ذلك ، يمكن لعنوان EOA قبول المكالمة لتشغيل وظيفة العقد.
إن مزايا EIP7702 واضحة للغاية، حيث أن الميزة الأساسية لها هي أنها تسمح بشكل أساسي لـ EOA بامتلاك وظائف العقود الذكية. هذا يتماشى مع القواعد الأساسية للاحتساب المجرد مثل ERC4337، مما يعني أن EIP7702 يمكن أن يستفيد من جميع الاستكشافات الحالية في مجال الحساب المجرد وإعادة استخدام البنية التحتية الموجودة، مثلما يمكن لـ EIP7702 استخدام بنية ERC4337 التحتية مباشرة. في الوقت الحالي، أطلقت ERC4337 دعمًا لاستدعاءات EIP7702 من خلال EntryPoint v0.8. من منظور إعادة استخدام البنية التحتية الحالية، تتمتع EIP7702 بنفس درجة اللامركزية مثل ERC4337.
بالطبع، لم يصل EIP7702 إلى إصلاح كامل للمشاكل التي ظهرت في EIP3074. لا تزال معظم المشاكل الموجودة في EIP3074 قائمة. يتطلب EIP7702 أن تمتلك عقود الحساب تنفيذًا آمنًا، بينما لا يضمن البروتوكول نفسه أي أمان. في المراحل المبكرة التي قدم فيها EIP7702، كان هناك بعض المطورين الذين اقترحوا توحيد nonce التوقيع لتجنب هجمات إعادة التشغيل المحتملة، لكن في النهاية لم يقبل EIP7702 هذه الاقتراحات. لذا إذا كان المستخدم يرغب في استخدام EIP7702 بأمان، فسيتعين على المستخدم مراجعة أمان العقد بنفسه.
في الوقت نفسه، ستجلب EIP7702 مجموعة من المشكلات لطبقة التنفيذ. في الفقرة السابقة، قدمنا طريقة محتملة لاستخدام EIP3074 لشن هجوم DoS على تجمع الذاكرة لطبقة التنفيذ. هذه الطريقة فعالة أيضًا في EIP7702. لذلك، توصي EIP7702 بأن تكون جميع عناوين EOA التي تستخدم EIP7702 موجودة في تجمع الذاكرة بصفقة واحدة فقط قيد المعالجة، لتجنب حدوث هجمات DoS واسعة النطاق.
بناءً على ما تقدم، فإن أكبر مشكلة في EIP3074 هي أن EIP3074 لم يحقق وظيفة التجريد الكامل للحسابات، بينما EIP7702 حقق وظيفة التجريد الكامل للحسابات. وقد حدد مؤلفو ERC4337 ما تحتويه "التجريد الكامل للحسابات". يجب أن يكون القراء الآن قادرين على فهم سبب معارضة فريق ERC4337 لـ EIP3074، وفي النهاية تم استبداله بـ EIP7702. سنقوم بتقديم عملية الحوكمة والنقاش الشاملة في النص التالي.
عملية حوكمة EIP3074 و EIP7702
تم ذكر EIP3074 في اجتماع مطوري الإيثريوم الأساسيين في وقت مبكر جداً. في اجتماع #109 بتاريخ 2 أبريل 2021، ناقش مطورون الإيثريوم الأساسيون EIP3074 بشكل بسيط. وكانت نتيجة المناقشة بسيطة جداً:
من المثير للاهتمام أن فيتاليك في هذا المؤتمر اعتقد أنه بغض النظر عن أي شيء، يحتاج الإيثيريوم إلى حل تقني ينتج عدة استدعاءات من معاملة مصممة لـ EOA. على الرغم من وجود مشكلات أمان محتملة في EIP3074، إلا أن EIP3074 يقدم حلاً تقنيًا محتملاً، ويحتاج المطورون إلى التقدم بناءً على EIP3074.
من الواضح أن اجتماع لندن لم يشمل EIP3074 بسبب وجود مشكلات أمان.
في اجتماع #115 بتاريخ 11 يونيو 2021، قدم مطورو EIP3074 تقريرًا حول تدقيق الأمان، حيث ناقش الاجتماع بشكل أساسي قضايا الأمان المتعلقة بـ EIP3074. الاستنتاج البسيط هو أن عقد invoker الخاص بـ EIP3074 مهم جدًا داخل النظام، لذا فإن السؤال هو ما إذا كان هناك حاجة لإدارة عقد invoker. يأمل مطورو EIP3074 في إجراء إثبات رسمي لعقد invoker بهدف زيادة الأمان.
بالطبع، هناك جزء من المناقشة حول استخدام بعض العقود msg.sender == tx.origin للتحقق مما إذا كانت عنوان الاستدعاء هو EOA، عندما تم إدخال EIP3074، فإن هذه التحليلات ستفقد فعاليتها، لكن الخلاصة هي أن فقدان فعالية هذه التحليلات لن يؤدي إلى مشاكل أمنية خطيرة. باختصار، كانت هذه الاجتماع عبارة عن تقديم من قبل مقدمي EIP3074 للمطورين الرئيسيين حول نتائج التدقيق الأمني لـ 3074. وكانت النتيجة النهائية للاجتماع هي أن 3074 لا يزال بحاجة إلى النظر في مشكلة عقد invoker، وينصح بعدم إضافتها في الشوكة الصلبة لندن.
في اجتماع #116 بتاريخ 25 يونيو 2021، قدم المؤلف الرئيسي لـ ERC4337 Yova مواد بعنوان "حالة لبديل أبسط لـ EIP 3074"، حيث أشارت المواد إلى وجود العديد من مشاكل الأمان في EIP3074، واقترحت تعديل بعض محتوياتها، مثل تقييد محتوى حقل commit في التوقيع، بحيث يصبح حقل commit في شكل {nonce,to,gas,calldata,value,chainid}. بعد استخدام هذا النمط من التوقيع، يمكن استخدام EIP3074 فقط لتنفيذ بعض المعاملات المحددة لضمان أمان المعاملات.
في هذا الاجتماع، رد مؤلف EIP3074 على المواد المقدمة من Yova:
اقترح فيتاليك النقاط الثلاث التالية في هذا الاجتماع:
في اجتماع #131 الذي عُقد في 4 فبراير 2022، ناقش المطورون نوع EIP الذي يجب أن يتضمنه ترقية شانغهاي. تم تضمين EIP3074 في نطاق المناقشة، لكن المطورين قاموا ببساطة بمزامنة تطورات EIP3074. من الجدير بالذكر أنه قبل بدء الاجتماع، كتبت نذرمايند مقالة بعنوان "محافظ إيثريوم اليوم وغداً - EIP-3074 مقابل ERC-4337"، ولم تتضمن المقالة أي آراء معارضة لـ EIP3074.
في اجتماع #167 بتاريخ 3 أغسطس 2023، ذكر المطورون الرئيسيون EIP3074 أثناء مناقشة EIP5806 أخرى. EIP5806 هو اقتراح يسمح لـ EOA باستدعاء العقود الخارجية أثناء عملية المعاملات باستخدام طريقة deleGate.io call. هذا الاقتراح مشابه إلى حد ما لـ EIP7702. لكن المطورين الرئيسيين أعربوا أيضًا عن شكوكهم حول أمان هذا الاقتراح، حيث أشار Ansgar إلى أن EIP3074 لم يتم تضمينه في الانقسام الصعب بسبب مشاكل الأمان المحتملة.
في اجتماع #182 الذي عقد في 29 فبراير 2024، ناقش المطورون بالتفصيل ما إذا كان ينبغي إدراج EIP3074 في ترقية Pectra. اقترح فيتاليك أن أي معيار للتجريد الحسابي يجب أن يحتوي على الوظائف الثلاث التالية:
قد تكون تعليقات فيتاليك على EIP5806 خيارا أفضل من EIP3074. يعتقد أندرو أن EIP3074 أكثر تنوعا من EIP5806 ويوصي باستخدام EIP3074. يرد فيتاليك على أندرو ، بحجة أن جميع المحافظ في المستقبل قد تكون محافظ عقود ذكية ، وأنه إذا حدث ذلك ، إبطال رمز التشغيل المجمع مسبقا الذي قدمته EIP3074. قدم يوآف ، مؤلف ERC4337 ، عرضا مطولا في المؤتمر ، والذي غطى الموضوعات التالية:
يوفا تميل أكثر إلى استخدام EIP5806 كحل للتجريد الحسابي.
في اجتماع #183 الذي عقد في 14 مارس 2024، دعا المطورون الرئيسيون دان فينلاي من ميتا ماسك لمناقشة وجهة نظر المحفظة حول EIP3074. كان دان مؤيدًا لـ EIP3074، مشيرًا إلى أن ميتا ماسك ستقدم أيضًا الدعم لاختبار EIP3074. تعتقد ميتا ماسك أن EIP3074 يمكن أن يمكّن EOA من الاستفادة من جميع وظائف تجريد الحساب. من الناحية الأمنية، يوفر EIP3074 حلاً لمزودي خدمات المحفظة، وهو فصل المفاتيح الساخنة والباردة. يمكن لمزودي خدمات المحفظة الاحتفاظ بتوقيع EIP3074 الخاص بـ EOA لبدء المعاملات، ويمكن للمستخدمين استخدام المفتاح الخاص الساخن في المعاملات العادية، ولكن يمكن الاحتفاظ بالمفتاح الخاص البارد في محفظة الأجهزة الخاصة بالمستخدم، وعندما يتم اكتشاف حالة طارئة، يمكن للمستخدم استخدام المفتاح الخاص البارد في المحفظة الباردة لإلغاء توقيع EIP3074. يوفر هذا الحل لفصل المفاتيح الساخنة والباردة مرونة لمزودي المحفظة.
أشار فيتالك في EIP3074 إلى أنه يجب على مصممي المحفظة تصميم منطق تفويض صارم لتجنب إساءة استخدام توقيع EIP3074 الخاص بالمستخدمين. ومن المثير للاهتمام، أنه خلال مناقشة دعم ميزة EIP3074 في MetaMask، أشار فيتالك إلى أنه يمكن استخدام L2 كحل انتقالي، حيث يجب أن تتم أي تعديلات جديدة على طبقة التنفيذ داخل L2 كممارسة أولية، نظرًا لأن حجم الأموال في L2 محدود، حتى لو حدثت مشاكل خطيرة، سيؤدي ذلك إلى خسائر جسيمة.
أشار درور تيروس في المناقشة إلى أن أفضل طريقة لضمان أمان EIP3074 هي أن تعطي الإيثيريوم الرسمية عقد invoker مباشرة. لكن دان فينلاي عارض رأي تقديم العقد الرسمي، حيث اعتبر دان أن عقد invoker يجب أن يحدد بالكامل من قبل المستخدم، وأن السوق في النهاية ستختار أكثر عقود invoker أمانًا.
لا يزال أنسجار يصر على أن EIP3074 توقيع واحد يجب أن يتوافق مع معاملة واحدة فقط ، ويجب على مزودي خدمة المحفظة عدم إعادة استخدام توقيعات المستخدم لبدء المعاملات ، لكن دان فينلي اعترض أيضا. يعتقد Dan Finlay أنه يجب توقيع EIP3074 بواسطة محفظة باردة ، ومن ثم يمكن لمزود خدمة المحفظة إعادة استخدام التوقيع لبدء المعاملات مباشرة للمستخدم ، وإذا طلب من المستخدم إعادة التوقيع في كل مرة ، فيمكن استخدام المفتاح الخاص البارد عدة مرات. هذا لا يتفق مع فكرة فصل المفاتيح الخاصة الساخنة والباردة.
في هذا الاجتماع، ناقش المطورون الرئيسيون موضوعًا مهمًا آخر وهو قائمة التضمين. قائمة التضمين هي وسيلة لزيادة خصائص الإيثيريوم المناهضة للرقابة. ببساطة، تسمح قائمة التضمين ببعض المعاملات بالالتزام بأن يتم تضمينها مباشرة في الكتلة التالية. لكن المطورين الرئيسيين أشاروا إلى أن EIP3074 يتعارض مع قائمة التضمين.
في اجتماع #185 الذي عُقد في 11 أبريل 2024، اتفق معظم عملاء التنفيذ الداخلي على إضافة EIP3074 إلى الانقسام الصلب لـ Pectra، لكن Geth أبدى معارضته، حيث أن EIP3074 قد يؤدي إلى مشاكل تتعلق بشجرة Verkle. لا يزال Danno يعبر عن معارضته، لأن EIP3074 قد يؤدي إلى حالات إعادة استخدام التوقيع. كما أبدى Yoav معارضته، حيث قدم Yoav خطة لاستخدام EIP3074 وهجمات Blob على تجمع الذاكرة. ببساطة، يمكن للمهاجم أن يطلق عددًا كبيرًا من معاملات Blob، تحتوي جميعها على كميات كبيرة من البيانات، ثم يستخدم EIP3074 لجعل جميع هذه المعاملات غير صالحة.
باختصار، في هذا الاجتماع، اتفق جميع مطوري العملاء على أن EIP3074 سيتم تضمينه في الترقية النهائية.
في اجتماع رقم 187 في 9 مايو 2024، ناقش المطورون الرئيسيون لأول مرة مسألة استبدال EIP7702 بـ EIP3074. وقد تم الانتهاء من EIP7702 قبل 90 دقيقة من بدء اجتماع المطورين الرئيسيين بقيادة فيتاليك. في الاجتماع، اعترف المطورون الرئيسيون أن EIP7702 هو معيار أفضل بكثير مقارنةً بـ EIP3074. لم يكن هناك أي صوت معارض لـ EIP7702 في هذا الاجتماع، ولكن كان هناك بعض الباحثين الذين يرون أن EIP7702 يحتوي أيضًا على خصائص لا يمكن التراجع عنها مشابهة لـ EIP3074، مما قد يؤدي إلى مشاكل في أمان الأموال.
في اجتماع Meeting #188 الذي عُقد في 23 مايو 2024، ناقش المطورون الرئيسيون إمكانية استبدال EIP7702 بـ EIP3074. وكانت النتيجة النهائية للاجتماع هي استخدام EIP7702 بدلاً من EIP3074 كمعيار تجريد الحسابات في الانقسام الصلب Pectra. أشار فيتاليك إلى أن EIP7702 يحتوي أيضًا على بعض الخصائص غير القابلة للإلغاء المتوافقة مع EIP3074، وقد تم مناقشة هذه الخصائص بشكل مكثف أثناء مناقشة EIP3074. ومن المثير للاهتمام أن هناك عددًا كبيرًا من ممثلي ERC4337 قد شاركوا في المناقشة.
في الواقع، كانت مناقشة استبدال EIP3074 بـ EIP7702 قد نوقشت على نطاق واسع قبل 188 اجتماعًا للمطورين الأساسيين، وكانت نتيجة المناقشة في ذلك الوقت هي أن 3074 سيتم استبداله، لذا لم يكن هناك الكثير من الجدل في اجتماع المطورين الأساسيين.
خريطة الطريق والقرارات
نشرت البنية التحتية الأساسية لواجهة الحساب Zerodev مقالًا مثيرًا للاهتمام بعد أن علمت أن EIP3074 ستتم استبداله، وكان عنوان المقال "تأملات حول حوكمة إيثريوم بعد ملحمة 3074"، وتوصلت المقالة إلى أن EIP7702 هو اقتراح جيد يمكن أن يعود بالنفع على جميع المستخدمين. لكن عملية الحوكمة التي تستبدل EIP3074 بـ EIP7702 ليست الأفضل، والأسباب تشمل:
تعتقد Zerodev أن أفضل مسار حوكمة يجب أن يكون من خلال مشاركة واسعة من مجتمع ERC4337 والتعبير عن آرائهم خلال المناقشات المطولة بين المطورين الأساسيين لـ EIP3074.
يعتقد مطورو EIP3074 أن ERC4337 يجب أن يتحمل مسؤولية فشل الحكم. لأن EIP3074 شارك بنشاط في الحكم خلال السنوات القليلة الماضية وتواصل عدة مرات مع مطورين رئيسيين في ERC4337 مثل yova.
تعتقد مجتمع ERC4337 أن EIP3074 يجب أن يتحمل المسؤولية الرئيسية عن فشل الحوكمة. يعتبر أعضاء مجتمع ERC4337 أن Yova، بوصفه مطورًا رئيسيًا لـ ERC4337، قد عبر في عدة اجتماعات للمطورين الرئيسيين عن معارضته لـ EIP3074، لكن المطورين الرئيسيين يبدو أنهم لم يستمعوا إلى الآراء. لم يكن معظم أعضاء المجتمع في ERC4337 مهتمين بديناميكيات الحوكمة لـ EIP3074، حيث يعتقد معظم الأعضاء أن EIP3074 هو معيار ميت. يعتقد مجتمع ERC4337 أيضًا أن المطورين الرئيسيين لم يتواصلوا بنشاط مع مجتمع ERC4337.
تعتقد EIP3074 و ERC4337 أنهما قامتا بعمل حكومي صحيح ، ويجب أن تتحمل الأخرى المسؤولية الرئيسية عن فشل الحكومة. من الواضح أن هناك سببًا أعمق يلعب دورًا في هذه العملية الحكومية.
ببساطة، السبب الأعمق هو في الواقع خارطة طريق إيثريوم. تمتلك خارطة طريق إيثريوم سلطة تفوق اجتماعات المطورين الأساسيين. خارطة طريق تجريد الحسابات تركز على ERC4337. EIP7702 متوافق تمامًا مع معيار ERC4337، ولكن EIP3074 ليس متوافقًا بالكامل مع معيار ERC4337. لذلك، من منظور خارطة طريق إيثريوم، من المؤكد أن EIP3074 سيُستبدل.
بالطبع، خريطة طريق الإيثريوم هي عرض لرؤية فيتاليك الشخصية لمستقبل الإيثريوم. إذا حدث جدل خطير أثناء عملية الحوكمة، فإن فيتاليك، باعتباره مُحدد خريطة الطريق، يمتلك السلطة النهائية في القرار. وقد أدت قرارات فيتاليك إلى استبدال EIP3074.
نموذج حوكمة الإيثريوم هو نموذج القيم ⇒ الرؤية ⇒ خرائط الطريق ⇒ العملاء، أو ما يعرف اختصارًا بنموذج VVRC. عملية الحوكمة الخاصة به هي كما يلي:
العملية المذكورة أعلاه هي عملية الحوكمة الحقيقية للإيثريوم. يمكننا أن نرى أن الرؤية الشخصية لـ Vitalik تقع في الجزء الأساسي من نموذج حوكمة الإيثريوم، لذا بمجرد ظهور جدل خطير في تنفيذ العميل، ستتم ممارسة الرأي الشخصي لـ Vitalik كحكم نهائي.