السؤال: هل يجب أن يكون Ethereum على ما يرام مع تضمين المزيد من الأشياء في البروتوكول؟

المؤلف: فيتاليك بوتيرين

تم إعداده بواسطة: نيان يين سي تانغ، بلانيت ديلي

منذ بداية مشروع إيثريوم، كانت هناك فلسفة قوية تتمثل في محاولة جعل جوهر إيثريوم بسيطًا قدر الإمكان، وتحقيق ذلك قدر الإمكان من خلال بناء بروتوكولات فوقه. في مجال blockchain، غالبًا ما يُنظر إلى النقاش حول "البناء على L1" مقابل "التركيز على L2" على أنه يدور في المقام الأول حول التوسع، ولكن في الواقع، هناك مشكلات مماثلة في تلبية احتياجات العديد من مستخدمي Ethereum: تبادل الأصول الرقمية، والخصوصية. وأسماء المستخدمين والتشفير المتقدم وأمن الحساب ومقاومة الرقابة والحماية الأمامية والمزيد. ومع ذلك، كانت هناك بعض المحاولات الحذرة الأخيرة لتضمين المزيد من هذه الميزات في بروتوكول إيثريوم الأساسي.

ستستعرض هذه المقالة بعض الاستدلالات الفلسفية خلف فلسفة التغليف الأدنى (minimal enshrinement) الأصلية، وكذلك بعض الأفكار الحديثة حول هذه المسائل. والهدف هو بدء بناء إطار لتحديد ما قد تكون عليه الأهداف التي يستحق فيها تغليف بعض الخصائص داخل البروتوكول.

الفلسفة المبكرة حول حداثة/بساطة البروتوكول (protocol minimalism)

في التاريخ المبكر الذي كان يُعرف آنذاك باسم “Ethereum 2.0”، كان هناك رغبة قوية في إنشاء بروتوكول نظيف وبسيط وجميل، يحاول قدر الإمكان ألا يبني داخل ذاته معظم الأشياء، ويترك تقريبًا كل هذا العمل للمستخدمين. وبشكل مثالي، يكون البروتوكول مجرد آلة افتراضية، وأن يكون التحقق من بلوك مجرد استدعاء إلى آلة افتراضية.

هذه إعادة بناء تقريبية لما رسمته أنا وGavin Gavin Wood على لوحة في مطلع 2015، عندما كنت أتحدث عن شكل Ethereum 2.0.

سيكون “دالة انتقال الحالة” (دالة معالجة البلوكات) مجرد استدعاء واحد لآلة افتراضية، وستحدث بقية المنطق عبر العقود: بعض العقود على مستوى النظام، لكن في الغالب عبر العقود التي يزوّدها المستخدم. إحدى ميزات هذا النموذج الرائعة هي أنه حتى hard fork كامل يمكن وصفه كمعاملة مفردة لعقد معالج البلوكات، ستتم الموافقة عليها عبر حوكمة خارجية أو على السلسلة، ثم يتم تشغيلها بصلاحيات ترقية.

تتعلق هذه المناقشات من عام 2015 بشكل خاص بمحورين ننظر إليهما: تجريد الحسابات والتوسع (scaling). في حالة التوسع، كانت الفكرة محاولة إنشاء شكل أقصى من التجريد للتوسع، تشبه الامتداد الطبيعي للمخطط أعلاه. يمكن للعقود استدعاء أغلب البيانات غير المخزنة لدى معظم عقد Ethereum، وسيكتشف البروتوكول ذلك، ثم يحل الاستدعاء عبر نوع عام جدًا من وظائف الحوسبة الموسعة. ومن منظور الجهاز الافتراضي، سيسقط هذا الاستدعاء في نظام فرعي مستقل، ثم بعد فترة “يعود بشكل سحري” بالنتيجة الصحيحة.

قمنا باستكشاف هذه الفكرة بشكل سريع، لكن تراجعنا بسرعة لأننا كنا نركز كثيرًا على فكرة أن أي نوع من توسعة السلسلة قابل للتحقق بأي شكل. ومع أننا سنرى لاحقًا أن الجمع بين أخذ عينات من توفر البيانات وZK-EVM يعني أن مستقبل توسعة Ethereum يبدو قريبًا جدًا من هذا الرؤية! من ناحية أخرى، بالنسبة لتجريد الحسابات، عرفنا منذ البداية أن هناك نوعًا من التنفيذ الممكن؛ لذلك بدأ البحث فورًا بمحاولة تحويل “مجرد أن تكون المعاملة استدعاء” كنقطة انطلاق صافية قدر الإمكان إلى واقع.

عند التعامل مع المعاملات وإخراج استدعاء EVM فعلي في الطبقة السفلى من عنوان المرسل، يظهر الكثير من التعليمات المتكررة (boilerplate)، ثم يظهر المزيد من التعليمات المتكررة بعد ذلك. كيف يمكننا تقليل هذه الشيفرة قدر الإمكان إلى ما يقارب الصفر؟

أحد أهم قطع الكود هنا هو validate_transaction(state, tx)، وهو مسؤول عن التحقق من أن nonce وتوقيع المعاملة صحيحان. ومنذ البداية، كانت النية الفعلية وراء تجريد الحسابات هي السماح للمستخدم باستبدال منطق التحقق الأساسي غير التزايدي وECDSA بمنطقه الخاص؛ وبذلك يصبح من الأسهل على المستخدمين استخدام ميزات مثل الاسترداد الاجتماعي ومحافظ متعددة التوقيع. لذلك، فإن إيجاد طريقة لإعادة هيكلة apply_transaction لتصبح مجرد استدعاء EVM بسيط ليس مجرد مهمة “لتكون الشيفرة نظيفة لمجرد كونها نظيفة”؛ بل هو نقل المنطق إلى كود حساب المستخدم، وتزويد المستخدم بالمرونة التي يحتاجها.

ومع ذلك، فإن الإصرار على أن تحتوي apply_transaction على أقل منطق ثابت ممكن في النهاية قاد إلى تحديات كثيرة. يمكننا إلقاء نظرة على واحدة من أقدم مقترحات تجريد الحسابات: EIP-86.

إذا تم تضمين EIP-86 كما هو، فسوف يقلل من تعقيد EVM، لكن على حساب زيادة كبيرة في تعقيد بقية أجزاء مكدس Ethereum. سيتطلب ذلك كتابة كود جوهريًا مطابق في مكان آخر، بالإضافة إلى إدخال فئة غريبة جديدة تمامًا؛ مثلًا: قد تظهر نفس المعاملة عدة مرات على السلسلة بقيمة تجزئة نفسها، ناهيك عن مشاكل التعطل المتعدد (multi-failures).

مشاكل التعطل المتعددة في تجريد الحسابات. معاملة واحدة مضمنة على السلسلة قد تجعل آلاف المعاملات الأخرى في الـ mempool غير صالحة، مما يجعل الـ mempool عرضة للإغراق الرخيص.

منذ ذلك الحين، تطور تجريد الحسابات على مراحل. أصبح EIP-86 لاحقًا EIP-208، ثم ظهر في النهاية EIP-2938 القابل للتطبيق فعليًا.

ومع ذلك، فإن EIP-2938 ليس على الإطلاق مقتضبًا. يشمل محتواه:

• نوع معاملات جديدة

• ثلاثة متغيرات عالمية لنطاقات معاملات جديدة

• عمليتان جديدتان من opcodes، بما في ذلك opcode غير عملي (guilty) جدًا لـ PAYgas لمعالجة فحص أسعار الغاز وحدود الغاز، كنقاط توقف (breakpoints) أثناء تنفيذ EVM، وتخزين مؤقت للـ ETH لدفع الرسوم مرة واحدة

• مجموعة من استراتيجيات التعدين والترحيل المعقدة، بما في ذلك قائمة من opcodes التي يُحظر استخدامها في مرحلة التحقق من المعاملة

لتحقيق تجريد الحسابات دون إشراك مطوري نواة Ethereum (المركزين على تحسين عميل Ethereum وتحقيق الـ merge)، تمت إعادة هيكلة EIP-2938 في النهاية ليصبح بالكامل ERC-4337 خارج البروتوكول.

ERC-4337. نعم، يعتمد بالكامل على استدعاءات EVM!

بما أنه ERC، فلا يتطلب hard fork، وهو موجود تقنيًا في “خارج بروتوكول Ethereum”. لذا… هل انتهت المشكلة؟ اتضح أنه ليس كذلك. تتضمن خارطة الطريق الحالية متوسطة المدى لـ ERC-4337 في الواقع تحويل معظم ERC-4337 إلى سلسلة من وظائف داخل البروتوكول. وهذا مثال مفيد لفهم لماذا قد نحتاج للنظر في هذه المسار.

تغليف ERC-4337

هناك عدة أسباب محورية لمناقشة إعادة إدخال ERC-4337 إلى البروتوكول في النهاية:

كفاءة gas: أي عملية يتم تنفيذها داخل EVM ستؤدي إلى نوع من تكاليف الماكينة الافتراضية، بما في ذلك حالات عدم الكفاءة عند استخدام ميزات مكلفة مثل مخازن التخزين. حاليًا، تجمع هذه الإضافات غير الكفؤة ما لا يقل عن 20,000 gas، وربما أكثر. إن وضع هذه المكونات داخل البروتوكول هو أبسط طريقة لإزالة هذه المشكلات.

مخاطر أخطاء في الكود: إذا احتوى عقد “Entry Point” في ERC-4337 على خطأ كارثي بما يكفي، فقد يرى كل محفظات متوافقة مع ERC-4337 أن كل أموالهم قد نضبت. إن استبدال وظيفة داخل البروتوكول بمثل هذا العقد يولّد مسؤولية ضمنية: إصلاح أخطاء الكود عبر hard fork بحيث يتم القضاء على مخاطر نضوب أموال المستخدمين.

يدعم عمليات EVM مثل txt.origin. يجعل ERC-4337 نفسه txt.origin يعود إلى عنوان “bundler” الذي يقوم بتجميع مجموعة من عمليات المستخدم داخل معاملة. يمكن للتجريد الأصلي للحسابات حل هذه المشكلة عبر جعل txt.origin يشير إلى الحساب الفعلي الذي يقوم بإرسال المعاملة، بحيث يعمل بالطريقة نفسها التي تعمل بها EOA.

مقاومة الرقابة: إحدى تحديات فصل المقترح/البنّاء هي أن رقابة معاملة واحدة تصبح أسهل. في عالم يمكن لبروتوكول Ethereum فيه التعرف على المعاملات الفردية، يمكن لقائمة الإدراج أن تخفف هذه المشكلة بشكل كبير: فهي تسمح للمقترح بتحديد قائمة المعاملات التي يجب إدراجها في اثنين من الفتحات القادمة في معظم الحالات. لكن ERC-4337 خارج البروتوكول يقوم بتغليف “User Operations” داخل معاملة واحدة، مما يجعل User Operations غير شفافة لبروتوكول Ethereum؛ وبالتالي فإن قائمة الإدراج التي يوفرها بروتوكول Ethereum لن تتمكن من تقديم مقاومة للرقابة لـ ERC-4337 User Operations. إن تغليف ERC-4337 وجعل User Operations نوعًا “مناسبًا” من المعاملات سيحل هذه المشكلة.

ومن الجدير بالذكر أنه في صورته الحالية، يعد ERC-4337 أغلى بكثير من معاملات Ethereum “الأساسية”: تكلفة المعاملة هي 21,000 gas، بينما تكلفة ERC-4337 تقارب 42,000 gas.

نظريًا، كان يجب أن يكون بالإمكان ضبط نظام كلفة غاز EVM حتى تتطابق تكلفة التخزين داخل البروتوكول وتكلفة الوصول إلى التخزين خارج البروتوكول؛ لذلك، عندما تصبح عمليات تعديل التخزين الأخرى أرخص، لا يوجد سبب يدعو لقيام نقل ETH بدفع 9000 gas. في الواقع، يحاول EIPان المرتبطان بتحويل Verkle tree القادم فعليًا القيام بذلك. لكن حتى لو فعلنا ذلك، يوجد سبب واضح يشرح لماذا سيكون من المستحيل تقريبًا أن تكون وظائف التغليف داخل البروتوكول أرخص بكثير من كود EVM بغض النظر عن مدى كفاءة EVM: كود التغليف لا يحتاج إلى دفع gas للـ preloading.

توضح الميزات الكاملة لمحفظة ERC-4337 حجمًا كبيرًا، إذ إن هذا التنفيذ الذي تقوم بتجميعه ووضعه على السلسلة يشغل حوالي 12,800 بايت. وبالطبع، يمكنك نشر هذا الجزء من الكود مرة واحدة واستخدام DELEGATECALL لتمكين كل محفظة منفردة من استدعائه، لكنك ستظل بحاجة إلى الوصول إلى هذا الكود في كل بلوك تستخدمه. في ظل تكاليف gas في شجرة Verkle وفق EIP، ستشكل 12,800 بايت 413 chunk، وسيستلزم الوصول إلى هذه الـ chunks دفع 2× witness branch_cost (إجمالي 3,800 gas) و413× witness chunk_cost (إجمالي 82,600 gas). وهذا حتى قبل أن نبدأ بالحديث عن نقطة دخول ERC-4337 نفسها: ففي الإصدار 0.6.0، يوجد على السلسلة 23,689 بايت (وفق قواعد Verkle tree EIP، ما يقارب 158,700 gas للتحميل).

وهذا يؤدي إلى مشكلة: يجب أن يتم توزيع تكلفة gas اللازمة للوصول فعليًا إلى هذه الكودات بطريقة ما ضمن المعاملة. الطريقة الحالية المستخدمة في ERC-4337 ليست جيدة: المعاملة الأولى داخل الـ bundle تستهلك تكلفة التخزين/قراءة الكود لمرة واحدة (one-off), ما يجعلها أغلى بكثير من باقي المعاملات. إن تغليف المكتبات المشتركة داخل البروتوكول سيسمح بأن تصبح هذه المكتبات جزءًا من البروتوكول، وسيتمكن الجميع من الوصول إليها مجانًا.

ماذا يمكننا أن نتعلم من هذا المثال، ومتى يصبح التغليف (encapsulation) أكثر عمومية؟

في هذا المثال، رأينا بعض المبادئ الأساسية المختلفة لتغليف تجريد الحسابات داخل البروتوكول.

عندما تكون التكاليف الثابتة مرتفعة، فإن الطرق المبنية على السوق والتي “تدفع التعقيد إلى الحافة” هي الأكثر عرضة للفشل. وبالفعل، يبدو أن خارطة طريق تجريد الحسابات على المدى الطويل تتضمن الكثير من التكاليف الثابتة لكل بلوك: 244,100 gas لتحميل كود المحافظ القياسي شيء واحد؛ لكن التجميع (aggregation) قد يضيف عشرات أو مئات الآلاف من gas للتحقق من ZK-SNARK، بالإضافة إلى تكلفة التحقق على السلسلة. لا توجد طريقة لفرض هذه التكاليف على المستخدمين دون إدخال كميات كبيرة من عدم الكفاءة المنبثقة عن السوق. أما تحويل بعض هذه الوظائف إلى وظائف داخل البروتوكول يمكن للجميع الوصول إليها مجانًا، فيحل المشكلة بشكل ممتاز.

استجابة المجتمع لأخطاء الكود. إذا كان مقطع كود ما مستخدمًا من قبل جميع المستخدمين أو من قبل شريحة واسعة جدًا منهم، فعادة يكون من المنطقي أكثر أن يتحمل مجتمع البلوكشين مسؤولية الـ hard fork لإصلاح أي خطأ يظهر. يُدخل ERC-4337 كمية كبيرة من الكود المشترك عالميًا؛ وعلى المدى الطويل، فإن إصلاح الأخطاء عبر hard fork يكون بلا شك أكثر عقلانية من التسبب في خسارة المستخدمين لكمية كبيرة من ETH.

أحيانًا يمكن تحقيق شكله الأقوى عبر الاستفادة مباشرة من وظائف البروتوكول. المثال الأساسي هنا هو وظائف مقاومة الرقابة داخل البروتوكول، مثل قائمة الإدراج (inclusion list): يمكن لقائمة الإدراج داخل البروتوكول أن تضمن مقاومة الرقابة بشكل أفضل من الأساليب خارج البروتوكول، لأنه لكي يستفيد المستخدمون من قائمة الإدراج بشكل حقيقي، يجب أن تكون عملية المستخدم قابلة للقراءة (“易读”) من البروتوكول. مثال آخر أقل شهرة: تصميم إثبات الحصة في Ethereum في عصر 2017 كان يقوم بتجريد حساب لمفاتيح الحصة، وتم التخلي عنه لصالح دعم تجريد عبر تغليف BLS، لأن BLS يدعم آلية “تجميع” يجب تنفيذها على مستوى البروتوكول والشبكة، مما يمكن أن يجعل التعامل مع عدد كبير من التواقيع أكثر كفاءة.

لكن من المهم أن نتذكر: مقارنة بالواقع، فإن حتى تغليف تجريد الحسابات داخل البروتوكول لا يزال يُعد شكلاً كبيرًا من “إزالة التغليف” (de-enshrinement). في الوقت الحالي، لا يمكن للمعاملات الأعلى في Ethereum إلا أن تبدأ من حسابات يملكها أشخاص (EOA)، وتتحقق باستخدام توقيع ECDSA على منحنى secp256k1 واحد. تجريد الحسابات يلغي ذلك ويترك شروط التحقق للمستخدم لتعريفها بنفسه. لذلك، في هذه القصة عن تجريد الحسابات، نرى أيضًا أقوى سبب ضد التغليف: المرونة في تلبية احتياجات المستخدمين المختلفين.

لنُكمل هذا السرد بمراجعة أمثلة لعدة خصائص أخرى تم التفكير في تضمينها مؤخرًا. وسنركز بشكل خاص على: ZK-EVM، وفصل المقترح-البنّاء (proposer-builder separation)، والمخازن الخاصة، والـ liquid staking، وعمليات ما قبل الترجمة (new precompiles).

تغليف ZK-EVM

لنحوّل الانتباه إلى هدف تغليف محتمل آخر داخل بروتوكول Ethereum: ZK-EVM. حاليًا لدينا عدد كبير من ZK-rollup، وكلها يجب أن تكتب كودًا متشابهًا جدًا للتحقق من تنفيذ يشبه تنفيذ كتل Ethereum داخل ZK-SNARK. وهناك نظام بيئي مستقل متنوع من التنفيذ: PSE ZK-EVM وKakarot وPolygon ZK-EVM وLinea وZeth وغيرها.

كان هناك جدل حديث في مجال EVM ZK-rollup يتعلق بكيفية التعامل مع الأخطاء المحتملة في كود ZK. حاليًا، تمتلك كل هذه الأنظمة قيد التشغيل نوعًا من آلية “مجلس الأمان” يمكنه التحكم في نظام الإثبات في حال ظهور bug. في العام الماضي، حاولت إنشاء إطار معياري لتشجيع المشاريع على توضيح مستوى الثقة لديهم في نظام الإثبات، وكذلك مستوى الثقة في مجلس الأمان، وتقليل تدريجي لسلطة هذه الجهة مع مرور الوقت.

على المدى المتوسط، قد يعتمد الـ rollup على أنظمة إثبات متعددة، ولا يملك مجلس الأمان الصلاحية إلا في الحالة القصوى عندما يقع خلاف بين نظامين إثبات مختلفين.

ومع ذلك، هناك شعور بأن بعض هذا العمل يبدو زائدًا عن الحاجة. لدينا طبقة أساس في Ethereum بالفعل، وبها EVM، ولدينا آلية لمعالجة أخطاء التنفيذ: إذا ظهرت أخطاء، سيقوم العميل بتحديث لإصلاحها، ثم تستمر السلسلة. ومن منظور عميل يحتوي على أخطاء، يبدو أن البلوكات التي كانت قد تأكدت بالفعل لن تُؤكد بعد الآن، لكن على الأقل لن نرى خسارة المستخدمين لأموالهم. وبالمثل، إذا أراد rollup فقط أن يحقق نفس التأثير مثل EVM، فسيتوجب عليهم تنفيذ حوكمتهم الخاصة لتغيير قواعد ZK-EVM الداخلية باستمرار بما يتوافق مع ترقية الطبقة الأساسية لإيثيريوم؛ ويبدو هذا خطأً لأنهم في النهاية يبنون فوق الطبقة الأساسية لإيثيريوم نفسها، والتي تعرف متى يتم الترقي وكيف تُطبق القواعد الجديدة.

بما أن L2 ZK-EVM هذه تستخدم في الأساس EVM مطابقًا تمامًا لإيثيريوم، فهل يمكننا بطريقة ما تضمين “التحقق من تنفيذ EVM داخل ZK” كوظيفة داخل البروتوكول، ومعالجة الحالات الشاذة مثل الأخطاء والترقيات عبر تطبيق الإجماع الاجتماعي لإيثيريوم، تمامًا كما نفعل بالفعل مع تنفيذ EVM في الطبقة الأساسية؟

هذا موضوع مهم ومليء بالتحديات.

قد تكون إحدى نقاط الجدل بشأن قابلية توفر البيانات في ZK-EVM الأصلي هي حالة “الـ statefulness”. إذا لم تكن ZK-EVM بحاجة إلى حمل بيانات “witness”، فستكون كفاءتها في البيانات أعلى بكثير. أي أنه إذا كانت بعض البيانات قد تم قراءتها أو كتابتها في بلوك سابق ما، يمكننا افتراض أن الـ prover يمتلك إمكانية الوصول إليها، دون الحاجة لجعلها متاحة مرة أخرى. ليس الأمر مجرد عدم إعادة تحميل التخزين والكود؛ اتضح أن rollup إذا ضغط البيانات بشكل صحيح، يمكن أن يوفر compression حالية حتى 3 أضعاف مقارنة بالـ stateless compression.

وهذا يعني أنه بالنسبة لـ ZK-EVM precompile لدينا خياران:

1. تتطلب precompiles توفر كل البيانات في نفس البلوك. وهذا يعني أن الـ prover يمكن أن يكون بلا حالة (stateless)، لكنه يعني أيضًا أن ZK-rollup التي تستخدم هذه precompiles تكون أغلى بكثير من rollup التي تستخدم كودًا مخصصًا.

2. تُمكّن precompiles المؤشر من الإشارة إلى البيانات التي تم استخدامها أو إنشاؤها سابقًا. هذا يجعل ZK-rollup قريبًا من الأمثل، لكنه أكثر تعقيدًا، ويقدم حالة جديدة يجب أن يخزنها الـ prover.

ماذا يمكننا أن نتعلم؟ يوجد سبب جيد لتغليف تحقق ZK-EVM بطريقة ما: فالـ rollup بالفعل يبني نسخته المخصصة، وإيثيريوم على استعداد لوضع أوزان تنفيذ EVM الخاصة به—مع العديد من تطبيقاته وإجماعها الاجتماعي خارج السلسلة—لتنفيذ EVM على L1. وهذا يبدو خطأً، لكن أن تقوم L2 بعمل الشيء نفسه تمامًا يجب تنفيذها مع أدوات صغيرة معقدة تتضمن مجلس الأمان. من جهة أخرى، توجد مشكلة كبيرة في التفاصيل: هناك نسخ مختلفة من ZK-EVM، وتكاليفها وفوائدها مختلفة. والتمييز بين stateful وstateless يلامس السطح فقط؛ فمحاولة دعم “قريب من EVM (almost-EVM)” —أي أن هذه الشيفرات المخصصة التي أثبتت أن أنظمة أخرى لا بأس بها —قد تكشف عن مساحة تصميم أكبر. لذا فإن تغليف ZK-EVM يجلب الأمل والتحديات معًا.

فصل المقترح والبنّاء داخل/من ePBS

أدى ظهور MEV إلى جعل إنتاج البلوكات نشاطًا اقتصاديًا واسع النطاق، حيث يستطيع مشاركون معقدون إنتاج بلوكات تحقق إيرادات أكثر من خوارزمية افتراضية تراقب الـ mempool وتضم معاملات فقط. حتى الآن، حاول مجتمع Ethereum معالجة ذلك باستخدام حلول مثل MEV- Boost Boost BOOST هو منصة تطبيقات لا مركزية تهدف إلى تحسين التجربة عبر زيادة وظائف الأدوات الموجودة وجعلها أكثر متانة. BOOST هو توكن عملي أصلي (native utility token) لمعالجة المدفوعات لفك فتح وظائف متقدمة وقابلة للترقية، ولأصوات مستقبلية في نشاطات الحوكمة، ولفتح وظائف منتجات مستقبلية. وتشمل منتجات BOOST القادمة BoostSWAP وBoostFARM وBoostNFT. ستقوم هذه المنتجات بابتكار سيُحسن بنية DeFi التحتية الحالية ويساعد على توسيع مجتمع الإنترنت اللامركزي. تم إطلاق BOOST Coin في 9 أغسطس 2021، مع وجود 1 مليار توكن في التداول. يمكن تداول Boost حاليًا على Uniswap وسيصبح متاحًا قريبًا على BoostSwap. راجع المزيد. مثل حلول فصل المقترح والبنّاء خارج البروتوكول (proposer-builder separation)، والتي تعالج المشكلة عبر السماح للمتحققين العاديين (“المقترحين”) بإسناد بناء البلوك إلى مشاركين متخصصين (“البنّائين”).

ومع ذلك، يقوم MEV-Boost على افتراض ثقة جديد في فئة مشاركين جديدة، تسمى relay (المرحل). في السنتين الماضيتين، اقترح كثيرون إنشاء “PBS مُغلّف” (encapsulated PBS). ما فائدة ذلك؟ في هذا السياق، تكون الإجابة بسيطة جدًا: PBS التي يتم بناؤها مباشرة باستخدام وظائف البروتوكول ستكون أقوى من PBS التي لا تستخدمها (بمعنى وجود افتراضات ثقة أضعف). وهذا يشبه حالة تغليف مخبر/متنبئ الأسعار داخل البروتوكول—مع وجود معارضة قوية حتى في تلك الحالة.

تغليف مخازن ذاكرة خاصة

عندما يرسل المستخدم معاملة، تصبح تلك المعاملة معلنة فورًا ومكشوفة للجميع، حتى قبل تضمينها على السلسلة. هذا يجعل العديد من التطبيقات عرضة لهجمات اقتصادية على المستخدمين، مثل هجمات السبق (front-running).

في الآونة الأخيرة، ظهرت العديد من المشاريع التي تركز على إنشاء “مخازن ذاكرة خاصة” (أو “مخازن ذاكرة مشفرة”) تقوم بتشفير معاملات المستخدمين حتى يتم قبولها قبولًا لا رجعة فيه داخل بلوك.

لكن المشكلة هي أن هذا يتطلب تشفيرًا خاصًا: لمنع المستخدمين من التدفق إلى النظام وفك التشفير أولًا، يجب أن يتم فك التشفير تلقائيًا بعد قبول المعاملة قبولًا لا رجعة فيه بالفعل.

لتحقيق هذا الشكل من التشفير، توجد تقنيات مختلفة بمقايضات متنوعة. وقد وصف Jon Charbonneau ذلك جيدًا:

تشفير للمشغلين المركزيين، مثل Flashbots Flashbots Flashbots هي شركة بحث وتطوير متخصصة في استخراج القيمة القابلة للاستخراج من الـ MEV (MEV) تهدف إلى تقليل الآثار الخارجية السلبية والمخاطر الناتجة عن MEV على سلاسل بلوكشين العقود الذكية. راجع المزيد Protect.

تشفير مع قفل زمني: بعد المرور بخطوات حسابية مرتبة وفق تسلسل معيّن، يمكن لأي شخص فك التشفير، ولا يمكن إجراء ذلك بالتوازي؛

تشفير عتبي (threshold encryption): الثقة في أغلبية صادقة لفك تشفير البيانات. راجع مفهوم الـ beacon chain المغلق لمعرفة توصيات مفصلة.

عتاد موثوق، مثل SGX.

للأسف، لكل شكل من أشكال التشفير نقاط ضعف مختلفة. ورغم أن جزءًا من المستخدمين لكل حل مستعد للثقة فيه، لا يوجد حل تبلغ فيه درجة الثقة به القدر الكافي لقبوله فعليًا على Layer1. لذلك، على الأقل حتى يتم إتقان التشفير المتأخر أو حدوث اختراق تقني آخر، يبدو أن تغليف وظيفة مقاومة anti-front-running على Layer1 طرحٌ صعب، حتى لو كانت وظيفة قيّمة؛ إذ ظهرت حلول لتطبيقات كثيرة بالفعل.

تغليف الـ liquid staking

من الاحتياجات المشتركة لمستخدمي DeFi على Ethereum القدرة على استخدام ETH الخاصة بهم في نفس الوقت للرهان وكضمان (collateral) في تطبيقات أخرى. وهناك حاجة شائعة أخرى بسيطة: يريد المستخدمون إمكانية الرهان دون تشغيل عقد (node) مع إبقاءه متصلًا دائمًا، ومن دون تعقيدات إدارة هذا الاتصال (وبالذات حماية مفاتيح الرهان على الخط).

حتى الآن، فإن أبسط واجهة Staking تحقق هاتين الحاجتين هي مجرد رمز ERC20: تحويل ETH إلى “stETH”، الاحتفاظ به، ثم تحويله مرة أخرى. والواقع أن Lido Lido Lido هو حل لتقديم Staking بسيولة (liquidity pool staking). يتيح Lido للمستخدمين المراهنة على سلاسل PoS بطريقة عائد مركب (compounding)، بينما يشاركون في أنشطة على السلسلة (مثل الإقراض والاقتراض والتداول) دون الحاجة إلى حد أدنى للإيداع أو صيانة للبنية التحتية. حاليًا، مدعوم ETH2.0 وTerra وSolana، وقد يتم توسيع ذلك إلى سلاسل PoS أخرى مستقبلًا. راجع المزيد و Rocket Rocket Rocket (ROCKET) هي عملة مشفرة تم إطلاقها في 2021 وتعمل على منصة BNB Smart Chain (BEP20). راجع المزيد Pool Pool تدعم تمكين الأشخاص العاديين من الربح من البيانات ومشاركة البيانات عبر المنظمات. راجع المزيد. وقد بدأت بالفعل بعض مزودي السيولة في ذلك. ومع ذلك، هناك آليات مركزية طبيعية تعمل في الـ liquid staking: يميل الناس إلى الدخول في أكبر إصدار من stETH لأنه الأكثر دراية والأكثر سيولة.

كل إصدار من staked ETH يحتاج إلى بعض الآليات لتحديد من يمكنه أن يكون مشغل عقد الطبقة الأساسية. لا يمكن أن يكون ذلك غير محدود لأن المهاجمين سينضمون ويستغلون أموال المستخدمين لتكبير الهجوم. حاليًا، في المرتبة الأولى جرت العادة أن يكون الاثنان هما Lido و Rocket Pool Rocket Pool RocketPool هي خدمة بنية تحتية لـ Ethereum PoS. يمكن لأي فرد أو منظمة يرغب في الحصول على فائدة من الرهن الدوري للـ Ethereum المشاركة عبر تشغيل شبكة عقد RocketPool اللامركزية. راجع المزيد. بينما تملك الأولى قوائم DAO البيضاء لمشغلي العقد، تسمح الثانية لأي شخص بتشغيل عقد عند إيداع 8 ETH. كلتا الطريقتين لهما مخاطر مختلفة: تسمح طريقة Rocket Pool للمهاجمين بشن هجوم 51% على الشبكة وإجبار المستخدمين على دفع معظم التكلفة. أما طريقة DAO، فإذا سيطر رمز رهن معين، فقد يؤدي ذلك إلى سيطرة “أداة حوكمة” واحدة—قد تكون قابلة للهجوم—على جزء كبير من مدققي Ethereum. بالطبع، قامت بروتوكولات مثل Lido بالفعل بتنفيذ إجراءات حماية، لكن طبقة واحدة من الدفاع قد لا تكون كافية.

على المدى القصير، أحد الخيارات هو تشجيع المشاركين في النظام البيئي على استخدام مزودين متنوعين للـ liquid staking لتقليل احتمال أن يؤدي الاعتماد على طرف واحد إلى مخاطر نظامية. ومع ذلك، على المدى الطويل، هذا توازن غير مستقر؛ والاعتماد المفرط على الضغط الأخلاقي لحل المشكلة أمر خطير. وينشأ سؤال طبيعي: هل من المفيد تغليف وظيفة ما داخل البروتوكول لتجعل الـ liquid staking أقل مركزية؟

السؤال الحاسم هنا هو: ما هي الوظيفة داخل البروتوكول؟ إن إنشاء رمز “staked ETH” قابل للاستبدال داخل البروتوكول يطرح مشكلة، وهي أنه يجب أن يكون له تغليف (wrapper) لاختيار من يشغّل العقد (عبر حوكمة ضمن نطاق Ethereum) أو أن يكون مفتوحًا، لكن ذلك يجعله أداة بيد المهاجمين.

فكرة ممتعة هي مقالة Dankrad Feist حول تعظيم الـ liquid staking. أولًا، نعض على الجرح: إذا تعرضت Ethereum لهجوم بنسبة 51%، فقد يُعاقَب/يُسحب فقط 5% من ETH التي تم التهاجم بها. هذا توازن معقول. حاليًا يوجد أكثر من 26 مليون ETH مُرهَن، وثلثه تقريبًا (حوالي 8 ملايين ETH) تكون تكلفة مهاجمته “مبالغًا فيها”، خصوصًا إذا أخذنا في الاعتبار عدد أنواع الهجمات خارج النماذج (model out) التي يمكن تنفيذها بتكلفة أقل. في الواقع، تمت مناقشة توازنات مشابهة في مقترحات “المجلس الفائق” الخاصة بتنفيذ single-slot finality.

إذا قبلنا أن 5% فقط من ETH ستتعرّض للجزاء، فلن يتأثر أكثر من 90% من ETH المُرهَن بالجزاء، وبالتالي يمكن استخدامها كـ liquid staking قابلة للاستبدال داخل البروتوكول ثم تُستخدمها تطبيقات أخرى.

تلك المسار مثير للاهتمام. لكنه يترك سؤالًا: ما الذي سيتم تغليفه تحديدًا؟ أسلوب Rocket Pool يشبه هذا جدًا: كل مشغل عقد يقدّم بعض التمويل، ويقدّم رهان السيولة التمويل المتبقي. يمكننا ببساطة تعديل بعض الثوابت بحيث يصبح أقصى عقوبة مصادرة 2 ETH، عندها ستصبح rETH الحالية لـ Rocket Pool بلا مخاطر.

من خلال تعديل بروتوكول بسيط، يمكننا أيضًا القيام بأشياء أذكى. على سبيل المثال، افترض أننا نريد نظامًا به نوعان من “الرهان”: مشغلو العقد (مع متطلبات رهان عالية) وحاملو الرصيد/المودعون (لا توجد متطلبات حد أدنى للرهان، ويمكنهم الانضمام والخروج في أي وقت). ومع ذلك نريد منع مركزية مشغلي العقد عبر منح لجنة من الحَمَلة بصلاحية عبر عينات عشوائية—مثل اقتراح قوائم معاملات (لأسباب مقاومة الرقابة)، والتحكم في اختيار التفرع أثناء فترات التسريب/عدم النشاط، أو ضرورة التوقيع على بلوك. يمكن تحقيق ذلك بطريقة شبه منفصلة عن البروتوكول: عبر تعديل البروتوكول بحيث يطلب من كل مدقق توفير (i) مفتاح رهان عادي (ii) وعنوان ETH يمكن استدعاؤه في كل فتحة (slot) لإخراج مفتاح رهان ثانوي. يمنح البروتوكول لهذين المفتاحين السلطة، لكن آلية اختيار المفتاح الثاني في كل فتحة يمكن تركها لبروتوكول مجمّع الرهان (staking pool). قد يكون تغليف بعض الوظائف مباشرة أفضل، لكن من الجدير بالذكر أن مساحة تصميم “تغليف بعض الأشياء وإسناد الأشياء الأخرى للمستخدمين” موجودة فعلاً.

تغليف المزيد من precompiles

precompile (أو “عقد precompiled”) هو عقد في Ethereum ينفذ عمليات تشفير معقدة، ويكون منطقها مُضمَّنًا أصلاً في كود العميل بدلًا من كود عقد ذكي داخل EVM. الـ precompile كانت فكرة حل وسط اُعتمدت منذ بدايات تطوير Ethereum: لأن تكلفة الماكينة الافتراضية تكون كبيرة جدًا لبعض الأكواد شديدة التعقيد والمختصة، يمكننا تنفيذ بعض العمليات الأساسية المهمة محليًا في كود العميل لتجعلها أسرع. اليوم، يشمل هذا عمليًا بعض دوال التجزئة المحددة وعملات الدوال على المنحنيات الإهليلجية (elliptic curve operations).

يبدو أن هناك من يدفع لإضافة precompile لـ sepc256r1، وهي منحنى إهليلجي مختلف قليلًا عن secp256k1 المستخدم في حسابات Ethereum الأساسية، لكنه مدعوم جيدًا من خلال وحدات عتادية موثوقة (trusted hardware modules)، وبالتالي فإن استخدامه على نطاق واسع يمكن أن يحسن أمن المحافظ. في السنوات الأخيرة، ضغطت المجتمعات أيضًا لإضافة precompile لـ BLS-12-377 وBW6-761، وعمليات الاقتران العامة (generalized pairing) وغيرها.

الرد على هذه المتطلبات المتزايدة لعدد أكبر من ملفات precompile هو أن الكثير من الـ precompiles التي تمت إضافتها سابقًا (مثل RIPEMD وBLAKE) كانت نسبة استخدامها الفعلية أقل بكثير من المتوقع، وينبغي أن نستخلص العبرة من ذلك. بدلًا من إضافة precompiles لعمليات محددة أكثر، قد يكون من الأفضل التركيز على نهج أكثر لطفًا يستند إلى EVM- MAX MAX MAX Token هو توكن عملي يُصدره MAX، وهو سوق لتداول أصول العملات. MAX Exchange تركز على دعم مجتمع التداول لديها وتقديم أكثر منصة تداول أمانًا. سيتم مكافأة MAX Tokens عبر التعدين في أثناء التداول، كما يمكن استخدامها في تقديم مكافآت عبر Staking على المنصة. راجع المزيد و أفكار مثل SIMD التي تكون خاملة ولكن قابلة للاسترداد دائمًا (بشكل proposal) ستجعل تنفيذ نطاق أوسع من “أنواع الكود” في EVM بتكلفة أقل. ربما حتى يمكن حذف precompiles الحالية قليلة الاستخدام، واستبدالها بتنفيذ كود EVM لنفس الدوال (حتماً سيكون أقل كفاءة). أي أنه قد يظل هناك عمليات تشفير محددة قيمتها كبيرة بما يكفي لتسريع التنفيذ، وبالتالي يكون من المنطقي إضافتها كـ precompiles.

ماذا تعلمنا من كل هذا؟

الرغبة في تغليف بأقل قدر ممكن مفهوم وجيد؛ إذ ينبع من تقليد فلسفي في Unix Unix راجع المزيد فلسفة، أي إنشاء برمجيات بسيطة للغاية يمكنها التكيف بسهولة مع احتياجات المستخدمين المختلفة، وتجنب لعنة تضخم البرمجيات. ومع ذلك، فإن البلوكشين ليس نظام تشغيل حسابات فردي؛ بل هو نظام اجتماعي. وهذا يعني أنه من المفيد تغليف بعض الوظائف داخل البروتوكول.

في كثير من الحالات، كانت هذه الأمثلة الأخرى مشابهة لما رأيناه في تجريد الحسابات. لكننا تعلمنا أيضًا بعض الدروس الجديدة:

• تغليف الميزات يمكن أن يساعد في تجنب مخاطر المركزية في مناطق أخرى من المكدس:

عادةً ما يؤدي الحفاظ على تقليل حجم البروتوكول الأساسي وتعقيده إلى دفع التعقيد إلى بعض النظام البيئي خارج البروتوكول. ومن منظور فلسفة Unix، هذا أمر جيد. ومع ذلك، أحيانًا توجد مخاطر مركزية في نظام بيئي خارج البروتوكول، غالبًا (ولكن ليس فقط) بسبب التكاليف الثابتة المرتفعة. قد يقلل التغليف أحيانًا من هذه المركزية بحكم الواقع.

• تغليف الكثير قد يؤدي إلى زيادة مبالغ بها في عبء الثقة والحوكمة في البروتوكول:

هذا هو موضوع المقال السابق بعنوان “لا تُحمّل إجماع Ethereum فوق طاقته”: إذا أدى تغليف وظيفة محددة إلى إضعاف نموذج الثقة وجعل Ethereum ككل أكثر “ذاتية” (subjective)، فإن ذلك يضعف الحياد الموثوق لإيثيريوم. في هذه الحالات، من الأفضل اعتبار الوظيفة المعينة آلية فوق Ethereum بدلًا من محاولة إدخالها في Ethereum نفسه. في هذا السياق، يُعد مخزن الذاكرة المشفر مثالًا أفضل ما يمكن—فقد يكون من الصعب تغليفه، على الأقل حتى تتحسن تقنيات التشفير المتأخر.

• قد يجعل تغليف الكثير من المحتوى البروتوكول معقدًا للغاية:

تعقيد البروتوكول هو خطر منهجي: إضافة الكثير من الميزات إلى البروتوكول تزيد هذا الخطر. precompiles هي المثال الأفضل على ذلك.

• على المدى الطويل، قد يأتي التغليف بنتائج عكسية بسبب أن احتياجات المستخدمين غير قابلة للتنبؤ:

الميزة التي يظن كثير من الناس أنها مهمة والتي سيستخدمها الكثير من المستخدمين، من المحتمل ألا تُستخدم كثيرًا عمليًا.

علاوة على ذلك، تُظهر أمثلة liquid staking وZK-EVM وprecompiles وجود مسار وسيط ممكن: الحد الأدنى القابل للتطبيق من التغليف (minimal viable enshrinement). لا يحتاج البروتوكول إلى تغليف كل الوظائف، بل يمكنه تضمين أجزاء محددة تعالج التحديات الأساسية، بحيث تصبح هذه الوظيفة أسهل في التنفيذ دون الوقوع في هوس التضمين أو انحياز شديد. من أمثلة ذلك:

• بدلًا من تغليف نظام كامل للـ liquid staking، لنغيّر قواعد عقوبات الرهن لجعل الـ liquid staking غير المركزي أكثر قابلية للتطبيق؛

• بدلًا من تغليف المزيد من precompilers، لنغلف EVM-MAX و/أو SIMD لتمكين فئات أوسع من العمليات من تنفيذها بكفاءة أكبر؛

• يمكننا ببساطة تغليف تحقق EVM، بدلًا من تغليف كامل مفهوم rollup.

يمكننا توسيع المخطط السابق على النحو التالي:

أحيانًا يكون من المنطقي تغليف بعض الأشياء، وإزالة precompiles قليلة الاستخدام مثال على ذلك. أيضًا، تجريد الحسابات ككل هو شكل مهم من أشكال “إزالة التغليف”. إذا أردنا دعم التوافق الخلفي مع المستخدمين الحاليين، فقد تكون هذه الآلية، بشكل مدهش، مشابهة لآلية إزالة التغليف الخاصة بـ precompiles: أحد المقترحات هو EIP-5003، الذي سيسمح لـ EOA بتحويل حسابه إلى عقد يوفر نفس (أو وظائف أفضل) مع البقاء بوظائف متكافئة.

ما هي الخصائص التي يجب إدخالها إلى البروتوكول، وأي منها يجب تركه لطبقات أخرى في النظام البيئي؟ هذا توازن معقد. ومع تحسن فهمنا لاحتياجات المستخدمين، وتطوير أفكار وحزم تقنيات متاحة، يُتوقع أن يستمر هذا التوازن في التحسن مع مرور الوقت.