بحث ابری ICP در اصل بحث پذیرش است

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

قوی‌ترین بخش این پیشنهاد، تشخیص مشکل در رابط پذیرش است. توسعه‌دهندگان از قبل پشته‌هایی مانند Rust، Go، Java، Python، PostgreSQL و Redis را می‌شناسند. وادار کردن تیم‌ها به یادگیری یک مدل اجرایی تازه می‌تواند پیش از تجربه مزایای ICP اصطکاک ایجاد کند. بنابراین نویسنده خواهان پلتفرمی است که نرم‌افزار آشنا را بپذیرد و مزیت تمرکززدایی را به یک مزیت عملیاتی تبدیل کند، نه نخستین مفهومی که توسعه‌دهنده باید یاد بگیرد.

معماری فعلی ICP تفاوت اساسی با ابر متعارف دارد. مستندات رسمی، کانسترها را واحدهای WebAssembly تکثیرشده‌ای توصیف می‌کنند که کد و وضعیت پایدار را در کنار هم نگه می‌دارند، از طریق پیام با یکدیگر ارتباط می‌گیرند و می‌توانند بدون سرور یا CDN خارجی محتوای وب ارائه کنند. این پلتفرم فقط به Motoko محدود نیست: Rust رسماً پشتیبانی می‌شود و CDKهای جامعه برای زبان‌هایی مانند TypeScript و Python نیز وجود دارد. بنابراین بحث صرفاً «Motoko در برابر همه زبان‌های دیگر» نیست؛ مسئله این است که چه مقدار از جریان کاری موجود توسعه‌دهندگان می‌تواند در اطراف مدل کانستری حفظ شود.

مخالفان این دیدگاه استدلال دیگری دارند: ارزش ICP دقیقاً در اجرای تکثیرشده و مقاوم در برابر دست‌کاری و مدل اعتماد آن است؛ چیزی که ارائه‌دهندگان ابری معمولی عرضه نمی‌کنند. تبدیل شبکه به فروشنده‌ای عمومی برای زیرساخت می‌تواند بازار هدف را بزرگ‌تر کند، اما دلیل انتخاب ICP را تضعیف کند. در نتیجه، ظاهر و تجربه‌ای شبیه ابر می‌تواند با معماری ICP سازگار باشد، اما جایگزین کردن خود معماری تمایزی را از بین می‌برد که منتقدان می‌خواهند حفظ شود.

برداشت عملی این است که ICP مجبور نیست فوراً میان «فناوری بیگانه» و «نسخه‌ای از AWS» یکی را انتخاب کند. می‌توان استقرار، پشتیبانی زبانی، مشاهده‌پذیری و میزبانی یک‌کلیکی را به‌عنوان لایه‌های محصولی پیرامون کانسترها توسعه داد. مستندات رسمی هم‌اکنون میزبانی دارایی‌های دارای گواهی و چرخه استقرار از طریق خط فرمان را توضیح می‌دهند؛ پرسش حل‌نشده این است که آیا این قابلیت‌ها برای تیم‌هایی که نمی‌خواهند پیش از عرضه محصول پروتکل را مطالعه کنند، به اندازه کافی آشنا و ساده می‌شوند یا نه.

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