عنوان المقال الأصلي: "مستقبلات محتملة لبروتوكول Ethereum، الجزء 4: The Verge"

المقال الأصلي بقلم فيتاليك بوتيرين

ترجمة المصدر: Mensh، ChainCatcher

نشكر بشكل خاص جوستين دريك وهسيا-وي وانب وغيوم باليه وايسيناسيو وروش رودولف وليف سوخانوي ريان شون آدمز وأما روي على ملاحظاتهم ومراجعتهم.

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

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

خريطة طريق The Verge 2023

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

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

The Verge: الهدف الرئيسي

• عميل عديم الحالة: يجب ألا تتجاوز مساحة التخزين المطلوبة لمصادقة العميل بالكامل ووضع علامة على العقدة بضعة غيغابايت.
• (الطويل الأجل) التحقق الكامل من سلسلة الكتل على الساعة الذكية (الإجماع والتنفيذ). قم بتنزيل بعض البيانات، والتحقق من SNARK، واكتمال.

في هذا الفصل

• العميل غير المتصل بالحالة: Verkle أو STARKs
• تنفيذ EVM إثبات صحة
• الإجماع الصحيح للإثبات

التحقق من الحالة: Verkle أو STARKs

ما هي المشكلة التي نحتاج إلى حلها؟

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

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

كيف يعمل؟

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

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

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

2. الرمز لم يتم تمريره عبر 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 بايتًا، بغض النظر عن عرض الشجرة. القيود الوحيدة على عرض الشجرة هي أن كفاءة حساب الإثبات تسقط إذا كانت الشجرة واسعة جدًا. عرض التنفيذ المقترح لـ ETH هو 256.

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

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

1. قم بتحليل Poseidon بشكل سريع وبكميات كبيرة وتعرف عليه بما فيه الكفاية لنشره في L1.
2. استخدام وظيفة تجزئة "محافظة" مثل SHA 256 أو BLAKE

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

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

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

• بركة الذاكرة: عندما يتم بث المعاملة في الشبكة بين العقد، يحتاج العقدة للتحقق من صحة المعاملة قبل إعادة بثها. التحقق يشمل التحقق من التوقيع، والتحقق من توفر الرصيد وصحة البادئة. في المستقبل (على سبيل المثال، باستخدام تجريد الحساب الأصلي مثل EIP-7701)، قد ينطوي ذلك على تشغيل بعض أكواد EVM التي تقوم ببعض الوصول إلى الحالة. إذا كانت العقدة بلا حالة، فإن المعاملة تحتاج إلى إرفاق برهان على حالة الكائن.
• قائمة المعلومات: هذه هي ميزة مقترحة تسمح للمدققون (الذين قد يكونون صغار الحجم وغير معقدة) بإجبار بلوك العملة التالي ليحتوي على المعاملات، بغض النظر عن رغبة بناة البلوك (الذين قد يكونون أكبر حجماً وأكثر تعقيداً). وهذا سيقوض قدرة الأطراف ذوي السلطة على تلاعب سلسلة الكتل عن طريق تأخير المعاملات. ومع ذلك، فإن ذلك يتطلب من المدققين وسيلة للتحقق من صحة المعاملات الموجودة في قائمة المعلومات.
• العميل الخفيف: إذا كنا نرغب في ال Permalink: 01928374656574839201 المستخدمين في الوصول إلى السلسلة عبر المحفظة (مثل Metamask و Rainbow و Rabby ، إلخ) ، فعلينا تشغيل عميل خفيف (مثل Helios). يوفر الوحدة النووية الأساسية لـ Helios للمستخدمين جذر حالة موثق. وللحصول على تجربة بدون ثقة تامة ، يحتاج المستخدمون إلى تقديم دليل لكل استدعاء RPC يقومون به (على سبيل المثال ، لطلب الشبكة ETH (يحتاج المستخدمون إلى إثبات جميع الحالات التي يتم الوصول إليها خلال الاستدعاء).

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

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

• أشجار Verkle
• مقال جون كوسمول حول شجرة فيركيل الأصلية
• ستاركوير
• ورقة بوسيدون 2
• Ajtai (وظيفة بديلة سريعة معتمدة على صلابة الشبكة البلوريةالتجزئة)
• Verkle.info

01928374656574839201

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

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

2. إكمال المزيد من العمل على برنامج الانتقال واختباره، وهذا هو الجزء الرئيسي من تعقيد أي حل بيئي بدون جنسية.

3. تحليل أمان إضافي لوظائف Poseidon و Ajtai وغيرها من وظائف التجزئة المتوافقة مع STARK.

4. لتطوير وظائف بروتوكول STARK فائقة الكفاءة بشكل أكبر للتجزئة "المحافظة" (أو "التقليدية")، مثل وجهات النظر المستندة إلى Binius أو GKR.

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

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

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

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

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

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

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

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

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

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

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

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

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

ما هي المشكلة التي نحتاج إلى حلها؟

الهدف الطويل الأجل للتحقق من كتلة ايثر واضح جدًا - يجب أن يكون بإمكانك التحقق من كتلة ايثر من خلال (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
• المطالبة 2: إذا تم تشغيل STF على Q ، (i) يحصل عملية التنفيذ فقط على الوصول إلى كائنات داخل Q ، (ii) تكون كتل البيانات صالحة ، (iii) تكون النتيجة هي Q'
• الادعاء 3: إذا تم احتساب معلومات Q' و P مرة أخرى للحصول على جذر حالة جديد، سيتم الحصول على R'

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

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

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

• EFPSE ZK-EVM (بسبب وجود خيارات أفضل، تم تعطيلها الآن)
• يعمل Zeth عن طريق ترجمة EVM إلى RISC-0 ZK-VM
• مشروع التحقق الرسمي ZK-EVM

01928374656574839201

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

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

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

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

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

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

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

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

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

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

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

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

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

• الأمان ووقت المحقق: إذا تم اختيار وظيفة الالتجزئة الأكثر تقدما أو نظام الإثبات الأكثر تعقيدا أو فرضية الأمان الأكثر تقدما أو أي تصميم آخر، فقد يتسنى تقليص وقت المحقق.
• اللامركزية و Proof-of-Time: تحتاج المجتمع إلى التوافق حول 'المواصفات' للأجهزة البرهانية المستهدفة. هل يمكن أن يكون البرهان على نطاق كبير من الكيانات؟ هل نأمل أن يكون بإمكان أجهزة الكمبيوتر المحمولة الاستهلاكية عالية الجودة قادرة على إثبات كتلة Ethereum في 4 ثوانٍ؟ هل بين الاثنين؟
• مدى كسر التوافق مع الخلف: يمكن تعويض النواحي الأخرى النقص من خلال تغيير أكثر فعالية في تكلفة الغاز، ولكن من المرجح أن يزيد هذا بشكل غير متناسب من تكلفة بعض التطبيقات، مما يجبر مطوري البرامج على إعادة كتابة ونشر الشفرة للحفاظ على الاقتصادية. وبالمثل، هذه الأدواتان لهما تعقيد وعيوبهما الخاصة.

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

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

• إثبات صحة L2 (أي "ZK rollup")
• طريقة الإثبات الثنائي لـ "STARK" غير الحالية

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

此外，EVM L1 يمكن أن يعزز بشكل كبير إثبات صحة L1 لزيادة حدود الغاز.

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

ما هي المشكلة التي نحتاج إلى حلها؟

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

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

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

يتم تعريف سلاسل المنارة على أنها وظائف انتقال الحالة, تماما مثل EVMs. تتكون وظيفة انتقال الحالة من ثلاثة أجزاء رئيسية:

• ECADD (للتحقق من توقيع BLS)
• الزوج (يستخدم للتحقق من توقيع BLS)
• القيمة المشفرة SHA 256 (المستخدمة لقراءة وتحديث الحالة)

في كل كتلة، نحتاج إلى إثبات 1-16 BLS 12-381 ECADD لكل المدققون (قد يكون أكثر من واحد لأن التوقيع قد يحتوي على مجموعات متعددة). يمكن تعويض ذلك باستخدام تقنية الحساب الفرعي المسبق، لذلك يمكننا القول إن كل مدقق يحتاج فقط إلى إثبات BLS 12-381 ECADD واحد. حاليًا، يحتوي كل فتحة على 30،000 توقيع للمدقق. في المستقبل، قد يحدث هذا الوضع تغييرًا في اتجاهين مختلفين: إذا اتبعنا الطريقة الخشنة، قد يزداد عدد المدققين في كل فتحة إلى مليون. في الوقت نفسه، إذا تم استخدام Orbit SSF، ستظل عدد المدققين عند 32،768 أو حتى يقل إلى 8192.

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

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

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

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

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

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

• تغيير وظيفة التجزئة: يتم الآن استخدام وظيفة التجزئة SHA 256 "الكاملة" ، لذلك يتعين في كل مرة على استدعاء الدالة مرتين للحصول على اثنين من استدعاءات الضغط الأساسية بسبب التعبئة. إذا تم استخدام دالة ضغط SHA 256 ، فسنتمكن على الأقل من الحصول على ضعف العائد. إذا تم استخدام Poseidon ، فقد نحصل على زيادة تصل إلى 100 مرة ، مما يحل جميع مشاكلنا (على الأقل فيما يتعلق بقيمة التجزئة): يمكن قراءة مليون سجل التحقق في غضون بضع ثوانٍ في البرهان بسرعة تصل إلى 1.7 مليون تجزئة في الثانية (54 ميجابايت) حتى.
• إذا كانت Orbit فقط، تخزين سجلات المُحقِّقين المُختلطة مباشرةً: إذا اختير عدد محدد من المُحقِّقين (مثل 8192 أو 32768 مُحقِّقًا) كلجنة لفتحة معينة، فإنه يتم وضعهم مباشرةً في حالة بجانب بعضهم البعض، حيث يمكن قراءة المفاتيح العامة لجميع المُحقِّقين فقط بالحد الأدنى من التجزئة في البرهان. كما يمكن إنجاز جميع التحديثات المتوازنة بكفاءة عالية.
• التوقيع الجماعي: أي حل توقيع جماعي عالي الأداء سينطوي على إثبات متبادل بطريقة ما، حيث تقوم عقدة مختلفة في الشبكة بإثبات جزء من التوقيع. وبالتالي، يتم توزيع عمل الإثبات بشكل طبيعي على عدة عقد في الشبكة، مما يقلل بشكل كبير من عبء "المثبت النهائي".
• حلول توقيع أخرى: بالنسبة لتوقيع Lamport+ Merkle ، نحتاج إلى 256 + 32 قيمة هاش للتحقق من التوقيع ؛ بالضرب في 32768 موقع توقيع ، نحصل على 9437184 قيمة هاش. يمكن تحسين حل التوقيع بعد الأمثلة بواسطة عامل ثابت صغير لتحسين هذه النتيجة بشكل أكبر. إذا استخدمنا Poseidon ، يمكن إثبات ذلك في فتحة واحدة فقط. ومع ذلك ، في الواقع ، ستكون الطريقة الأكثر سرعة هي استخدام حل التجميع التكراري.

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

• بروفوف الإجماع ETH موجز (للجنة التوافق فقط)
• Helios في SP 1 المبسطة
• مختصر BLS 12-381 مُعدّل مُسبقًا
• التحقق من توقيع مجموعة BLS على أساس Halo 2

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

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

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

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

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