كنت أعتقد في الأصل أن @NewtonProtocol يساهم بشكل أساسي في فصل التفويض عن منطق التطبيق. وبعد أن قضيت وقتًا أطول مع المعمارية، وجدت نفسي أركز على شيء أصغر بكثير: قرار ربط مُعرّفات السياسة بتكوين PolicyClient بدلًا من التعامل مع التكوين باعتباره مجرد تفصيل ثانوي.
يؤدي هذا الآلية إلى تغيير طريقة الحفاظ على سجل التفويض.
يُشير PolicyClient الخاص بـ Julia إلى سياسة Rego قابلة لإعادة الاستخدام مع تزويدها بمعلمات وقت التشغيل مثل حدود الإنفاق، والمستلمين المعتمدين، والقيود القضائية، أو غير ذلك من القيود التشغيلية. تظل منطق السياسة كما هو، لكن التكوين يحدد البيئة التي يتم فيها تقييم هذا المنطق. بدلًا من تضمين هذه الحدود داخل كل سياسة على حدة، يمرر Newton هذه الحدود على شكل بيانات تهيئة مُنظمة أثناء التقييم.
تظهر النقطة المثيرة للاهتمام عندما تتغير تلك الحدود.
بدلًا من السماح باستمرار هوية التفويض نفسها، يُنشئ نيوتن مُعرّف سياسة جديدًا كلما تغيّرت إعدادات PolicyClient. الإقرارات التي تم إنشاؤها ضمن الإعداد السابق لم تعد صالحة بعد أن يشير العميل إلى المُعرّف الجديد. لذلك يظل التفويض مرتبطًا تمامًا بالإعداد المحدد الذي أنتجه، بدلًا من الارتباط فقط بالسياسة القابلة لإعادة الاستخدام.
من منظور معماري، يؤدي ذلك إلى إنشاء ارتباط أقوى بين الموافقة والسياق. قد تنفّذ تطبيقان منطق سياسة متطابقًا بينما تفرضان حدودًا تشغيلية مختلفة. إن تعامل تلك البيئات بوصفها هويات تفويض منفصلة يجعل من السهل تمييز أي موافقات تنتمي إلى أي إعداد.
لكن شيئًا ما ظل يزعجني.
الإعداد هو مصدر واحد للتغيير فقط. بعض قرارات التفويض تعتمد أيضًا على معلومات موجودة خارج سلسلة الكتل. يعالج نيوتن ذلك من خلال PolicyData Oracles التي تعمل كمكوّنات WASM معزولة. يدخل إدخال مُهيكل إلى المكوّن، تُنفَّذ العمليات المسموح بها داخل بيئة معزولة (sandbox)، وتصبح JSON مُهيكلة متاحة أثناء تقييم السياسة.
العزل متعمّد. تمنع عملية Oracle عناوين loopback وعِدَد الشبكات الخاصة وواجهات الشبكات المحلية (link-local)، مع تقييد طلبات HTTP بنقاط نهاية يمكن الوصول إليها علنًا. ويمكن للمطوّرين أيضًا تحديد مخططات JSON بحيث يمكن رفض الطلبات غير الصالحة قبل بدء التنفيذ.
يعيد التصميم تحديد الحدود.
تُدخل استجابات الـ Oracle تمييزًا آخر لفت انتباهي. إذا تعذّر الحصول على معلومات خارجية أو فشلت عملية التحقق، يمكن للسياسات تفسير بيانات خطأ مُهيكلة ورفض التفويض. وإذا تعذّر على مكوّن WASM نفسه التنفيذ بنجاح، يتوقف التقييم عند DataProviderError بدلًا من إنتاج نتيجة تفويض عادية.
إنه لا يزيل الثقة. بل ينقلها.
تنتقل المسؤولية إلى من يقوم بإعداد السياسات وتصميم مكوّنات المُزوِّدات (oracles) وتحديد كيفية تأثير حالات الفشل على نتائج التفويض. يوفّر البروتوكول آليات قابلة لإعادة الاستخدام، لكن تبقى التطبيقات مسؤولة عن اختيار فترات الانتهاء والحدود التشغيلية وسلوك السياسة بما يتوافق مع متطلباتها.
تظهر نفس الموازنة في الإقرارات. يتضمن كل تفويض قيمة expireAfter، مما يتيح للتطبيقات إمّا تقصير نوافذ الصلاحية لتقليل فرص إعادة الاستخدام أو إطالة النوافذ لزيادة سهولة الاستخدام. يوفر البروتوكول مرونة دون أن يفرض مكان ضبط تلك الموازنة.
تتجاوز أهمية التنفيذ أهمية الآلية نفسها.
بالنسبة للمطوّرين الذين يبنون أنظمة حول فحص العقوبات، أو التحقق من الهوية، أو ضوابط الخزانة، أو عمليات العملات المستقرة (stablecoin)، أو نقل الأصول في العالم الحقيقي، أو وكلاء برمجيات مستقلين، تغيّر المعمارية مكان تعقيد النظام. بدلًا من توزيع منطق التفويض داخل كود التطبيق، تُركّز المسؤولية داخل سياسات قابلة لإعادة الاستخدام، ومعرّفات مدركة للإعداد، ومزوّدي بيانات معزولين، وإقرارات محددة بوقت whose meaning depends on the conditions under which they were created.
هل يؤدي ربط التفويض بمُعرّفات سياسات خاصة بإعداد بعينه إلى تعزيز سلامة التفويض على المدى الطويل، أم أنه لا يفعل سوى نقل المسؤولية التشغيلية إلى طبقة مختلفة؟