a16z تطلق Lattice Jolt: إثبات أسرع بثلاث مرات ومقاوم للهجمات الكمومية
Panewslabبقلم: a16z crypto
ترجمة: Deep Tide TechFlow
مقدمة Deep Tide: لطالما انتُقدت zkVM (الآلة الافتراضية ذات المعرفة الصفرية) بسبب "بطء الإثبات وكبر حجمه"، لكن a16z استبدلت هذه المرة المنحنيات الإهليلجية بالتشفير الشبكي، مما جعل الإثبات أسرع بثلاث مرات وقلص حجمه إلى أقل من 100 كيلوبايت. هذا هو الحل الوحيد ما بعد الكمومي الذي يتفوق حاليًا على حلول المنحنيات الإهليلجية التقليدية من حيث السرعة، وله تأثير مباشر على تكلفة التحقق على السلسلة وتطبيقات الخصوصية.
نعلن اليوم رسميًا عن إطلاق Lattice Jolt، أحدث إصدار من zkVM مفتوحة المصدر. كان Jolt بالفعل أسرع وأبسط zkVM، ولم تتغير بنيته. لكن التشفير الأساسي تغير: من المنحنيات الإهليلجية إلى التشفير الشبكي. هذا التغيير الواحد يجلب ثلاثة أشياء في آن واحد:
- أصبح Jolt آمنًا ما بعد الكمومي.
- تحسنت سرعة المُثبِت (prover) والمُحقق (verifier) بمقدار 2-3 مرات.
- أصبح Lattice Jolt صاحب أقصر إثبات بين جميع zkVM ما بعد الكمومية: حاليًا أقل من 100 كيلوبايت، ويمكن ضغطه أكثر لاحقًا. الإثبات يحتاج إلى وضعه على السلسلة ونقله عبر الشبكات، وكلما كان الإثبات أصغر، انخفضت تكلفة التحقق.
تغطي هذه الميزات جميع حالات استخدام zkVM. نفس المُثبِت يمكنه معالجة مليارات دورات وحدة المعالجة المركزية على وحدة معالجة الرسومات، وإثبات ملايين الدورات على الهاتف المحمول. في كلتا الحالتين، يكتب المطورون برامج عادية دون الحاجة إلى كتابة دوائر يدويًا تتطلب معرفة متخصصة. لهذا نقول إن Jolt هو "SNARK شامل".
لكن القصة الأكبر هي ما يعنيه Lattice Jolt لتصميم واعتماد SNARK (حجة معرفة موجزة غير تفاعلية). تقريبًا جميع SNARK ما بعد الكمومية المنتجة حاليًا في السوق مبنية على التجزئة. يثبت Lattice Jolt أن SNARK المبنية على الشبكات يمكن أن تكون أسرع وأكثر إحكامًا. تمر التوقيعات الرقمية بنفس التحول: حلول التجزئة هي الخيار المحافظ، لكن حلول الشبكات هي ما ينشره العالم على نطاق واسع. نتوقع أن تسلك SNARK نفس المسار، وسيشرح النصف الثاني من هذه المقالة السبب.
استبدال المنحنيات الإهليلجية بالشبكات
كان مخطط الالتزام متعدد الحدود السابق في Jolt يسمى Dory، وكان المكون الوحيد في النظام الذي يعتمد على تشفير المنحنيات الإهليلجية. يستبدل Lattice Jolt مخطط Dory بمخطط Akita، وهو مخطط التزام متعدد الحدود جديد تمامًا يعتمد على افتراض الشبكة Module-SIS. يعتمد Lattice Jolt على هذا الافتراض القياسي المدروس جيدًا، ويستهدف أمانًا كاملاً بمقدار 128 بت.
ينتمي Module-SIS وشقيقه Module-LWE إلى نفس عائلة الافتراضات التي تهاجر إليها البنية التحتية الرقمية في العالم. هذه الافتراضات لا تدعم فقط معيار التوقيع الرقمي ML-DSA، بل تدعم أيضًا معيار إنشاء المفاتيح ML-KEM، وهو بالفعل أكثر البدائيات ما بعد الكمومية انتشارًا على مستوى العالم.
قاد تطوير وتنفيذ Akita باحثون ومهندسون من LayerZero، بمشاركة باحثين من جامعة كارنيجي ميلون (Carnegie Mellon University) وجامعة جنوب كاليفورنيا (University of Southern California) وفريقنا الهندسي والبحثي في a16z crypto.
لماذا Lattice Jolt أسرع
Lattice Jolt ليس آمنًا ما بعد الكمومي فحسب، بل إنه أسرع من نسخة المنحنيات الإهليلجية التي حل محلها.
يأتي التسريع أساسًا من سبب بسيط. تجبر المنحنيات الإهليلجية Jolt على العمل في حقل 256 بت، بينما يحقق التشفير الشبكي نفس مستوى الأمان في حقل 128 بت. العمل الرئيسي لمُثبِت Jolt هو ضرب عناصر الحقل (وهو في الأساس ضرب أعداد ضخمة)، لذا فإن خفض حجم الأرقام إلى النصف يجعل كل عملية ضرب أسرع بعدة مرات.
كان Jolt مع Dory سريعًا بالفعل: أظهر آخر تحديث للأداء أن Jolt يمكنه إثبات حوالي 700,000 دورة RISC-V (RV64IMAC) في الثانية على جهاز كمبيوتر محمول، ودفعت التحسينات اللاحقة نسخة المنحنيات من Jolt إلى أكثر من مليون دورة في الثانية.
يمكن لـ Lattice Jolt إثبات أكثر من مليوني دورة في الثانية على نفس الجهاز.
خلال معظم الأشهر الستة الماضية، لم نكتفِ بتطوير Akita ودمجه في Jolt، بل أعدنا كتابة قاعدة كود Jolt من الصفر. كان Jolt يعمل جيدًا على وحدات معالجة الرسومات من قبل، لكن إعادة الكتابة هذه جعلت تنفيذ GPU أسهل في البناء والتحسين.
أول نتيجة هي تنفيذ Apple Metal، الذي جلب تسريعًا هائلاً لأجهزة Apple. (Metal هو إطار عمل Apple لتشغيل الكود على وحدات معالجة الرسومات المدمجة في أجهزة مثل MacBook وiPhone.)
- يمكن لـ Lattice Jolt المسرع بوحدة معالجة الرسومات إثبات أكثر من 10 ملايين دورة RV64IMAC في الثانية على MacBook.
- يمكن لـ Lattice Jolt بوحدة المعالجة المركزية فقط إثبات أكثر من مليوني دورة في الثانية على نفس الجهاز.
- حتى نسخة المنحنيات من Jolt يمكنها الآن تحقيق حوالي 4 ملايين دورة في الثانية على MacBook مع Metal.
أي أن إصدارًا واحدًا رفع Jolt على MacBook من حوالي مليون دورة في الثانية (نسخة المنحنيات، وحدة المعالجة المركزية فقط) إلى أكثر من 10 ملايين دورة في الثانية (نسخة الشبكات، مع Metal).
لنضع هذه الأرقام في سياقها: عندما كتبنا لأول مرة عن تكلفة مُثبِت SNARK قبل أربع سنوات، كان إثبات عملية حسابية أغلى بملايين المرات من تنفيذها مباشرة. خفض Lattice Jolt هذه التكلفة إلى حوالي عشرة آلاف مرة. لم نصل إلى الحد الأقصى بعد، فلا تزال هناك مساحة للتحسين على مستوى الهندسة والبروتوكول.
حجم الإثبات لا يقل أهمية عن سرعة المُثبِت. بحجم أقل من 100 كيلوبايت، أصبح إثبات Lattice Jolt أصغر بكثير من zkVM الأخرى ما بعد الكمومية، التي تتراوح إثباتاتها من أكثر من 200 كيلوبايت إلى حوالي 600 كيلوبايت أو أكثر.
بعد التحول إلى الشبكات، تحسن أيضًا استخدام الذاكرة الممتاز أصلًا في Jolt: انخفض استخدام مساحة المُثبِت من حوالي 300 بايت لكل دورة إلى 200 بايت. هذا يعني أنه يمكنك إثبات ملايين دورات RISC-V على الهاتف المحمول.
ستُنشر قريبًا ورقة بحثية مصاحبة تضيف خاصية المعرفة الصفرية إلى Lattice Jolt، وهي خاصية تحتاجها تطبيقات الخصوصية.
لماذا الشبكات بدلاً من التجزئة
لسنوات، تركز اهتمام مجتمع SNARK (وجميع عمليات النشر الإنتاجية تقريبًا) على SNARK المبنية على التجزئة كطريق نحو الأمان ما بعد الكمومي.
لكن كان هناك أيضًا خط بحثي مستمر حول SNARK والتزامات الشبكات، يشمل LaBRADOR وGreyhound وLatticeFold وSuperNeo، والسلف المباشر لـ Akita وهو Hachi. يبني Lattice Jolt على هذه الأبحاث، جالبًا طبقة التزامات الشبكات إلى بنية zkVM عالية الأداء، ومثبتًا أن SNARK المبنية على الشبكات لا مثيل لها في السرعة والإحكام.
لا ينبغي أن يكون هذا مفاجئًا. كما ذكرنا، حدث النمط نفسه بالفعل في التوقيعات الرقمية.
بنى علماء التشفير توقيعات بناءً على افتراضات عديدة. عادة ما تُعتبر توقيعات التجزئة الخيار الأكثر تحفظًا: افتراضاتها الأمنية بسيطة وقديمة. لكن العالم يتجه بشكل أساسي إلى توقيعات الشبكات لأنها أقصر وأسرع:
- توقيعات ML-DSA تبلغ حوالي بضعة كيلوبايت.
- البديل المعياري من NIST للتجزئة SLH-DSA أكبر بعدة مرات.
- بالنسبة للتشفير وتبادل المفاتيح، الوضع أوضح: لا يوجد خيار تجزئة على الإطلاق (هناك إثبات على استحالة ذلك)، والنشر ما بعد الكمومي يعتمد بشكل ساحق على الشبكات. ML-KEM (معيار إنشاء المفاتيح الرئيسي الذي حدده NIST في 2024) تم نشره افتراضيًا بالفعل في المتصفحات الرئيسية وتطبيقات المراسلة، ويُستخدم في عدد كبير من اتصالات TLS على الإنترنت.
التشبيه بين SNARK والتوقيعات ليس سطحيًا. التوقيع الرقمي هو في جوهره إثبات معرفة بالمفتاح الخاص لرسالة مصرح بها. توسع SNARK هذا النموذج من بيان ضيق إلى حسابات عشوائية. لذا سيكون من الغريب أن تختلف الخريطة التشفيرية طويلة المدى لـ SNARK تمامًا عن خريطة التوقيعات والتشفير.
هناك أيضًا سوء فهم يستحق التوضيح: كثيرًا ما توصف SNARK المبنية على التجزئة بأنها الخيار المحافظ ما بعد الكمومي لأنها "تعتمد فقط على دوال التجزئة". هذا صحيح فقط إذا كانت دالة التجزئة الأساسية غير جبرية.
اليوم، تعتمد معظم عمليات نشر SNARK المبنية على التجزئة على بنى تجزئة جبرية صديقة لـ SNARK (مثل Poseidon) لإثبات تقييم التجزئة بتكلفة منخفضة. هذا مهم بشكل خاص للتكرار (نعني بالتكرار هنا إثبات أنك تملك إثبات SNARK صالحًا). هذه البنى لها بنية أكثر من دوال التجزئة القياسية، وتحليلها التشفيري غير ناضج.
باختصار، لسنا واثقين من أمان دوال التجزئة الجبرية. ومع ذلك، فهي تُستخدم على نطاق واسع اليوم في أنظمة SNARK الإنتاجية. (لكن هناك إشارة تقدم: أعلنت مؤسسة إيثريوم (Ethereum Foundation) مؤخرًا أنها ستتخلى عن استخدامها.)
التجزئة الجبرية ليست الافتراض الخفي الوحيد في SNARK المبنية على التجزئة المنشورة: تاريخيًا، استخدمت العديد من الأنظمة حدود proximity-gap التخمينية لتحديد مستويات أمان ملموسة بدلاً من استخدام حدود مثبتة بالكامل. بعض هذه الحدود التي اعتُبرت الأقوى ثبت لاحقًا أنها خاطئة.
حتى عند تجنب SNARK المبنية على التجزئة التخمينية المذكورة أعلاه، فإن أهدافها الأمنية عادة ما تكون أقل من 128 بت، لأن الأمان الكامل بمقدار 128 بت يفرض تكلفة أداء كبيرة. لماذا؟ لا يمكن لـ SNARK المبنية على التجزئة تحقيق أمان 128 بت في حقل 128 بت، لأن خطأ الموثوقية يتناسب مع n/|F|، حيث n هو حجم البيان المُثبت تقريبًا و|F| هو حجم الحقل. لذا فإن إثبات بيان بمليار خطوة في حقل 128 بت يفقد حوالي 30 بت من الأمان، مما يجعله أقل من 100 بت. بالمقارنة، يتناسب خطأ موثوقية Lattice Jolt مع log(n)/|F|، مما يحافظ تقريبًا على أمان 128 بت الكامل في نفس الحقل (يمكن استرداد خسارة log(n) الصغيرة بتقنيات قياسية).
من المفارقات أن بعض الأنظمة التي يُروج لها كخيارات "محافظة" ما بعد الكمومية تعتمد في الواقع في نفس الوقت على دوال تجزئة جبرية وحدود proximity-gap تخمينية ومستويات أمان مستهدفة أقل من 128 بت. لذلك، بينما تعد SNARK المبنية على التجزئة اتجاهًا مهمًا، فهي ليست تلقائيًا الخيار منخفض المخاطر الذي يعتقده الكثيرون.
Jolt واحد، ثلاث أسس: المنحنيات والشبكات والتجزئة
لطالما رأينا أن Jolt لا ينبغي أن يرتبط بأساس تشفيري واحد. يجب أن نمتلك SNARK ناضجة وعالية الأداء مبنية على المنحنيات والتجزئة والشبكات. ستناسب الافتراضات وخصائص الأداء المختلفة سيناريوهات مختلفة.
لكن إذا كانت التوقيعات الرقمية مرجعًا، فإن SNARK المبنية على الشبكات ستصبح الخيار ما بعد الكمومي الأكثر انتشارًا.
يتمتع Jolt بموقع متميز بشكل غير عادي في هذا التحول. استغل تصميم Jolt الأصلي خصائص المنحنيات الإهليلجية المفيدة بشكل خاص للالتزامات، بما في ذلك الالتزام السريع بالمتجهات المتفرقة. تتمتع التزامات الشبكات بنفس الخاصية: عندما تكون معظم عناصر المتجه صفرًا أو صغيرة، تكون تكلفة الالتزام بالمتجه منخفضة، وJolt يلتزم تقريبًا فقط بهذا النوع من المتجهات. سمحت لنا هذه الخاصية باستبدال Dory بـ Akita مع الحفاظ على بقية Jolt دون تغيير.
سنبني نسخة من Jolt مبنية على التجزئة. لكن مقارنة بـ Jolt المبني على المنحنيات والشبكات، فإن النسخة المبنية على التجزئة أسوأ في كفاءة المساحة، وإثباتاتها أكبر، ولديها مشاكل تعقيد متنوعة. هذا لأن أكثر SNARK المبنية على التجزئة الواعدة تعمل في الحقول الثنائية. هذا النظام العددي مناسب لإثبات تقييم التجزئة، لكنه لا يتوافق مع طريقة حساب وحدة المعالجة المركزية. هذا عدم التطابق يجعل إثبات ضرب وحدة المعالجة المركزية العادي مكلفًا. ومع ذلك، يجب أن يمتلك النظام البيئي zkVM تحت كل عائلة افتراضات رئيسية، كما هو الحال في مجال التوقيعات الرقمية.
SNARK شامل
يلبي Lattice Jolt جميع احتياجات البنائين من zkVM دفعة واحدة: ما بعد الكمومي، شفاف، سريع، مدمج، وفعال في المساحة. إنه يجلب خط أبحاث SNARK الشبكية من LaBRADOR إلى Hachi إلى zkVM إنتاجي، دون التخلي عن أي من المزايا التي جعلت Jolt سريعًا في الأصل.
هدفنا ليس فقط جعل أقوى zkVM مفتوح المصدر متاحًا للجميع، بل أيضًا القضاء بشكل كبير على الحاجة إلى ضبط SNARK يدويًا لتطبيقات محددة. هذا لا يتطلب أن يكون Jolt بنفس سرعة المُثبتات المضبوطة يدويًا. هذا هدف مستحيل، مثل مطالبة وحدة المعالجة المركزية بمضاهاة ASIC متخصص في كل مهمة. يتطلب فقط أن يكون Jolt سريعًا بما يكفي لتقديم تجربة مستخدم مقبولة.
بالنسبة للبيانات "الصغيرة" المتعلقة بإثباتات العميل (حيث تهيمن الدوائر المحسنة يدويًا اليوم)، فإن المعيار الرئيسي هو توليد إثبات في حوالي ثانية واحدة على الهاتف المحمول. Jolt يقترب بالفعل من تحقيق ذلك، وهناك العديد من خطط التسريع قيد التنفيذ.
لقد حان عصر SNARK الشبكية.
هذا المحتوى لأغراض معلوماتية وتعليمية فقط، ولا يمثل نصيحة استثمارية تتعلق بـ BTCC. تبذل BTCC قصارى جهدها ولكنها لا تضمن صحة أو دقة أو أصالة المحتوى المذكور أعلاه.