قضيت بعض الوقت في قراءة دليل ترقية بروتوكول Newton، وكنت أعود باستمرار إلى تفصيل تنفيذي واحد: تُضاف دائمًا متغيرات التخزين الجديدة إلى مخطط التخزين الحالي بدلًا من إدخالها فيه
يبدو ذلك شبه بديهي
لا أعتقد ذلك
لقد رأيت عقودًا قابلة للترقية تنكسر لأن شخصًا ما قلّل من تقدير تخطيط التخزين. تنجح ترقية الـ proxy، وتبدو الاختبارات جيدة، ثم بعد أسابيع يكتشف شخصٌ ما أن متغيرًا قد تم الكتابة عليه لأن ترتيب التخزين تغيّر. إنها فوضى. ليس من الضروري أن يفشل العقد فورًا. أحيانًا يبدأ فقط بالتصرف بشكل مختلف، وهو ما يصعب تشخيصه بدرجة أكبر بكثير.
يتجنب بروتوكول Newton هذا الفخ من خلال التعامل مع تخطيط التخزين كشيء ينبغي الحفاظ عليه بدلاً من إعادة ترتيبه. يعجبني هذا النهج لأنه يحترم مدى هشاشة البروكسيات القابلة للترقية
تفصيل آخر لفت انتباهي هو علم newtonPolicyClientInitialized. هدفه بسيط: التهيئة اللاحقة للترقية لا يمكن أن تحدث إلا مرة واحدة. كما يوصي بروتوكول Newton باختبار الترقية على نسخة (fork) وباستخدام مؤقت تأخير (timelock) أو محفظة متعددة التوقيع (multisig) عند تنفيذ معاملة التهيئة. لم يبدُ لي ذلك مجرد نصيحة نمطية. لقد بدا كاعتراف بأن الترقية لم تكتمل بعد عند نشر التنفيذ الجديد
تُعدّ التهيئة جزءاً من الترقية
حتى يتم إكمال تلك الخطوة، قد تكون منطقيات التفويض موجودة بالفعل داخل العقد، لكن عميل السياسة ما زال غير متصل بالـ TaskManager الصحيح أو غير مُسند إلى مالك عميل السياسة المقصود. إذا كان أي من القيمتين خاطئاً، فقد يفشل طبقة التفويض حتى لو بدا أن عملية النشر نفسها تمت بنجاح
لهذا أعتقد أن علم التهيئة مرة واحدة مهم
إنه يمنع شخصاً من تشغيل التهيئة مرة أخرى، لكنه لا يحمي من جعل التنفيذ الأول خاطئاً. إذا احتوت الإعدادات الأولية على أخطاء، فإن قفلها خلف علم مرة واحدة لا يصلحها بشكل سحري. بل يجعل التنفيذ الأول واحداً من أكثر اللحظات حساسية في عملية النشر بأكملها
لاحظت أيضاً أن بروتوكول Newton لا يجمد كل الإعدادات بشكل دائم بعد التهيئة. ما زال بإمكان مالك عميل السياسة تحديث إعدادات السياسة، وتغيير عنوان عقد السياسة، ونقل الملكية لاحقاً. في الواقع، أفضّل ذلك على التظاهر بأن الأنظمة لا تحتاج أبداً إلى التطور. تغييرات في البنية التحتية. تغييرات في الحوكمة. تغيّر المتطلبات. التحدي هو التأكد من بقاء تلك الصلاحيات خاضعة بشكل جيد للضبط مع مرور الوقت. إن توافق التخزين يخلق فئة مختلفة تماماً من المخاطر
أمر واحد أقدّره في بروتوكول Newton هو أنه يسمح للفرق بإدخال فرض السياسات دون إعادة بناء تطبيقهم من الصفر. هذا اختيار تصميمي عملي. لكن ترقية البوابة لا تزال يجب أن تحافظ على توافق التخزين تماماً. أدخل متغيراً واحداً في الموضع الخاطئ، وقد تبدو طبقة التفويض سليمة تماماً بينما يتم إتلاف حالة تطبيق غير مرتبطة بشكل صامت تحت السطح
لقد رأيت ما يكفي من الأنظمة القابلة للترقية لأعرف أن هذا ليس مجرد قلق افتراضي
تفصيل آخر لا أعتقد أنه ينبغي إغفاله هو تدفق التنفيذ. إضافة دالة محمية جديدة في Newton لا يعني تلقائياً تأمين دالة أقدم تؤدي الإجراء نفسه. كل مسار يفترض أن يفرض التفويض ما زال يتعين عليه استدعاء validateAttestation أو validateAttestationDirect قبل تشغيل منطق الأعمال المحمي. إذا أغفلت مساراً واحداً، فقد أنشأت ضمانات أمنية غير متسقة دون أن تدرك ذلك
على الأرجح هذا ما وجدته أكثر إثارة للاهتمام في بروتوكول Newton
تفصل البنية NewtonPolicyClient
بدلاً من إجبار المطورين على إعادة تصميم كل شيء حول إطار عمل جديد. أفضّل عادةً هذا النوع من النهج المعياري لأن الأنظمة الكبيرة نادراً ما تُعاد كتابتها من الصفر. إنها تتطور خطوة بخطوة مع كل ترقية
وفي الوقت نفسه. ما زلت أتساءل إن كانت المخاطر تختفي فعلاً
أم أنه ببساطة ينقلها
يجعل بروتوكول Newton دمج التفويض أسهل في العقود القابلة للترقية الموجودة. أرى أن ذلك قيمة كبيرة. لكن هذا أيضاً يعني أن ترقية البوابة، وترحيل التخزين، ونداء التهيئة الأول للغاية تصبح نقاطاً يتم فيها تركيز معظم مخاطر التشغيل فعلياً
لا أرى ذلك ضعفاً في التصميم
أراه كتذكير بأن التصميم الجيد لا يلغي القرارات الصعبة. إنه يجعل تحديدها أسهل عادةً
كل ترقية تغيّر الكود، لكن ليس كل ترقية تعزّز الأمان. بالنسبة لي، يوضح بروتوكول Newton أن تفاصيل التنفيذ الأصغر غالباً ما يكون لها أكبر أثر في بناء عقود ذكية مرنة