پرسش اجماع RPC: جایی که Chain Fusion آی‌سی‌پی به لبه ناپایدار سولانا می‌رسد

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

مستندات کنونی Chain Fusion آی‌سی‌پی یک EVM RPC canister نوع‌دار و یک SOL RPC canister اختصاصی را توضیح می‌دهد. درخواست‌ها می‌توانند به چند ارائه‌دهنده مستقل ارسال شوند و نتیجه بر اساس میزان توافق آن‌ها دسته‌بندی شود. این الگو به توسعه‌دهندگان اجازه می‌دهد وضعیت بیرونی را بخوانند، بدون آن‌که هر برنامه یک endpoint متمرکز RPC را درون خود جای دهد.

مخزن SOL RPC canister این طراحی را عملی‌تر نشان می‌دهد. به‌طور پیش‌فرض، هر درخواست سه ارائه‌دهنده متمایز Solana JSON-RPC را پرس‌وجو و پاسخ‌های آن‌ها را تجمیع می‌کند. توسعه‌دهندگان می‌توانند راهبرد اجماع دیگری انتخاب کنند، مثلاً توافق سه ارائه‌دهنده از پنج ارائه‌دهنده را لازم بدانند، یا مجموعه ارائه‌دهندگان خود را معرفی کنند. هزینه درخواست‌ها با cycles پرداخت می‌شود و برای روش‌هایی که client نوع‌دار ندارند، مسیر عمومی JSON request نیز وجود دارد.

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

سرعت سولانا مرز دومی ایجاد می‌کند. مخزن SOL RPC می‌گوید پشتیبانی از getLatestBlockhash از طریق HTTPS outcallهای تکرارشونده دشوار است، زیرا این مقدار تقریباً هر ۴۰۰ میلی‌ثانیه تغییر می‌کند، در حالی که گره‌های subnet برای رسیدن به اجماع به زمان نیاز دارند. گزینه‌های مستندشده استفاده از durable nonce یا دریافت یک slot تازه و سپس واکشی بلوک متناظر است؛ بلوک داده مربوط به blockhash را در خود دارد. این مخزن همچنین هشدار می‌دهد که استقرار محلی می‌تواند تفاوت‌های mainnet را پنهان کند: endpointهای IPv4 و رفتار تک‌replica ممکن است محلی کار کنند، اما شرایط تولید را بازتاب ندهند.

درس عملی برای سازندگان Chain Fusion این است که طراحی را بر اساس ویژگی‌های سازگاری هر روش بیرونی انجام دهند، نه صرفاً بر اساس حضور یک زنجیره در جدول پشتیبانی. خواندن حساب‌هایی که آهسته تغییر می‌کنند، داده‌های finalized و صفحه‌بندی idempotent برای outcallهای تکرارشونده مناسب‌تر از مقادیری هستند که چند بار در ثانیه تغییر می‌کنند. ساخت تراکنش نیز باید تازگی داده، retry، راهبرد nonce و نتیجه ارائه‌دهندگان ناسازگار را صریحاً مدیریت کند.

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

بنابراین زاویه تازه، افزودن یک زنجیره دیگر نیست؛ بلکه واردشدن معنا و محدودیت‌های RPC به مدل امنیتی برنامه است. Chain Fusion می‌تواند مسیر قدرتمندی برای اجرای بین‌زنجیره‌ای در اختیار canisterها بگذارد، اما طراحی‌های ایمن‌تر quorum ارائه‌دهندگان، تازگی زمانی داده و رفتار مختص mainnet را محدودیت‌های اصلی پروتکل در نظر می‌گیرند.