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

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

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

---

شكر خاص لجوستين دريك ، Hsiao-Wei Wang ، Guillaume Ballet ، Ignacio ، Josh Rudolf ، Lev Soukhanov ، Ryan Sean Adams و Uma Roy على ملاحظاتهم ومراجعتهما.

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

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

The Verge ، 2023 خريطة الطريق.

في البداية ، يشير “Verge” إلى فكرة نقل تخزين حالة Ethereum إلى أشجار Verkle – وهي عبارة عن بنية شجرة تسمح بمزيد من الأدلة المدمجة التي تتيح التحقق من كتل Ethereum عديمة الجنسية.يمكن للعقد التحقق من كتل Ethereum دون أي حالة Ethereum (رصيد الحساب ، رمز العقد ، التخزين …) على محرك الأقراص الثابتة ، ولكن على حساب إنفاق مئات من بيانات الإثبات ومئات المللي ثانية من الوقت الإضافي للتحقق من الدليل.اليوم ، تمثل Verge رؤية أكبر تركز على تحقيق أقصى قدر من التحقق من كفاءة الموارد لسلسلة Ethereum ، والتي لا تتضمن فقط تقنية التحقق عديمة الجنسية ، ولكن أيضًا التحقق من صحة جميع عمليات إعدام Ethereum باستخدام Snark.

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

لذلك ، على مدار العام الماضي ، أصبحت Verge أكثر انفتاحًا وهناك إمكانيات متعددة.

حافة: أهداف المفتاح

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

• (على المدى الطويل) سلسلة التحقق الشاملة (الإجماع والتنفيذ) على الساعات الذكية.قم بتنزيل بعض البيانات ، والتحقق من snark ، والانتهاء.

في هذه المقالة ، يتم تسليط الضوء على المحتوى التالي:

• التحقق عديم الجنسية: Verkle أو Starks

• دليل على صحة تنفيذ EVM

• إثبات صحة الإجماع

التحقق عديم الجنسية: Verkle أو Starks

ما هي المشاكل التي نريد حلها؟

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

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

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

التحقق من عدم الجنسية هو تقنية تسمح للعقد بالتحقق من الكتل دون وجود حالة كاملة.بدلاً من ذلك ، تأتي كل كتلة مع شاهد ، يتضمن قيمًا (1) في موقع معين في الحالة التي ستحصل عليها الكتلة (مثل الكود والتوازن والتخزين) و (2) دليل التشفير لهذه القيم صحيح.

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

• إنه سداسيسغرام (على سبيل المثال ، كل عقدة لديها 16 عقدة طفل).هذا يعني أنه في المتوسط ​​، فإن الدليل في شجرة من الحجم n لديه 32*(16-1)*log16 (n) = 120*log2 (n) بايت ، أو حوالي 3840 بايت في شجرة 232 عنصر.بالنسبة للأشجار الثنائية ، هناك حاجة إلى 32*(2-1)*log2 (n) = 32*log2 (n) بايت ، أي حوالي 1024 بايت.

• هذا الرمز ليس merkelized.هذا يعني أن أي وصول إلى رمز الحساب مطلوب لتوفير الرمز الكامل ، بحد أقصى طول قدره 24000 بايت.

يمكننا حساب أسوأ حالة على النحو التالي:

30،000،000 غاز / 2400 (تكلفة قراءة حساب “البرد”) * (5 * 480 + 24،000) = 330،000،000 بايت

تكاليف الفرع أقل قليلاً (5*480 بدلاً من 8*480) ، لأنه عندما يكون هناك العديد من الفروع ، سيتم تكرار الجزء العلوي من الفرع.ولكن على الرغم من ذلك ، فإن كمية البيانات التي تم تنزيلها في فتحة واحدة غير واقعية تمامًا.إذا حاولنا لفه في Stark ، لدينا مشكلتان: (1) Keccak ليس ودودًا بالنسبة إلى Stark ، (II) 330 ميجابايت من البيانات يعني أنه يتعين علينا إثبات 5 ملايين مكالمة إلى وظيفة Round Confer حتى لو تمكنا من جعل Stark يثبت أن Keccak أكثر كفاءة ، فهناك الكثير من الأشياء التي لا يمكن إثباتها على جميع الأجهزة إلى جانب أقوى أجهزة المستهلكين.

إذا استبدلنا hexagram فقط بشجرة ثنائية وأضفنا رمز merkelize ، فستكون أسوأ حالة حوالي 30،000،000 / 2،400 * 32 * (32 – 14 + 8) = 10،400،000 بايت ~ 214 فرعًا ، 8 منها دليل على دخول الطول ورقة).لاحظ أن هذا يتطلب تغيير تكلفة الغاز للوصول إلى كل كتلة رمز فردية ؛10.4 ميغابايت أفضل بكثير ، ولكن بالنسبة للعديد من العقد ، لا يزال هناك الكثير من البيانات التي يمكن تنزيلها في فتحة واحدة.لذلك نحن بحاجة إلى تقديم بعض التقنيات الأكثر قوة.للقيام بذلك ، هناك حلان رئيسيان: شجرة Verkle وشجرة التجزئة الثنائية.

شجرة فيركل

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

لذلك ، يصبح حجم فرع واحد في الدليل 32*log256 (n) = 4*log2 (n) بايت.من الناحية النظرية ، يصبح الحد الأقصى لحجم الإثبات حوالي 30،000،000/2،400*32*(32-14+8)/8 = 1،300،000 بايت (الحسابات الرياضية مختلفة قليلاً في الممارسة العملية بسبب توزيع غير متساوٍ لكتل ​​الحالة ، ولكن هذا هو الأول جيد جدًا) .

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

نستخدم أيضًا هذا التحذير لفعل شيء آخر: نحن نجعل الوصول إلى التخزين “المجاور” رخيص جدًا: العديد من كتل التعليمات البرمجية من نفس العقد ، أو فتحات التخزين المجاورة.يوفر EIP-4762 تعريفًا متاخمًا ، ويتم فرض رسوم على الوصول إلى 200 رسوم غاز فقط.للوصول المجاور ، يصبح حجم إثبات أسوأ الحالات 30،000،000/200*32 = 4،800،800 بايت ، والتي لا تزال ضمن نطاق التسامح تقريبًا.إذا أردنا تقليل هذه القيمة للأمان ، فيمكننا زيادة تكلفة الوصول المجاور قليلاً.

شجرة التجزئة الثنائية ذات البطولة

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

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

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

• قم بإجراء الكثير من التحليل الأمني ​​بسرعة على Poseidon وكن على دراية به لنشره على L1

• استخدم وظيفة التجزئة “المحافظة” ، مثل SHA256 أو Blake

في وقت كتابة هذا التقرير ، لم يكن بإمكان Prover Stark’s Starkware أن يثبت سوى حوالي 10-30 ألف علامة تجزئة في الثانية على جهاز كمبيوتر محمول للمستهلك إذا أراد إثبات وظيفة التجزئة المحافظة.ومع ذلك ، فإن تقنية ستارك تتقدم بسرعة.حتى اليوم ، تُظهر التكنولوجيا المستندة إلى GKR إمكانية زيادتها إلى نطاق 100-200K تقريبًا.

حالات استخدام الشهود بخلاف كتل التحقق

بالإضافة إلى كتلة التحقق ، هناك ثلاث حالات أخرى لاستخدام المفاتيح التي تتيح التحقق من أكثر كفاءة عديمة الجنسية:

• تجمع الذاكرة:عند بث المعاملة ، تحتاج العقد في شبكة P2P إلى التحقق من أن المعاملة صالحة قبل إعادة البث.اليوم ، لا يتضمن التحقق ليس فقط التحقق من التوقيع ، ولكن أيضًا التحقق من أن الرصيد كافٍ وأن الرقم العشوائي صحيح.في المستقبل (على سبيل المثال ، باستخدام تجريدات الحساب الأصلي ، مثل EIP-7701) ، قد يتضمن ذلك تشغيل بعض رمز EVM الذي يؤدي بعض الوصول إلى الدولة.إذا كانت العقدة عديمة الجنسية ، فستتطلب المعاملة إثباتًا مع دليل على كائن الحالة.

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

• العميل الخفيف:إذا كنا نريد من المستخدمين الوصول إلى السلسلة من خلال محافظ (مثل Metamask و Rainbow و Rabby …) دون الوثوق بالمشاركين المركزيين ، فإنهم بحاجة إلى تشغيل عميل خفيف (مثل Helios).توفر وحدة Helios الأساسية للمستخدمين جذر الحالة المصادق عليه.ومع ذلك ، من أجل الحصول على تجربة غير موثوقة تمامًا ، يحتاج المستخدمون إلى تقديم دليل على كل مكالمة RPC الفردية التي يقومون بها (على سبيل المثال ، لطلب eth_call ، يحتاج المستخدمون إلى دليل على جميع الدول التي يتم الوصول إليها أثناء المكالمة) ؛

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

ما هي الروابط مع الأبحاث الحالية؟

شجرة فيركل:https://vitalik.eth.limo/general/2021/06/18/verkle.html

ورقة شجرة فيركل الأصلية من جون كوسزموول:https://math.mit.edu/research/highschool/primes/materials/2018/kuszmaul.pdf

بيانات إثبات Starkware:https://x.com/starkwareltd/status/1807776563188162562

ورقة poseidon2:https://eprint.iacr.org/2023/323

Ajtai (وظيفة التجزئة السريعة البديلة على أساس صلابة الشبكة):https://www.wisdom.weizmann.ac.il/~oded/col/cfh.pdf

verkle.info:https://verkle.info/

ما الذي يجب القيام به وما هي المفاضلات التي يجب وزنها؟

المهام الرئيسية المتبقية التي يتعين القيام بها هي:

• مزيد من التحليل لعواقب EIP-4762 (تغييرات تكلفة الغاز عديمة الجنسية)

• المزيد من إجراءات الانتهاء من العمل واختبارها ، وهو جزء كبير من أي تعقيد EIP عديمي الجنسية

• المزيد من التحليل الأمني ​​ل poseidon ، Ajtai ، وغيرها من وظائف التجزئة “الصديقة”

• مزيد من تطوير بروتوكولات صاروخية فائقة الكفاءة لوظائف التجزئة “المحافظة” (أو “التقليدية”) ، مثل الفكرة القائمة على Binius أو GKR.

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

بالإضافة إلى “أرقام العنوان” هذه ، هناك بعض الاعتبارات المهمة الأخرى:

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

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

• الخامستتمتع شجرة Erkle بخصائص تحديث الشهود المثيرة للاهتمام– Verkle Tree Witness يتم تحديثه.هذه الخاصية مفيدة لمجمعات الذاكرة ، وتشمل القوائم وحالات الاستخدام الأخرى ، وقد تساعد أيضًا في تحقيق الكفاءة: إذا قمت بتحديث كائن الحالة ، فيمكنك تحديث الشاهد على مستوى ما قبل الأخير حتى قراءة المستوى الأخير.

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

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

إذا ثبت أن النظام غير فعال بما فيه الكفاية في أسوأ الحالات ، فيمكننا تعويض هذا العيب مع “أرنب في القبعة” آخر ، وهو غاز متعدد الأبعاد: الوصول إلى (1) Calldata ، (2) الحوسبة ، ( (3) الدولة وربما الموارد المختلفة الأخرى لها قيود غاز منفصلة.يضيف الغاز متعدد الأبعاد التعقيد ، ولكن في مقابلته يحد بشكل أكبر من النسبة بين المتوسط ​​وأسوأ سيناريو الحالات.بالنسبة للغاز متعدد الأبعاد ، قد يتم تخفيض الحد الأقصى لعدد الفروع النظرية التي يجب إثباتها من 30،000،000 / 2400 = 12500 إلى 3000.هذا سيجعل blake3 (بالكاد) كافية حتى اليوم ، دون مزيد من التحسينات إثبات.

يتيح الغاز متعدد الأبعاد قيود موارد الكتلة لتكرار قيود موارد الأجهزة الأساسية أقرب إلى تلك الموجودة في الأجهزة الأساسية.

آخر “التنفس الذي يظهر” هو الاقتراح لتأخير حساب جذر الدولة حتى بعد الكتلة.سيعطينا هذا 12 ثانية كاملة لحساب جذر الحالة ، مما يعني أنه حتى في الحالات الأكثر تطرفًا ، فإن حوالي 60،000 من الوقت للدليل/الثاني فقط هو ما يكفي ، مما يضعنا مرة أخرى في Blake3 بالكاد بما فيه الكفاية في نطاق الاستخدام.

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

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

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

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

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

دليل على صحة تنفيذ EVM

ما هي المشاكل التي نريد حلها؟

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

لتحقيق ذلك ، يلزم وجود أدلة Snark أو Stark مع (1) طبقة الإجماع (أي إثبات الحصة) و (2) طبقة التنفيذ (أي EVM).الأول يمثل تحديًا في حد ذاته ويجب معالجته في عملية زيادة تحسين طبقة الإجماع (على سبيل المثال ، نهائية واحدة).هذا الأخير يتطلب إثبات تنفيذ EVM.

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

رسميًا ، في مواصفات Ethereum ، يتم تعريف EVM كدالة انتقالية للدولة: لديك بعض الأماكن المسبقة S ، A Block B ، وأنت تقوم بحساب ما بعد الحالة S ‘= STF (S ، B).إذا كان المستخدم يستخدم عميلًا خفيفًا ، فلن يكون لديهم S و S ‘، أو حتى B Full ؛البيان الكامل الذي يجب إثباته هو تقريبًا:

• المدخلات العامة:الجذر السابق للدولة R ، وجذر الحالة الأخير R ‘، و Hash H.

• مدخلات خاصة:الكتلة B ، الكائنات في الحالة التي تم الوصول إليها بواسطة Block Q ، تم تنفيذ نفس الكائن بعد الكتلة Q ‘، دليل الدولة (مثل Merkle Branch) P.

• الاقتراح 1:P هو دليل صحيح على أن Q يحتوي على بعض أجزاء الدولة ممثلة بواسطة R.

• الاقتراح 2:إذا قمت بتشغيل STF على Q ، (i) قم بتنفيذ الكائنات الوصول فقط داخل Q ، (ii) تكون الكتلة صالحة ، و (iii) والنتيجة هي Q ‘.

• الاقتراح 3:إذا قمت بإعادة حساب جذر الحالة الجديد باستخدام المعلومات في Q ‘و P ، فستحصل على R “.

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

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

ما هي الروابط مع الأبحاث الحالية؟

EC PSE ZK-EVM (تم إهمالها الآن لأن هناك خيارات أفضل):https://github.com/privacy-scaling-explorations/zkevm- دوائر

Zeth ، الذي يعمل عن طريق تجميع EVM في RISC-0 ZK-VM:https://github.com/risc0/zeth

مشروع التحقق الرسمي ZK-EVM:https://verified-zkevm.org/

ما الذي يجب القيام به وما هي المفاضلات التي يجب وزنها؟

الآن،دليل صحة EVM لا يكفي في جانبين: الأمن ووقت الإثبات.

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

وقت إثبات سريع بما فيه الكفاية يعني أن أي كتلة Ethereum يمكن إثباتها في أقل من 4 ثوان.اليوم ، ما زلنا بعيدون عن هذا الهدف ، على الرغم من أننا أقرب بكثير مما كنا نظن قبل عامين.لتحقيق ذلك ، نحتاج إلى التقدم في ثلاثة جوانب:

• التوازي – يمكن أن يثبت أسرع Prover EVM اليوم كتلة Ethereum المتوسطة في حوالي 15 ثانية.يفعل هذا من خلال موازاة مئات من وحدات معالجة الرسومات ثم وضع عملهم معًا.من الناحية النظرية ، نحن نعرف بالضبط كيفية صنع المثل EVM يمكن أن يثبت الحساب في O (log (n)) الوقت: دع وحدة معالجة الرسومات تؤدي كل خطوة ثم تنفيذ “شجرة التجميع”:

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

• تحسين نظام الإثبات –قد تؤدي أنظمة إثبات جديدة مثل Orion و Binius و GKR إلى انخفاض كبير في وقت الإثبات لمحسوبة عامة.

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

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

• استبدال بنية البيانات –بالإضافة إلى استبدال شجرة الحالة ببديل أكثر ملاءمة لـ Stark ، نحتاج أيضًا إلى استبدال قوائم المعاملات وأشجار الاستلام والهياكل الأخرى التي تثبت باهظة الثمن.يقوم EIP الخاص بـ Ethan Kissling بنقل بنية المعاملة والاستلام إلى SSZ ([1] [2] [3]) ، خطوة في هذا الاتجاه.

بالإضافة إلى ذلك ، يمكن أن تساعد “الأرانب التي تخرج من القبعة” المذكورة في القسم السابق (الغاز متعدد الأبعاد وجذور الحالة المتأخرة) هنا.ومع ذلك ، تجدر الإشارة إلى أنه على عكس التحقق عديمة الجنسية ، فإن التحقق عديمة الجنسية يعني أن لدينا تقنية كافية للقيام بما نحتاجه اليوم ، وحتى مع هذه التقنيات ، فإن التحقق الكامل ZK-EVM سيتطلب المزيد من العمل-يتطلب عمل أقل.

شيء واحد غير مذكور أعلاه هو الأجهزة الإثبات: إنشاء دليل أسرع باستخدام وحدات معالجة الرسومات و FPGAs و ASIC.تشفير النسيج ، cysic و accseal هم المروجين لهؤلاء الشركات الثلاث.هذا أمر ذي قيمة للغاية بالنسبة إلى المستوى 2 ، ولكن من غير المرجح أن يكون الاعتبار الحاسم للمستوى 1 ، حيث هناك رغبة قوية في الحفاظ على المستوى 1 اللامركزي ، مما يعني أن توليد الإثبات يجب أن يكون في مجموعة فرعية كبيرة ضمن نطاق القدرة .يجب ألا يواجه مستخدمو Ethereum اختناقات في أجهزة شركة واحدة.الطبقة 2 تسمح لمزيد من المفاضلات الجذرية.

هناك المزيد من العمل الذي يتعين القيام به في هذه المجالات:

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

• نحتاج إلى مزيد من التحليل لإيجاد مجموعة مثالية من اختلافات تكلفة الغاز لتقليل وقت الإثبات الأسوأ.

• نحن بحاجة إلى بذل المزيد من الجهد على نظام الإثبات

تتضمن المفاضلات المحتملة هنا:

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

• وقت لا مركزي ووقت المثل:يحتاج المجتمع إلى الاتفاق على “المعيار” لأجهزة المثل المستهدفة.هل من المقبول أن تطلب من الدليل أن يكون كيانًا واسع النطاق؟هل نأمل أن تتمكن أجهزة الكمبيوتر المحمولة للمستهلكين الراقية من إثبات كتلة Ethereum في 4 ثوان؟شيء بينهما؟

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

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

تتم مشاركة التقنيات الأساسية المطلوبة لتنفيذ دليل صحة EVM في الطبقة 1 على نطاق واسع مع مجالين آخرين:

• دليل على صحة الطبقة 2 (أي “ZK Rollups”)

• “Stark Binary Hash Proof” طريقة عديمة الجنسية

يثبت التنفيذ الناجح للصلاحية في المستوى 1 أنه من السهل في نهاية المطاف أن يتنافس: حتى أضعف أجهزة الكمبيوتر ، بما في ذلك الهواتف المحمولة أو الساعات الذكية ، يمكن أن تتجه.هذا يزيد كذلك من قيمة معالجة القيود الأخرى للتجول بشكل فردي (على سبيل المثال ، الحد الأدنى 32 ETH).

علاوة على ذلك ، أثبتت صحة EVM من L1 زيادة كبيرة في حد الغاز لـ L1.

إثبات صحة الإجماع

ما هي المشاكل التي نريد حلها؟

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

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

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

يتم تعريف سلسلة المنارة على أنها وظيفة انتقالية الدولة ، تمامًا مثل EVM.يتم تحديد وظيفة نقل الدولة بثلاثة عوامل:

• ECADD (للتحقق من توقيعات BLS)

• الاقتران (للتحقق من توقيعات BLS)

• تجزئة SHA256 (للقراءة وتحديث الحالة)

في كل كتلة ، نحتاج إلى إثبات 1-16 BLS12-381 ECADDs لكل مصادقة (ربما أكثر من واحدة ، حيث يمكن تضمين التوقيع في مجاميع متعددة).يمكن تعويض ذلك عن طريق تقنيات الحاسوب المسبقة للمجموعة الفرعية ، لذلك يمكننا القول أن كل مصلحة هي BLS12-381 ECADD.اليوم ، هناك حوالي 30000 توقيعات المدقق لكل فترة.في المستقبل ، لنهاية الفتحة الفردية ، قد يتغير هذا في أي من الاتجاهين(انظر التعليمات هنا): إذا اتخذنا المسار “القوي” ، فقد تزداد كل فتحة إلى مليون صدق.وفي الوقت نفسه ، مع المدار SSF ، ستبقى في 32،768 ، أو حتى تقليل إلى 8،1.

كيف يعمل تجميع BLS.يتطلب التحقق من التوقيع الكلي فقط ECADD لكل مشارك ، وليس ECMUL.ولكن لا يزال هناك الكثير لإثباته في 30،000 ecadds.

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

يتمثل أحد التحديات الرئيسية في عملية Proof BLS12-381 في عدم وجود منحنيات ملائمة لها في منحنى منحنى ما يساوي حجم حقل BLS12-381 ، والذي يضيف كمية كبيرة إلى أي نظام إثبات.من ناحية أخرى ، تم تصميم شجرة Verkle المقترحة لـ Ethereum باستخدام منحنيات Bandersnatch ، مما يجعل BLS12-381 نفسه منحنى طبيعي يستخدم في نظام Snark لإثبات فروع Verkle.يمكن أن يوفر التنفيذ البسيط إلى حد ما حوالي 100 G1 في الثانية ؛

بالنسبة لـ SHA256 Hash ، فإن أسوأ سيناريو هو كتلة تحويل الحقبة ، حيث يتم تحديث شجرة التوازن القصيرة للمقاومة بالكامل وعدد كبير من أرصدة المدقق.شجرة التوازن القصيرة للمقاومة ، لا يوجد سوى بايت واحد لكل مصادقة ، لذلك سيتم إعادة صياغة حوالي 1 ميغابايت من البيانات.هذا يعادل 32768 مكالمة SHA256.إذا كان رصيد ألف من الأهمية أعلى أو أقل من العتبة ، فيجب تحديث الرصيد الصحيح في سجل المدقق ، وهو ما يتوافق مع ألف فرع Merkle ، لذلك قد يكون هناك عشرة آلاف من التجزئة.تتطلب آلية الخلط 90 بت لكل مصلحة (وبالتالي 11 ميجابايت من البيانات) ، ولكن يمكن حساب ذلك في أي وقت في عملية الحقبة.بالنسبة لنهاية الفتحة الفردية ، قد تزيد هذه الأرقام أو تنخفض مرة أخرى وفقًا للتفاصيل.يصبح خلط ورق اللعب غير ضروري ، على الرغم من أن المسار قد يعيد بطريقة ما الحاجة إلى خلط ورق اللعب.

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

الكل في الكل ، هناك العديد من التحديات.

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

• تغييرات وظيفة التجزئة:اليوم ، يتم استخدام وظيفة التجزئة “الكاملة” SHA256 ، لذلك بسبب الحشوة ، تتوافق كل مكالمة مع مكالمتين من الوظائف المضغوطة الأساسية.على الأقل ، يمكننا الحصول على ربح 2x عن طريق التبديل إلى وظيفة ضغط SHA256.إذا استخدمنا بوسيدون بدلاً من ذلك ، فيمكننا الحصول على حوالي 100x ربح ، مما يحل كل مشاكلنا بالكامل (على الأقل بالنسبة للتجزئة): 1.7 مليون تجزئة في الثانية (54 ميجابايت) وحتى “قراءة مليون” سجلات التحقق “” يمكن أن تثبت ذلك في ثوان.

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

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

• مخططات توقيع أخرى:بالنسبة لتوقيع Lamport+Merkle ، نحتاج إلى 256+32 تجزئة للتحقق من التوقيع ؛يمكن تحسين تحسين مخطط التوقيع من خلال عامل ثابت صغير.إذا استخدمنا بوسيدون ، فهذا ضمن نطاق الدليل داخل فتحة واحدة.ولكن في الواقع ، مع مخطط التجميع العودية ، يصبح هذا أسرع.

ما هي الروابط مع الأبحاث الحالية؟

موجزة ، إثبات إجماع Ethereum (اللجنة المتزامنة فقط):https://github.com/succinctlabs/eth-proof-of-consensus

بسيطة ، هيليوس في SP1:https://github.com/succinctlabs/sp1-helios

موجز BLS12-381 مسبق:https://blog.succinct.xyz/succinctshipsprocompiles/

التحقق من توقيع تجميع BLS المستند إلى HALO2:https://ethreesear.ch/t/zkpos-with-halo2-pairing-for-verification-aggregate-bls-signatures/14671

ما الذي يجب القيام به وما هي المفاضلات التي يجب وزنها؟

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

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

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

يجب أن يكون Stark Friendly هو التركيز الرئيسي لإعادة التصميم على المدى الطويل لإجماع Ethereum Proof-Of-Stake ، وأبرزها نهائيات المنحمة الواحدة ، والمدار ، وتغييرات مخطط التوقيع وتجميع التوقيع.