مقال واحد لفهم Jolt zkEVM الذي أطلقته a16z

المؤلف: مايكل تشو (مهندس أبحاث التشفير a16z)، سام راجسدال (مهندس استثمار التشفير a16z)؛ الترجمة: Golden Finance xiaozou

في 9 أبريل 2024، أصدر فريق البحث والهندسة لتشفير a16z تقرير Jolt الأولي التنفيذ، طريقة تصميم SNARK جديدة أسرع مرتين من التكنولوجيا الحالية، مع المزيد من التحسينات القادمة.

تعد الحوسبة القابلة للتحقق (المعروفة باسم ZK) تقنية قوية جدًا تنطبق على كل من سلاسل الكتل وغيرها. فهو يمكّن أحد أجهزة الكمبيوتر (المدقق) من تفويض العمليات الحسابية إلى جهاز كمبيوتر آخر أكثر قوة (المثبت) ويجعله يتحقق بشكل فعال من أن الحسابات قد تم إجراؤها بشكل صحيح.

في صناعة التشفير، تتضمن تطبيقات الحسابات التي يمكن التحقق منها (خاصة SNARKs) ما يلي:

الطبقة تستخدم سلاسل الكتل L2 (L2) SNARKs لضمان سلامة انتقالات حالتها.

• يستخدم الجسر عبر السلسلة SNARKs إثبات عمليات الإيداع والسحب من سلسلة إلى أخرى.

• يستخدم "المعالج المساعد ZK" (المحدد بواسطة Axiom) SNARKs لإثبات العمليات الحسابية خارج السلسلة لبعض البيانات الموجودة على السلسلة، مثل نظرًا لأن تكلفة الحساب الأصلي لهذه البيانات الموجودة على السلسلة في العقود الذكية مرتفعة جدًا.

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

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

لطالما تم وصف الحوسبة التي يمكن التحقق منها على أنها واعدة بالحل النهائي لتوسيع نطاق blockchain، لكن التكنولوجيا تواجه ثلاثة عوائق رئيسية أمام اعتمادها:

• الأداء:تنفيذ يقدم برنامج الإثبات أوامر ذات حجم أعلى من التنفيذ الأصلي.

• التعقيد:يثير تعقيد SNARKs مخاوف بشأن أمان تنفيذها، لأنه سيكون مسؤولاً لأمن مليارات الدولارات من الأصول الموجودة على السلسلة.

• التوفر: الخبرة المطلوبة للغات الخاصة بالمجال (DSL) مثل Circom ضخمة غير متاح لمعظم مطوري البرامج.

يتغلب تطوير الأجهزة الافتراضية ذات المعرفة الصفرية (zkVMs) على العائق الثالث (سهولة الاستخدام) لأن zkVMs تسمح للمطورين بكتابة البرامج في لغات البرمجة عالية المستوى مثل Rust أو Go لا تتطلب أي معرفة بـ SNARK الأساسي لإثبات تنفيذها. لكن التوفر المتزايد لـ zkVMs يؤدي أيضًا إلى زيادة الأداء (من 8 إلى 9 أوامر من حيث الحجم) والنشر المعقد.

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

الآن، يسعدنا إطلاق نشر Jolt مفتوح المصدر لمجموعة تعليمات RV32I، والوفاء بالوعد الذي قطعته في مقالة Jolt.

• سريع:< يعد نشرنا أسرع بأكثر من 5 مرات من RISC Zero وأسرع مرتين من SP1 الذي تم إصداره للتو في المعايير الأولية.

• موجز (نسبيًا):قاعدة التعليمات البرمجية بأكملها أقل من 25000 سطر من Rust (أقل من نصف وحدات zkVM الأخرى)، تستغرق تعليمات وحدة المعالجة المركزية الواحدة 50 سطرًا فقط من التعليمات البرمجية لتنفيذها.

بعد ذلك، دعونا نلقي نظرة على معايير الأداء. يمكننا أن نرى أن Jolt هو zkVM الناشئ الأكثر تقدمًا. لقد قدمنا ​​أيضًا بعض الإرشادات للمطورين المهتمين بتطوير التطبيقات التي تستخدم Jolt، بالإضافة إلى معاينة خريطة الطريق للمطورين المهتمين بالمساهمة في Jolt - نتوقع أن يصبح Jolt أسرع وأسهل في الاستخدام في الأشهر المقبلة.

تم بناء فريق هندسة التشفير a16z على إيمان راسخ بقيمة المصدر المفتوح. سيؤدي جعل Jolt منتجًا عامًا مفتوح المصدر إلى تسريع أبحاث zkVM وأبحاث SNARK الأوسع وصناعة web3 بأكملها. إن بناء التشفير في صوامع مغلقة المصدر (حيث لا يمكن للجمهور مراجعة الكود) غالبًا ما يؤدي إلى زيادة الثقة في نظام غير جدير بالثقة.

1، الأداء

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

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

يقيس معيارنا a16z/zkvm Jolt وSP1 وRISC Zero على مجموعة متنوعة من برامج Rust المختلفة. والنتيجة هي أن الأداء النسبي متشابه بين العديد من برامج RV32 المماثلة. يشير الشكل أدناه إلى برنامج يقوم بتنفيذ سلسلة تجزئة Sha2.

نتائج هذه المعايير موضحة أدناه. تم تشغيل المعايير على جهاز AWS r7g.16xlarge ARM مع 64 مركزًا لوحدة المعالجة المركزية وذاكرة الوصول العشوائي (RAM) بسعة 512 جيجا بايت DDR5. جميع المعايير مخصصة لوحدة المعالجة المركزية فقط.

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

2، كيفية استخدام Jolt تم تطويره وبناءه

لجعل Jolt سهل الاستخدام قدر الإمكان، توفر Jolt SDK (التي أنشأها شريك هندسة التشفير a16z Noah Citron) العناصر الأساسية وظائف حول أغلفة النماذج القصيرة Jolt. كل ما عليك فعله هو: إضافة السمة jolt_sdk::provable إلى الوظيفة التي تريد إثباتها.

بعد ذلك، ستتمكن من استخدام وظائف build_* لإنشاء مُثبت ومُحقق.

راجع مثال فيبوناتشي الكامل (وغيره) في مستودع الأكواد.

للحصول على فهم أعمق لبنية Jolt، يعد Jolt Book (WIP) مستندًا محدثًا مباشرًا حول اختيارات التصميم وقواعد التعليمات البرمجية غير الموثقة في مقالات Jolt. خلال الأسابيع القليلة المقبلة، سنصدر المزيد من المحتوى للمطورين المهتمين بالبناء على Jolt أو التعرف على العناصر الداخلية لـ Jolt.

3. ما هي الخطوة التالية

على الرغم من أهمية Jolt علامة فارقة في مجال zkVM، ولكن لا يزال أمامنا طريق طويل لنقطعه. إذا نظرنا خطوة إلى الوراء، تظهر معايير الأداء لدينا أن برنامج Jolt (الموجود على M3 Max) أثبت أنه برنامج يتمتع بسرعة معالج 100 كيلو هرتز - ضعف قوة الحوسبة على متن مهمة أبولو 11 القمرية المأهولة. لإجراء مقارنة متواضعة أخرى، فهي أبطأ بمقدار 150 مرة من الآلة الحاسبة الرسومية TI-84.

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

• Binius: اقترح Ben Diamond وJim Posen مؤخرًا مخطط التزام متعدد الحدود متعدد الخطوط وهو مفيد بشكل خاص لأنظمة مثل Jolt لأن القيمة الموعودة صغيرة. سيؤدي دمج Binius مع خوارزمية التحقق من مجموع النطاق الصغير الخاصة بـ Justin Thaler إلى تحسين أداء إثبات Jolt بشكل كبير (نقدر 5-10 مرات).

• مزيد من التعليمات: تنشر قاعدة كود Jolt حاليًا RV32I، لكن بنية Jolt مرنة للغاية. نحن نخطط لإضافة امتداد RISC-V "M" لتوفير الدعم لضرب الأعداد الصحيحة وقسمتها، كما هو موضح في مقالة Jolt. بالإضافة إلى ذلك، يمكن لـ Jolt دعم متغير 64 بت RV64IM بسهولة.

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

• تكرار الإثبات: من خلال الجمع بين Jolt ونظام إثبات آخر، نقوم بتقليل حجم الإثبات ووقت التحقق بشكل أكبر . على سبيل المثال، يمكن تنفيذ أداة التحقق من صحة Jolt باستخدام لغة Circom لإنشاء أدلة Groth16 ذات الحجم الثابت والتي يمكن التحقق منها بكفاءة على السلسلة.