مسار ZK يستقبل نقطة تحول: فك الارتباط بين تطوير التجميع وقوة الحوسبة الخلفية

كتابة: هاوتيان

اعتماد ZK الحقيقي على نطاق واسع كان دائمًا مقيدًا بجبلين عظيمين: صعوبة البرمجة وارتفاع تكلفة الحوسبة. لكن مؤخرًا، هناك اثنين من “وظائف الخطوة” (Step functions) على وشك التنفيذ في المسار، والتي من المتوقع أن تحسن هذه المشكلة:

واحد هو OpenVM V2 الذي ستطلقه @openvm_org قريبًا، والذي يسمح للمطورين بكتابة الأعمال باستخدام لغات عامة مألوفة، وسيقوم المحرك الأساسي تلقائيًا بـ “ترجمتها” بشكل موثوق إلى إثبات ZK؛

والآخر هو ميزة الترجمة التلقائية للإنتاج (Auto-precompiles) التي تقدمها @powdr_labs، حيث يمكن للمترجم التعرف تلقائيًا على العمليات التشفيرية التي تستغرق وقتًا طويلاً، وتوجيهها مباشرة إلى الأجهزة المثلى لمعالجتها، مما يلغي الحاجة إلى المطورين للغوص يدويًا في تحسينات المستوى الأدنى.

هذه الاختراقات بمثابة تزويد المطورين بـ “مترجم بسيط الاستخدام” و"مساعد تسريع تلقائي".

لكن لماذا تعتبر هذه التطورات مفيدة جدًا لمسار ZK؟

دعونا نُجري استنتاجًا منطقيًا تجاريًا لنوضح الأمر: عندما تقترب حواجز الدخول من الصفر، وتزدهر تطبيقات ZK، فإن ذلك سيؤدي حتمًا إلى زيادة هائلة في طلبات حساب الإثبات (Proving). ومع ذلك، فإن سوق إثبات ZK الحالي قد بدأ بالفعل في تلبية جزء من هذا الطلب، لكن الطلب على تطبيقات ZK لا يزال غير كافٍ…

وهذا هو السبب في أن السوق المفتوحة لإثباتات مثل @boundless_xyz تتطلع إلى هذه التقدمات التكنولوجية، لأنها بدون طلبات تطبيقات ZK واسعة النطاق، من أين ستأتي الحاجة إلى حسابات إثبات هائلة؟ وكيف يمكن إثبات تفوق تقنية ZK الخاصة بها وقيمتها التجارية في ظل غموض التكنولوجيا الحالي؟

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

التقدم المتزامن لكلا الجانبين هو الذي سيدفع حقًا إلى انفجار مسار ZK.