مُعَرَّف.
لقد كنت أُعيد الاطلاع على وثائق بروتوكول نيوتن، وقرار تصميم واحد تحديدًا ما زال يجذبني للعودة إليه.
تدور معظم مناقشات البنية التحتية حول التنفيذ.
يعيد نيوتن مرارًا وتكرارًا طلب التفويض.
في البداية، افترضت أن الفرق كان في الغالب فرقًا معماريًا.
كلما قرأت أكثر، قلّ اقتناعي.
تفصل وثائق نيوتن باستمرار بين سياسات التفويض وتنفيذ التطبيقات. ومن خلال VaultKit، يحدد المطورون سياسات قابلة للبرمجة، بينما يقوم طبقة التفويض بتقييم تلك السياسات قبل أن تمضي المعاملات قدمًا.
يبدو هذا مباشرًا.
لا أعتقد أن التداعيات واضحة.
لسنوات، اعتبرت التطبيقات أن التفويض مسؤولية داخلية. كل بروتوكول يبني نموذج الصلاحيات الخاص به، وقواعده التشغيلية الخاصة به، وطريقة تحديد من يمكنه فعل ماذا.
يبدو أن نيوتن يشكك في هذا الافتراض.
بدلًا من تضمين تلك القرارات داخل كل تطبيق، فإنه يعامل التفويض كبنية تحتية يمكن أن تعتمد عليها عدة تطبيقات في نهاية المطاف.
هذا التحول يغيّر أكثر من مجرد سير عمل المطور.
هذا يغيّر مكان توقع الثقة أن تعيش فيه.
تظل التطبيقات تملك منطقها الخاص بالأعمال.
تصبح طبقة التفويض مسؤولة عن تقييم ما إذا كانت السياسات المحددة مسبقًا قد تم الوفاء بها فعليًا قبل بدء التنفيذ.
بقراءة الوثائق، لاحظت أن نيوتن نادرًا ما يصف هذا بأنه يستبدل العقود الذكية.
يصفه بأنه إضافة طبقة قرار قابلة للبرمجة حولها.
تلك الصياغة تبدو مقصودة.
كان التنفيذ دائمًا يجيب عن: "ماذا حدث؟"
محاولات التفويض للإجابة عن: "هل ينبغي أن يحدث؟"
هذه الأسئلة ليست مترادفة.
يتم تسجيل النتائج.
بينما الجهة الأخرى تقيم النية مقابل السياسة.
ما يراودني باستمرار هو ما إذا سيراهم المطورون في النهاية التفويض بالطريقة نفسها التي يرون بها المحافظ أو مزودي RPC أو خدمات الفهرسة—بنية تحتية مشتركة يستهلكها التطبيق بدلًا من إعادة بنائها بشكل مستقل.
إذا حدث ذلك، فقد تكون معمارية نيوتن تقدم طريقة تفكير مختلفة في تصميم التطبيقات بدلًا من مجرد ميزة بروتوكول أخرى.
هذه هي النقطة التي أجدها الأكثر إثارة للاهتمام.
إذا أصبح التفويض بنية تحتية مستقلة بدلًا من كونه منطق تطبيق، فهل يصبح Web3 أسهل في الحوكمة... أم أن الحوكمة ستنتقل ببساطة إلى طبقة يتعين على كل تطبيق الاعتماد عليها في النهاية؟
@NewtonProtocol #NEWT $NEWT
#Newt
