يحاول بروتوكول نيوتن تحويل شبكة المدققين لديه من نظام يعمل تحت إشراف المؤسسة إلى نظام يمكنه في النهاية قبول المشاركين دون موافقة مركزية. ومن المرجح أن يحدث الانتقال تدريجيًا وليس من خلال إطلاق واحد.
في البداية، تتحكم مؤسسة نيوتن في بيئة المدققين. الخطوة التالية تُدخل مشغّلين خارجيين مُختارين. يتمثل الهدف طويل الأجل في شبكة يمكن لمشاركين مؤهلين الانضمام إليها وفق قواعد بروتوكول عام بدلًا من تلقي التصريح من منظمة مركزية.
قد يبدو هذا التدرج بسيطًا، لكن المرحلة الثانية مهمة بشكل خاص. قد تبدو شبكة من مدققين خارجيين مُعتمدين لا مركزية بينما لا تزال تعتمد بشكل كبير على المؤسسة التي أنشأتها.
بالنسبة لنيوتن، لن يكون الاختبار الحقيقي هو ما إذا بدأت الشركات الخارجية تشغيل المدققين. بل سيكون ما إذا تلقى هؤلاء المشغّلون استقلالًا كافيًا لتقييد سلطة المؤسسة.
لماذا تتبع نيوتن نهجًا تدريجيًا
تم تصميم بروتوكول نيوتن لمساعدة المستخدمين والمؤسسات على وضع شروط قابلة للإنفاذ حول نشاط سلسلة كتل تلقائي.
قد يسمح المستخدم بإجراء معاملة فقط عندما يبقى رمز معيّن ضمن نطاق سعر محدد. قد تتطلب مؤسسة إجراء فحص الهوية وحدودًا للمعاملات وفحوصات لمخاطر المحفظة أو التحقق من الامتثال قبل انتقال الأموال. قد تجمع السياسات الأكثر تعقيدًا عدة شروط ومصادر بيانات.
يُفترض أن يقوم مشغّلو نيوتن بتقييم ما إذا تم استيفاء تلك الشروط، وإنتاج نتائج مُوقعة يمكن استخدامها أثناء التفويض.
هذه مسؤولية لا يمكن اعتبارها منخفضة المخاطر.
قد يؤخر مشغّل غير موثوق المعاملات الصحيحة. قد يوافق مدقق مُخترق على نتيجة بناءً على معلومات تم العبث بها. قد يرفض فريق منسق معالجة الطلبات أو يدعم مخرج سياسة غير صحيح.
إن فتح المشاركة فورًا سيجعل من الصعب على نيوتن فهم هذه المخاطر بينما لا تزال الشبكة في طور التطور. يمنح تعيين مجموعة مشغّلين تحت السيطرة المشروع وقتًا لاختبار برمجياته والحوافز الاقتصادية وأنظمة المراقبة وإجراءات حل النزاعات وآليات الاسترداد.
لذلك، فإن قرار البدء بحذر مفهوم. ومع ذلك، تصبح السيطرة المؤقتة مصدر قلق عندما تكون حدود تلك السيطرة غير واضحة أو عندما لا توجد مسار يمكن قياسه لتقليصها.
التشغيل الخارجي لا يضمن الاستقلال
لا يصبح المدقق مستقلًا بشكل ذي معنى لمجرد أنه تُشغِّله شركة خارج مؤسسة نيوتن.
قد يظل المشغّل يعتمد على نيوتن في شبه كل جزء مهم من عمله. قد يشغّل برمجيات لا يصونها إلا فريق النواة، ويتبع تعليمات تشغيل خاصة، ويحصل على المهام عبر بنية تحتية تخضع لسيطرة المؤسسة، ويعتمد على الموافقة المستمرة للبقاء ضمن مجموعة المدققين.
ضمن هذه الظروف، وزّعت الشبكة العمل التشغيلي دون أن تُوزّع بالضرورة السلطة.
هذه التفرقة مهمة لأن اللا مركزية غالبًا ما تُقاس بمؤشرات مرئية لكنها غير مكتملة. تعلن المشاريع عن شركاء مدققين جدد، وتنشر الشعارات، وتشير إلى ازدياد عدد المشغّلين. قد تمثل هذه الإعلانات تقدمًا، لكنها لا تُظهر مقدار الحرية التي يمتلكها كل مشغّل.
ستطلب التقييمات الأقوى الإجابة عن ما إذا كان بإمكان المشغّلين:
- الاحتفاظ بمفاتيح توقيعهم الخاصة وإدارتها.
- اختيار بنية تحتية ومزودي أمن خاصين بهم.
- التحقق بشكل مستقل من إصدارات البرمجيات.
- رفض ترقية يعتبرونها غير آمنة.
- تحدّي قرارات الشبكة علنًا.
- الاستمرار في التشغيل بعد الخلاف مع المؤسسة.
- المشاركة وفق قواعد منشورة بدل ترتيبات خاصة.
إن كان هناك مشغّل ينفذ فقط عملًا تقنيًا روتينيًا بينما تتحكم المؤسسة بالقبول والإزالة والبرمجيات والحوكمة، فإنه يكون أقرب إلى متعهد/مقاول منه إلى مشارك مستقل في شبكة.
يجب فحص مجموعة المدققين كنظام
لا يمكن الحكم على أمن نيوتن بعدّ هويات المشغّلين المُسجلين.
قد توفر عشرة مدققين حماية قليلة إذا كانوا متصلين عبر ملكية مشتركة أو مزود استضافة واحد أو خدمات متطابقة لإدارة المفاتيح أو علاقات مالية مشتركة. قد يفشل عدة مشغّلين يبدو أنهم منفصلون أو يتعاونوا في الوقت نفسه.
أكثر سؤال ذي صلة هو ما إذا كانت مجموعة المدققين تحتوي على مجالات فشل مستقلة.
هذا يعني فحص عدة أشكال من التركيز.
تركيز الملكية
لا تضمن أسماء مدققين مختلفة مصالح تحكم مختلفة. قد يكون المشغّلون شركات تابعة، أو شركاء تجاريين، أو مستثمرين في بعضهم، أو مشاركين في مجموعة خدمة واحدة.
لا تستطيع عناوين سلسلة الكتل كشف كل علاقة قد تؤثر على السلوك. قد تهم الاتفاقيات القانونية وترتيبات التمويل والشراكات غير الرسمية بقدر أهمية الرصيد على السلسلة.
تركيز البنية التحتية
قد تكون المؤسسات منفصلة قانونيًا أثناء تشغيلها على نفس منصة السحابة أو في نفس المنطقة أو عبر مركز بيانات واحد.
قد يؤثر انقطاع سحابي أو فشل في الشبكات أو تعليق حساب أو خطأ في التهيئة على عدة مدققين في الوقت نفسه. ستبدو الشبكة لا مركزية أثناء التشغيل العادي لكنها تتصرف مثل خدمة مركزية أثناء تعطّل كبير.
تركيز البرمجيات
شبكة يستخدم فيها كل مشغّل نفس العميل تحتوي على ضعف تقني مشترك. قد يؤثر خطأ في إصدار واحد على مجموعة المدققين بأكملها.
توفر تطبيقات عميل متعددة مستقلة حماية أقوى، رغم أن الحفاظ عليها يتطلب موارد تطوير إضافية. على الأقل، يجب أن يستطيع المشغّلون فحص الإصدارات واختبار التغييرات وتأخير النشر عند ظهور مخاوف.
تركيز إدارة المفاتيح
قد يعتمد مشغّلون منفصلون على مزود الحفظ نفسه أو مزود إدارة المفاتيح نفسه. يمكن أن تؤدي أي عُطلة أو اختراق أمني لدى ذلك المزود إلى الإضرار بعدة هويات توقيع في آن واحد.
لذا فإن الاستقلال عن المفاتيح/المهام بقدر الاستقلال التنظيمي أمَرا مهمًا بقدر الاستقلال التنظيمي.
تركيز اقتصادي
قد يكون الرهان موزعًا عبر عناوين مختلفة بينما يأتي في النهاية من الخزانة نفسها أو من المستثمر نفسه أو من مصدر تفويض/تفويض واحد.
إذا كانت عدة جهات مشغّلة تعتمد اقتصاديًا على نيوتن أو على مجموعة صغيرة من الداعمين، فقد تكون حوافزها متوافقة بدرجة أكبر مما تشير إليه قائمة المدققين.
يجب أن يفحص تقرير لا مركزية موثوق كل هذه العلاقات بدل عرض عدد المشغّلين كالمقياس الرئيسي للتقدم.
قواعد القبول جزء من الإجماع
في نظام بلا إذن، تُدار المشاركة أساسًا بمتطلبات بروتوكول عامة. يمكن لمشارك يستوفي الشروط التقنية والاقتصادية أن يحاول الانضمام.
في المرحلة المسموحة من نيوتن، يجب على مؤسسة/منظمة ما أن تقرر من هو المؤهل.
إن قرارًا كهذا ليس وظيفة إدارية ثانوية. فهو يحدد مجموعة المدققين قبل أي تقييم للسياسات أو توقيع يحدث.
قد تطلب نيوتن بشكل معقول من المتقدمين إظهار بنية تحتية مستقرة وكفاءة تقنية ومسؤولية قانونية وإجراءات استجابة للحوادث ودعم مالي كافٍ. لا ينبغي لشبكة متعلقة بتفويض المعاملات أن تتجاهل جودة التشغيل.
تنشأ المشكلة عندما تكون قرارات التأهيل خاصة أو غير متسقة أو يتعذر الطعن فيها.
يجب على إطار قبول شفاف أن يشرح:
- ما المعايير التقنية التي يجب على المتقدمين استيفاؤها.
- ما إذا كانت هناك حاجة إلى حد أدنى من الرهان أو تأمين.
- كيف يتم تقييم استقلال المشغّل.
- من يراجع الطلبات.
- كم تستغرق عملية المراجعة عادةً.
- لماذا قد يتم رفض طلب تطبيق ما.
- ما إذا كان المتقدمون غير الناجحين يحصلون على شرح.
- ما السلوك الذي قد يؤدي إلى التعليق أو الإزالة.
- ما إذا كان بإمكان المشغّل استئناف قرار.
من دون هذه القواعد، يمكن للمؤسسة التأثير على الشبكة عبر الاختيار حتى عندما لم تعد تشارك في كل قرار للسياسات.
يمكن استبعاد مشغّل مؤهل تقنيًا يعترض على المؤسسة قبل أن يحصل أصلًا على فرصة للتحقق. قد تصل الشبكة الناتجة إلى إجماع صحيح بينما لا تزال تعكس مجموعة مدققين شكلتها تفضيلات مركزية.
لهذا السبب، يجب اعتبار سياسة القبول جزءًا من نموذج حوكمة نيوتن ونموذج أمنها.
يجب تعريف اللا مركزية عبر طبقات نيوتن
يبدو أن بنية نيوتن تتضمن عدة وظائف: تخزين/إدارة الأذونات، تقييم السياسات، جمع النتائج المُوقَّعة، تنسيق الطلبات، وتقديم مخرجات التفويض إلى التطبيقات على سلاسل الكتل المدعومة.
لا يؤدي توزيع إحدى هذه الوظائف تلقائيًا إلى لا مركزية الوظائف الأخرى.
على سبيل المثال، قد تسمح نيوتن للمشغّلين الخارجيين بتقييم السياسات مع الاحتفاظ بالتحكم المركزي في تخزين الأذونات. قد توزع نيوتن التوقيع مع إبقاء توزيع المهام تحت بوابة واحدة. وقد تفتح المشاركة/الرهان مع السماح للمؤسسة فقط بالموافقة على تحديثات البرمجيات.
كل ترتيب يوزع نوعًا مختلفًا من السلطة.
لذلك تحتاج نيوتن إلى تقديم خريطة معمارية واضحة تُظهر:
- أي مكوّن يخزن أذونات المستخدمين.
- أي مكوّن يقيّم شروط السياسة.
- من يتحكم بالبرمجيات لكل مكوّن.
- كيف يحصل المشغّلون على المهام.
- كيف يتم دمج الردود المُوقعة.
- كيف يتم تحدّي النتائج.
- من يمكنه إيقاف النظام أو ترقيته.
- أي الأجزاء يتم التحكم فيها بواسطة العقود الذكية.
- أي الأجزاء تظل تحت سيطرة المؤسسات.
يجب أن يشرح هذا المخطط أيضًا كيف ترتبط تصميمات المشروع المتعلقة بالمفاتيح/Keystore مع شبكة المشغّلين والتكاملات الأمنية الخارجية.
بدون هذا الوضوح، قد يخلط المراقبون بين لا مركزية جزء واحد ولا مركزية البروتوكول ككل.
يمكن لمصادر البيانات أن تعيد تقديم السيطرة المركزية
قد يحتاج مشغلو نيوتن إلى معلومات خارجية لتحديد ما إذا كانت السياسة قد تم استيفاؤها.
قد تعتمد السياسة على أسعار الأصول أو التحقق من الهوية أو معلومات مخاطر المحفظة أو بيانات العقوبات أو سجل المعاملات أو إشارة أخرى خارج السلسلة. قد يوقّع المشغّلون بشكل مستقل استنتاجاتهم، لكن تلك الاستنتاجات لا تكون متباينة إلا بقدر تنوع المعلومات التي يتلقونها.
لنفرض أن كل مشغّل يتحقق من مزود السعر نفسه. إذا أفاد ذلك المزود بقيمة غير صحيحة، فقد يصل المدققون بصدق إلى الاستنتاج نفسه غير الصحيح.
ستُظهر التواقيع الناتجة اتفاقًا لا دقةً.
يخلق ذلك فرقًا بين تنوع المدققين وتنوع المعلومات.
قد تستخدم نيوتن أساليب المقارنة أو نطاقات التحمل أو حساب المتوسط الوسيط أو ملاحظات متعددة لتقليل أثر الفروق الصغيرة. قد تكون هذه الآليات قيمة، لكنها توفر حماية محدودة عندما يعتمد جميع المشغلين على المصدر الأساسي نفسه.
يجب أن يشجع التصميم الأقوى على التنوع في:
- مزودو الأوراكل.
- مسارات بيانات جغرافية.
- خدمات فحص المخاطر.
- مزودو الهوية.
- نقاط نهاية RPC.
- خدمات الفهرسة.
- منصات السحابة.
- تطبيقات البرمجيات.
يجب أن يحدد النظام أيضًا ما الذي يحدث عندما تتعارض المصادر الموثوقة. يحتاج المشغّلون إلى قواعد بشأن عدم اليقين والبيانات المتأخرة ومزودين غير متاحين والنتائج المتعارضة.
لا ينبغي لشبكة سياسات أن تفرض قرارًا واثقًا عندما تكون المعلومات المتاحة غير موثوقة.
يجب أن تكون بنية التنسيق أيضًا مرنة
حتى مع وجود مجموعة مدققين موزعة، قد يعتمد النظام على منسق مركزي.
قد تعيّن البوابة مهام تقييم السياسات، وتتلقى ردود المشغّلين، وتجمع التواقيع، ثم تعيد النتيجة إلى التطبيق الذي قدّم طلبًا. إذا كانت تلك البوابة غير متاحة أو مُخترقة، فقد لا تتمكن مجموعة المدققين من تنفيذ عمل مفيد.
ناقشت نيوتن آليات تهدف إلى تدوير مسؤوليات التنسيق أو نقلها عند فشل مشغّل. قد يقلل هذا التصميم الاعتماد على خدمة مركزية دائمة.
المسألة المهمة هي ما إذا كان نظام التحويل عند الفشل يعمل في ظروف واقعية.
يجب على نيوتن نشر أدلة تشغيلية تُظهر:
- مدى تكرار تغيّر مسؤولية التنسيق.
- ما إذا كانت عملية الدوران/التناوب تحدث تلقائيًا.
- كم يستغرق التعافي بعد حدوث فشل.
- ما إذا كانت الطلبات المعلّقة تُحفظ.
- كيف يتم حل حالات تعارض بوابات الدخول.
- ما إذا كان بإمكان المستخدمين تقديم الطلبات عبر مسارات بديلة.
- كيف يتصرف النظام أثناء انقسام/انقطاع الشبكة.
يمكن لمستند تصميم أن يصف التكرار/الاحتياط. قد تُظهر بيانات الأداء العامة ما إذا كان التكرار حقيقيًا.
تمنح مرحلة السماح/التخويل نيوتن فرصة لتنفيذ تمارين فشل مُتحكم بها. يمكن للمشغّلين فصل العقد عمدًا، وتأخير الاستجابات، وتدوير المفاتيح، ومحاكاة مزودات بيانات غير متاحة، واختبار استرداد البوابة.
إن نشر النتائج سيقدم دليلًا أقوى من مجرد الإعلان عن شراكات مدققين إضافية.
يجب أن يكون التجريد/الاقتطاع أكثر من مجرد تهديد
تهدف العقوبات الاقتصادية إلى ردع المشغّلين عن الموافقة على نتائج خاطئة أو التصرف بنزاهة معدومة.
من حيث المبدأ، يمكن للتجريد/الاقتطاع أن يجعل الهجمات مكلفة. قد يفقد مشغّل يوقّع نتيجة غير صحيحة جزءًا أو كل الرهان الذي يدعم مشاركته.
ومع ذلك، فإن نظام التجريد/الاقتطاع يكون فعالًا فقط عندما يمكن اكتشاف سوء السلوك وإثباته ومعاقبته عبر عملية قابلة للتنبؤ.
تحتاج نيوتن إلى شرح عدة تفاصيل.
أولًا، يجب أن تكون شروط التجريد/الاقتطاع محددة. «سوء السلوك» واسع جدًا. يحتاج المشغّلون إلى معرفة أي الإجراءات تولد مسؤولية/التزامًا.
ثانيًا، يجب أن تكون الأدلة متاحة. يجب على نظام التحدّي تحديد السياسة محل النزاع ونتيجة المشغّل المُوقَّعة وإدخالات البيانات ذات الصلة والقاعدة التي يُزعم أنها كانت منتهكة.
ثالثًا، يجب أن تكون العملية في وقت مناسب. قد تمنع فترة تحدّي قصيرة جدًا النزاعات المشروعة. أما إذا كانت طويلة جدًا فقد تؤخر الحسم وتخلق عدم يقين.
رابعًا، يجب أن تكون العقوبة ذات معنى اقتصاديًا. إذا كان الربح المحتمل من الموافقة على معاملة ضارة أكبر من الخسارة المحتملة للمشغّل، فإن الرهان لا يوفر رادعًا كافيًا.
خامسًا، يجب أن يراعي النظام السلوكيات المترابطة. قد لا يكفي تجريد مشغّل واحد من الرهان إذا شارك عدة مشغّلين مترابطين في الهجوم نفسه.
يجب على نيوتن نشر مقدار الأمان الاقتصادي الذي يدعم شبكة مشغّليها، وشرح كيفية مقارنة هذا المقدار بالقيمة التي قد تسمح الشبكة بتفويضها.
الإتاحة ومقاومة الرقابة أصعب لإثباتهما
قد يمكن إثبات التواقيع غير الصحيحة أحيانًا عبر سجلات تشفيرية. الصمت أصعب في تفسيره.
قد يفشل المشغّل في الرد بسبب:
- عطل في الأجهزة.
- تعطيل الشبكة.
- أخطاء برمجية.
- الصيانة.
- رقابة متعمدة.
- الضغط القانوني.
- رفض استراتيجي.
قد يلاحظ البروتوكول الاستجابة الفائتة، لكن ليس السبب وراءها.
قد تسمح العقوبات الضعيفة للغاية للمشغلين بتجاهل الطلبات دون عواقب. قد تؤدي العقوبات المفرطة في الشدة إلى معاقبة حالات فشل صادقة وردع المشاركة.
ستحتاج نيوتن إلى نظام توفر/إتاحة مُصمَّم بعناية. قد يشمل مواعيد نهائية للاستجابة، وعمليات فشل متكررة قبل العقوبة، ومراقبة صحة المشغّلين، وإعادة التعيين التلقائية، وإجراءات الإبلاغ عن الصيانة المخطط لها.
تعتمد مقاومة الرقابة أيضًا على ما إذا كان لدى المستخدمين أكثر من طريقة لإرسال طلب. إذا كانت جميع الطلبات تمر عبر واجهة واحدة يتحكم بها نيوتن، فلن تكون المدققين وحدهم نقطة الرقابة المحتملة.
لذلك يجب على المشروع تقييم المسار الكامل للمعاملة، من طلب المستخدم حتى التفويض النهائي.
ستكشف ترقيات البرمجيات عن البنية الحقيقية للسلطة
قد لا تكشف التشغيلات الروتينية الفرق بين المشغّلين المستقلين ومقدمي الخدمة الخاضعين للإشراف.
غالبًا سيصدر إصدار برمجيات مثير للجدل.
فكّر في حالة تنشر فيها نيوتن تحديثًا عاجلًا. يعتقد بعض المشغّلين أن الإصدار يتضمن خطرًا أمنيًا أو يغيّر سلوك الشبكة بطريقة لم تُراجع بشكل صحيح.
هل يمكن لهؤلاء المشغّلين رفض التحديث دون أن يتم إزالتهم؟
هل يمكنهم تنسيق تدقيق مستقل؟
هل يمكنهم الاستمرار في تشغيل الإصدار السابق؟
هل يمكنهم اقتراح تنفيذ بديل؟
هل توجد عملية رسمية لحل الخلاف؟
إن كان على المشغّل تثبيت كل إصدار مُعتمد من المؤسسة، فلا يكون له تأثير يذكر على اتجاه النظام. قد يمتلك مفتاحًا لكن لا يملك قوة حوكمة ذات معنى.
يعد التحكم بالترقية مهمًا بشكل خاص عندما تمتلك مؤسسة واحدة العميل الوحيد القابل للاستخدام. حتى دون إكراه رسمي، قد لا تكون لدى المشغّلين بدائل عملية.
يمكن لنيوتن تقليل هذا الاعتماد عبر نشر مواصفات كاملة، ودعم بناءات قابلة لإعادة الإنتاج، والسماح باختبارات مستقلة، وإنشاء فترات مراجعة عامة، وفي النهاية تشجيع أكثر من تنفيذ عميل واحد.
قد توفر أولى حالات عدم الاتفاق الكبيرة حول ترقية ما قياسًا أفضل للا مركزية من عدد المدققين الذين يعالجون طلبات روتينية.
صلاحيات الطوارئ تحتاج إلى حدود
غالبًا ما تتضمن الشبكات في المراحل المبكرة ضوابط طوارئ. قد تتمكن مؤسسة أو مجلس أمن من إيقاف العقود، وإزالة المشغّلين، وحظر ترقية، أو الاستجابة لثغرة/استغلال.
يمكن لهذه الصلاحيات حماية المستخدمين أثناء التطوير. ويمكن أيضًا أن تتحول إلى مصادر دائمة للسيطرة المركزية.
يجب على نيوتن تحديد كل سلطة طوارئ موجودة وشرح:
- من يمكنه تفعيلها.
- كم عدد التواقيع المطلوبة.
- ما الأحداث التي تبرر استخدامه.
- ما إذا كانت العملية مرئية على السلسلة أم لا.
- إلى متى يمكن أن تستمر حالة الطوارئ.
- من يمكنه استعادة التشغيل العادي.
- ما إذا كانت القوة ستُخفض في النهاية أو تُزال.
لا ينبغي لآلية الطوارئ أن تعمل كمفتاح إداري غير مقيد.
يمكن أن تقلل التأخيرات الزمنية والإشعارات العامة والموافقات متعددة الأطراف والأذونات الضيقة وانتهاء الصلاحية التلقائي من خطر استخدام ضوابط الطوارئ للحوكمة العادية.
إن استعداد المؤسسة لتقييد هذه الصلاحيات سيكون علامة مهمة على ما إذا كانت مرحلة السماح/التخويل مؤقتة حقًا.
يجب أن تكون شروط الخروج من الانتقال قابلة للقياس
يجب أن تتضمن خريطة طريق اللا مركزية أكثر من وعود عامة.
قد تقول نيوتن إن مشاركة المدققين المفتوحة تعتمد على إثباتات تشفيرية أقوى وأمن عدة الأجهزة المحسن وتدقيقات إضافية وتكاليف يمكن التحكم بها ووضوح تنظيمي. جميع هذه المخاوف معقولة.
كما أنها مفتوحة النهايات.
يمكن دائمًا تحسين الأمان. يمكن دائمًا تكليف تدقيق آخر. قد يبقى التنظيم غير مؤكد لسنوات. يمكن للمشروع استخدام هذه الحجج لإرجاء فتح المشاركة دون أجل إلى أجل غير مسمى دون التخلي رسميًا عن الهدف.
بدلًا من ذلك، يجب على نيوتن نشر شروط قابلة للقياس للتقدم إلى المرحلة التالية.
قد تشمل المؤشرات الممكنة:
- حد أدنى من عدد المشغّلين المتحكمين بشكل مستقل.
- حدود الرهان المحتفظ به من قبل كيانات مترابطة.
- أهداف تنوع المواقع جغرافيًا ومزودات السحابة.
- لوحات معلومات عامة لأداء المدققين.
- آلية تحدّي مُختبرة وفعالة.
- شروط تجريد/اقتطاع واضحة.
- التحويل عند الفشل للبوابة موثق.
- سياسات القبول والإزالة المنشورة.
- مراجعة مستقلة للبرمجيات.
- تقليل سلطة مؤسسة نيوتن في الترقيات.
- عملية تسمح للمشغّلين المؤهلين بالانضمام دون تفاوض خاص.
- جدول زمني لمراجعة صلاحيات الطوارئ المتبقية.
لا تضمن هذه الشروط لا مركزية، لكنها تجعل التقدم أسهل في التقييم.
تاريخ مستهدف وحده سيكون أقل فائدة. قد تصل نيوتن إلى ذلك التاريخ مع الحفاظ على نفس بنية السيطرة. ستُظهر المعالم المبنية على نقل السلطة ما إذا كان النظام يتغير فعليًا.
يجب أن تبدأ الشفافية قبل التحقق بلا إذن
لا تحتاج نيوتن إلى الانتظار حتى توجد شبكة مدققين مفتوحة قبل نشر معلومات ذات معنى.
أثناء مرحلة السماح/التخويل، يمكنها توفير سجل مشغّلين عام يتضمن هوية كل مشارك وحصته ومنطقته في البنية التحتية ونهج إدارة المفاتيح وسجل أدائه وارتباطاته/اعتماداته الرئيسية.
لن تكون هناك حاجة للإفصاح عن معلومات أمان حساسة. الهدف
#USStrikesIranAfterHormuzShipAttack #SpaceXAnthropicOpenAIIPOsMayTopVCExitsSince2000 #BlackRockBUIDLTops$900MAUMOnAvalanche #US2YTreasuryYieldHitsHighestSince2025
