"العناصر الأساسية للبنائين: 'الصدمة الداخلية'" من a16z

المؤلف: a16z crypto؛ تجميع: Block unicorn

مقدمة

أصدرت LayerZero اليوم سلسلتها الجديدة، Zero، التي تتضمن العديد من التطورات التقنية، بما في ذلك طريقة إثبات جديدة تعتمد على مبدأ انعدام المعرفة، والتي تفصل تنفيذ المعاملات عن التحقق منها. كل هذا بفضل "Jolt Inside".

ما هو Jolt؟ Jolt عبارة عن آلة افتراضية مفتوحة المصدر تعتمد على معمارية RISC-V zkVM (آلة افتراضية تعتمد على مبدأ انعدام المعرفة، أو بتعبير أدق، آلة افتراضية "بسيطة")، وهي سريعة وآمنة وسهلة الاستخدام.

يمثل هذا منهجية تصميم SNARK جديدة ومتطورة طورتها شركة a16z crypto على مدار ثلاث سنوات، وقد أتحناها كمصدر مفتوح ليستخدمها أي شخص أو يطورها. لكن في الواقع، قصة ولادة Jolt هي قصة تتشكل منذ عقود. لماذا تُعد تصميمات zkVM وSNARK بهذه الأهمية؟ قبل الخوض في تطور تصميم SNARK، نحتاج أولاً إلى فهم ماهية zkVM. يُطلق على هذا النوع من الآلات الافتراضية غالبًا اسم "آلة افتراضية zk"، ولكن السمة الأكثر شيوعًا هنا هي البساطة. بينما يُعدّ "انعدام المعرفة" أمرًا بالغ الأهمية للخصوصية، فإن "البساطة" تعني أن تكون البراهين قصيرة وسهلة التحقق - وهما سمتان مفيدتان ولكنهما متميزتان، وغالبًا ما يتم الخلط بينهما. (تتمتع منصة Jolt بالفعل بالبساطة، وستحقق قريبًا براهين انعدام المعرفة). ولكن لماذا تُعدّ zkVM بهذه الأهمية؟ تُعدّ zkVM، وبشكل أوسع SNARKs (براهين المعرفة البسيطة غير التفاعلية)، مكونات أساسية لقابلية التوسع والخصوصية والأمان في تقنية البلوك تشين. لهذه البراهين والحجج وبراهين انعدام المعرفة (المعروفة مجتمعةً بتقنيات الحوسبة القابلة للتحقق) تطبيقات لا حصر لها في صناعة العملات المشفرة وخارجها. نظرًا لهياكل التصميم التقليدية وأسباب أخرى، فقد اعتمدت الصناعة حتى الآن نهجًا معقدًا نسبيًا لبناء zkVM؛ وسيتم مناقشة هذا بمزيد من التفصيل لاحقًا. ومع ذلك، ركزت Jolt منذ البداية على نهج تصميم SNARK مختلف جذريًا، بهدف تحقيق كفاءة وسهولة استخدام وأداء أفضل. باختصار، zkVM هي طريقة لإثبات أنك شغّلت برنامج كمبيوتر بشكل صحيح. تكمن ميزة zkVM على غيرها من تقنيات SNARK في سهولة استخدامها من قِبل المطورين. فمن خلال الاستفادة من البنية التحتية الحاسوبية الحالية (مثل نظام LLVM مفتوح المصدر)، يستطيع المطورون تسخير قوة SNARK في لغة البرمجة التي يختارونها دون الحاجة إلى لغة برمجة خاصة بالمجال (DSL). وهذا يُشبه إلى حد كبير العديد من مجالات التشفير الحديثة اليوم، حيث تتوفر لدينا مكتبات قياسية مدمجة للتشفير والتوقيعات الرقمية، والتي يستخدمها المطورون العاديون يوميًا دون الحاجة إلى فهم آليات عملها. يوفر Jolt للمطورين نفس التجريد: ببساطة، استخدم البرامج الموجودة وتحقق من صحتها دون القلق بشأن التفاعل بينها. وهذا أمرٌ ضروري لأي تطبيق جديد واسع الانتشار للتشفير. إذ يُمكن للمطورين التركيز على الجوانب العملية. مع Jolt، لا يحتاج المطورون إلى أي خبرة في SNARK؛ إذ يُمكنهم إنشاء Jolt من شفرة الحاسوب الموجودة لديهم بضغطة زر. ومع ذلك، حتى مع التطورات الكبيرة التي شهدها Jolt، لا يزال إثبات أي برهان معقد نسبيًا (مثل عملية تستغرق ثانية واحدة من نواة معالج قياسية واحدة) يتطلب قدرة حاسوبية كبيرة. لإنشاء براهين معقدة في وقت معقول، أنت بحاجة إلى وحدات معالجة رسومية متعددة. قامت LayerZero بنقل مُثبت Jolt إلى CUDA باستخدام Zero: فهو يجمع بين خوارزمية Jolt الأساسية عالية التوازي مع الأجهزة المتوازية لوحدات المعالجة الرسومية، مما يحقق قابلية توسع أكبر. تلتزم LayerZero بتوفير Jolt في براهين جاهزة للإنتاج على وحدات المعالجة الرسومية، بما في ذلك التعاون معنا لتطوير إصدارات مُلائمة لوحدات المعالجة الرسومية من خوارزمية Jolt، وهو أمر بالغ الأهمية لتحسين zkVM وقابلية توسع البراهين. تطوير مفتوح المصدر: Jolt نفسه مفتوح المصدر، لذا يمكن لأي شخص استخدامه أو التطوير بناءً على تقنياته المبتكرة. المصادر المفتوحة هي المُضاعف الأمثل: فمشاركة النتائج علنًا تسمح لمزيد من الأشخاص في النظام البيئي بالاستخدام وإعادة الاستخدام واختبار التحمل/التدقيق/الإصلاح والتحسين والابتكار بشكل أكبر. قد يبدو استثمار شركات رأس المال الاستثماري في مشاريع مفتوحة المصدر أمرًا غير معتاد، لكن هيكل البحث والتطوير الحديث يفرض أن معظم أعمال التطوير تتم إما داخل الشركات - مثل مختبرات الشركات في الماضي أو مختبرات المؤسسات اليوم - أو في الأوساط الأكاديمية. هدفنا من إنشاء معهد أبحاث التشفير a16z هو إنشاء مختبر أبحاث صناعي وفريق هندسي يربط النظرية الأكاديمية بالتطبيق العملي في الصناعة. وبصفتنا شركة رأس مال مخاطر، يمكننا أيضًا تمويل مشاريع لا تستطيع المؤسسات الأخرى تمويلها، لا سيما في مجال الهندسة العكسية. يُعد دعم منهجيات الهندسة العكسية لـ SNARKs أمرًا بالغ الأهمية لشركة Jolt. يكتسب هذا أهمية خاصة لأنه يُمثل نقلة نوعية جذرية تختلف اختلافًا كبيرًا عن أساليب التصميم السابقة. وقد استغرق هذا التطور في التصميم سنوات عديدة. غالبًا ما تدور قصة الابتكار حول تحويل التصميم المعماري. لفهم التغييرات الرئيسية التي أدخلتها Jolt على منهجية تصميم SNARK، يجب أن نعود إلى أكثر من ألفي عام: فقد كان الإغريق القدماء روادًا في تطوير أنظمة البرهان الرياضي الرسمية، والتي توسع فيها لاحقًا علماء في الشرق الأوسط وآسيا ومناطق أخرى. كانت هذه البراهين المبكرة - وهي عبارة عن اشتقاقات منطقية خطوة بخطوة - تُكتب بلغة أو صيغة رسمية بحيث يمكن لأي شخص التحقق منها. على سبيل المثال، يمكن لرياضي أن يكتب البرهان في "كتاب"، ثم يقرأه رياضي آخر كلمةً كلمةً للتحقق منه. هذا المفهوم التقليدي للبرهان الكتابي الثابت هو تجسيد لفئة التعقيد الشهيرة "P مقابل NP". تجدر الإشارة إلى أن هذه الطريقة التقليدية للبرهان تسلسلية وتتطلب التناوب: فهي ثابتة وليست تفاعلية. مع ذلك، في عام 1985*، اقترح شافي غولدواسير وسيلفيو ميكالي وتشارلز راكوف برهانًا تفاعليًا. مفهوم البرهان التفاعلي (IP). [*في الواقع، قُدِّمت ورقتهم البحثية قبل ذلك بسنوات، ولكن لم تُقبل إلا بعد رفضها عدة مرات]. الفكرة الأساسية لهذه الطريقة التفاعلية للبرهان هي أنه، على سبيل المثال، إذا كان رياضيان يتواصلان، فلا داعي لانتظار أحدهما حتى يكتب البرهان قبل محاولة إقناع الآخر. بدلًا من ذلك، يمكنهما طرح الأسئلة في الوقت الفعلي؛ أي يمكنهما استكشاف جوهر البرهان من خلال التفاعل. لم تُدرك القوة الهائلة لهذا النوع من البراهين التفاعلية -مقارنةً بالبراهين الثابتة التقليدية التي ابتكرها الإغريق القدماء- إدراكًا كاملًا إلا بعد خمس سنوات، أي في عام 1990. في ذلك الوقت، اقترح كارستن لوند، ولانس فورتناو، وهوارد كارلوف، ونوام نيسان بروتوكول التحقق بالجمع: وهو أسلوب جبري لأنظمة البراهين التفاعلية. وبالاقتران مع عمل آدي شامير... أدت الأعمال اللاحقة سريعًا إلى الاستنتاج الأساسي القائل بأن "IP = PSPACE" - وهو بيان تقني يُلخص البيان البديهي التالي: إذا كان بإمكان المُثبتين والمُتحققين التفاعل -أي الانخراط في التحدي والاستجابة كما هو الحال في أنظمة البراهين التقليدية (بافتراض أن المُثبت الكاذب لن يُكشف بتحدٍ لا يستطيع الإجابة عليه)- فعندئذٍ، مقارنةً بالبراهين التقليدية الثابتة المكتوبة لليونان القديمة، يُمكننا التحقق بسرعة من... إثبات عبارات أكثر تعقيدًا.

بعبارة أخرى: تُعطينا الخصائص التفاعلية ميزة كبيرة في أنظمة البراهين.

ويُعدّ التحقق من المجموع جوهر ترجمة هذه الميزة إلى تحقق فعال، إذ يسمح للمُدقِّق بالتحقق من النتيجة المُدَّعى بها دون إعادة بناء العملية الحسابية بأكملها المراد إثباتها.

بعد بضع سنوات، اقترح جو كيليان بناء براهين موجزة خالية من المعرفة المسبقة استنادًا إلى البراهين الاحتمالية القابلة للتحقق (PCP). في نظرية البرهان الخاصة بـ PCP، يكتب المُثبت (يمكن تخيله كعالم رياضيات يوناني قديم، إلا أنه الآن جهاز كمبيوتر) برهانًا بسيطًا في "كتاب"، لكن هذا الشكل مُكرر للغاية. تجدر الإشارة إلى أن هذا التكرار يسمح للمُدقِّق بعدم قراءة الكتاب بأكمله: إذ يكفيه اختيار عددٍ مُحدد من مواضع البرهان عشوائيًا - كثلاث "كلمات" مثلًا - للحكم على صحة البرهان بأكمله بثقة عالية.

مع ذلك، تكمن المشكلة في بروتوكول PCP. فالبرهان نفسه طويل، على الرغم من انخفاض تكلفة التحقق. لذلك، أوضح كيليان كيفية دمج بروتوكول PCP مع التشفير، مما يسمح للمُثبِت "بالالتزام" بإكمال هذا "الكتاب الطويل"، ثم الكشف عن بضع كلمات مُستخرجة فقط مع إقرار تشفيري موجز. البرهان النهائي في بروتوكول كيليان هو في الواقع هذه الكلمات القليلة (بالإضافة إلى بعض بيانات الإقرار التشفيري) - لكنها كافية لإقناع المُدقِّق بصحة الكتاب بأكمله. كانت هذه البراهين تفاعلية في ذلك الوقت. لاحقًا، أوضح ميكالي كيفية تحويل براهين كيليان التفاعلية القائمة على بروتوكول PCP إلى براهين غير تفاعلية بتطبيق تحويل فيات-شامير. باختصار، يُلغي تحويل فيات-شامير التحدي العشوائي للمُدقِّق، مما يسمح للمُثبت بإنشاء التحدي بنفسه وإخراج البرهان كاملاً دفعة واحدة. الأثر الدائم للبنى القديمة: بالنظر إلى تاريخ وتطور أنظمة البرهان، رأينا تقدماً من ثابت إلى تفاعلي، ثم إلى احتمالي وغير تفاعلي، ثم العودة إلى التفاعلي (انظر كيليان)، وأخيراً العودة إلى غير التفاعلي (انظر ميكالي). ظهرت بنى SNARK في نهاية هذا التطور: بتطبيق تحويل فيات-شامير على براهين كيليان التفاعلية، حصل ميكالي على ما نسميه الآن أول بنية SNARK. مع ذلك، في بنى SNARK المبكرة القائمة على الاحتمالية وغير التفاعلية، كان عبء العمل على المُثبت هائلاً - كان وقت الحساب طويلاً للغاية - مما جعل نشرها غير عملي. ومع ذلك، ظلت منهجية تصميم بنى SNARK دون تغيير لعقود. على الرغم من محاولات الصناعة الابتعاد عن أساليب تصميم SNARK القائمة على بروتوكول التحقق من الجمع (PCP)، استمر المصممون في استخدام مفاهيم ذات صلة (مثل "PCP الخطي")، وهي في جوهرها تنويعات على أساليب PCP الاستدلالية. وبينما أسفرت هذه الأساليب بالفعل عن SNARKs ذات براهين قصيرة للغاية، إلا أنها لم تُنتج أسرع SNARKs للمُثبتين. لقد فشل مصممو SNARKs باستمرار في العودة إلى مصدرهم الأساسي - بروتوكول التحقق من الجمع - لتحقيق مُثبتين أسرع وأكثر سهولة في الاستخدام، وهو ما أصبح ممكنًا الآن مع الحوسبة الحديثة. وللعودة خطوة إلى الوراء، فإن اعتماد بروتوكول التحقق من الجمع في وقت مبكر يتطلب دراسة تاريخ وتطور SNARKs الموضح أعلاه بطريقة غير خطية. من (أ) البراهين التفاعلية ← (ب) PCP ← (ج) البراهين التفاعلية الموجزة ← (د) SNARKs المبكرة. على مدار تطورها، شهدت الصناعة التحولات التالية: في الانتقال من (أ) البراهين التفاعلية إلى (ب) PCP، كان التحدي الرئيسي هو إزالة التفاعلات من نظام البرهان مع الحفاظ على بساطة التحقق. دفع هذا المصممين إلى التخلي عن بروتوكول التحقق التجميعي (أي الجزء التفاعلي). مع ذلك، عند الانتقال من (ب) بروتوكول التحقق التجميعي (PCP) إلى (ج) براهين المعرفة الصفرية الموجزة، عادت التفاعلات للظهور... وفي النهاية، أُزيلت هذه التفاعلات من خلال تحويل فيات-شامير، ما أدى إلى الانتقال من (ج) البراهين التفاعلية الموجزة إلى (د) نماذج SNARK المبكرة. عند النظر إلى هذه الخطوات بشكل خطي من (أ) إلى (ب) إلى (ج) إلى (د)، نلاحظ بوضوح أن مصممي SNARK قد أغفلوا التفاعل مرتين - مرة من (أ) إلى (ب) ومرة ​​أخرى من (ج) إلى (د). مع ذلك، إذا أردنا استخدام فيات-شامير لإزالة التفاعل، فعلينا تخطي الخطوة الوسيطة (ب)، وهي البرهان القابل للتحقق الاحتمالي! يُعد تخطي هذه الخطوة الوسيطة (ب) الفكرة الأساسية وراء طريقة Jolt، التي تبني SNARK مباشرةً من البرهان التفاعلي، متجهةً مباشرةً إلى التحقق التجميعي. لماذا لم يتجه المزيد من المصممين إلى منهجية تصميم تعتمد على بروتوكولات التحقق من المجموع في وقتٍ سابق؟ ربما يعود ذلك إلى التشابه الظاهري بين PCP وSNARK، حيث يطبق كلاهما مفهوم التحقق الموجز. أما بالنسبة للتطورات اللاحقة، فقد يستمر هذا التشابه في البنية، وما يصاحبه من سوء فهم. بالنسبة لنا، يُعد استثمار موارد هندسية وبحثية كبيرة في zkVM Jolt القائم على التحقق من المجموع رهانًا مخالفًا للتيار السائد، إذ يتعارض مع النموذج الذي هيمن على مجال SNARK لعقود. تعتمد منهجية تصميم SNARK (التي بدورها تعتمد على آليات التقييم الدفعي وفحص الذاكرة، مثل Twist + Shout) على البراهين التفاعلية وبروتوكول المجموع الاختباري. الآن، وبعد بضع سنوات من بدء تطوير Jolt، بدأ آخرون في تبني منهجية بروتوكول المجموع الاختباري في تصاميمهم. فما هي أبرز ميزات Jolt في zkVM اليوم؟ يُحسّن Jolt استخدام البنى المتكررة في تنفيذ وحدة المعالجة المركزية إلى أقصى حد. من خلال مراقبة كيفية تطبيق تجريد "جلب-فك تشفير-تنفيذ" لكل نواة معالج على آليات التقييم الدفعي، يحقق Jolt كفاءة لا مثيل لها بأقل قدر من التعقيد. في المقابل، تعتمد zkVMs الأخرى بشكل كبير على تطبيقات "مُجمّعة مسبقًا" (شبيهة بمُسرّعات ASIC لروتينات فرعية مُحددة) لتحقيق أداء معقول. يتخلى Jolt عن هذه التجميعات المُسبقة لأنها ستُكرر أخطاء SNARK السابقة لـ zkVM. فشل نهج التصميم: نظرًا لأن SNARKs المُتخصصة هذه تتطلب تصميمًا خبيرًا، فهي أكثر عرضة للأخطاء وأصعب على المُطورين في استخدامها. يُركز Jolt على جعل SNARKs أكثر سهولة في الوصول إليها. يُعد التحقق من صحة تنفيذ وحدة المعالجة المركزية القيمة الأساسية لـ zkVM - واختراقًا كبيرًا في تجربة المُطور - لأنه يسمح بإعادة استخدام البنية التحتية الحاسوبية العامة المُحسّنة الحالية. تم بناء البنية التحتية الحاسوبية العالمية لدعم وحدات المعالجة المركزية، ويستفيد Jolt بشكل كامل من "بنية" تنفيذ وحدة المعالجة المركزية، مما يزيد من البساطة والأداء. يُعطي Jolt الأولوية لسهولة الاستخدام منذ البداية. تُعطى الأولوية للأداء عالي الجودة: إذ يُمكن للمطورين التحقق من صحة البرامج الحالية مباشرةً؛ حتى في حالة التحقق السريع، لا يلزم إجراء أي تعديلات على الكود. على عكس الحلول الأخرى التي تُجبر الفرق على إعادة هيكلة التطبيقات باستخدام واجهات برمجة تطبيقات "مُجمّعة مسبقًا" أو واجهات برمجة تطبيقات خاصة لتحقيق أداء مقبول، يحافظ Jolt على سلامة الكود الأصلي، مما يُسهّل اعتماده ومراجعته ويُقلّل من تكلفة تطويره. والأهم من ذلك، أن Jolt ليس أسرع فحسب، بل أبسط أيضًا. تتطلب الحلول الأخرى من مصممي zkVM تحديد دائرة لكل تعليمة أساسية في الآلة الافتراضية، بينما لا يتطلب Jolt ذلك: في Jolt، يُمكن تحديد كل تعليمة أساسية في حوالي عشرة أسطر من كود Rust. لا حاجة لدوائر، فقط عشرة أسطر من الكود. ما هي الخطوة التالية لـ Jolt؟ نحن بالفعل رواد في السرعة. مع المزيد من التحسينات وإضافة ميزات، بما في ذلك الاستدعاء الذاتي وإثباتات المعرفة الصفرية - وخاصةً تحوّلنا المُخطط له من تشفير المنحنى الإهليلجي إلى تشفير الشبكة - سنحقق تحسينًا في السرعة بمقدار عشرة أضعاف في وقت لاحق من هذا العام، ناهيك عن عصر ما بعد الحوسبة الكمومية. يُتيح تطبيق Jolt المزيد من التطبيقات. بالنسبة لتقنية البلوك تشين، ستصبح قابلية التوسع واللامركزية التي طال انتظارها أسهل بكثير في النشر. تتوفر ميزة تجميع إثباتات المعرفة الصفرية بشكل فوري، مما يُغني عن الحاجة إلى شهور أو حتى سنوات من هندسة التشفير. ومع استمرار تطوير Jolt - على سبيل المثال، من خلال إنشاء آلة افتراضية سريعة وسهلة الاستخدام لإثباتات المعرفة الصفرية، والتي يمكن تشغيلها على الهواتف وأجهزة الكمبيوتر المحمولة - سيتمكن المطورون من اكتشاف المزيد من حالات الاستخدام فيما يتعلق بجانب العميل وحماية الخصوصية. على سبيل المثال، يمكن للتطبيقات التي تحافظ على الخصوصية على الهواتف المحمولة أن تتحول بسهولة من تطبيقات يصعب صيانتها إلى تطبيقات شبه مستحيلة التشغيل فورًا. على المدى البعيد، ستصبح أنظمة الإثبات هذه عنصرًا أساسيًا في البنية التحتية الرقمية العالمية، على غرار التشفير والتوقيعات الرقمية. تُعد تقنية الضغط المشفر الشاملة هذه - حيث يمكن لأي شخص إثبات امتلاكه لبيانات بحجم غيغابايتات تُطابق سمات محددة عن طريق إرسال ملف إثبات بحجم 50 كيلوبايت، بدلاً من البيانات بأكملها - قوية للغاية لدرجة أنه من الصعب التنبؤ بالتطبيقات التي سيتم تطويرها باستخدامها. إمكانياتها لا حصر لها.