چرخه انتشار سریع‌تر Internet Identity، بازبینی را به بخشی از مدل امنیتی تبدیل می‌کند

Internet Identity فاصله میان تغییر کد و انتشار در محیط تولید را کاهش می‌دهد. تیم این پروژه در اطلاعیه‌ای در انجمن، در ۴ ژوئن ۲۰۲۶، اعلام کرد که قصد دارد از تقریباً یک پیشنهاد انتشار هفتگی به حداکثر دو پیشنهاد برسد: یک پیشنهاد اصلی در روز جمعه و در صورت مناسب‌بودن، یک پیشنهاد ثانویه در دوشنبه یا سه‌شنبه. اگر در بازبینی جامعه مانعی پیدا نشود، رأی‌گیری DFINITY معمولاً پس از آن انجام می‌شود.

جزئیات عملی این برنامه از تیتر آن مهم‌تر است. انتظار می‌رود پیشنهاد اصلی تغییرات بزرگ‌تر را شامل شود، درحالی‌که بازه ثانویه برای قابلیت‌های پشت پرچم، اصلاحات کوچک تجربه کاربری یا تغییرات کم‌ریسک در نظر گرفته شده است. هر پیشنهاد می‌تواند فقط کانستر backend، فقط کانستر frontend یا هر دو را ارتقا دهد. این موضوع انعطاف انتشار را بیشتر می‌کند، اما حالت‌های بیشتری را برای درک و آزمایش در اختیار سازندگان قرار می‌دهد.

این چرخه با تغییرات معماری و سازمانی توضیح‌داده‌شده در همان اطلاعیه ممکن شده است. Internet Identity می‌گوید برنامه‌ها را به تجربه id.ai منتقل کرده، کانسترهای backend و frontend را از هم جدا کرده، بدهی فنی را کاهش داده، توسعه مبتنی بر کمک هوش مصنوعی را پذیرفته و تیم تمام‌وقت خود را به سه مهندس رسانده است. طبق اطلاعیه، این عوامل باعث شده‌اند انتظار چند روز اضافی برای انتشار یک بهبود بررسی‌شده همیشه مفید نباشد.

برای توسعه‌دهندگان ICP، نتیجه عملی این است که اتصال به احراز هویت باید یک وابستگی در حال تغییر تلقی شود، نه نصب یک‌باره یک کتابخانه. راهنمای فعلی توسعه‌دهندگان جدایی backend و frontend در Internet Identity، شناسه‌های کانستر mainnet، استقرار محلی با تنظیم ii: true در icp-cli و مدل principal وابسته به origin را توضیح می‌دهد. این راهنما همچنین هشدار می‌دهد که برنامه‌ها باید امضاکننده ویژگی‌های هویتی، origin، nonce و تازگی داده را بررسی کنند و صرفاً به دلیل امضاشدن یک بسته، آن را قابل اعتماد ندانند.

پس چرخه انتشار سریع‌تر، ارزش یک فهرست بررسی کوچک و تکرارپذیر را افزایش می‌دهد. سازندگان باید محتوای پیشنهادها را دنبال کنند، جریان‌های ورود و بازیابی را در برابر کانستر تحت‌تأثیر آزمایش کنند، مطمئن شوند originهای frontend و تنظیمات alternative origin با استقرارشان سازگار است و پردازش ویژگی‌های تأییدشده را دوباره بررسی کنند. کنترل دسترسی حساس باید در update callها باقی بماند؛ راهنمای امنیتی ICP مشخصاً هشدار می‌دهد که canister_inspect_message توسط یک node اجرا می‌شود و نمی‌تواند تنها مرز کنترل دسترسی باشد.

این محدودیت مهم است: پست انجمن یک برنامه عملیاتی اعلام‌شده را توصیف می‌کند، نه تضمینی که هر هفته دو پیشنهاد منتشر شود. اهمیت فعلی آن این است که این برنامه همچنان به‌صورت عمومی مستند و امروز قابل راستی‌آزمایی است. اگر این روند به‌طور منظم اجرا شود، بازبینی جامعه به بخش پیوسته‌تری از مدل امنیتی Internet Identity تبدیل می‌شود و پایش انتشار را به یک وظیفه معمول نگهداری برای هر برنامه ICP وابسته به آن بدل می‌کند.