إليك نسخة أكثر طبيعية وحوارية تحافظ على العمق التقني، لكنها تبدو كتحليل شخصي حقيقي وليست تقريرًا رسميًا.
ظننت أن أكبر ميزة أمنية في نيوتن كانت محرك سياساتها. كنت مخطئًا.
عندما بدأت لأول مرة بالقراءة عن بروتوكول Newton، افترضت أن الجزء الأهم في بنية النظام هو محرك السياسات نفسه.
في النهاية، هذا هو المكان الذي تعيش فيه منطق التفويض. يقوم المشغّلون بتقييم سياسات Rego، وتوليد إثباتات تشفيرية، ثم يقوم PolicyClient بالتحقق من تلك الإثباتات قبل السماح بتنفيذ عملية (transaction).
كان ذلك يبدو كقلب النظام.
لكن بعد قضاء وقت إضافي مع الوثائق، أدركت شيئًا مهمًا يحدث قبل أن يقوم أي مشغل بتقييم قاعدة واحدة.
يجب أولاً السماح بالسياسة ضمن بيئة الإنتاج.
غيّر ذلك طريقة تفكيري في نموذج أمان نيوتن.
يمكن للمطور أن يبني سياسة، ويختبرها محليًا، ويوصل أوَرَكِلز، ويحاكي سيناريوهات مختلفة، ويُحضّر كل شيء للنشر. لكن لا يعني أيّ من ذلك تلقائيًا أن السياسة يمكنها تأمين أصول حقيقية على الشبكة الرئيسية.
وفقًا لوثائق نشر نيوتن، يجب أولاً إدراج سياسات الإنتاج في قائمة السماح من قِبل فريق نيوتن.
في البداية، رأيت ذلك كقيود.
ثم أدركت أنه يحل مشكلة لا تستطيع التشفير وحده حلها.
يمكن للمشغلين الموزعين إثبات أنهم جميعًا قيموا السياسة نفسها بشكل صحيح.
لا يمكنهم إثبات أن السياسة كُتبت بمسؤولية.
لا يمكنهم معرفة ما إذا كان مطور ما قد أنشأ عن طريق الخطأ قاعدة تمنع كل المعاملات، أو يوافق على شيء لا ينبغي الموافقة عليه، أو يعتمد على بيانات غير موثوقة، أو يتصرف بشكل غير متوقع عندما تتغير ظروف السوق.
الاجتماع/التوافق ممتاز في التحقق من التنفيذ.
لم يُصمَّم للحكم على جودة السياسة.
لهذا بدأت بالنظر إلى نظام السماح المسبق كطبقة أمان منفصلة، وليس مجرد خطوة إدارية.
بعبارة أخرى، لا يقوم نيوتن بتأمين طريقة تنفيذ السياسات فقط.
كما أنه يحاول تقليل خطر وصول أي سياسات إلى الإنتاج من الأساس.
يبدو أن هذا التمييز أكثر أهمية مما كنت أعتقد في البداية.
كما يسلط الضوء على شيء مثير للاهتمام حول اللامركزية.
غالبًا ما يفترض الناس أنه إذا كان التنفيذ لامركزيًا، فيجب أن تكون كل أجزاء النظام لامركزية أيضًا.
لكن نيوتن يفصل بين هذه المسؤوليات.
المطورون أحرار في تصميم السياسات.
يقوم مشغلو الشبكة بتقييم السياسات المعتمدة.
تتحقق سلسلة الكتل من النتيجة.
وقبل كل ذلك، توجد عملية قبول ضمن الإنتاج تحدد أي السياسات يمكنها فعلاً حماية الأصول المباشرة.
تُحل كل طبقة مشكلة مختلفة.
يركز محرك السياسة على التفويض.
يركز المشغلون على التقييم المتسق.
توفر الإثباتات التشفيرية تنفيذًا يمكن التحقق منه.
يركز نظام السماح المسبق على مخاطر الإنتاج.
لا تُغني أيّ من هذه الطبقات عن الأخرى—بل تتكامل معها.
وبالنسبة لبروتوكول ما يزال في مرحلة مبكرة نسبيًا من رحلته على الشبكة الرئيسية، فإن هذا النهج منطقي عمليًا بالفعل.
قد تؤدي سياسة تفويض مصممة بشكل سيئ إلى تجميد نشاط مشروع، أو الموافقة على معاملات لا ينبغي حدوثها، أو إنشاء إخفاقات غير متوقعة عبر التطبيقات.
إن العثور على تلك المشكلات قبل أن يتأثر المستخدمون الحقيقيون يكلف أقل بكثير من إصلاحها بعد ذلك.
وفي الوقت نفسه، يثير هذا أيضًا أسئلة أعتقد أنها ستصبح أكثر أهمية مع نمو نيوتن.
هل سيظل نظام السماح المسبق دائمًا عملية يديرها الفريق؟
هل يمكن أن تصبح بعض أجزاء قبول السياسات لا مركزية في النهاية؟
هل ستكون هناك معايير مراجعة منشورة يعرف من خلالها المطورون بالضبط ما هو متوقع قبل تقديم سياسة؟
هل يمكن أن تصبح عمليات تدقيق أمني مستقلة جزءًا من عملية الموافقة؟
مع توسع النظام البيئي، تكتسب هذه الأسئلة أهمية لأن الثقة لا تُبنى فقط عبر إثباتات تشفيرية.
كما أنها بُنيت عبر عمليات شفافة.
أمر واحد لفت انتباهي حقًا هو أن معمارية نيوتن لا تعتمد على آلية أمان واحدة فقط.
بدلًا من ذلك، تقوم بتكديس/تطبيق الأمان على عدة مراحل.
يكتب المطورون السياسات.
يتم مراجعة السياسات قبل الإنتاج.
يقوم المشغلون بتقييمها بشكل مستقل.
تُنشئ توقيعات BLS إثباتات قابلة للتحقق.
يتحقق عميل السياسة (PolicyClient) من تلك الإثباتات قبل أن تتقدم أي معاملة محمية.
تقلل كل خطوة فئة مختلفة من المخاطر.
كلما نظرت أكثر، أدركت أن نيوتن لا يقوم ببناء شبكة تفويض لامركزية فحسب.
إنها تعمل على بناء نظام تبدأ فيه الأمان قبل التنفيذ، ويستمر أثناء التقييم، ويتم التحقق منه قبل السماح بحدوث معاملة.
بالنسبة لي، كانت تلك أكبر نقطة خرجت بها.
قد لا تكون أهم قرارات الأمان هي مدى دقة تقييم السياسة.
قد يكون الأمر يتعلق بتحديد أي السياسات موثوقة بما يكفي لتدخل الإنتاج من الأساس.