ارتقای رجیستری ICP آمادگی Chain Fusion را به مسئله‌ای درباره ترتیب ارتقا تبدیل می‌کند

جدیدترین پروپوزال Registry Canister اینترنت کامپیوتر، بیش از آن‌که یک انتشار تک‌قابلیتی باشد، یک ارتقای هماهنگ‌کننده برای لایه کنترل شبکه است.

پروپوزال ۱۴۴۱۹۹ ارتقای Registry Canister به commit 98c898f را پیشنهاد می‌کند. این commit تغییراتی را کنار هم می‌گذارد که مستقیماً برای Chain Fusion اهمیت دارند—به‌ویژه افزودن گزینه secp256r1 به پیکربندی کلیدهای زنجیره‌ای ECDSA—و هم‌زمان برای split کردن subnet، استقرار نسخه replica و مهاجرت وضعیت Registry محافظ ایجاد می‌کند.

افزوده رمزنگاری‌شده به‌تنهایی کامل نیست. پروپوزال اجازه می‌دهد create_subnet و update_subnet منحنی NIST P-256 را نام‌گذاری کنند، اما subnet دارای این پیکربندی همچنان باید کلید خود را از طریق پروپوزال‌های جداگانه تولید و فعال کند. برای توسعه‌دهندگان برنامه‌های بین‌زنجیره‌ای، این تفاوت مهم است: پشتیبانی از پیکربندی با در دسترس بودن عملیاتی کلید یکسان نیست.

این ارتقا همچنین endpoint جدید merge_subnets را از طریق یک پروپوزال MergeSubnets اضافه می‌کند. دامنه آن عمداً محدود است: جدول مسیریابی را بازنویسی می‌کند تا بازه‌های canister از یک subnet به subnet دیگر منتقل شوند، در حالی که رکورد هر دو subnet بدون تغییر می‌ماند و subnet مبدأ حذف نمی‌شود. بنابراین این عملیات یک گذار مسیریابی است، نه حذف کامل subnet.

چند تغییر برای جلوگیری از race در لایه کنترل طراحی شده‌اند. اکنون اگر رکورد نسخه replica موتور استاندارد در زمانی که material کلید جدید برای subnet در حال split شدن تولید می‌شود تغییر کند، درخواست split شکست می‌خورد. همچنین وقتی subnet یک cloud engine است و نسخه خود را از همان رکورد می‌گیرد، در زمان استقرار نسخه جدید replica، split آن رد می‌شود. این بررسی‌ها خطر ایجاد دو subnet با نسخه‌های runtime ناسازگار پس از تغییر توپولوژی را کاهش می‌دهند.

این commit invariantهای Registry را نیز سخت‌گیرانه‌تر می‌کند. شناسه‌های نسخه GuestOS و HostOS که انتخاب می‌شوند باید توسط نوع‌های نسخه مصرف‌کننده قابل پردازش باشند. رکوردهای catch-up package باید نوع CUP داشته باشند و یک مهاجرت یک‌باره، رکوردهای قدیمی را به Genesis یا Recovery دسته‌بندی می‌کند. CUPهای Genesis دیگر به فیلد height نیاز ندارند، چون ارتفاع آن‌ها همیشه صفر در نظر گرفته می‌شود.

آشکارترین تغییر از نظر عملیاتی، افزایش MAX_CHUNKABLE_ATOMIC_MUTATION_LEN از ۱۰ MiB به ۱۳ MiB است. commit توضیح می‌دهد که در دوره‌ای طولانی‌تر از معمول میان ارتقاها، مهاجرت‌های Registry روی هم جمع شدند و در post_upgrade یک mutation حدوداً ۱۲ مگابایتی برای وضعیت mainnet ساختند. این تغییر افزایش ظرفیت سازوکار ارتقا است، نه افزایش throughput قابل مشاهده برای کاربر؛ و یک درس نگهداری را نشان می‌دهد: مهاجرت‌های به‌تعویق‌افتاده می‌توانند ارتقاهای معمولی را به مسئله اندازه‌گذاری state اتمیک تبدیل کنند.

این پروپوزال در ۲ اکتبر ۲۰۲۶ منتشر شد و release پایه مرتبط IC نیز همان روز منتشر شد، اما خود پروپوزال مرجع اصلی برای بررسی اقدام حاکمیتی و وضعیت اجرای آن است. صفحه پروپوزال و material منبع، ارتقای موردنظر را توضیح می‌دهند؛ این مقاله به‌طور مستقل اجرای ارتقا روی mainnet را اثبات نمی‌کند. همچنین افزودن پشتیبانی secp256r1 به‌تنهایی کلید زنجیره‌ای را تولید یا فعال نمی‌کند و برای آن مرحله، پروپوزال‌های جداگانه لازم است.

برای توسعه‌دهندگان Chain Fusion، نتیجه عملی این است که قابلیت‌های Registry را زیرساختی مرحله‌ای در نظر بگیرند. ابتدا بررسی کنید منحنی مربوط و پیکربندی subnet در دسترس است؛ سپس مطمئن شوید تولید و فعال‌سازی کلید، مسیریابی و وضعیت نسخه replica به‌صورت سازگار پیش رفته‌اند. این commit این گذارها را صریح‌تر می‌کند و برای مهاجرت‌های لازم جهت مدیریت آن‌ها، حاشیه ظرفیت بیشتری در اختیار Registry می‌گذارد.