المؤلف: mo المصدر: X، @no89thkey الترجمة: شان أوبا، Golden Finance
دعني أحاول الإجابة على هذا السؤال برقم:
هل من الممكن أن نتقارب فقط إلى نقطة سحرية مثالية في مستوى المقايضة ؟ لا، مستقبل الحوسبة التي يمكن التحقق منها خارج السلسلة هو منحنى مستمر يطمس الخطوط الفاصلة بين ZK المتخصصة وZK للأغراض العامة. اسمحوا لي أن أشرح كيف تطورت هذه المصطلحات تاريخيا وكيف ستندمج في المستقبل.
قبل عامين، كانت البنية التحتية ZK "الاحترافية" تعني أطر عمل الدوائر منخفضة المستوى مثل circom وHalo2 وarkworks. تطبيقات ZK المبنية باستخدام هذه الدوائر هي في الأساس دوائر ZK مكتوبة بخط اليد. فهي سريعة ورخيصة الثمن بالنسبة لمهام محددة للغاية، ولكن غالبًا ما يكون من الصعب تطويرها وصيانتها. وهي تشبه العديد من شرائح الدوائر المتكاملة الخاصة بالتطبيقات (السيليكون المادي) الموجودة في صناعة IC اليوم، مثل رقائق NAND ورقائق التحكم.
على مدى العامين الماضيين،تطورت البنية التحتية ZK "المتخصصة" إلى بنية تحتية "أكثر عمومية".
لدينا الآن ZKML، والمعالج المساعد ZK، وإطار عمل ZKSQL، والتي توفر أدوات تطوير البرامج (SDK) سهلة الاستخدام وقابلة للبرمجة بدرجة كبيرة والتي يمكنها إنشاء فئات مختلفة من تطبيقات ZK دون كتابة سطر واحد من كود دائرة ZK. على سبيل المثال، يسمح المعالج المساعد ZK للعقود الذكية بالوصول إلى حالة/أحداث/معاملات blockchain التاريخية بشكل غير موثوق وإجراء حسابات عشوائية على هذه البيانات. تتيح ZKML للعقود الذكية الاستفادة بشكل موثوق من نتائج استدلال الذكاء الاصطناعي لتنفيذ مجموعة واسعة من نماذج التعلم الآلي.
تعمل هذه الأطر المتطورة على زيادة قابلية البرمجة بشكل كبير ضمن نطاقاتها المستهدفة مع الحفاظ على الأداء العالي والتكلفة المنخفضة بسبب طبقة التجريد (SDK/API) رقيقة جدًا وقريبة من الدوائر المعدنية العارية. إنها تشبه وحدات معالجة الرسومات ووحدات TPU وFPGAs في سوق IC: فهي خبراء في المجال القابل للبرمجة.
حققت ZKVM أيضًا تقدمًا كبيرًا في العامين الماضيين. تجدر الإشارة إلى أن جميع ZKVM للأغراض العامة مبنية على أعلى أطر عمل ZK المتخصصة ذات المستوى المنخفض. الفكرة هي أنه يمكنك كتابة تطبيقات ZK بلغة عالية المستوى (حتى أكثر سهولة في الاستخدام من SDK/API) والتي يمكن تجميعها في مجموعة من الدوائر المتخصصة في مجموعة التعليمات (RISC-V أو WASM-like). . في تشبيهنا بصناعة الدوائر المتكاملة، فهي مثل رقائق وحدة المعالجة المركزية.
ZKVM عبارة عن طبقة تجريد أعلى إطار عمل ZK منخفض المستوى، مثل المعالج المساعد ZK وما إلى ذلك، وإن كانت طبقة أكثر سمكًا.
كما قال رجل حكيم ذات مرة، طبقة واحدة من التجريد تحل كل مشكلة في علوم الكمبيوتر ولكنها تخلق مشكلة أخرى. المقايضة، يا أصدقائي، هي اسم اللعبة هنا. بشكل أساسي، مع ZKVM لدينا مقايضة بين الأداء وتعدد الاستخدامات.
قبل عامين، كان أداء ZKVM "المعدني العاري" سيئًا حقًا. ومع ذلك، في غضون عامين فقط، تحسن أداء ZKVM بشكل ملحوظ. لماذا؟
لأن أجهزة ZKVM "العالمية" هذه أصبحت أكثر "احترافية"! المجال الرئيسي لتحسين الأداء يأتي من "التجميع المسبق". هذه المترجمات المسبقة عبارة عن دوائر ZK متخصصة يمكنها حساب البرامج عالية المستوى شائعة الاستخدام مثل SHA2 والتحقق من التوقيعات المختلفة بشكل أسرع بكثير من العملية العادية لتقسيمها إلى دوائر تعليمات.
لذلك فإن الاتجاه واضح بالفعل.
أصبحت البنية التحتية ZK المتخصصة أكثر عمومية، وأصبحت ZKVM العامة أكثر تخصصًا!
بالنسبة لكلا الحلين في السنوات القليلة الماضية، فإن التحسين هو تحقيق نقطة مقايضة أفضل من ذي قبل: القيام بعمل أفضل في نقطة واحدة دون التضحية بنقطة أخرى . ولهذا السبب يشعر الطرفان بأننا "نحن المستقبل بالتأكيد".
ومع ذلك، فإن حكمة علوم الكمبيوتر تخبرنا بكل ذلك أنه في مرحلة ما، سنواجه "جدار باريتو الأمثل" (الخط الأخضر المنقط)، حيث في هذه الحالة، لا يمكننا تحسين ميزة واحدة دون التضحية بأخرى. لذا فإن سؤال المليون دولار يطرح نفسه: هل يحل أحدهما محل الآخر تماما في الوقت المناسب؟
إذا كان قياس صناعة الدوائر المتكاملة مفيدًا: يبلغ حجم سوق وحدة المعالجة المركزية 126 مليار دولار أمريكي، ويبلغ حجم سوق صناعة الدوائر المتكاملة بأكملها، بالإضافة إلى جميع الدوائر المتكاملة "المتخصصة"، 126 دولارًا أمريكيًا مليار دولار أمريكي. أعتقد، على المستوى الجزئي، أن التاريخ سوف يتناغم هنا ولن يحل محل الآخر.
ومع ذلك، لا أحد يقول اليوم، "مرحبًا، أنا أستخدم جهاز كمبيوتر مدعومًا بالكامل بوحدة معالجة مركزية للأغراض العامة" أو "مرحبًا، انظر إلى هذه الروبوتات الغريبة المدعومة بوحدات متكاملة مخصصة "
نعم، يجب علينا بالفعل أن ننظر إلى هذا من المستوى الكلي. المستقبل هو توفير منحنى مقايضة يسمح للمطورين بالاختيار بمرونة وفقًا لاحتياجاتهم الشخصية.
في المستقبل، يمكن للبنية التحتية ZK لخبراء المجال وZKVM للأغراض العامة العمل معًا. يمكن أن يحدث هذا بأشكال عديدة.
في أيامنا هذه، أصبحت أبسط طريقة ممكنة. على سبيل المثال، يمكنك استخدام المعالج المساعد ZK لإنشاء بعض النتائج الحسابية على مدار التاريخ الطويل لمعاملات blockchain، ولكن منطق الأعمال الحسابي الموجود أعلى تلك البيانات معقد للغاية بحيث لا يمكنك التعبير عنه بسهولة في SDK/API.
ما يمكنك فعله هو الحصول على إثبات ZK عالي الأداء ومنخفض التكلفة للبيانات ونتائج الحساب الوسيطة، ثم توجيهها إلى جهاز افتراضي معمم عبر العودية إثبات.
p> p>
على الرغم من أنني أعتقد أن هذه الأنواع من المناقشات مثيرة للاهتمام، إلا أنني أعلم أننا جميعًا نبني مستقبلًا من الحوسبة غير المتزامنة لسلاسل الكتل المدعومة بحسابات يمكن التحقق منها خارج السلسلة. عندما نرى حالات استخدام لتبني المستخدمين على نطاق واسع في السنوات القليلة المقبلة، أعتقد أنه يمكن حل هذا النقاش بسهولة. ص>