فيتاليك حول مستقبل إيثريوم (4): The Verge

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

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

الجانب 2023 خريطة الطريق

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

بالإضافة إلى متابعة SNARK للتحقق من صحة السلسلة بشكل دائم، هناك مشكلة جديدة متعلقة بما إذا كانت شجرة Verkle هي أفضل تقنية. يمكن أن تتعرض شجرة Verkle بسهولة للهجمات الكمبيوتر الكمي، لذلك إذا قمنا بتبديل شجرة Verkle في الشجرة الحالية لـ KECCAK Merkle Patricia، فسيتعين علينا استبدال الشجرة مرة أخرى لاحقًا. الطريقة البديلة الذاتية لشجرة Merkle هي تخطي استخدام فروع Merkle مباشرةً ووضعها في شجرة ثنائية. من الناحية التاريخية، كانت هذه الطريقة تعتبر غير قابلة للتنفيذ بسبب التكلفة وتعقيد التقنية. ومع ذلك، في الآونة الأخيرة، رأينا شركة Starkware تثبت 1700000 إثبات في الثانية باستخدام ckcle STARKs على كمبيوتر محمول، ونظرًا لظهور تقنيات مثل GKB، فإن أوقات إثبات "التجزئة" التقليدية أيضًا تتقلص بسرعة. لذلك، في العام الماضي، أصبح "Verge" أكثر انفتاحًا ولديه عدة احتمالات.

المرتفعات: الهدف الرئيسي

· العميل غير المتصل: يجب ألا يتجاوز مساحة التخزين المطلوبة للعميل الذي يتحقق تمامًا ويُعلَّم العقدة عدة غيغابايت.

· (الطويلة الأجل) التحقق الكامل من سلسلة الكتل (الإجماع والتنفيذ) على الساعة الذكية. قم بتنزيل بعض البيانات والتحقق من SNARK واكتماله.

في هذا الفصل

· عميل بدون حالة: Verkle أو STARKs

· تنفيذ EVM إثبات صحة

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

التحقق غير الحالة: Verkle أو STARKs

نريد حل أي مشكلة؟

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

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

كيف يعمل؟

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

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

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

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

30000000 غاز / 2400 (الحساب البارد تكلفة القراءة) * (5 * 488 + 24000) = 330000000 بايت

تكلفة الفروع تنخفض قليلا (استبدال 5*480 بـ 8*480)، لأن الجزء العلوي منها يتكرر عند وجود فروع كثيرة. ومع ذلك، حتى في فترة زمنية واحدة، فإن كمية البيانات التي يجب تنزيلها ليست واقعية تمامًا. إذا حاولنا تغليفها باستخدام STARK، سنواجه مشكلتين: (i) KECCAK ليس وديًا تجاه STARK؛ (ii) يعني 330 ميغابايت من البيانات أن علينا أن نثبت 5 ملايين مكالمة لوظيفة جولة KECCAK، وهذا قد لا يمكن إثباته لجميع الأجهزة بخلاف الأجهزة الاستهلاكية الأقوى، حتى لو كان بإمكاننا جعل STARK يثبت كفاءة KECCAK.

إذا استبدلنا مباشرة شجرة البيانات الثنائية بشجرة السادس عشري وقمنا بمعالجة Merkle إضافية للشفرة، فإن أسوأ حالة ستصبح تقريبًا 30000000/2400*32*(32-14+8) = 10400000 بايت (حيث 14 هو الطرح المتبقي للفروع الزائدة بقوة 2^14، و 8 هو طول دليل الورقة الداخلية في كتلة الشفرة). يجب الانتباه إلى أن هذا يتطلب تغيير تكلفة الغاز وفرض رسوم على الوصول إلى كل كتلة شفرة بشكل منفصل؛ وهذا بالضبط ما فعله EIP-4762. سيكون سعة 10.4 ميجابايت أفضل بكثير، ولكن بالنسبة للعديد من العقد، فإن كمية البيانات التي يتم تنزيلها في فترة زمنية معينة ما زالت كبيرة للغاية. لذلك، نحتاج إلى إدخال تقنية أكثر قوة. في هذا الصدد، هناك حلول رائدة اثنتان: شجرة Verkle وشجرة تجزئة الهاش الثنائي STARKed.

شجرة Verkle

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

لذلك، يصبح حجم فرع واحد في البرهان هو 32 - 1og256(N) = 4* log2(N) بايت. لذلك، يكون الحجم الأقصى النظري للبرهان حوالي 30000000 / 2400 *32* (32 -14 + 8) / 8 = 130000 بايت (نتيجة الحساب الفعلي تختلف قليلاً بسبب توزيع كتل الحالة غير المتكافئ، ولكن يمكن اعتبارها قيمة تقريبية أولية).

ويجب أيضا الانتباه إلى أن 'أسوأ الحالات' في الأمثلة المذكورة أعلاه ليست الحالة الأسوأ: الحالة الأسوأ هي أن يقوم المهاجم بعمد 'حفر' عناوين العنوانين بشكل مشترك طويل في الشجرة وقراءة البيانات من واحدة منهما، مما قد يؤدي إلى زيادة طول فرع الحالة الأسوأ مرتين. ولكن حتى في مثل هذه الحالة، يبلغ طول البرهان الأسوأ لشجرة Verkle 2.6 ميغابايت، وهو تقريبا متطابق مع بيانات التحقق في أسوأ الحالات حاليا.

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

شجرة التجزئة الثنائية STARKed

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

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

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

تحليل Poseidon بشكل سريع وكبير من الناحية الأمنية، والتعرف عليه بما فيه الكفاية لنشره في L1
استخدام وظيفة تجزئة "أكثر حذرًا" مثل SHA256 أو BLAKE

إذا كنت ترغب في إثبات وظيفة تجزئة محافظة ، فإن دائرة STARK لشركة Starkware يمكنها إثبات 10-30k قيمة تجزئة في الثانية فقط على أجهزة الكمبيوتر المحمولة الاستهلاكية في وقت كتابة هذا المقال. ومع ذلك ، تتحسن تقنية STARK بسرعة. حتى اليوم ، تظهر التقنية القائمة على GKR قدرتها على زيادة هذه السرعة إلى نطاق 100-2O0k.

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

بالإضافة إلى التحقق من الكتل ، هناك ثلاث حالات استخدام رئيسية أخرى تتطلب التحقق غير المتصل بالحالة بشكل أكثر كفاءة:

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

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

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

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

ما هي العلاقات الموجودة مع البحوث الحالية:

· أشجار فيركلي

الأصلي بخصوص شجرة فيركلي من جون كوسمول

· ستاركوير

· ورقة بوسيدون2

· Ajtai (دالة التجزئة البديلة السريعة المعتمدة على صعوبة الشبكة البلورية)

· Verkle.info

ماذا يمكن أن تفعل بعد ذلك؟

العمل الرئيسي المتبقي هو

تحليلات إضافية حول آثار EIP-4762 (تغيير تكاليف الغاز غير الحالة).
القيام بالمزيد من العمل في إكمال واختبار برامج الانتقال، وهذا هو الجزء الرئيسي من تعقيد أي حل تنفيذ بيئة بلا جنسية
تحليل أمان إضافي لوظائف الهاش "STARK-friendly " الأخرى مثل Poseidon و Ajtai
لمزيد من تطوير وظائف بروتوكول STARK فائق الكفاءة 'التجزئة' المحافظة (أو 'التقليدية')، مثل وجهات النظر المستندة إلى Binius أو GKR.

بالإضافة إلى ذلك ، سنقرر قريبًا اختيارًا واحدًا من الخيارات الثلاث التالية: (i) Verkle شجرة ، (ii) وظيفة STARK-friendly التجزئة ، و (iii) وظيفة التجزئة المحافظة. يمكن تلخيص خصائصها تقريبًا في الجدول التالي:

بالإضافة إلى هذه "الأرقام الرئيسية"، هناك عوامل أخرى مهمة أيضًا:

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

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

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

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

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

إذا كان في أسوأ الحالات ، فإن ثبوت عدم كفاية كفاءة النظام يمكننا أن نستخدم غاز متعدد الأبعاد كأداة غير متوقعة لتعويض هذا النقص: لـ (i) calldata؛ (ii) الحساب ؛ (iii) الوصول إلى الحالة وتعيينات الموارد المختلفة المحتملة ، تكون هناك حدود غاز منفصلة. يزيد غاز متعدد الأبعاد من التعقيد ، ولكن كمقابل ، يحد بدقة نسبة الحالة المتوسطة إلى الأسوأ. مع غاز متعدد الأبعاد ، قد ينخفض عدد الفروع القصوى التي يجب إثباتها نظريًا من 12500 إلى مثلاً 3000. وهذا سيجعل BLAKE3 يكفي (بالكاد) حتى اليوم.

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

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

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

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

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

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

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

إثبات صحة تنفيذ EVM

نريد حل أي مشكلة؟

الهدف الطويل الأجل للتحقق من كتلة ETH واضح جدًا - يجب أن يكون من الممكن التحقق من كتلة ETH عن طريق (i) تنزيل الكتلة، أو حتى تنزيل جزء صغير من عينة قابلة للاستخدام من البيانات في الكتلة؛ (ii) التحقق من صغيرة البرهان الصالحة للكتلة. سيكون هذا عملية تستخدم موارد قليلة جدًا ويمكن إكمالها في عميل الجوال والمتصفح، وحتى يمكن إكمالها في سلسلة أخرى (بدون جزء صالح للاستخدام من البيانات).

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

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

من الناحية الشكلية، يتم تعريف EVM في مواصفات إثيريوم كوظيفة تحويل الحالة: لديك بعض الحالة السابقة S، وكتلة B، وأنت تقوم بحساب الحالة اللاحقة S' = STF(S،B). إذا كان المستخدم يستخدم العميل الخفيف، فإنهم لا يمتلكون S و S' بالكامل، ولا حتى E؛ بل على العكس، لديهم جذر حالة سابق R، وجذر حالة لاحق R' وقيمة تجزئة للكتلة H.

· الإدخال العام: جذر الحالة السابقة R، جذر الحالة التالية R'، الكتلة H

· الإدخال الخاص: كيانات الحالة التي يصل إليها كل من كتلة البرنامج B وكتلة البرنامج Q، الكيانات نفسها بعد تنفيذ كتلة البرنامج Q'، والبراهين الحالية (مثل فروع Merkle) P

· الادعاء 1: P هو دليل صالح على أن Q يحتوي على جزء من الحالة التي يمثلها R

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

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

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

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

ما العلاقة بينها وبين الأبحاث الحالية؟

· EFPSE ZK-EVM (تم تعطيله الآن بسبب وجود خيارات أفضل)

· Zeth، يعمل عن طريق ترجمة EVM إلى RISC-0 ZK-VM

· مشروع التحقق الرسمي ZK-EVM

ماذا يمكن أن تفعل بعد ذلك؟

اليوم، يوجد نقص في إثبات صحة نظام المحاسبة الإلكتروني من جهتين: الأمان ووقت التحقق.

إثبات صحة آمن يتطلب ضمان أن SNARK قد قام بالتحقق الفعلي لحسابات EVM وأنه لا توجد ثغرات. تقنيتان رئيسيتان لزيادة الأمان هما العديد من المحققين والتحقق الشكلي. المحققون المتعددون يشير إلى وجود تنفيذات مستقلة متعددة لإثبات الصحة، تماما كما هو الحال مع وجود عملاء متعددين، إذا قام جزء كبير من هذه التنفيذات بإثبات كافٍ لكتلة معينة، سيقوم العميل بقبول تلك الكتلة. التحقق الشكلي ينطوي على استخدام أدوات تستخدم عادة لإثبات النظريات الرياضية، مثل Lean4، لإثبات أن إثبات الصحة يقبل فقط تنفيذ صحيح لمواصفات EVM الأساسية (مثل الدلالة K لـ EVM أو مواصفات طبقة تنفيذ إيثريوم المكتوبة بلغة Python (EELS)).

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

· التوازي - يثبت أسرع مدقق EVM حاليا وجود Ethereum في متوسط 15 ثانية. يقوم بذلك عن طريق موازاة مئات وحدات معالجة الرسومات ثم تجميع عملهم معا في النهاية. من الناحية النظرية ، نحن نعرف بالضبط كيفية إنشاء مدقق EVM يمكنه إثبات الحساب في وقت O (log (N)) : دع وحدة معالجة الرسومات تقوم بكل خطوة ، ثم قم بعمل "شجرة تجميع":

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

· نظام الإثبات محسن - النظام الجديد للإثبات مثل Orion و Binius و GRK والمزيد من المعلومات قد يؤدي إلى اختصار كبير آخر في وقت التحقق من الحسابات العامة.

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

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

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

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

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

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

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

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

الثمن المحتمل هو:

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

· اللامركزية وProof of Stake: تحتاج المجتمع إلى التوافق حول 'المواصفات' المتعلقة بأجهزة الحواسيب المعدة للإثبات. هل يمكن أن تكون المثبتات كيانات ذات مقياس كبير؟ نأمل أن تتمكن أجهزة الكمبيوتر المحمولة ذات الاستهلاك العالي من إثبات كتلة ETH في غضون 4 ثوانٍ؟ أو ربما ما بين الاثنين؟

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

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

تتشارك التكنولوجيا الأساسية المطلوبة لإثبات صحة L1 EVM إلى حد كبير مع مجالين آخرين: 01928374656574839201

· L2 的إثبات صحة（即「ZK rollup」）

· الطريقة غير القائمة على الحالة "STARK الثنائي الدليل التجزئة"

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

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

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

نريد حل أي مشكلة؟

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

الإجماع أسهل بكثير من EVM، ولكن التحدي الذي يواجهه هو أننا لا نمتلك L2 EVM مجمع، لذا يجب إكمال معظم العمل على أي حال. لذا، فإن أي تنفيذ لإثيريوم الإجماع يتطلب 'البدء من جديد'، على الرغم من أن نظام الإثبات نفسه يمكن بناؤه عليه لمشاركة العمل.

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

يتم تعريف سلسلة beacon كدالة لتحويل الحالة، تمامًا مثل EVM. يتألف الدالة الخاصة بتحويل الحالة أساسًا من ثلاثة أجزاء:

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

· توافق (لاختبار توقيع BLS)

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

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

كيف يعمل BLS Aggregation: يتطلب التحقق من التوقيع الإجمالي فقط ECADD واحد لكل مشارك ، بدلاً من ECMUL. ومع ذلك ، فإن 30000 ECADD لا يزال عددًا كبيرًا من الأدلة.

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

تحدٍ رئيسي في إثبات عمليات BLS12-381 هو عدم وجود منحنى ملائم يكون درجة المنحنى مساوية لحجم الحقل BLS12-381 ، مما يزيد من تكلفة أي نظام إثبات بشكل كبير. من ناحية أخرى ، يتم بناء شجرة Verkle المقترحة لـ ETH على منحنى Bandersnatch ، مما يجعل BLS12-381 نفسه يعمل كمنحنى فرعي لإثبات فروع Verkle في نظام SNARK. تنفذ تحقيقًا بسيطًا يمكنه إثبات إضافة 100 G1 في الثانية ؛ لجعل سرعة الإثبات كافية ، فمن المؤكد تقريبًا أنه سيكون هناك حاجة لتقنيات ذكية مثل GKR.

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

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

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

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

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

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

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

ما العلاقة بينها وبين الأبحاث الحالية؟

· عقد إثيريوم المبسط للإجماع (فقط للمجلس المتزامن)

· هيليوس في SP1 البسيطة

· تجهيز BLS12-381 بإيجاز

· التحقق من توقيع مجموعة BLS بناءً على Halo2

ما هي المهام الأخرى التي يجب القيام بها وكيفية التحكم فيها:

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

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

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

أثناء إعادة تصميم PoS لـ ETH ، يجب أن تكون ودية STARK هي العامل الأساسي ، خاصة مع نهاية الفتحة الفردية وأوربيت وتغييرات خطة التوقيع والتجميع.

01928374656574839201