فيتاليك: مستقبل بروتوكول الإيثريوم – The Splurge

المؤلف: فيتاليك، مؤسس إيثريوم؛ المترجم: دينج تونج، جولدن فاينانس

ملاحظة: هذه المقالة هي السادسة في سلسلة من المقالات حول "التطور المستقبلي لبروتوكول إيثريوم" التي نشرتها مؤخرًا فيتاليك، مؤسس إيثريوم الجزء "العقود المستقبلية المحتملة لبروتوكول إيثريوم، الجزء 6: ال Splurge"، يمكن العثور على الجزء 5 على "فيتاليك: المستقبل المحتمل لبروتوكول إيثريوم - التطهير"، يمكن العثور على الجزء الرابع على "فيتاليك: مستقبل إيثريوم الحافة". يمكن العثور على الجزء الثالث في "Vitalik: الأهداف الرئيسية لمرحلة البلاء في Ethereum"، ويمكن للجزء الثاني يمكن العثور عليها في "فيتاليك: كيف يجب أن يتطور بروتوكول إيثريوم أثناء الطفرة"، للجزء الأول، راجع " <أ href="https://www.jinse.cn/blockchain/3699549.html">ما الذي يمكن تحسينه أيضًا في Ethereum PoS". فيما يلي النص الكامل للجزء السادس:

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

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

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

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

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

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

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

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

تحسينات EVM

ما الذي يحل السؤال؟

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

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

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

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

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

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

• تمت إضافة آلية روتين فرعي صريحة جديدة.

بنية كود EOF

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

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

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

يعتمد التصميم التقريبي لـ EIP المدمج على EIP-6690 كنقطة بداية، ثم:

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

• لكل EVMMAX يضيف Opcode (add، sub، mul) إصدارًا بدلاً من أخذ 3 حركات فورية x، y، z، يأخذ 7 حركات فورية: x_start، x_skip، y_start، y_skip، z_start، z_skip، count. في كود Python، ستقوم أكواد التشغيل هذه بما يعادل:

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

• إذا أمكن، أضف XOR، AND، OR modulo على الأقل قوى 2 , NOT و SHIFT (دوري وغير دوري). تمت إضافة ISZERO أيضًا (دفع الإخراج إلى مكدس EVM الرئيسي).

سيكون هذا قويًا بدرجة كافية لتنفيذ تشفير المنحنى الناقص، وتشفير النطاق الصغير (مثل Poseidon، وSTARK الدائرية)، ووظائف التجزئة التقليدية (مثل SHA256، وKECCAK، وBLAKE) والتشفير القائم على الشبكة.

من الممكن إجراء ترقيات أخرى لـ EVM، لكنها حظيت باهتمام أقل حتى الآن.

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

EOF: https:// evmobjectformat.org/

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

SIMD:https://eips.ethereum.org/EIPS/eip-616

ما الذي بقي؟ المقايضات؟

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

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

أحد الأجزاء المهمة من العمل هو تنفيذ شيء مثل EVM-MAX بالإضافة إلى SIMD وقياس مقدار الطاقة التي تتطلبها عمليات التشفير المختلفة.

كيف يتفاعل مع الأجزاء الأخرى من خريطة الطريق؟

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

تجريد الحساب

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

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

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

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

• p>

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

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

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

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

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

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

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

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

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

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

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

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

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

• مطلوب لضمان نقل خصائص Ethereum (مثل ضمانات التضمين التي أنشأتها قوائم التضمين) إلى حسابات المستخدم الملخص؛ .

بالإضافة إلى ذلك، يقوم 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 ( AA المضمن استنادًا إلى EOF): https://eips.ethereum.org/EIPS/eip-7701

ما الذي بقي؟ المقايضات؟

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

< نمط الامتداد = "حجم الخط: 14px;">بنية كود EOF لحسابات EIP-7701

الشيء الرائع في هذا النهج هو أنه يوضح بوضوح طريقتين متكافئتين لعرض تجريد الحساب الأصلي:

• EIP-4337، ولكن كجزء من الاتفاقية

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

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

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

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

كيف يتفاعل مع الأجزاء الأخرى من خريطة الطريق؟

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

تحسينات EIP-1559

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

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

ومع ذلك، EIP- يعتبر التنفيذ الحالي للقرار 1559 غير كامل من عدة جوانب:

• هذه الصيغة معيبة بعض الشيء: فبدلاً من استهداف 50% من الكتل، فإنها تستهدف ~50- استهداف 53% من الكتل الكاملة (وهذا له علاقة بما يسميه علماء الرياضيات "عدم المساواة AM-GM")؛

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

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

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

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

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

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

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

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

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

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

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

التحسينات المقترحة للسماح بإجراء تعديلات سريعة:h ttps://kclpure.kcl.ac.uk/ws/portalfiles/portal/180741021/Transaction_Fees_on_a_Honeymoon_Ethereums_EIP_1559_One_Month_Later.pdf

الأسئلة الشائعة حول EIP-4844، حول آلية الرسوم الأساسية: h ttps://notes.ethereum.org/@vbuterin/proto_danksharding_faq#How-does-the-exponential-EIP-1559-blob-fee-adjustment-mechanism-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

ما الذي بقي للقيام به وما هي المقايضات؟

للغاز متعدد الأبعاد مقايضتان رئيسيتان:

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

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

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

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

كيف يتفاعل مع الأجزاء الأخرى من خريطة الطريق؟

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ما الذي بقي للقيام به وما هي المقايضات؟

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

كيف يتفاعل مع الأجزاء الأخرى من خريطة الطريق؟

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

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

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

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

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

"البروتوكولات الجديرة بالثقة رياضيًا"، رسم تخطيطي لنيك زابو

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

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

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

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

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

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

Cursive هو تطبيق يستخدم الحساب المتبادل وFHE لاكتشاف المصالح المشتركة للحفاظ على الخصوصية.

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

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

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

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

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

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

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

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

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

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

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

يمكن أن يؤدي ارتباك عدم التمييز إلى تمكين تطبيقات قوية أخرى. على سبيل المثال:

• المنظمات اللامركزية المستقلة والمزادات عبر السلسلة والتطبيقات الأخرى ذات التحكم الداخلي العشوائي برنامج الدول السرية.

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

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

• مجموعة الذاكرة المشفرة. يصبح من السهل جدًا تداول العملات المشفرة بحيث لا يمكن فك تشفيرها إلا عند حدوث بعض الأحداث على السلسلة في المستقبل. قد يتضمن هذا أيضًا تنفيذ VDF ناجحًا.

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

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

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

بروتوكول تشويش عدم التمييز لعام 2021: https://eprint.iacr.org/2021/1334.pdf

كيف يمكن أن يساعد التشويش إيثريوم: https://ethresear.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 بتات، أو ليست حواسيب كمومية حقيقية، على الرغم من أنها قد تحتوي على الأجزاء الكمومية، لكنها لا تستطيع إجراء حسابات ذات معنى حقيقي، مثل خوارزمية شور أو خوارزمية جروفر. في الآونة الأخيرة، ظهرت دلائل تشير إلى أن أجهزة الكمبيوتر الكمومية "الحقيقية" لم تعد بعيدة جدًا. ومع ذلك، حتى لو أصبحت أجهزة الكمبيوتر الكمومية "الحقيقية" متاحة قريبًا، فإن اليوم الذي يمتلك فيه الأشخاص العاديون جهاز كمبيوتر كميًا على أجهزة الكمبيوتر المحمولة أو الهواتف المحمولة الخاصة بهم قد يستغرق عقودًا قبل أن تتمكن المؤسسات القوية من الوصول إلى جهاز كمبيوتر كمي قادر على كسر تشفير المنحنى الإهليلجي.

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

كيف يتفاعل مع الأجزاء الأخرى من خريطة الطريق؟

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

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

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

• يمكن استبدال العديد من بروتوكولات الخصوصية المعقدة بـ "فقط" وجود جهاز EVM يحافظ على الخصوصية.

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

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