نقشه‌راه سازندگان ICP در حال تبدیل‌شدن به یک پشتهٔ اجرایی است

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

مشخص‌ترین ایدهٔ مطرح‌شده در این بحث، یک کانستر عامل هوش مصنوعی پشت Internet Identity است. این عامل می‌تواند پروژه‌ها را برنامه‌ریزی کند، فایل‌ها را ویرایش کند، از طریق HTTPS outcall به یک مدل خارجی متصل شود، تاریخچه و آرتیفکت‌های پروژه را در کانستر دیگری ذخیره کند و در نهایت کد Motoko یا Rust را کامپایل و به‌عنوان یک برنامهٔ ICP مستقر کند. این نمودار یک پیشنهاد جامعهٔ توسعه‌دهندگان است، نه نقشه‌راه اعلام‌شدهٔ محصول.

بااین‌حال، اجزای این چشم‌انداز در پلتفرم فعلی بیشتر دیده می‌شوند. کانسترهای ICP می‌توانند بدون واسطهٔ اوراکل به وب‌سرورهای عمومی از طریق HTTPS outcall درخواست بفرستند. درخواست‌های replicated از اجماع subnet استفاده می‌کنند؛ در مقابل، حالت‌های non-replicated و flexible به توسعه‌دهنده اجازه می‌دهند بسته به کاربرد، میان میزان replication، هزینه، فشار محدودیت نرخ و تمامیت پاسخ انتخاب کند. در حالت flexible، پاسخ‌های مستقل به کانستر برگردانده می‌شوند تا خود برنامه آن‌ها را ارزیابی کند و این حالت از قیمت‌گذاری پرداخت به‌اندازهٔ مصرف استفاده می‌کند. جزئیات در مستندات HTTPS outcalls آمده است.

این موضوع برای برنامه‌های هوش مصنوعی مهم است، چون یک کانستر عامل لازم نیست هر سرویس خارجی را از طریق یک پل اختصاصی و سفارشی صدا بزند. بااین‌حال، توسعه‌دهنده باید محدودیت دسترسی به endpointهای عمومی، سقف پاسخ، timeout، هزینهٔ cycles، افشای کلیدهای API و تفاوت میان پاسخ‌های مبتنی بر اجماع و پاسخ یک replica را مدیریت کند. برای درخواست‌های POST که وضعیت را تغییر می‌دهند نیز idempotency همچنان مسئولیت برنامه است.

بخش ذخیره‌سازی هم به بلوغ رسیده، اما مرزهای طراحی مشخصی دارد. مستندات فعلی ICP، حافظهٔ heap را برای wasm32 برابر ۴ گیگابایت و برای wasm64 برابر ۶ گیگابایت اعلام می‌کنند؛ درحالی‌که stable memory می‌تواند به ۵۰۰ گیگابایت برسد و پس از ارتقا باقی بماند. بنابراین heap باید ناحیهٔ سریع اجرای برنامه تلقی شود، نه جایگزینی برای ذخیره‌سازی امن در برابر ارتقا. سازندهٔ یک فضای کاری عامل هوش مصنوعی باید فایل‌ها، نسخه‌ها و تاریخچه را در ساختارهای پایدار یا کانسترهای ذخیره‌سازی جداگانه قرار دهد، نه اینکه روی هدف تأییدنشدهٔ heap سی‌ودوگیگابایتی حساب کند.

قطعهٔ مفقود، لایهٔ هماهنگ‌سازی است. یک کانستر می‌تواند کانسترهای دیگر را ایجاد و مدیریت کند، اما سامانه‌ای حرفه‌ای برای تبدیل «prompt به برنامهٔ مستقرشده» هنوز باید مشخص کند چه کسی اجازهٔ کامپایل کد را دارد، کامپایل در کجا انجام می‌شود، آرتیفکت‌های تولیدشده چگونه راستی‌آزمایی می‌شوند، چه کسی ارتقاها را مجاز می‌کند و استقرارهای ناموفق چگونه rollback می‌شوند. این‌ها به همان اندازه که پرسش فنی هستند، پرسش اعتماد و عملیات نیز هستند.

برداشت قوی‌تر از این بحث همین است: فرصت نزدیک‌مدت سازندگان در ICP شاید کمتر به یک ارتقای بزرگ و نمایشی شبکه وابسته باشد و بیشتر به ترکیب primitiveهای موجود برای ساخت یک کنترل‌پلین توسعهٔ قابل‌راستی‌آزمایی مربوط شود: Internet Identity برای دسترسی، کانسترها برای وضعیت و اجرا، HTTPS outcall برای تعامل خارجیِ محدودشده و controllerها یا حاکمیت صریح برای اختیار استقرار.

این نکتهٔ احتیاطی مهم است: این تاپیک انجمن یک بحث جامعهٔ توسعه‌دهندگان است، نه نقشه‌راه الزام‌آور. اشاره به «Intelligence Gateway»، cloud engineهای تحت کنترل DAO یا heapهای بزرگ‌تر نباید به‌عنوان تعهد عرضه تلقی شود. سیگنال عملی، خود معماری است و این واقعیت که بیشتر اجزای زیربنایی آن هم‌اکنون مستند و قابل استفاده‌اند.