SUPERFULL

ألاحظ باستمرار أن قابلية الترقية غالبًا ما تُناقش باعتبارها مشكلة تعاقدية. أجعلني مستندات تكامل العقود الذكية من نيوتن أن أنظر إلى الأمر بطريقة مختلفة: ماذا لو ظل عنوان العقد ثابتًا بينما تتطور منطق التفويض الكامن خلفه؟ @NewtonProtocol $NEWT #Newt في NewtonProtocol، يمكن توجيه PolicyClient موجود إلى سياسة أحدث باستخدام: setPolicyAddress(newPolicy) لكن هذا ليس مجرد تحديث لمؤشر أعمى. عند استدعاء setPolicyAddress()، يتم التحقق من إصدار المصنع الخاص بالسياسة مقابل الحد الأدنى من إصدار وقت التشغيل المتوافق لدى TaskManager. إذا كان الإصدار غير متوافق، فإن التحديث يتراجع بدلًا من إرفاق منطق سياسة غير مدعوم. يمضي تدفق الترحيل أبعد من ذلك: التحقق من التوافق ↓ إعادة نشر بيانات السياسة غير المتوافقة ↓ نشر السياسة عبر أحدث مصنع ↓ تحديث PolicyClient الموجود ↓ التحقق من الترحيل ما لفت انتباهي هو ما لا يتغير. يبقى عنوان PolicyClient كما هو. هذا يعني أنه يمكن أن يظل العميل المواجه للتنفيذ ثابتًا بينما تتطور سياسة التنفيذ وبيانات السياسة المتوافقة. كما تذكر وثائق نيوتن أن روابط الهوية وموافقة المستخدم تظل سليمة لأن عنوان العميل لا يتغير. بالنسبة لي، يخلق ذلك فصلًا معماريًا مثيرًا للاهتمام: هوية عميل ثابتة ≠ منطق تفويض ثابت العميل يوفر الاستمرارية. والسياسة توفر التغيير. يحدد التحقق من التوافق أي تغييرات يمكن إرفاقها بأمان. يبدو ذلك أكثر أهمية من مجرد ميزة “ترقية” بسيطة. أنظمة التفويض تحتاج إلى التطور، لكن التكاملات المبنية حولها أيضًا تحتاج إلى الاستمرارية. السؤال الذي بقي لدي يتعلق بالموافقة: إذا ظل PolicyClient كما هو لكن سياسته تتغير، فماذا يفترض أن يفكر المستخدمون أنهم وافقوا عليه؟ هل الموافقة تتعلق بالعميل نفسه، أم بإصدار السياسة المحدد الكامن خلفه؟ أين يجب أن ترتبط الموافقة؟ #VitalikOutlinesLeanEthereumRoadmap #BrazilCentralBankSaysStablecoinsElectronicMoney #UKFCAPublishesCryptoRegFramework #BitcoinFallsOver50%FromOctoberHigh $LAB $VANRY