دِلیگیشن وارد حالت فقط‌خواندنی می‌شود: تغییرات مشخصات رابط ICP 0.64 برای امنیت کنیسترها

جدیدترین ورودی مشخصات رابط اینترنت کامپیوتر، تغییر کوچکی اما مهم در مرزهای اعتماد کنیسترها ایجاد می‌کند: اکنون می‌توان برای دِلیگیشن‌های درخواست، مجوز تعیین کرد و کنیسترها نیز می‌توانند برای فراخوانی‌های ورودی بین‌کنیستری حداقل تعداد چرخه مطالبه کنند.

تغییرات نسخه 0.64.0 که تاریخ آن ۶ ژوئیه ۲۰۲۶ ثبت شده، یک فیلد اختیاری permissions به دِلیگیشن‌های درخواست اضافه می‌کند. دِلیگیشنی که با مقدار queries علامت‌گذاری شده باشد برای کوئری‌ها و درخواست‌های read_state پذیرفته می‌شود، اما فراخوانی‌های update دارای چنین دِلیگیشنی رد خواهند شد. رفتار قبلی نیز با مقدار all یا حذف این فیلد همچنان ممکن است.

این تفاوت برای برنامه‌هایی مهم است که به دسترسی خواندن، اما نه اختیار نوشتن، نیاز دارند. داشبورد، سرویس پایش یا حسابرس خودکار می‌تواند اعتبارنامه‌ای دریافت کند که وضعیت را بررسی می‌کند، اما از نظر ساختاری قادر به ارسال فراخوانی update نیست. این قابلیت یک سیستم نقش‌دهی جدید در سطح برنامه نیست؛ بلکه محدودیتی در سطح پروتکل برای نوع درخواست قابل‌ارسال با دِلیگیشن است.

این به‌روزرسانی همچنین minimum_incoming_canister_call_cycles را به تنظیمات کنیستر اضافه می‌کند. اگر این مقدار تنظیم شده باشد، فراخوانی یک کنیستر دیگر که چرخه‌ای کمتر از حد تعیین‌شده همراه داشته باشد، با خطای CANISTER_ERROR رد می‌شود و چرخه‌های پیوست‌شده به فراخواننده بازگردانده می‌شوند. پیام‌های ingress و فراخوانی‌های self-call مشمول این محدودیت نیستند. مرجع کنیستر مدیریتی مقدار پیش‌فرض را صفر اعلام می‌کند؛ یعنی تا زمانی که کنیستر صراحتاً فعالش نکند، حداقلی اعمال نمی‌شود.

کاربرد عملی این قابلیت، انضباط منابع است. یک سرویس عمومی می‌تواند فراخوانی‌هایی را که حداقل هزینه اعلام‌شده را تأمین نمی‌کنند رد کند و مسیرهای مبهمِ کمبود بودجه را کاهش دهد. این ویژگی جایگزین احراز هویت، محدودسازی نرخ یا اعتبارسنجی ورودی نیست؛ فراخواننده‌ای که حد چرخه را رعایت می‌کند همچنان ممکن است غیرمجاز یا سوءاستفاده‌گر باشد.

برای سازندگان، این تغییر یک بازبینی دولایه پیشنهاد می‌کند. ابتدا هر اعتبارنامه دِلیگیشن را فقط‌خواندنی یا کاملاً مجاز طبقه‌بندی کنید و محدودترین مجوز لازم را به کار ببرید. سپس برای هر نقطه پایانی بین‌کنیستری عمومی بررسی کنید که آیا حداقل چرخه لازم است یا نه و رفتار بازپرداخت و خطا را در فراخواننده‌ها آزمایش کنید.

نکته ایمنی مهم این است که changelog نسخه 0.64.0 تغییرات رابط را مستند می‌کند، اما به‌تنهایی ثابت نمی‌کند که همه زیرشبکه‌ها، SDKها یا کتابخانه‌های کلاینت همین حالا از آن پشتیبانی می‌کنند. پیش از اتکا به این کنترل‌ها در محیط تولید، نسخه مستقر زیرشبکه هدف و کتابخانه‌های مورد استفاده برنامه را بررسی کنید. پیاده‌سازی اصلی ICP نیز در مخزن عمومی ic متعلق به DFINITY نگهداری می‌شود و این مخزن روندهای راستی‌آزمایی انتشارها را توضیح می‌دهد.

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