بينما كنت أستكشف ورقة @NewtonProtocol البيضاء لبروتوكول نيوتن الخاصة بحملة CreatorPad الحالية اليوم، أدركت أنه لسنوات اعتمد Web3 على افتراض بسيط: إذا أنشأ المحفظة توقيعًا صالحًا، فالمعاملة تكون مُصرّحًا بها. تعمل هذه الفكرة بشكل جيد عندما تكون المفاتيح الخاصة تحت سيطرة البشر. لكن مع بدء عملاء الذكاء الاصطناعي في إدارة الخزائن والسيولة والاشتراكات واستراتيجيات عبر السلاسل، لم يعد امتلاك مفتاح كافيًا للإجابة عن السؤال الأكثر أهمية: هل تم السماح بهذه العملية فعلًا؟
$NEWT يقدم نموذج ثقة مختلفًا. بدلًا من السؤال "من وقّع هذه المعاملة؟"
تسأل NEWT: "هل تحقق هذا الطلب/النية للمعاملة من شرط الامتثال الصحيح لاتحاد السياسات على الإنترنت قبل التنفيذ؟"
هذا التحول الدقيق يغير جوهريًا طريقة تفاعل الأنظمة المستقلة مع الأصول على السلسلة.
على عكس نقاط نهاية RPC التقليدية التي تبث المعاملات الموقعة فورًا، تقبل بوابة نيوتن نية المعاملة عبر "newt_createTask".
في هذه المرحلة، لم يتم منح أي ترخيص للتنفيذ بعد. يدخل الطلب أولًا إلى خط تقييم سياسات لامركزي حيث يتم تنفيذ منطق سياسات WASM حتمي على مدخلاتٍ مُشفّرة. يقوم كل مُدقق على حدة بتقييم النية نفسها تحت السياسة نفسها، مما يضمن أن قرار الترخيص قابل لإعادة الإنتاج بدلًا من أن يكون خاضعًا للاجتهاد.
تخيل أن خزانة مؤسسة تُعرّف سياسة مثل هذه:
• تحولات الخزانة التي تتجاوز 5 ملايين دولار تتطلب موافقة حوكمة متعددة الأطراف.
• يُسمح بالتنفيذ فقط خلال نوافذ تشغيل محددة مسبقًا.
• يجب أن تستوفي المعاملة قيود مخاطر المحفظة.
• يجب أن تجتاز عناوين الوجهة فحوصات الامتثال.
• قد يعيد وكلاء الذكاء الاصطناعي موازنة المراكز لكن لا يمكنهم تعديل معلمات التخصيص الاستراتيجي.
لاحظ أن أيًا من هذه القواعد لا يصف كيفية توقيع معاملة. بل تحدد ما إذا كانت المعاملة تستحق أصلًا أن تُوقَّع أم لا.
يمكن تزويد معلومات الهوية الحساسة عبر "newt_uploadEncryptedData"، بينما تبقى الاعتمادات السرية ومفاتيح API ومعلمات التنفيذ محمية باستخدام "newt_storeEncryptedSecrets" ومزوّدي الأسرار المشفّرة بنظام NPE في نيوتن.
تستهلك السياسات مدخلاتٍ مُشفّرة دون تعريض النص الصريح للمُدققين، ما يسمح باتخاذ قرارات الترخيص دون التضحية بالسرية. بمجرد اكتمال التقييم، تُرجع البوابة شيئًا أكثر قيمة من رسالة موافقة. إنها تُرجع إقرارًا قابلاً للتحقق مدعومًا بتوقيع BLS مُجمَّع يمثل الإجماع حول نتيجة تقييم السياسة. ويمكن تقديم هذا الإقرار مع المعاملة المترتبة لاحقًا، ما يتيح لأي عقد ذكي متوافق التحقق على السلسلة بأن قيود السياسة المطلوبة قد تم استيفاؤها قبل التنفيذ.
وبمنظور مماثل، خذ ثلاثة أمثلة شائعة:
جهة مُصدِرة لعملة مستقرة، وخزنة DeFi، ووكلاء ذكاء اصطناعي يتعاملون مع المدفوعات على السلسلة. جميعها تحتاج إلى ترخيص قبل التنفيذ، لكن لأسباب مختلفة. يجب على مُصدّر العملة المستقرة التحقق من حالة KYC والاختصاص القضائي قبل إصدار العملة. يجب على الخزنة فرض أهلية المستثمر وحدود المراكز قبل تخصيص رأس المال. يحتاج وكيل الذكاء الاصطناعي إلى حدود إنفاق وسياسات معاملة قبل أن يتمكن من تحريك الأموال. ورغم أن هذه المتطلبات متشابهة مفاهيميًا، فإن كل فريق عادةً ما يطبقها بشكل مستقل. يؤدي ذلك إلى تكرار غير ضروري. قد تكون قائمة العقوبات نفسها مُدمجة داخل عقد ذكي واحد، أو معروضة عبر واجهة API خارج السلسلة في مشروع آخر، أو حتى مستبعدة تمامًا لأنها تقع خارج النطاق الأولي للفريق. يجب تدقيق كل تنفيذ وصيانته وتحديثه على حدة، حتى عندما تكون السياسة الأساسية في الواقع هي نفسها فعليًا.
إن المعمارية أيضًا مشكلة بالطريقة نفسها. صُممت العقود الذكية لتنفيذ انتقالات حالة حتمية، لا لإدارة قواعد سياسة تتغير مع الزمن. تتطور قوائم العقوبات، وتتغير متطلبات الاختصاص القضائي، وتُعدَّل عتبات المخاطر. غالبًا ما يعني إبقاء هذا المنطق على السلسلة ترقيات للعقود، بينما يؤدي دفعه خارج السلسلة إلى طبقة إضافية يمكن أن تنحرف عن توافقها مع البروتوكول.
لا يكون تطبيق السياسات ذا معنى إلا إذا حدث في المكان الذي يحدث فيه التنفيذ. إذا كانت فحوص السياسة موجودة فقط في واجهة أمامية أو خدمة خلفية، يمكن لأي شخص يتفاعل مباشرةً مع العقد—سواء روبوت أو بروتوكول آخر أو وكيل آلي—تجاوزها بالكامل. تظل المعاملة ناجحة لأن العقد نفسه لا يملك طريقة للتحقق من إكمال الفحوص المطلوبة. تصبح المشكلة أكثر وضوحًا عندما تتكامل البروتوكولات مع بعضها البعض.
لا تمتلك التطبيقات اللاحقة طريقة معيارية للتحقق مما إذا كان بروتوكول سابق قد أجَرى فعلًا تقييم امتثال أو تقييم مخاطر، وما هي السياسة التي تم تقييمها، أو ما إذا كانت النتيجة ما تزال صالحة. وبدون إقرارات توثيقية مشفّرة قابلة للحمل، يُجبر كل بروتوكول على الثقة—أو إعادة—عملية التحقق نفسها.
تتعامل NEWT مع المشكلة بطريقة مختلفة. بدلًا من اعتبار فرض السياسات منطقًا خاصًا بالتطبيق، تجعل ذلك جزءًا من طبقة البروتوكول. تُكتب السياسات مرة واحدة في Rego، وتُنشر في سجل مشترك، وتُعاد إعادة استخدامها عبر تطبيقات مختلفة.
قبل التنفيذ، تتطلب العقود إقرارًا موثقًا بتوقيع تشفيري صادرًا عن شبكة مشغّلين لامركزيين. وبما أن التحقق يتم على مستوى البروتوكول بدلًا من واجهة أمامية أو خادم بعينه، تنطبق السياسة نفسها سواء كانت المعاملة صادرة من مستخدم أو من وكيل ذكاء اصطناعي أو من بروتوكول آخر.
تقدم نسخة بيتا من بروتوكول NEWT تدفق تنفيذ يصبح:
نية المعاملة → اتحاد السياسات على الإنترنت → تقييم WASM حتمي → إقرار BLS مُجمَّع → تحقق العقد الذكي → انتقال الحالة
التمييز المعماري المهم هو أن الترخيص بات منفصلًا تشفيريًا عن التنفيذ. لا يزال المفتاح الخاص هو الذي يُخوِّل معاملة البلوك تشين. يثبت الإقرار أن المعاملة أصبحت مؤهلة للتنفيذ فقط بعد استيفاء قيود سياسة قابلة للبرمجة يُفرضها عبر شبكة سياسات لامركزية في نيوتن. وهذا يستبدل الثقة الضمنية بأدلة قابلة للتحقق. ومع تحمل الوكلاء المستقلين مسؤولية أكبر في إدارة الأصول الرقمية، قد لا يعود عنق الزجاجة هو سرعة تنفيذ المعاملات أو كفاءة الغاز.
سيتمثل التحدي الحقيقي في إثبات أن كل قرار مستقل امتثل للقواعد الشفافة القابلة للبرمجة قبل حدوث أي انتقال في الحالة. تمنح العقود الذكية بلوك تشين طريقة للتحقق من الحسابات. تستكشف واجهة برمجة بوابة نيوتن الخطوة التالية: تمكين تطبيقات مبنية للذكاء الاصطناعي من التحقق من الترخيص نفسه. وإذا حظي هذا النموذج بالاعتماد، فقد تصبح أكثر توقيع قيمة في Web3 ليس ذلك الذي ينفذ المعاملة—بل الإقرار التوثيقي التشفيري الذي يثبت أن المعاملة كان لها الحق في الوجود من الأساس.