پایان تله‌های خاموش: درون انقلاب ثبت لاگ کنیستر رایانه اینترنتی

یکی از دردناک‌ترین تجربه‌ها برای توسعه‌دهندگان وب۳ (Web3) در رایانه اینترنتی (ICP)، به طور تاریخی «تله خاموش» (silent trap) بوده است. از آنجا که رایانه اینترنتی قراردادهای هوشمند را درون کنیسترهای ایزوله‌شده‌ی وب‌اسمبلی (Wasm) اجرا می‌کند، هرگونه خطای بحرانی زمان اجرا (panic)، خطای کمبود حافظه یا خرابی (یک «تله» یا همان trap) باعث بازگشت کامل وضعیت (state rollback) به حالت قبل می‌شود. اگرچه این امر از یکپارچگی وضعیت محافظت می‌کند، اما ردپای تشخیصی را نیز از بین می‌برد. در شبکه اصلی (mainnet)، دیباگ کردن عملیات‌های ناهمگام مانند ضربان‌های قلب (heartbeats) یا تایمرهای تحریک‌شده توسط سیستم تقریباً غیرممکن بود، زیرا هیچ اثری از خود در رپلیکا (replica) باقی نمی‌گذاشتند.

راه‌اندازی لاگ‌گیری کنیستر (Canister Logging) در زیرشبکه‌های رایانه اینترنتی، این پارادایم را برای همیشه تغییر می‌دهد. قابلیت لاگ‌گیری کنیستر که مستقیماً در محیط اجرای رپلیکا تعبیه شده است، یک لایه تشخیصی مجازی و مدیریت‌شده توسط سیستم را معرفی می‌کند.

چگونه لایه لاگ‌گیری از بازگشت وضعیت (Rollbacks) عبور می‌کند

به طور سنتی، کتابخانه‌های لاگ‌گیری که درون کنیسترها نوشته می‌شدند هنگام بروز خطاهای بحرانی (panics) با شکست مواجه می‌شدند، زیرا مکانیزم بازگشت وضعیت (rollback)، لاگ‌ها را نیز همراه با وضعیت به حالت قبل برمی‌گرداند. سیستم جدید لاگ‌گیری در سطح سیستم، این محدودیت بازگشت وضعیت را دور می‌زند.

هنگامی که یک کنیستر تابع ic0.debug_print را فرامی‌خواند یا دچار تله زمان اجرا (runtime trap) می‌شود، محیط اجرا خروجی تشخیصی را رهگیری کرده و آن را مستقیماً در یک بافر امن و مدیریت‌شده توسط سیستم می‌نویسد.

این بافر لاگ:

• تا ۴ کیلوبایت (4 KiB) از آخرین ورودی‌ها و تله‌های بحرانی (panic traps) را نگه می‌دارد.
• در طول ارتقای کنیستر حفظ می‌شود و به توسعه‌دهندگان اجازه می‌دهد پس از استقرار کد جدید، داده‌های تشخیصی را بررسی کنند.
• فقط در حین نصب مجدد تمیز (clean re-installation) یا حذف کامل، به طور خودکار پاک می‌شود.

ایجاد تعادل بین قابلیت حسابرسی و امنیت با ویژگی log_visibility

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

type log_visibility = variant {
  controllers;
  public;
  allowed_viewers : vec principal;
};

به طور پیش‌فرض، میزان دید یا همان قابلیت رویت روی controllers تنظیم شده است. با این حال، اضافه شدن allowed_viewers یک برد بزرگ برای حاکمیت غیرمتمرکز (decentralized governance) محسوب می‌شود. برای کنیسترهای تحت مدیریت سازمان‌های خودگردان غیرمتمرکز (SNS DAO)، توسعه‌دهندگان می‌توانند مجوزهای مشاهده لاگ را به حداکثر ده آدرس پرینسیپال (principal) خاص (مانند حسابرسان امنیتی منتخب یا اعضای کمیته اضطراری) اعطا کنند. این کار دسترسی عمیق تشخیصی را بدون افشای ساختار داخلی زیرساخت برای عموم امکان‌پذیر می‌سازد.

فراخوانی لاگ‌ها بدون تهدید تخلیه سایکل (Cycle Drains)

برای واکشی این لاگ‌ها، توسعه‌دهندگان کنیستر مدیریت مجازی (aaaaa-aa) را از طریق اندپوینت fetch_canister_logs فراخوانی می‌کنند، یا به سادگی دستور به‌روزشده‌ی dfx canister logs <canister-id> را اجرا می‌کنند.

از آنجا که بازیابی لاگ به عنوان یک فراخوانی کوئری غیرتکراری (non-replicated query call) پردازش می‌شود، به صورت محلی روی یک گره (node) واحد اجرا شده و اجماع (consensus) را دور می‌زند. در نتیجه، واکشی لاگ‌ها هیچ سایکلی (cycles) مصرف نمی‌کند. این تصمیم در طراحی، یک بردار حمله خطرناک را از بین می‌برد: عوامل مخرب نمی‌توانند با تحریک مداوم و کوئری گرفتن از حجم عظیمی از داده‌های لاگ، حملات محروم‌سازی از سرویس (DDoS) تخلیه سایکل را راه‌اندازی کنند.

با فعال‌سازی لاگ‌گیری کنیستر و ردیابی خودکار استک (stack traces) در شبکه اصلی، توسعه‌دهندگان رایانه اینترنتی (ICP) بالاخره به ابزارهای نظارتی در سطح سازمانی که برای ساخت، نظارت و مقیاس‌پذیری برنامه‌های غیرمتمرکز (dApps) کاملاً مستقل مورد نیاز است، دسترسی دارند.