بعد إجراء بحث حول كيفية معالجة البروتوكول اللامركزي لخطر التحديثات الحية أثناء وقت التشغيل، توصلت إلى أن أكثر الثغرات خطورة في العقود الذكية اللامركزية هي إمكانية قيام طرف ثالث بتعديل القواعد النشطة عبر مفاتيح الحوكمة. إليك كيف يعالج بروتوكول Newton هذه المشكلة تحديدًا بالتصميم بطريقة لا تتطلب إعادة كتابة البنية بالكامل لنظام الخادم الخلفي (backend) الخاص بك.
من بين التحديات الأساسية المرتبطة بأتمتة البلوك تشين غير المصرّح بها هي القدرة على تحديث قواعد اللعبة مع مرور الوقت. إذا كان عقد الحوكمة أو حساب متعدد التواقيع المسؤول عن اتخاذ هذه القرارات يتصرف بسوء نية ويعدّل القيود أثناء وقت التشغيل، فإن ذلك يخلق «متجه تحديث السياسة» لهجوم.
على سبيل المثال، يمكن لمهاجم لديه وصول إلى مثل هذا الحساب زيادة حد الإنفاق مباشرة قبل تمرير معاملة، أو تخفيف بعض إجراءات الامتثال. يخفف بروتوكول نيوتن من اتجاه الهجوم هذا من خلال اشتراط أن تُوقَّع انتقالات الحالة بإثبات تشفيري يربطها بجذر حالة تاريخي محدد.
لفهم سبب ضرورة هذا النهج، يجب أن نتحدث عن المشكلة التي يهدف نيوتن إلى حلها. أي نظام يتطلب من مشغّل تحديث السياسات في الوقت الفعلي يواجه تحديًا خطيرًا من ناحية قابلية التوسع بسبب العدد الهائل من حالات انتقال ممكنة. على سبيل المثال، في كل مرة يريد فيها المشغّل تغيير شيء ما، يجب على النظام التأكد من أن صحة الحالة الجديدة تقع ضمن قيود جميع حالات سابقة. وقد يكون ذلك مرهقًا للغاية على الشبكة إذا احتوى الاقتراح على سلسلة من الحالات الطرفية المعقدة. ويمكن تجنب هذا العبء في نيوتن عبر استخدام جذر حالة، حيث يتم الالتزام بكل تغيير في السياسة كعملية ذرية واحدة يتم التحقق منها من قبل الشبكة عبر فحص منطق الزمن الخطي (Linear Temporal Logic). تتمثل الفكرة في أنه بدلًا من مطالبة الشبكة بالتحقق مما إذا كان كود جديد صالحًا أم لا، تطلب منها التحقق من مجموعة محددة من التغييرات باعتبارها امتدادًا منطقيًا للحالة الحالية ذات الجذر.
عندما يتم بث تغيير قاعدة أو اقتراح تحديث سياسة إلى الشبكة، تبدأ عقد المُصدِّق عملية تجميع التواقيع، ما يسمح لها بتحديد ما إذا كانت هناك دعماً كافياً لاعتماد القواعد الجديدة. إذا كان الانتقال صالحًا، فهذا يعني أن غالبية المُصدِّقين يوافقون على التغيير وسيتم إضافته إلى سلسلة الكتل كجذر حالة جديد في أقرب فرصة متاحة.
من ناحية أخرى، إذا كانت عقد المُصدِّق غير قادرة على تنفيذ الانتقال بنجاح بسبب عدم كفاية التوقيعات أو وجود تناقضات رياضية مع جذر الحالة الحالي، فسيتم التراجع عن التحديث. وفعليًا، أي تغييرات في عقد النظام لا تجتاز مراجعة تشفيرية صارمة تُرفَض فورًا، مما يمنع هجمات «الحَوْكمة السريعة» ذات النية السيئة التي تسعى إلى تخفيف القيود مؤقتًا ثم قفلها مرة أخرى في مكانها.
من خلال اشتراط أن يتضمن كل تغيير في عقد النظام انتقالًا موقَّعًا من جذر الحالة الحالي، يمنع نيوتن الهجمات التي تسعى إلى تقويض نزاهة أنظمة سلاسل الكتل على السلسلة غير المرخصة. في هذا النموذج، لا يتعين على المطورين بناء تدابير أمان متقدمة مباشرة داخل العقد الأساسي لضمان موثوقية مقترحات الحوكمة. بدلًا من ذلك، يمكنهم التركيز على بناء عقود ذكية فعّالة وحتمية، بينما تُدار القيود الأكثر تقلبًا بشكل منفصل في صورة تحديثات للسياسات.
