اهرم اعتماد HTTP در ICP: یکپارچه‌سازی سریع‌تر با اجماع ضعیف‌تر، به‌صورت انتخابی

کانسترهای Internet Computer می‌توانند از طریق management canister مستقیماً به سرویس‌های عمومی HTTPS درخواست ارسال کنند و برای بسیاری از یکپارچه‌سازی‌های API به سرویس اوراکل جداگانه نیاز نداشته باشند. مستندات فعلی توسعه‌دهندگان یک انتخاب مهم را شفاف کرده‌اند: فراخوانی‌های HTTPS دو حالت replicated و non-replicated دارند.

در حالت replicated، همه replicaهای subnet درخواست را ارسال می‌کنند. پاسخ‌ها با یک تابع transform عادی‌سازی می‌شوند و subnet درباره نتیجه به اجماع می‌رسد. این حالت قوی‌ترین مدل یکپارچگی را حفظ می‌کند، اما ممکن است ترافیک سرویس خارجی را چند برابر کند. مستندات می‌گویند یک subnet معمولی ۱۳ نودی ممکن است ۱۳ درخواست را در چند میلی‌ثانیه ارسال کند؛ وضعیتی که می‌تواند محدودیت نرخ API را فعال کند.

در حالت non-replicated، مقدار is_replicated = false تنظیم می‌شود. فقط یک replica که به‌صورت تصادفی انتخاب شده درخواست را ارسال می‌کند؛ بنابراین ارسال‌های تکراری حذف شده و فشار بر APIهای دارای rate limit کاهش می‌یابد. این حالت برای webhookها، عملیات POST با طراحی دقیق، و endpointهایی مناسب است که پاسخ آن‌ها ورودی حساس و ارزشمند برای اجماع نیست.

این مصالحه بنیادی است، نه صرفاً ظاهری. چون فقط یک replica درخواست را ارسال می‌کند، پاسخ برگشتی با اجماع subnet تأیید نمی‌شود؛ یک replica معیوب یا مخرب از نظر تئوری می‌تواند پاسخ را تغییر دهد. به همین دلیل، اعلام رسمی این قابلیت را آزمایشی توصیف می‌کند و مستندات فعلی توصیه می‌کنند فقط زمانی از آن استفاده شود که توسعه‌دهنده این فرض اعتماد را بپذیرد یا بتواند پاسخ را به‌طور مستقل بررسی کند.

این قابلیت توصیه‌های معمول یکپارچه‌سازی را نیز تغییر می‌دهد. درخواست‌های POST در حالت replicated باید از idempotency key استفاده کنند، چون هر replica ممکن است عملیات را ارسال کند. توسعه‌دهندگان باید مقدار max_response_bytes را دقیق و محدود تعیین کنند، زیرا هزینه چرخه‌ها بر اساس حداکثر اعلام‌شده محاسبه می‌شود، نه فقط تعداد بایت‌های نهایی. اعتبارنامه‌های API که در state کانستر ذخیره می‌شوند برای replicaها قابل مشاهده‌اند؛ بنابراین نگهداری اعتبارنامه‌های حساس به احتیاط بیشتری نیاز دارد.

درس بزرگ‌تر این است که ICP سیاست زیرساخت را در اختیار توسعه‌دهنده برنامه می‌گذارد. فراخوانی خارجی دیگر فقط یک درخواست HTTP نیست؛ بلکه انتخابی میان قدرت اجماع، سازگاری با API، هزینه و اعتماد است. برای فیدهای قیمتی یا تغییرات حساس در state، حالت replicated همچنان پیش‌فرض امن‌تر است. برای اعلان‌های کم‌ریسک و سرویس‌های دارای محدودیت نرخ، حالت non-replicated می‌تواند یک گلوگاه عملی را برطرف کند؛ اما فقط زمانی که برنامه بر اساس تضمین ضعیف‌تر آن طراحی شده باشد.