واصلت التساؤل عن اختيار تصميمي واحد أثناء قراءة وثائق بروتوكول نيوتن.
لماذا لا يتيح نيوتن للعقود الذكية تقييم السياسات بأنفسها؟
في البداية، بدا أن فصل تقييم السياسة عن تنفيذ العقد الذكي طبقة معمارية غير ضرورية.
تقوم العقود الذكية الحديثة بالفعل بالتحقق من التواقيع، وتطبيق منطق الأعمال، وتنفيذ المعاملات. كان يبدو أن إضافة نظام آخر قبل التنفيذ تعقيدًا إضافيًا بدلاً من كونه تحسينًا واضحًا.
تصف الوثائق نهجًا مختلفًا. بدلًا من تضمين قواعد التفويض مباشرة داخل العقود الذكية، يقوم نيوتن بتقييم نية المعاملة قبل تنفيذها. تتم معالجة السياسات المكتوبة بصيغة Rego بواسطة شبكة مشغلين لامركزية.
يقوم المشغّلون بتقييم السياسة نفسها، ويُنتجون إثباتات إسنادٍ تشفيرية، وعندما يتم بلوغ العتبة المطلوبة، يتحقق PolicyClient من صحة الإثبات قبل أن يمضيّت المعاملة المحمية على السلسلة مباشرةً.
العقد الذكي مسؤول عن التنفيذ. محرك السياسة مسؤول عن تحديد ما إذا كان ينبغي حدوث التنفيذ. في البداية، اعتقدت أن هذا الفصل موجود أساساً من أجل الامتثال.
تستخدم الورقة البيضاء كثيراً أمثلة مثل التحقق من KYC، وفحص العقوبات، والتحقق من الاختصاص القضائي، وحدود الإنفاق، وأهلية المستثمر. جعل ذلك من السهل افتراض أن نيوتن كان ينقل ببساطة عمليات الفحص التنظيمي خارج العقود الذكية.
أدى مواصلة القراءة إلى تغيير تلك الانطباع. تشرح هذه الأمثلة ما الذي يمكن لمحرك السياسة تقييمه، لكنها لا تشرح بالكامل لماذا تم فصل البنية أصلاً. يبدو أن قرار التصميم الأكبر يتعلق بالمسؤولية.
تصير عملية التنفيذ والترخيص نظامين مستقلين. لم يعد العقد الذكي بحاجة إلى فهم كل قاعدة تنظيمية، أو متطلبات امتثال، أو نموذج صلاحيات. كل ما يحتاج إليه هو التحقق من وجود إثبات ترخيص مسبقاً. وهذا يجعل العقد نفسه أبسط بكثير.
وهذا يعني أيضاً أن منطق السياسة يمكن أن يتطور دون إجبار المطورين على إعادة تصميم عقود التطبيق في كل مرة تتغير فيها قاعدة عمل. وهذا يبدو ميزة عملية. لكنَّه أيضاً يقدّم مقايضة واضحة. بمجرد انتقال الترخيص خارج العقد الذكي، يعتمد التنفيذ على نظام موزع آخر يعمل بشكل صحيح.
يجب على المشغّلين تقييم السياسات بشكل متسق. يجب أن تكون مصادر البيانات المطلوبة متاحة. يجب توليد إثباتات الترخيص قبل بدء التنفيذ.
لقد لم تختفِ التعقيدات التي كانت تعيش داخل عقود التطبيق. لقد نقلها نيوتن فقط إلى طبقة تفويض مخصصة مشتركة بين عدة تطبيقات.
يبدو أن هذا المقايضة مقصودة. بدل أن يُطلب من كل مطوّر بناء إطار ترخيص مختلف، يركز نيوتن هذه المسؤولية في بنية تحتية قابلة لإعادة الاستخدام. وهل يقلّل ذلك التعقيد الإجمالي أم لا، ربما يعتمد على حجم المنظومة التي تستخدمه.
برزت نتيجة واحدة أكثر مما توقعت. يركز معظم الحديث حول نيوتن على المشغّلين، أو الرهن (staking)، أو الإثباتات التشفيرية، أو التحقق بدون معرفة (zero-knowledge). وهذه آليات أمنية مهمة.
لكنهم يدعمون قراراً معمارياً أكبر بكثير.
يفصل نيوتن السؤال "هل يمكن لهذه المعاملة أن تنفذ؟" عن السؤال "هل ينبغي لهذه المعاملة أن تنفذ؟"
تجيب البلوكشينات التقليدية عن السؤال الأول بشكل ممتاز جداً. أما نيوتن فيهتم أساساً بالسؤال الثاني. وهذا يغيّر كيفية التعامل مع الترخيص. بدل أن يكون كوداً خاصاً بالتطبيق، يصبح بنية تحتية لبروتوكول مشترك يمكن لتطبيقات مختلفة إعادة استخدامها مع الحفاظ على منطق تنفيذها بسيطاً نسبياً.
هناك نتيجة أخرى لا يلمّح إليها التوثيق إلا بشكل خفيف. وبما أن تقييم السياسة يحدث قبل التنفيذ، فإن طبقة الترخيص تعتمد على معلومات تتجاوز حالة البلوكشين.
قد تعتمد السياسات على بيانات اعتماد الهوية، أو بيانات العقوبات، أو الصلاحيات المُفوّضة، أو مدخلات خارجية أخرى. يشرح التوثيق كيفية تقييم المشغّلين للسياسات الحتمية بمجرد توفر تلك المدخلات.
يقول أقل بكثير عن السلوك التشغيلي عندما تصبح تلك التبعيات غير متاحة مؤقتاً أو تُنتج نتائج متعارضة.
هل يتوقف تقييم السياسة ببساطة حتى تتوفر بيانات موثوقة؟
هل ترفض* التطبيق المعاملة افتراضياً؟
أم أن السلوك يعتمد على كيفية كتابة كل سياسة؟
لا يجيب التوثيق بالكامل عن أسئلة التشغيل تلك، ويبدو ذلك أمراً معقولاً لأن التطبيقات المختلفة قد تتطلب نماذج إخفاق مختلفة.
ومع ذلك، يبرز أمراً يسهل إغفاله. فصل الترخيص عن التنفيذ لا يفصل المسؤوليات فقط. بل يفصل أيضاً التبعيات.
يعتمد التنفيذ في الغالب على إجماع البلوكشين. وقد تعتمد عملية الترخيص على منطق السياسة وتقييم المشغّل والتحقق التشفيري والبيانات الخارجية الموثوقة التي تعمل معاً قبل أن يمكن أن يبدأ التنفيذ حتى.
ليس بالضرورة أن يكون ذلك ضعفاً. إنها فقط خيار معماري مختلف. يبدو أن نيوتن يجادل بأن محركات التنفيذ ينبغي أن تركز على تنفيذ كود حتمي، بينما يقع الترخيص ضمن طبقة برمجية خاصة يمكن أن تتطور بشكل مستقل عن عقود التطبيقات.
ما إذا كانت هذه الفصـلة ستصبح بنية تحتية معيارية لتطبيقات البلوكشين—أم ما إذا استمر المطورون في تضمين الترخيص مباشرةً داخل العقود الذكية—لا يزال يبدو سؤالاً أكثر إثارة للاهتمام.
