Vitalik: المستقبل المحتمل لبروتوكول Ethereum – التفاخر

المؤلف: Vitalik ، مؤسس Ethereum ؛

ملاحظة: هذا المقال هو الجزء السادس من سلسلة المقالات التي نشرتها Vitalik مؤخرًا ، مؤسس Ethereum ،العقود الآجلة المحتملة لبروتوكول Ethereum ، الجزء 6: التفاخر“، انظر الجزء الخامس”Vitalik: المستقبل المحتمل لبروتوكول Ethereum – التطهير“، انظر الجزء الرابع”Vitalik: المستقبل المحتمل لـ Ethereum الحفر“. يرى “Vitalik: الأهداف الرئيسية لل Ethereum مرحلة Scourge“، انظر الجزء الثاني”Vitalik: كيف ينبغي أن يتطور بروتوكول Ethereum في مرحلة الارتفاع“، انظر الجزء الأول”ماذا يمكن تحسينه على Ethereum POS“ما يلي هو النص الكامل للجزء 6:

---

شكر خاص لجوستين دريك وتيم بيكو على ملاحظاتهما وتعليقاتهم.

من الصعب أن تقع بعض الأشياء في فئة.هناك العديد من “الأشياء الصغيرة” في تصميم بروتوكول Ethereum والتي هي ذات قيمة كبيرة لنجاح Ethereum ، لكنها ليست مناسبة للتصنيف في فئة فرعية أكبر.في الواقع ، ينتهي الأمر إلى ما يقرب من نصفهم في نهاية المطاف مع تحسينات EVM المختلفة ، في حين أن الباقي يتكون من مختلف الموضوعات المتخصصة.هذا ما هو “التفاخر” ل.

تفاخر ، 2023 خريطة الطريق

التفاخر: الأهداف الرئيسية

• جلب EVM إلى أداء عالي الأداء ومستقر “الحالة النهائية”

• أدخل تجريد الحساب في البروتوكولات بحيث يمكن لجميع المستخدمين الاستفادة من حسابات أكثر أمانًا وأكثر ملاءمة

• تحسين اقتصاد رسوم المعاملات ، وتحسين قابلية التوسع ، وتقليل المخاطر

• استكشف تقنيات التشفير المتقدمة التي يمكن أن تجعل Ethereum أفضل على المدى الطويل

تحسينات EVM

ما هي المشكلات التي يحلها؟

من الصعب إجراء تحليلات EVMs اليوم ، مما يجعل من الصعب إنشاء تطبيقات فعالة ورمز التحقق الرسمي ومزيد من الحجم بمرور الوقت.علاوة على ذلك ، فإنه غير فعال للغاية ، مما يجعل من الصعب تنفيذ أشكال متعددة من التشفير المتقدم ما لم يتم دعمها بشكل صريح عن طريق الولادة.

ما هو وكيف يعمل؟

الخطوة الأولى في خارطة الطريق الحالية لتحسين EVM هي تنسيق كائن EVM (EOF) ، والذي من المقرر أن يتم تضمينه في الشوكة الصلبة التالية.EOF هي سلسلة من EIPs المستخدمة لتحديد إصدارات جديدة من رمز EVM مع العديد من الميزات الفريدة ، وأبرزها:

• الفصل بين الكود (قابل للتنفيذ ، ولكن لا يقرأ من EVM) والبيانات (قابلة للقراءة ، ولكن غير قابلة للتنفيذ).

• القفزات الديناميكية محظورة ، فقط القفزات الثابتة مسموح بها.

• لم يعد بإمكان رمز EVM مراقبة المعلومات المتعلقة بالغاز.

• وأضاف آلية جديدة صريحة الفرعية.

هيكل رمز EOF

ستستمر العقود القديمة في الوجود ويمكن إنشاؤها ، على الرغم من أن العقود القديمة قد يتم إهمالها في النهاية (وربما حتى إجبارها على التحويل إلى رمز EOF).ستستفيد العقود الجديدة من مكاسب الكفاءة التي تقدمها EOF-أولاً ، مع وظائف روتين فرعي ، وسيكون رمز Bytecode أصغر قليلاً ، ثم يتم تقليل وظائف EOF الخاصة المحددة ، أو تكاليف الغاز الخاصة بـ EOF.

مع إدخال EOF ، أصبح من الأسهل تقديم المزيد من الترقيات.الأكثر اكتمالا في الوقت الحاضر هو امتداد evm النيجيج الحسابي (EVM-Max).يقوم EVM-Max بإنشاء مجموعة من العمليات الجديدة المصممة للحساب المعياري ويضعها في مساحة ذاكرة جديدة لا يمكن الوصول إليها من خلال الرموز الأخرى.هذا يسمح باستخدام التحسينات ، مثل تكاثر Montgomery.

فكرة أحدث هي الجمع بين إمكانات EVM-Max مع تعليمات واحدة متعددة البيانات (SIMD).لقد كانت SIMD فكرة عن Ethereum منذ Greg Colvin’s EIP-616.يمكن استخدام SIMD لتسريع مجموعة متنوعة من أشكال التشفير ، بما في ذلك وظائف التجزئة ، والتشفير القائم على المصفوفة 32 بت ، والتشفير المستند إلى DOT.تشكل EVM-Max و SIMD معًا زوجًا من ملحقات EVM الموجهة نحو الأداء.

يبدأ التصميم التقريبي لـ EIP المشترك بـ EIP-6690 ، ثم:

• يسمح (ط) أي رقم فردي أو (2) أي قوة 2 (حتى 2^768) كمعامل

• لكل رمز Opcode EVMMAX (إضافة ، Sub ، MUL) ، لا تستخدم هذا الإصدار 3 أرقام فورية X و Y و Z ، ولكنها تستخدم 7 أرقام فورية: X_START ، X_SKIP ، Y_START .في رمز Python ، ستقوم برامج التشغيل هذه بعمليات تعادل ما يلي:

ما لم تكن في التنفيذ الفعلي ، ستتم معالجتها بالتوازي.

• إذا كان ذلك ممكنًا ، أضف xor ، أو ، أو لا ، والتحول (حلقة و acyclic) إلى 2 modulo على الأقل.وأضاف أيضا iszero (دفع الإخراج إلى المكدس الرئيسي EVM).

سيكون هذا قويًا بما يكفي لتنفيذ تشفير المنحنى الإهليلجي ، تشفير المجال الصغير (على سبيل المثال ، بوسيدون ، وظائف دائرة الدائرية) ، وظائف التجزئة التقليدية (على سبيل المثال ، SHA256 ، Keccak ، Blake) ، والتشفير المستندة إلى مصفوفة DOT.

يمكن أيضًا تنفيذ ترقيات EVM الأخرى ، لكن حتى الآن تلقوا اهتمامًا أقل.

ما الأبحاث المتوفرة؟

eof:https://evmobjectformat.org/

EVM-MAX:https://eips.ethereum.org/eips/eip-6690

سيمد:https://eips.ethereum.org/eips/eip-616

ما هي الأشياء المتبقية التي يجب القيام بها وما هي المفاضلات الموجودة؟

حاليًا ، يتم تضمين خطة EOF في الشوكة الصعبة التالية.على الرغم من أنه من الممكن دائمًا إزالته – تمت إزالة الميزة في الشوكة الصلبة السابقة في اللحظة الأخيرة – ستكون معركة شاقة للقيام بذلك.يعني حذف EOF أنه لن يتم استخدام EOF في أي ترقيات مستقبلية لـ EVM ، والتي يمكن القيام بها ، ولكن قد تكون أكثر صعوبة.

المقايضات الرئيسية لـ EVM هي تعقيد L1 وتعقيد البنية التحتية.EOF هو الكثير من التعليمات البرمجية التي تمت إضافتها إلى تطبيق EVM ، وفحص الكود الثابت معقد للغاية.ومع ذلك ، في المقابل ، نكتسب تبسيط اللغة عالية المستوى ، وتبسيط تنفيذ EVM ، وغيرها من الفوائد.يمكن القول أنه سيتم تضمين خريطة الطريق لتحديد أولويات التحسينات المستمرة على Ethereum L1 وبناءها على EOF.

تتمثل إحدى الوظائف المهمة في تنفيذ شيء مثل EVM-Max Plus SIMD و Benchmark كمية الغاز المطلوبة لمختلف عمليات التشفير.

كيف تتفاعل مع بقية خريطة الطريق؟

يقوم L1 بضبط EVM لجعل L2 أسهل في إجراء نفس التعديلات.سيؤدي التعديل والتعديل الآخر إلى بعض عدم التوافق ، والذي له عيوب خاصة به.بالإضافة إلى ذلك ، يمكن لـ EVM-Max Plus SIMD تقليل تكاليف الغاز للعديد من أنظمة الإثبات ، مما يؤدي إلى L2 أكثر كفاءة.كما أنه يجعل من الأسهل إزالة المزيد من الإجراءات المسبقة عن طريق استبدالها برمز EVM الذي يمكن أن يؤدي نفس المهام دون الحاجة إلى تأثير كبير على الكفاءة.

تجريد الحساب

ما هي المشكلات التي يحلها؟

حاليًا ، لا يمكن التحقق من المعاملات إلا بطريقة واحدة: توقيعات ECDSA.في البداية ، تم تصميم تجريد الحساب لتجاوز هذا والسماح بأن يكون منطق التحقق من الحساب رمز EVM تعسفي.هذا يمكن أن يحقق مجموعة من التطبيقات:

• التبديل إلى تقنية التشفير المقاومة للكمية ؛

• تدوير المفاتيح القديمة (تعتبر على نطاق واسع ممارسة الأمن الموصى بها) ؛

• محفظة متعددة التوقيع ومحفظة الانتعاش الاجتماعي ؛

• قم بتوقيع العمليات ذات القيمة المنخفضة مع عمليات مفتاح وذات قيمة عالية مع مفتاح آخر (أو مجموعة من المفاتيح) ؛

• إن السماح بروتوكولات الخصوصية بالعمل دون أن يقلل أجهزة التوتر بشكل كبير من تعقيدها ويزيل التبعيات المركزية الحرجة.

منذ أن بدأ تجريد الحساب في عام 2015 ، توسع الهدف ليشمل عددًا كبيرًا من “أهداف الراحة” مثل ETH ولكن بعض حسابات ERC20 قادرة على دفع الغاز مع ERC20.يظهر ملخص هذه الأهداف في الجدول التالي:

هنا MPC هي الحوسبة متعددة الأحزاب: تقسيم المفتاح البالغ من العمر 40 عامًا إلى أجزاء متعددة ، وتخزينها على أجهزة متعددة ، وتولد توقيعات باستخدام التشفير دون الجمع مباشرة بين الأجزاء الفردية من المفتاح.

EIP-7702 هو EIP المخطط ليتم تقديمه في الشوكة الصلبة التالية.EIP-7702 هو نتيجة لزيادة الاعتراف بالحاجة إلى توفير تجريد الحساب لجميع المستخدمين ، بما في ذلك مستخدمي EOA ، لتحسين تجربة المستخدم على المدى القصير وتجنب الانقسام إلى نظامين بيئيين.بدأ هذا العمل مع EIP-3074 وبلغت ذروتها في نهاية المطاف في EIP-7702.EIP-7702 “وظيفة الراحة” التي تجعل الحساب التجريدي متاحًا لجميع المستخدمين ، بما في ذلك EOA (الحسابات المملوكة خارجيًا ، أي الحسابات التي يتحكم فيها توقيع ECDSA).

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

ما هذا؟كيف تعمل؟

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

مثال توضيحي على التحدي الرئيسي هو مشكلة الإبطال المتعددة:

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

على مر السنين ، أدت الجهود المبذولة لتوسيع القدرات مع الحد من مخاطر DOS إلى اتفاق على حلول لتحقيق “تجريد الحساب المثالي”: ERC-4337.

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

تم تصميم ERC-4337 كمعيار خارج البروتوكول (ERC) لأن مطوري عميل Ethereum يركزون على الاندماج في ذلك الوقت وليس لديهم قدرة إضافية للتعامل مع وظائف أخرى.هذا هو السبب في أن ERC-4337 يستخدم كائناته الخاصة (تسمى عمليات المستخدم) بدلاً من المعاملات العادية.ومع ذلك ، فقد أدركنا مؤخرًا الحاجة إلى تضمين جزء على الأقل من هذا في الاتفاقية.سببان رئيسيان هما:

• نقطة الالتحاق غير فعالة بطبيعتها كعقد: ثابت ~ 100K الغاز النفقات العامة لكل حزمة وآلاف الرسوم الإضافية لكل عملية مستخدم ؛

• من الضروري التأكد من أن خصائص Ethereum (مثل ضمانات التضمين التي تم إنشاؤها بواسطة قوائم التضمين) تستمر إلى مستخدم Abstract Abstract.

بالإضافة إلى ذلك ، يمتد ERC-4337 أيضًا وظيفتين:

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

• المجددي: يدعم ميزات التجميع المتوقيع مثل BLS التجميع أو التجميع القائم على SNARK.هذا ضروري لتحقيق أعلى كفاءة البيانات في الملخص.

ما الأبحاث المتوفرة؟

الحساب التجريدي السجل مقدمة:https://www.youtube.com/watch؟v=ILF8QPOMXQC

ERC-4337:https://eips.ethereum.org/eips/eip-4337

EIP-7702:https://eips.ethereum.org/eips/eip-7702

رمز Blswallet (باستخدام وظيفة التجميع):https://github.com/getwax/bls-wallet

EIP-7562 (ملخص حساب تضمين):https://eips.ethereum.org/eips/eip-7562

EIP-7701 (EOF المستند إلى AA):https://eips.ethereum.org/eips/eip-7701

ما هي الأشياء المتبقية التي يجب القيام بها وما هي المفاضلات الموجودة؟

والسؤال الرئيسي المتبقي هو كيفية دمج تجريد الحساب بالكامل في الاتفاقية.تجريد الحساب الأكثر شيوعًا هو EIP-7701 ، والذي ينفذ تجريد الحساب أعلى EOF.يمكن أن يكون للحساب قسم رمز منفصل للتحقق ، وإذا كان الحساب قد حدد قسم الرمز ، فسيتم تنفيذ الرمز في خطوة التحقق من معاملة الحساب.

هيكل رمز EOF لحساب EIP-7701

ما يدور حول هذا النهج هو أنه يظهر بوضوح طريقتان معادلتين لعرض تجريدات الحساب الأصلي:

• EIP-4337 ، ولكن كجزء من البروتوكول

• نوع جديد من EOA حيث خوارزمية التوقيع هي تنفيذ رمز EVM

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

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

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

كيف تتفاعل مع بقية خريطة الطريق؟

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

تحسينات EIP-1559

ما هي المشكلات التي يحلها؟

تم إطلاق EIP-1559 على Ethereum في عام 2021 وحسّن بشكل كبير متوسط ​​وقت إدراج الكتلة.

ومع ذلك ، فإن التنفيذ الحالي لـ EIP-1559 ليس مثاليًا بعدة طرق:

• الصيغة معيبة قليلاً: بدلاً من استهداف 50 ٪ من الكتل ، فإنها تستهدف حوالي 50-53 ٪ من الكتل الكاملة بناءً على التباين (وهذا يرتبط بما يسميه علماء الرياضيات “عدم المساواة AM-GM”) ؛

• لا يضبط بسرعة كافية في الظروف القاسية.

تم تصميم الصيغة المستخدمة لاحقًا في BLOBS (EIP-4844) بوضوح لحل المشكلة الأولى وكانت عمومًا أكثر إيجازًا.لم يحاول EIP-1559 نفسها ولا EIP-4844 حل العدد الثاني.لذلك ، فإن الوضع الراهن هو حالة مربكة للتخلي عن منتصف الطريق والتي تنطوي على آليتين مختلفتين ، وحتى واحدة هي أن كلاهما يحتاج إلى تحسن مع مرور الوقت.

بالإضافة إلى ذلك ، يحتوي تسعير موارد Ethereum على نقاط ضعف أخرى لا تتعلق بـ EIP-1559 ، ولكن يمكن حلها عن طريق ضبط EIP-1559.إحدى المشكلات الرئيسية هي الفرق بين المتوسط ​​وأسوأ سيناريو: يجب تعيين سعر المورد في Ethereum ليكون قادرًا على التعامل مع سيناريو أسوأ الحالات ، أي أن الغاز الكامل للكتلة يستهلك موردًا ، ولكن متوسط ​​الاستخدام أقل بكثير بهذه الطريقة ، يحدث عدم الكفاءة.

ما هذا؟كيف تعمل؟

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

لدينا غاز متعدد الأبعاد للتنفيذ والنقاط اليوم ؛

يقدم EIP-7706 بعد غاز جديد لبيانات الاتصال.في الوقت نفسه ، فإنه يحل أيضًا العيوب الرياضية لـ EIP-1559 عن طريق تبسيط آلية الغاز متعددة الأبعاد عن طريق جعل الأنواع الثلاثة من الغازات تنتمي إلى إطار (EIP-4844-Style).

يعد EIP-7623 حلاً أكثر دقة لمشكلات الموارد المتوسطة والأسوأ ، مما يحد بشكل أكبر من أقصى بيانات الاتصال دون تقديم أبعاد جديدة تمامًا.

يتمثل الاتجاه الإضافي في حل مشكلة معدل التحديث وإيجاد خوارزمية حساب أساسية أسرع للرسوم مع الاحتفاظ بالمثورين الرئيسيين المقدمة من آلية EIP-4844 (أي أن متوسط ​​الاستخدام قريب تمامًا من الهدف على المدى الطويل).

ما الأبحاث المتوفرة؟

eip-1559 الأسئلة الشائعة:https://notes.ethereum.org/@vbuterin/eip-1559-faq

EIP-1559 التحليل التجريبي:https://dl.acm.org/doi/10.1145/3548606.3559341

التحسينات الموصى بها للسماح بالتعديلات السريعة:https://kclpure.kcl.ac.uk/ws/portalfiles/portal/180741021/transaction_fees_on_a_honeymoon_ethereums_eip_1559_one_month_later.pdf

EIP-4844 الأسئلة الشائعة ، قسم عن آلية الرسوم الأساسية:https://notes.ethereum.org/@vbuterin/proto_danksharding_faq#how-does-the-exponential-eip-1559-lob-fee-adjustment-mischanism-work

EIP-7706:https://eips.ethereum.org/eips/eip-7706

EIP-7623:https://eips.ethereum.org/eips/eip-7623

غاز متعدد الأبعاد:https://vitalik.eth.limo/general/2024/05/09/multidim.html

ما هي الأشياء المتبقية التي يجب القيام بها وما هي المفاضلات الموجودة؟

هناك نوعان من المفاضلات الرئيسية للغاز متعدد الأبعاد:

• يزيد من تعقيد البروتوكول

• يزيد من تعقيد أفضل الخوارزمية المطلوبة لملء الكتل إلى السعة

يعد تعقيد البروتوكول مشكلة صغيرة نسبيًا لـ CallData ، ولكن مشكلة أكبر لأبعاد الغاز “داخل EVM” (مثل قراءة التخزين والكتابة).المشكلة هي أنها ليست فقط حدود غاز المستخدم: تقوم العقود أيضًا بتعيين قيود عند استدعاء العقود الأخرى.والآن ، فإن الطريقة الوحيدة التي يضعون فيها القيود هي أحادية البعد.

تتمثل إحدى الطرق السهلة للقضاء على هذه المشكلة في جعل الغاز متعدد الأبعاد متاحًا فقط داخل EOF ، لأن EOF لا تسمح للعقود بتعيين حدود الغاز عند استدعاء العقود الأخرى.يجب أن تدفع العقود غير EOF جميع أنواع رسوم الغاز عند إجراء عمليات التخزين (على سبيل المثال ، إذا كان Sload ينفق 0.03 ٪ من حد غاز الوصول إلى تخزين الكتلة ، سيتم أيضًا فرض رسوم على المستخدمين من غير EOF 0.03 ٪ من حد الغاز للتنفيذ)

إن إجراء المزيد من الأبحاث حول الغاز متعدد الأبعاد سيساعد على فهم المقايضات وإيجاد التوازن المثالي.

كيف تتفاعل مع بقية خريطة الطريق؟

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

كما ذكر أعلاه ، نظرًا لأن EOF غير قابل للملاحظة ، فإن الإصدارات المتعددة الأبعاد الأكثر تطرفًا من الغاز أسهل في التنفيذ.

وظيفة التأخير التي تم التحقق منها (VDF)

ما هي المشكلات التي يحلها؟

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

ما هذا؟كيف تعمل؟

وظيفة التأخير التي يمكن التحقق منها هي وظيفة لا يمكن حسابها إلا بالترتيب ولا يمكن تسريعها بالتوازي.مثال بسيط هو تكرار التجزئة: حساب i: x = التجزئة (x) في النطاق (10 ** 9).يثبت الإخراج من خلال صحة Snark ويمكن استخدامه كقيمة عشوائية.الفكرة هي أنه يتم تحديد الإدخال استنادًا إلى المعلومات المتوفرة في الوقت T ، في حين أن الإخراج غير واضح في الوقت T: سيكون متاحًا فقط في وقت ما بعد أن يقوم شخص ما بتشغيل الحساب بالكامل.نظرًا لأن أي شخص يمكنه تشغيل الحساب ، فمن المستحيل إخفاء النتائج وبالتالي ليس لديه القدرة على معالجة النتائج.

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

• تسريع الأجهزة: قام شخص ما بعمل ASIC الذي تعمل حلقة حسابية أسرع بكثير من الأجهزة الموجودة.

• التوازي غير المتوقع: وجد شخص ما طريقة لتشغيل الوظيفة بشكل أسرع من خلال التوازي ، حتى لو استغرق الأمر أكثر من 100 مرة من المورد.

تتمثل مهمة إنشاء VDF ناجحة في تجنب كلتا القضيتين مع بقاء كفاءة وعملية (على سبيل المثال ، إحدى المشكلات في الأساليب القائمة على التجزئة هي أن Snark في الوقت الفعلي يثبت أنه مطلوب من الأجهزة).غالبًا ما يتم حل تسريع الأجهزة عن طريق السماح للجهات الفاعلة المصلحة العامة بإنشاء وتوزيع قريبة بشكل معقول من ASICs المثلى لـ VDFs نفسها.

ما الأبحاث المتوفرة؟

vdfresearch.org:https://vdfresearch.org/

أفكار حول الهجمات على VDFs المستخدمة في Ethereum في عام 2018:https://ethreesear.ch/t/verifiable-delay-functions-and-thacks/2365

الهجوم على minroot (VDF مقترح):https://inria.hal.science/hal-04320126/file/minrootanalysis2023.pdf

ما هي الأشياء المتبقية التي يجب القيام بها وما هي المفاضلات الموجودة؟

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

كيف تتفاعل مع بقية خريطة الطريق؟

VDF هو مكون مستقل نسبيًا من بروتوكول Ethereum ، ولكن بالإضافة إلى تحسين أمان اختيار المقترح ، يمكن أيضًا استخدامه في (1) تطبيقات على السلسلة التي تعتمد على العشوائية ، وكذلك الذاكرة المشفرة (ii) المحتملة (ii) حمامات السباحة.

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

الارتباك والتوقيع لمرة واحدة: مستقبل التشفير

ما هي المشكلات التي يحلها؟

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

“بروتوكول موثوق به من الناحية الرياضية” ، الرسم البياني الذي رسمه نيك سزابو

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

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

لكن ZK-SNARK هي الأولى من بين ثلاثة بدايات عالمية قوية للغاية.هذه البروتوكولات قوية للغاية لدرجة أنه عندما أفكر فيها ، فإنهم يذكرونني بمجموعة قوية للغاية من البطاقات في Yu-Gi-Oh ، وهي لعبة ورق وبرنامج تلفزيوني لعبت كطفل في كثير من الأحيان وأرى: بطاقة إله المصرية.بطاقات الإله المصرية هي ثلاث بطاقات قوية للغاية ، ووفقًا للأسطورة ، فإن جعلها قاتلة وقوية لدرجة لا يُسمح لها باستخدام المبارزات.وبالمثل ، في التشفير ، لدينا ثلاثة بروتوكولات إله مصرية:

ما هذا؟كيف تعمل؟

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

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

Cursive هو تطبيق يستخدم كل من الحوسبة و FET لاكتشاف الخصوصية.

لكن لدى FHE حدوده: لا تزال أي تقنية تستند إلى FHE تتطلب من شخص ما أن يحمل مفتاح فك التشفير.قد يكون هذا إعدادًا موزعًا لـ M-of-N ، يمكنك حتى إضافة دفاع الطبقة 2 باستخدام Tee ، لكن هذا لا يزال قيدًا.

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

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

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

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

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

• ثم ، نضيف ZK-Snark.الآن ، لدينا الخصوصية: كل تصويت مجهول ، مع ضمان أن الناخبين المعتمدين فقط يمكنهم التصويت ، وأن كل ناخب يمكنه التصويت مرة واحدة فقط.

• الآن ، نضيف آلية MACI.يتم تشفير التصويت على مفتاح فك التشفير للخادم المركزي.يحتاج الخادم المركزي إلى تشغيل عملية حساب التصويت ، بما في ذلك التخلص من الأصوات المكررة ونشر ZK-Snark الذي يثبت الإجابة.يحتفظ هذا بالضمان السابق (حتى لو كان الخادم يخدع!) ، ولكن إذا كان الخادم صادقًا ، فإنه يضيف ضمانًا إلزاميًا للمقاومة: لا يمكن للمستخدم إثبات كيفية تصويته ، حتى لو أرادوا.هذا لأنه على الرغم من أن المستخدمين يمكنهم إثبات التصويت الذي صوتوا فيه ، إلا أنهم لا يستطيعون إثبات أنهم لم يقوموا بصوت آخر لإلغاء التصويت.هذا يمنع الرشوة والهجمات الأخرى.

• ندير العد داخليًا في FHE ثم فك تشفيره عن طريق إجراء حسابات فك تشفير عتبة N/2-OF-N.هذا يجعل المقاومة الإلزامية مضمونة لتكون n/2-of-n ، وليس 1 من 1.

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

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

يمكن أن يمكّن التغلب العشوائي أيضًا تطبيقات قوية أخرى.على سبيل المثال:

• DAO ، المزادات على السلسلة والتطبيقات الأخرى مع أي حالة سرية داخلية.

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

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

• تجمع الذاكرة المشفرة.أصبحت معاملات التشفير سهلة للغاية لدرجة أنها لن يتم فك تشفيرها إلا إذا حدثت أحداث معينة على السلسلة في المستقبل.قد يشمل هذا حتى التنفيذ الناجح لـ VDFs.

مع التوقيعات لمرة واحدة ، يمكننا حماية blockchain من هجمات الانعكاس النهائية 51 ٪ ، على الرغم من أن هجمات الرقابة قد لا تزال موجودة.يمكن أن تنفذ البدائية المشابهة لتوقيعات لمرة واحدة العملات الكمومية وحل مشكلة الدفع المزدوج دون blockchain ، على الرغم من أن العديد من التطبيقات الأكثر تعقيدًا لا تزال تتطلب blockchain.

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

ما الأبحاث المتوفرة؟

اتفاقية التشويش العشوائية لعام 2021:https://eprint.iacr.org/2021/1334.pdf

الارتباك كيفية مساعدة Ethereum:https://ethreesear.ch/t/how-obfuscation-can-help-ethereum/7380

أول بنية توقيع لمرة واحدة معروفة:https://eprint.iacr.org/2020/107.pdf

محاولات شديدة التنفيذ (1):https://mediatum.ub.tum.de/doc/1246288/1246288.pdf

محاولات شديدة التنفيذ (2):https://github.com/sorasuegami/iomaker/tree/main

ما هي الأشياء المتبقية التي يجب القيام بها وما هي المفاضلات الموجودة؟

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

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

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

كيف تتفاعل مع بقية خريطة الطريق؟

يمكن أن تكون تقنية التشفير القوية للغاية بمثابة تغيير للألعاب.على سبيل المثال:

• إذا حصلنا على ZK-Snark الذي يسهل التحقق منه كتوقيع ، فقد لا نحتاج إلى أي بروتوكول تجميع ؛

• قد تعني التواقيع لمرة واحدة إثباتًا أكثر أمانًا لاتفاق الحصة.

• يمكن استبدال العديد من بروتوكولات الخصوصية المعقدة بـ EVMs “فقط” المحمية بالخصوصية.

• تصبح تجمعات الذاكرة المشفرة أسهل في التنفيذ.

أولاً ، ستحدث الفوائد في طبقة التطبيق ، لأن Ethereum L1 يحتاج بشكل أساسي إلى أن يكون محافظًا على افتراضات الأمن.ومع ذلك ، حتى باستخدام طبقة التطبيق وحدها يمكن أن يكون مغير اللعبة ، تمامًا مثل ظهور ZK-Snark.