zkAPI على إيثريوم يخفي هوية من يدفع مقابل الذكاء الاصطناعي.. لكن النموذج لا يزال يرى المطالبة

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

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

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

وهذا مهم لأن عبارة “مدفوعات ذكاء اصطناعي خاصة” قد يفهمها البعض على أنها تعني استخدامًا خاصًا أو مجهولًا للذكاء الاصطناعي.

وبحسب المؤسسة، أصبحت الخدمة متاحة بالفعل، مع مستودع عام على GitHub، وخزنة على الشبكة الرئيسية تحتوي على أرصدة USDC، وواجهة دردشة تجريبية مرتبطة بالإعلان.

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

إيداع واحد يمكن أن يحل محل سلسلة من فواتير واجهات برمجة التطبيقات

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

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

يتحقق خادم الدفع من الإثبات ثم يصدر مفتاح API قصير الأجل ومحدد القيمة بالدولار.

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

ويمكن لإثبات واحد تغطية جلسة تضم عدة طلبات.

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

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

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

وضع الوكيل يوفر مسارًا مختلفًا

هناك أيضًا وضع أبسط يعمل كوكيل وسيط.

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

وبالتالي، عند الاختيار بين الوضعين، ينبغي للمستخدم أن يسأل: أي طرف أثق به للاطلاع على المحتوى، وأي طرف يحتاج فقط إلى التحقق من إثبات الدفع؟

وقد تبدو الواجهة المحلية متطابقة في الحالتين، لكن طريقة توجيه الطلبات قد تختلف خلف الكواليس.

الملاحظة تثبت وجود القيمة دون الكشف عن صاحب الإيداع

يعتمد التصميم التشفيري على التزامات مخزنة داخل شجرة Merkle.

ويثبت الإثبات أن ملاحظة المستخدم موجودة ضمن الملاحظات الممولة الصالحة، من دون تحديد الورقة التي تمثلها. كما يمنع الـNullifier، المشتق من سر الملاحظة، استخدام الرصيد نفسه مرتين.

وتذكر المؤسسة استخدام إثباتات Groth16 على شبكة BN254، إلى جانب تجزئة Poseidon وشجرة مكونة من 32 مستوى.

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

ولا يحصل المستخدم على استخدام مجاني لمجرد إخفاء هويته.

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

فإذا تم حجز حد أقصى قدره 10 دولارات، واستخدم العميل خدمات بقيمة 3 دولارات، فمن المفترض أن يتم خصم 3 دولارات وليس 10 دولارات.

وهذا المثال يوضح آلية الحجز، وليس سعرًا معلنًا أو حدًا أدنى مضمونًا.

ويبقى الرصيد المتبقي داخل الملاحظة الخاصة، وفقًا لقواعد التنفيذ.

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

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

مسار الخروج من العقد مهم أيضًا

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

ويمنع ذلك جعل خادم الدفع المسار الوحيد لاستعادة الأموال.

لكن هذا لا يجعل عمليات الخروج مخفية، إذ تسجل إيثريوم المعاملات ذات الصلة على السلسلة.

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

مزود النموذج يستطيع التعرف على المستخدم بطرق لا يكشفها الإثبات

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

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

ولا يحتاج المزود إلى معرفة عنوان المحفظة.

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

بيانات الشبكة توفر مسارًا آخر للربط

توفر بيانات الشبكة مسارًا إضافيًا.

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

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

وقد يغير استخدام VPN أو Tor مسار الاتصال، لكنه لا يمنع المستخدم من كتابة اسمه داخل المطالبة.

اختبار الخصوصية يتكون من ثلاث طبقات

هناك ثلاثة أنواع رئيسية من الخصوصية يجب فصلها:

خصوصية الدفع: هل يمكن ربط الفاتورة بملاحظة تمويل أو بشخص محدد؟

خصوصية الشبكة: هل تستطيع الخدمة تحديد الاتصال من خلال عنوان IP أو التوقيت أو خصائص الجهاز؟

خصوصية المحتوى: هل يستطيع أي طرف يدير النموذج قراءة المطالبة؟

صُممت zkAPI بشكل أساسي لمعالجة الطبقة الأولى.

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

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

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

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

مجموعة إخفاء الهوية قد تكون صغيرة رغم سلامة الإثباتات

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

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

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

لكن الاستنتاج من المعلومات الخارجية يمثل نوعًا مختلفًا من الهجمات.

ويعد مستوى شجرة Merkle البالغ 32 مستوى معلمة سعة في التصميم، وليس دليلًا على وجود مليارات المستخدمين المختلفين الذين يخلطون أرصدتهم حاليًا.

وقد تكون الخدمة الجديدة ذات عدد صغير من الملاحظات الممولة.

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

ولا يوفر حجم الشجرة النظري أو عدد المعاملات وحدهما هذه الأرقام.

ولنفترض أن هناك 10 ملاحظات مؤهلة لجلسة معينة، لكن المعلومات العامة تستبعد تسعًا منها.

يمكن للإثبات الرياضي أن يخفي المعلومة السرية بشكل مثالي، بينما تشير البيانات المحيطة إلى الملاحظة العاشرة.

وهذا يوضح لماذا يكون حجم وتنوع المجموعة المحتملة أهم من العدد الإجمالي للمعاملات في الخزنة.

وقد تساعد عمليات توحيد المبالغ وتأخير النشاط والاستخدام المنتظم، لكن سلوك المستخدم وتصميم الخدمة هما ما يحددان المعلومات المتاحة للمقارنة والربط.

سجلات الجلسة تكشف حدود الخصوصية

يمكن رسم سجلات جلسة واحدة دون افتراض وجود أي طرف يتصرف بشكل غير صحيح.

تسجل إيثريوم معاملة الإيداع وعنوان التمويل. ويحتفظ جهاز المستخدم بسر الملاحظة ويرسل إثباتًا إلى خادم الدفع.

ويسجل الخادم صلاحية الإثبات، والـNullifier، وحدث إصدار مفتاح محدود القيمة.

أما مزود النموذج فيسجل المفتاح والطلبات والاستخدام الذي تمت فوترته.

ويربط الإيصال الموقع المفتاح بإجمالي الاستخدام المقاس.

وعند الإغلاق، يمكن للعقد الذكي تسجيل عملية الخروج.

وبالتالي يمتلك كل طرف سجلًا جزئيًا.

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

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

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

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

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

عمر مفاتيح الجلسات يؤثر في مستوى الربط

تكشف دراسة السجلات أيضًا أهمية مدة صلاحية المفاتيح.

فمفتاح الجلسة يجمع عمدًا كل الطلبات التي يسمح بها، حتى يتمكن مزود الخدمة من قياس الاستخدام.

وقد يسمح حد قدره 50 دولارًا بإرسال عدد كبير من المطالبات تحت مفتاح واحد.

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

ولا يوجد إعداد واحد يضمن أعلى مستوى من الخصوصية في جميع الحالات؛ إذ يختار المستخدم والمزود بين الراحة والتكلفة وإمكانية الربط.

وينبغي لنموذج التهديد العام أن يحدد بدقة السجلات التي يتم الاحتفاظ بها ومدة الاحتفاظ بها.

كما ينبغي أن يوضح ما إذا كان الخادم يسجل عناوين IP أثناء إرسال إثبات الدفع، وما إذا كان يحتفظ بالـNullifiers إلى أجل غير مسمى، وما إذا كان يمكن ربط معرفات الإيصالات بمحتوى الطلب بعد التسوية.

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

إيصال الاستخدام الموقع ينقل الثقة إلى نظام القياس

يحتاج المزود أو الخادم إلى طريقة لتحصيل تكلفة العمل المنجز فعليًا.

ويستخدم التصميم إيصالًا موقعًا مرتبطًا بالمفتاح قصير الأجل وحجم الاستخدام.

وهذا ينقل سؤالًا تجاريًا أساسيًا إلى دقة القياس.

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

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

وينبغي للمستخدم أن يسأل:

• ما وحدة القياس التي يتم تحصيل الرسوم على أساسها؟

• من يقوم بتوقيع الإيصال؟

• كيف يتم تحرير المبلغ المحجوز وغير المستخدم؟

• ماذا يحدث إذا فشل الطلب في منتصف التنفيذ؟

هذه أسئلة فوترة تقليدية، لكن ضمن بنية تشفيرية غير معتادة.

ويحد سقف الإنفاق من حجم الرسوم غير المتوقعة في جلسة واحدة، لكن يمكن لعدد كبير من الجلسات الصغيرة أن يتراكم إلى تكلفة كبيرة.

وقد تحتاج الخدمات إلى حدود استخدام ونظام فواتير وآلية خصوصية لتسوية النزاعات.

المقايضة هنا تشغيلية

تسهل الحسابات التقليدية دعم العملاء واسترداد الأموال والتحقيق في إساءة الاستخدام، لأن مزود الخدمة يستطيع تحديد هوية المشتري.

أما zkAPI فتزيل الهوية الدائمة للفوترة من مسار الدفع المقصود.

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

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

ومن الاختبارات العملية المهمة تجربة جلسة تتعرض للانقطاع.

يحصل العميل على مفتاح محدود القيمة، ويرسل عدة طلبات، ثم يفقد الاتصال بالشبكة ويعيد الاتصال لاحقًا.

هل يعكس الإيصال الاستخدام الذي تم تسليمه فقط؟

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

وإذا اختفى الخادم، هل يستطيع المستخدم استعادة الرصيد غير المستخدم من خلال العقد كما هو معلن؟

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

العقد الذكي هو مسار للخروج وليس درعًا للخصوصية

يمكن لعقد الخزنة التحقق من إثباتات الإيداع والإغلاق وعمليات الخروج، وفقًا لمؤسسة إيثريوم.

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

لكن العقد الذكي يستبدل جزءًا من الثقة بالمؤسسة المركزية بمخاطر العقود الذكية.

فوجود خلل في التحقق من الإثباتات أو المحاسبة أو آلية السحب قد يؤثر في الأموال رغم سلامة مفهوم الخصوصية.

والعنوان الموجود على الشبكة دليل على النشر، وليس شهادة تدقيق أمني.

كما أن عمليات الإيداع والسحب العامة لها تكلفة على الخصوصية.

فمن يعرف عنوان تمويل المستخدم يستطيع ملاحظة تفاعله مع الخزنة.

وقد لا يتمكن من معرفة جلسة واجهة برمجة التطبيقات التي دفع تكلفتها، لكنه يستطيع رؤية المشاركة والمبالغ.

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

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

جذور المشروع تعود إلى أبحاث إيثريوم

تعود جذور المشروع إلى تصميم بحثي في Ethereum Research يتعلق بأرصدة واجهات برمجة التطبيقات المعتمدة على المعرفة الصفرية، وتحدد مؤسسة إيثريوم أن العمل يرتبط بـ Davide Crapis وVitalik Buterin.

لكن المقترح البحثي والنظام الإنتاجي يجيبان عن سؤالين مختلفين.

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

ويضع إطلاق 1 أكتوبر الفكرة في بيئة تشغيل يمكن اختبارها، وهو التطور الجديد الأهم.

جهود خصوصية إيثريوم الأوسع ليست المنتج نفسه

لا ينبغي الخلط بين جهود الخصوصية الأوسع في إيثريوم وبين zkAPI.

فتغطية Crypto.news لتصميم خصوصية أصلي مقترح تتعلق بتغيير مقترح على مستوى البروتوكول، بينما zkAPI تطبيق يعمل حاليًا.

كما أن إطلاق محفظة zk.money الأخيرة يتعلق بتحويلات خاصة في بيئة مختلفة.

ولا ينبغي استخدام أي منهما كدليل على أن المطالبة المرسلة عبر zkAPI مخفية عن مزود نموذج الذكاء الاصطناعي.

ادعاءات الخصوصية يجب أن تصمد أمام اختبار قابل لإعادة التنفيذ

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

وينبغي اختبار الوضع المباشر ووضع الوكيل بشكل منفصل.

فإذا تلقى خادم الدفع المطالبة في الوضع المباشر، فإن ذلك يتعارض مع الفصل الموصوف.

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

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

ويعتمد هذا الاختبار على حجم مجموعة إخفاء الهوية الفعلية ونوع المعلومات الإضافية التي يمتلكها المهاجم.

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

اختبار المحتوى يكشف الحد الفاصل بوضوح

اختبار المحتوى بسيط ومهم.

أرسل المستند المميز نفسه باستخدام مفتاحي جلسة جديدين.

إذا استطاع مزود النموذج التعرف عليه في الجلستين، فإن عدم ربط الدفع بالمستخدم لم يتحول إلى عدم قابلية ربط المحادثة.

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

ومن شأن نشر الوضع المستخدم ونموذج التهديد ونتائج الاختبارات أن يساعد المستخدمين على اختيار الأداة المناسبة لمخاوفهم الفعلية.

النقطة الأقوى هي فصل الفوترة عن المحتوى المفيد

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

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

وهذه هي الحاجة الأضيق التي يعالجها تصميم zkAPI.

كما يسمح التصميم للآلة بدفع تكلفة الخدمات التي تعتمد على الاستخدام دون الحاجة إلى إدارة حساب شخصي طويل الأجل لكل طلب.

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

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

وقد يفضل بعض المستخدمين حسابًا تقليديًا يوفر دعمًا واستردادًا للأموال على نظام دفع تشفيري لا تزال آليات تسوية النزاعات فيه حديثة.

ويعتمد الاختيار على نموذج التهديد الفعلي للمستخدم.

خارطة خصوصية إيثريوم لا تمنح هذه الخدمة حماية مستقبلية تلقائيًا

تطرح خارطة طريق الخصوصية في إيثريوم، التي ناقشتها Crypto.news، الخصوصية باعتبارها هدفًا أوسع.

لكن خارطة الطريق لا تمنح هذه الحماية المستقبلية للتطبيق الحالي.

ويجب على مستخدم الذكاء الاصطناعي تقييم مسار العميل ومزود الخدمة الذي يتعامل فعليًا مع المطالبة.

كما شرحت Crypto.news في دليل منفصل آليات المعرفة الصفرية بصورة أوسع.

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

وتوضح مقابلاتها حول البنية التحتية لإيثريوم التي تركز على الخصوصية مدى اختلاف المنتجات في البيانات التي تحميها.

والسؤال المفيد في حالة zkAPI ليس ما إذا كان المشروع يستحق وصف “خاص”، وإنما: أي طرف يرى أي سجل في كل مرحلة؟

أفضل دليل على نجاح الخصوصية سيكون قياسًا عمليًا

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

أما أقوى دليل على ضرورة تجنب المبالغة في وصف الخصوصية، فهو موجود بالفعل في إعلان مؤسسة إيثريوم نفسها: مزود النموذج يرى المطالبة.

ويمكن أن تكون الملاحظتان صحيحتين في الوقت نفسه.

المدفوعات الآلية أحد الاستخدامات المحتملة

تذكر المؤسسة أن مدفوعات واجهات برمجة التطبيقات بين الآلات يمكن أن تكون أحد الاستخدامات المحتملة.

وقد يرسل وكيل مستقل مئات الطلبات باستخدام ملاحظة ممولة واحدة أو عدة جلسات قصيرة.

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

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

الوكلاء يحتاجون أيضًا إلى ضوابط للميزانية

يحد السقف لكل مفتاح من تكلفة جلسة واحدة، لكن يمكن للوكيل إنشاء مفاتيح جديدة بشكل متكرر حتى استنزاف الملاحظة، ما لم يفرض العميل سياسة إنفاق أوسع.

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

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

وعندما تشترك عدة وكلاء في مجموعة أرصدة واحدة، يمكن أن تصبح المحاسبة الداخلية نظام الفوترة المخفي.

وقد يحتاج المشغل إلى توزيع الرسوم على فرق أو عملاء دون تصدير هوياتهم إلى مزود واجهة برمجة التطبيقات.

ويمكن تنفيذ ذلك من خلال سجل محلي، لكنه ينشئ مجموعة بيانات حساسة أخرى تحتاج إلى الحماية.

فالانتقال من الفوترة القائمة على الحساب إلى الفوترة القائمة على الملاحظات لا يلغي عملية التسوية؛ بل ينقلها إلى مكان آخر.

سلوك الوكيل قد يكشف هويته أيضًا

يمكن للوكيل أن يكشف عن نفسه من خلال سلوكه.

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

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

النشر لا يزال يحتاج إلى تدقيق لنموذج التهديد

اعتبارًا من 2 أكتوبر، تقول مؤسسة إيثريوم إن الكود والخادم والعميل والخزنة أصبحت متاحة.

ويرتبط الإعلان بعقد على الشبكة الرئيسية ومستودع برمجي.

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

ولا تشير هذه الملاحظات إلى اختراق أو سوء سلوك من جانب مزود محدد.

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

وينبغي للمراجعة الخارجية فحص الإعدادات الافتراضية للعميل والاتصالات الصادرة.

هل ترسل الواجهة التجريبية بيانات إضافية إلى نطاقات غير مرتبطة؟

هل يحتفظ العميل المحلي بالمفاتيح أو بسجل المطالبات؟

هل يستطيع خادم الدفع ربط توقيتات إصدار المفاتيح بعناوين الشبكة؟

هل يمكن ربط معرفات الإيصالات بين الجلسات؟

وكيف تتم إدارة تحديثات الدوائر والعقود؟

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

كما ينبغي أن يختبر التقييم الخارجي ما يراه مزود الذكاء الاصطناعي.

فهو يرى المحتوى الذي يعالجه وبيانات اعتماد الجلسة.

وقد يجمع أيضًا بيانات عن الجهاز أو الشبكة وفقًا لمسار الطلب.

وتظل سياسة الاحتفاظ بالبيانات لدى المزود والشروط التعاقدية ذات أهمية كبيرة.

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

الخلاصة: خصوصية الدفع ليست خصوصية المحادثة

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

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

ويجب تقييم الادعاءين بشكل منفصل.

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