*شكر خاص لجوستين دريك وتينا تشن ويواف فايس على تعليقاتهم ومراجعتهم. *
منذ بداية مشروع إيثريوم، كانت هناك فلسفة قوية تتمثل في محاولة جعل جوهر إيثريوم بسيطًا قدر الإمكان، وتحقيق ذلك قدر الإمكان من خلال بناء بروتوكولات فوقه. في مجال blockchain، غالبًا ما يُنظر إلى النقاش حول "البناء على L1" مقابل "التركيز على L2" على أنه يدور في المقام الأول حول التوسع، ولكن في الواقع، هناك مشكلات مماثلة في تلبية احتياجات العديد من مستخدمي Ethereum: تبادل الأصول الرقمية، والخصوصية. وأسماء المستخدمين والتشفير المتقدم وأمن الحساب ومقاومة الرقابة والحماية الأمامية والمزيد. ومع ذلك، كانت هناك بعض المحاولات الحذرة الأخيرة لتضمين المزيد من هذه الميزات في بروتوكول إيثريوم الأساسي.
سوف تتعمق هذه المقالة في بعض الأسباب الفلسفية وراء الفلسفة الأصلية للتغليف الأدنى، بالإضافة إلى بعض طرق التفكير الحديثة حول هذه الأفكار. سيكون الهدف هو البدء في بناء إطار عمل لتحديد الأهداف المحتملة بشكل أفضل حيث قد يكون من المفيد النظر في تغليف وظائف معينة.
فلسفة مبكرة حول بساطة البروتوكول
في التاريخ المبكر لما كان يُعرف آنذاك باسم "Ethereum 2.0"، كانت هناك رغبة قوية في إنشاء بروتوكول نظيف وبسيط وجميل حاول بأقل قدر ممكن البناء على نفسه وترك كل هذه الأعمال تقريبًا للمستخدمين. من الناحية المثالية، يكون البروتوكول مجرد جهاز افتراضي، والتحقق من صحة الكتلة هو مجرد استدعاء جهاز افتراضي.
هذه إعادة بناء تقريبية لمخطط السبورة البيضاء الذي رسمته أنا وجافين وود في أوائل عام 2015 عندما كنت أتحدث عن الشكل الذي سيبدو عليه Ethereum 2.0.
ستكون "وظيفة نقل الحالة" (الوظيفة التي تتعامل مع الكتلة) مجرد مكالمة واحدة لـ VM، وكل المنطق الآخر سيحدث من خلال العقود: بعض العقود على مستوى النظام، ولكن في الغالب العقود المقدمة من المستخدم. الميزة الرائعة جدًا لهذا النموذج هي أنه حتى الهارد فورك بأكمله يمكن وصفه بأنه معاملة واحدة لعقد معالج الكتلة، والذي ستتم الموافقة عليه من خلال الحوكمة خارج السلسلة أو على السلسلة ثم ترقية إذن التشغيل.
تنطبق هذه المناقشات في عام 2015 على وجه التحديد على مجالين نأخذهما في الاعتبار: تجريد الحساب وتوسيع نطاقه. في حالة القياس، تتمثل الفكرة في محاولة إنشاء الحد الأقصى من أشكال القياس المجردة التي تبدو وكأنها امتداد طبيعي للرسم البياني أعلاه. يمكن للعقود استدعاء البيانات التي لا يتم تخزينها بواسطة معظم عقد الإيثيريوم، وسيقوم البروتوكول باكتشاف ذلك وحل المكالمة عبر بعض وظائف الحوسبة الموسعة العامة جدًا. من منظور الجهاز الظاهري، ستنتقل المكالمة إلى نظام فرعي منفصل ثم تعيد الإجابة الصحيحة بطريقة سحرية في وقت لاحق.
لقد استكشفنا هذه الفكرة لفترة وجيزة ولكننا سرعان ما تخلينا عنها لأننا كنا نركز بشكل كبير على إثبات أن أي نوع من التوسع في blockchain كان ممكنًا. على الرغم من أنه كما سنرى لاحقًا، فإن الجمع بين عينات توفر البيانات وZK-EVM يعني أن المستقبل المحتمل لتوسيع نطاق Ethereum يبدو في الواقع قريبًا جدًا من هذه الرؤية! من ناحية أخرى، مع تجريد الحساب، عرفنا منذ البداية أن نوعًا ما من التنفيذ كان ممكنًا، لذلك بدأ البحث على الفور في محاولة جعل شيء ما أقرب ما يمكن إلى نقطة البداية النقية المتمثلة في "المعاملة هي مجرد مكالمة".
*يوجد الكثير من التعليمات البرمجية المعيارية بين معالجة المعاملة وإجراء مكالمة EVM الأساسية الفعلية من عنوان المرسل، والمزيد من التعليمات البرمجية المعيارية بعد ذلك. كيف يمكننا تقليل هذا الرمز إلى ما يقرب من الصفر قدر الإمكان؟ *
أحد الرموز الرئيسية هنا هو validate_transaction(state, tx)، وهو المسؤول عن التحقق من صحة رقم المعاملة وتوقيعها. كان الهدف الحقيقي لتجريد الحساب منذ البداية هو السماح للمستخدمين باستبدال التحقق الأساسي غير المتزايد والتحقق من ECDSA بمنطق التحقق الخاص بهم، بحيث يمكن للمستخدمين استخدام ميزات مثل الاسترداد الاجتماعي والمحافظ متعددة التوقيع بسهولة أكبر. لذا فإن العثور على طريقة لإعادة هيكلة application_transaction في استدعاء EVM بسيط ليس مجرد مهمة "جعل التعليمات البرمجية نظيفة من أجل جعل التعليمات البرمجية نظيفة"؛ بل يتعلق بنقل المنطق إلى رمز حساب المستخدم، مما يمنح المستخدمين المرونة التي يمكنهم يحتاج.
ومع ذلك، فإن الإصرار على أن التطبيق_المعاملة يحتوي على أقل قدر ممكن من المنطق الثابت أدى إلى خلق الكثير من التحديات. يمكننا أن ننظر إلى أحد أقدم مقترحات تجريد الحساب، EIP-86.
إذا تم تضمين EIP-86 كما هو، فسيؤدي ذلك إلى تقليل تعقيد EVM على حساب زيادة تعقيد الأجزاء الأخرى من مكدس Ethereum بشكل كبير، مما يتطلب بشكل أساسي كتابة نفس الكود في مكان آخر، بالإضافة إلى تقديم وحدة كاملة. فئة جديدة من الغرابة، على سبيل المثال، قد تظهر نفس المعاملة بنفس قيمة التجزئة عدة مرات في السلسلة، ناهيك عن مشكلة الإبطال المتعدد.
*مشكلات إبطال متعددة في تجريد الحساب. يمكن أن تؤدي معاملة واحدة مضمنة على السلسلة إلى إبطال آلاف المعاملات الأخرى في مجمع الذاكرة، مما يجعل من السهل ملء مجمع الذاكرة بتكلفة زهيدة. *
ومنذ ذلك الحين، تطور تجريد الحساب على مراحل. أصبح EIP-86 فيما بعد EIP-208، وفي النهاية ظهر EIP-2938 العملي.
ومع ذلك، EIP-2938 ليس سوى الحد الأدنى. محتوياته تشمل:
نوع المعاملة الجديد
ثلاثة متغيرات عالمية جديدة لنطاق المعاملات
اثنين من أكواد التشغيل الجديدة، بما في ذلك كود تشغيل PAYgas الخرقاء للغاية للتعامل مع أسعار الغاز وفحوصات حدود الغاز، كنقاط توقف لتنفيذ EVM، وتخزين ETH مؤقتًا للدفع لمرة واحدة
مجموعة معقدة من استراتيجيات التعدين وإعادة الإرسال، بما في ذلك قائمة رموز التشغيل المحظورة أثناء مرحلة التحقق من المعاملة
في محاولة لتحقيق تجريد الحساب دون إشراك مطوري Ethereum الأساسيين (الذين ركزوا على تحسين عملاء Ethereum وتنفيذ عمليات الدمج)، تمت إعادة تصميم EIP-2938 في النهاية ليصبح ERC-4337، والذي كان خارج البروتوكول تمامًا.
نظرًا لأن هذا ERC، فهو لا يتطلب انقسامًا كليًا وهو موجود تقنيًا "خارج بروتوكول Ethereum". إذن...حلت المشكلة؟ اتضح أن الأمر ليس كذلك. تتضمن خارطة الطريق الحالية متوسطة المدى لـ ERC-4337 في النهاية نقل أجزاء كبيرة من ERC-4337 إلى سلسلة من ميزات البروتوكول، وهو مثال مفيد للإرشادات حول سبب ضرورة أخذ هذا المسار في الاعتبار.
الحزمة ERC-4337
هناك عدة أسباب رئيسية تمت مناقشتها لإعادة دمج ERC-4337 في البروتوكول في نهاية المطاف:
كفاءة استخدام الغاز: أي عملية يتم إجراؤها داخل جهاز EVM تؤدي إلى مستوى معين من الحمل الزائد للجهاز الافتراضي، بما في ذلك عدم الكفاءة عند استخدام ميزات باهظة الثمن مثل فتحات التخزين. حاليًا، تصل أوجه القصور الإضافية هذه إلى ما لا يقل عن 20000 غاز أو أكثر. يعد وضع هذه المكونات في البروتوكول هو أسهل طريقة للتخلص من هذه المشكلات.
خطر خطأ الكود: إذا كان "عقد نقطة الدخول" ERC-4337 به خطأ فظيع بما فيه الكفاية، فقد تشهد جميع المحافظ المتوافقة مع ERC-4337 نفاد أموالها. يؤدي استبدال العقود بوظائف داخل البروتوكول إلى إنشاء التزام ضمني بإصلاح أخطاء التعليمات البرمجية من خلال الهارد فورك، وبالتالي إزالة مخاطر نفاد أموال المستخدمين.
يدعم رموز تشغيل EVM، مثل txt.origin. يتسبب ERC-4337 نفسه في قيام txt.origin بإرجاع عنوان "المجمع" الذي يجمع مجموعة من إجراءات المستخدم في معاملة. يحل تجريد الحساب الأصلي هذه المشكلة عن طريق جعل txt.origin يشير إلى الحساب الفعلي الذي يرسل المعاملة، مما يجعله يتصرف مثل EOA.
مقاومة الرقابة: أحد التحديات التي تواجه الفصل بين مقدم العرض والمنشئ هو أنه يصبح من الأسهل مراجعة المعاملات الفردية. في عالم حيث يمكن لبروتوكول إيثريوم تحديد المعاملات الفردية، يمكن تخفيف هذه المشكلة إلى حد كبير من خلال قوائم التضمين، والتي تسمح لمقدمي العروض بتحديد قائمة المعاملات التي يجب تضمينها في الخانتين التاليتين في جميع الحالات تقريبًا. ومع ذلك، فإن ERC-4337 خارج البروتوكول يقوم بتغليف "عمليات المستخدم" في معاملة واحدة، مما يجعل عمليات المستخدم مبهمة لبروتوكول إيثريوم؛ وبالتالي، فإن قائمة التضمين التي يوفرها بروتوكول إيثريوم لن تكون قادرة على توفير مقاومة الرقابة لمستخدم ERC-4337. عمليات. إن التفاف ERC-4337 وجعل إجراء المستخدم هو نوع معاملة "مناسب" من شأنه أن يحل هذه المشكلة.
ومن الجدير بالذكر أن ERC-4337 في شكله الحالي أغلى بكثير من معاملات الإيثيريوم "الأساسية": تبلغ تكلفة المعاملة 21000 غاز، بينما تكلف ERC-4337 حوالي 42000 غاز.
من الناحية النظرية، يجب أن يكون من الممكن ضبط نظام تكلفة غاز EVM حتى تتطابق التكلفة داخل البروتوكول وتكلفة الوصول إلى التخزين خارج البروتوكول؛ ولا يوجد سبب للحاجة إلى إنفاق 9000 غاز لنقل ETH عندما تكون أنواع أخرى من تحرير التخزين العمليات أرخص. في الواقع، تحاول عمليتان EIP مرتبطتان بتحول شجرة Verkle القادم القيام بذلك. ولكن حتى لو فعلنا ذلك، فهناك سبب واضح وراء كون وظائف البروتوكول المغلفة، بغض النظر عن مدى كفاءة EVM، أرخص بكثير من كود EVM: لا يحتاج الكود المغلف إلى دفع تكاليف التحميل المسبق.
تعتبر محفظة ERC-4337 التي تعمل بكامل طاقتها كبيرة الحجم، ويستغرق التنفيذ المترجم والوضع على السلسلة حوالي 12800 بايت. بالطبع، يمكنك نشر هذا الرمز مرة واحدة واستخدام DELEGATECALL للسماح لكل محفظة فردية بالاتصال به، ولكنك ستظل بحاجة إلى الوصول إلى الرمز في كل كتلة يتم استخدامها فيها. بموجب خطة EIP لتكلفة غاز شجرة Verkle، ستشكل 12800 بايت 413 قطعة. سيتطلب الوصول إلى هذه القطع دفع ضعف تكلفة الفرع الشاهد (إجمالي 3800 غاز) و413 ضعف تكلفة القطعة الشاهدة_(إجمالي 82 600 غاز). لم يبدأ هذا حتى في ذكر نقطة دخول ERC-4337 نفسها، والتي تحتوي في الإصدار 0.6.0 على 23689 بايت على السلسلة (حوالي 158700 غاز للتحميل وفقًا لقواعد Verkle Tree EIP).
وهذا يؤدي إلى مشكلة: تكلفة الغاز للوصول فعليًا إلى هذه الرموز يجب أن يتم إطفاءها عبر المعاملات بطريقة ما. النهج الحالي الذي يستخدمه ERC-4337 ليس جيدًا جدًا: تستهلك المعاملة الأولى في الحزمة تكلفة تخزين/قراءة التعليمات البرمجية لمرة واحدة، مما يجعلها أكثر تكلفة بكثير من المعاملات الأخرى. سيسمح التغليف داخل البروتوكول لهذه المكتبات العامة المشتركة بأن تصبح جزءًا من البروتوكول ويمكن للجميع الوصول إليها مجانًا.
ماذا يمكننا أن نتعلم من هذا المثال، ومتى يجب ممارسة التغليف بشكل عام؟
في هذا المثال، نرى بعض الأسباب المنطقية المختلفة لتغليف تجريدات الحساب في البروتوكولات.
** من المرجح أن تفشل الأساليب القائمة على السوق والتي "تدفع التعقيد إلى الحافة" عندما تكون التكاليف الثابتة مرتفعة. **في الواقع، يبدو أن خارطة طريق تجريد الحساب طويلة المدى تتضمن الكثير من التكاليف الثابتة لكل كتلة. 244,100 غاز لتحميل رمز المحفظة الموحد هو شيء واحد؛ لكن التجميع يمكن أن يضيف مئات الآلاف من الغاز للتحقق من ZK-SNARK، بالإضافة إلى تكلفة التحقق من الإثبات على السلسلة. لا توجد طريقة لتحصيل هذه التكاليف من المستخدمين دون إدخال أوجه قصور هائلة في السوق، وتحويل بعض هذه الميزات إلى ميزات بروتوكول يمكن للجميع الوصول إليها مجانًا من شأنه أن يحل هذه المشكلة بشكل جيد للغاية.
**استجابة على مستوى المجتمع لأخطاء التعليمات البرمجية. **إذا تم استخدام جزء من التعليمات البرمجية من قبل جميع المستخدمين أو مجموعة واسعة جدًا من المستخدمين، فغالبًا ما يكون من المنطقي أن يتحمل مجتمع blockchain مسؤولية الانقسام الكلي لإصلاح أي أخطاء قد تنشأ. يقدم ERC-4337 كمية كبيرة من التعليمات البرمجية المشتركة عالميًا، وعلى المدى الطويل، من المعقول بلا شك إصلاح الأخطاء في التعليمات البرمجية من خلال الهارد فورك بدلاً من التسبب في خسارة المستخدمين لكمية كبيرة من الإيثريوم.
**في بعض الأحيان، يمكن تنفيذ شكل أقوى من البروتوكول من خلال الاستفادة بشكل مباشر من وظائفه. **المثال الرئيسي هنا هو ميزات مقاومة الرقابة داخل البروتوكول، مثل قوائم التضمين: يمكن أن تضمن قوائم التضمين داخل البروتوكول مقاومة الرقابة بشكل أفضل من الطرق خارج البروتوكول. لكي تستفيد العمليات على مستوى المستخدم حقًا من داخل البروتوكول تضمين القوائم، يجب أن تكون العمليات الفردية على مستوى المستخدم "مقروءة" للبروتوكول. مثال آخر أقل شهرة هو أن تصميم إثبات حصة الإيثريوم في حقبة 2017 كان يحتوي على تجريد حسابي لمفاتيح الحصة، والذي تم التخلي عنه لصالح BLS المغلف لأن BLS دعم آلية "التجميع" التي كان لا بد من تنفيذها في البروتوكول و مستويات الشبكة، وهذا يمكن أن يجعل معالجة أعداد كبيرة من التوقيعات أكثر كفاءة.
ولكن من المهم أن نتذكر أنه حتى تجريد الحساب ضمن بروتوكول التغليف لا يزال يمثل عملية "إلغاء تغليف" ضخمة مقارنة بالوضع الراهن. اليوم، لا يمكن بدء معاملات الإيثريوم ذات المستوى الأعلى إلا من الحسابات المملوكة خارجيًا (EOA)، والتي يتم التحقق منها باستخدام توقيع منحنى بيضاوي واحد secp 256k 1. يزيل تجريد الحساب هذا الأمر ويترك شروط التحقق للمستخدم ليحددها. لذلك، في هذه القصة حول تجريد الحساب، نرى أيضًا السبب الأكبر ضد التغليف: المرونة لتلبية احتياجات المستخدمين المختلفين.
دعونا نوضح القصة بشكل أكبر من خلال النظر في بعض الأمثلة الأخرى للميزات التي تم أخذها في الاعتبار مؤخرًا للتغليف. على وجه الخصوص، سننظر في: ZK-EVM، والفصل بين مقدم العرض والباني، ومجموعات الذاكرة الخاصة، وحصص السيولة، والتجميع المسبق الجديد.
الحزمة ZK-EVM
دعونا نحول انتباهنا إلى هدف تغليف محتمل آخر لبروتوكول الإيثريوم: ZK-EVM. حاليًا، لدينا عدد كبير من مجموعات ZK التي يتعين عليها جميعًا كتابة تعليمات برمجية متشابهة إلى حد ما للتحقق من تنفيذ كتل Ethereum مماثلة في ZK-SNARKs. هناك نظام بيئي متنوع إلى حد ما من التطبيقات المستقلة: PSE ZK-EVM، Kakarot، Polygon ZK-EVM، Linea، Zeth، وغيرها الكثير.
يتعلق الجدل الأخير في مجال تراكمي EVM ZK بكيفية التعامل مع الأخطاء التي قد تظهر في كود ZK. حاليًا، جميع هذه الأنظمة العاملة لديها شكل من أشكال آلية "مجلس الأمن" الذي يتحكم في نظام التصديق في حالة حدوث خطأ. في العام الماضي، حاولت إنشاء إطار موحد من شأنه أن يشجع المشاريع على توضيح مدى ثقتها في نظام التصديق، ومدى ثقتها في مجلس الأمن، والحد تدريجيا من سلطتها على تلك المنظمة مع مرور الوقت.
*على المدى المتوسط، من المرجح أن يعتمد التجميع على أنظمة شهادات متعددة، مع عدم حصول مجلس الأمن على السلطة إلا في الحالات القصوى حيث يتباعد نظامان مختلفان لإصدار الشهادات. *
ومع ذلك، هناك شعور بأن بعض هذه الأعمال تبدو زائدة عن الحاجة. لدينا بالفعل طبقة أساسية من Ethereum، ولديها EVM، ولدينا بالفعل آلية عمل للتعامل مع الأخطاء في التنفيذ: إذا كان هناك خطأ، فسيتم تحديث العميل لإصلاحه، وستستمر السلسلة في العمل . من وجهة نظر العميل الذي يعاني من الأخطاء، يبدو أن عمليات الحظر التي تم الانتهاء منها لن يتم تأكيدها بعد الآن، ولكن على الأقل لن نرى المستخدمين يخسرون الأموال. وبالمثل، إذا كانت المجموعات المجمعة ترغب فقط في الحفاظ على الدور المعادل لـ EVM، فإنها تحتاج إلى تنفيذ إدارتها الخاصة لتغيير قواعد ZK-EVM الداخلية الخاصة بها باستمرار لمطابقة الترقيات مع الطبقة الأساسية لـ Ethereum، وهو ما يبدو خاطئًا لأنها في النهاية مبنية على القمة من الطبقة الأساسية للإيثريوم نفسها، فهي تعرف متى يجب الترقية ووفقًا للقواعد الجديدة.
نظرًا لأن L2 ZK-EVMs تستخدم أساسًا نفس EVM تمامًا مثل Ethereum، فهل يمكننا بطريقة أو بأخرى دمج "التحقق من تنفيذ EVM في ZK" في وظيفة البروتوكول والتعامل مع الاستثناءات من خلال تطبيق الإجماع الاجتماعي لـ Ethereum، مثل الأخطاء والترقيات، كما نفعل بالفعل من أجل تنفيذ الطبقة الأساسية EVM نفسها؟
هذا موضوع مهم وصعب.
أحد المواضيع المحتملة للنقاش فيما يتعلق بتوفر البيانات في ZK-EVM الأصلي هو الحالة. ستكون أجهزة ZK-EVM أكثر كفاءة في التعامل مع البيانات إذا لم تكن بحاجة إلى حمل بيانات "الشاهد". وهذا يعني أنه إذا تمت قراءة جزء معين من البيانات أو كتابته بالفعل في بعض الكتل السابقة، فيمكننا ببساطة أن نفترض أن المُثبِّت لديه حق الوصول إليها ولا يتعين عليه إتاحتها مرة أخرى. لا يقتصر الأمر على عدم إعادة تحميل وحدة التخزين والتعليمات البرمجية فحسب، بل اتضح أنه إذا ضغطت مجموعة البيانات المجمعة بشكل صحيح، فإن الضغط ذو الحالة يمكن أن يوفر ما يصل إلى 3 أضعاف البيانات مقارنة بالضغط عديم الحالة.
هذا يعني أنه بالنسبة للتجميع المسبق لـ ZK-EVM، لدينا خياران:
**1.**يتطلب التجميع المسبق أن تكون جميع البيانات متاحة في نفس الكتلة. هذا يعني أن المُثبِّت يمكن أن يكون عديم الحالة، ولكنه يعني أيضًا أن استخدام مجموعة ZK المترجمة مسبقًا هذه أكثر تكلفة بكثير من استخدام مجموعة التعليمات البرمجية المخصصة.
**2.**يسمح التجميع المسبق للمؤشرات بالإشارة إلى البيانات المستخدمة أو الناتجة عن عمليات التنفيذ السابقة. وهذا يجعل ZK-rollup قريبًا من المستوى الأمثل، ولكنه أكثر تعقيدًا ويقدم حالة جديدة يجب تخزينها بواسطة المُثبِّت.
ماذا يمكننا أن نتعلم من هذا؟ هناك سبب وجيه لتغليف التحقق من ZK-EVM بطريقة ما: تقوم مجموعة التحديثات بالفعل ببناء نسختها المخصصة الخاصة، وEthereum على استعداد لتنفيذ EVM على L1 مع وزن تطبيقاتها المتعددة والإجماع الاجتماعي خارج السلسلة. خطأ، ولكن قيام L2 بنفس المهمة بالضبط سيتعين عليه تنفيذ أداة معقدة تشمل مجلس الأمن. ولكن من ناحية أخرى، هناك مشكلة كبيرة في التفاصيل: هناك إصدارات مختلفة من ZK-EVM، ولها تكاليف وفوائد مختلفة. إن التمييز بين ذو الحالة وعديم الحالة لا يؤدي إلا إلى خدش السطح؛ وقد تؤدي محاولات دعم التعليمات البرمجية المخصصة "تقريبًا EVM" والتي تم إثباتها بواسطة أنظمة أخرى إلى الكشف عن مساحة تصميم أكبر. لذلك، تجلب تعبئة ZK-EVM الأمل والتحديات معًا.
فصل مقترح التغليف والباني (ePBS)
إن ظهور MEV يجعل إنتاج الكتل نشاطًا اقتصاديًا على نطاق واسع، مع وجود جهات فاعلة متطورة قادرة على إنتاج كتل تولد إيرادات أكثر من الخوارزمية الافتراضية، التي تراقب ببساطة مجموعة من المعاملات وتحتويها. حتى الآن، حاول مجتمع إيثريوم حل هذه المشكلة عن طريق استخدام مخططات فصل بين مقدم العرض والباني خارج البروتوكول مثل MEV-Boost، والتي تسمح للمدققين العاديين ("المقترحون") بدفع الكتل إلى جهات فاعلة متخصصة ("البناة"). ").
ومع ذلك، فإن MEV-Boost تضع افتراضات الثقة في فئة جديدة من الجهات الفاعلة تسمى المرحلات. في العامين الماضيين، كانت هناك العديد من المقترحات لإنشاء "برنامج تلفزيوني معبأ". ما هي فوائد القيام بذلك؟ في هذه الحالة، الإجابة بسيطة للغاية: إن برنامج تلفزيوني مبني باستخدام ميزات البروتوكول مباشرة يكون أكثر قوة (بمعنى وجود افتراضات ثقة أضعف) من برنامج تلفزيوني مبني دون استخدامها. وهذا مشابه لحالة تغليف أوراكل الأسعار ضمن البروتوكول - على الرغم من وجود اعتراضات قوية في هذه الحالة.
تغليف تجمع الذاكرة الخاصة
عندما يرسل المستخدم معاملة، تصبح عامة ومرئية للجميع على الفور، حتى قبل تضمينها في السلسلة. وهذا يترك مستخدمي العديد من التطبيقات عرضة للهجمات الاقتصادية، مثل الهجمات الأمامية.
في الآونة الأخيرة، كان هناك عدد من المشاريع المخصصة لإنشاء "مجموعات الذاكرة الخاصة" (أو "مجموعات الذاكرة المشفرة")، والتي تعمل على تشفير معاملات المستخدمين حتى يتم قبولها بشكل لا رجعة فيه في الكتلة.
ومع ذلك، تكمن المشكلة في أن مثل هذا المخطط يتطلب نوعًا خاصًا من التشفير: لمنع المستخدمين من إغراق النظام وفك تشفيره أولاً، يجب فك تشفير التشفير تلقائيًا بعد قبول المعاملة بشكل لا رجعة فيه.
هناك تقنيات مختلفة مع مقايضات مختلفة من أجل تنفيذ هذا النوع من التشفير. وقد وصفها جون شاربونو ذات مرة بشكل جيد:
التشفير للمشغلين المركزيين مثل Flashbots Protect**. **
تشفير قفل الوقت، يمكن لأي شخص فك تشفير نموذج التشفير هذا بعد خطوات حسابية تسلسلية معينة، ولا يمكن موازنته؛
تشفير العتبة، ثق بلجنة أغلبية نزيهة لفك تشفير البيانات. راجع مفهوم سلاسل المنارات المغلقة للحصول على اقتراحات محددة.
أجهزة موثوقة، مثل SGX.
لسوء الحظ، كل طريقة تشفير لها نقاط ضعف مختلفة. بينما يوجد لكل حل شريحة من المستخدمين يرغبون في الثقة به، إلا أنه لا يوجد حل موثوق به بدرجة كافية ليتم قبوله فعليًا من قبل الطبقة الأولى. **لذا، على الأقل حتى يتم إتقان التشفير المؤجل أو بعض التقدم التكنولوجي الآخر، يبدو أن تغليف وظيفة مكافحة التداول المسبق في الطبقة الأولى يمثل اقتراحًا صعبًا، حتى لو كانت ميزة ذات قيمة كافية تحلها العديد من التطبيقات. ظهرت الخطة.
تغليف عماد السيولة
هناك حاجة شائعة بين مستخدمي Ethereum DeFi وهي القدرة على استخدام ETH الخاص بهم في نفس الوقت للتخزين وكضمان في التطبيقات الأخرى. طلب شائع آخر هو ببساطة من أجل الراحة: يريد المستخدمون أن يكونوا قادرين على المشاركة (وحماية مفاتيح التخزين عبر الإنترنت) دون تعقيد تشغيل العقدة وإبقائها متصلة بالإنترنت دائمًا.
إن أبسط "واجهة" للتخزين تلبي كلا هاتين الحاجتين هي مجرد رمز ERC 20: قم بتحويل ETH الخاص بك إلى "التخزين ETH"، ثم احتفظ به، ثم قم بتحويله مرة أخرى. في الواقع، يقوم مقدمو خدمات الرهن العقاري مثل Lido وRocket Pool بذلك بالفعل. ومع ذلك، هناك بعض آليات المركزية الطبيعية التي تلعب دورًا في المراهنة على السيولة: سينتقل الأشخاص بشكل طبيعي إلى المراهنة على أكبر نسخة من ETH لأنها الأكثر شيوعًا وسيولة.
يحتاج كل إصدار من ETH إلى بعض الآليات لتحديد من يمكنه أن يصبح مشغل العقدة الأساسي. لا يمكن أن يكون غير محدود لأن المهاجمين سينضمون ويستخدمون أموال المستخدم لتوسيع هجماتهم. حاليًا، أعلى اثنين هما Lido وRocket Pool، حيث يحتوي الأول على مشغلي العقد DAO المدرجين في القائمة البيضاء والأخير يسمح لأي شخص بتشغيل عقدة بإيداع 8 ETH. الطريقتان لهما مخاطر مختلفة: تسمح طريقة Rocket Pool للمهاجم بتنفيذ هجوم بنسبة 51% على الشبكة وتجبر المستخدمين على دفع معظم التكاليف؛ أما بالنسبة لطريقة DAO، إذا سيطر رمز مميز معين، فسوف يؤدي ذلك إلى تتحكم أداة حوكمة واحدة من المحتمل أن تكون معرضة للخطر في جزء كبير من جميع أدوات التحقق من صحة Ethereum. ويُحسَب أن بروتوكولات مثل ليدو نفذت ضمانات، ولكن طبقة واحدة من الدفاع قد لا تكون كافية.
على المدى القصير، يتمثل أحد الخيارات في تشجيع المشاركين في النظام البيئي على استخدام مجموعة متنوعة من مقدمي حصص السيولة لتقليل احتمالية قيام اللاعب المهيمن بفرض مخاطر نظامية. ولكن على المدى الطويل، يشكل هذا التوازن غير مستقر، كما أن الاعتماد المفرط على الضغوط الأخلاقية لحل المشاكل أمر بالغ الخطورة. يطرح سؤال طبيعي: ** هل من المنطقي تضمين بعض الوظائف في البروتوكول لجعل عملية الرهان على السيولة أقل مركزية؟ **
السؤال الرئيسي هنا هو: ما نوع الوظيفة داخل البروتوكول؟ تتمثل إحدى مشكلات إنشاء رمز مميز "Saging ETH" قابل للاستبدال ضمن البروتوكول في أنه يجب إما أن يكون لديه حوكمة مغلفة على مستوى Ethereum لاختيار من يمكنه تشغيل العقد، أو أن يكون مفتوحًا، ولكن هذا من شأنه أن يحوله إلى عملة للمهاجم. أدوات.
فكرة مثيرة للاهتمام هي مقالة Dankrad Feist حول تعظيم حصص السيولة. أولاً، دعونا نتعرف على الأمر، إذا تعرض إيثريوم لهجوم بنسبة 51%، فقد يتم قطع 5% فقط من عملة إيثريوم التي تمت مهاجمتها. هذه مقايضة معقولة؛ مع وجود أكثر من 26 مليون ETH حاليًا، فإن تكلفة مهاجمة ثلث ذلك (حوالي 8 مليون ETH) باهظة، لا سيما بالنظر إلى عدد الهجمات "الخارجة عن النموذج" التي يمكن القيام بها في مكان ما. أقل تكلفة. في الواقع، تم استكشاف مقايضات مماثلة في اقتراح اللجنة العليا لتنفيذ نهائية الفتحة الواحدة.
إذا قبلنا أن 5% فقط من هجوم ETH قد تم قطعه، فإن أكثر من 90% من ETH المتراكمة لن تتأثر بالقطع، لذلك يمكن استخدامها كرموز تخزين سائلة قابلة للاستبدال ضمن البروتوكول ثم استخدامها بواسطة تطبيقات أخرى.
هذا المسار مثير للاهتمام. ولكن لا يزال يترك سؤالا: ما هو بالضبط مغلفة؟ **يعمل Rocket Pool بشكل مشابه جدًا: يوفر كل مشغل عقدة بعض الأموال، ويوفر أصحاب السيولة الباقي. يمكننا ببساطة تعديل بعض الثوابت للحد الأقصى لعقوبة القطع إلى 2 إيثريوم، وسوف تصبح قيمة الـ RETH الحالية في Rocket Pool خالية من المخاطر.
ومن خلال تعديلات بسيطة على البروتوكول، يمكننا أيضًا القيام بأشياء ذكية أخرى. على سبيل المثال، لنفترض أننا نريد نظامًا يحتوي على "مستويين" من التوقيع المساحي: مشغلو العقد (متطلبات ضمانات عالية) والمودعين (لا يوجد حد أدنى لمتطلبات الضمانات، ويمكنهم الانضمام والمغادرة في أي وقت)، لكننا ما زلنا نريد منح عينات عشوائية صلاحيات لجنة الإيداع لمنع مركزية مشغلي العقد، مثل التوصية بقائمة المعاملات التي يجب تضمينها (لأسباب مقاومة الرقابة)، أو التحكم في اختيار الشوكة أثناء تسرب عدم النشاط، أو طلب التوقيعات على الكتل. يمكن تحقيق ذلك بطريقة تخرج بشكل أساسي عن البروتوكول عن طريق تعديل البروتوكول ليطلب من كل مدقق توفير (1) مفتاح تخزين عادي، و (2) يتم استدعاء عنوان ETH الذي يمكن استخدامه في كل فتحة لإخراج مفتاح التعهد الثانوي. سيقوم البروتوكول بتمكين كلا المفتاحين، ولكن يمكن ترك آلية اختيار المفتاح الثاني في كل فتحة لبروتوكول تجمع التوقيع المساحي. قد يكون من الأفضل تغليف بعض الوظائف بشكل مباشر، ولكن تجدر الإشارة إلى أن مساحة التصميم هذه التي تتمثل في "تضمين بعض الأشياء وترك أشياء أخرى للمستخدم" موجودة.
تغليف المزيد من التجميع المسبق
العقود المجمعة مسبقًا (أو "العقود المجمعة") هي عقود إيثريوم تنفذ عمليات تشفير معقدة، مع تنفيذ المنطق محليًا في كود العميل بدلاً من كود العقد الذكي EVM. التشفير المسبق هو حل وسط تم تبنيه منذ بداية تطوير الإيثيريوم: نظرًا لأن الحمل الزائد للجهاز الظاهري كبير جدًا بالنسبة لبعض التعليمات البرمجية المعقدة للغاية والمتخصصة للغاية، فيمكننا تنفيذ بعض التطبيقات المهمة في التعليمات البرمجية الأصلية، وتقييم العمليات المهمة لجعلها أسرع. اليوم، يتضمن هذا بشكل أساسي بعض وظائف التجزئة المحددة وعمليات المنحنى الإهليلجي.
يوجد حاليًا دفعة لإضافة تجميع مسبق لـ secp 256 r 1، وهو منحنى إهليلجي مختلف قليلاً عن secp 256 k 1 المستخدم لحسابات الإيثريوم الأساسية، والذي يستخدم على نطاق واسع لأنه مدعوم جيدًا من خلال وحدات الأجهزة الموثوقة، استخدمه لزيادة أمان المحفظة. في السنوات الأخيرة، دفع المجتمع أيضًا لإضافة التجميع المسبق لـ BLS-12-377 وBW 6-761 والاقتران المعمم وميزات أخرى.
الحجة المضادة لهذه الدعوات لمزيد من المترجمات المسبقة هي أن العديد من المترجمات المسبقة التي تمت إضافتها سابقًا (مثل RIPEMD و BLAKE) انتهى بها الأمر إلى استخدام أقل بكثير مما كان متوقعًا، وعلينا أن نتعلم من هذا. بدلاً من إضافة المزيد من التجميع المسبق لعمليات محددة، ربما ينبغي لنا أن نركز على نهج أكثر ليونة يعتمد على أفكار مثل EVM-MAX ومقترح Hibernate-But-Always-Resumable SIMD، والذي من شأنه تمكين تطبيقات EVM من العمل بتكلفة أقل. مجموعة واسعة من فئات التعليمات البرمجية. ربما يمكن إزالة الترجمة المسبقة الحالية قليلة الاستخدام واستبدالها بتطبيق كود EVM (الأقل كفاءة حتمًا) لنفس الوظائف. ومع ذلك، لا يزال من الممكن أن تكون هناك عمليات تشفير محددة ذات قيمة كافية لتسريعها، لذا فمن المنطقي إضافتها على أنها مترجمة مسبقًا.
ماذا تعلمنا من كل هذا؟
إن الرغبة في تغليف أقل قدر ممكن أمر مفهوم وجيد؛ فهو ينبع من التقليد الفلسفي لنظام يونكس المتمثل في إنشاء برامج بسيطة يمكنها التكيف بسهولة مع الاحتياجات المختلفة للمستخدمين وتجنب لعنة تضخم البرامج. ومع ذلك، فإن blockchain ليس نظام تشغيل حاسوبي شخصي، ولكنه نظام اجتماعي. وهذا يعني أنه من المنطقي تغليف وظائف معينة في البروتوكول.
وفي كثير من الحالات، تكون هذه الأمثلة الأخرى مشابهة لما رأيناه في تجريد الحساب. لكننا تعلمنا أيضًا بعض الدروس الجديدة:
يمكن أن تساعد الوظائف المغلفة في تجنب مخاطر المركزية في مناطق أخرى من المكدس:
في كثير من الأحيان، يؤدي الحفاظ على الحد الأدنى من البروتوكول الأساسي وبساطته إلى دفع التعقيد إلى بعض الأنظمة البيئية خارج البروتوكول. من وجهة نظر فلسفة يونكس، هذا أمر جيد. ومع ذلك، هناك في بعض الأحيان خطر أن يصبح النظام البيئي خارج البروتوكول مركزيًا، عادةً (ولكن ليس فقط) بسبب التكاليف الثابتة المرتفعة. يمكن أن يؤدي التغليف في بعض الأحيان إلى تقليل المركزية الفعلية.
قد يؤدي تضمين قدر كبير جدًا من المحتوى إلى زيادة عبء الثقة والحوكمة في البروتوكول:
هذا هو موضوع مقال سابق حول "لا تفرط في إجماع الإيثريوم": إذا كان تغليف ميزة معينة يضعف نموذج الثقة ويجعل الإيثريوم ككل أكثر "ذاتية"، فإن هذا يضعف الإيثريوم. الحياد الموثوق. في هذه الحالات، من الأفضل أن يكون لديك وظيفة محددة كآلية أعلى الإيثريوم بدلاً من محاولة جلبها إلى الإيثريوم نفسه. تعد مجموعات الذاكرة المشفرة أفضل مثال هنا، والتي قد يكون من الصعب بعض الشيء تغليفها، على الأقل حتى يتحسن تشفير زمن الوصول.
تغليف الكثير من المحتوى قد يجعل البروتوكول معقدًا للغاية:
يعد تعقيد البروتوكول بمثابة خطر نظامي يزداد عن طريق إضافة العديد من الميزات إلى البروتوكول. التجميع المسبق هو أفضل مثال.
على المدى الطويل، قد تؤدي وظيفة التغليف إلى نتائج عكسية لأن احتياجات المستخدم لا يمكن التنبؤ بها:
الميزة التي يعتقد الكثير من الناس أنها مهمة والتي سيستخدمها العديد من المستخدمين ربما لا يتم استخدامها كثيرًا في الممارسة العملية.
بالإضافة إلى ذلك، تُظهر حصص السيولة وZK-EVM والأمثلة المترجمة مسبقًا إمكانية وجود مسار وسط: الحد الأدنى من التكريس القابل للتطبيق. لا يحتاج البروتوكول إلى تغليف الوظيفة بأكملها، ولكن يمكن أن يحتوي على أجزاء محددة تعالج التحديات الرئيسية، مما يجعل الوظيفة سهلة التنفيذ دون أن تكون مذعورًا أو ضيقًا للغاية. الامثله تشمل:
بدلاً من تغليف نظام كامل لرهانات السيولة، من الأفضل تغيير قواعد عقوبات الستاكينغ لجعل رهانات السيولة غير الموثوقة أكثر جدوى؛
بدلاً من تغليف المزيد من المترجمات المسبقة، من الأفضل تغليف EVM-MAX و/أو SIMD لتسهيل تنفيذ فئة أوسع من العمليات بكفاءة؛
يمكن ببساطة تغليف التحقق من EVM بدلاً من تغليف مفهوم التجميع بالكامل.
يمكننا توسيع المخطط السابق على النحو التالي:
في بعض الأحيان يكون من المنطقي تغليف شيء ما، ومن الأمثلة على ذلك إزالة المترجمات المسبقة التي نادرًا ما تستخدم. يعد تجريد الحساب ككل، كما ذكرنا سابقًا، أيضًا شكلاً مهمًا من أشكال إلغاء التغليف. إذا أردنا دعم التوافق العكسي للمستخدمين الحاليين، فقد تكون الآلية في الواقع مشابهة بشكل مدهش لتلك التي قامت بإلغاء تغليف التجميع المسبق: أحد المقترحات هو EIP-5003، والذي من شأنه أن يسمح لـ EOAs بتحويل حساباتهم للحصول على نفس الحسابات (أو أفضل) العقد الوظيفي.
إن تحديد الميزات التي يجب إدراجها في البروتوكول وأيها يجب تركها لطبقات أخرى من النظام البيئي هي مقايضة معقدة. ومن المتوقع أن تستمر هذه المقايضة في التحسن بمرور الوقت مع استمرار تحسن فهمنا لاحتياجات المستخدم ومجموعة الأفكار والتقنيات المتاحة.
شاهد النسخة الأصلية
قد تحتوي هذه الصفحة على محتوى من جهات خارجية، يتم تقديمه لأغراض إعلامية فقط (وليس كإقرارات/ضمانات)، ولا ينبغي اعتباره موافقة على آرائه من قبل Gate، ولا بمثابة نصيحة مالية أو مهنية. انظر إلى إخلاء المسؤولية للحصول على التفاصيل.
أحدث مقالة طويلة لبوتيرين: هل يجب أن يتضمن بروتوكول الإيثريوم المزيد من الوظائف؟
المؤلف: فيتاليك بوتيرين المترجم: أوديلي بلانيت ديلي نيان ينسيتانغ
*شكر خاص لجوستين دريك وتينا تشن ويواف فايس على تعليقاتهم ومراجعتهم. *
منذ بداية مشروع إيثريوم، كانت هناك فلسفة قوية تتمثل في محاولة جعل جوهر إيثريوم بسيطًا قدر الإمكان، وتحقيق ذلك قدر الإمكان من خلال بناء بروتوكولات فوقه. في مجال blockchain، غالبًا ما يُنظر إلى النقاش حول "البناء على L1" مقابل "التركيز على L2" على أنه يدور في المقام الأول حول التوسع، ولكن في الواقع، هناك مشكلات مماثلة في تلبية احتياجات العديد من مستخدمي Ethereum: تبادل الأصول الرقمية، والخصوصية. وأسماء المستخدمين والتشفير المتقدم وأمن الحساب ومقاومة الرقابة والحماية الأمامية والمزيد. ومع ذلك، كانت هناك بعض المحاولات الحذرة الأخيرة لتضمين المزيد من هذه الميزات في بروتوكول إيثريوم الأساسي.
سوف تتعمق هذه المقالة في بعض الأسباب الفلسفية وراء الفلسفة الأصلية للتغليف الأدنى، بالإضافة إلى بعض طرق التفكير الحديثة حول هذه الأفكار. سيكون الهدف هو البدء في بناء إطار عمل لتحديد الأهداف المحتملة بشكل أفضل حيث قد يكون من المفيد النظر في تغليف وظائف معينة.
فلسفة مبكرة حول بساطة البروتوكول
في التاريخ المبكر لما كان يُعرف آنذاك باسم "Ethereum 2.0"، كانت هناك رغبة قوية في إنشاء بروتوكول نظيف وبسيط وجميل حاول بأقل قدر ممكن البناء على نفسه وترك كل هذه الأعمال تقريبًا للمستخدمين. من الناحية المثالية، يكون البروتوكول مجرد جهاز افتراضي، والتحقق من صحة الكتلة هو مجرد استدعاء جهاز افتراضي.
أحدث مقال طويل لـ V God: هل يجب أن يتضمن بروتوكول Ethereum المزيد من الوظائف؟
هذه إعادة بناء تقريبية لمخطط السبورة البيضاء الذي رسمته أنا وجافين وود في أوائل عام 2015 عندما كنت أتحدث عن الشكل الذي سيبدو عليه Ethereum 2.0.
ستكون "وظيفة نقل الحالة" (الوظيفة التي تتعامل مع الكتلة) مجرد مكالمة واحدة لـ VM، وكل المنطق الآخر سيحدث من خلال العقود: بعض العقود على مستوى النظام، ولكن في الغالب العقود المقدمة من المستخدم. الميزة الرائعة جدًا لهذا النموذج هي أنه حتى الهارد فورك بأكمله يمكن وصفه بأنه معاملة واحدة لعقد معالج الكتلة، والذي ستتم الموافقة عليه من خلال الحوكمة خارج السلسلة أو على السلسلة ثم ترقية إذن التشغيل.
تنطبق هذه المناقشات في عام 2015 على وجه التحديد على مجالين نأخذهما في الاعتبار: تجريد الحساب وتوسيع نطاقه. في حالة القياس، تتمثل الفكرة في محاولة إنشاء الحد الأقصى من أشكال القياس المجردة التي تبدو وكأنها امتداد طبيعي للرسم البياني أعلاه. يمكن للعقود استدعاء البيانات التي لا يتم تخزينها بواسطة معظم عقد الإيثيريوم، وسيقوم البروتوكول باكتشاف ذلك وحل المكالمة عبر بعض وظائف الحوسبة الموسعة العامة جدًا. من منظور الجهاز الظاهري، ستنتقل المكالمة إلى نظام فرعي منفصل ثم تعيد الإجابة الصحيحة بطريقة سحرية في وقت لاحق.
لقد استكشفنا هذه الفكرة لفترة وجيزة ولكننا سرعان ما تخلينا عنها لأننا كنا نركز بشكل كبير على إثبات أن أي نوع من التوسع في blockchain كان ممكنًا. على الرغم من أنه كما سنرى لاحقًا، فإن الجمع بين عينات توفر البيانات وZK-EVM يعني أن المستقبل المحتمل لتوسيع نطاق Ethereum يبدو في الواقع قريبًا جدًا من هذه الرؤية! من ناحية أخرى، مع تجريد الحساب، عرفنا منذ البداية أن نوعًا ما من التنفيذ كان ممكنًا، لذلك بدأ البحث على الفور في محاولة جعل شيء ما أقرب ما يمكن إلى نقطة البداية النقية المتمثلة في "المعاملة هي مجرد مكالمة".
أحدث مقال طويل لـ V God: هل يجب أن يتضمن بروتوكول Ethereum المزيد من الوظائف؟
*يوجد الكثير من التعليمات البرمجية المعيارية بين معالجة المعاملة وإجراء مكالمة EVM الأساسية الفعلية من عنوان المرسل، والمزيد من التعليمات البرمجية المعيارية بعد ذلك. كيف يمكننا تقليل هذا الرمز إلى ما يقرب من الصفر قدر الإمكان؟ *
أحد الرموز الرئيسية هنا هو validate_transaction(state, tx)، وهو المسؤول عن التحقق من صحة رقم المعاملة وتوقيعها. كان الهدف الحقيقي لتجريد الحساب منذ البداية هو السماح للمستخدمين باستبدال التحقق الأساسي غير المتزايد والتحقق من ECDSA بمنطق التحقق الخاص بهم، بحيث يمكن للمستخدمين استخدام ميزات مثل الاسترداد الاجتماعي والمحافظ متعددة التوقيع بسهولة أكبر. لذا فإن العثور على طريقة لإعادة هيكلة application_transaction في استدعاء EVM بسيط ليس مجرد مهمة "جعل التعليمات البرمجية نظيفة من أجل جعل التعليمات البرمجية نظيفة"؛ بل يتعلق بنقل المنطق إلى رمز حساب المستخدم، مما يمنح المستخدمين المرونة التي يمكنهم يحتاج.
ومع ذلك، فإن الإصرار على أن التطبيق_المعاملة يحتوي على أقل قدر ممكن من المنطق الثابت أدى إلى خلق الكثير من التحديات. يمكننا أن ننظر إلى أحد أقدم مقترحات تجريد الحساب، EIP-86.
إذا تم تضمين EIP-86 كما هو، فسيؤدي ذلك إلى تقليل تعقيد EVM على حساب زيادة تعقيد الأجزاء الأخرى من مكدس Ethereum بشكل كبير، مما يتطلب بشكل أساسي كتابة نفس الكود في مكان آخر، بالإضافة إلى تقديم وحدة كاملة. فئة جديدة من الغرابة، على سبيل المثال، قد تظهر نفس المعاملة بنفس قيمة التجزئة عدة مرات في السلسلة، ناهيك عن مشكلة الإبطال المتعدد.
أحدث مقال طويل لـ V God: هل يجب أن يتضمن بروتوكول Ethereum المزيد من الوظائف؟
*مشكلات إبطال متعددة في تجريد الحساب. يمكن أن تؤدي معاملة واحدة مضمنة على السلسلة إلى إبطال آلاف المعاملات الأخرى في مجمع الذاكرة، مما يجعل من السهل ملء مجمع الذاكرة بتكلفة زهيدة. *
ومنذ ذلك الحين، تطور تجريد الحساب على مراحل. أصبح EIP-86 فيما بعد EIP-208، وفي النهاية ظهر EIP-2938 العملي.
ومع ذلك، EIP-2938 ليس سوى الحد الأدنى. محتوياته تشمل:
في محاولة لتحقيق تجريد الحساب دون إشراك مطوري Ethereum الأساسيين (الذين ركزوا على تحسين عملاء Ethereum وتنفيذ عمليات الدمج)، تمت إعادة تصميم EIP-2938 في النهاية ليصبح ERC-4337، والذي كان خارج البروتوكول تمامًا.
أحدث مقال طويل لـ V God: هل يجب أن يتضمن بروتوكول Ethereum المزيد من الوظائف؟
إرك-4337. إنها تعتمد كليًا على مكالمات EVM!
نظرًا لأن هذا ERC، فهو لا يتطلب انقسامًا كليًا وهو موجود تقنيًا "خارج بروتوكول Ethereum". إذن...حلت المشكلة؟ اتضح أن الأمر ليس كذلك. تتضمن خارطة الطريق الحالية متوسطة المدى لـ ERC-4337 في النهاية نقل أجزاء كبيرة من ERC-4337 إلى سلسلة من ميزات البروتوكول، وهو مثال مفيد للإرشادات حول سبب ضرورة أخذ هذا المسار في الاعتبار.
الحزمة ERC-4337
هناك عدة أسباب رئيسية تمت مناقشتها لإعادة دمج ERC-4337 في البروتوكول في نهاية المطاف:
ومن الجدير بالذكر أن ERC-4337 في شكله الحالي أغلى بكثير من معاملات الإيثيريوم "الأساسية": تبلغ تكلفة المعاملة 21000 غاز، بينما تكلف ERC-4337 حوالي 42000 غاز.
من الناحية النظرية، يجب أن يكون من الممكن ضبط نظام تكلفة غاز EVM حتى تتطابق التكلفة داخل البروتوكول وتكلفة الوصول إلى التخزين خارج البروتوكول؛ ولا يوجد سبب للحاجة إلى إنفاق 9000 غاز لنقل ETH عندما تكون أنواع أخرى من تحرير التخزين العمليات أرخص. في الواقع، تحاول عمليتان EIP مرتبطتان بتحول شجرة Verkle القادم القيام بذلك. ولكن حتى لو فعلنا ذلك، فهناك سبب واضح وراء كون وظائف البروتوكول المغلفة، بغض النظر عن مدى كفاءة EVM، أرخص بكثير من كود EVM: لا يحتاج الكود المغلف إلى دفع تكاليف التحميل المسبق.
تعتبر محفظة ERC-4337 التي تعمل بكامل طاقتها كبيرة الحجم، ويستغرق التنفيذ المترجم والوضع على السلسلة حوالي 12800 بايت. بالطبع، يمكنك نشر هذا الرمز مرة واحدة واستخدام DELEGATECALL للسماح لكل محفظة فردية بالاتصال به، ولكنك ستظل بحاجة إلى الوصول إلى الرمز في كل كتلة يتم استخدامها فيها. بموجب خطة EIP لتكلفة غاز شجرة Verkle، ستشكل 12800 بايت 413 قطعة. سيتطلب الوصول إلى هذه القطع دفع ضعف تكلفة الفرع الشاهد (إجمالي 3800 غاز) و413 ضعف تكلفة القطعة الشاهدة_(إجمالي 82 600 غاز). لم يبدأ هذا حتى في ذكر نقطة دخول ERC-4337 نفسها، والتي تحتوي في الإصدار 0.6.0 على 23689 بايت على السلسلة (حوالي 158700 غاز للتحميل وفقًا لقواعد Verkle Tree EIP).
وهذا يؤدي إلى مشكلة: تكلفة الغاز للوصول فعليًا إلى هذه الرموز يجب أن يتم إطفاءها عبر المعاملات بطريقة ما. النهج الحالي الذي يستخدمه ERC-4337 ليس جيدًا جدًا: تستهلك المعاملة الأولى في الحزمة تكلفة تخزين/قراءة التعليمات البرمجية لمرة واحدة، مما يجعلها أكثر تكلفة بكثير من المعاملات الأخرى. سيسمح التغليف داخل البروتوكول لهذه المكتبات العامة المشتركة بأن تصبح جزءًا من البروتوكول ويمكن للجميع الوصول إليها مجانًا.
ماذا يمكننا أن نتعلم من هذا المثال، ومتى يجب ممارسة التغليف بشكل عام؟
في هذا المثال، نرى بعض الأسباب المنطقية المختلفة لتغليف تجريدات الحساب في البروتوكولات.
ولكن من المهم أن نتذكر أنه حتى تجريد الحساب ضمن بروتوكول التغليف لا يزال يمثل عملية "إلغاء تغليف" ضخمة مقارنة بالوضع الراهن. اليوم، لا يمكن بدء معاملات الإيثريوم ذات المستوى الأعلى إلا من الحسابات المملوكة خارجيًا (EOA)، والتي يتم التحقق منها باستخدام توقيع منحنى بيضاوي واحد secp 256k 1. يزيل تجريد الحساب هذا الأمر ويترك شروط التحقق للمستخدم ليحددها. لذلك، في هذه القصة حول تجريد الحساب، نرى أيضًا السبب الأكبر ضد التغليف: المرونة لتلبية احتياجات المستخدمين المختلفين.
أحدث مقال طويل لـ V God: هل يجب أن يتضمن بروتوكول Ethereum المزيد من الوظائف؟
دعونا نوضح القصة بشكل أكبر من خلال النظر في بعض الأمثلة الأخرى للميزات التي تم أخذها في الاعتبار مؤخرًا للتغليف. على وجه الخصوص، سننظر في: ZK-EVM، والفصل بين مقدم العرض والباني، ومجموعات الذاكرة الخاصة، وحصص السيولة، والتجميع المسبق الجديد.
الحزمة ZK-EVM
دعونا نحول انتباهنا إلى هدف تغليف محتمل آخر لبروتوكول الإيثريوم: ZK-EVM. حاليًا، لدينا عدد كبير من مجموعات ZK التي يتعين عليها جميعًا كتابة تعليمات برمجية متشابهة إلى حد ما للتحقق من تنفيذ كتل Ethereum مماثلة في ZK-SNARKs. هناك نظام بيئي متنوع إلى حد ما من التطبيقات المستقلة: PSE ZK-EVM، Kakarot، Polygon ZK-EVM، Linea، Zeth، وغيرها الكثير.
يتعلق الجدل الأخير في مجال تراكمي EVM ZK بكيفية التعامل مع الأخطاء التي قد تظهر في كود ZK. حاليًا، جميع هذه الأنظمة العاملة لديها شكل من أشكال آلية "مجلس الأمن" الذي يتحكم في نظام التصديق في حالة حدوث خطأ. في العام الماضي، حاولت إنشاء إطار موحد من شأنه أن يشجع المشاريع على توضيح مدى ثقتها في نظام التصديق، ومدى ثقتها في مجلس الأمن، والحد تدريجيا من سلطتها على تلك المنظمة مع مرور الوقت.
أحدث مقال طويل لـ V God: هل يجب أن يتضمن بروتوكول Ethereum المزيد من الوظائف؟
*على المدى المتوسط، من المرجح أن يعتمد التجميع على أنظمة شهادات متعددة، مع عدم حصول مجلس الأمن على السلطة إلا في الحالات القصوى حيث يتباعد نظامان مختلفان لإصدار الشهادات. *
ومع ذلك، هناك شعور بأن بعض هذه الأعمال تبدو زائدة عن الحاجة. لدينا بالفعل طبقة أساسية من Ethereum، ولديها EVM، ولدينا بالفعل آلية عمل للتعامل مع الأخطاء في التنفيذ: إذا كان هناك خطأ، فسيتم تحديث العميل لإصلاحه، وستستمر السلسلة في العمل . من وجهة نظر العميل الذي يعاني من الأخطاء، يبدو أن عمليات الحظر التي تم الانتهاء منها لن يتم تأكيدها بعد الآن، ولكن على الأقل لن نرى المستخدمين يخسرون الأموال. وبالمثل، إذا كانت المجموعات المجمعة ترغب فقط في الحفاظ على الدور المعادل لـ EVM، فإنها تحتاج إلى تنفيذ إدارتها الخاصة لتغيير قواعد ZK-EVM الداخلية الخاصة بها باستمرار لمطابقة الترقيات مع الطبقة الأساسية لـ Ethereum، وهو ما يبدو خاطئًا لأنها في النهاية مبنية على القمة من الطبقة الأساسية للإيثريوم نفسها، فهي تعرف متى يجب الترقية ووفقًا للقواعد الجديدة.
نظرًا لأن L2 ZK-EVMs تستخدم أساسًا نفس EVM تمامًا مثل Ethereum، فهل يمكننا بطريقة أو بأخرى دمج "التحقق من تنفيذ EVM في ZK" في وظيفة البروتوكول والتعامل مع الاستثناءات من خلال تطبيق الإجماع الاجتماعي لـ Ethereum، مثل الأخطاء والترقيات، كما نفعل بالفعل من أجل تنفيذ الطبقة الأساسية EVM نفسها؟
هذا موضوع مهم وصعب.
أحد المواضيع المحتملة للنقاش فيما يتعلق بتوفر البيانات في ZK-EVM الأصلي هو الحالة. ستكون أجهزة ZK-EVM أكثر كفاءة في التعامل مع البيانات إذا لم تكن بحاجة إلى حمل بيانات "الشاهد". وهذا يعني أنه إذا تمت قراءة جزء معين من البيانات أو كتابته بالفعل في بعض الكتل السابقة، فيمكننا ببساطة أن نفترض أن المُثبِّت لديه حق الوصول إليها ولا يتعين عليه إتاحتها مرة أخرى. لا يقتصر الأمر على عدم إعادة تحميل وحدة التخزين والتعليمات البرمجية فحسب، بل اتضح أنه إذا ضغطت مجموعة البيانات المجمعة بشكل صحيح، فإن الضغط ذو الحالة يمكن أن يوفر ما يصل إلى 3 أضعاف البيانات مقارنة بالضغط عديم الحالة.
أحدث مقال طويل لـ V God: هل يجب أن يتضمن بروتوكول Ethereum المزيد من الوظائف؟
هذا يعني أنه بالنسبة للتجميع المسبق لـ ZK-EVM، لدينا خياران:
**1.**يتطلب التجميع المسبق أن تكون جميع البيانات متاحة في نفس الكتلة. هذا يعني أن المُثبِّت يمكن أن يكون عديم الحالة، ولكنه يعني أيضًا أن استخدام مجموعة ZK المترجمة مسبقًا هذه أكثر تكلفة بكثير من استخدام مجموعة التعليمات البرمجية المخصصة.
**2.**يسمح التجميع المسبق للمؤشرات بالإشارة إلى البيانات المستخدمة أو الناتجة عن عمليات التنفيذ السابقة. وهذا يجعل ZK-rollup قريبًا من المستوى الأمثل، ولكنه أكثر تعقيدًا ويقدم حالة جديدة يجب تخزينها بواسطة المُثبِّت.
ماذا يمكننا أن نتعلم من هذا؟ هناك سبب وجيه لتغليف التحقق من ZK-EVM بطريقة ما: تقوم مجموعة التحديثات بالفعل ببناء نسختها المخصصة الخاصة، وEthereum على استعداد لتنفيذ EVM على L1 مع وزن تطبيقاتها المتعددة والإجماع الاجتماعي خارج السلسلة. خطأ، ولكن قيام L2 بنفس المهمة بالضبط سيتعين عليه تنفيذ أداة معقدة تشمل مجلس الأمن. ولكن من ناحية أخرى، هناك مشكلة كبيرة في التفاصيل: هناك إصدارات مختلفة من ZK-EVM، ولها تكاليف وفوائد مختلفة. إن التمييز بين ذو الحالة وعديم الحالة لا يؤدي إلا إلى خدش السطح؛ وقد تؤدي محاولات دعم التعليمات البرمجية المخصصة "تقريبًا EVM" والتي تم إثباتها بواسطة أنظمة أخرى إلى الكشف عن مساحة تصميم أكبر. لذلك، تجلب تعبئة ZK-EVM الأمل والتحديات معًا.
فصل مقترح التغليف والباني (ePBS)
إن ظهور MEV يجعل إنتاج الكتل نشاطًا اقتصاديًا على نطاق واسع، مع وجود جهات فاعلة متطورة قادرة على إنتاج كتل تولد إيرادات أكثر من الخوارزمية الافتراضية، التي تراقب ببساطة مجموعة من المعاملات وتحتويها. حتى الآن، حاول مجتمع إيثريوم حل هذه المشكلة عن طريق استخدام مخططات فصل بين مقدم العرض والباني خارج البروتوكول مثل MEV-Boost، والتي تسمح للمدققين العاديين ("المقترحون") بدفع الكتل إلى جهات فاعلة متخصصة ("البناة"). ").
ومع ذلك، فإن MEV-Boost تضع افتراضات الثقة في فئة جديدة من الجهات الفاعلة تسمى المرحلات. في العامين الماضيين، كانت هناك العديد من المقترحات لإنشاء "برنامج تلفزيوني معبأ". ما هي فوائد القيام بذلك؟ في هذه الحالة، الإجابة بسيطة للغاية: إن برنامج تلفزيوني مبني باستخدام ميزات البروتوكول مباشرة يكون أكثر قوة (بمعنى وجود افتراضات ثقة أضعف) من برنامج تلفزيوني مبني دون استخدامها. وهذا مشابه لحالة تغليف أوراكل الأسعار ضمن البروتوكول - على الرغم من وجود اعتراضات قوية في هذه الحالة.
تغليف تجمع الذاكرة الخاصة
عندما يرسل المستخدم معاملة، تصبح عامة ومرئية للجميع على الفور، حتى قبل تضمينها في السلسلة. وهذا يترك مستخدمي العديد من التطبيقات عرضة للهجمات الاقتصادية، مثل الهجمات الأمامية.
في الآونة الأخيرة، كان هناك عدد من المشاريع المخصصة لإنشاء "مجموعات الذاكرة الخاصة" (أو "مجموعات الذاكرة المشفرة")، والتي تعمل على تشفير معاملات المستخدمين حتى يتم قبولها بشكل لا رجعة فيه في الكتلة.
ومع ذلك، تكمن المشكلة في أن مثل هذا المخطط يتطلب نوعًا خاصًا من التشفير: لمنع المستخدمين من إغراق النظام وفك تشفيره أولاً، يجب فك تشفير التشفير تلقائيًا بعد قبول المعاملة بشكل لا رجعة فيه.
هناك تقنيات مختلفة مع مقايضات مختلفة من أجل تنفيذ هذا النوع من التشفير. وقد وصفها جون شاربونو ذات مرة بشكل جيد:
لسوء الحظ، كل طريقة تشفير لها نقاط ضعف مختلفة. بينما يوجد لكل حل شريحة من المستخدمين يرغبون في الثقة به، إلا أنه لا يوجد حل موثوق به بدرجة كافية ليتم قبوله فعليًا من قبل الطبقة الأولى. **لذا، على الأقل حتى يتم إتقان التشفير المؤجل أو بعض التقدم التكنولوجي الآخر، يبدو أن تغليف وظيفة مكافحة التداول المسبق في الطبقة الأولى يمثل اقتراحًا صعبًا، حتى لو كانت ميزة ذات قيمة كافية تحلها العديد من التطبيقات. ظهرت الخطة.
تغليف عماد السيولة
هناك حاجة شائعة بين مستخدمي Ethereum DeFi وهي القدرة على استخدام ETH الخاص بهم في نفس الوقت للتخزين وكضمان في التطبيقات الأخرى. طلب شائع آخر هو ببساطة من أجل الراحة: يريد المستخدمون أن يكونوا قادرين على المشاركة (وحماية مفاتيح التخزين عبر الإنترنت) دون تعقيد تشغيل العقدة وإبقائها متصلة بالإنترنت دائمًا.
إن أبسط "واجهة" للتخزين تلبي كلا هاتين الحاجتين هي مجرد رمز ERC 20: قم بتحويل ETH الخاص بك إلى "التخزين ETH"، ثم احتفظ به، ثم قم بتحويله مرة أخرى. في الواقع، يقوم مقدمو خدمات الرهن العقاري مثل Lido وRocket Pool بذلك بالفعل. ومع ذلك، هناك بعض آليات المركزية الطبيعية التي تلعب دورًا في المراهنة على السيولة: سينتقل الأشخاص بشكل طبيعي إلى المراهنة على أكبر نسخة من ETH لأنها الأكثر شيوعًا وسيولة.
يحتاج كل إصدار من ETH إلى بعض الآليات لتحديد من يمكنه أن يصبح مشغل العقدة الأساسي. لا يمكن أن يكون غير محدود لأن المهاجمين سينضمون ويستخدمون أموال المستخدم لتوسيع هجماتهم. حاليًا، أعلى اثنين هما Lido وRocket Pool، حيث يحتوي الأول على مشغلي العقد DAO المدرجين في القائمة البيضاء والأخير يسمح لأي شخص بتشغيل عقدة بإيداع 8 ETH. الطريقتان لهما مخاطر مختلفة: تسمح طريقة Rocket Pool للمهاجم بتنفيذ هجوم بنسبة 51% على الشبكة وتجبر المستخدمين على دفع معظم التكاليف؛ أما بالنسبة لطريقة DAO، إذا سيطر رمز مميز معين، فسوف يؤدي ذلك إلى تتحكم أداة حوكمة واحدة من المحتمل أن تكون معرضة للخطر في جزء كبير من جميع أدوات التحقق من صحة Ethereum. ويُحسَب أن بروتوكولات مثل ليدو نفذت ضمانات، ولكن طبقة واحدة من الدفاع قد لا تكون كافية.
أحدث مقال طويل لـ V God: هل يجب أن يتضمن بروتوكول Ethereum المزيد من الوظائف؟
على المدى القصير، يتمثل أحد الخيارات في تشجيع المشاركين في النظام البيئي على استخدام مجموعة متنوعة من مقدمي حصص السيولة لتقليل احتمالية قيام اللاعب المهيمن بفرض مخاطر نظامية. ولكن على المدى الطويل، يشكل هذا التوازن غير مستقر، كما أن الاعتماد المفرط على الضغوط الأخلاقية لحل المشاكل أمر بالغ الخطورة. يطرح سؤال طبيعي: ** هل من المنطقي تضمين بعض الوظائف في البروتوكول لجعل عملية الرهان على السيولة أقل مركزية؟ **
السؤال الرئيسي هنا هو: ما نوع الوظيفة داخل البروتوكول؟ تتمثل إحدى مشكلات إنشاء رمز مميز "Saging ETH" قابل للاستبدال ضمن البروتوكول في أنه يجب إما أن يكون لديه حوكمة مغلفة على مستوى Ethereum لاختيار من يمكنه تشغيل العقد، أو أن يكون مفتوحًا، ولكن هذا من شأنه أن يحوله إلى عملة للمهاجم. أدوات.
فكرة مثيرة للاهتمام هي مقالة Dankrad Feist حول تعظيم حصص السيولة. أولاً، دعونا نتعرف على الأمر، إذا تعرض إيثريوم لهجوم بنسبة 51%، فقد يتم قطع 5% فقط من عملة إيثريوم التي تمت مهاجمتها. هذه مقايضة معقولة؛ مع وجود أكثر من 26 مليون ETH حاليًا، فإن تكلفة مهاجمة ثلث ذلك (حوالي 8 مليون ETH) باهظة، لا سيما بالنظر إلى عدد الهجمات "الخارجة عن النموذج" التي يمكن القيام بها في مكان ما. أقل تكلفة. في الواقع، تم استكشاف مقايضات مماثلة في اقتراح اللجنة العليا لتنفيذ نهائية الفتحة الواحدة.
أحدث مقال طويل لـ V God: هل يجب أن يتضمن بروتوكول Ethereum المزيد من الوظائف؟
إذا قبلنا أن 5% فقط من هجوم ETH قد تم قطعه، فإن أكثر من 90% من ETH المتراكمة لن تتأثر بالقطع، لذلك يمكن استخدامها كرموز تخزين سائلة قابلة للاستبدال ضمن البروتوكول ثم استخدامها بواسطة تطبيقات أخرى.
هذا المسار مثير للاهتمام. ولكن لا يزال يترك سؤالا: ما هو بالضبط مغلفة؟ **يعمل Rocket Pool بشكل مشابه جدًا: يوفر كل مشغل عقدة بعض الأموال، ويوفر أصحاب السيولة الباقي. يمكننا ببساطة تعديل بعض الثوابت للحد الأقصى لعقوبة القطع إلى 2 إيثريوم، وسوف تصبح قيمة الـ RETH الحالية في Rocket Pool خالية من المخاطر.
ومن خلال تعديلات بسيطة على البروتوكول، يمكننا أيضًا القيام بأشياء ذكية أخرى. على سبيل المثال، لنفترض أننا نريد نظامًا يحتوي على "مستويين" من التوقيع المساحي: مشغلو العقد (متطلبات ضمانات عالية) والمودعين (لا يوجد حد أدنى لمتطلبات الضمانات، ويمكنهم الانضمام والمغادرة في أي وقت)، لكننا ما زلنا نريد منح عينات عشوائية صلاحيات لجنة الإيداع لمنع مركزية مشغلي العقد، مثل التوصية بقائمة المعاملات التي يجب تضمينها (لأسباب مقاومة الرقابة)، أو التحكم في اختيار الشوكة أثناء تسرب عدم النشاط، أو طلب التوقيعات على الكتل. يمكن تحقيق ذلك بطريقة تخرج بشكل أساسي عن البروتوكول عن طريق تعديل البروتوكول ليطلب من كل مدقق توفير (1) مفتاح تخزين عادي، و (2) يتم استدعاء عنوان ETH الذي يمكن استخدامه في كل فتحة لإخراج مفتاح التعهد الثانوي. سيقوم البروتوكول بتمكين كلا المفتاحين، ولكن يمكن ترك آلية اختيار المفتاح الثاني في كل فتحة لبروتوكول تجمع التوقيع المساحي. قد يكون من الأفضل تغليف بعض الوظائف بشكل مباشر، ولكن تجدر الإشارة إلى أن مساحة التصميم هذه التي تتمثل في "تضمين بعض الأشياء وترك أشياء أخرى للمستخدم" موجودة.
تغليف المزيد من التجميع المسبق
العقود المجمعة مسبقًا (أو "العقود المجمعة") هي عقود إيثريوم تنفذ عمليات تشفير معقدة، مع تنفيذ المنطق محليًا في كود العميل بدلاً من كود العقد الذكي EVM. التشفير المسبق هو حل وسط تم تبنيه منذ بداية تطوير الإيثيريوم: نظرًا لأن الحمل الزائد للجهاز الظاهري كبير جدًا بالنسبة لبعض التعليمات البرمجية المعقدة للغاية والمتخصصة للغاية، فيمكننا تنفيذ بعض التطبيقات المهمة في التعليمات البرمجية الأصلية، وتقييم العمليات المهمة لجعلها أسرع. اليوم، يتضمن هذا بشكل أساسي بعض وظائف التجزئة المحددة وعمليات المنحنى الإهليلجي.
يوجد حاليًا دفعة لإضافة تجميع مسبق لـ secp 256 r 1، وهو منحنى إهليلجي مختلف قليلاً عن secp 256 k 1 المستخدم لحسابات الإيثريوم الأساسية، والذي يستخدم على نطاق واسع لأنه مدعوم جيدًا من خلال وحدات الأجهزة الموثوقة، استخدمه لزيادة أمان المحفظة. في السنوات الأخيرة، دفع المجتمع أيضًا لإضافة التجميع المسبق لـ BLS-12-377 وBW 6-761 والاقتران المعمم وميزات أخرى.
الحجة المضادة لهذه الدعوات لمزيد من المترجمات المسبقة هي أن العديد من المترجمات المسبقة التي تمت إضافتها سابقًا (مثل RIPEMD و BLAKE) انتهى بها الأمر إلى استخدام أقل بكثير مما كان متوقعًا، وعلينا أن نتعلم من هذا. بدلاً من إضافة المزيد من التجميع المسبق لعمليات محددة، ربما ينبغي لنا أن نركز على نهج أكثر ليونة يعتمد على أفكار مثل EVM-MAX ومقترح Hibernate-But-Always-Resumable SIMD، والذي من شأنه تمكين تطبيقات EVM من العمل بتكلفة أقل. مجموعة واسعة من فئات التعليمات البرمجية. ربما يمكن إزالة الترجمة المسبقة الحالية قليلة الاستخدام واستبدالها بتطبيق كود EVM (الأقل كفاءة حتمًا) لنفس الوظائف. ومع ذلك، لا يزال من الممكن أن تكون هناك عمليات تشفير محددة ذات قيمة كافية لتسريعها، لذا فمن المنطقي إضافتها على أنها مترجمة مسبقًا.
ماذا تعلمنا من كل هذا؟
إن الرغبة في تغليف أقل قدر ممكن أمر مفهوم وجيد؛ فهو ينبع من التقليد الفلسفي لنظام يونكس المتمثل في إنشاء برامج بسيطة يمكنها التكيف بسهولة مع الاحتياجات المختلفة للمستخدمين وتجنب لعنة تضخم البرامج. ومع ذلك، فإن blockchain ليس نظام تشغيل حاسوبي شخصي، ولكنه نظام اجتماعي. وهذا يعني أنه من المنطقي تغليف وظائف معينة في البروتوكول.
وفي كثير من الحالات، تكون هذه الأمثلة الأخرى مشابهة لما رأيناه في تجريد الحساب. لكننا تعلمنا أيضًا بعض الدروس الجديدة:
في كثير من الأحيان، يؤدي الحفاظ على الحد الأدنى من البروتوكول الأساسي وبساطته إلى دفع التعقيد إلى بعض الأنظمة البيئية خارج البروتوكول. من وجهة نظر فلسفة يونكس، هذا أمر جيد. ومع ذلك، هناك في بعض الأحيان خطر أن يصبح النظام البيئي خارج البروتوكول مركزيًا، عادةً (ولكن ليس فقط) بسبب التكاليف الثابتة المرتفعة. يمكن أن يؤدي التغليف في بعض الأحيان إلى تقليل المركزية الفعلية.
هذا هو موضوع مقال سابق حول "لا تفرط في إجماع الإيثريوم": إذا كان تغليف ميزة معينة يضعف نموذج الثقة ويجعل الإيثريوم ككل أكثر "ذاتية"، فإن هذا يضعف الإيثريوم. الحياد الموثوق. في هذه الحالات، من الأفضل أن يكون لديك وظيفة محددة كآلية أعلى الإيثريوم بدلاً من محاولة جلبها إلى الإيثريوم نفسه. تعد مجموعات الذاكرة المشفرة أفضل مثال هنا، والتي قد يكون من الصعب بعض الشيء تغليفها، على الأقل حتى يتحسن تشفير زمن الوصول.
يعد تعقيد البروتوكول بمثابة خطر نظامي يزداد عن طريق إضافة العديد من الميزات إلى البروتوكول. التجميع المسبق هو أفضل مثال.
الميزة التي يعتقد الكثير من الناس أنها مهمة والتي سيستخدمها العديد من المستخدمين ربما لا يتم استخدامها كثيرًا في الممارسة العملية.
بالإضافة إلى ذلك، تُظهر حصص السيولة وZK-EVM والأمثلة المترجمة مسبقًا إمكانية وجود مسار وسط: الحد الأدنى من التكريس القابل للتطبيق. لا يحتاج البروتوكول إلى تغليف الوظيفة بأكملها، ولكن يمكن أن يحتوي على أجزاء محددة تعالج التحديات الرئيسية، مما يجعل الوظيفة سهلة التنفيذ دون أن تكون مذعورًا أو ضيقًا للغاية. الامثله تشمل:
يمكننا توسيع المخطط السابق على النحو التالي:
في بعض الأحيان يكون من المنطقي تغليف شيء ما، ومن الأمثلة على ذلك إزالة المترجمات المسبقة التي نادرًا ما تستخدم. يعد تجريد الحساب ككل، كما ذكرنا سابقًا، أيضًا شكلاً مهمًا من أشكال إلغاء التغليف. إذا أردنا دعم التوافق العكسي للمستخدمين الحاليين، فقد تكون الآلية في الواقع مشابهة بشكل مدهش لتلك التي قامت بإلغاء تغليف التجميع المسبق: أحد المقترحات هو EIP-5003، والذي من شأنه أن يسمح لـ EOAs بتحويل حساباتهم للحصول على نفس الحسابات (أو أفضل) العقد الوظيفي.
إن تحديد الميزات التي يجب إدراجها في البروتوكول وأيها يجب تركها لطبقات أخرى من النظام البيئي هي مقايضة معقدة. ومن المتوقع أن تستمر هذه المقايضة في التحسن بمرور الوقت مع استمرار تحسن فهمنا لاحتياجات المستخدم ومجموعة الأفكار والتقنيات المتاحة.