المؤلف: Vitalik، مؤسس Ethereum الترجمة: Golden Finance 0xjs

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

ستستعرض هذه المقالة بعض الأسس الفلسفية وراء أيديولوجية تبسيط بروتوكول إيثريوم المبكرة، وبعضًا من آرائي الأحدث بشأن هذه الأفكار. الهدف هو بناء إطار أفضل تدريجيًا للتعرف على الأهداف التي قد تجعل ترسيخ بعض الميزات داخل البروتوكول أمرًا يستحق التفكير.

فلسفة التبسيط المبكر للبروتوكول

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

إعادة بناء تقريبية جدًا للوحة بيضاء من أوائل 2015 قمت بها أنا وGavin Wood، حين كنا نناقش كيف ستبدو إيثريوم 2.0.

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

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

طُرح هذا النوع من التفكير لفترة وجيزة، لكنه رُفض بسرعة لأننا كنا مفرطين في التركيز على ما إذا كان التوسع في البلوكشين ممكنًا بأي شكل أم لا. لكن كما سنرى لاحقًا، فإن الجمع بين أخذ عينات توافر البيانات وZK-EVM يعني أن أحد المستقبلات المحتملة لتوسيع إيثريوم قد يبدو في الواقع قريبًا بشكل مدهش من هذا التصور! أما بالنسبة لتجريد الحسابات، فمن ناحية أخرى، فقد كنا نعلم منذ البداية أن شكلًا ما من التنفيذ ممكن، ولذلك بدأنا مباشرةً في دراسة كيفية جعل البداية النقية القائلة إن «المعاملة ليست سوى استدعاء» أقرب ما يمكن إلى الواقع.

هناك هنا الكثير من الشيفرات التي تحدث قبل وبعد معالجة المعاملة وقبل استدعاءات EVM الأساسية من عنوان الإرسال. كيف يمكننا تقليص هذه الشيفرة إلى أقرب ما يكون من الصفر؟

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

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

المواصفات

إذا كان block.number >= METROPOLIS_FORK_BLKNUM، فحينئذٍ: 1، إذا كان توقيع المعاملة هو (0, 0, 0) (أي v = r = s = 0)، فاعتبرها صالحة واضبط عنوان المرسل إلى 2 ** 160 - 1. 2، اضبط عنوان أي عقد يُنشأ بواسطة معاملة إنشاء إلى sha3(0 + شيفرة التهيئة) % 2 ** 160، حيث تعني + الربط، مع استبدال صيغة العنوان السابقة sha3(rlp.encode([sender, nonce])) 3، أنشئ opcode جديدًا بالقيمة 0xfb، CREATE_P2SH، والذي يضبط العنوان المُنشأ إلى sha3(sender + init code) % 2 ** 160. إذا كان هناك عقد موجود بالفعل عند هذا العنوان، يفشل ويعيد 0، كما لو أن شيفرة التهيئة استهلكت كل الغاز.

بشكل أساسي، إذا جرى تعيين التوقيع إلى (0, 0, 0)، فإن المعاملة تصبح فعليًا «مجرد استدعاء». وسيكون الحساب نفسه مسؤولًا عن وجود شيفرة لتحليل المعاملة، واستخراج التوقيع والـ nonce والتحقق منهما، ودفع الرسوم، انقر هنا لرؤية نسخة مبكرة من هذه الشيفرة، وانقر هنا لرؤية شيفرة validate_transaction التي ستستبدلها شيفرة هذا الحساب، مما اختزل apply_transaction في مرحلة ما إلى مجرد استدعاء EVM. وبعبارة أخرى، كان بروتوكول إيثريوم سيقوم بالتحقق من المعاملة، مع ترك منطق المعاملة المحدد لشيفرة حساب المستخدم نفسه، لتوفير المرونة.

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

لاحظ أن على المعدّنين وضع استراتيجية لقبول هذه المعاملات. يجب أن تكون هذه الاستراتيجية انتقائية للغاية، وإلا فقد يقبلون معاملات لا تدفع أي رسوم (بالنسبة لشيفرة validate_transaction التي سيحل محلها كود ما قبل الحساب)، أو حتى معاملات لا يكون لها أي أثر (مثلًا لأن المعاملة أُدرجت بالفعل ولم يعد nonce صالحًا). تتمثل إحدى الطرق البسيطة في وضع قائمة بيضاء على codehash للشيفرة الخاصة بالحسابات التي تُرسل إليها المعاملات المقبولة؛ وستشمل الشيفرة المعتمدة المنطق الذي يدفع رسوم المعاملة للمعدنين. لكن هذا قد يكون مقيِّدًا أكثر من اللازم؛ وبديل أكثر مرونة لكنه لا يزال فعّالًا هو قبول أي شيفرة تطابق الصيغة العامة نفسها المذكورة أعلاه، وتستهلك عددًا محدودًا من الغاز فقط لتنفيذ فحوصات nonce والتوقيع، مع ضمان دفع رسوم المعاملة للمعدن. وهناك استراتيجية أخرى تتمثل، بالإضافة إلى الطرق الأخرى، في محاولة التعامل مع أي طلب يقل عن 250,000 غاز وعدم إدراجه إلا إذا زاد رصيد المعدّن بشكل مناسب بعد تنفيذ المعاملة.

إذا أُدخل EIP-86 كما هو، فسيقلل تعقيد EVM، لكنه سيزيد تعقيد الأجزاء الأخرى من مكدس إيثريوم بشكل كبير، مع اشتراط كتابة الشيفرة نفسها تقريبًا في أماكن أخرى، فضلًا عن إدخال إمكانات غريبة جديدة تمامًا، مثل إمكانية ظهور المعاملة نفسها ذات الهاش نفسه على السلسلة عدة مرات، ناهيك عن مشكلة الرفض المتعدد.

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

لقد تطوّر تجريد الحسابات تدريجيًا من هناك. أصبح EIP-86 هو EIP-208، ثم أصبح لاحقًا المنشور على ethresear.ch حول «المفاضلات في مقترحات تجريد الحسابات»، ثم بعد نصف عام أصبح هذا المنشور على ethresear.ch. وفي النهاية، أنتج كل ذلك EIP-2938 الذي كان عمليًا قابلًا للتطبيق إلى حد كبير.

ومع ذلك، فإن EIP-2938 ليس بالحد الأدنى. إذ يتضمن هذا الـ EIP:

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

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

• أوبكودان جديدان، بما في ذلك PAYGAS الضخم للغاية، يتعاملان مع سعر الغاز وفحص حد الغاز، باعتبارهما نقطة توقف في تنفيذ EVM، وفي الوقت نفسه يخزنان ETH مؤقتًا لدفع الرسوم.

• مجموعة معقدة من استراتيجيات التعدين وإعادة التشغيل، بما في ذلك سلسلة من الأوبكودات المحظورة في مرحلة التحقق من المعاملة

ولكي يتقدم تجريد الحسابات دون إشراك مطوري إيثريوم الأساسيين المنشغلين بتحسين عملاء إيثريوم وتنفيذ الدمج، أعيد تصميم EIP-2938 في النهاية ليصبح ERC-4337 بالكامل خارج البروتوكول.

ERC-4337. إنه يعتمد بالكامل فعلًا على استدعاءات EVM لإنجاز كل شيء!

ولأنه ERC، فهو لا يحتاج إلى فورك صلب، ومن الناحية التقنية يكون «خارج بروتوكول إيثريوم». فهل انتهت المشكلة إذًا؟ حسنًا، في الواقع لم تُحل بالكامل بعد. فخارطة الطريق المتوسطة الحالية لـ ERC-4337 تتضمن في النهاية تحويل معظم ERC-4337 إلى مجموعة من ميزات البروتوكول، وهو مثال مفيد لفهم لماذا يُنظر في هذا المسار.

ترسيخ ERC-4337 على مستوى البروتوكول

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

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

• خطر الأخطاء البرمجية: إذا كان «عقد نقطة الدخول» في ERC-4337 يحتوي على خطأ فادح بما فيه الكفاية، فقد ترى جميع المحافظ المتوافقة مع ERC-4337 أن أموالها تُفرَّغ بالكامل. عبر استبدال العقد بميزة بروتوكولية، يمكن إنشاء مسؤولية ضمنية عن إصلاح الأخطاء البرمجية، وإزالة خطر فقدان أموال المستخدمين.

• دعم أوبكودات EVM مثل tx.origin. إن ERC-4337 نفسه يجعل tx.origin يعيد عنوان «المرسِل المُجمِّع» الذي يرسل حزمة من عمليات المستخدم في معاملة. ويمكن للتجريد الحسابي الأصلي معالجة هذه المشكلة بجعل tx.origin يشير إلى الحساب الذي أرسل المعاملة فعليًا، بحيث يتصرف كما تعمل EOA.

• مقاومة الرقابة: في حالة PBS، يتمثل أحد التحديات في أن رقابة المعاملات الفردية تصبح أسهل. في عالم تكون فيه كل معاملة مرئية لبروتوكول إيثريوم، يمكن للتخفيف من هذه المشكلة بشكل كبير من خلال قوائم الإدراج، التي تسمح للمقترح بتحديد قائمة من المعاملات التي يجب تضمينها في الكتلتين التاليتين في معظم الحالات. لكن ERC-4337 خارج البروتوكول يلف «عمليات المستخدم» داخل معاملة واحدة، ما يجعل عمليات المستخدم غير مرئية لبروتوكول إيثريوم؛ وبالتالي فإن قوائم الإدراج التي يوفرها بروتوكول إيثريوم لن تستطيع توفير مقاومة الرقابة لعمليات مستخدم ERC-4337. إن تقنين ERC-4337 وجعل عمليات المستخدم نوع معاملة «رسمي» سيحل هذه المشكلة.

من الجدير التعمق أكثر في مسألة كفاءة الغاز. في شكله الحالي، ERC-4337 أكثر تكلفة بكثير من معاملات إيثريوم «الأساسية»: تكلفة المعاملة 21,000 غاز، بينما تبلغ تكلفة ERC-4337 نحو 42,000 غاز. ويسرد هذا المستند بعض الأسباب لذلك:

• هناك العديد من تكاليف القراءة/الكتابة الفردية للتخزين التي يجب دفعها، وبالنسبة لـ EOA يجري تجميعها ضمن دفعة واحدة مقدارها 21000 غاز:

• تعديل خانة التخزين التي تحتوي على pubkey+nonce (〜5000)

• تكلفة calldata لـ UserOperation (〜4500، ويمكن خفضها إلى 〜2500 عبر الضغط)

• ECRECOVER (〜3000)

• تسخين المحفظة نفسها (〜2600)

• تسخين حساب المستلم (〜2600)

• تحويل ETH إلى حساب المستلم (〜9000)

• تعديل التخزين لدفع الرسوم (〜5000)

• الوصول إلى خانة التخزين التي تحتوي على الوكيل (〜2100)، ثم الوكيل نفسه (〜2600)

• إضافةً إلى تكاليف القراءة/الكتابة المذكورة أعلاه، تحتاج العقدة أيضًا إلى تنفيذ «منطق الأعمال» (فك ضغط UserOperation، وتجزئتها، وإعادة ترتيب المتغيرات، وما إلى ذلك)، بينما تُعالج معاملات EOA عبر بروتوكول إيثريوم «مجانًا».

• 需要消耗 الغاز لدفع رسوم السجل (EOA لا تُصدر سجلات)

• تكلفة إنشاء عقد لمرة واحدة (التكلفة الأساسية حوالي 〜32000، ويضيف كل بايت من الشيفرة في الوكيل 200 غاز، إضافةً إلى 20000 غاز لإعداد عنوان الوكيل)

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

محافظ ERC-4337 كاملة الوظائف ضخمة. هذا التنفيذ، بعد ترجمته ووضعه على السلسلة، يشغل حوالي 12800 بايت. بالطبع، يمكنك نشر هذه الشيفرة الضخمة مرة واحدة واستخدام DELEGATECALL للسماح لكل محفظة منفردة باستدعائها، لكن الشيفرة ما تزال تحتاج إلى الوصول في كل كتلة تستخدمها. وبحسب EIP القادم لتكاليف غاز أشجار Verkle، فإن 12800 بايت ستشغل 413 chunk، والوصول إلى هذه الـ chunks سيتطلب 2x WITNESS_BRANCH_COST (إجمالي 3,800 غاز) و413x WITNESS_CHUNK_COST (إجمالي 82,600 غاز). وهذا لا يذكر حتى نقطة دخول ERC-4337 نفسها، التي تبلغ في الإصدار 0.6.0 على السلسلة 23689 بايت (وبحسب قواعد EIP الخاصة بأشجار Verkle، فإن تحميلها يتطلب نحو 158700 غاز).

وهذا يخلق مشكلة: فتكلفة الغاز للوصول إلى هذه الشيفرة الفعلية يجب أن توزَّع بطريقة ما بين المعاملات. والطريقة التي يستخدمها ERC-4337 حاليًا ليست جيدة: إذ تتحمل المعاملة الأولى في الحزمة تكلفة قراءة التخزين/الشيفرة لمرة واحدة، ما يجعلها أغلى بوضوح من بقية المعاملات. إن جعل هذه المكتبات المشتركة الشائعة جزءًا من البروتوكول، ومتاحة للجميع دون رسوم، هو طريقة حل هذه المشكلة.

ما الذي يمكن أن نتعلمه من هذا المثال حول متى ينبغي تعميم التثبيت داخل البروتوكول؟

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

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

• الاستجابة الجماعية لمجتمع ما للأخطاء البرمجية. إذا كانت مجموعة من الشيفرات تستخدمها جميع الفئات من المستخدمين أو عدد كبير منهم، فعادةً ما يكون من الأكثر منطقية أن يتحمل مجتمع سلسلة الكتل مسؤولية إصلاح الأخطاء المحتملة عبر فورك صلب. لقد قدّم ERC-4337 قدرًا كبيرًا من الشيفرة المشتركة عالميًا، وعلى المدى الطويل فإن إصلاح الأخطاء في تلك الشيفرة يكون أفضل عبر فورك صلب بدلًا من تعريض المستخدمين لخسارة كميات كبيرة من ETH.

• أحيانًا، يمكن أن يتيح الاستفادة المباشرة من سلطة البروتوكول أشكالًا أقوى من الوظائف. على سبيل المثال، يمكن للرقابة داخل البروتوكول أن تضمن مقاومة الرقابة بشكل أفضل، ولكي تستفيد عمليات المستخدم على مستوى المستخدم حقًا من البروتوكول، يجب أن تكون العمليات الفردية على مستوى المستخدم «قابلة للقراءة» للبروتوكول. مثال آخر أقل شهرة هو أن تصميم إيثريوم لإثبات الحصة في 2017 كان يتضمن تجريدًا للسلطة، لكن هذا جرى التخلي عنه لصالح BLS في مرحلة التجميع، لأن BLS يدعم آلية «التجميع» التي يجب تنفيذها على مستوى البروتوكول والشبكة، ويمكن أن تجعل معالجة كميات كبيرة من التواقيع أكثر كفاءة.

لكن من المهم أن نتذكر أنه حتى تجريد الحسابات المُرسّخ في البروتوكول يظل، مقارنةً بالوضع الحالي، نوعًا هائلًا من «اللا-تثبيت». اليوم، لا يمكن بدء معاملات الطبقة العليا في إيثريوم إلا من حسابات مملوكة خارجيًا (EOA)، وتُتحقق هذه الحسابات بتوقيع إهليلجي واحد من نوع secp256k1. أما تجريد الحسابات فيعكس هذا ويتيح انفتاحًا في تحديد شروط التحقق من قبل المستخدم. لذلك، في هذه القصة عن تجريد الحسابات، نرى أيضًا أقوى حجة ضد الإغلاق: وهي المرونة لتلبية احتياجات المستخدمين المختلفة.

دعونا نحاول تحسين هذه القصة أكثر من خلال النظر في بعض الميزات التي جرى التفكير مؤخرًا في ترسيخها. وسنركز على: ZK-EVMs، وفصل المقترح-الباني، والحوضات الخاصة، والرهن السائل، والـ precompiles الجديدة.

ترسيخ ZK-EVMs

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

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

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

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

وبما أن هذه الـ ZK-EVMs الخاصة بالطبقة الثانية تستخدم أساسًا نفس EVM الخاص بإيثريوم، ألا يمكننا بطريقة ما تحويل «التحقق من تنفيذ EVM داخل ZK» إلى ميزة بروتوكولية؟ وفي حالات الأخطاء والترقيات، ألا يمكننا معالجة ذلك عبر تطبيق الإجماع الاجتماعي لإيثريوم، كما نفعل مع تنفيذ EVM في الطبقة الأساسية نفسها؟

هذا موضوع مهم وصعب. وهناك بعض الدقائق الدقيقة:

1، نريد أن نكون متوافقين مع فلسفة إيثريوم متعددة العملاء. وهذا يعني أننا نريد السماح لعملاء مختلفين باستخدام أنظمة إثبات مختلفة. وهذا بدوره يعني أنه لأي تنفيذ EVM يُثبت باستخدام نظام ZK-SNARK واحد، نريد ضمان توافر البيانات الأساسية بحيث يمكن توليد براهين لأنظمة ZK-SNARK أخرى.

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

3، نحتاج إلى أوقات إثبات أسرع، بحيث إذا تم توليد نوع من البراهين، يمكن بسرعة توليد أنواع أخرى من البراهين كي تتحقق منها عملاء آخرون. ويمكن حل هذه المشكلة بإنشاء precompile له استجابة غير متزامنة بعد نافذة زمنية معينة (مثل 3 ساعات)، لكن ذلك سيزيد التعقيد.

4، نريد دعم ليس فقط نسخًا مطابقة لـ EVM، بل أيضًا «شبه-EVMs». فالابتكار على مستوى التنفيذ وتوسيع EVM جزء من جاذبية الطبقة الثانية. وإذا كانت آلة L2 الافتراضية المعطاة تختلف عن EVM باختلافات طفيفة فقط، فسيكون من الجيد أن تستخدم الـ ZK-EVM البروتوكولي الأصلي في الأجزاء التي تتطابق فيها مع EVM، وتستند فقط إلى شيفرتها الخاصة في التعامل مع الأجزاء المختلفة. ويمكن تحقيق ذلك عبر تصميم precompile لـ ZK-EVM بحيث يسمح للمستدعي بتحديد مجموعة من الأوبكودات أو العناوين في جدول، أو قائمة حقول بتية، تتعامل معها جداول خارجية بدلًا من EVM نفسه. ويمكننا أيضًا، إلى حد ما، جعل تكاليف الغاز قابلة للتخصيص.

عند استخدام ZK-EVM أصلي، أحد المواضيع الجدلية المحتملة فيما يتعلق بتوافر البيانات هو الحالة. إذا لم تكن ZK-EVMs بحاجة إلى حمل بيانات «الشاهد»، فستكون أكثر كفاءة في البيانات. أي، إذا تمت قراءة بيانات معينة أو كتابتها في كتلة سابقة، فيمكننا ببساطة افتراض أن المُثبت يمكنه الوصول إليها، ولا نحتاج إلى توفيرها مرة أخرى. ولا يقتصر هذا على عدم إعادة تحميل التخزين والشيفرة؛ إذ يتبيّن أنه إذا ضغط أحد الـ rollups البيانات بشكل صحيح بحيث يكون الضغط ذا حالة، فسيؤدي ذلك إلى توفير ما يصل إلى 3 أضعاف البيانات مقارنةً بالضغط عديم الحالة.

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

1، تتطلب الـ precompiles أن تكون جميع البيانات متاحة في الكتلة نفسها. وهذا يعني أن المُثبت يمكن أن يكون عديم الحالة، لكنه يعني أيضًا أن ZK-rollup الذي يستخدم مثل هذا الـ precompile يكون أكثر تكلفة من rollup يستخدم شيفرة مخصصة.

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

ما الدرس الذي يمكن استخلاصه من هذا؟ هناك حجة قوية إلى حد ما لترسيخ التحقق من ZK-EVM بطريقة ما: فعمليات الـ rollup تبني بالفعل نسخها المخصصة الخاصة، ويبدو غريبًا أن تكون إيثريوم مستعدة لوضع ثقل تنفيذ EVM على L1 مع تعدد تطبيقاتها وتوافقها الاجتماعي خارج السلسلة، بينما يُطلب من L2 الذي يقوم بالمهمة نفسها أن يطبق أدوات معقدة تتضمن مجلسًا أمنيًا. لكن من ناحية أخرى، توجد مشكلة كبيرة في التفاصيل: هناك نسخ مختلفة من ZK-EVM المرسّخ، لها تكاليف وفوائد مختلفة. فالحالة مقابل عدم الحالة ليست سوى قمة جبل الجليد؛ ومحاولة دعم «شبه-EVMs» بشيفرة مخصصة مع براهين نظامية أخرى قد تكشف عن مساحة تصميم أكبر بكثير. لذا فإن ترسيخ ZK-EVMs يحمل وعودًا وتحديات في آن واحد.

ترسيخ فصل المقترح-الباني (ePBS)

لقد أدى صعود MEV إلى جعل إنتاج الكتل نشاطًا ذا اقتصاديات الحجم، حيث يستطيع المشاركون الأذكياء توليد كتل تحقق إيرادات أكبر من الخوارزميات الافتراضية التي تكتفي بمراقبة المعاملات في حوض الذاكرة وإدراجها. حاول مجتمع إيثريوم حتى الآن معالجة هذه المشكلة عبر استخدام مخططات فصل المقترح-الباني خارج البروتوكول مثل MEV-Boost، والذي يسمح للمحققين العاديين («المقترحين») بإسناد بناء الكتل إلى مشاركين متخصصين («البانين»).

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

ترسيخ حوض الذاكرة الخاص

عندما يرسل المستخدم معاملة، تصبح هذه المعاملة عامة ومرئية للجميع على الفور، حتى قبل إدراجها على السلسلة. وهذا يجعل مستخدمي العديد من التطبيقات عرضة للهجمات الاقتصادية مثل الـ front-running: فإذا نفذ المستخدم صفقة كبيرة على Uniswap، فقد يتمكن المهاجم من إدخال معاملة قبله، ما يرفع السعر الذي يدفعه، ثم يقتنص ربح المراجحة.

مؤخرًا، ظهرت بعض المشاريع التي تنشئ «حوض ذاكرة خاص» (أو «حوض ذاكرة مشفّر») يجعل معاملات المستخدمين تبقى مشفرة حتى يتم قبولها بشكل غير قابل للعكس في كتلة.

لكن هذا المخطط يتطلب نوعًا محددًا من التشفير: لمنع المستخدم من إغراق النظام والقيام بـ front-running لعملية فك التشفير نفسها قبل أن تُقبل المعاملة فعليًا بشكل غير قابل للعكس، يجب أن يكون التشفير قابلًا للفك تلقائيًا عند قبول المعاملة بشكل غير قابل للعكس.

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

• تشفير إلى مشغّل مركزي مثل Flashbots Protect.

• التشفير المقيد زمنيًا، وهو شكل من التشفير يمكن فكّه من قبل أي شخص بعد عدد معيّن من خطوات الحساب المتسلسلة، بحيث لا يمكن موازنتها بالتوازي.

• التشفير العتبي، مع الثقة في أغلبية لجنة لفك تشفير البيانات. انظر مفهوم Shutterized beacon chain للحصول على اقتراح محدد.

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

للأسف، لكل ذلك نقاط ضعف مختلفة. ولأسباب واضحة، لا يمكن قبول المشغّل المركزي ضمن البروتوكول. أما التشفير التقليدي القائم على الحوض الزمني الذاخر لعشرات الآلاف من المعاملات فهو مكلف جدًا. وهناك بديل أقوى يُسمّى التشفير المؤجل يتيح فك تشفير فعال على عدد معيّن من الرسائل، لكن بناؤه عمليًا صعب، كما أن هجمات على النماذج الحالية ما تزال تُكتشف أحيانًا. وكما هو الحال مع دوال التجزئة، قد نحتاج سنوات إضافية من البحث والتحليل قبل أن ينضج التشفير المؤجل بما يكفي. أما التشفير العتبي فيتطلب الثقة في أن أغلبية اللجنة لن تتواطأ، وفي البيئات التي يمكن فيها التواطؤ دون أن يُكتشف (على عكس هجوم 51% حيث يُعرف فورًا من شارك) فهذا أمر غير مقبول. ويضيف SGX اعتمادًا على جهة تصنيع موثوقة واحدة.

على الرغم من أن كل حل له مجموعة من المستخدمين المستعدين للثقة به، فلا يوجد حتى الآن حل واحد جدير بالثقة بدرجة كافية ليُقبل فعليًا على الطبقة الأولى. لذلك، إلى أن/ما لم تتحسن تقنيات التشفير المؤجل أو يظهر اختراق تقني آخر، يبدو إدخال مقاومة الـ front-running إلى الطبقة الأولى اقتراحًا صعبًا، حتى لو كان ميزة ذات قيمة كبيرة وقد ظهرت بالفعل لها حلول تطبيقية كثيرة.

ترسيخ الرهن السائل

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

حتى الآن، أبسط «واجهة» للرهن التي تلبي هذين الطلبين هي رمز ERC20: حوّل ETH الخاص بك إلى «ETH مرهون»، احتفظ به، ثم حوّله مرة أخرى. وفي الواقع، ظهرت بالفعل مزودات رهن سائل مثل Lido وRocketpool للقيام بذلك. لكن للرهن السائل بعض آليات المركزية الطبيعية التي تعمل هنا: فالأشخاص ينتقلون طبيعيًا إلى أكبر إصدار من ETH المرهون لأنه الأكثر ألفة والأكثر سيولة (ويحظى بأفضل دعم من التطبيقات، والتي بدورها تدعمه لأنه أكثر ألفة، لأنه أحد الأنواع التي سمع بها معظم المستخدمين).

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

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

السؤال الأساسي هنا هو: أي ميزة بروتوكولية ينبغي ترسيخها؟ إن مجرد إنشاء رمز «ETH مرهون» قابل للاستبدال داخل البروتوكول يعني أنه إما يجب أن تكون لديه حوكمة عالمية لإيثريوم مُرسّخة لاختيار من يشغّل العقد، أو أن يكون مفتوحًا، ما يجعله أداة بيد المهاجمين.

من الأفكار المثيرة للاهتمام مقال Dankrad Feist عن التطرف في الرهن السائل. أولًا، علينا أن نواجه حقيقة أنه إذا تعرضت إيثريوم لهجوم 51%، فمن الممكن أن يُعاقَب فقط 5% من ETH المهاجم. وهذا مفاضلة معقولة؛ فهناك الآن أكثر من 26 مليون ETH مرهونة، وثلث تكلفة الهجوم (حوالي 8 ملايين ETH) يُعد فائضًا تمامًا، لا سيما بالنظر إلى عدد الهجمات «خارج النموذج» التي يمكن تنفيذها بتكلفة أقل بكثير. وفي الواقع، فقد جرى استكشاف مفاضلة مشابهة بالفعل في اقتراح «اللجنة الفائقة» المستخدم لتنفيذ النهائية ذات الشق الواحد.

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

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

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

ترسيخ المزيد من الـ precompiles

الـ precompile (أو «العقد المسبق الترجمة») هو عقد في إيثريوم يحقق عمليات تشفير معقدة نُفذت محليًا في كود العميل بدلًا من كود عقد ذكي على EVM. كانت الـ precompiles تسوية في المراحل الأولى من تطور إيثريوم: نظرًا لأن حمل الـ VM كان كبيرًا جدًا على بعض أنواع الشيفرات شديدة التعقيد والتخصص، أمكننا تنفيذ بعض العمليات الأساسية ذات القيمة لأنواع مهمة من التطبيقات بلغة أصلية لجعلها أسرع. واليوم، يشمل هذا أساسًا بعض دوال التجزئة المحددة وعمليات المنحنيات الإهليلجية.

يجري حاليًا الدفع لإضافة precompile لـ secp256r1، وهو منحنى إهليلجي مختلف قليلًا عن secp256k1 المستخدم في حسابات إيثريوم الأساسية، لأنه مدعوم على نطاق واسع من وحدات العتاد الموثوق، وبالتالي فإن استخدامه على نطاق واسع قد يحسّن أمان المحافظ. وفي السنوات الأخيرة، كانت هناك أيضًا جهود لدفع إضافة precompiles لوظائف مثل BLS-12-377 وBW6-761 والاقترانات المعممة وغيرها.

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

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

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

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

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

• قد يؤدي الإفراط في التثبيت إلى زيادة عبء الثقة والحَوْكمة على البروتوكول بشكل مفرط. هذا هو موضوع أحد المقالات المبكرة حول «لا تُحمّل إجماع إيثريوم أكثر من طاقته» (راجع المقال المترجم سابقًا في الذهبية): إذا أدى تثبيت وظيفة معينة إلى إضعاف نموذج الثقة وجعل إيثريوم ككل أكثر «ذاتية»، فهذا يقوض حياده الموثوق. في مثل هذه الحالات، من الأفضل إبقاء تلك الوظيفة تحديدًا آليةً فوق إيثريوم بدلًا من محاولة إدخالها إلى إيثريوم نفسه. وهنا تُعد حوضات الذاكرة المشفرة أفضل مثال على شيء قد يكون من الصعب جدًا تثبيته، على الأقل إلى أن تتحسن تقنيات التشفير المؤجل أو ما لم تتحسن.

• قد يؤدي الإفراط في التثبيت إلى تعقيد البروتوكول بشكل مفرط. فتعقيد البروتوكول يمثل خطرًا على النظام، وإضافة الكثير من الميزات داخل البروتوكول تزيد من هذا الخطر. والـ precompiles هو أفضل مثال على ذلك.

• قد يأتي التثبيت بنتائج عكسية على المدى الطويل لأن احتياجات المستخدمين غير قابلة للتنبؤ. كثير من الميزات التي يعتقد الناس أنها مهمة وسيستخدمها عدد كبير من المستخدمين قد لا تُستخدم كثيرًا عمليًا.

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

• بدلًا من ترسيخ نظام الرهن السائل بأكمله، غيّر قواعد العقوبة لجعل الرهن السائل عديم الثقة أكثر قابلية للتطبيق.

• بدلًا من ترسيخ المزيد من الـ precompiles، ثبّت EVM-MAX و/أو SIMD لجعل فئات أوسع من العمليات أسهل في التنفيذ بكفاءة.

• بدلًا من ترسيخ المفهوم الكامل للـ Rollups، يمكننا ببساطة ترسيخ التحقق من EVM.

يمكننا توسيع المخطط أعلاه في هذه المقالة كما يلي:

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

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