ICP صاحب لایه‌ای تایپ‌شده برای مشاهده‌پذیری شد: نسخه ۰٫۴۰٫۱ ic-query چه چیزی برای سازندگان تغییر می‌دهد؟

سازندگان Internet Computer پیش از نوشتن منطق برنامه، اغلب باید به پرسش‌های عملیاتی پاسخ دهند: یک کانستر روی کدام subnet قرار دارد؟ نسخه فعلی رجیستری چیست؟ آیا یک دفترکل قابلیت‌های مورد انتظار ICRC را ارائه می‌کند؟ کدام نسخه replica یا رکورد ارائه‌دهنده نود در منابع عمومی قابل مشاهده است؟

پروژه جامعه‌محور ic-query در ۱۵ اوت نسخه ۰٫۴۰٫۱ خود را در crates.io منتشر کرد. هدف اعلام‌شده آن تبدیل پاسخ‌های Internet Computer و شبکه عمومی مرتبط به گزارش‌های تایپ‌شده با منشأ داده مشخص است. این بسته یک کتابخانه Rust دارد و ic-query-cli رابط خط فرمان icq را ارائه می‌کند.

اهمیت این انتشار در آن است که بازرسی شبکه را به یک لایه داده قابل‌استفاده‌مجدد تبدیل می‌کند، نه مجموعه‌ای از فرمان‌های موقتی shell. مستندات پروژه سطوح مختلفی را برای وضعیت تأییدشده IC، داشبورد رسمی IC، CloudEngine، رجیستری و حاکمیت NNS، SNS، دفترکل‌های ICRC و کانسترهای سیستمی فهرست می‌کند. نمونه فرمان‌ها شامل icq ic canister info، icq nns topology summary، icq sns metrics و پرس‌وجوهای موجودی و تحلیل ICRC است.

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

بسته فعلی همچنین یک هسته سازگار با Wasm و وابستگی اختیاری ic-cdk دارد. این موضوع مسیری برای اشتراک‌گذاری مدل‌های گزارش و منطق اعتبارسنجی با برنامه‌های مبتنی بر کانستر نشان می‌دهد، اما ثابت نمی‌کند که همه جریان‌های پرس‌وجوی زنده داخل کانستر اجرا می‌شوند. گفت‌وگوی انجمن در ۱۴ اوت صراحتاً می‌گوید builderهای زنده و قابلیت‌های host به مؤلفه‌های بومی مانند ic-agent، Tokio، Reqwest و cacheهای مبتنی بر فایل متکی هستند و هنوز adapter مشخصی برای runtime کانستر ارائه نشده است.

این مرزبندی، مهم‌ترین نتیجه مهندسی است. تیم‌ها می‌توانند ic-query را به‌عنوان کتابخانه گزارش‌دهی و بازرسی تایپ‌شده، یا icq را در CI و عملیات به کار بگیرند، بدون آنکه تصور کنند این پروژه از هم‌اکنون یک چارچوب دریافت داده درون‌زنجیره‌ای است. منشأ داده و semantics مربوط به cache می‌تواند ابهام ابزارها را کاهش دهد، در حالی که نبود adapter کانستری همچنان حوزه روشنی برای کار آینده است.

یک caveat مهم وجود دارد: ic-query پروژه‌ای جامعه‌محور است و انتشار رسمی DFINITY نیست؛ بنابراین نسخه و سطح قابلیت‌های آن ممکن است به‌سرعت تغییر کند. توسعه‌دهندگان باید نسخه‌ها را pin کنند، مخزن و یادداشت‌های انتشار را بررسی کنند و پیش از قرار دادن آن در اتوماسیون تولید، schema گزارش‌ها را آزمایش کنند.

مسیر کلی برای زیرساخت ICP معنادار است. هرچه شبکه‌ها داده عملیاتی بیشتری عرضه می‌کنند، گلوگاه بیشتر به تفسیر قابل‌اعتماد تبدیل می‌شود: مدل‌های تایپ‌شده، مرزهای تأییدشده، snapshotهای بازتولیدپذیر و رفتار خطایی که داده سالم را بی‌سروصدا با نتیجه ناقص جایگزین نکند. نسخه ۰٫۴۰٫۱ ic-query گامی مشخص در جهت چنین لایه ابزاری است.