في التاريخ المبكر لما كان يعرف آنذاك باسم "Ethereum 2.0" ، كانت هناك رغبة قوية في إنشاء بروتوكول نظيف وبسيط وممتع من الناحية الجمالية حاول البناء من تلقاء نفسه بأقل قدر ممكن وترك كل هذا النوع من العمل تقريبا للمستخدمين. من الناحية المثالية ، يكون البروتوكول مجرد جهاز افتراضي ، والتحقق من صحة جزء هو مجرد استدعاء آلة افتراضية.
ستكون "وظيفة انتقال الحالة" (الوظيفة التي تعالج القطعة) مجرد استدعاء VM واحد ، وسيحدث كل المنطق الآخر من خلال العقد: بعض العقود على مستوى النظام ، ولكن في الغالب العقود التي يقدمها المستخدم. ميزة جيدة جدا لهذا النموذج هي أنه حتى الهارد فورك بأكمله يمكن وصفه بأنه معاملة واحدة لعقد معالج الكتلة الذي ستتم الموافقة عليه من قبل الحوكمة خارج السلسلة أو على السلسلة ثم يتم تشغيله بامتيازات مرتفعة.
تنطبق هذه المناقشات في عام 2015 بشكل خاص على مجالين نظرنا فيهما: تجريد الحساب وتوسيع نطاقه. في حالة القياس ، تكمن الفكرة في محاولة إنشاء أقصى شكل تجريدي للقياس يبدو وكأنه امتداد طبيعي للمخطط أعلاه. يمكن للعقود استدعاء البيانات التي لم يتم تخزينها بواسطة معظم عقد Ethereum ، وسوف يكتشف البروتوكول ذلك ويحل المكالمة بنوع من وظيفة الحوسبة الموسعة العامة جدا. من منظور الجهاز الظاهري ، تنتقل المكالمة إلى نظام فرعي منفصل وتعيد الإجابة الصحيحة بطريقة سحرية بعد فترة.
لقد استكشفنا هذا الخط من التفكير لفترة وجيزة ، لكننا سرعان ما استسلمنا لأننا كنا نركز بشكل كبير على التحقق من أن أي نوع من توسيع نطاق blockchain ممكن. على الرغم من أننا سنرى لاحقا ، فإن الجمع بين أخذ عينات توافر البيانات و ZK-EVM يعني أن المستقبل المحتمل لتوسيع نطاق Ethereum يبدو في الواقع قريبا جدا من هذه الرؤية! من ناحية أخرى ، بالنسبة لتجريد الحساب ، علمنا منذ البداية أن نوعا من التنفيذ كان ممكنا ، لذلك بدأ البحث على الفور في محاولة تقريب شيء ما قدر الإمكان من نقطة البداية الخالصة المتمثلة في "التداول هو مجرد دعوة" إلى الواقع.
بين معالجة المعاملة وإجراء مكالمة EVM الأساسية الفعلية من عنوان المرسل ، هناك الكثير من التعليمات البرمجية المعيارية ، والمزيد من التعليمات البرمجية المعيارية بعد ذلك. كيف يمكننا تقليل هذا الرمز إلى أقرب ما يمكن من الصفر؟
أحد الرموز الرئيسية هنا هو validate_transaction(state، tx) ، وهو المسؤول عن التحقق من أن المعاملة تحتوي على nonce والتوقيع الصحيحين. منذ البداية ، كان الهدف العملي لتجريد الحساب هو السماح للمستخدمين باستبدال التحقق الأساسي غير التدريجي والتحقق ECDSA بمنطق التحقق الخاص بهم ، بحيث يمكن للمستخدمين استخدام ميزات مثل الاسترداد الاجتماعي والمحافظ متعددة التواقيع بسهولة أكبر. لذا ، فإن إيجاد طريقة لإعادة تصميم التطبيق \ _transaction كاستدعاء EVM بسيط ليس مجرد مهمة "رمز نظيف من أجل جعل الكود نظيفا" ؛ بدلا من ذلك ، يتعلق الأمر بنقل المنطق إلى رمز حساب المستخدم ، مما يمنح المستخدم المرونة التي يحتاجها.
ومع ذلك ، فإن الإصرار على أن يحتوي التطبيق \ _transaction على أقل قدر ممكن من المنطق الثابت ينتهي به الأمر إلى خلق الكثير من التحديات. يمكننا إلقاء نظرة على أحد أقدم مقترحات تجريد الحساب ، EIP-86 .
إذا تم تضمين EIP-86 كما هو ، فسوف يقلل من تعقيد EVM على حساب زيادة تعقيد الأجزاء الأخرى من مكدس Ethereum بشكل كبير ، مما يتطلب كتابة رمز متطابق بشكل أساسي في مكان آخر ، باستثناء إدخال فئات غريبة جديدة تماما ، مثل نفس المعاملة بنفس رقم التجزئة قد تظهر عدة مرات في السلسلة ، ناهيك عن مشكلة الإبطال المتعدد.
مشكلات إبطال متعددة في تجريد الحساب. يمكن أن تؤدي معاملة واحدة مضمنة في السلسلة إلى إبطال آلاف المعاملات الأخرى في mempool ، مما يجعل من السهل إغراق mempool بثمن بخس.
منذ ذلك الحين ، تطور تجريد الحساب على مراحل. أصبح 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.
مقاومة الرقابة: أحد تحديات الفصل بين مقدم العرض / المنشئ هو أنه يصبح من الأسهل مراجعة المعاملات الفردية. يمكن تخفيف هذه المشكلة بشكل كبير في عالم يمكن فيه لبروتوكول Ethereum التعرف على معاملة واحدة ، مما يسمح للمقترح بتحديد قائمة بالمعاملات التي يجب تضمينها في الفتحتين التاليتين في جميع الحالات تقريبا. ومع ذلك ، فإن ERC-4337 خارج البروتوكول يلخص "عمليات المستخدم" في معاملة واحدة ، مما يجعل عمليات المستخدم مبهمة لبروتوكول Ethereum ؛ لذلك ، لن تتمكن قائمة التضمين التي يوفرها بروتوكول Ethereum من توفير مقاومة الرقابة لعمليات مستخدم ERC-4337. سيؤدي تغليف ERC-4337 وجعل إجراء المستخدم نوعا "مناسبا" من المعاملات إلى حل هذه المشكلة.
تجدر الإشارة إلى أن ERC-4337 في شكله الحالي أغلى بكثير من معاملة Ethereum "الأساسية": تكلفة المعاملة هي 21،000 غاز ، بينما تكلف ERC-4337 حوالي 42،000 غاز.
من الناحية النظرية ، يجب أن يكون من الممكن ضبط نظام تكلفة غاز EVM حتى تتطابق التكلفة غير المتفق عليها وتكلفة الوصول خارج البروتوكول إلى التخزين ؛ عندما تكون الأنواع الأخرى من عمليات تحرير التخزين أرخص ، فلا يوجد سبب لنقل ETH عند 9000 غاز. في الواقع ، يحاول اثنان من EIPs المرتبطين بتحويل شجرة Verkle القادم القيام بذلك بالضبط. ولكن حتى لو فعلنا ذلك ، فهناك سبب واضح يجعل وظيفة البروتوكول المغلف ستكون حتما أرخص بكثير من كود EVM ، بغض النظر عن مدى كفاءة EVM: لا يحتاج الرمز المغلف إلى دفع الغاز مقابل التحميل المسبق.
محفظة ERC-4337 التي تعمل بكامل طاقتها كبيرة ، ويستغرق التنفيذ الذي يقوم بتجميعها ووضعها على السلسلة حوالي 12،800 بايت. بالطبع ، يمكنك نشر هذا الرمز مرة واحدة واستخدام DELEGATECALL للسماح لكل محفظة فردية بالاتصال به ، ولكن لا يزال يتعين عليك الوصول إلى الرمز في كل كتلة تستخدمه. بموجب تكلفة غاز شجرة Verkle EIP ، سيشكل 12,800 بايت 413 قطعة ، وسيتطلب الوصول إلى هذه القطع دفع 2x فرع الشاهد \ _cost (إجمالي 3,800 غاز) و 413x قطعة الشاهد \ _cost (إجمالي 82,600 غاز). وهذا لم يبدأ حتى في ذكر نقطة دخول ERC-4337 نفسها ، والتي تحتوي في الإصدار 0.6.0 على 23،689 بايت على السلسلة (حوالي 158،700 غاز للتحميل وفقا لقواعد شجرة Verkle EIP).
هذا يؤدي إلى المشكلة: يجب أن يتم إطفاء تكلفة الغاز للوصول الفعلي إلى هذه الرموز بطريقة ما عبر المعاملة. النهج الحالي الذي يستخدمه ERC-4337 ليس جيدا جدا: تستهلك المعاملة الأولى في الحزمة تكلفة تخزين / قراءة رمز لمرة واحدة ، مما يجعلها أغلى بكثير من المعاملات الأخرى. سيسمح التغليف داخل البروتوكول لهذه المكتبات العامة المشتركة بأن تكون جزءا من البروتوكول ويمكن للجميع الوصول إليها مجانا.
ما الذي يمكن أن نتعلمه من هذا المثال ، ومتى سيكون التغليف أكثر شيوعا؟ **
في هذا المثال ، نرى بعض الأسس المنطقية المختلفة لتغليف جانب تجريد الحساب في البروتوكول.
من المرجح أن تفشل الأساليب القائمة على السوق والتي "تدفع التعقيد إلى الحافة" عندما تكون التكاليف الثابتة مرتفعة. في الواقع ، تبدو خارطة طريق تجريد الحساب طويل الأجل وكأن كل كتلة لديها الكثير من التكاليف الثابتة. 244 ، 100 غاز لتحميل رموز المحفظة الموحدة شيء واحد ؛ لكن التجميع يمكن أن يضيف مئات الآلاف من الغاز إلى التحقق من صحة ZK-SNARK ، بالإضافة إلى التكلفة على السلسلة للتحقق من إثبات السلسلة. لا توجد طريقة لفرض رسوم على المستخدمين مقابل هذه التكاليف دون إدخال الكثير من أوجه القصور في السوق ، وترجمة بعض هذه الميزات إلى ميزات بروتوكول يمكن للجميع الوصول إليها مجانا يحل هذه المشكلة بشكل جيد.
استجابات على مستوى المجتمع لأخطاء التعليمات البرمجية. إذا تم استخدام بعض مقتطفات التعليمات البرمجية من قبل جميع المستخدمين أو مجموعة واسعة جدا من المستخدمين ، فعادة ما يكون من المنطقي أن يتحمل مجتمع blockchain مسؤولية الهارد فورك لإصلاح أي أخطاء تنشأ. يقدم ERC-4337 كمية كبيرة من التعليمات البرمجية المشتركة عالميا ، وإصلاح الأخطاء في التعليمات البرمجية من خلال الهارد فورك هو بلا شك أكثر منطقية على المدى الطويل من التسبب في فقدان المستخدمين الكثير من ETH.
في بعض الأحيان ، يمكن تحقيق شكل أقوى من خلال الاستفادة مباشرة من وظائف البروتوكول. المثال الرئيسي هنا هو ميزة مكافحة الرقابة داخل البروتوكول ، مثل قائمة التضمين: يمكن أن تضمن قائمة التضمين داخل البروتوكول مقاومة الرقابة بشكل أفضل من الطريقة خارج البروتوكول ، ولكي تستفيد العمليات على مستوى المستخدم حقا من قائمة التضمين داخل البروتوكول ، يجب أن تكون عملية واحدة على مستوى المستخدم "قابلة للقراءة" للبروتوكول. مثال آخر أقل شهرة هو تصميم إثبات الحصة في Ethereum لعام 2017 الذي استخرج حساب مفتاح الحصة ، والذي تم التخلي عنه لصالح تغليف BLS ، حيث يدعم BLS آلية "التجميع" التي يجب تنفيذها على مستوى البروتوكول والشبكة ، والتي يمكن أن تجعل التعامل مع أعداد كبيرة من التوقيعات أكثر كفاءة.
ولكن من المهم أن تتذكر أنه حتى تغليف تجريد الحساب داخل البروتوكول لا يزال يمثل "إزالة تغليف" ضخمة مقارنة بالوضع الحالي. اليوم ، لا يمكن بدء معاملات Ethereum من الدرجة الأولى إلا من الحسابات المملوكة خارجيا (EOAs) التي يتم التحقق منها بتوقيع منحنى بيضاوي الشكل واحد 256k1. يزيل تجريد الحساب هذا ويترك معايير التحقق للمستخدم لتحديدها. لذلك ، في هذه القصة حول تجريد الحساب ، نرى أيضا أكبر حجة ضد التغليف: المرونة لتلبية احتياجات المستخدمين المختلفين.
دعنا نوضح هذه القصة بشكل أكبر من خلال النظر في العديد من الأمثلة الأخرى للميزات التي تم اعتبارها مغلفة مؤخرا. سنولي اهتماما خاصا لما يلي: ZK-EVM ، وفصل مقدم العرض ، ومجمعات الميمات الخاصة ، وتخزين السيولة ، والتجميع المسبق الجديد.
الحزمة ZK-EVM
دعنا نوجه انتباهنا إلى هدف تغليف محتمل آخر لبروتوكول Ethereum: ZK-EVM. حاليا ، لدينا عدد كبير من ZK-rollups ، وكلها يجب أن تكتب رمزا مشابها إلى حد ما للتحقق من تنفيذ كتل Ethereum المماثلة في ZK-SNARK. هناك نظام بيئي متنوع إلى حد ما من التطبيقات المستقلة: PSE ZK-EVM ، Kakarot ، Polygon ZK-EVM ، Linea ، Zeth وغيرها الكثير.
يتعلق الجدل الأخير في مساحة EVM ZK-rollup بكيفية التعامل مع الأخطاء المحتملة في كود ZK. حاليا ، كل هذه الأنظمة قيد التشغيل لديها شكل من أشكال آلية "مجلس الأمن" التي تتحكم في نظام التصديق في حالة حدوث أخطاء. وفي العام الماضي، حاولت إنشاء إطار موحد لتشجيع المشاريع على توضيح مستوى ثقتها في نظام إصدار الشهادات، وكذلك في مجلس الأمن، والحد تدريجيا من سلطتها على المنظمة بمرور الوقت.
وفي الأجل المتوسط، قد تعتمد عمليات التجميع على نظم تصديق متعددة، ولن تكون لمجلس الأمن السلطة إلا في الحالات القصوى التي يتباعد فيها نظامان مختلفان للتصديق.
ومع ذلك ، هناك شعور بأن بعض الأعمال تبدو زائدة عن الحاجة. لدينا بالفعل طبقة Ethereum الأساسية ، ولديها EVM ، ولدينا بالفعل آلية عمل للتعامل مع الأخطاء في التنفيذ: إذا كان هناك خطأ ، فسيقوم العميل بالتحديث لإصلاحه ، ثم ستستمر السلسلة في العمل. من وجهة نظر عميل عربات التي تجرها الدواب ، يبدو أن الكتل التي تم الانتهاء منها لن يتم تأكيدها بعد الآن ، ولكن على الأقل لن نرى المستخدمين يخسرون المال. وبالمثل ، إذا أرادت المجموعات فقط الحفاظ على دورها المكافئ ل EVM ، فإنها تحتاج إلى تنفيذ الحوكمة الخاصة بها لتغيير قواعد ZK-EVM الداخلية باستمرار لمطابقة الترقيات إلى طبقة Ethereum الأساسية ، وهو أمر خاطئ لأنها في النهاية مبنية على قمة طبقة Ethereum الأساسية نفسها ، والتي تعرف متى يتم الترقية ووفقا للقواعد الجديدة.
نظرا لأن L2 ZK-EVMs تستخدم بشكل أساسي نفس EVMs تماما مثل Ethereum ، فهل يمكننا بطريقة ما دمج "التحقق من تنفيذ EVM في ZK" في وظيفة البروتوكول والتعامل مع الاستثناءات مثل الأخطاء والترقيات من خلال تطبيق الإجماع الاجتماعي ل Ethereum ، كما نفعل بالفعل مع تطبيق EVM للطبقة الأساسية نفسها؟
هذا موضوع مهم وصعب.
أحد الموضوعات المحتملة للنقاش حول توافر البيانات في ZK-EVM الأصلي هو الحالة. إذا لم تكن ZK-EVMs بحاجة إلى حمل بيانات "شاهد" ، فستكون كفاءة بياناتها أعلى بكثير. أي أنه إذا تمت قراءة جزء معين من البيانات أو كتابته بالفعل في بعض الكتل السابقة ، فيمكننا ببساطة افتراض أن البروفير لديه حق الوصول إليه ولا يتعين عليه إتاحته مرة أخرى. لا يتعلق الأمر فقط بعدم إعادة تحميل التخزين والرمز. اتضح أن ضغط الحالة يمكن أن يوفر ما يصل إلى 3x من البيانات مقارنة بالضغط عديم الحالة إذا قام أحد التراكمات بضغط البيانات بشكل صحيح.
هذا يعني أنه بالنسبة للتجميع المسبق ل ZK-EVM ، لدينا خياران:
يتطلب التجميع المسبق أن تكون جميع البيانات متاحة في نفس القطعة. هذا يعني أن prover يمكن أن يكون عديم الجنسية ، ولكنه يعني أيضا أن استخدام مجموعة ZK المترجمة مسبقا أغلى بكثير من استخدام مجموعة التحديثات مع التعليمات البرمجية المخصصة.
يسمح التحويل البرمجي المسبق للمؤشر بالإشارة إلى البيانات التي تم تنفيذها أو استخدامها أو إنشاؤها مسبقا. هذا يجعل ZK-rollup مثاليا تقريبا ، ولكنه أكثر تعقيدا ويقدم حالة جديدة يجب تخزينها بواسطة prover.
ماذا يمكن أن نتعلم من هذا؟ هناك سبب وجيه لتغليف التحقق من ZK-EVM بطريقة أو بأخرى: تقوم مجموعة التحديثات بالفعل ببناء نسختها المخصصة الخاصة ، و Ethereum على استعداد لتقييم تطبيقاتها المتعددة والإجماع الاجتماعي خارج السلسلة على L1 لتنفيذ EVM ، وهو أمر خاطئ ، لكن L2 الذي يقوم بنفس المهمة بالضبط يجب أن ينفذ أدوات معقدة تشمل مجلس الأمن. ولكن من ناحية أخرى ، هناك مشكلة كبيرة في التفاصيل: هناك إصدارات مختلفة من ZK-EVM ، والتي تختلف في التكلفة والفائدة. التمييز بين عديمي الجنسية وعديمي الجنسية يخدش السطح فقط. قد تؤدي محاولة دعم "almost-EVM" ، الرموز المخصصة التي أثبتتها أنظمة أخرى ، إلى كشف مساحة تصميم أكبر. وبالتالي ، فإن تغليف ZK-EVM يمثل وعدا وتحديات.
** فصل الغلاف والمنشئ (ePBS) **
أدى صعود MEV إلى جعل إنتاج البلوك نشاطا اقتصاديا واسع النطاق ، حيث يستطيع المشاركون المعقدون إنتاج كتل تولد إيرادات أكثر من الخوارزمية الافتراضية ، والتي تراقب ببساطة مجموعة المعاملات وتحتوي عليها. حتى الآن ، حاول مجتمع Ethereum حل هذه المشكلة باستخدام مخطط فصل بين مقدم الاقتراح والبناء خارج البروتوكول مثل MEV-Boost ، والذي يسمح للمدققين المنتظمين ("المقترحين") بالاستعانة بمصادر خارجية لبناء الكتلة للمشاركين المتخصصين ("البناة").
ومع ذلك ، فإن MEV-Boost تضع افتراضات ثقة في فئة جديدة من المشاركين تسمى المرحلات. في العامين الماضيين ، كان هناك العديد من المقترحات لإنشاء "PBS مغلفة". ما هي فوائد هذا؟ في هذه الحالة ، الجواب بسيط: PBS المبني مباشرة مع ميزات البروتوكول أقوى (بمعنى وجود افتراضات ثقة أضعف) من PBS المبني بدونها. هذا مشابه لحالة أوراكل السعر داخل بروتوكول التغليف - على الرغم من أنه في هذه الحالة ، هناك أيضا معارضة قوية.
تغليف تجمع الذاكرة الخاص
عندما يرسل المستخدم معاملة ، تكون عامة ومرئية للجميع على الفور ، حتى قبل تضمينها في السلسلة. وهذا يجعل مستخدمي العديد من التطبيقات عرضة للهجمات الاقتصادية ، مثل المعاملات الوقائية.
في الآونة الأخيرة ، كان هناك عدد من المشاريع المخصصة لإنشاء "mempools خاصة" (أو "mempools مشفرة") التي تقوم بتشفير معاملات المستخدمين حتى يتم قبولها بشكل لا رجعة فيه في كتلة.
ومع ذلك ، تكمن المشكلة في أن مثل هذه المخططات تتطلب نوعا خاصا من التشفير: من أجل منع المستخدمين من إغراق النظام وفك تشفيره أولا ، يجب فك تشفير التشفير تلقائيا بعد قبول المعاملة بالفعل بشكل لا رجعة فيه.
لتحقيق هذا النوع من التشفير ، هناك العديد من تقنيات المقايضة. جون شاربونو قال ذلك بشكل جيد:
تشفير المشغلين المركزيين ، مثل Flashbots Protect.
تشفير Timelock ، والذي يمكن فك تشفيره من قبل أي شخص بعد خطوة حسابية متسلسلة معينة ولا يمكن موازاته ؛
تشفير العتبة ، والثقة في لجنة أغلبية صادقة لفك تشفير البيانات. للحصول على توصيات محددة, راجع مفهوم سلسلة المنارة المغلقة.
الأجهزة الموثوق بها، مثل SGX.
لسوء الحظ ، كل تشفير له نقاط ضعف مختلفة. بينما لكل حل ، هناك مجموعة فرعية من المستخدمين على استعداد للثقة به ، لا يوجد أي من الحلول موثوق بها بما يكفي لقبولها فعليا بواسطة الطبقة 1. لذلك ، على الأقل حتى يتم إتقان تشفير زمن الوصول أو بعض الاختراقات التكنولوجية الأخرى ، يبدو تغليف وظائف التداول المضادة للتقدم في الطبقة 1 اقتراحا صعبا ، حتى لو كانت ميزة قيمة بما يكفي لظهور العديد من حلول التطبيقات.
تخزين السيولة المغلفة
هناك حاجة شائعة لمستخدمي Ethereum DeFi وهي القدرة على استخدام ETH الخاص بهم في وقت واحد للتخزين وكضمان في التطبيقات الأخرى. هناك حاجة شائعة أخرى هي ببساطة للراحة: يريد المستخدمون أن يكونوا قادرين على المشاركة (وحماية مفاتيح التخزين عبر الإنترنت) دون تعقيد تشغيل عقدة وإبقائها دائما على الإنترنت.
حتى الآن ، فإن أبسط "واجهة" تخزين تلبي كلا الاحتياجين هي مجرد رمز ERC 20: قم بتحويل ETH إلى "حصة ETH" ، واحتفظ بها ، وقم بتحويلها مرة أخرى. في الواقع ، بدأ مقدمو خدمات تخزين السيولة مثل Lido و Rocket Pool بالفعل في القيام بذلك. ومع ذلك ، فإن تخزين السيولة لديه بعض آليات المركزية الطبيعية في العمل: يذهب الناس بشكل طبيعي إلى أكبر نسخة من Staking ETH لأنها الأكثر شيوعا وسيولة.
يتطلب كل إصدار من Staking ETH بعض الآليات لتحديد من يمكنه أن يكون مشغل العقدة الأساسي. لا يمكن أن يكون غير محدود ، حيث سينضم المهاجمون إلى الهجوم ويضخمونه بأموال المستخدم. حاليا ، أعلى اثنين هما Lido ، الذي يحتوي على مشغل عقدة القائمة البيضاء DAO ، و Rocket Pool ، والذي يسمح لأي شخص بتشغيل عقدة مع إيداع 8 ETH. وتنطوي الطريقتان على مخاطر مختلفة: يسمح نهج Rocket Pool للمهاجمين بتنفيذ هجمات بنسبة 51٪ على الشبكة ويجبر المستخدمين على دفع معظم التكلفة. أما بالنسبة لنهج DAO ، إذا سيطر رمز تخزين معين ، فإنه ينتج عنه أداة حوكمة واحدة يمكن مهاجمتها تتحكم في جزء كبير من جميع مدققي Ethereum. من المؤكد أن بروتوكولات مثل ليدو لديها بالفعل احتياطات مطبقة ، لكن طبقة الدفاع قد لا تكون كافية.
وعلى المدى القصير، يتمثل أحد الخيارات في تشجيع المشاركين في النظام الإيكولوجي على استخدام مجموعة متنوعة من مقدمي خدمات تخزين السيولة للحد من احتمال حدوث مخاطر نظامية من شركة واحدة. ولكن هذا التوازن محفوف بالمخاطر في الأمد البعيد، ومن الخطورة بمكان أن نعتمد أكثر مما ينبغي على الضغوط الأخلاقية لحل المشاكل. والسؤال الطبيعي الذي يطرح نفسه: هل من المنطقي أن نغلف نوعا من الوظائف في البروتوكول لجعل تخزين السيولة أقل مركزية؟
السؤال الرئيسي هنا هو: ما نوع الوظائف داخل البروتوكول؟ تكمن المشكلة ببساطة في إنشاء رمز "Staking ETH" القابل للاستبدال في البروتوكول في أنه إما يجب أن يكون لديه حوكمة مغلفة على مستوى Ethereum لاختيار من يدير العقد ، أو أنه مفتوح ، ولكن هذا يحولها إلى أداة للمهاجمين.
فكرة مثيرة للاهتمام هي مقالة Dankrad Feist حول تعظيم تخزين السيولة. أولا ، دعنا نعض الرصاصة وإذا تعرضت Ethereum للهجوم بنسبة 51٪ ، فقد تتم مصادرة 5٪ فقط من الهجوم ETH. هذه مقايضة معقولة. مع وجود أكثر من 26 مليون ETH يتم تخزينها حاليا ، فإن ثلث ذلك (حوالي 8 ملايين ETH) من تكلفة الهجوم مفرط ، لا سيما بالنظر إلى عدد الهجمات "خارج النموذج" التي يمكن القيام بها بتكلفة أقل. في الواقع ، تم استكشاف مقايضات مماثلة في اقتراح اللجنة العليا لتنفيذ نهائية الفتحة الواحدة.
إذا قبلنا مصادرة 5٪ فقط من ETH للهجوم ، فلن يتأثر أكثر من 90٪ من ETH المربوط بالمصادرة ، لذلك يمكن استخدامها كرموز تخزين سيولة قابلة للاستبدال داخل البروتوكول ثم استخدامها من قبل تطبيقات أخرى.
المسار مثير للاهتمام. لكنه لا يزال يترك السؤال: ما هو مغلف بالضبط؟ يعمل Rocket Pool بشكل مشابه جدا: يوفر كل مشغل عقدة بعض الأموال ، ويوفر مخزنو السيولة الباقي. يمكننا ببساطة ضبط بعض الثوابت للحد من العقوبة القصوى إلى 2 ETH وستصبح rETH الحالية ل Rocket Pool خالية من المخاطر.
من خلال تعديلات البروتوكول البسيطة ، يمكننا أيضا القيام بأشياء ذكية أخرى. على سبيل المثال ، لنفترض أننا نريد نظاما يحتوي على "طبقتين" من التراص: مشغلي العقد (متطلبات الضمان العالية) والمودعين (لا يوجد حد أدنى لمتطلبات الضمان ويمكنهم الانضمام والمغادرة في أي وقت) ، لكننا ما زلنا نريد منع مركزية مشغلي العقد من خلال تمكين لجنة مودعين عينة عشوائية ، مثل اقتراح قائمة بالمعاملات التي يجب تضمينها (لأسباب مقاومة الرقابة) ، أو التحكم في اختيار الشوكة أثناء التسريبات غير النشطة ، أو طلب توقيع الكتلة. يمكن تحقيق ذلك بطريقة تنفصل بشكل أساسي عن البروتوكول عن طريق تعديل البروتوكول لمطالبة كل مدقق بتوفير (i) مفتاح تخزين عادي ، و (ii) عنوان ETH يمكن استدعاؤه عبر كل فتحة لإخراج مفتاح تخزين ثانوي. سيعطي البروتوكول الطاقة لكلا المفتاحين ، ولكن يمكن ترك آلية اختيار المفتاح الثاني في كل فتحة لبروتوكول تجمع Staking . قد لا يزال من الأفضل تغليف بعض الميزات مباشرة ، ولكن تجدر الإشارة إلى أن مساحة التصميم هذه "تشمل بعض الأشياء وتترك كل شيء آخر للمستخدم".
** تغليف المزيد من التجميعات المسبقة **
المترجمة مسبقا (أو "العقود المترجمة مسبقا") هي عقود Ethereum التي تنفذ عمليات تشفير معقدة ، يتم تنفيذ منطقها أصلا في رمز العميل ، بدلا من رمز العقد الذكي EVM. كان الترميز المسبق حلا وسطا تم تبنيه في بداية تطوير Ethereum: نظرا لأن الحمل الزائد للجهاز الظاهري كان كبيرا جدا بالنسبة لبعض التعليمات البرمجية المعقدة للغاية والمتخصصة للغاية ، يمكننا تنفيذ بعض العمليات الرئيسية في التعليمات البرمجية المحلية التي كانت ذات قيمة للتطبيقات المهمة لجعلها أسرع. اليوم ، يتضمن هذا بشكل أساسي بعض وظائف التجزئة المحددة وعمليات المنحنى الإهليلجي.
يوجد حاليا دفعة لإضافة تجميع مسبق ل secp 256 R1 ، وهو منحنى بيضاوي مختلف قليلا عن secp 256 K1 لحسابات Ethereum الأساسية ، حيث إنه مدعوم جيدا بوحدات الأجهزة الموثوقة ، لذا فإن استخدامه على نطاق واسع يمكن أن يحسن أمان المحفظة. في السنوات الأخيرة ، دفع المجتمع أيضا لإضافة مجموعات مسبقة ل BLS-12-377 و BW 6-761 والاقتران المعمم وميزات أخرى.
الحجة المضادة لهذه الطلبات لمزيد من الملفات المترجمة مسبقا هي أن العديد من التجميعات المسبقة المضافة سابقا (مثل RIPEMD و BLAKE) ينتهي بها الأمر باستخدام أقل بكثير مما كان متوقعا ، ويجب أن نتعلم منها. بدلا من إضافة المزيد من التجميع المسبق لعمليات محددة ، ربما يجب علينا التركيز على نهج ألطف يعتمد على أفكار مثل EVM-MAX ومقترحات SIMD الخاملة ولكن القابلة للاسترداد دائما ، والتي ستمكن تطبيقات EVM من تنفيذ مجموعة واسعة من فئات التعليمات البرمجية بتكلفة أقل. ربما يمكن إزالة التجميع المسبق الحالي الذي نادرا ما يستخدم واستبداله بتنفيذ (أقل كفاءة حتما) لرمز EVM لنفس الوظيفة. ومع ذلك ، لا يزال من الممكن وجود عمليات تشفير محددة ذات قيمة كافية لتسريعها ، لذلك من المنطقي إضافتها على أنها مجمعة مسبقا.
ماذا تعلمنا من كل هذا؟
الرغبة في تغليف أقل قدر ممكن أمر مفهوم وجيد. إنه مستمد من تقليد Unix الفلسفي المتمثل في إنشاء برامج بسيطة يمكن تكييفها بسهولة مع الاحتياجات المختلفة للمستخدمين وتجنب لعنة سخام البرامج. ومع ذلك ، فإن blockchain ليس نظام تشغيل حوسبة شخصية ، ولكنه نظام اجتماعي. هذا يعني أنه من المنطقي تغليف وظائف معينة في البروتوكول.
في كثير من الحالات ، تشبه هذه الأمثلة الأخرى ما نراه في تجريد الحساب. لكننا تعلمنا أيضا بعض الدروس الجديدة:
يمكن أن يساعد التغليف في تجنب خطر المركزية في مكان آخر في المكدس:
في كثير من الأحيان ، يؤدي الحفاظ على الحد الأدنى من البروتوكول الأساسي وبسيطه إلى دفع التعقيد إلى ما هو أبعد من بعض بروتوكولات النظام البيئي. من وجهة نظر يونكس الفلسفية ، هذا جيد. ومع ذلك ، هناك في بعض الأحيان خطر أن النظم الإيكولوجية خارج البروتوكول سوف تتركز ، عادة (ولكن ليس فقط) بسبب ارتفاع التكاليف الثابتة. يمكن أن يقلل التغليف في بعض الأحيان من المركزية الفعلية.
يمكن أن يؤدي تغليف الكثير من المحتوى إلى زيادة عبء الثقة والحوكمة على البروتوكول:
هذا هو موضوع مقال سابق حول "لا تفرط في إجماع Ethereum": إذا كان تغليف وظيفة معينة يضعف نموذج الثقة ويجعل Ethereum ككل أكثر "ذاتية" ، فإنه يضعف حياد Ethereum الموثوق به. في هذه الحالات ، من الأفضل تقديم ميزة محددة كآلية أعلى Ethereum بدلا من محاولة تقديمها إلى Ethereum نفسها. هنا ، تعد تجمعات الذاكرة المشفرة أفضل مثال ، وقد يكون من الصعب بعض الشيء تغليفها ، على الأقل حتى يتحسن تشفير زمن الوصول.
يمكن أن يؤدي التغليف المفرط إلى تعقيد البروتوكول:
تعقيد البروتوكول هو خطر نظامي يمكن زيادته عن طريق إضافة الكثير من الميزات إلى البروتوكول. التجميع المسبق هو أفضل مثال.
على المدى الطويل ، يمكن أن تؤدي وظيفة التغليف إلى نتائج عكسية لأن احتياجات المستخدم لا يمكن التنبؤ بها:
من المحتمل ألا يتم استخدام الميزة التي يعتبرها العديد من الأشخاص مهمة وسيستخدمها العديد من المستخدمين بانتظام في الممارسة العملية.
بالإضافة إلى ذلك ، يظهر تخزين السيولة ، ZK-EVM ، والحالات المجمعة مسبقا إمكانية وجود طريق وسط: الحد الأدنى من التكريس القابل للتطبيق. لا تحتاج البروتوكولات إلى تغليف الوظيفة بأكملها ، ولكن يمكن أن تحتوي على أجزاء محددة تعالج التحديات الرئيسية ، مما يجعل الوظيفة سهلة التنفيذ دون أن تكون بجنون العظمة أو ضيقة جدا. ومن الأمثلة على ذلك ما يلي:
وبدلا من تغليف نظام كامل لرهن السيولة، من الأفضل تغيير قواعد عقوبة الرهان لجعل التعهد بالسيولة غير الموثوق به أكثر جدوى؛
بدلا من تغليف المزيد من المجمعين المسبقين ، قم بتغليف EVM-MAX و / أو SIMD لتسهيل التنفيذ بكفاءة لمجموعة واسعة من فئات التشغيل ؛
يمكن ببساطة تغليف التحقق من EVM بدلا من تغليف مفهوم التجميع بأكمله.
يمكننا توسيع الرسم البياني السابق على النحو التالي:
في بعض الأحيان يكون من المنطقي التفاف شيء ما ، وإزالة التجميع المسبق الذي نادرا ما يستخدم هو مثال. تجريد الحساب ككل ، كما ذكرنا سابقا ، هو أيضا شكل مهم من أشكال إزالة التغليف. إذا أردنا دعم التوافق مع الإصدارات السابقة للمستخدمين الحاليين ، فقد تكون الآلية في الواقع مشابهة بشكل لافت للنظر لتلك التي تقوم بإلغاء تغليف التجميع المسبق: أحد المقترحات هو EIP-5003 ، والذي سيسمح ل EOA بتحويل حساباتها إلى عقود بنفس الوظيفة (أو أفضل).
إن السمات التي يجب إدخالها في البروتوكول والتي يجب تركها لطبقات أخرى من النظام البيئي هي مقايضة معقدة. من المتوقع أن تستمر هذه المقايضة في التحسن بمرور الوقت مع استمرار تحسن فهمنا لاحتياجات المستخدمين والأفكار المتاحة ومجموعات التكنولوجيا.
شاهد النسخة الأصلية
قد تحتوي هذه الصفحة على محتوى من جهات خارجية، يتم تقديمه لأغراض إعلامية فقط (وليس كإقرارات/ضمانات)، ولا ينبغي اعتباره موافقة على آرائه من قبل Gate، ولا بمثابة نصيحة مالية أو مهنية. انظر إلى إخلاء المسؤولية للحصول على التفاصيل.
فيتاليك بوتيرين: هل يجب أن تغلف Ethereum المزيد من الميزات؟
** الفلسفات المبكرة لبساطتها البروتوكول **
في التاريخ المبكر لما كان يعرف آنذاك باسم "Ethereum 2.0" ، كانت هناك رغبة قوية في إنشاء بروتوكول نظيف وبسيط وممتع من الناحية الجمالية حاول البناء من تلقاء نفسه بأقل قدر ممكن وترك كل هذا النوع من العمل تقريبا للمستخدمين. من الناحية المثالية ، يكون البروتوكول مجرد جهاز افتراضي ، والتحقق من صحة جزء هو مجرد استدعاء آلة افتراضية.
ستكون "وظيفة انتقال الحالة" (الوظيفة التي تعالج القطعة) مجرد استدعاء VM واحد ، وسيحدث كل المنطق الآخر من خلال العقد: بعض العقود على مستوى النظام ، ولكن في الغالب العقود التي يقدمها المستخدم. ميزة جيدة جدا لهذا النموذج هي أنه حتى الهارد فورك بأكمله يمكن وصفه بأنه معاملة واحدة لعقد معالج الكتلة الذي ستتم الموافقة عليه من قبل الحوكمة خارج السلسلة أو على السلسلة ثم يتم تشغيله بامتيازات مرتفعة.
تنطبق هذه المناقشات في عام 2015 بشكل خاص على مجالين نظرنا فيهما: تجريد الحساب وتوسيع نطاقه. في حالة القياس ، تكمن الفكرة في محاولة إنشاء أقصى شكل تجريدي للقياس يبدو وكأنه امتداد طبيعي للمخطط أعلاه. يمكن للعقود استدعاء البيانات التي لم يتم تخزينها بواسطة معظم عقد Ethereum ، وسوف يكتشف البروتوكول ذلك ويحل المكالمة بنوع من وظيفة الحوسبة الموسعة العامة جدا. من منظور الجهاز الظاهري ، تنتقل المكالمة إلى نظام فرعي منفصل وتعيد الإجابة الصحيحة بطريقة سحرية بعد فترة.
لقد استكشفنا هذا الخط من التفكير لفترة وجيزة ، لكننا سرعان ما استسلمنا لأننا كنا نركز بشكل كبير على التحقق من أن أي نوع من توسيع نطاق blockchain ممكن. على الرغم من أننا سنرى لاحقا ، فإن الجمع بين أخذ عينات توافر البيانات و ZK-EVM يعني أن المستقبل المحتمل لتوسيع نطاق Ethereum يبدو في الواقع قريبا جدا من هذه الرؤية! من ناحية أخرى ، بالنسبة لتجريد الحساب ، علمنا منذ البداية أن نوعا من التنفيذ كان ممكنا ، لذلك بدأ البحث على الفور في محاولة تقريب شيء ما قدر الإمكان من نقطة البداية الخالصة المتمثلة في "التداول هو مجرد دعوة" إلى الواقع.
بين معالجة المعاملة وإجراء مكالمة EVM الأساسية الفعلية من عنوان المرسل ، هناك الكثير من التعليمات البرمجية المعيارية ، والمزيد من التعليمات البرمجية المعيارية بعد ذلك. كيف يمكننا تقليل هذا الرمز إلى أقرب ما يمكن من الصفر؟
أحد الرموز الرئيسية هنا هو validate_transaction(state، tx) ، وهو المسؤول عن التحقق من أن المعاملة تحتوي على nonce والتوقيع الصحيحين. منذ البداية ، كان الهدف العملي لتجريد الحساب هو السماح للمستخدمين باستبدال التحقق الأساسي غير التدريجي والتحقق ECDSA بمنطق التحقق الخاص بهم ، بحيث يمكن للمستخدمين استخدام ميزات مثل الاسترداد الاجتماعي والمحافظ متعددة التواقيع بسهولة أكبر. لذا ، فإن إيجاد طريقة لإعادة تصميم التطبيق \ _transaction كاستدعاء EVM بسيط ليس مجرد مهمة "رمز نظيف من أجل جعل الكود نظيفا" ؛ بدلا من ذلك ، يتعلق الأمر بنقل المنطق إلى رمز حساب المستخدم ، مما يمنح المستخدم المرونة التي يحتاجها.
ومع ذلك ، فإن الإصرار على أن يحتوي التطبيق \ _transaction على أقل قدر ممكن من المنطق الثابت ينتهي به الأمر إلى خلق الكثير من التحديات. يمكننا إلقاء نظرة على أحد أقدم مقترحات تجريد الحساب ، EIP-86 .
إذا تم تضمين EIP-86 كما هو ، فسوف يقلل من تعقيد EVM على حساب زيادة تعقيد الأجزاء الأخرى من مكدس Ethereum بشكل كبير ، مما يتطلب كتابة رمز متطابق بشكل أساسي في مكان آخر ، باستثناء إدخال فئات غريبة جديدة تماما ، مثل نفس المعاملة بنفس رقم التجزئة قد تظهر عدة مرات في السلسلة ، ناهيك عن مشكلة الإبطال المتعدد.
مشكلات إبطال متعددة في تجريد الحساب. يمكن أن تؤدي معاملة واحدة مضمنة في السلسلة إلى إبطال آلاف المعاملات الأخرى في mempool ، مما يجعل من السهل إغراق mempool بثمن بخس.
منذ ذلك الحين ، تطور تجريد الحساب على مراحل. أصبح 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.
مقاومة الرقابة: أحد تحديات الفصل بين مقدم العرض / المنشئ هو أنه يصبح من الأسهل مراجعة المعاملات الفردية. يمكن تخفيف هذه المشكلة بشكل كبير في عالم يمكن فيه لبروتوكول Ethereum التعرف على معاملة واحدة ، مما يسمح للمقترح بتحديد قائمة بالمعاملات التي يجب تضمينها في الفتحتين التاليتين في جميع الحالات تقريبا. ومع ذلك ، فإن ERC-4337 خارج البروتوكول يلخص "عمليات المستخدم" في معاملة واحدة ، مما يجعل عمليات المستخدم مبهمة لبروتوكول Ethereum ؛ لذلك ، لن تتمكن قائمة التضمين التي يوفرها بروتوكول Ethereum من توفير مقاومة الرقابة لعمليات مستخدم ERC-4337. سيؤدي تغليف ERC-4337 وجعل إجراء المستخدم نوعا "مناسبا" من المعاملات إلى حل هذه المشكلة.
تجدر الإشارة إلى أن ERC-4337 في شكله الحالي أغلى بكثير من معاملة Ethereum "الأساسية": تكلفة المعاملة هي 21،000 غاز ، بينما تكلف ERC-4337 حوالي 42،000 غاز.
من الناحية النظرية ، يجب أن يكون من الممكن ضبط نظام تكلفة غاز EVM حتى تتطابق التكلفة غير المتفق عليها وتكلفة الوصول خارج البروتوكول إلى التخزين ؛ عندما تكون الأنواع الأخرى من عمليات تحرير التخزين أرخص ، فلا يوجد سبب لنقل ETH عند 9000 غاز. في الواقع ، يحاول اثنان من EIPs المرتبطين بتحويل شجرة Verkle القادم القيام بذلك بالضبط. ولكن حتى لو فعلنا ذلك ، فهناك سبب واضح يجعل وظيفة البروتوكول المغلف ستكون حتما أرخص بكثير من كود EVM ، بغض النظر عن مدى كفاءة EVM: لا يحتاج الرمز المغلف إلى دفع الغاز مقابل التحميل المسبق.
محفظة ERC-4337 التي تعمل بكامل طاقتها كبيرة ، ويستغرق التنفيذ الذي يقوم بتجميعها ووضعها على السلسلة حوالي 12،800 بايت. بالطبع ، يمكنك نشر هذا الرمز مرة واحدة واستخدام DELEGATECALL للسماح لكل محفظة فردية بالاتصال به ، ولكن لا يزال يتعين عليك الوصول إلى الرمز في كل كتلة تستخدمه. بموجب تكلفة غاز شجرة Verkle EIP ، سيشكل 12,800 بايت 413 قطعة ، وسيتطلب الوصول إلى هذه القطع دفع 2x فرع الشاهد \ _cost (إجمالي 3,800 غاز) و 413x قطعة الشاهد \ _cost (إجمالي 82,600 غاز). وهذا لم يبدأ حتى في ذكر نقطة دخول ERC-4337 نفسها ، والتي تحتوي في الإصدار 0.6.0 على 23،689 بايت على السلسلة (حوالي 158،700 غاز للتحميل وفقا لقواعد شجرة Verkle EIP).
هذا يؤدي إلى المشكلة: يجب أن يتم إطفاء تكلفة الغاز للوصول الفعلي إلى هذه الرموز بطريقة ما عبر المعاملة. النهج الحالي الذي يستخدمه ERC-4337 ليس جيدا جدا: تستهلك المعاملة الأولى في الحزمة تكلفة تخزين / قراءة رمز لمرة واحدة ، مما يجعلها أغلى بكثير من المعاملات الأخرى. سيسمح التغليف داخل البروتوكول لهذه المكتبات العامة المشتركة بأن تكون جزءا من البروتوكول ويمكن للجميع الوصول إليها مجانا.
ما الذي يمكن أن نتعلمه من هذا المثال ، ومتى سيكون التغليف أكثر شيوعا؟ **
في هذا المثال ، نرى بعض الأسس المنطقية المختلفة لتغليف جانب تجريد الحساب في البروتوكول.
من المرجح أن تفشل الأساليب القائمة على السوق والتي "تدفع التعقيد إلى الحافة" عندما تكون التكاليف الثابتة مرتفعة. في الواقع ، تبدو خارطة طريق تجريد الحساب طويل الأجل وكأن كل كتلة لديها الكثير من التكاليف الثابتة. 244 ، 100 غاز لتحميل رموز المحفظة الموحدة شيء واحد ؛ لكن التجميع يمكن أن يضيف مئات الآلاف من الغاز إلى التحقق من صحة ZK-SNARK ، بالإضافة إلى التكلفة على السلسلة للتحقق من إثبات السلسلة. لا توجد طريقة لفرض رسوم على المستخدمين مقابل هذه التكاليف دون إدخال الكثير من أوجه القصور في السوق ، وترجمة بعض هذه الميزات إلى ميزات بروتوكول يمكن للجميع الوصول إليها مجانا يحل هذه المشكلة بشكل جيد.
استجابات على مستوى المجتمع لأخطاء التعليمات البرمجية. إذا تم استخدام بعض مقتطفات التعليمات البرمجية من قبل جميع المستخدمين أو مجموعة واسعة جدا من المستخدمين ، فعادة ما يكون من المنطقي أن يتحمل مجتمع blockchain مسؤولية الهارد فورك لإصلاح أي أخطاء تنشأ. يقدم ERC-4337 كمية كبيرة من التعليمات البرمجية المشتركة عالميا ، وإصلاح الأخطاء في التعليمات البرمجية من خلال الهارد فورك هو بلا شك أكثر منطقية على المدى الطويل من التسبب في فقدان المستخدمين الكثير من ETH.
في بعض الأحيان ، يمكن تحقيق شكل أقوى من خلال الاستفادة مباشرة من وظائف البروتوكول. المثال الرئيسي هنا هو ميزة مكافحة الرقابة داخل البروتوكول ، مثل قائمة التضمين: يمكن أن تضمن قائمة التضمين داخل البروتوكول مقاومة الرقابة بشكل أفضل من الطريقة خارج البروتوكول ، ولكي تستفيد العمليات على مستوى المستخدم حقا من قائمة التضمين داخل البروتوكول ، يجب أن تكون عملية واحدة على مستوى المستخدم "قابلة للقراءة" للبروتوكول. مثال آخر أقل شهرة هو تصميم إثبات الحصة في Ethereum لعام 2017 الذي استخرج حساب مفتاح الحصة ، والذي تم التخلي عنه لصالح تغليف BLS ، حيث يدعم BLS آلية "التجميع" التي يجب تنفيذها على مستوى البروتوكول والشبكة ، والتي يمكن أن تجعل التعامل مع أعداد كبيرة من التوقيعات أكثر كفاءة.
ولكن من المهم أن تتذكر أنه حتى تغليف تجريد الحساب داخل البروتوكول لا يزال يمثل "إزالة تغليف" ضخمة مقارنة بالوضع الحالي. اليوم ، لا يمكن بدء معاملات Ethereum من الدرجة الأولى إلا من الحسابات المملوكة خارجيا (EOAs) التي يتم التحقق منها بتوقيع منحنى بيضاوي الشكل واحد 256k1. يزيل تجريد الحساب هذا ويترك معايير التحقق للمستخدم لتحديدها. لذلك ، في هذه القصة حول تجريد الحساب ، نرى أيضا أكبر حجة ضد التغليف: المرونة لتلبية احتياجات المستخدمين المختلفين.
دعنا نوضح هذه القصة بشكل أكبر من خلال النظر في العديد من الأمثلة الأخرى للميزات التي تم اعتبارها مغلفة مؤخرا. سنولي اهتماما خاصا لما يلي: ZK-EVM ، وفصل مقدم العرض ، ومجمعات الميمات الخاصة ، وتخزين السيولة ، والتجميع المسبق الجديد.
الحزمة ZK-EVM
دعنا نوجه انتباهنا إلى هدف تغليف محتمل آخر لبروتوكول Ethereum: ZK-EVM. حاليا ، لدينا عدد كبير من ZK-rollups ، وكلها يجب أن تكتب رمزا مشابها إلى حد ما للتحقق من تنفيذ كتل Ethereum المماثلة في ZK-SNARK. هناك نظام بيئي متنوع إلى حد ما من التطبيقات المستقلة: PSE ZK-EVM ، Kakarot ، Polygon ZK-EVM ، Linea ، Zeth وغيرها الكثير.
يتعلق الجدل الأخير في مساحة EVM ZK-rollup بكيفية التعامل مع الأخطاء المحتملة في كود ZK. حاليا ، كل هذه الأنظمة قيد التشغيل لديها شكل من أشكال آلية "مجلس الأمن" التي تتحكم في نظام التصديق في حالة حدوث أخطاء. وفي العام الماضي، حاولت إنشاء إطار موحد لتشجيع المشاريع على توضيح مستوى ثقتها في نظام إصدار الشهادات، وكذلك في مجلس الأمن، والحد تدريجيا من سلطتها على المنظمة بمرور الوقت.
وفي الأجل المتوسط، قد تعتمد عمليات التجميع على نظم تصديق متعددة، ولن تكون لمجلس الأمن السلطة إلا في الحالات القصوى التي يتباعد فيها نظامان مختلفان للتصديق.
ومع ذلك ، هناك شعور بأن بعض الأعمال تبدو زائدة عن الحاجة. لدينا بالفعل طبقة Ethereum الأساسية ، ولديها EVM ، ولدينا بالفعل آلية عمل للتعامل مع الأخطاء في التنفيذ: إذا كان هناك خطأ ، فسيقوم العميل بالتحديث لإصلاحه ، ثم ستستمر السلسلة في العمل. من وجهة نظر عميل عربات التي تجرها الدواب ، يبدو أن الكتل التي تم الانتهاء منها لن يتم تأكيدها بعد الآن ، ولكن على الأقل لن نرى المستخدمين يخسرون المال. وبالمثل ، إذا أرادت المجموعات فقط الحفاظ على دورها المكافئ ل EVM ، فإنها تحتاج إلى تنفيذ الحوكمة الخاصة بها لتغيير قواعد ZK-EVM الداخلية باستمرار لمطابقة الترقيات إلى طبقة Ethereum الأساسية ، وهو أمر خاطئ لأنها في النهاية مبنية على قمة طبقة Ethereum الأساسية نفسها ، والتي تعرف متى يتم الترقية ووفقا للقواعد الجديدة.
نظرا لأن L2 ZK-EVMs تستخدم بشكل أساسي نفس EVMs تماما مثل Ethereum ، فهل يمكننا بطريقة ما دمج "التحقق من تنفيذ EVM في ZK" في وظيفة البروتوكول والتعامل مع الاستثناءات مثل الأخطاء والترقيات من خلال تطبيق الإجماع الاجتماعي ل Ethereum ، كما نفعل بالفعل مع تطبيق EVM للطبقة الأساسية نفسها؟
هذا موضوع مهم وصعب.
أحد الموضوعات المحتملة للنقاش حول توافر البيانات في ZK-EVM الأصلي هو الحالة. إذا لم تكن ZK-EVMs بحاجة إلى حمل بيانات "شاهد" ، فستكون كفاءة بياناتها أعلى بكثير. أي أنه إذا تمت قراءة جزء معين من البيانات أو كتابته بالفعل في بعض الكتل السابقة ، فيمكننا ببساطة افتراض أن البروفير لديه حق الوصول إليه ولا يتعين عليه إتاحته مرة أخرى. لا يتعلق الأمر فقط بعدم إعادة تحميل التخزين والرمز. اتضح أن ضغط الحالة يمكن أن يوفر ما يصل إلى 3x من البيانات مقارنة بالضغط عديم الحالة إذا قام أحد التراكمات بضغط البيانات بشكل صحيح.
هذا يعني أنه بالنسبة للتجميع المسبق ل ZK-EVM ، لدينا خياران:
يتطلب التجميع المسبق أن تكون جميع البيانات متاحة في نفس القطعة. هذا يعني أن prover يمكن أن يكون عديم الجنسية ، ولكنه يعني أيضا أن استخدام مجموعة ZK المترجمة مسبقا أغلى بكثير من استخدام مجموعة التحديثات مع التعليمات البرمجية المخصصة.
يسمح التحويل البرمجي المسبق للمؤشر بالإشارة إلى البيانات التي تم تنفيذها أو استخدامها أو إنشاؤها مسبقا. هذا يجعل ZK-rollup مثاليا تقريبا ، ولكنه أكثر تعقيدا ويقدم حالة جديدة يجب تخزينها بواسطة prover.
ماذا يمكن أن نتعلم من هذا؟ هناك سبب وجيه لتغليف التحقق من ZK-EVM بطريقة أو بأخرى: تقوم مجموعة التحديثات بالفعل ببناء نسختها المخصصة الخاصة ، و Ethereum على استعداد لتقييم تطبيقاتها المتعددة والإجماع الاجتماعي خارج السلسلة على L1 لتنفيذ EVM ، وهو أمر خاطئ ، لكن L2 الذي يقوم بنفس المهمة بالضبط يجب أن ينفذ أدوات معقدة تشمل مجلس الأمن. ولكن من ناحية أخرى ، هناك مشكلة كبيرة في التفاصيل: هناك إصدارات مختلفة من ZK-EVM ، والتي تختلف في التكلفة والفائدة. التمييز بين عديمي الجنسية وعديمي الجنسية يخدش السطح فقط. قد تؤدي محاولة دعم "almost-EVM" ، الرموز المخصصة التي أثبتتها أنظمة أخرى ، إلى كشف مساحة تصميم أكبر. وبالتالي ، فإن تغليف ZK-EVM يمثل وعدا وتحديات.
** فصل الغلاف والمنشئ (ePBS) **
أدى صعود MEV إلى جعل إنتاج البلوك نشاطا اقتصاديا واسع النطاق ، حيث يستطيع المشاركون المعقدون إنتاج كتل تولد إيرادات أكثر من الخوارزمية الافتراضية ، والتي تراقب ببساطة مجموعة المعاملات وتحتوي عليها. حتى الآن ، حاول مجتمع Ethereum حل هذه المشكلة باستخدام مخطط فصل بين مقدم الاقتراح والبناء خارج البروتوكول مثل MEV-Boost ، والذي يسمح للمدققين المنتظمين ("المقترحين") بالاستعانة بمصادر خارجية لبناء الكتلة للمشاركين المتخصصين ("البناة").
ومع ذلك ، فإن MEV-Boost تضع افتراضات ثقة في فئة جديدة من المشاركين تسمى المرحلات. في العامين الماضيين ، كان هناك العديد من المقترحات لإنشاء "PBS مغلفة". ما هي فوائد هذا؟ في هذه الحالة ، الجواب بسيط: PBS المبني مباشرة مع ميزات البروتوكول أقوى (بمعنى وجود افتراضات ثقة أضعف) من PBS المبني بدونها. هذا مشابه لحالة أوراكل السعر داخل بروتوكول التغليف - على الرغم من أنه في هذه الحالة ، هناك أيضا معارضة قوية.
تغليف تجمع الذاكرة الخاص
عندما يرسل المستخدم معاملة ، تكون عامة ومرئية للجميع على الفور ، حتى قبل تضمينها في السلسلة. وهذا يجعل مستخدمي العديد من التطبيقات عرضة للهجمات الاقتصادية ، مثل المعاملات الوقائية.
في الآونة الأخيرة ، كان هناك عدد من المشاريع المخصصة لإنشاء "mempools خاصة" (أو "mempools مشفرة") التي تقوم بتشفير معاملات المستخدمين حتى يتم قبولها بشكل لا رجعة فيه في كتلة.
ومع ذلك ، تكمن المشكلة في أن مثل هذه المخططات تتطلب نوعا خاصا من التشفير: من أجل منع المستخدمين من إغراق النظام وفك تشفيره أولا ، يجب فك تشفير التشفير تلقائيا بعد قبول المعاملة بالفعل بشكل لا رجعة فيه.
لتحقيق هذا النوع من التشفير ، هناك العديد من تقنيات المقايضة. جون شاربونو قال ذلك بشكل جيد:
تشفير المشغلين المركزيين ، مثل Flashbots Protect.
تشفير Timelock ، والذي يمكن فك تشفيره من قبل أي شخص بعد خطوة حسابية متسلسلة معينة ولا يمكن موازاته ؛
تشفير العتبة ، والثقة في لجنة أغلبية صادقة لفك تشفير البيانات. للحصول على توصيات محددة, راجع مفهوم سلسلة المنارة المغلقة.
الأجهزة الموثوق بها، مثل SGX.
لسوء الحظ ، كل تشفير له نقاط ضعف مختلفة. بينما لكل حل ، هناك مجموعة فرعية من المستخدمين على استعداد للثقة به ، لا يوجد أي من الحلول موثوق بها بما يكفي لقبولها فعليا بواسطة الطبقة 1. لذلك ، على الأقل حتى يتم إتقان تشفير زمن الوصول أو بعض الاختراقات التكنولوجية الأخرى ، يبدو تغليف وظائف التداول المضادة للتقدم في الطبقة 1 اقتراحا صعبا ، حتى لو كانت ميزة قيمة بما يكفي لظهور العديد من حلول التطبيقات.
تخزين السيولة المغلفة
هناك حاجة شائعة لمستخدمي Ethereum DeFi وهي القدرة على استخدام ETH الخاص بهم في وقت واحد للتخزين وكضمان في التطبيقات الأخرى. هناك حاجة شائعة أخرى هي ببساطة للراحة: يريد المستخدمون أن يكونوا قادرين على المشاركة (وحماية مفاتيح التخزين عبر الإنترنت) دون تعقيد تشغيل عقدة وإبقائها دائما على الإنترنت.
حتى الآن ، فإن أبسط "واجهة" تخزين تلبي كلا الاحتياجين هي مجرد رمز ERC 20: قم بتحويل ETH إلى "حصة ETH" ، واحتفظ بها ، وقم بتحويلها مرة أخرى. في الواقع ، بدأ مقدمو خدمات تخزين السيولة مثل Lido و Rocket Pool بالفعل في القيام بذلك. ومع ذلك ، فإن تخزين السيولة لديه بعض آليات المركزية الطبيعية في العمل: يذهب الناس بشكل طبيعي إلى أكبر نسخة من Staking ETH لأنها الأكثر شيوعا وسيولة.
يتطلب كل إصدار من Staking ETH بعض الآليات لتحديد من يمكنه أن يكون مشغل العقدة الأساسي. لا يمكن أن يكون غير محدود ، حيث سينضم المهاجمون إلى الهجوم ويضخمونه بأموال المستخدم. حاليا ، أعلى اثنين هما Lido ، الذي يحتوي على مشغل عقدة القائمة البيضاء DAO ، و Rocket Pool ، والذي يسمح لأي شخص بتشغيل عقدة مع إيداع 8 ETH. وتنطوي الطريقتان على مخاطر مختلفة: يسمح نهج Rocket Pool للمهاجمين بتنفيذ هجمات بنسبة 51٪ على الشبكة ويجبر المستخدمين على دفع معظم التكلفة. أما بالنسبة لنهج DAO ، إذا سيطر رمز تخزين معين ، فإنه ينتج عنه أداة حوكمة واحدة يمكن مهاجمتها تتحكم في جزء كبير من جميع مدققي Ethereum. من المؤكد أن بروتوكولات مثل ليدو لديها بالفعل احتياطات مطبقة ، لكن طبقة الدفاع قد لا تكون كافية.
وعلى المدى القصير، يتمثل أحد الخيارات في تشجيع المشاركين في النظام الإيكولوجي على استخدام مجموعة متنوعة من مقدمي خدمات تخزين السيولة للحد من احتمال حدوث مخاطر نظامية من شركة واحدة. ولكن هذا التوازن محفوف بالمخاطر في الأمد البعيد، ومن الخطورة بمكان أن نعتمد أكثر مما ينبغي على الضغوط الأخلاقية لحل المشاكل. والسؤال الطبيعي الذي يطرح نفسه: هل من المنطقي أن نغلف نوعا من الوظائف في البروتوكول لجعل تخزين السيولة أقل مركزية؟
السؤال الرئيسي هنا هو: ما نوع الوظائف داخل البروتوكول؟ تكمن المشكلة ببساطة في إنشاء رمز "Staking ETH" القابل للاستبدال في البروتوكول في أنه إما يجب أن يكون لديه حوكمة مغلفة على مستوى Ethereum لاختيار من يدير العقد ، أو أنه مفتوح ، ولكن هذا يحولها إلى أداة للمهاجمين.
فكرة مثيرة للاهتمام هي مقالة Dankrad Feist حول تعظيم تخزين السيولة. أولا ، دعنا نعض الرصاصة وإذا تعرضت Ethereum للهجوم بنسبة 51٪ ، فقد تتم مصادرة 5٪ فقط من الهجوم ETH. هذه مقايضة معقولة. مع وجود أكثر من 26 مليون ETH يتم تخزينها حاليا ، فإن ثلث ذلك (حوالي 8 ملايين ETH) من تكلفة الهجوم مفرط ، لا سيما بالنظر إلى عدد الهجمات "خارج النموذج" التي يمكن القيام بها بتكلفة أقل. في الواقع ، تم استكشاف مقايضات مماثلة في اقتراح اللجنة العليا لتنفيذ نهائية الفتحة الواحدة.
إذا قبلنا مصادرة 5٪ فقط من ETH للهجوم ، فلن يتأثر أكثر من 90٪ من ETH المربوط بالمصادرة ، لذلك يمكن استخدامها كرموز تخزين سيولة قابلة للاستبدال داخل البروتوكول ثم استخدامها من قبل تطبيقات أخرى.
المسار مثير للاهتمام. لكنه لا يزال يترك السؤال: ما هو مغلف بالضبط؟ يعمل Rocket Pool بشكل مشابه جدا: يوفر كل مشغل عقدة بعض الأموال ، ويوفر مخزنو السيولة الباقي. يمكننا ببساطة ضبط بعض الثوابت للحد من العقوبة القصوى إلى 2 ETH وستصبح rETH الحالية ل Rocket Pool خالية من المخاطر.
من خلال تعديلات البروتوكول البسيطة ، يمكننا أيضا القيام بأشياء ذكية أخرى. على سبيل المثال ، لنفترض أننا نريد نظاما يحتوي على "طبقتين" من التراص: مشغلي العقد (متطلبات الضمان العالية) والمودعين (لا يوجد حد أدنى لمتطلبات الضمان ويمكنهم الانضمام والمغادرة في أي وقت) ، لكننا ما زلنا نريد منع مركزية مشغلي العقد من خلال تمكين لجنة مودعين عينة عشوائية ، مثل اقتراح قائمة بالمعاملات التي يجب تضمينها (لأسباب مقاومة الرقابة) ، أو التحكم في اختيار الشوكة أثناء التسريبات غير النشطة ، أو طلب توقيع الكتلة. يمكن تحقيق ذلك بطريقة تنفصل بشكل أساسي عن البروتوكول عن طريق تعديل البروتوكول لمطالبة كل مدقق بتوفير (i) مفتاح تخزين عادي ، و (ii) عنوان ETH يمكن استدعاؤه عبر كل فتحة لإخراج مفتاح تخزين ثانوي. سيعطي البروتوكول الطاقة لكلا المفتاحين ، ولكن يمكن ترك آلية اختيار المفتاح الثاني في كل فتحة لبروتوكول تجمع Staking . قد لا يزال من الأفضل تغليف بعض الميزات مباشرة ، ولكن تجدر الإشارة إلى أن مساحة التصميم هذه "تشمل بعض الأشياء وتترك كل شيء آخر للمستخدم".
** تغليف المزيد من التجميعات المسبقة **
المترجمة مسبقا (أو "العقود المترجمة مسبقا") هي عقود Ethereum التي تنفذ عمليات تشفير معقدة ، يتم تنفيذ منطقها أصلا في رمز العميل ، بدلا من رمز العقد الذكي EVM. كان الترميز المسبق حلا وسطا تم تبنيه في بداية تطوير Ethereum: نظرا لأن الحمل الزائد للجهاز الظاهري كان كبيرا جدا بالنسبة لبعض التعليمات البرمجية المعقدة للغاية والمتخصصة للغاية ، يمكننا تنفيذ بعض العمليات الرئيسية في التعليمات البرمجية المحلية التي كانت ذات قيمة للتطبيقات المهمة لجعلها أسرع. اليوم ، يتضمن هذا بشكل أساسي بعض وظائف التجزئة المحددة وعمليات المنحنى الإهليلجي.
يوجد حاليا دفعة لإضافة تجميع مسبق ل secp 256 R1 ، وهو منحنى بيضاوي مختلف قليلا عن secp 256 K1 لحسابات Ethereum الأساسية ، حيث إنه مدعوم جيدا بوحدات الأجهزة الموثوقة ، لذا فإن استخدامه على نطاق واسع يمكن أن يحسن أمان المحفظة. في السنوات الأخيرة ، دفع المجتمع أيضا لإضافة مجموعات مسبقة ل BLS-12-377 و BW 6-761 والاقتران المعمم وميزات أخرى.
الحجة المضادة لهذه الطلبات لمزيد من الملفات المترجمة مسبقا هي أن العديد من التجميعات المسبقة المضافة سابقا (مثل RIPEMD و BLAKE) ينتهي بها الأمر باستخدام أقل بكثير مما كان متوقعا ، ويجب أن نتعلم منها. بدلا من إضافة المزيد من التجميع المسبق لعمليات محددة ، ربما يجب علينا التركيز على نهج ألطف يعتمد على أفكار مثل EVM-MAX ومقترحات SIMD الخاملة ولكن القابلة للاسترداد دائما ، والتي ستمكن تطبيقات EVM من تنفيذ مجموعة واسعة من فئات التعليمات البرمجية بتكلفة أقل. ربما يمكن إزالة التجميع المسبق الحالي الذي نادرا ما يستخدم واستبداله بتنفيذ (أقل كفاءة حتما) لرمز EVM لنفس الوظيفة. ومع ذلك ، لا يزال من الممكن وجود عمليات تشفير محددة ذات قيمة كافية لتسريعها ، لذلك من المنطقي إضافتها على أنها مجمعة مسبقا.
ماذا تعلمنا من كل هذا؟
الرغبة في تغليف أقل قدر ممكن أمر مفهوم وجيد. إنه مستمد من تقليد Unix الفلسفي المتمثل في إنشاء برامج بسيطة يمكن تكييفها بسهولة مع الاحتياجات المختلفة للمستخدمين وتجنب لعنة سخام البرامج. ومع ذلك ، فإن blockchain ليس نظام تشغيل حوسبة شخصية ، ولكنه نظام اجتماعي. هذا يعني أنه من المنطقي تغليف وظائف معينة في البروتوكول.
في كثير من الحالات ، تشبه هذه الأمثلة الأخرى ما نراه في تجريد الحساب. لكننا تعلمنا أيضا بعض الدروس الجديدة:
يمكن أن يساعد التغليف في تجنب خطر المركزية في مكان آخر في المكدس:
في كثير من الأحيان ، يؤدي الحفاظ على الحد الأدنى من البروتوكول الأساسي وبسيطه إلى دفع التعقيد إلى ما هو أبعد من بعض بروتوكولات النظام البيئي. من وجهة نظر يونكس الفلسفية ، هذا جيد. ومع ذلك ، هناك في بعض الأحيان خطر أن النظم الإيكولوجية خارج البروتوكول سوف تتركز ، عادة (ولكن ليس فقط) بسبب ارتفاع التكاليف الثابتة. يمكن أن يقلل التغليف في بعض الأحيان من المركزية الفعلية.
يمكن أن يؤدي تغليف الكثير من المحتوى إلى زيادة عبء الثقة والحوكمة على البروتوكول:
هذا هو موضوع مقال سابق حول "لا تفرط في إجماع Ethereum": إذا كان تغليف وظيفة معينة يضعف نموذج الثقة ويجعل Ethereum ككل أكثر "ذاتية" ، فإنه يضعف حياد Ethereum الموثوق به. في هذه الحالات ، من الأفضل تقديم ميزة محددة كآلية أعلى Ethereum بدلا من محاولة تقديمها إلى Ethereum نفسها. هنا ، تعد تجمعات الذاكرة المشفرة أفضل مثال ، وقد يكون من الصعب بعض الشيء تغليفها ، على الأقل حتى يتحسن تشفير زمن الوصول.
يمكن أن يؤدي التغليف المفرط إلى تعقيد البروتوكول:
تعقيد البروتوكول هو خطر نظامي يمكن زيادته عن طريق إضافة الكثير من الميزات إلى البروتوكول. التجميع المسبق هو أفضل مثال.
على المدى الطويل ، يمكن أن تؤدي وظيفة التغليف إلى نتائج عكسية لأن احتياجات المستخدم لا يمكن التنبؤ بها:
من المحتمل ألا يتم استخدام الميزة التي يعتبرها العديد من الأشخاص مهمة وسيستخدمها العديد من المستخدمين بانتظام في الممارسة العملية.
بالإضافة إلى ذلك ، يظهر تخزين السيولة ، ZK-EVM ، والحالات المجمعة مسبقا إمكانية وجود طريق وسط: الحد الأدنى من التكريس القابل للتطبيق. لا تحتاج البروتوكولات إلى تغليف الوظيفة بأكملها ، ولكن يمكن أن تحتوي على أجزاء محددة تعالج التحديات الرئيسية ، مما يجعل الوظيفة سهلة التنفيذ دون أن تكون بجنون العظمة أو ضيقة جدا. ومن الأمثلة على ذلك ما يلي:
وبدلا من تغليف نظام كامل لرهن السيولة، من الأفضل تغيير قواعد عقوبة الرهان لجعل التعهد بالسيولة غير الموثوق به أكثر جدوى؛
بدلا من تغليف المزيد من المجمعين المسبقين ، قم بتغليف EVM-MAX و / أو SIMD لتسهيل التنفيذ بكفاءة لمجموعة واسعة من فئات التشغيل ؛
يمكن ببساطة تغليف التحقق من EVM بدلا من تغليف مفهوم التجميع بأكمله.
يمكننا توسيع الرسم البياني السابق على النحو التالي:
في بعض الأحيان يكون من المنطقي التفاف شيء ما ، وإزالة التجميع المسبق الذي نادرا ما يستخدم هو مثال. تجريد الحساب ككل ، كما ذكرنا سابقا ، هو أيضا شكل مهم من أشكال إزالة التغليف. إذا أردنا دعم التوافق مع الإصدارات السابقة للمستخدمين الحاليين ، فقد تكون الآلية في الواقع مشابهة بشكل لافت للنظر لتلك التي تقوم بإلغاء تغليف التجميع المسبق: أحد المقترحات هو EIP-5003 ، والذي سيسمح ل EOA بتحويل حساباتها إلى عقود بنفس الوظيفة (أو أفضل).
إن السمات التي يجب إدخالها في البروتوكول والتي يجب تركها لطبقات أخرى من النظام البيئي هي مقايضة معقدة. من المتوقع أن تستمر هذه المقايضة في التحسن بمرور الوقت مع استمرار تحسن فهمنا لاحتياجات المستخدمين والأفكار المتاحة ومجموعات التكنولوجيا.