في 25 أغسطس، تم إصدار Zeth، وهو مدقق كتلة ZK مفتوح المصدر لإيثريوم استنادًا إلى RISC Zero zkVM، علنًا. يقوم Zeth بكل الأعمال المطلوبة لبناء كتل جديدة في zkVM دون الاعتماد على المدققين أو لجان المزامنة. تم التحقق من Zeth على عدة كتل حقيقية لشبكة Ethereum الرئيسية واجتاز جميع الاختبارات ذات الصلة لمجموعة اختبار Ethereum الرسمية. تمكنت Zeth من تنفيذ دعم Rust القائم على zkVM واللوحات القوية بما في ذلك revm، والإيثرات، والسبائك في غضون 4 أسابيع. بفضل دعم zkVM للاستمرارية وخدمات إثبات Bonsai، يمكن لـ Zeth إنشاء هذه الأدلة في دقائق. ومن خلال دعم Zeth للتحقق عبر السلسلة، يمكن لأي شخص التحقق من هذه الأدلة عبر السلسلة بتكلفة منخفضة. في هذا المنشور، سنتناول المزيد من التفاصيل، ولكن إذا كنت تريد التعمق في الكود، فتحقق من الكود المصدري وقم بزيارة بوابة مطور RISC Zero.
ملخص
منذ حوالي عام، تحدث فيتاليك بالتفصيل عن الأنواع المختلفة لـ zkEVM:
لم يتم تصميم Ethereum في الأصل بحيث يكون متوافقًا مع ZK، لذلك هناك أجزاء كثيرة من بروتوكول Ethereum تتطلب حوسبة مكثفة للتحقق من ZK. يهدف جهاز EVM من النوع الأول إلى تكرار Ethereum بالكامل، لذلك لا يمكنه التخفيف من أوجه القصور هذه. في الوقت الحالي، تستغرق إثباتات كتل الإيثيريوم ساعات حتى تكتمل.
على الرغم من وجود حالات في تاريخ Ethereum حيث كان ذلك ممكنًا، يسعدنا اليوم أن نعلن أن إثباتات كتلة Ethereum باستخدام خدمات RISC Zero's zkVM وBonsai تستغرق دقائق، وليس ساعات.
Zeth: إنشاء كتلة إيثريوم يمكن التحقق منها
أطلقنا اليوم Zeth، وهو مدقق كتلة ZK مفتوح المصدر لـ Ethereum على RISC Zero zkVM.
يمكن لـ Zeth إثبات أن كتلة Ethereum معينة صالحة دون الاعتماد على المدققين أو لجان المزامنة. وذلك لأن Zeth يقوم بكل العمل المطلوب لإنشاء كتل جديدة في zkVM، بما في ذلك:
التحقق من توقيع المعاملة
التحقق من صحة الحساب وحالة التخزين مقابل جذر الحالة للكتلة الأصلية.
معاملات التطبيق
دفع رسوم حظر المؤلفين.
تحديث حالة الجذر
الأعمال الأخرى اللازمة لتوليد الكتل
بعد إنشاء كتلة جديدة، يقوم Zeth بحساب وإخراج التجزئة الخاصة بها. من خلال تشغيل هذه العملية في zkVM، يمكننا الحصول على أدلة ZK على صلاحية الكتل الجديدة.
من خلال الاستفادة من zkVM الخاص بـ RISC Zero وصناديق Rust الشائعة مثل revm وether و Alloy، قمنا بكتابة الإصدار الأول من Zeth في أقل من 4 أسابيع. بفضل دعم zkVM للاستمرارية وخدمة إثبات Bonsai، يمكن إنشاء الدليل في دقائق معدودة. من خلال دعم التحقق على السلسلة، يمكننا التحقق من هذه الأدلة على السلسلة بتكلفة منخفضة.
تم التحقق من Zeth على عدة كتل حقيقية لشبكة Ethereum الرئيسية واجتاز جميع الاختبارات ذات الصلة لمجموعة اختبار Ethereum الرسمية.
نظرًا لأن Zeth تقوم ببناء كتل Ethereum قياسية، فيمكن اعتبارها من النوع 1 zkEVM. ولكنه أكثر من ذلك بكثير: نظرًا لأن Zeth تم تصميمه باستخدام لوحات تشفير Rust القياسية (نفس لوحات التشفير التي تستخدمها العقد الكاملة الشائعة مثل Reth)، فإننا نفضل التفكير في الأمر كفئة 0 zkEVM: توافق كامل مع البروتوكول، والكثير من إعادة استخدام التعليمات البرمجية . **
يمثل هذا الإنجاز خطوة كبيرة إلى الأمام بالنسبة لتقنية ZK والنظام البيئي للإيثريوم. نناقش في هذا المنشور كيفية كتابة الإصدار الأول من Zeth في غضون أسابيع قليلة، وأداءه، وكيفية عمله، وما يعنيه هذا بالنسبة لمشروع ZK.
RISC Zero يجعل من السهل إنشاء مجموعات zk وzkEVMs والعملاء الخفيفين والجسور
لقد كتبنا Zeth لسببين:
اجعل من السهل على الفرق الأخرى إنشاء البنية التحتية الخاصة بها التي تعمل بنظام ZK: ZK rollup، وzkEVM، وZK light client، وZK Bridge، وما إلى ذلك. يوفر Zeth كل ما يلزم لإنشاء أدلة ZK للكتل المستندة إلى EVM. يعد هذا مكونًا رئيسيًا لأي zkEVM أو جسر. Zeth هو برنامج مفتوح المصدر يعتمد على المراجعة، لذلك يمكن لمطوري المشاريع تعديله أو استخدامه بسهولة. يمكن التحقق من البراهين على السلسلة (رائع للجسور وL2)، أو في تطبيق محلي (رائع للعقد الكاملة والعملاء الخفيفين).
إجراء الأبحاث ذات الصلة حول أداء EVM في Zeth's zkVM، وخاصة المهام المتعلقة بـ Ethereum. (انظر أدناه لتحليل نتائج الاستطلاع).
مجموعة zk وzkEVM
باعتباره النوع 0 zkEVM، يمكّن Zeth المطورين من إنشاء مجموعات zk مع توافق EVM وEthereum الأصلي بالكامل. إلى جانب دعم Zeth للتحقق من الأدلة على السلسلة، سيصبح بناء حل توسيع L2 المستند إلى ZK أمرًا بسيطًا للغاية.
تعد مجموعات ZK الحالية ودوائر zkEVM متجانسة حسب التصميم ولا يمكن ترقيتها دون أن يتمتع المطور بفهم عالي المستوى لتشفير ZK. في المقابل، يتيح نهج Zeth القائم على zkVM لأي مطور إمكانية تخصيصه وتعديله وفقًا لاحتياجاته.
Zeth هو مصدر مفتوح يعتمد على revm، ويعد التغيير والتبديل لدعم السلاسل الأخرى المتوافقة مع zkEVM وEVM مهمة سهلة نسبيًا. ولذلك، سيكون لدى Zeth استجابة أسرع نسبيًا لتحديثات EIP المستقبلية. بالإضافة إلى ذلك، يوفر Zeth أيضًا نمطية، مما يسمح للمطورين ببناء منطق بناء الكتل الخاص بهم فيه.
نأمل أن تؤدي جهود Zeth إلى إضفاء الطابع الديمقراطي على zk rollup وzkEVMs، مع العلم أن حلول L2 المعتمدة على zk كانت تتطلب في السابق سنوات من البحث والتطوير وتمويل أكثر من 100 مليون دولار أمريكي، وهو استهلاك لا تستطيع معظم المشاريع تحمله.
العميل الخفيف والجسر
ليس هناك شك في أن إدخال سلسلة المنارة يعد بمثابة نعمة لعملاء الضوء والجسور. تعتمد هذه التقنيات على نموذج إثبات الحصة (PoS) الخاص بـ Ethereum الذي أصبح ناضجًا الآن، مما يسمح للعملاء الخفيفين والجسور بالتحقق بسهولة من الكتل الأخيرة دون إعادة بنائها، بشرط أن يلتزم الجميع بالقواعد.
وبطبيعة الحال، فإن الهدف الأساسي من التوقيع المساحي هو توفير حوافز اقتصادية للعقد لاتباع القواعد. ومع ذلك، فإن التهديد الذي يفرضه القطع على العقد لا يمكن أن يتجنب تمامًا الحوافز الخارجية الشريرة التي ستميل دائمًا "توازن" المصالح نحو الشر - ومن المهم جدًا تصميم عميل خفيف أو جسر يمكنه التعامل بشكل صحيح مع هذه السلوكيات الضارة. صعب.
باستخدام أدوات مثل Zeth، يتم تقليل خطر قيام العقد بعمل الشر بشكل كبير. يمكن لعملاء Light التكامل مع Zeth ببساطة عن طريق إضافة عدد قليل من وسائل الشرح إلى zkVM، ويمكن للتطبيقات الموجودة على السلسلة مثل الجسور التكامل مع Zeth باستخدام عقد التحقق من إثبات الإثبات على السلسلة.
في المستقبل القريب، يمكننا أن نتخيل العملاء والجسور الخفيفة باستخدام إثباتات ZK لتحديد ما إذا كانت كتلة معينة صالحة أم لا. من شأن هذا النهج أن يقلل المخاطر بشكل كبير دون زيادة تكلفة التحقق من صحة الكتل بشكل كبير.
وهذا مهم بشكل خاص لسلاسل التطبيقات، والأنظمة البيئية المعيارية، والسلاسل الجديدة التي لا تتمتع بعد بنفس مستوى الأمان الذي يوفره مجتمع العقدة الكاملة الكبير في Ethereum.
الأساس الجيد يبسط عملية تطوير المشروع
استنادًا إلى RISC Zero zkVM والمدعوم ببنية مجموعة تعليمات RISC-V، يمكن لـ Zeth أن يوفر للمطورين تجربة برمجة مألوفة. لكن zkVM الخاص بنا هو أكثر من مجرد نواة RISC-V. لدينا أيضًا دوائر تسريع لمهام التشفير الشائعة مثل التجزئة والتحقق من التوقيع.
هذا النهج الهجين (مزيج من نوى وحدة المعالجة المركزية للأغراض العامة مع دوائر التسريع) يمنحنا أفضل ما في العالمين:
دعم لغات البرمجة السائدة.
لا يتم المساس بأداء عمليات التشفير الهامة.
ونتيجة لذلك، تمكنا من بناء Zeth بسرعة باستخدام حزم كود Rust الموجودة من revm، وether، وAlloy. من خلال إعادة استخدام اللوحات الموجودة، أكملنا الإصدار الأول من Zeth في أقل من 4 أسابيع. هذا النوع من السرعة غير ممكن في النظم البيئية الأقل نضجا.
فيما يتعلق بالأداء، تستفيد Zeth من دوائر التسريع الخاصة بنا للتحقق من توقيع ECDSA بالإضافة إلى الاستمرارية - وهي ميزة جديدة لإطار ZK الخاص بنا والتي تجعل من السهل استخدام مجموعات من وحدات معالجة الرسومات التي تعمل بالتوازي (باستخدام nVidia CUDA أو Apple Metal) لإثبات حجمها بسرعة العمليات الحسابية. الاستمرارية سهلة الاستخدام: يتم توفير هذه الوظيفة بشفافية لجميع برامج الضيف التي تعمل في zkVM، أي أنه لا يلزم إجراء تعديلات على التعليمات البرمجية حتى تعمل بشكل صحيح.
باستخدام zkVM الخاص بنا، نحن قادرون على إنشاء أدلة ZK على صلاحية كتلة Ethereum بسرعة في دقائق، وليس ساعات.
أداء
سنغطي أداء مولد كتلة Zeth. لا يزال Zeth منتجًا جديدًا، لذا فإن هذه الأرقام عرضة للتغيير؛ ومع ذلك، أردنا تقديم بعض الأرقام الملموسة لتكون بمثابة خط أساس للعمل المستقبلي.
عندما يتعلق الأمر بالأداء، هناك عدة عوامل يجب أخذها في الاعتبار:
الموارد الحسابية اللازمة لإنشاء البراهين.
"وقت الحائط" المطلوب لإنشاء الدليل (أي المدة التي يجب على المستخدم انتظارها حتى يتوفر الدليل).
يمكن ضبط zkVM الخاص بـ Zeth للأداء باستخدام التشغيل المستمر. لذلك نحن بحاجة إلى التوقف للحظة ومناقشة كيفية عمل "العملية المستمرة".
يستخدم zkVM معالجات RISC-V القياسية. ولذلك، يتم قياس التنفيذ في دورات. (في دائرتنا، يتم تنفيذ معظم تعليمات RISC-V في دورة واحدة، على الرغم من وجود استثناءات). تتطلب البرامج البسيطة عادةً بضع مئات الآلاف من الدورات فقط للتنفيذ، لكن البرامج الأكثر تعقيدًا قد تتطلب مليارات الدورات.
في نظام ZK النموذجي، يتم تجميع دورات التنفيذ هذه في دليل؛ مع زيادة عدد الدورات، يزداد الوقت والذاكرة اللازمان لإنشاء الدليل. لكن zkVM الخاص بنا لا يتبع هذه الصور النمطية، وفي وقت سابق من هذا العام ابتكرنا ميزة استمرارية جديدة تعمل على تحسين عيوب إنشاء مخطط الإثبات التقليدي.
ومن حيث الاستمرارية، تنقسم عملية الإثبات إلى ثلاث مراحل:
نقوم بإجراء الحسابات المطلوبة في جهاز محاكاة غير مقاوم. على طول الطريق، نحسب عدد المرات التي تم فيها تشغيل الحلقة حتى الآن. على فترات زمنية قابلة للتكوين، نلتقط لقطات لحالة البرنامج. يؤدي هذا إلى تقسيم التنفيذ بشكل فعال إلى أجزاء متعددة. كل جزء صغير، يمثل عادةً مليون دورة أو أقل.
تم تخصيص هذه القطع لمجموعة من عمال توليد الإثبات. يقومون بإنشاء أدلة ZK لقطاعات البرنامج الخاصة بهم. والأهم من ذلك أنهم يستطيعون القيام بذلك بالتوازي. وطالما أن هناك عدداً كافياً من العاملين، يمكن إثبات جميع شرائح البرنامج في الوقت اللازم لإثبات مقطع برنامج واحد. ونظرًا لصغر حجم مقطع الشبكة، فإن الوقت المطلوب عادةً ما يكون قصيرًا (عشرات الثواني).
عند إنشاء أدلة المقاطع، سيتم تجميعها في النهاية. تأخذ كل عملية "تراكمية" زوجًا من البراهين المجزأة المتتالية وتنتج برهانًا جديدًا لمجموعة تلك المقاطع. على سبيل المثال، إذا أثبت الجزء 1 أن البرنامج انتقل من الحالة أ إلى الحالة ب، وأثبت الجزء 2 أن البرنامج انتقل من الحالة ب إلى الحالة ج، فإن التجميع يثبت أن البرنامج انتقل من الحالة أ إلى الحالة ج. مع وجود عدد كافٍ من العمال، يمكن القيام بذلك في وقت السجل (N)، حيث N هو عدد الأجزاء.
سنرى هذه المراحل قيد التنفيذ عندما نتعمق في الأرقام.
**ما مدى صعوبة بناء كتلة إيثريوم؟ **
أولاً، دعونا نلقي نظرة على مدى تعقيد بناء كتلة إيثريوم. في الجدول أدناه، نأخذ بعض كتل الإيثريوم الحقيقية ونعيد بنائها باستخدام Zeth في zkVM.
على سبيل المثال، الكتلة 17606771 تنتج 2131 نطاقًا. يمثل كل مقطع 2^20 دورة تنفيذ على الأكثر، وبالتالي فإن الحساب بأكمله يستغرق 2,234,515,456 دورة تنفيذ على الأكثر.
بشكل عام، نرى كتلة إيثريوم نموذجية تستغرق ما بين 2 إلى 400 مليون دورة للبناء، ولكن في بعض الأحيان ما يصل إلى 9.5 مليار دورة. (في البداية، فوجئنا برؤية أن هذه الاختلافات لم تنعكس في غاز الصفقة. ولكن بعد التفكير في الأمر أكثر، أصبح الأمر منطقيًا: لقد تم تصميم نظام الغاز مع وضع التنفيذ المنتظم في الاعتبار، وليس إثباتات ZK).
ومع الاستمرارية، يصبح من السهل إدارة هذا النطاق. وفقًا لهذه الأرقام، فإن شبكة نظير إلى نظير المكونة من 10,000 عقدة تقوم بتشغيل أدوات التحقق من صحة zkVM تكفي لتحقيق أعلى أداء تحقق متوازي لأكبر الكتل، وهو جزء صغير من 700,000 أداة تحقق تمتلكها Ethereum حاليًا.
**كم من الوقت يستغرق إنشاء الإثبات؟ **
لجمع بعض بيانات الأداء الأساسية، أطلقنا نسخة اختبار Bonsai مع 64 عاملاً في وحدة معالجة الرسومات. ثم طلبنا منها إثبات حظر 17735424 (182 معاملة، أو 3242 مقطعًا، أو حوالي 3.4 مليار دورة) باستخدام Zeth.
لإنشاء البراهين، يجب على zkVM أولاً تقسيم التنفيذ إلى أجزاء. في لقطة الشاشة أدناه، تم التقاط هذه العملية بواسطة مهمة المستخدم، والتي استمرت لمدة 10 دقائق. (معظم ذلك الوقت هو القيام بأشياء AWS مثل الكتابة إلى وحدة تخزين الشبكة). على الجهاز المحلي، تستغرق نفس المهمة أقل من 6 دقائق لإكمالها. ونأمل أن نخفض هذا الوقت بشكل كبير خلال العام المقبل).
أخيرًا قام المنفذ بتقسيم التنفيذ إلى 3242 قطعة. هذا كثير من التجزئة بالنسبة لـ 64 وحدة معالجة رسوميات فقط. لذلك، يجب أن تقوم كل عقدة عاملة بإنشاء 50 إثباتًا للمقاطع. كما هو موضح في الشكل أدناه، يستغرق ذلك 35 دقيقة. إذا كان لدينا 50 ضعف عدد العقد العاملة، فسيستغرق الأمر 42 ثانية فقط.
بعد اكتمال إثبات المقطع، يبدأ التجميع. نظرًا لوجود 3242 مقطعًا، نحتاج إلى إجراء عملية تراكمية لـ log_2(3242) = 12 جولة. في المراحل الأولى من عملية التجميع، يكون عدد العمال أكبر من عدد العمال؛ لذا تستغرق المرحلة الأولى دقيقة واحدة، وتستغرق المرحلة الثانية 35 ثانية، وتستغرق المرحلة الثالثة 25 ثانية، وهكذا. بحلول المرحلة السابعة، استقر الوقت عند ما يزيد قليلاً عن 5 ثوانٍ. وبالمثل، إذا كان لدينا المزيد من العمال، فستستغرق كل مرحلة 5 ثوانٍ فقط.
بعد اكتمال عملية التجميع، يتم الانتهاء من النتائج، الأمر الذي يستغرق دقيقة أخرى.
ونتيجة لذلك، تمكنا من إنشاء البراهين في حوالي 50 دقيقة (السرعة الفعالة 1.1 ميجاهرتز) مع عدم كفاية حجم المجموعة. إذا كان حجم المجموعة مناسبًا، فإننا نقدر أن إنشاء البراهين سيكون أسرع:
في حالة التوازي الكامل، يمكن إكمال خطوة الإثبات خلال 42 + 12 * 5 + 60 ثانية أو دقيقتين و42 ثانية.
إذا قمنا بالتقريب بشكل متحفظ وقمنا بتضمين وقت المنفذ، فإن الوقت يتراوح بين 9 و12 دقيقة (السرعة الفعالة 4.7 ميجا هرتز - 6.3 ميجا هرتز).
وبينما نواصل تحسين المنفذين وإطار الإثبات لدينا، فإننا متفائلون بأن هذه المرة سيتم تخفيضها بشكل كبير خلال العام المقبل.
استهلاك الموارد لإنشاء البراهين
تم نشر مجموعة الاختبار المذكورة أعلاه على AWS. وهو يتألف من 64 عقدة إثبات g5.xlarge وعقدة تنفيذ m5zn.xlarge واحدة. وفقًا لأمازون، تحتوي كل عقدة g5.xlarge على
1 GPU مع ذاكرة GPU 24 جيجا بايت
4 وحدات معالجة مركزية افتراضية بسعة ذاكرة 16 جيجا بايت
حتى كتابة هذه السطور، يبلغ السعر عند الطلب لهذه المثيلات 1.006 دولارًا أمريكيًا في الساعة، والمثيلات المحجوزة هي 0.402 دولارًا أمريكيًا في الساعة. وفي الوقت نفسه، توضح ورقة مواصفات أمازون أن العقدة m5zn.xlarge الخاصة بنا موجودة
4 وحدات معالجة مركزية افتراضية، وذاكرة وصول عشوائي (RAM) سعة 16 جيجابايت
حتى كتابة هذه السطور، كان السعر عند الطلب لهذه الحالة هو 0.3303 دولارًا أمريكيًا في الساعة.
يمكننا استخدام هذه الأرقام لتقدير تكلفة الإثبات تقريبًا للكتلة 17735424 الموضحة أعلاه.
تذكر أننا قمنا بنشر 64 عقدة إثبات وفي هذا النشر استغرق الأمر 50 دقيقة (من النهاية إلى النهاية) لإنشاء الإثبات. بتجاهل وقت العامل الخامل، تكلف 64 عقدة إثبات بالإضافة إلى عقدة تنفيذ واحدة 50/60 * (64 * 0.402 + 0.3303) = 21.72 دولارًا لمدة 50 دقيقة. وهذا مبالغة في التقدير لأنه يفترض أننا ندفع للعمال العاطلين عن العمل. إذا لم نأخذ في الاعتبار تكلفة العمال العاطلين عن العمل (على سبيل المثال، إغلاقهم أو تعيينهم في وظائف أخرى)، فإن التكلفة تبلغ حوالي 19.61 دولارًا.
تحتوي هذه الكتلة على 182 معاملة، أو 0.11 دولار لكل معاملة.
*القيمة الإجمالية للمعاملة هي 1.125045057 إيثريوم، أي حوالي 2137.59 دولار. وبالتالي، فإن كل دولار واحد من الإثبات ينتج عنه 109.01 دولارًا أمريكيًا من أموال المستخدم.
المكافأة المدفوعة لنفس الكتلة هي 0.117623263003047027 Eth (باستثناء رسوم المعاملات). في وقت كتابة هذا التقرير، كان هذا حوالي 223.48 دولارًا. لذلك، تكلف البراهين لدينا حوالي 8.7% من مكافأة الكتلة.
تضيف رسوم المعاملات ما يصل إلى 0.03277635 إيثريوم، أو 62.28 دولارًا أمريكيًا، أي أكثر من 3 أضعاف تكلفة الإثبات الخاص بنا.
ومن الجدير بالذكر أن هذه التقديرات بالدولار مستقلة عن حجم الكتلة! ما يهم هو عدد الأجزاء. وذلك لأن جهازًا واحدًا يقوم بمهمتين متتابعتين يكلف نفس تكلفة جهازين يقومان بعمل واحد بالتوازي. ولذلك، إذا كان حجم المجموعة أكبر، فسيتم إنشاء البراهين بشكل أسرع، ولكن ليس أكثر تكلفة.
هناك عدة طرق لمزيد من خفض التكاليف. بالإضافة إلى الاستمرار في تحسين أداء zkVM، وربما إضافة مسرع Keccak، يمكننا أيضًا البحث عن مثيلات أرخص. الأهم من ذلك، نظرًا للأجهزة منخفضة المواصفات التي نستخدمها (ويدعم zkVM الخاص بنا nVidia Cuda وApple Metal)، يمكن تنفيذ هذا العمل بسهولة عبر شبكة p2p من أجهزة الكمبيوتر الشخصية وأجهزة Mac الاستهلاكية العادية.
التحقق عبر السلسلة
كما ذكرنا أعلاه، قمنا بالتحقق من إثباتات Zeth على Sepolia باستخدام أداة التحقق من الصحة RISC Zero Groth16. يعد هذا جزءًا جديدًا نسبيًا من حزمة بروتوكول RISC Zero، التي تم إصدارها في وقت سابق من هذا الشهر. إنه يعمل عن طريق استخدام Bonsai لتحويل دليل STARK الأصلي الخاص بـ zkVM إلى دليل SNARK مكافئ، وإرسال هذا الدليل إلى أداة التحقق من صحة SNARK على السلسلة.
إذا نظرنا إلى إدخال المعاملة كبيانات UTF-8، فسنرى أن الدليل يتوافق مع الكتلة 17735424.
باستخدام Bonsai، يستغرق التحويل من STARK إلى SNARK حوالي 40 ثانية. كلف التحقق من SNARK على السلسلة 245,129 دولارًا (حوالي 5.90 دولارًا في وقت كتابة هذا التقرير).
بالطبع، إحدى ميزات zkVM هي أنه يمكنه الجمع بين العديد من البراهين في برهان واحد. باستخدام هذه الوظيفة، يمكن التحقق من مجموعة كاملة من الأدلة على السلسلة دون استخدام أي غاز إضافي. بهذه الطريقة، يمكن توزيع تكلفة التحقق عبر السلسلة عبر مجموعة الأدلة بأكملها، مما يقلل التكلفة للجميع.
ماذا يعني هذا بالنسبة للإيثريوم
كما ذكرنا سابقًا، لم يتم تصميم إيثريوم مع وضع ملاءمة ZK في الاعتبار. كما تظهر حالة zkEVMs، هناك العديد من الأشياء التي يمكن القيام بها بطرق مختلفة، خاصة عندما يتعلق الأمر بأكواد التشغيل والتوقيعات الرقمية ووظائف التجزئة.
على الرغم من أن هذه التغييرات أدت إلى تحسين الأداء، إلا أننا مازلنا قادرين على تحقيق أداء قوي بدون هذه التغييرات. عندما كتب Vitalik عن أنواع مختلفة من zkEVMs العام الماضي، استغرق الأمر ساعات لإثبات صلاحية كتلة Ethereum؛ الآن، يمكننا القيام بذلك في دقائق. يتحسن أداء ZK بسرعة، ولدينا سبب للاعتقاد بأن هذا الاتجاه سيستمر في السنوات القليلة المقبلة.
الملحق: كيف يعمل زيث
هذا القسم مخصص للمطورين.
بشكل تقريبي، يقوم Zeth ببناء الكتل بنفس طريقة بناء العقدة الكاملة: نبدأ بالكتلة الأصلية، وقائمة المعاملات، ومؤلف الكتلة، ثم نقوم بالكثير من العمليات الحسابية (التحقق من التوقيعات، وتشغيل المعاملات، وتحديث الحالة العالمية، وما إلى ذلك). وأخيرًا قم بإرجاع قيمة تجزئة الكتلة الجديدة.
ولكن على عكس العقد الكاملة، فإننا نقوم بذلك في zkVM. هذا يعني أننا حصلنا على دليل ZK على أن الكتلة التي تحتوي على تجزئة معينة صالحة.
وبطبيعة الحال، لا يخلو هذا من التحديات. وفي هذا القسم، نعرض هذه التحديات وكيفية معالجتها.
التشفير
التحدي الأول هو التشفير. يتطلب إنشاء كتلة إيثريوم الكثير من العمل، وأهمها التجزئة (Keccak-256) والتحقق من التوقيع (ECDSA وsecp256k1).
لقد قام zkVM الخاص بنا بتسريع دعم المنحنيات الإهليلجية، لذا فإن التحقق من توقيع ECDSA ليس بالأمر الصعب.
ولكن عندما يتعلق الأمر بالتجزئة، فإننا لسنا محظوظين جدًا. قام zkVM الخاص بنا بتسريع دعم Sha2-256، ولكن ليس (في وقت كتابة هذا التقرير) Keccak-256. لذلك، نستخدم حاليًا تطبيق Keccak فقط في صندوق sha3 Rust. من خلال التنميط، نعلم أن هذا يستغرق الكثير من الدورات. إنه ليس الحل الأمثل، لكن جهاز zkVM الخاص بنا يمكنه التعامل معه، ويمكننا إعادة تدوير مسرعات Keccak وإضافتها لاحقًا.
الحسابات ومساحة التخزين: الأداء والأمان
في إيثريوم، يتم تتبع الحسابات والتخزين بواسطة Merkle Patricia Trie (MPT) العالمية.
وفي وقت كتابة هذا التقرير، كانت الشجرة تحتوي على حالة ما يقرب من 250 مليون عنوان إيثريوم فريد، وفقًا لشركة Etherscan. هذه ليست كمية هائلة من البيانات بشكل عام، ولكنها كافية لجعلنا نكون حذرين بشأن كيفية تخزينها واستخدامها. على وجه الخصوص، أداء MPT أمر بالغ الأهمية.
ولكن الأداء ليس هو العامل الوحيد، يجب علينا أيضا أن نأخذ في الاعتبار الأمن.
يعمل مولد الكتل الخاص بـ Zeth كعميل في zkVM. وهذا يعني أنه لا يمكنه الوصول مباشرة إلى شبكة Ethereum p2p أو موفري RPC الآخرين. وبدلاً من ذلك، يجب أن تعتمد على البيانات المقدمة من برامج منفصلة تعمل خارج zkVM.
عند تحليل أمان تطبيق ZK، يجب أن نفترض أن البرامج الخارجية ضارة وبالتالي قد تخدم بيانات ضارة. ولمنع ذلك، يجب على تطبيقات ZK التحقق من صحة البيانات المقدمة لها.
بالنسبة لمولدات كتلة Zeth، يعني هذا التحقق من حالة جميع الحسابات ووحدات التخزين ذات الصلة (أي الحسابات ووحدات التخزين المطلوبة لتشغيل قائمة معينة من المعاملات).
لحسن الحظ، يتم توفير هذه الآلية بواسطة EIP-1186، والتي تحدد طريقة قياسية لإثبات حالة حساب معين (ومساحة تخزينه) عبر تضمين Merkle.
من حيث المبدأ، يمكن لمولدات الكتل الخاصة بـ Zeth التحقق من حالة الحساب والتخزين من خلال التحقق من مجموعة من إثباتات تضمين EIP-1186. ولكن هذا النهج ليس مثاليا.
بدلاً من ذلك، من الأفضل استخدام البيانات الموجودة في إثبات التضمين EIP-1186 لإنشاء MPT جزئي. هذا نوع من MPT يتضمن فقط العقد ذات الصلة بقائمة معاملات معينة، ويتم تمثيل الفروع غير المرتبطة ببساطة بالتجزئة المقابلة. يمكنك التفكير في MPTs الجزئية كنوع من "اتحاد" إثباتات تضمين Merkle؛ أو، إذا كنت تفضل ذلك، كدليل على مجموعة Merkle الفرعية.
إن عملية التحقق من MPT الجزئي هي في الأساس نفس عملية التحقق من إثبات EIP-1186 العادي: يتم حساب تجزئة الجذر ومقارنتها بجذر الحالة للكتلة الأصلية. وإذا تساوى الاثنان، يمكن الوثوق بسلامة الحسابات والتخزين بداخلها.
بمجرد التحقق من MPT الجزئي، يمكن تطبيق المعاملة وتحديث MPT الجزئي. يمكن الحصول على جذر الحالة الجديد عن طريق حساب قيمة تجزئة الجذر الجديدة لـ MPT الجزئي.
قبل تشغيل مولد الكتل Zeth، نقوم بتشغيل قائمة المعاملات في وضع الحماية لتحديد الحسابات ووحدات التخزين ذات الصلة. (تسمح لنا هذه العملية أيضًا بتحديد أقدم كتلة سابقة ذات صلة، وهي مطلوبة لدعم استعلامات blockhash()).
حصلنا على إثبات التضمين EIP-1186 لكل حساب ووحدة تخزين ذات صلة. (نحصل أيضًا على الكتل السابقة ذات الصلة).
نستخدم أدلة التضمين هذه لبناء MPT جزئي يتضمن جميع البيانات ذات الصلة.
نبدأ تشغيل zkVM، ونسمح له بتشغيل مولد كتلة Zeth، ونوفر بعض MPT والمدخلات الأخرى (الكتلة الأصلية، وقائمة المعاملات، وما إلى ذلك).
في zkVM، مولد كتلة Zeth:
تحقق من أن جذر MPT الجزئي يطابق جذر الحالة للكتلة الأصلية.
التحقق من سلسلة التجزئة للكتلة السابقة حتى الكتلة الأصلية.
معاملات التطبيق.
قم بتحديث بعض MPTs.
استخدم تجزئة الجذر الجديد لـ MPT الجزئي كجذر الحالة للكتلة الجديدة.
بعد اكتمال مولد كتلة Zeth، سيتم إخراج قيمة التجزئة للكتلة الجديدة.
تتضمن هذه التجزئة التزامًا بالكتلة الأصلية، وبالتالي جذر الحالة للكتلة الأصلية (المستخدمة للتحقق من MPT الجزئي الأصلي). وهذا يعني أن أداة التحقق الضارة لا يمكنها توفير حسابات وتخزين ببيانات غير صالحة دون توفير كتلة أصل غير صالحة.
بمعنى آخر: إذا كانت الكتلة الأصلية صالحة، فإن الكتلة الجديدة التي تم إنشاؤها بواسطة Zeth صالحة أيضًا.
لذا، إذا أعطاك شخص ما كتلة جديدة وإثبات ZK تم إنشاؤه بواسطة Zeth، فيمكنك التحقق من صحة الكتلة عن طريق التحقق من الأشياء الثلاثة التالية:
تأكد من صحة إثبات ZK ومن Zeth. بالنسبة للتطبيقات خارج السلسلة، يمكن استخدام الوظائف التي يوفرها صندوق zkVM Rust للفحص. بالنسبة للتطبيقات الموجودة على السلسلة، يمكن التحقق من ذلك باستخدام أداة التحقق من صحة الأدلة الموجودة على السلسلة.
تأكد من أن ZK يثبت أن تجزئة الكتلة الجديدة قد تم الالتزام بها.
تأكد من أن الكتلة الأصلية تحتوي على التجزئة التي تتوقعها.
إذا تم التحقق من ذلك، فإن الكتلة الجديدة صالحة.
القيود والتحسينات المستقبلية
الهدف من مشروعنا هو دراسة أداء بناء الكتل. لهذا السبب، قررنا قصر النطاق على الكتل المدمجة.
بالإضافة إلى ذلك، في حين أن Zeth قادر على إثبات صحة كتلة معينة، فإنه لا يمكنه حاليًا إثبات الإجماع (أي أن الكتلة مدرجة بالفعل في السلسلة الأساسية). قد يتغير هذا في المستقبل، ربما عن طريق إضافة عمليات فحص لتوقيعات المدقق أو لجنة المزامنة في zkVM.
أخيرًا، Zeth هو برنامج جديد. على الرغم من قيامنا ببعض الاختبارات (بما في ذلك مجموعة اختبار Ethereum والعديد من الكتل الواقعية)، إلا أن Zeth قد لا يزال يحتوي على بعض الأخطاء. وحتى كتابة هذه السطور، ينبغي اعتباره برنامجًا تجريبيًا.
شاهد النسخة الأصلية
قد تحتوي هذه الصفحة على محتوى من جهات خارجية، يتم تقديمه لأغراض إعلامية فقط (وليس كإقرارات/ضمانات)، ولا ينبغي اعتباره موافقة على آرائه من قبل Gate، ولا بمثابة نصيحة مالية أو مهنية. انظر إلى إخلاء المسؤولية للحصول على التفاصيل.
شرح تفصيلي لمدقق كتلة الايثيريوم Zeth: النوع الأول 0 zkEVM
العنوان الأصلي: الإعلان عن Zeth: النوع الأول Zero zkEVM
النجوم: تيم كارتنز، فيكتور جراف، رامي خليل، ستيفن لي، باركر طومسون، وولفجانج ويلز، زيث كولابوريشن.
البناء: Bayemon.eth، ChainCatcher
في 25 أغسطس، تم إصدار Zeth، وهو مدقق كتلة ZK مفتوح المصدر لإيثريوم استنادًا إلى RISC Zero zkVM، علنًا. يقوم Zeth بكل الأعمال المطلوبة لبناء كتل جديدة في zkVM دون الاعتماد على المدققين أو لجان المزامنة. تم التحقق من Zeth على عدة كتل حقيقية لشبكة Ethereum الرئيسية واجتاز جميع الاختبارات ذات الصلة لمجموعة اختبار Ethereum الرسمية. تمكنت Zeth من تنفيذ دعم Rust القائم على zkVM واللوحات القوية بما في ذلك revm، والإيثرات، والسبائك في غضون 4 أسابيع. بفضل دعم zkVM للاستمرارية وخدمات إثبات Bonsai، يمكن لـ Zeth إنشاء هذه الأدلة في دقائق. ومن خلال دعم Zeth للتحقق عبر السلسلة، يمكن لأي شخص التحقق من هذه الأدلة عبر السلسلة بتكلفة منخفضة. في هذا المنشور، سنتناول المزيد من التفاصيل، ولكن إذا كنت تريد التعمق في الكود، فتحقق من الكود المصدري وقم بزيارة بوابة مطور RISC Zero.
ملخص
منذ حوالي عام، تحدث فيتاليك بالتفصيل عن الأنواع المختلفة لـ zkEVM:
على الرغم من وجود حالات في تاريخ Ethereum حيث كان ذلك ممكنًا، يسعدنا اليوم أن نعلن أن إثباتات كتلة Ethereum باستخدام خدمات RISC Zero's zkVM وBonsai تستغرق دقائق، وليس ساعات.
Zeth: إنشاء كتلة إيثريوم يمكن التحقق منها
أطلقنا اليوم Zeth، وهو مدقق كتلة ZK مفتوح المصدر لـ Ethereum على RISC Zero zkVM.
يمكن لـ Zeth إثبات أن كتلة Ethereum معينة صالحة دون الاعتماد على المدققين أو لجان المزامنة. وذلك لأن Zeth يقوم بكل العمل المطلوب لإنشاء كتل جديدة في zkVM، بما في ذلك:
بعد إنشاء كتلة جديدة، يقوم Zeth بحساب وإخراج التجزئة الخاصة بها. من خلال تشغيل هذه العملية في zkVM، يمكننا الحصول على أدلة ZK على صلاحية الكتل الجديدة.
من خلال الاستفادة من zkVM الخاص بـ RISC Zero وصناديق Rust الشائعة مثل revm وether و Alloy، قمنا بكتابة الإصدار الأول من Zeth في أقل من 4 أسابيع. بفضل دعم zkVM للاستمرارية وخدمة إثبات Bonsai، يمكن إنشاء الدليل في دقائق معدودة. من خلال دعم التحقق على السلسلة، يمكننا التحقق من هذه الأدلة على السلسلة بتكلفة منخفضة.
تم التحقق من Zeth على عدة كتل حقيقية لشبكة Ethereum الرئيسية واجتاز جميع الاختبارات ذات الصلة لمجموعة اختبار Ethereum الرسمية.
نظرًا لأن Zeth تقوم ببناء كتل Ethereum قياسية، فيمكن اعتبارها من النوع 1 zkEVM. ولكنه أكثر من ذلك بكثير: نظرًا لأن Zeth تم تصميمه باستخدام لوحات تشفير Rust القياسية (نفس لوحات التشفير التي تستخدمها العقد الكاملة الشائعة مثل Reth)، فإننا نفضل التفكير في الأمر كفئة 0 zkEVM: توافق كامل مع البروتوكول، والكثير من إعادة استخدام التعليمات البرمجية . **
يمثل هذا الإنجاز خطوة كبيرة إلى الأمام بالنسبة لتقنية ZK والنظام البيئي للإيثريوم. نناقش في هذا المنشور كيفية كتابة الإصدار الأول من Zeth في غضون أسابيع قليلة، وأداءه، وكيفية عمله، وما يعنيه هذا بالنسبة لمشروع ZK.
RISC Zero يجعل من السهل إنشاء مجموعات zk وzkEVMs والعملاء الخفيفين والجسور
لقد كتبنا Zeth لسببين:
مجموعة zk وzkEVM
باعتباره النوع 0 zkEVM، يمكّن Zeth المطورين من إنشاء مجموعات zk مع توافق EVM وEthereum الأصلي بالكامل. إلى جانب دعم Zeth للتحقق من الأدلة على السلسلة، سيصبح بناء حل توسيع L2 المستند إلى ZK أمرًا بسيطًا للغاية.
تعد مجموعات ZK الحالية ودوائر zkEVM متجانسة حسب التصميم ولا يمكن ترقيتها دون أن يتمتع المطور بفهم عالي المستوى لتشفير ZK. في المقابل، يتيح نهج Zeth القائم على zkVM لأي مطور إمكانية تخصيصه وتعديله وفقًا لاحتياجاته.
Zeth هو مصدر مفتوح يعتمد على revm، ويعد التغيير والتبديل لدعم السلاسل الأخرى المتوافقة مع zkEVM وEVM مهمة سهلة نسبيًا. ولذلك، سيكون لدى Zeth استجابة أسرع نسبيًا لتحديثات EIP المستقبلية. بالإضافة إلى ذلك، يوفر Zeth أيضًا نمطية، مما يسمح للمطورين ببناء منطق بناء الكتل الخاص بهم فيه.
نأمل أن تؤدي جهود Zeth إلى إضفاء الطابع الديمقراطي على zk rollup وzkEVMs، مع العلم أن حلول L2 المعتمدة على zk كانت تتطلب في السابق سنوات من البحث والتطوير وتمويل أكثر من 100 مليون دولار أمريكي، وهو استهلاك لا تستطيع معظم المشاريع تحمله.
العميل الخفيف والجسر
ليس هناك شك في أن إدخال سلسلة المنارة يعد بمثابة نعمة لعملاء الضوء والجسور. تعتمد هذه التقنيات على نموذج إثبات الحصة (PoS) الخاص بـ Ethereum الذي أصبح ناضجًا الآن، مما يسمح للعملاء الخفيفين والجسور بالتحقق بسهولة من الكتل الأخيرة دون إعادة بنائها، بشرط أن يلتزم الجميع بالقواعد.
وبطبيعة الحال، فإن الهدف الأساسي من التوقيع المساحي هو توفير حوافز اقتصادية للعقد لاتباع القواعد. ومع ذلك، فإن التهديد الذي يفرضه القطع على العقد لا يمكن أن يتجنب تمامًا الحوافز الخارجية الشريرة التي ستميل دائمًا "توازن" المصالح نحو الشر - ومن المهم جدًا تصميم عميل خفيف أو جسر يمكنه التعامل بشكل صحيح مع هذه السلوكيات الضارة. صعب.
باستخدام أدوات مثل Zeth، يتم تقليل خطر قيام العقد بعمل الشر بشكل كبير. يمكن لعملاء Light التكامل مع Zeth ببساطة عن طريق إضافة عدد قليل من وسائل الشرح إلى zkVM، ويمكن للتطبيقات الموجودة على السلسلة مثل الجسور التكامل مع Zeth باستخدام عقد التحقق من إثبات الإثبات على السلسلة.
في المستقبل القريب، يمكننا أن نتخيل العملاء والجسور الخفيفة باستخدام إثباتات ZK لتحديد ما إذا كانت كتلة معينة صالحة أم لا. من شأن هذا النهج أن يقلل المخاطر بشكل كبير دون زيادة تكلفة التحقق من صحة الكتل بشكل كبير.
وهذا مهم بشكل خاص لسلاسل التطبيقات، والأنظمة البيئية المعيارية، والسلاسل الجديدة التي لا تتمتع بعد بنفس مستوى الأمان الذي يوفره مجتمع العقدة الكاملة الكبير في Ethereum.
الأساس الجيد يبسط عملية تطوير المشروع
استنادًا إلى RISC Zero zkVM والمدعوم ببنية مجموعة تعليمات RISC-V، يمكن لـ Zeth أن يوفر للمطورين تجربة برمجة مألوفة. لكن zkVM الخاص بنا هو أكثر من مجرد نواة RISC-V. لدينا أيضًا دوائر تسريع لمهام التشفير الشائعة مثل التجزئة والتحقق من التوقيع.
هذا النهج الهجين (مزيج من نوى وحدة المعالجة المركزية للأغراض العامة مع دوائر التسريع) يمنحنا أفضل ما في العالمين:
ونتيجة لذلك، تمكنا من بناء Zeth بسرعة باستخدام حزم كود Rust الموجودة من revm، وether، وAlloy. من خلال إعادة استخدام اللوحات الموجودة، أكملنا الإصدار الأول من Zeth في أقل من 4 أسابيع. هذا النوع من السرعة غير ممكن في النظم البيئية الأقل نضجا.
فيما يتعلق بالأداء، تستفيد Zeth من دوائر التسريع الخاصة بنا للتحقق من توقيع ECDSA بالإضافة إلى الاستمرارية - وهي ميزة جديدة لإطار ZK الخاص بنا والتي تجعل من السهل استخدام مجموعات من وحدات معالجة الرسومات التي تعمل بالتوازي (باستخدام nVidia CUDA أو Apple Metal) لإثبات حجمها بسرعة العمليات الحسابية. الاستمرارية سهلة الاستخدام: يتم توفير هذه الوظيفة بشفافية لجميع برامج الضيف التي تعمل في zkVM، أي أنه لا يلزم إجراء تعديلات على التعليمات البرمجية حتى تعمل بشكل صحيح.
باستخدام zkVM الخاص بنا، نحن قادرون على إنشاء أدلة ZK على صلاحية كتلة Ethereum بسرعة في دقائق، وليس ساعات.
أداء
سنغطي أداء مولد كتلة Zeth. لا يزال Zeth منتجًا جديدًا، لذا فإن هذه الأرقام عرضة للتغيير؛ ومع ذلك، أردنا تقديم بعض الأرقام الملموسة لتكون بمثابة خط أساس للعمل المستقبلي.
عندما يتعلق الأمر بالأداء، هناك عدة عوامل يجب أخذها في الاعتبار:
استمرارية
يمكن ضبط zkVM الخاص بـ Zeth للأداء باستخدام التشغيل المستمر. لذلك نحن بحاجة إلى التوقف للحظة ومناقشة كيفية عمل "العملية المستمرة".
يستخدم zkVM معالجات RISC-V القياسية. ولذلك، يتم قياس التنفيذ في دورات. (في دائرتنا، يتم تنفيذ معظم تعليمات RISC-V في دورة واحدة، على الرغم من وجود استثناءات). تتطلب البرامج البسيطة عادةً بضع مئات الآلاف من الدورات فقط للتنفيذ، لكن البرامج الأكثر تعقيدًا قد تتطلب مليارات الدورات.
في نظام ZK النموذجي، يتم تجميع دورات التنفيذ هذه في دليل؛ مع زيادة عدد الدورات، يزداد الوقت والذاكرة اللازمان لإنشاء الدليل. لكن zkVM الخاص بنا لا يتبع هذه الصور النمطية، وفي وقت سابق من هذا العام ابتكرنا ميزة استمرارية جديدة تعمل على تحسين عيوب إنشاء مخطط الإثبات التقليدي.
ومن حيث الاستمرارية، تنقسم عملية الإثبات إلى ثلاث مراحل:
نقوم بإجراء الحسابات المطلوبة في جهاز محاكاة غير مقاوم. على طول الطريق، نحسب عدد المرات التي تم فيها تشغيل الحلقة حتى الآن. على فترات زمنية قابلة للتكوين، نلتقط لقطات لحالة البرنامج. يؤدي هذا إلى تقسيم التنفيذ بشكل فعال إلى أجزاء متعددة. كل جزء صغير، يمثل عادةً مليون دورة أو أقل.
تم تخصيص هذه القطع لمجموعة من عمال توليد الإثبات. يقومون بإنشاء أدلة ZK لقطاعات البرنامج الخاصة بهم. والأهم من ذلك أنهم يستطيعون القيام بذلك بالتوازي. وطالما أن هناك عدداً كافياً من العاملين، يمكن إثبات جميع شرائح البرنامج في الوقت اللازم لإثبات مقطع برنامج واحد. ونظرًا لصغر حجم مقطع الشبكة، فإن الوقت المطلوب عادةً ما يكون قصيرًا (عشرات الثواني).
عند إنشاء أدلة المقاطع، سيتم تجميعها في النهاية. تأخذ كل عملية "تراكمية" زوجًا من البراهين المجزأة المتتالية وتنتج برهانًا جديدًا لمجموعة تلك المقاطع. على سبيل المثال، إذا أثبت الجزء 1 أن البرنامج انتقل من الحالة أ إلى الحالة ب، وأثبت الجزء 2 أن البرنامج انتقل من الحالة ب إلى الحالة ج، فإن التجميع يثبت أن البرنامج انتقل من الحالة أ إلى الحالة ج. مع وجود عدد كافٍ من العمال، يمكن القيام بذلك في وقت السجل (N)، حيث N هو عدد الأجزاء.
سنرى هذه المراحل قيد التنفيذ عندما نتعمق في الأرقام.
**ما مدى صعوبة بناء كتلة إيثريوم؟ **
أولاً، دعونا نلقي نظرة على مدى تعقيد بناء كتلة إيثريوم. في الجدول أدناه، نأخذ بعض كتل الإيثريوم الحقيقية ونعيد بنائها باستخدام Zeth في zkVM.
على سبيل المثال، الكتلة 17606771 تنتج 2131 نطاقًا. يمثل كل مقطع 2^20 دورة تنفيذ على الأكثر، وبالتالي فإن الحساب بأكمله يستغرق 2,234,515,456 دورة تنفيذ على الأكثر.
بشكل عام، نرى كتلة إيثريوم نموذجية تستغرق ما بين 2 إلى 400 مليون دورة للبناء، ولكن في بعض الأحيان ما يصل إلى 9.5 مليار دورة. (في البداية، فوجئنا برؤية أن هذه الاختلافات لم تنعكس في غاز الصفقة. ولكن بعد التفكير في الأمر أكثر، أصبح الأمر منطقيًا: لقد تم تصميم نظام الغاز مع وضع التنفيذ المنتظم في الاعتبار، وليس إثباتات ZK).
ومع الاستمرارية، يصبح من السهل إدارة هذا النطاق. وفقًا لهذه الأرقام، فإن شبكة نظير إلى نظير المكونة من 10,000 عقدة تقوم بتشغيل أدوات التحقق من صحة zkVM تكفي لتحقيق أعلى أداء تحقق متوازي لأكبر الكتل، وهو جزء صغير من 700,000 أداة تحقق تمتلكها Ethereum حاليًا.
**كم من الوقت يستغرق إنشاء الإثبات؟ **
لجمع بعض بيانات الأداء الأساسية، أطلقنا نسخة اختبار Bonsai مع 64 عاملاً في وحدة معالجة الرسومات. ثم طلبنا منها إثبات حظر 17735424 (182 معاملة، أو 3242 مقطعًا، أو حوالي 3.4 مليار دورة) باستخدام Zeth.
لإنشاء البراهين، يجب على zkVM أولاً تقسيم التنفيذ إلى أجزاء. في لقطة الشاشة أدناه، تم التقاط هذه العملية بواسطة مهمة المستخدم، والتي استمرت لمدة 10 دقائق. (معظم ذلك الوقت هو القيام بأشياء AWS مثل الكتابة إلى وحدة تخزين الشبكة). على الجهاز المحلي، تستغرق نفس المهمة أقل من 6 دقائق لإكمالها. ونأمل أن نخفض هذا الوقت بشكل كبير خلال العام المقبل).
أخيرًا قام المنفذ بتقسيم التنفيذ إلى 3242 قطعة. هذا كثير من التجزئة بالنسبة لـ 64 وحدة معالجة رسوميات فقط. لذلك، يجب أن تقوم كل عقدة عاملة بإنشاء 50 إثباتًا للمقاطع. كما هو موضح في الشكل أدناه، يستغرق ذلك 35 دقيقة. إذا كان لدينا 50 ضعف عدد العقد العاملة، فسيستغرق الأمر 42 ثانية فقط.
بعد اكتمال إثبات المقطع، يبدأ التجميع. نظرًا لوجود 3242 مقطعًا، نحتاج إلى إجراء عملية تراكمية لـ log_2(3242) = 12 جولة. في المراحل الأولى من عملية التجميع، يكون عدد العمال أكبر من عدد العمال؛ لذا تستغرق المرحلة الأولى دقيقة واحدة، وتستغرق المرحلة الثانية 35 ثانية، وتستغرق المرحلة الثالثة 25 ثانية، وهكذا. بحلول المرحلة السابعة، استقر الوقت عند ما يزيد قليلاً عن 5 ثوانٍ. وبالمثل، إذا كان لدينا المزيد من العمال، فستستغرق كل مرحلة 5 ثوانٍ فقط.
بعد اكتمال عملية التجميع، يتم الانتهاء من النتائج، الأمر الذي يستغرق دقيقة أخرى.
ونتيجة لذلك، تمكنا من إنشاء البراهين في حوالي 50 دقيقة (السرعة الفعالة 1.1 ميجاهرتز) مع عدم كفاية حجم المجموعة. إذا كان حجم المجموعة مناسبًا، فإننا نقدر أن إنشاء البراهين سيكون أسرع:
في حالة التوازي الكامل، يمكن إكمال خطوة الإثبات خلال 42 + 12 * 5 + 60 ثانية أو دقيقتين و42 ثانية.
إذا قمنا بالتقريب بشكل متحفظ وقمنا بتضمين وقت المنفذ، فإن الوقت يتراوح بين 9 و12 دقيقة (السرعة الفعالة 4.7 ميجا هرتز - 6.3 ميجا هرتز).
وبينما نواصل تحسين المنفذين وإطار الإثبات لدينا، فإننا متفائلون بأن هذه المرة سيتم تخفيضها بشكل كبير خلال العام المقبل.
استهلاك الموارد لإنشاء البراهين
تم نشر مجموعة الاختبار المذكورة أعلاه على AWS. وهو يتألف من 64 عقدة إثبات g5.xlarge وعقدة تنفيذ m5zn.xlarge واحدة. وفقًا لأمازون، تحتوي كل عقدة g5.xlarge على
حتى كتابة هذه السطور، يبلغ السعر عند الطلب لهذه المثيلات 1.006 دولارًا أمريكيًا في الساعة، والمثيلات المحجوزة هي 0.402 دولارًا أمريكيًا في الساعة. وفي الوقت نفسه، توضح ورقة مواصفات أمازون أن العقدة m5zn.xlarge الخاصة بنا موجودة
حتى كتابة هذه السطور، كان السعر عند الطلب لهذه الحالة هو 0.3303 دولارًا أمريكيًا في الساعة.
يمكننا استخدام هذه الأرقام لتقدير تكلفة الإثبات تقريبًا للكتلة 17735424 الموضحة أعلاه.
تذكر أننا قمنا بنشر 64 عقدة إثبات وفي هذا النشر استغرق الأمر 50 دقيقة (من النهاية إلى النهاية) لإنشاء الإثبات. بتجاهل وقت العامل الخامل، تكلف 64 عقدة إثبات بالإضافة إلى عقدة تنفيذ واحدة 50/60 * (64 * 0.402 + 0.3303) = 21.72 دولارًا لمدة 50 دقيقة. وهذا مبالغة في التقدير لأنه يفترض أننا ندفع للعمال العاطلين عن العمل. إذا لم نأخذ في الاعتبار تكلفة العمال العاطلين عن العمل (على سبيل المثال، إغلاقهم أو تعيينهم في وظائف أخرى)، فإن التكلفة تبلغ حوالي 19.61 دولارًا.
ومن الجدير بالذكر أن هذه التقديرات بالدولار مستقلة عن حجم الكتلة! ما يهم هو عدد الأجزاء. وذلك لأن جهازًا واحدًا يقوم بمهمتين متتابعتين يكلف نفس تكلفة جهازين يقومان بعمل واحد بالتوازي. ولذلك، إذا كان حجم المجموعة أكبر، فسيتم إنشاء البراهين بشكل أسرع، ولكن ليس أكثر تكلفة.
هناك عدة طرق لمزيد من خفض التكاليف. بالإضافة إلى الاستمرار في تحسين أداء zkVM، وربما إضافة مسرع Keccak، يمكننا أيضًا البحث عن مثيلات أرخص. الأهم من ذلك، نظرًا للأجهزة منخفضة المواصفات التي نستخدمها (ويدعم zkVM الخاص بنا nVidia Cuda وApple Metal)، يمكن تنفيذ هذا العمل بسهولة عبر شبكة p2p من أجهزة الكمبيوتر الشخصية وأجهزة Mac الاستهلاكية العادية.
التحقق عبر السلسلة
كما ذكرنا أعلاه، قمنا بالتحقق من إثباتات Zeth على Sepolia باستخدام أداة التحقق من الصحة RISC Zero Groth16. يعد هذا جزءًا جديدًا نسبيًا من حزمة بروتوكول RISC Zero، التي تم إصدارها في وقت سابق من هذا الشهر. إنه يعمل عن طريق استخدام Bonsai لتحويل دليل STARK الأصلي الخاص بـ zkVM إلى دليل SNARK مكافئ، وإرسال هذا الدليل إلى أداة التحقق من صحة SNARK على السلسلة.
إذا نظرنا إلى إدخال المعاملة كبيانات UTF-8، فسنرى أن الدليل يتوافق مع الكتلة 17735424.
باستخدام Bonsai، يستغرق التحويل من STARK إلى SNARK حوالي 40 ثانية. كلف التحقق من SNARK على السلسلة 245,129 دولارًا (حوالي 5.90 دولارًا في وقت كتابة هذا التقرير).
بالطبع، إحدى ميزات zkVM هي أنه يمكنه الجمع بين العديد من البراهين في برهان واحد. باستخدام هذه الوظيفة، يمكن التحقق من مجموعة كاملة من الأدلة على السلسلة دون استخدام أي غاز إضافي. بهذه الطريقة، يمكن توزيع تكلفة التحقق عبر السلسلة عبر مجموعة الأدلة بأكملها، مما يقلل التكلفة للجميع.
ماذا يعني هذا بالنسبة للإيثريوم
كما ذكرنا سابقًا، لم يتم تصميم إيثريوم مع وضع ملاءمة ZK في الاعتبار. كما تظهر حالة zkEVMs، هناك العديد من الأشياء التي يمكن القيام بها بطرق مختلفة، خاصة عندما يتعلق الأمر بأكواد التشغيل والتوقيعات الرقمية ووظائف التجزئة.
على الرغم من أن هذه التغييرات أدت إلى تحسين الأداء، إلا أننا مازلنا قادرين على تحقيق أداء قوي بدون هذه التغييرات. عندما كتب Vitalik عن أنواع مختلفة من zkEVMs العام الماضي، استغرق الأمر ساعات لإثبات صلاحية كتلة Ethereum؛ الآن، يمكننا القيام بذلك في دقائق. يتحسن أداء ZK بسرعة، ولدينا سبب للاعتقاد بأن هذا الاتجاه سيستمر في السنوات القليلة المقبلة.
الملحق: كيف يعمل زيث
هذا القسم مخصص للمطورين.
بشكل تقريبي، يقوم Zeth ببناء الكتل بنفس طريقة بناء العقدة الكاملة: نبدأ بالكتلة الأصلية، وقائمة المعاملات، ومؤلف الكتلة، ثم نقوم بالكثير من العمليات الحسابية (التحقق من التوقيعات، وتشغيل المعاملات، وتحديث الحالة العالمية، وما إلى ذلك). وأخيرًا قم بإرجاع قيمة تجزئة الكتلة الجديدة.
ولكن على عكس العقد الكاملة، فإننا نقوم بذلك في zkVM. هذا يعني أننا حصلنا على دليل ZK على أن الكتلة التي تحتوي على تجزئة معينة صالحة.
وبطبيعة الحال، لا يخلو هذا من التحديات. وفي هذا القسم، نعرض هذه التحديات وكيفية معالجتها.
التشفير
التحدي الأول هو التشفير. يتطلب إنشاء كتلة إيثريوم الكثير من العمل، وأهمها التجزئة (Keccak-256) والتحقق من التوقيع (ECDSA وsecp256k1).
لقد قام zkVM الخاص بنا بتسريع دعم المنحنيات الإهليلجية، لذا فإن التحقق من توقيع ECDSA ليس بالأمر الصعب.
ولكن عندما يتعلق الأمر بالتجزئة، فإننا لسنا محظوظين جدًا. قام zkVM الخاص بنا بتسريع دعم Sha2-256، ولكن ليس (في وقت كتابة هذا التقرير) Keccak-256. لذلك، نستخدم حاليًا تطبيق Keccak فقط في صندوق sha3 Rust. من خلال التنميط، نعلم أن هذا يستغرق الكثير من الدورات. إنه ليس الحل الأمثل، لكن جهاز zkVM الخاص بنا يمكنه التعامل معه، ويمكننا إعادة تدوير مسرعات Keccak وإضافتها لاحقًا.
الحسابات ومساحة التخزين: الأداء والأمان
في إيثريوم، يتم تتبع الحسابات والتخزين بواسطة Merkle Patricia Trie (MPT) العالمية.
وفي وقت كتابة هذا التقرير، كانت الشجرة تحتوي على حالة ما يقرب من 250 مليون عنوان إيثريوم فريد، وفقًا لشركة Etherscan. هذه ليست كمية هائلة من البيانات بشكل عام، ولكنها كافية لجعلنا نكون حذرين بشأن كيفية تخزينها واستخدامها. على وجه الخصوص، أداء MPT أمر بالغ الأهمية.
ولكن الأداء ليس هو العامل الوحيد، يجب علينا أيضا أن نأخذ في الاعتبار الأمن.
يعمل مولد الكتل الخاص بـ Zeth كعميل في zkVM. وهذا يعني أنه لا يمكنه الوصول مباشرة إلى شبكة Ethereum p2p أو موفري RPC الآخرين. وبدلاً من ذلك، يجب أن تعتمد على البيانات المقدمة من برامج منفصلة تعمل خارج zkVM.
عند تحليل أمان تطبيق ZK، يجب أن نفترض أن البرامج الخارجية ضارة وبالتالي قد تخدم بيانات ضارة. ولمنع ذلك، يجب على تطبيقات ZK التحقق من صحة البيانات المقدمة لها.
بالنسبة لمولدات كتلة Zeth، يعني هذا التحقق من حالة جميع الحسابات ووحدات التخزين ذات الصلة (أي الحسابات ووحدات التخزين المطلوبة لتشغيل قائمة معينة من المعاملات).
لحسن الحظ، يتم توفير هذه الآلية بواسطة EIP-1186، والتي تحدد طريقة قياسية لإثبات حالة حساب معين (ومساحة تخزينه) عبر تضمين Merkle.
من حيث المبدأ، يمكن لمولدات الكتل الخاصة بـ Zeth التحقق من حالة الحساب والتخزين من خلال التحقق من مجموعة من إثباتات تضمين EIP-1186. ولكن هذا النهج ليس مثاليا.
بدلاً من ذلك، من الأفضل استخدام البيانات الموجودة في إثبات التضمين EIP-1186 لإنشاء MPT جزئي. هذا نوع من MPT يتضمن فقط العقد ذات الصلة بقائمة معاملات معينة، ويتم تمثيل الفروع غير المرتبطة ببساطة بالتجزئة المقابلة. يمكنك التفكير في MPTs الجزئية كنوع من "اتحاد" إثباتات تضمين Merkle؛ أو، إذا كنت تفضل ذلك، كدليل على مجموعة Merkle الفرعية.
إن عملية التحقق من MPT الجزئي هي في الأساس نفس عملية التحقق من إثبات EIP-1186 العادي: يتم حساب تجزئة الجذر ومقارنتها بجذر الحالة للكتلة الأصلية. وإذا تساوى الاثنان، يمكن الوثوق بسلامة الحسابات والتخزين بداخلها.
بمجرد التحقق من MPT الجزئي، يمكن تطبيق المعاملة وتحديث MPT الجزئي. يمكن الحصول على جذر الحالة الجديد عن طريق حساب قيمة تجزئة الجذر الجديدة لـ MPT الجزئي.
في zkVM، مولد كتلة Zeth:
بعد اكتمال مولد كتلة Zeth، سيتم إخراج قيمة التجزئة للكتلة الجديدة.
تتضمن هذه التجزئة التزامًا بالكتلة الأصلية، وبالتالي جذر الحالة للكتلة الأصلية (المستخدمة للتحقق من MPT الجزئي الأصلي). وهذا يعني أن أداة التحقق الضارة لا يمكنها توفير حسابات وتخزين ببيانات غير صالحة دون توفير كتلة أصل غير صالحة.
بمعنى آخر: إذا كانت الكتلة الأصلية صالحة، فإن الكتلة الجديدة التي تم إنشاؤها بواسطة Zeth صالحة أيضًا.
لذا، إذا أعطاك شخص ما كتلة جديدة وإثبات ZK تم إنشاؤه بواسطة Zeth، فيمكنك التحقق من صحة الكتلة عن طريق التحقق من الأشياء الثلاثة التالية:
إذا تم التحقق من ذلك، فإن الكتلة الجديدة صالحة.
القيود والتحسينات المستقبلية
الهدف من مشروعنا هو دراسة أداء بناء الكتل. لهذا السبب، قررنا قصر النطاق على الكتل المدمجة.
بالإضافة إلى ذلك، في حين أن Zeth قادر على إثبات صحة كتلة معينة، فإنه لا يمكنه حاليًا إثبات الإجماع (أي أن الكتلة مدرجة بالفعل في السلسلة الأساسية). قد يتغير هذا في المستقبل، ربما عن طريق إضافة عمليات فحص لتوقيعات المدقق أو لجنة المزامنة في zkVM.
أخيرًا، Zeth هو برنامج جديد. على الرغم من قيامنا ببعض الاختبارات (بما في ذلك مجموعة اختبار Ethereum والعديد من الكتل الواقعية)، إلا أن Zeth قد لا يزال يحتوي على بعض الأخطاء. وحتى كتابة هذه السطور، ينبغي اعتباره برنامجًا تجريبيًا.