موتورهای ابری، تقسیم آنلاین زیرشبکه و فراخوانی‌های HTTPS با پرداخت به‌ازای مصرف: کد ICP از چه چیزی خبر می‌دهد؟

موتورهای ابری، تقسیم آنلاین زیرشبکه و فراخوانی‌های HTTPS با پرداخت به‌ازای مصرف: کد ICP از چه چیزی خبر می‌دهد؟

صفحه‌های نقشهٔ راه می‌گویند یک تیم امیدوار است چه چیزی عرضه کند. لاگ کامیت‌ها می‌گوید واقعاً چه چیزی در حال ساخته شدن است. ما حدود ۱٬۵۰۰ کامیتی را که بین اواخر مارس تا ۴ سپتامبر ۲۰۲۶ روی شاخهٔ master مخزن dfinity/ic نشسته‌اند خواندیم، آن‌ها را با پیشنهادهای NNS و رشته‌های فوروم که به آن‌ها ارجاع می‌دهند تطبیق دادیم و تغییراتی را بیرون کشیدیم که در ماه‌های آینده بیشترین اهمیت را برای سازندگان روی رایانهٔ اینترنتی خواهند داشت.

شش جریان اصلی به چشم می‌آید: موتورهای ابری (Cloud Engines) و قطار ارتقای NNS آن‌ها، تقسیم آنلاین زیرشبکه، فراخوانی‌های HTTPS انعطاف‌پذیر با قیمت‌گذاری پرداخت به‌ازای مصرف، مدل تازهٔ واریز برای ckETH و ckERC20، مجموعه‌ای از قابلیت‌های کنیستر مدیریت، و فشار «مأموریت ۷۰» بر پاداش‌ها. بیشترشان هنوز روی شبکهٔ اصلی نیستند. اما همهٔ آن‌ها در کدی هستند که همین امروز می‌توانید بخوانید.

۱. موتورهای ابری صاحب یک صفحهٔ کنترل واقعی می‌شوند

طرح مأموریت ۷۰، موتورهای ابری را زیرشبکه‌های خصوصی‌ای توصیف می‌کند که یک تیم از میان گره‌های شبکه و از طریق پیکربندی‌کننده‌ای که NNS میزبانی می‌کند می‌سازد؛ ۸۰ درصد درآمد موتور به گره‌ها می‌رسد و ۲۰ درصد سوزانده می‌شود. رجیستری حالا دقیقاً برای همین یک نوع زیرشبکه دارد. فایل rs/protobuf/def/registry/subnet/v1/subnet.proto مقدار SUBNET_TYPE_CLOUD_ENGINE = 5 را تعریف می‌کند و آن را «زیرشبکه‌های خصوصی قابل‌پیکربندی و مختص یک برنامه، زیر نظر NNS و قواعد ایمنی آن» می‌نامد.

بخش رو به کاربر، یک کنیستر کنترل‌کنندهٔ موتور تازه است (rs/engine_controller، با شناسهٔ si2b5-pyaaa-aaaaa-aaaja-cai روی شبکهٔ اصلی) که رجیستری اکنون در کنار حاکمیت NNS به آن اجازهٔ ساخت و حذف زیرشبکه می‌دهد. رابط Candid آن کوچک و گویاست:

service : (opt EngineControllerInitArgs) -> {
  create_engine : (CreateEngineArgs) -> (CreateEngineResult);
  delete_engine : (DeleteEngineArgs) -> (Result);
  update_subnet : (UpdateSubnetPayload) -> (Result);
  change_subnet_membership : (ChangeSubnetMembershipPayload) -> (Result);
  deploy_guestos_to_all_subnet_nodes : (DeployGuestosToAllSubnetNodesPayload) -> (Result);
}

create_engine فهرستی از شناسه‌های گره (حداقل چهار گره اجباری است)، پرینسیپال‌هایی که مدیر زیرشبکه می‌شوند و یک نسخهٔ replica می‌گیرد. update_subnet کل payload رجیستری را جلو می‌فرستد، اما وقتی فراخوان کنترل‌کنندهٔ موتور باشد، رجیستری هر چیزی جز subnet_id و subnet_admins را رد می‌کند. امروز فقط یک پرینسیپال ثابت اجازهٔ فراخوانی این کنیستر را دارد و موتورهای تازه عمداً از DKG یک زیرشبکهٔ غیر-NNS راه‌اندازی می‌شوند تا NNS هرگز والد یک موتور خصوصی نباشد.

هوشمندانه‌ترین بخش، شیوهٔ ارتقای موتورهاست. یک موتور می‌تواند replica_version_id را در SubnetRecord خود خالی بگذارد، که یعنی «قطار استاندارد را دنبال کن». این قطار یک رکورد تازه در رجیستری است به نام StandardEngineReplicaVersionRecord با سه فیلد: new_replica_version_id، old_replica_version_id و deployment_progress، عددی اعشاری بین ۰ و ۱. هر موتور یک «اولویت ارتقا» محاسبه می‌کند: رشتهٔ upgrade priority، شناسهٔ نسخهٔ جدید و شناسهٔ زیرشبکهٔ خودش را با SHA-256 هش می‌کند، هشت بایت اول را به‌صورت یک عدد صحیح little-endian می‌خواند و بر ۲^۶۴ − ۱ تقسیم می‌کند. موتورهایی که اولویتشان کمتر یا مساوی deployment_progress باشد نسخهٔ جدید را اجرا می‌کنند و بقیه روی نسخهٔ قدیمی می‌مانند. بنابراین بالا بردن progress از ۰٫۱ به ۰٫۵ و سپس ۱٫۰ یک انتشار قناری قطعی روی کل ناوگان است و بازگشت، یعنی صفر کردن آن.

این اهرم از طریق یک نوع پیشنهاد کاملاً تازه در NNS به نام UpdateStandardEngineReplicaVersion (PR شمارهٔ ۱۰۸۸۴ در حاکمیت) در دسترس است، همراه با زیرفرمان متناظر ic-admin propose-to-update-standard-engine-replica-version. کارهای پشتیبان در طول تابستان شامل اجازهٔ ترافیک XNet روی موتورها، باز کردن پراکسی SOCKS گره‌های مرزی API برای آن‌ها، قواعد فایروال برای اجرای ic-gateway به‌عنوان side-car در کنار replica، حذف زیرشبکه در رجیستری و مسیریابی پیام و PocketIC، و محافظی بود که تقسیم یک موتور را در حین استقرار یک نسخه رد می‌کند.

۲. تقسیم زیرشبکه بدون ساعت‌ها توقف

تقسیم یک زیرشبکه سال‌هاست ممکن بوده، اما فقط به‌صورت آفلاین و با یک توقف طولانی برای کپی کردن وضعیت. کار سال ۲۰۲۶ آن را به یک عملیات آنلاین در سطح پروتکل تبدیل می‌کند. جهش رجیستری do_split_subnet ورودی را سخت‌گیرانه اعتبارسنجی می‌کند: فقط زیرشبکه‌های Application و VerifiedApplication قابل تقسیم‌اند، مجموعهٔ گره‌ها باید به‌طور مساوی تقسیم شود، زیرشبکه‌های امضاکننده، اجاره‌ای و متوقف‌شده مستثنا هستند و کل قابلیت پشت پرچم is_subnet_splitting_enabled قرار دارد.

کار جالب را اجماع انجام می‌دهد (PR شمارهٔ ۱۰۹۸۰ و PR شمارهٔ ۱۰۹۳۶). وقتی یک تقسیم در رجیستری زمان‌بندی می‌شود، خلاصهٔ DKG آن بازه را با Scheduled علامت می‌زند. سپس replicaها ساخت بلوک را متوقف می‌کنند و به جای تولید یک بستهٔ catch-up برای ارتفاع خلاصه، هر کدام یک CUP «پس از تقسیم» برای بلوکی ۵۰۰ ارتفاع جلوتر می‌سازند که به‌صورت قطعی برای زیرشبکه‌ای که پس از تقسیم به آن تعلق خواهند داشت محاسبه می‌شود. دو مجموعه سهم CUP روی همان شبکهٔ همتا‌به‌همتا می‌چرخند؛ هر طرف سهم‌هایی را که با بلوک پس از تقسیم و هش وضعیت خودش می‌خواند تأیید و سهم‌های طرف دیگر را رد می‌کند. replicaهای زیرشبکهٔ مقصد تا زمانی که orchestrator این CUP از نوع PostSplit را ببیند و آن‌ها را با شناسهٔ زیرشبکهٔ جدید راه‌اندازی مجدد کند متوقف می‌مانند.

دو افزودهٔ کوچک‌تر کار را کامل می‌کنند. یک پرچم cooling_down روی SubnetRecord و SubnetTopology زیرشبکه را ساکت می‌کند: هیچ ingress پذیرفته نمی‌شود، چیزی به آن یا از آن مسیریابی نمی‌شود و بازپرداخت‌ها به جای گم شدن نگه داشته می‌شوند تا جریان‌ها پیش از یک تقسیم یا ادغام خالی شوند. و یک نشانگر subnet_merged در SystemMetadata نشان می‌دهد ادغام‌ها هم در همین مسیرند. برای نویسندگان کنیستر در سطح API چیزی عوض نمی‌شود، اما زیرشبکه‌ای که امروز روی آن مستقر می‌شوید ممکن است فردا دو زیرشبکه باشد؛ با یک مکث کوتاه به جای چند ساعت قطعی.

۳. فراخوانی‌های HTTPS انعطاف‌پذیر، حالا با قیمت‌گذاری پرداخت به‌ازای مصرف

در ۲ سپتامبر پرچم FLEXIBLE_HTTP_REQUESTS_FEATURE در rs/config/src/execution_environment.rs به Enabled تغییر کرد (PR شمارهٔ ۱۱۳۹۹). این پرچم سه کار می‌کند: فراخوانی‌های کاملاً replicated و non-replicated اکنون می‌توانند نسخهٔ قیمت‌گذاری پرداخت به‌ازای مصرف را انتخاب کنند، فراخوانی‌های انعطاف‌پذیر روی زیرشبکه‌های پولی عادی در دسترس می‌شوند، و زیرشبکه‌های رایگان و سیستمی به حسابداری پرداخت به‌ازای مصرف می‌روند در حالی که رایگان می‌مانند. این تغییر با نسخهٔ IC OS بعدی که انتخاب شود روی شبکهٔ اصلی می‌نشیند؛ پس پیشنهادهای انتخاب نسخه را دنبال کنید.

شکل درخواست FlexibleCanisterHttpRequestArgs است که به URL، هدرها، بدنه، متد و transform آشنا، یک رکورد replication اضافه می‌کند:

record {
  total_requests : nat32;
  min_responses : nat32;
  max_responses : nat32;
}

یک کنیستر انتخاب می‌کند چند replica درخواست را بفرستند و به چند پاسخ هم‌نظر نیاز دارد. چون این اعداد فقط نسبت به اندازهٔ زیرشبکه معنا دارند، یک API سیستمی تازه به نام ic0_subnet_self_node_count اضافه شده است. نسخهٔ قیمت‌گذاری ۲ (PRICING_VERSION_PAY_AS_YOU_GO) هزینهٔ ثابت قدیمی را با یک کارمزد پایه به‌علاوهٔ بازپرداخت ناهمگام سایکل‌های استفاده‌نشده جایگزین می‌کند؛ درخواستی که بودجه‌اش تمام شود با خطای اختصاصی OutOfCycles شکست می‌خورد. متد PATCH بالاخره مجاز شده و max_response_bytes برای درخواست‌های انعطاف‌پذیر هم اعمال می‌شود. پیش‌نویس مشخصات رابط در pull request شمارهٔ ۲۵۴ مخزن dfinity/developer-docs قرار دارد و PocketIC نسخهٔ ۱۶ همین حالا هم فراخوانی‌های انعطاف‌پذیر و قیمت‌گذاری پرداخت به‌ازای مصرف را مدل می‌کند تا بتوانید پیش از تغییر شبکهٔ اصلی به‌صورت محلی آزمایش کنید.

۴. ckETH و ckERC20 دریافت انتقال ساده را یاد می‌گیرند

امروز واریز ckERC20 یعنی فراخوانی یک قرارداد کمکی با پرینسیپال شما. minter در حال ساختن مسیر دومی است که با یک انتقال ساده از هر صرافی یا کیف پولی کار می‌کند. نقطهٔ پایانی تازهٔ deposit_erc20 برای هر حساب ICP و هر دارایی، یک آدرس اتریوم قطعی از کلید threshold-ECDSA خود minter مشتق می‌کند (PR شمارهٔ ۱۰۶۸۵)، آن را همراه با minimum_deposit_amount برمی‌گرداند و سپس موجودی آدرس را پایش می‌کند. وضعیت پس از تشخیص وجوه از Scanning به AwaitingSweep می‌رود.

جاروب کردن (sweep) از EIP-7702 استفاده می‌کند. آدرس واریز یک مجوز امضا می‌کند که کد خود را به یک قرارداد جاروب‌کننده واگذار می‌کند، minter یک گواهی امضا می‌کند که آدرس را به حساب ICP پیوند می‌زند، و یک آدرس جاروب‌کنندهٔ اختصاصی، با nonce مستقل خودش تا یک جاروب گیرکرده هرگز نتواند برداشتی را به تأخیر بیندازد، یک تراکنش نوع ۴ می‌فرستد که واگذاری را نصب و توکن‌ها را یک‌جا جابه‌جا می‌کند. آخرین کامیت پیش از انتشار این مطلب (PR شمارهٔ ۱۱۴۴۹، ۴ سپتامبر) همین سازوکار را به ETH خامی که در یک آدرس واریز نشسته گسترش می‌دهد. تأمین کارمزد، حداقل‌های هر توکن و یک حالت Sponsored که در آن کس دیگری کارمزد ثبت را می‌پردازد هنوز در حال سیم‌کشی‌اند؛ پس این را یک پیش‌نمایش بدانید نه یک عرضهٔ رسمی.

۵. کنیستر مدیریت: دیدپذیری، متریک‌ها و زیرشبکه‌های بزرگ‌تر

مجموعه‌ای از تغییرات کوچک‌تر به‌زودی در مشخصات رابط ظاهر می‌شوند:

• status_visibility در کنار log_visibility و snapshot_visibility به تنظیمات کنیستر می‌پیوندد، با گزینه‌های controllers، public و allowed_viewers (تا ده پرینسیپال). فراخوانی‌های ردشده کد خطای تازهٔ ۵۴۲ یعنی CanisterStatusAccessDenied را برمی‌گردانند.
• minimum_incoming_canister_call_cycles به یک کنیستر اجازه می‌دهد فراخوانی‌های بین‌کنیستری‌ای را که سایکل کافی ضمیمه نکرده‌اند رد کند، بدون دست زدن به canister_inspect_message.
• subnet_metrics به یک نقطهٔ پایانی کنیستر مدیریت تبدیل می‌شود که block_height، num_canisters، canister_state_bytes، consumed_cycles_total و update_transactions_total را برمی‌گرداند؛ همان اعدادی که read_state زیر مسیر /subnet/<id>/metrics می‌دهد.
• canister_info اکنون یک query است و queryهای ترکیبی می‌توانند متدهای query کنیستر مدیریت را فراخوانی کنند.
• حداکثر تعداد کنیستر در هر زیرشبکه به ۲۵۰٬۰۰۰ می‌رسد (رشتهٔ فوروم ۷۴۸۶۲)، کنیسترها می‌توانند به جای ۲۰، ۳۲ متغیر محیطی داشته باشند، زمان ایجاد در درخت وضعیت نمایان می‌شود و fetch_canister_logs با حافظهٔ لاگ تازه در حالت replicated کار می‌کند.
• محدودیت‌های query هر زیرشبکه اکنون پیکربندی رجیستری هستند نه ثابت‌های زمان کامپایل؛ همین است که به یک موتور اجازه می‌دهد بودجهٔ query بزرگ‌تری برای خودش بخرد.

۶. SEV همه‌جا، پاداش‌ها زیر فشار

رایانش محرمانه از آزمایش به یک ناوردای ثابت تبدیل شد. یک بررسی رجیستری اکنون هر جهشی را که یک زیرشبکهٔ SEV را روی نسخه‌ای از GuestOS بدون guest_launch_measurements بگذارد رد می‌کند (PR شمارهٔ ۱۱۰۵۷)، دست‌دهی گواهی سیاست اشکال‌زدایی را در کلیدهای مشتق‌شده ترکیب می‌کند و سروری را که صرفاً گواهی مشتری را آینه کند رد می‌کند، و Bazel می‌تواند تصاویر بازیابی SEV بسازد. پیشنهاد ۱۴۲۷۴۳ دومین زیرشبکهٔ SEV را ساخت؛ پس انتظار داشته باشید الزام اندازه‌گیری برای زیرشبکه‌های تازه به پیش‌فرض تبدیل شود.

در سمت اقتصاد، کد رک و بی‌پرده است. طرح NNS شمارهٔ ۱۴۲۷۲۴ با عنوان «پیگیری استانداردهای ارائه‌دهندگان گره، آمادگی پاسخ به رخداد» در کنیستر پاداش گره‌ها به شکل final = base * performance_multiplier * 0.5 برای ارائه‌دهندگانی که در هر دو آزمون پاسخ به رخداد مردود شده‌اند پیاده شده، در بازه‌ای ثابت از ۱۵ ژوئیه تا ۱۵ اکتبر ۲۰۲۶، و گروه دومی هم در پایان ژوئیه اضافه شد. این تغییر بر تصویب مأموریت ۷۰ سوار است که انتشار سالانه را از ۹٫۷۲ درصد به حدود ۲٫۹۲ درصد تا پایان سال کاهش می‌دهد. حاکمیت گزینه‌های ارتقا برای پیشنهادهای InstallCode و فیلد reserved_cycles_limit برای UpdateCanisterSettings را به دست آورد، و دو طرح اجتماعی که ارزش دنبال کردن دارند در فوروم بازند: یکی برای بررسی همکاری فنی با Bittensor و دیگری برای احیای SNS-1.

این برای سازندگان چه معنایی دارد

• همین حالا برای بودجهٔ فراخوانی‌ها طراحی کنید. تصمیم بگیرید هر فراخوانی خارجی واقعاً به چند replica نیاز دارد؛ خواندن با یک replica به‌علاوهٔ حد نصاب دو یا سه replica برای هر چیزی که وضعیت را تغییر می‌دهد، پس از رسیدن پرداخت به‌ازای مصرف به شبکهٔ اصلی، بسیار ارزان‌تر از replication کامل امروز خواهد بود.
• فرض کنید زیرشبکهٔ شما می‌تواند جابه‌جا شود. تقسیم آنلاین شناسه‌ها و وضعیت کنیسترها را حفظ می‌کند، اما یک زیرشبکهٔ cooling_down مدتی ingress را متوقف می‌کند؛ کلاینت‌ها را طوری بنویسید که به‌صورت idempotent دوباره تلاش کنند.
• تنظیمات کنیسترتان را بازبینی کنید. پیش‌فرض status_visibility روی controllers است تا چیزی تصادفی نشت نکند، اما داشبوردهای عمومی و ابزارهای پایش public یا فهرست allowed_viewers می‌خواهند، و minimum_incoming_canister_call_cycles دفاعی آسان در برابر هرزنامهٔ تخلیهٔ سایکل است.
• در برابر PocketIC نسخهٔ ۱۶ آزمایش کنید. این نسخه فراخوانی‌های انعطاف‌پذیر، قیمت‌گذاری پرداخت به‌ازای مصرف و حذف زیرشبکه را می‌فهمد و ارزان‌ترین راه برای فهمیدن رفتار کدتان پیش از آن است که یک پیشنهاد انتخاب IC OS آن را واقعی کند.