مرز سازگاری: ماتریس Chain Fusion در ICP به چک‌لیست یکپارچه‌سازی تبدیل می‌شود

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

این چارچوب برای سازندگان اهمیت دارد. جدول مستندات، یکپارچه‌سازی مستقیم بیت‌کوین، دسترسی به شبکه‌های EVM از طریق EVM RPC canister، دسترسی به سولانا از طریق SOL RPC canister و شبکه‌هایی مانند Aptos، Avalanche، Cardano، Cosmos، NEAR، Polkadot، Stellar، TON و XRP از طریق HTTPS outcalls را فهرست می‌کند. ستون امضا نیز مشخص می‌کند که هر شبکه با امضای آستانه‌ای ECDSA، Schnorr روی secp256k1 یا Ed25519 سازگار است.

نتیجه عملی این است که «پشتیبانی Chain Fusion» به معنای یکسان بودن روش اتصال همه شبکه‌ها نیست. بیت‌کوین از آداپتر بومی ICP استفاده می‌کند و APIهای سطح پروتکل برای UTXOها و ارسال تراکنش ارائه می‌دهد. اتریوم و شبکه‌های سازگار با آن از فراخوانی‌های RPC نوع‌دار استفاده می‌کنند که درخواست را به چند ارائه‌دهنده می‌فرستد. شبکه‌های دیگر معمولاً به یکپارچه‌سازی مبتنی بر HTTPS outcall و سریال‌سازی اختصاصی تراکنش نیاز دارند.

بنابراین جدول طرح‌های امضا، یک ابزار مناسب برای طراحی اولیه است. هر تیم می‌تواند پیش از انتخاب معماری، سه سؤال بپرسد:

۱. آیا طرح امضای آستانه‌ای موجود در ICP می‌تواند امضایی تولید کند که شبکه مقصد می‌پذیرد؟ ۲. آیا برای شبکه مقصد آداپتر بومی، system canister نوع‌دار یا فقط مسیر RPC سفارشی وجود دارد؟ ۳. آیا ارائه‌دهندگان RPC انتخاب‌شده با مدل HTTPS outcall در ICP و از طریق IPv6 قابل دسترسی هستند؟

مستندات همچنین به Chain Fusion Signer قابل استفاده مجدد اشاره می‌کند. این سرویس APIهای امضای آستانه‌ای را در اختیار برنامه‌های وب و کاربران خط فرمان می‌گذارد و هزینه را از طریق cycles و فرایند approval مبتنی بر ICRC-2 دریافت می‌کند. برای برنامه‌های ساده، این روش می‌تواند نیاز به ساخت یک canister امضاکننده اختصاصی را کاهش دهد؛ اما مسئولیت استخراج صحیح آدرس، کدنویسی تراکنش، مدیریت کارمزد، nonce یا UTXO و منطق تأیید نهایی همچنان بر عهده برنامه است.

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

یک caveat مهم این است که جدول شبکه‌های پشتیبانی‌شده، راهنمای یکپارچه‌سازی است و تضمین نمی‌کند که برای همه شبکه‌های فهرست‌شده، آداپتر تولیدی و فعال وجود داشته باشد. خود مستندات تصریح می‌کند که این فهرست جامع نیست و یکپارچه‌سازی به وجود ارائه‌دهندگان RPC قابل دسترسی از طریق IPv6 وابسته است. بنابراین سازندگان باید این جدول را فقط به‌عنوان فیلتر سازگاری در نظر بگیرند و پیش از انتقال ارزش، APIهای فعلی شبکه مقصد، رفتار ارائه‌دهندگان، قالب تراکنش و وضعیت عملیاتی را جداگانه بررسی کنند.

برای توسعه‌دهندگان ICP، تغییر ماندگار همین است: Chain Fusion به‌عنوان مجموعه‌ای از مرزهای قابل ترکیب مستند می‌شود، نه فهرستی از پل‌ها. سریع‌ترین مسیر برای اتصال یک شبکه جدید از بررسی رمزنگاری و دسترسی شبکه آغاز می‌شود و سپس به کوچک‌ترین چرخه قابل اتکای خواندن، امضا، انتشار و تأیید تراکنش مورد نیاز شبکه مقصد می‌رسد.