ما هو zkAPI؟ كيف تستخدم إيثريوم إثباتات المعرفة الصفرية لمدفوعات الذكاء الاصطناعي الخاصة

zkAPI هو حل تكنولوجي للخصوصية يستخدم إثباتات المعرفة الصفرية (Zero-Knowledge Proof, ZKP) للتحكم في الوصول إلى واجهات برمجة التطبيقات (API) والتحقق من المدفوعات. يهدف إلى تقليل التعرض المباشر لهويات المستخدمين وحساباتهم وسجلات المدفوعات عند وصولهم إلى الخدمات عبر الإنترنت مثل نماذج الذكاء الاصطناعي. على عكس نماذج الوصول التقليدية التي تعتمد على الحسابات الموثقة، ومفاتيح API، وأنظمة الفوترة المركزية، يسعى zkAPI إلى السماح للمستخدمين بإثبات حقوق الوصول أو بيانات الدفع بشكل مشفر دون الكشف عن هويتهم الكاملة لمزود الخدمة.

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

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

النقاط الرئيسية

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

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

• تسمح إثباتات المعرفة الصفرية للمستخدمين بإثبات أنهم مؤهلون للوصول إلى خدمة أو لديهم قدرة دفع كافية دون الكشف عن جميع المعلومات الأساسية المستخدمة للتحقق.

• يمكن أن توفر Ethereum وشبكات Layer 2 الخاصة بها بنية تحتية للتحقق من المدفوعات، والعقود الذكية، وبيانات الاعتماد للحلول ذات الصلة. ومع ذلك، لا يعني ذلك أن طلبات استدلال الذكاء الاصطناعي أو جميع معلومات المعاملات تتلقى تلقائيًا حماية الخصوصية.

• لا تزال تطبيقات zkAPI في العالم الحقيقي بحاجة إلى معالجة قضايا مثل إعادة استخدام بيانات الاعتماد، وإدارة الحصص، وإساءة استخدام الطلبات، وتكاليف توليد الإثبات، والفوترة من جانب الخادم.

ما هو zkAPI؟ ولماذا قدمت Ethereum حلاً للمدفوعات المجهولة للذكاء الاصطناعي؟

zkAPI هو بروتوكول دفع API يركز على الخصوصية تم تطويره بشكل مشترك من قبل مشروع Open Anonymity ومؤسسة Ethereum. تم تصميمه للسماح للمستخدمين بالدفع مقابل نماذج الذكاء الاصطناعي وغيرها من الخدمات المدفوعة عند الاستخدام من خلال إثباتات المعرفة الصفرية دون ربط كل طلب API بهويتهم الحقيقية أو عنوان التمويل على السلسلة. في 1 أكتوبر 2026، أعلنت مؤسسة Ethereum أن zkAPI قد أطلق على الشبكة الرئيسية لـ Ethereum ونشرت تطبيقات للعميل، والخادم، والعقد الذكي. نشأ المشروع من تصميم اعتمادات استخدام ZK API الذي اقترحه سابقًا فيتاليك بوتيرين ودافيد كراپيس، رئيس فريق dAI في مؤسسة Ethereum.

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

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

لذلك، الهدف الأساسي من zkAPI هو جعل هويات الدفع غير مرتبطة بسجلات استخدام واجهات برمجة التطبيقات، بدلاً من تشفير أو إخفاء جميع طلبات الذكاء الاصطناعي تلقائيًا. هذه التفرقة أساسية لفهم القيمة التقنية للبروتوكول.

كيف تمكّن إثباتات المعرفة الصفرية المدفوعات الخاصة لواجهات برمجة التطبيقات للذكاء الاصطناعي؟

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

في zkAPI، بعد أن يقوم المستخدمون بإيداع ETH أو أصول مدعومة أخرى في عقد Vault الذكي على Ethereum، يمثل النظام الرصيد المتاح من خلال ملاحظة خاصة. يمكن فهم الملاحظة على أنها بيانات اعتماد دفع رقمية يتحكم فيها المعلومات السرية للمستخدم. يستخدم البروتوكول التزامات تشفيرية لتسجيل بيانات الاعتماد الصالحة وينظم هذه الالتزامات باستخدام شجرة ميركل. وهذا يسمح للمستخدمين بإثبات أن بيانات اعتمادهم تنتمي إلى مجموعة صالحة دون الكشف عن أي بيانات اعتماد محددة يحملونها.

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

لمنع استخدام نفس الرصيد بشكل متكرر، يقدم zkAPI آلية Nullifier. الـ Nullifier هو معرف فريد يتم إنشاؤه من المعلومات السرية ويستخدم لاكتشاف ما إذا تم استخدام نفس الائتمان القابل للصرف أكثر من مرة. إذا اكتشف النظام Nullifier مكررًا، يمكنه تحديد سلوك الإنفاق المزدوج المحتمل دون الكشف عن هوية المستخدم الكاملة أو سجلات التمويل. تستخدم التنفيذ الرسمي مكونات تقنية تشمل إثباتات المعرفة الصفرية Groth16، ومنحنى BN254، وتجزئة بوسيدون، وأشجار ميركل.

كيف يتعامل zkAPI مع المدفوعات من التمويل على Ethereum إلى استدعاءات نماذج الذكاء الاصطناعي؟

يمكن تقسيم عملية zkAPI إلى خمس مراحل: التمويل، إثبات الدفع، التفويض المؤقت، استدعاء النموذج، والفوترة النهائية. على عكس الأنظمة التي تبدأ معاملة على السلسلة لكل طلب API، يسمح zkAPI للمستخدمين بإيداع الأموال على Ethereum مسبقًا ثم إكمال عدة تفويضات للوصول إلى واجهات برمجة التطبيقات من خلال إثباتات خارج السلسلة، مما يتجنب الحاجة إلى الانتظار لتأكيد blockchain في كل مرة يتم فيها استدعاء نموذج.

أولاً، يقوم المستخدم بتمويل عقد Vault على Ethereum ويتلقى رصيدًا متاحًا يتم تمثيله من خلال ملاحظة خاصة. عندما يحتاج المستخدم إلى استدعاء نموذج ذكاء اصطناعي، يقوم العميل المحلي بتوليد إثبات دفع ويرسله إلى خادم zkAPI. بعد التحقق من صحة الإثبات، يقوم الخادم بإنشاء مفتاح API مؤقت للجلسة الحالية مع فترة انتهاء محددة وحدود إنفاق. يمكن للمستخدم استخدام هذا المفتاح للوصول إلى خدمات الذكاء الاصطناعي المدعومة دون استخدام مفتاح API مرتبط بشكل دائم بحساب الدفع الشخصي الخاص به.

في نموذج Runtime-Key الموصوف في المواد الرسمية، يتم إرسال مطالبة المستخدم مباشرة إلى مزود خدمة نموذج الذكاء الاصطناعي بدلاً من أن يتم تمريرها عبر خادم الدفع zkAPI. يتحقق خادم الدفع من أهلية الدفع ويتعامل مع الفوترة، بينما يتعامل مزود الخدمة الذكاء الاصطناعي مع استدلال النموذج. بعد انتهاء الجلسة، يقوم النظام بحساب الرسوم الفعلية بناءً على سجلات الاستخدام الموقعة ويخصم المبلغ المقابل من رصيد المستخدم الخاص. حد الإنفاق على المفتاح المؤقت هو مبلغ محجوز ولا يعني أن المستخدم سيتعين عليه بالضرورة دفع المبلغ المحجوز بالكامل.

يوفر zkAPI أيضًا وضع Proxy بسيط نسبيًا، حيث يقوم خادم وكيل بتمرير الطلبات. قد يكون هذا النهج أسهل في التكامل، ولكن يمكن أن يصل خادم الوكيل إلى حركة مرور الطلبات، مما يؤدي إلى حدود خصوصية مختلفة عن نموذج Runtime-Key. لذلك، عند تحليل قدرات خصوصية zkAPI، من الضروري التمييز بين أوضاع التشغيل المحددة بدلاً من اعتبار جميع طرق النشر لها نفس مستوى عزل البيانات.

ما هي الأدوار التي تلعبها Vault، والملاحظة الخاصة، وNullifier؟

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

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

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

من المهم ملاحظة أن التمويل والسحب من Vault تظل معاملات عامة على Ethereum. يخفي zkAPI بشكل أساسي العلاقة بين معاملات التمويل المحددة واستخدام واجهات برمجة التطبيقات اللاحق، بدلاً من جعل عناوين التمويل، أو مبالغ المعاملات، أو جميع الأنشطة على السلسلة غير مرئية تمامًا.

كيف يختلف zkAPI عن طرق الدفع التقليدية لواجهات برمجة التطبيقات للذكاء الاصطناعي؟

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

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

لذلك، لا يُقصد من zkAPI استبدال مفاتيح API التقليدية تمامًا. بدلاً من ذلك، يستخدم التفويض المؤقت وبيانات اعتماد الدفع الخاصة لتغيير العلاقة بين مفاتيح API وهويات الدفع طويلة الأجل. بالنسبة للتطبيقات التي تحتاج فقط إلى إدارة الفوترة والوصول القياسية، قد يظل النموذج التقليدي أبسط. بالنسبة للمستخدمين أو التطبيقات التي ترغب في تقليل تعرض هويات الدفع، يوفر zkAPI خيارًا تقنيًا آخر.

هل يمكن أن يمكّن zkAPI حقًا محادثات ذكاء اصطناعي مجهولة تمامًا؟

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

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

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

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

لماذا يعتبر zkAPI مناسبًا لوكلاء الذكاء الاصطناعي والمدفوعات من آلة إلى آلة؟

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

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

بالإضافة إلى استدلال نماذج الذكاء الاصطناعي، أدرجت مؤسسة Ethereum استعلامات RPC على blockchain، وتوليد الصور والفيديو، وخدمات عرض النطاق الترددي لشبكة VPN، وغيرها من الفوترة من آلة إلى آلة كحالات استخدام محتملة. تشترك هذه الخدمات في خصائص شائعة: يتم عادةً فوترة كل منها حسب الطلب، أو مهمة الحوسبة، أو الوقت، أو حجم الحركة، وبالتالي يمكنها استخدام آليات تفويض الائتمان وتسوية سجلات الاستخدام المماثلة.

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

ما هي القيود التقنية ومخاطر الأمان التي يواجهها zkAPI؟

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

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

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

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

ماذا يعني zkAPI لـ Ethereum وبنية الدفع للذكاء الاصطناعي؟

يعكس إطلاق zkAPI كيف أن استكشاف Ethereum لتطبيقات الذكاء الاصطناعي يتوسع من مدفوعات الأصول إلى تفويض الخصوصية وفوترة الخدمات. تركز المدفوعات التقليدية على blockchain عمومًا على القدرة على نقل الأصول بين عناوين مختلفة. يتجاوز zkAPI ذلك من خلال فحص كيفية إتمام المدفوعات مع تقليل الرابط بين هويات الدفع والاستخدام الفعلي للخدمة. وهذا يعني أن العقود الذكية لـ Ethereum يمكن أن تعمل ليس فقط كالبنية التحتية لنقل المدفوعات ولكن أيضًا كجزء من التحكم في الوصول وإدارة الأموال للخدمات الرقمية.

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

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

الخاتمة

zkAPI هو بروتوكول دفع API يركز على الخصوصية تم إطلاقه من خلال تعاون بين مؤسسة Ethereum ومشروع Open Anonymity. من خلال عقود Vault الذكية، والملاحظات الخاصة، وإثباتات المعرفة الصفرية، ومفاتيح API المؤقتة، يفصل بين هويات الدفع للمستخدمين وسجلات استخدام خدمات الذكاء الاصطناعي الخاصة بهم. يمكن للمستخدمين إيداع الأموال على Ethereum مسبقًا ثم الحصول على وصول إلى واجهات برمجة التطبيقات من خلال إثباتات تشفيرية دون الكشف عن مصدر التمويل المقابل لكل طلب.

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

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

الأسئلة الشائعة

1. ما هو zkAPI؟

zkAPI هو بروتوكول دفع API يركز على الخصوصية يعتمد على إثباتات المعرفة الصفرية. يسمح للمستخدمين بإثبات أن لديهم رصيد خدمة كافٍ من خلال بيانات اعتماد الدفع الخاصة دون الكشف عن مصدر التمويل المحدد أو هوية الدفع طويلة الأجل لخادم الدفع.

2. هل تم إطلاق zkAPI رسميًا من قبل Ethereum؟

تم تطوير zkAPI بشكل مشترك من قبل مشروع Open Anonymity ومؤسسة Ethereum وتم الإعلان عنه كحي على الشبكة الرئيسية لـ Ethereum في 1 أكتوبر 2026. إنه تنفيذ تقني تجريبي تم تطويره من خلال التعاون وليس بروتوكول طبقة أساسية إلزامي لشبكة Ethereum.

3. هل يمكن استخدام zkAPI للدفع باستخدام ETH أو USDC؟

تشير المواد الرسمية لمؤسسة Ethereum إلى أن أصولًا مثل ETH وUSDC يمكن استخدامها في سيناريوهات التمويل والدفع ذات الصلة. ومع ذلك، يجب تحديد الأصول المحددة المدعومة من قبل العميل، وعقد Vault، وإصدار النشر بناءً على الوثائق الأخيرة للتنفيذ ذي الصلة.

4. هل يمكن لـ zkAPI إخفاء المطالبات التي يقدمها المستخدمون إلى الذكاء الاصطناعي؟

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

5. لماذا يحتاج zkAPI إلى Nullifiers؟

تستخدم Nullifiers لاكتشاف ما إذا كانت بيانات اعتماد الرصيد الخاصة قد تم إنفاقها أكثر من مرة. يمكن للنظام منع إعادة استخدام نفس الائتمان من خلال التحقق من المعرفات الفريدة مع تجنب الكشف المباشر عن المعلومات السرية الكاملة للبيانات الاعتماد.

6. هل zkAPI مناسب للمدفوعات الآلية من قبل وكلاء الذكاء الاصطناعي؟

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