المؤلف: a16z crypto
مُترجم: Deep潮 TechFlow
مقدمة من Shenchao: كان يُنتقد zkVM باستمرار بسبب "بطء إثباتاته وحجمه الكبير"، لكن a16z استخدمت تشفيرًا قائمًا على الشبكات لاستبدال المنحنيات البيضاوية، مما زاد من سرعة الإثبات ثلاث مرات وخفض حجم الإثبات إلى أقل من 100 كيلوبايت. إنه الحل الوحيد الحالي الذي يتفوق على مخططات المنحنيات البيضاوية التقليدية من حيث السرعة، ويؤثر مباشرة على تكلفة التحقق على السلسلة وتطبيقات الخصوصية.

نُطلق اليوم رسميًا Lattice Jolt، وهو أحدث إصدار من zkVM (الآلة الافتراضية ذات المعرفة الصفرية) المفتوح المصدر لدينا. كان Jolt بالفعل أسرع وأبسط zkVM حاليًا، ولم يتغير هيكله. لكن التشفير الأساسي تم استبداله: من المنحنيات البيضاوية إلى تشفير الشبكات. هذا التغيير الوحيد يحقق ثلاث أمور في آنٍ واحد:
- Jolt يصبح آمنًا بعد الكمية.
- تم تحسين سرعة prover و verifier بمقدار 2-3 مرات.
- Lattice Jolt أصبحت تمتلك أقصر إثبات بين جميع zkVM ما بعد الكم: حاليًا أقل من 100 كيلوبايت، مع إمكانية ضغط إضافي في المستقبل. نظرًا لأن الإثباتات تحتاج إلى التسجيل على السلسلة ونقلها عبر الشبكات، كلما كان الإثبات أصغر، انخفضت تكلفة التحقق.
تغطي هذه الميزات جميع سيناريوهات استخدام zkVM. يمكن لـ prover واحد معالجة مليارات دورات المعالج على وحدة معالجة الرسوميات، كما يمكنه إثبات ملايين الدورات على الهاتف الذكي. في كلا الحالتين، يكتب المطورون برامج عادية دون الحاجة إلى كتابة دوائر تتطلب معرفة متخصصة. هذا هو السبب في أننا نقول إن Jolt هو "SNARK الشامل".
لكن القصة الأكبر هي أهمية Lattice Jolt لتصميم واعتماد SNARK. حاليًا، جميع أنظمة SNARK ما بعد الكمية التي تم إطلاقها في السوق تقريبًا تعتمد على التجزئة. أثبت Lattice Jolt أن SNARK القائم على الشبكات يمكن أن يكون أسرع وأكثر كفاءة. تمر التوقيعات الرقمية بنفس التحول: فحلول التجزئة هي الخيار المحافظ، لكن حلول الشبكات هي التي يتم نشرها على نطاق واسع في العالم. نتوقع أن يسلك SNARK نفس المسار، وسيشرح الجزء الثاني من هذه المدونة السبب.
استبدل المنحنى الإهليلجي بالشبكة
كان مخطط الالتزام متعدد الحدود السابق لـ Jolt يُسمى Dory، وهو المكون الوحيد في النظام الذي يعتمد على التشفير المنحني البيضاوي. استبدلت Lattice Jolt Dory بـ Akita، وهو مخطط امتياز متعدد الحدود جديد يستند إلى افتراض Module-SIS. تستند Lattice Jolt إلى هذا الافتراض القياسي والمستند إلى أبحاث وافرة، وتتوافق مع أمان كامل بمستوى 128 بت.
تنتمي وحدة-SIS وأخوها وحدة-LWE إلى نفس عائلة الافتراضات، والتي تنتقل إليها البنية التحتية الرقمية في جميع أنحاء العالم. لا تدعم هذه الافتراضات معيار التوقيع الرقمي ML-DSA فحسب، بل تدعم أيضًا معيار إنشاء المفتاح ML-KEM، الذي يُعد الآن أكثر المبادئ ما بعد الكم تعميمًا عالميًا.
يقود تطوير وتنفيذ Akita باحثون وهندسيون من LayerZero، بالتعاون مع باحثين من جامعة كارنيغي ميلون وجامعة جنوب كاليفورنيا، فريقنا الهندسي وفريق البحث في a16z crypto.
لماذا لاتيس جولت أسرع؟
Lattice Jolt ليس فقط آمنًا ما بعد الكم، بل هو أسرع من إصدار المنحنيات البيضاوية الذي استُبدل.
التسارع يعود إلى سبب بسيط. تجبر المنحنى الإهليلجي Jolt على العمل في مجال مكون من 256 بت، بينما يمكن للترميز الشبكي تحقيق نفس مستوى الأمان في مجال مكون من 128 بت. إن العمل الرئيسي لـ Jolt prover هو ضرب عناصر المجال (جوهره ضرب أرقام ضخمة جدًا)، لذا فإن تقليل حجم الأرقام إلى النصف يجعل كل عملية ضرب أسرع بعدة مرات.
Jolt مع Dory سريع بالفعل: أظهرت آخر تحديثات الأداء لدينا أن Jolt يمكنه إثبات حوالي 700,000 دورة RISC-V (RV64IMAC) في الثانية على جهاز كمبيوتر محمول، وبعد التحسينات، تجاوزت نسخة Jolt المنحنية عتبة المليون دورة في الثانية.
يمكن لـ Lattice Jolt إثبات أكثر من مليوني دورة في الثانية على نفس الجهاز.
لقد قضينا معظم الأشهر الستة الماضية لا فقط في تطوير Akita ودمجه في Jolt، بل أيضًا في إعادة كتابة قاعدة كود Jolt من الصفر. كان Jolt قادرًا بالفعل على الأداء جيدًا على وحدات معالجة الرسومات، لكن هذه إعادة الكتابة جعلت تنفيذ وحدات معالجة الرسومات أسهل في البناء والتحسين.
الإنجاز الأول هو تنفيذ Apple Metal، الذي حقق تسريعًا كبيرًا للأجهزة الخاصة بـ Apple. (Metal هو إطار عمل من Apple يُستخدم لتنفيذ التعليمات البرمجية على وحدات معالجة الرسوميات المدمجة في أجهزة مثل MacBook وiPhone.)
- يُمكن لـ Lattice Jolt المُسرّع بـ GPU إثبات أكثر من 10 ملايين دورة RV64IMAC في الثانية على MacBook.
- يستطيع Lattice Jolt الذي يعمل فقط بالـ CPU إثبات أكثر من مليوني دورة في الثانية على نفس الجهاز.
- حتى إصدار المنحنى من Jolt يمكنه الآن تحقيق حوالي 4 ملايين دورة في الثانية على MacBook مع Metal.
بمعنى آخر، أدى نشر واحد إلى رفع Jolt على MacBook من حوالي 1 مليون دورة في الثانية (النسخة المنحنية، CPU فقط) إلى أكثر من 10 ملايين دورة في الثانية (النسخة الشبكية، مع Metal).
عند النظر إلى هذه الأرقام في السياق الأوسع: قبل أربع سنوات، عندما كتبنا لأول مرة عن تكلفة مُثبت SNARK، كان إثبات حساب ما يكلف ملايين المرات أكثر من تشغيله مباشرة. وقد خفض Lattice Jolt هذه التكلفة إلى حوالي عشرة آلاف مرة. ولم ينتهِ الأمر بعد، فما زال هناك مجال للتحسين على مستوى الهندسة والبروتوكول.
حجم الإثبات وسرعة المُثبت متساويان في الأهمية. مع حجم أقل من 100 كيلوبايت، فإن إثباتات Lattice Jolt أصغر بكثير من غيرها من zkVM ما بعد الكمية، حيث تتراوح إثباتات الحلول الأخرى بين 200 كيلوبايت وأكثر من 600 كيلوبايت.
بعد التحويل إلى格، تحسّن استهلاك الذاكرة الخاص بـ Jolt، الذي كان ممتازًا بالفعل: انخفض استخدام المساحة الخاص بالـ prover من حوالي 300 بايت لكل دورة إلى 200 بايت. هذا يعني أنه يمكنك إثبات ملايين دورات RISC-V على هاتفك.
سيتم نشر ورقة بحثية مصاحبة قريبًا لإضافة خاصية الصفرية المعرفية إلى Lattice Jolt، وهي الخاصية المطلوبة للتطبيقات الخاصة.
لماذا تختار غريغ بدلاً من هاش؟
على مدار سنوات، ركز مجتمع SNARK على SNARKs القائمة على التجزئة (وتقريبًا جميع نشرات الإنتاج) كطريق نحو الأمان ما بعد الكمي.
لكن كان هناك دائمًا خط بحث مستمر في SNARKs وCommitments القائمة على الشبكات، يشمل LaBRADOR وGreyhound وLatticeFold وSuperNeo، بالإضافة إلى Hachi، السلف المباشر لـ Akita. يبني Lattice Jolt على هذه الأبحاث، مُقدّمًا طبقة التزامات القائمة على الشبكات إلى بنية zkVM عالية الأداء، مع إثبات أن SNARKs القائمة على الشبكات لا تُضاهى في السرعة والكثافة.
هذا لا ينبغي أن يكون مفاجئًا. كما ذُكر سابقًا، حدث نفس النمط بالفعل على التوقيعات الرقمية.
لقد بُنِيَتْ التوقيعات من قبل علماء التشفير بناءً على العديد من الافتراضات. تُعتبر التوقيعات القائمة على التجزئة عادةً الخيار الأكثر حذراً: فافتراضات أمانها بسيطة وقديمة. لكن العالم يتجه بشكل رئيسي نحو توقيعات الشبكات، لأنها أقصر وأسرع:
- تبلغ مساحة توقيع ML-DSA بضعة كيلوبايت.
- بديل التوقيع المعياري SLH-DSA المعياري من قبل NIST أكبر بكثير.
- بالنسبة للتشفير وتبادل المفاتيح، الوضع أكثر وضوحًا: لا توجد خيارات لخوارزميات التجزئة ممكنة على الإطلاق (وقد تم إثبات استحالة ذلك)، ويعتمد النشر ما بعد الكمي بشكل ساحق على الشبكات. تم نشر ML-KEM (المعيار الرئيسي لإنشاء المفتاح الذي حددته NIST في عام 2024) بشكل افتراضي في المتصفحات الرئيسية وتطبيقات التواصل، ويُستخدم على نطاق واسع في اتصالات TLS على الإنترنت.
التشبيه بين SNARK والتوقيعات الرقمية ليس سطحيًا. التوقيعات الرقمية هي في جوهرها دليل على معرفة المفتاح الخاص برسالة مُصرّح بها. وتوسّع SNARK هذا النموذج من بيان ضيق إلى أي حسابات عشوائية. لذا، سيكون غريبًا إذا كانت الخريطة التشفيرية الطويلة الأمد لـ SNARK مختلفة تمامًا عن خريطة التوقيعات والتشفير.
هناك أيضًا سوء فهم يستحق التوضيح: غالبًا ما يُوصف هاش SNARK بأنه خيار ما بعد الكم المحافظ، لأنه "يعتمد فقط على وظائف التجزئة". وهذا صحيح فقط إذا كانت وظيفة التجزئة الأساسية غير جبرية.
في الوقت الحالي، تعتمد معظم نشرات SNARK القائمة على التجزئة على بنى تجزئة جبرية صديقة لـ SNARK (مثل Poseidon) لإثبات تقييم التجزئة بدقة وبتكلفة منخفضة. وهذا أمر بالغ الأهمية للترميز التكراري (حيث يشير الترميز التكراري إلى إثبات امتلاكك إثبات SNARK صالح). هذه البنى تمتلك هيكلًا أكثر من وظائف التجزئة القياسية، بينما لا تزال تحليلها التشفيري غير ناضج.
ببساطة، لا نثق بأمان دوال التجزئة الجبرية. ومع ذلك، لا تزال تُستخدم على نطاق واسع في أنظمة SNARK المنتجة اليوم. (لكن ظهر إشارة تقدم: أعلنت مؤسسة إيثريوم مؤخرًا عن التخلي عن استخدامها.)
ليس التخفيض الجبري أحد الافتراضات المخفية الوحيدة في أنظمة SNARK القائمة على التجزئة المُنفَّذة: فقد استخدمت العديد من الأنظمة تاريخيًا حدودًا تخمينية للفجوة القريبة لتحديد مستويات أمان محددة، بدلاً من استخدام حدود مُثبتة بالكامل. وقد ثبت لاحقًا أن بعض هذه الحدود التي اعتُبرت الأقوى كانت خاطئة.
حتى لو تم تجنب SNARK القائم على التجزئة المذكور أعلاه، فإن أهداف الأمان الخاصة به عادةً ما تكون أقل من 128 بت، لأن الأمان الكامل البالغ 128 بت يُسبب عبئًا أداءً ملحوظًا. لماذا؟ لا يمكن لـ SNARK القائم على التجزئة تحقيق أمان 128 بت على مجال 128 بت، لأن خطأ الموثوقية يتناسب مع n/|F|، حيث n تقريبًا حجم الجملة المُثبتة، و|F| هو حجم المجال. وبالتالي، فإن إثبات جملة تضم مليار خطوة على مجال 128 بت يفقد حوالي 30 بت من الأمان، مما يجعله أقل من 100 بت. على النقيض من ذلك، فإن خطأ الموثوقية في Lattice Jolt يتناسب مع log(n)/|F|، مما يحافظ تقريبًا على أمان 128 بت الكامل على نفس المجال (يمكن استعادة خسارة قليلة من log(n) عبر تقنيات قياسية).
بشكل ساخر، تعتمد بعض الأنظمة التي تم الترويج لها كخيارات "محفظة" ما بعد الكم على دوال تجزئة جبرية، وحدود تقريبية استنتاجية، ومستوى أمان مستهدف أقل من 128 بت. وبالتالي، على الرغم من أن SNARKs القائمة على التجزئة اتجاه مهم، إلا أنها لا تصبح تلقائيًا خيارًا منخفض المخاطر كما يظن الكثيرون.
جولت واحد، ثلاثة أساسيات: المنحنى، الشبكة، والهاش
لطالما اعتبرنا أن Jolt لا ينبغي ربطه بأساس تشفيري واحد. يجب أن نمتلك SNARK ناضجة وعالية الأداء مبنية على المنحنيات والدوال التجزئة والشبكات. ستكون الافتراضات المختلفة وخصائص الأداء مناسبة لسيناريوهات مختلفة.
لكن إذا تم استخدام التوقيع الرقمي كمرجع، فستصبح SNARK القائمة على الشبكة الخيار الأكثر انتشارًا بعد الكمية.
يتمتع Jolt بميزة استثنائية خلال هذا التحول. استخدم التصميم الأصلي لـ Jolt الخصائص المفيدة من منحنيات بيضاوية للالتزام، بما في ذلك القدرة على إجراء التزامات سريعة للمتجهات النادرة. تمتلك التزامات الشبكة نفس الخصائص: عندما تكون معظم مدخلات المتجه صفرًا أو صغيرة، يكون تكلفة الالتزام بالمتجه منخفضة، بينما يلتزم Jolt تقريبًا فقط بمثل هذه المتجهات. هذه الخاصية تسمح لنا باستبدال Dory بـ Akita مع الحفاظ على باقي أجزاء Jolt دون تغيير.
سنقوم ببناء إصدار Jolt القائم على التجزئة. لكن مقارنة بالإصدارات القائمة على المنحنيات والقائمة على الشبكات، فإن الإصدار القائم على التجزئة أقل كفاءة من حيث التخزين، ويحتوي على إثباتات أكبر، ويعاني من مشكلات معقدة متنوعة. وذلك لأن أكثر الأعمال الواعدة في SNARK القائم على التجزئة تتم على الحقل الثنائي. هذا النظام العددي يسهل إثبات تقييم التجزئة، لكنه لا يتوافق مع طريقة الحساب التي تستخدمها وحدات المعالجة المركزية. هذا عدم التوافق يجعل إثبات ضرب وحدات المعالجة المركزية العادية مكلفًا. رغم ذلك، يجب أن يمتلك النظام البيئي zkVM في كل عائلة افتراضية رئيسية، تمامًا كما هو الحال في مجال التوقيعات الرقمية.
SNARK الشامل
يُلبّي Lattice Jolt جميع احتياجات المطورين لـ zkVM في مرة واحدة: مقاوم لما بعد الكمي، شفاف، سريع، مضغوط، وفعال من حيث المساحة. إنه ينقل مسار بحث SNARK الخاص بالشبكة من LaBRADOR إلى Hachi إلى zkVM جاهز للإنتاج، دون التخلي عن أي من الميزات التي جعلت Jolt سريعًا في الأصل.
هدفنا ليس فقط جعل zkVM الأسرع مفتوح المصدر للاستخدام من قبل أي شخص، بل أيضًا القضاء بشكل كبير على الحاجة إلى ضبط SNARK يدويًا لكل تطبيق محدد. هذا لا يتطلب أن يكون Jolt بنفس سرعة البروتوكولات المُحسَّنة يدويًا. هذا هدف مستحيل، تمامًا مثل مطالبة وحدة المعالجة المركزية بالمنافسة مع ASICات المخصصة في كل مهمة. إنه يتطلب فقط أن يكون Jolt سريعًا بما يكفي لتوفير تجربة مستخدم مقبولة.
بالنسبة للعبارات "الصغيرة" المرتبطة بإثبات العميل (حيث تهيمن الدوائر المُحسَّنة يدويًا حاليًا على هذه السيناريوهات)، فإن المعيار الأساسي هو توليد الإثبات في أقل من ثانية واحدة على الهاتف. وقد وصل Jolt بالفعل إلى مشارف هذا الهدف، كما أن هناك العديد من خطط التسريع قيد التقدم.
لقد حان عصر SNARK.
يُستخدم هذا المحتوى لأغراض إعلامية فقط ولا ينبغي الاعتماد عليه كنصيحة قانونية أو تجارية أو استثمارية أو ضريبية. يجب عليك استشارة مستشاريك الخاصين بشأن هذه المسائل. أي إشارة إلى أي أوراق مالية أو أصول رقمية تهدف فقط إلى التوضيح ولا تشكل نصيحة استثمارية أو عرضًا لتقديم خدمات استشارية استثمارية. علاوة على ذلك، لا يُوجَّه هذا المحتوى إلى أي مستثمر أو مستثمر محتمل، ولا يجوز استخدامه بأي حال من الأحوال كأساس لاتخاذ قرار بالاستثمار في أي صندوق يديره a16z. (يتم تقديم عرض الاستثمار في صناديق a16z فقط من خلال وثائق العرض الخاص، واتفاقيات الاشتراك، ومستندات أخرى ذات صلة، ويجب قراءة هذه الوثائق بالكامل.) لا تمثل أي استثمار أو شركة مدرجة أو مذكورة أو موصوفة جميع الاستثمارات في أدوات إدارة a16z، ولا يمكن ضمان تحقيق ربح من هذه الاستثمارات، ولا يمكن ضمان أن الاستثمارات المستقبلية ستكون لها خصائص أو نتائج مشابهة. يمكن الاطلاع على قائمة الاستثمارات التي قام بها الصناديق التي يديرها Andreessen Horowitz (باستثناء الاستثمارات التي لم تسمح الجهة المصدرة لـ a16z بالإفصاح عنها علنًا، والاستثمارات في الأصول الرقمية المدرجة غير المعلنة) على https://a16z.com/investments/
الرسوم البيانية المقدمة في النص هي لأغراض إرشادية فقط ولا ينبغي استخدامها كأساس لأي قرار استثماري. الأداء السابق لا يدل على النتائج المستقبلية. يمثل هذا المحتوى الوضع كما هو في التاريخ المذكور. أي توقعات أو تقديرات أو بيانات استشرافية أو أهداف أو آفاق و/أو آراء معبر عنها في هذه المواد قد تتغير في أي وقت دون إشعار سابق، وقد تختلف أو تتعارض مع آراء الآخرين. لمزيد من المعلومات المهمة، راجع https://a16z.com/disclosures.

