المؤلف: كيرنل فينتشرز تيربو قوو

المحررون: كيرنل فينتشرز روز، كيرنل فينتشرز ماندي، كيرنل فينتشرز يوشوا

TLDR: المعالج الزكي هو حل لتطبيقات اللامركزية لاستخدام موارد الحوسبة خارج السلسلة. تستكشف هذه المقالة الحلول الحالية، وتطبيقات متنوعة، وتطوير المستقبل للمعالجات الزكية. المواضيع الرئيسية المغطاة كالتالي:

1. RISC Zero's zkVM هو حل معالج زكي يسمح للعقود على السلسلة التي تستدعي zkVM خارج السلسلة بتشغيل كود Rust محدد وإرجاع النتائج إلى السلسلة، مع توفير zkp للتحقق من صحة الحساب على السلسلة.

2. توجد حلول مختلفة لـ ZK coprocessors. بالإضافة إلى zkVM، يمكن للمستخدمين أيضًا كتابة دوائر ZK مخصصة لبرامجهم، أو استخدام أطر جاهزة لكتابة الدوائر، بحيث تتمكن العقود من الاستفادة من موارد الحوسبة خارج السلسلة.

3. يمكن لـ ZK coprocessor أن يلعب دورًا في DeFi، مثل تفريغ حسابات AMM خارج السلسلة لالتقاط قيمة مشابهة لـ MEV أو تمكين منطق معقد وكثيف حسابيًا لـ AMMs. كما يمكن لـ ZK coprocessor تسهيل حساب معدلات الفائدة في الوقت الحقيقي لبروتوكولات الإقراض، مما يجعل حسابات الهامش شفافة، من بين أشياء أخرى. لدى zkAMM مساران للتنفيذ: أحدهما يستخدم zkVM، والآخر يستخدم zkOracle.

4. لـ ZK coprocessor أيضًا حالات استخدام محتملة أخرى، مثل المحافظ التي تستخدمه لإجراء تحقق من الهوية خارج السلسلة. ويمكن أن يمكّن حسابات أكثر تعقيدًا للألعاب على السلسلة، ويقلل الغاز المطلوب لحوكمة DAO، وغيرها من التطبيقات.

5. لا يزال مشهد coprocessors الخاصة بـ ZK غير مؤكد، لكن بالمقارنة مع قيام المستخدمين بكتابة دوائرهم بأنفسهم، فإن استخدام حل لتوصيل موارد خارج السلسلة يكون أكثر ملاءمة للمستخدم. ومع ذلك، يبقى سؤال أي مزوّدي خدمات الحوسبة يتم دمجهم خلف حل "الواجهة" هذا، سواء كانوا مزودي سحابة تقليدية أو شبكات مشاركة موارد لا مركزية، موضوعًا مهمًا للنقاش.

1. الغرض والتطبيق من coprocessors الخاصة بـ ZK

المصدر: Kernel Ventures

اللب/جوهر coprocessor الخاص بـ ZK هو نقل الحوسبة على السلسلة إلى خارج السلسلة، باستخدام إثباتات ZK لضمان موثوقية الحوسبة خارج السلسلة، ما يسمح للعقود الذكية بالتعامل بسهولة مع كمية كبيرة من الحوسبة مع التحقق من موثوقية الحوسبة. هذا يشبه فكرة zkRollups، لكن Rollups تستخدم موارد حوسبة خارج السلسلة على مستوى بروتوكول السلسلة، بينما تُستخدم coprocessors الخاصة بـ ZK بواسطة dApps للاستفادة من موارد خارج السلسلة.

باستخدام RISC Zero كمثال لشرح أحد حلول coprocessors الخاصة بـ ZK، قامت RISC Zero بتطوير بنية coprocessor Bonsai ZK، ويُعد جوهرها zkVM الخاص بـ RISC Zero. يمكن للمطورين توليد zkp على zkVM لـ "تنفيذ كود Rust معيّن بشكل صحيح". ومع zkVM، تكون الخطوات التفصيلية لتنفيذ coprocessor ZK كالتالي:

1. يرسل المطورون طلبًا إلى عقد ترحيل Bonsai، أي لتشغيل البرنامج المطلوب من المطور داخل zkVM.

2. يقوم عقد الترحيل بإرسال الطلب إلى تجمع طلبات خارج السلسلة (off-chain request pool).

3. ينفّذ Bonsai الطلب داخل zkVM خارج السلسلة، ويُجري حسابات على نطاق واسع، ثم يُولّد إيصالًا (receipt).

4. تُنشر هذه الإثباتات، والمعروفة أيضًا باسم "الإيصالات" (receipts)، مرة أخرى إلى السلسلة بواسطة Bonsai عبر عقد الترحيل.

المصدر: RISC Zero

في Bonsai، يُطلق على البرنامج الذي تم إثباته اسم برنامج الضيف (Guest Program)، ويُستخدم الـ receipt لإثبات أن برنامج الضيف تم تنفيذه بشكل صحيح. يتضمن الـ receipt مجلة (journal) وختمًا (seal). تحديدًا، تحمل المجلة المخرجات العامة لتطبيق zkVM، بينما يُستخدم الختم لإثبات صحة الـ receipt، أي لإثبات أن برنامج الضيف تم تنفيذه بشكل صحيح. الختم نفسه هو zkSTARK يتم توليده بواسطة المُثبت (prover). يضمن التحقق من الـ receipt أن الـ journal تم بناؤه باستخدام الدائرة الصحيحة، وما إلى ذلك.

يُبسّط Bonsai عملية قيام المطورين بتجميع كود Rust إلى بايتكود zkVM، ورفع البرامج، وتنفيذها داخل الـ VM، واستلام ملاحظات الإثبات، مما يسمح للمطورين بالتركيز أكثر على التصميم المنطقي. يتيح تشغيل منطق العقود بالكامل خارج السلسلة، وليس فقط منطقًا جزئيًا للعقد. كما تستخدم RISC Zero continuations، حيث يتم تقسيم توليد إثبات كبير إلى أجزاء أصغر، ما يمكّن من توليد الإثبات للبرامج الكبيرة دون استهلاك ذاكرة مفرطة. بالإضافة إلى RISC Zero، توجد مشاريع أخرى مثل IronMill و=nil وFoundation وMarlin تقدم حلولًا عامة مشابهة.

2. تطبيق coprocessors الخاصة بـ ZK في DeFi

2.1 AMM - Bonsai كمساعد/‏Coprocessor

zkUniswap هو AMM يستفيد من موارد الحوسبة خارج السلسلة. تتمثل ميزته الأساسية في تفريغ جزء من حسابات المبادلة خارج السلسلة باستخدام Bonsai. يبدأ المستخدم طلب مبادلة على السلسلة. يحصل عقد ترحيل Bonsai على الطلب، ويبدأ الحوسبة خارج السلسلة، وبعد اكتمالها يعيد نتيجة الحوسبة والإثبات إلى دالة رد النداء (callback) الخاصة بـ EVM. إذا تم التحقق من الإثبات بنجاح، تُنفَّذ المبادلة.

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

لمعالجة هذه المشكلة، صمم المطورون قفلًا للتجمع/الـ pool lock. عندما يبدأ المستخدم طلبًا، يتم قفل جميع العمليات الأخرى مؤقتًا باستثناء تسوية المبادلة (swap)، حتى ينجز الحوسبة خارج السلسلة بنجاح التشغيل المبادلة على السلسلة، أو حتى تنتهي المبادلة (تنتهي مهلة المبادلة؛ سيتم ضبط حد زمني مسبقًا). ومع وجود حد زمني، حتى لو ظهرت مشاكل في عقد الترحيل أو في zkp، فلن يبقى التجمع مقفلًا إلى أجل غير مسمى. قد يكون الحد الزمني المحدد بضع دقائق.

لدى zkUniswap تصميم فريد لالتقاط MEV، إذ يهدف المطورون إلى أن يستفيد البروتوكول من MEV. من الناحية النظرية، لدى zkAMMs أيضًا MEV، لأن الشخص الأول الذي يقدم طلب مبادلة يمكنه قفله والتقدم به (front-run) على الآخرين، ما يؤدي إلى حروب غاز (gas wars)، ويمكن للبنّائين (builders) ما زالوا تحديد أولوية ترتيب المعاملات. ومع ذلك، يأخذ zkUniswap أرباح MEV لنفسه باستخدام أسلوب يُعرف بـ Variable Rate Gradual Dutch Auction (VRGDA). تتيح هذه المقاربة لـ zkUniswap استخراج قيمة MEV من أجل البروتوكول.

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

2.2 AMM - zkOracle كمساعد/‏Coprocessor

بالإضافة إلى استخدام zkVM، اقترح البعض استخدام zkOracle للاستفادة من موارد الحوسبة خارج السلسلة. وتجدر الإشارة إلى أن zkOracle عبارة عن oracle للمدخلات/المخرجات (I/O) (أي يتعامل مع المدخلات والمخرجات). عمومًا، يوجد نوعان من الـ oracles: أحدهما oracle للمدخلات، والآخر oracle للمخرجات. يقوم oracle للمدخلات بمعالجة/حساب البيانات خارج السلسلة ونشرها على السلسلة، بينما يقوم oracle للمخرجات بمعالجة/حساب البيانات على السلسلة وتوفيرها خارج السلسلة. تقوم الـ I/O oracle (zkOracle) أولًا بتنفيذ المخرجات ثم المدخلات، ما يسمح للسلسلة بالاستفادة من موارد الحوسبة خارج السلسلة.

من جهة، يستخدم zkOracle بيانات على السلسلة كمصدر بيانات، ومن جهة أخرى، يستخدم ZK لضمان أن حسابات عقد/عُقد الـ oracle تكون صادقة، وبالتالي يحقق وظيفة coprocessor. لذلك يمكن وضع الحساب الأساسي لـ AMM داخل zkOracle، مما يسمح بالحفاظ على وظائف AMM التقليدية، وفي الوقت نفسه تمكين عمليات أكثر تعقيدًا وكثافةً حسابيًا باستخدام zkOracle.

المصدر: github fewwwww/zkAMM

2.3 حساب معدل الإقراض، حساب الهامش، وتطبيقات أخرى

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

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

3. تطبيقات أخرى لـ ZK coprocessors

3.1 Wallet - استخدام Bonsai كمساعد/‏Coprocessor

يستخدم Bonfire Wallet zkVM لتفريغ حساب التحقق من الهوية خارج السلسلة. الهدف من هذا المحفظة هو تمكين المستخدمين من إنشاء محافظ احتراق (burner wallets) باستخدام معلومات بيومترية (بصمات) أو عبر yubikey مُشفّر على العتاد. تحديدًا، يستخدم Bonfire Wallet WebAuthn، وهو معيار شائع لمصادقة الويب، لتمكين المستخدمين من إكمال التحقق من الهوية عبر الويب مباشرةً باستخدام الأجهزة دون كلمة مرور. لذلك في Bonfire Wallet، ينشئ المستخدمون مفتاحًا عامًا باستخدام WebAuthn (ليس على السلسلة، بل من أجل WebAuthn)، ثم يستخدمونه لإنشاء محفظة. تحتوي كل محفظة Burner على عقد على السلسلة يتضمن المفتاح العام لـ WebAuthn. يحتاج العقد إلى التحقق من توقيع WebAuthn الخاص بالمستخدم. لكن هذا الحساب كبير، لذلك يتم استخدام Bonsai لتفريغ هذه الحوسبة خارج السلسلة عبر برنامج ضيف (zkVM guest program) للتحقق من التوقيع خارج السلسلة، وإنتاج zkp للتحقق على السلسلة.

المصدر: Bonfire Wallet

3.2 استرجاع بيانات على السلسلة - دوائر ZK مكتوبة بواسطة المستخدمين

Axiom هو تطبيق لا يستخدم zkVM بل يستخدم حل coprocessor مختلف. لنقدّم أولًا ما الذي تهدف إليه Axiom. فهي تستفيد من coprocessors الخاصة بـ ZK لتمكين العقود من الوصول إلى معلومات على السلسلة بشكل تاريخي. في الواقع، فإن تمكين العقود من قراءة البيانات التاريخية أمر صعب للغاية، لأن العقود الذكية عادةً ما تحصل على بيانات آنية على السلسلة، وهو ما قد يكون مكلفًا للغاية. من الصعب على العقود الوصول إلى بيانات قيمة على السلسلة مثل الأرصدة التاريخية للحسابات أو سجلات المعاملات.

المصدر: Axiom demo

تصل عقد Axiom إلى بيانات السلسلة المطلوبة وتُجري الحساب المحدد خارج السلسلة، ثم تُولّد إثبات معرفة صفر (zero-knowledge proof) للحساب، لإثبات أن النتيجة تم حسابها بشكل صحيح بناءً على بيانات سلسلة صالحة. يتم التحقق من هذا الإثبات على السلسلة، ما يضمن أن العقد يمكنه الوثوق بهذه النتيجة.

لإنشاء zkp للحوسبة خارج السلسلة، يلزم تجميع البرامج في دوائر ZK (ZK circuits). في السابق ذكرنا أيضًا استخدام zkVM لهذا الغرض، لكن Axiom اقترح أن هناك العديد من الحلول، وأنه من الضروري الموازنة بين الأداء والمرونة وتجربة التطوير:

1. دوائر مُخصّصة: إذا قام المطورون بتخصيص الدوائر لبرامجهم، فستكون أفضل من حيث الأداء بالتأكيد، لكن ذلك يتطلب وقتًا للتطوير؛

2. eDSL/DSL: يواصل المطورون كتابة دوائرهم، لكن توجد بعض الأطر الاختيارية لمساعدة المطورين في حل مشكلات مرتبطة بـ zk، وبالتالي تحقيق توازن بين الأداء وتجربة التطوير.

3. zkVM: يقوم المطورون بتشغيل ZK مباشرةً على آلة افتراضية موجودة، وهذا مريح جدًا، لكن Axiom يعتقد أنه غير كفء.

لذلك اختارت Axiom الخيار الثاني، وتوفر للمستخدمين مجموعة من وحدات ZK مُحسّنة، ما يتيح لهم تصميم دوائرهم الخاصة.

تشمل المشاريع المشابهة لـ Axiom Herodotus، التي تهدف إلى العمل كـ middleware للرسائل عبر السلاسل. وبما أن معالجة المعلومات تتم خارج السلسلة، فمن المعقول السماح لسلاسل مختلفة بالحصول على البيانات المُعالجة. مشروع آخر، Space and Time، يستخدم بنية مماثلة لتنفيذ فهرسة البيانات.

3.3 ألعاب على السلسلة، حوكمة DAO، وتطبيقات أخرى

بالإضافة إلى ما سبق، يمكن أيضًا لألعاب على السلسلة وحوكمة DAO استخدام coprocessors الخاصة بـ ZK. يعتقد RISC Zero أن أي حساب يحتاج أكثر من 250k غاز سيكون أرخص باستخدام coprocessor الخاص بـ ZK، لكن كيفية حساب ذلك ما زالت بحاجة لمزيد من التحقيق. يمكن أيضًا لحوكمة DAO استخدام coprocessors الخاصة بـ ZK، لأنها تشمل عدة أشخاص وعدة عقود، ما يجعلها كثيفة من الناحية الحسابية للغاية. يدّعي RISC Zero أن استخدام Bonsai يمكن أن يقلل رسوم الغاز بنسبة 50%. تستخدم العديد من مشاريع ZKML، مثل Modulus Labs وGiza، نفس الحل بوصفها coprocessors الخاصة بـ ZK، لكن مفهوم coprocessors الخاصة بـ ZK أوسع نطاقًا.

يجدر الذكر أن هناك بعض المشاريع المساعدة في مجال coprocessors الخاصة بـ ZK، مثل ezkl، التي توفر مُجمّعات للدوائر الخاصة بـ ZK، وواجهات/أدوات (toolkits) لنشر ZK، وأدوات لتفريغ الحوسبة على السلسلة خارج السلسلة.

4. التوقعات المستقبلية

توفر الـ Coprocessors تطبيقات على السلسلة مع موارد حوسبة خارجية شبيهة بـ "السحابة"، ما يوفر حوسبة وفيرة وبتكلفة فعالة، بينما تركز المعالجة على السلسلة على الحسابات الأساسية. في الواقع، يمكن أيضًا تشغيل zkVM على السحابة. وبشكل أساسي، فإن coprocessors الخاصة بـ ZK هي نهج معماري ينقل الحوسبة على السلسلة إلى خارج السلسلة، مع مصدر غير محدود من الموارد الحاسوبية خارج السلسلة.

بشكل أساسي، يمكن توفير موارد الحوسبة خارج السلسلة بواسطة مزوّدي الخدمات السحابية التقليدية، وكذلك من خلال مشاركة موارد حوسبة لا مركزية، وأيضًا عبر الأجهزة المحلية. تتسم كل واحدة من هذه الاتجاهات بخصائصها. يمكن لمزوّدي السحابة التقليديين تقديم حلول ناضجة نسبيًا للحوسبة خارج السلسلة، وقد تكون "متانة" موارد الحوسبة اللامركزية المستقبلية أقوى، وللحوسبة المحلية أيضًا الكثير من الإمكانات. لكن حاليًا، لا تزال العديد من مشاريع المساعدات/الـ coprocessor الخاصة بـ ZK في مرحلة خدمة مغلقة المصدر، لأن منظومة هذه الخدمات لم تتشكل بالكامل بعد، كما أن التخصص بين الخدمات في مختلف المشاريع لم يُحدَّد بعد. سيناريوهان محتملان للمستقبل هما:

1. كل جزء من coprocessor الخاص بـ ZK لديه عدد كبير من المشاريع التي تتنافس مع بعضها البعض.

2. قد يهيمن مشروع واحد لديه تجربة خدمة ممتازة على السوق.

من منظور المطور، عند استخدام coprocessors الخاصة بـ ZK، قد يتفاعلون فقط مع مشروع "واجهة" واحدة. وهذا مشابه للسبب الذي يجعل Amazon Web Services تمتلك حصة سوقية كبيرة، لأن المطورين يميلون إلى التعود على طريقة نشر محددة. ومع ذلك، فإن سؤال أي مزوّدي خدمات الحوسبة (شركات سحابية تقليدية أو مشاركة موارد لا مركزية) يتم دمجهم خلف مشروع واجهة موارد الحوسبة خارج السلسلة هذا، هو موضوع آخر يستحق النقاش.

Kernel Ventures هي مؤسسة بحث وتطوير & مجتمع مجتمع مدفوع باستثمارات VC في عالم الكريبتو، مع أكثر من 70 استثمارًا في مراحل مبكرة، تركز على البنية التحتية والـ middleware وdApps، خاصة ZK وRollup وDEX وBlockchain Modular والقطاعات التي ستجلب المليار التالي من المستخدمين في الكريبتو مثل Account Abstraction وData Availability وScalability وما إلى ذلك. خلال السنوات السبع الماضية، التزمنا بدعم نمو مجتمعات المطورين الأساسية وجمعيات University Blockchain Associations في مختلف أنحاء العالم.

المرجع:

1. دليل coprocessors الخاصة بـ ZK للتوسع: https://www.risczero.com/news/a-guide-to-zk-coprocessors-for-scalability

2. تعريف zkOracle لـ Ethereum: https://ethresear.ch/t/defining-zkoracle-for-ethereum/15131

3. zkUniswap: zkAMM من نوعه الأول: https://ethresear.ch/t/zkuniswap-a-first-of-its-kind-zkamm/16839

4. ما هو ZK Coprocessor؟: https://blog.axiom.xyz/what-is-a-zk-coprocessor/

5. نبذة مختصرة عن Coprocessors: https://crypto.mirror.xyz/BFqUfBNVZrqYau3Vz9WJ-BACw5FT3W30iUX3mPlKxtA

6. آخر التطبيقات المبنية على Hyper Oracle (Bonus: أشياء يمكنك بناءها الآن): https://mirror.xyz/hyperoracleblog.eth/Tik3nBI9mw05Ql_aHKZqm4hNxfxaEQdDAKn7JKcx0xQ

7. Bonfire Wallet: https://ethglobal.com/showcase/bonfire-wallet-n1dzp