نسخه v0.5.1 از Chain Fusion Signer آرگومانهای ارتقا را به بخشی از مرز امنیتی تبدیل میکند
جدیدترین نسخه Chain Fusion Signer شیوه پیشنهاد ارتقا را تغییر میدهد: نوع صریح Upgrade پیکربندی فعلی کنیستر را حفظ میکند و آرگومانهای اولیه را دوباره اعمال نمیکند. برای یک سرویس امضای مشترک، این یک بهبود امنیت عملیاتی است، نه صرفاً جزئیات فرایند انتشار.
مهمترین تغییر نسخه v0.5.1 از Chain Fusion Signer بهسادگی ممکن است نادیده گرفته شود. این نسخه در کنار افزودن متد btc_sign_prehash، پیشنهادهای ارتقا را تغییر میدهد تا از نوع صریح (variant { Upgrade }) استفاده کنند. طبق یادداشت انتشار، نتیجه این است که پیکربندی موجود کنیستر حفظ میشود و آرگومانهای اولیه دوباره اعمال نمیشوند.
این تغییر اهمیت دارد، زیرا Chain Fusion Signer یک کنیستر است که قابلیتهای امضای آستانهای ICP را در اختیار برنامهها و کلاینتهای دیگر میگذارد. پیکربندی آن بخشی از مرز عملیاتی سرویس است. اگر یک ارتقا بهطور تصادفی آرگومانهای قدیمی، ناقص یا متفاوتی را برای مقداردهی اولیه دوباره استفاده کند، نگهداری کد میتواند رفتار زمان اجرا را نیز تغییر دهد.
این تغییر دو موضوع را از هم جدا میکند؛ موضوعاتی که معمولاً اشتباه یکی فرض میشوند: نصب کد جدید و مقداردهی اولیه کنیستر. ارتقا باید Wasm را جایگزین کند و پیکربندی فعال را حفظ کند. اجرای دوباره آرگومانهای اولیه میتواند یک اقدام معمول نگهداری را به تغییری در پیکربندی تبدیل کند، بهویژه زمانی که تنظیمات عملیاتی پس از استقرار اولیه تغییر کرده باشند.
برای سازندگان و اپراتورها، درس عملی این است که مسیر انتشار را بررسی کنند، نه فقط تفاوت کد Rust یا TypeScript را. مشخص کنید اسکریپت استقرار کدام نوع پیشنهاد را ارسال میکند، پیکربندی را پیش و پس از ارتقا ثبت کنید و هش ماژول مستقرشده را بهصورت مستقل بررسی کنید. این نسخه همچنین یک رویه انتشار خودکارتر و پیشنیاز اعتبارنامههای آن را مستند میکند؛ موضوعی که نشان میدهد تحویل قابلبازتولید بخشی از مدل اعتماد امضاکننده است.
همین نسخه متد btc_sign_prehash را نیز اضافه میکند و به فراخواننده اجازه میدهد برای یک digest دلخواه، زیر کلید بیتکوین، امضا درخواست کند. این قابلیت انعطافپذیری API را بیشتر میکند، اما بررسی سریالسازی و هشکردن در سمت برنامه را نیز مهمتر میسازد. این دو تغییر مکمل یکدیگرند: هرچه سطح امضای عمومیتر و انعطافپذیرتر میشود، فرایند ارتقا نیز باید طوری باشد که پیکربندی آن را ناخواسته بازنویسی نکند.
نکته احتیاطی مهم: صفحه GitHub تگ v0.5.1 و یادداشتهای انتشار آن را تأیید میکند، اما بهتنهایی ثابت نمیکند که همه نمونههای production امضاکننده ارتقا یافتهاند. اپراتورها باید پیش از فرضکردن فعال بودن این رفتار، وضعیت استقرار را از طریق سوابق حاکمیتی یا کنیستر مربوط بررسی کنند.
خبرخوان را در ایمیل بگیرید
هر سیگنال تازه، مستقیم از خط تولید. بدون مزاحمت، لغو عضویت در هر زمان.