ZK المتخصصة مقابل ZK العامة: أيهما المستقبل؟

التخصيص والتعميم، أيهما مستقبل ZK؟ دعني أحاول الإجابة عن هذا السؤال برسم بياني:

كما هو موضح في الشكل، هل من الممكن أن نصل إلى نقطة سحرية مثالية على نظام إحداثيات المفاضلة في المستقبل؟

لا، مستقبل الحوسبة القابلة للتحقق خارج السلسلة هو منحنى مستمر يطمس الحدود بين ZK المتخصصة والعامة. اسمحوا لي أن أشرح التطور التاريخي لهذه المصطلحات وكيف ستتقارب في المستقبل.

قبل عامين، كانت البنية التحتية “المتخصصة” لـ ZK تعني أطر عمل الدوائر منخفضة المستوى مثل circom و Halo2 و arkworks. كانت تطبيقات ZK التي تم إنشاؤها باستخدام هذه الأطر عبارة عن دوائر ZK مكتوبة يدويًا بشكل أساسي. كانت سريعة وفعالة من حيث التكلفة لمهام محددة ولكن عادةً ما كان من الصعب تطويرها وصيانتها. وهي شبيهة بمختلف رقائق الدوائر المتكاملة المتخصصة (رقائق السيليكون المادية) في صناعة الدوائر المتكاملة اليوم، مثل رقائق NAND ورقائق التحكم.

ومع ذلك، على مدار العامين الماضيين، أصبحت البنية التحتية ZK المتخصصة أكثر “تعميمًا” تدريجيًا.

لدينا الآن أطر عمل ZKQL و ZK coprocessor و ZKSK التي توفر حزم SDK سهلة الاستخدام وقابلة للبرمجة بدرجة كبيرة لبناء فئات مختلفة من تطبيقات ZK دون كتابة سطر واحد من كود دائرة ZK. على سبيل المثال، يسمح معالج ZK coprocessor للعقود الذكية بالوصول دون ثقة إلى الحالات والأحداث والمعاملات التاريخية للبلوك تشين وتشغيل عمليات حسابية عشوائية على هذه البيانات. يُمكِّن ZKML العقود الذكية من استخدام نتائج استدلال الذكاء الاصطناعي بطريقة غير موثوقة للتعامل مع مجموعة واسعة من نماذج التعلم الآلي.

تعمل هذه الأطر المطورة على تحسين قابلية البرمجة بشكل كبير في المجالات المستهدفة مع الحفاظ على الأداء العالي والتكلفة المنخفضة بسبب طبقات التجريد الرقيقة (SDK/API) القريبة من الدوائر المعدنية المجردة.

وهي شبيهة بوحدة معالجة الرسومات ووحدة معالجة الرسومات، ووحدة معالجة الرسومات، و FPGA في سوق الدوائر المتكاملة: متخصصون في المجال القابل للبرمجة.

كما خطت ZKVM خطوات كبيرة خلال العامين الماضيين. والجدير بالذكر أن جميع تطبيقات ZKVM ذات الأغراض العامة مبنية على أطر ZK منخفضة المستوى ومتخصصة. والفكرة هي أنه يمكنك كتابة تطبيقات ZK بلغات عالية المستوى (أكثر سهولة في الاستخدام من SDK/API)، والتي يتم تجميعها في مجموعة من الدوائر المتخصصة ومجموعات التعليمات (RISC-V أو ما شابه WASM). إنها مثل رقائق وحدة المعالجة المركزية في صناعة الدوائر المتكاملة.

ZKVM هي طبقة تجريدية فوق أطر ZK منخفضة المستوى، تمامًا مثل معالجات ZK المساعدة.

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

قبل عامين، كان أداء ZKVM “العاري” ضعيفًا بالفعل. ولكن، في غضون عامين فقط، تحسن أداء ZKVM بشكل ملحوظ.

لماذا؟

لأن هذه ZKVMs “للأغراض العامة” أصبحت أكثر “تخصصًا”. أحد الأسباب الرئيسية لتحسين الأداء هو “التجميع المسبق”. هذه التجميعات المسبقة عبارة عن دوائر ZK متخصصة قادرة على حوسبة البرامج عالية المستوى الشائعة، مثل SHA2 وعمليات التحقق من التوقيعات المختلفة، بشكل أسرع بكثير من تقسيمها إلى أجزاء دارة التعليمات.

وبالتالي، أصبح الاتجاه الآن واضحًا تمامًا.

أصبحت البنية التحتية المتخصصة ZK المتخصصة أكثر عمومية، بينما أصبحت ZKVMs العامة أكثر تخصصًا.

وقد حققت التحسينات التي أجريت على كلا الحلين خلال السنوات القليلة الماضية نقطة مفاضلة أفضل من ذي قبل: إحراز تقدم في نقطة دون التضحية بنقطة أخرى. ولهذا السبب يشعر الطرفان بأننا “نحن المستقبل بالتأكيد”.

ومع ذلك، تخبرنا حكمة علم الحاسوب أننا سنواجه في مرحلة ما “جدار باريتو الأمثل” (الخط الأخضر المتقطع)، حيث لا يمكننا تحسين أداء ما دون التضحية بأداء آخر.

لذلك، يبرز سؤال المليون دولار:

هل ستحل إحدى التقنيات محل الأخرى تماماً في الوقت المناسب؟

وباستعارة بعض الأفكار من صناعة الدوائر المتكاملة: يبلغ حجم سوق وحدة المعالجة المركزية 126 مليار دولار، بينما يبلغ حجم صناعة الدوائر المتكاملة بأكملها (بما في ذلك جميع الدوائر المتكاملة “المتخصصة”) 515 مليار دولار. أنا واثق من أن التاريخ سيعيد نفسه هنا، من منظور دقيق، ولن يحل أحدهما محل الآخر.

ومع ذلك، لن يقول أحد اليوم: “مرحبًا، أنا أستخدم جهاز كمبيوتر مدفوع بالكامل بوحدة معالجة مركزية للأغراض العامة”، أو “هذا روبوت فاخر مدفوع بدوائر متكاملة متخصصة”.

نعم، يجب علينا بالفعل أن ننظر إلى هذه المسألة من منظور كلي، وفي المستقبل، سيكون هناك منحنى مفاضلة يسمح للمطورين بالاختيار بمرونة وفقًا لاحتياجاتهم.

في المستقبل، يمكن أن تعمل البنية التحتية ZK المتخصصة و ZKVM العامة معًا. يمكن تحقيق ذلك بأشكال متعددة. أبسط طريقة يمكن تحقيقها بالفعل الآن. على سبيل المثال، يمكنك استخدام معالج ZK coprocessor لتوليد بعض النتائج الحسابية في سجل معاملات سلسلة الكتل، ولكن منطق عمل الحساب على هذه البيانات معقد للغاية ولا يمكن التعبير عنه ببساطة في SDK/API.

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

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