EN
→ بازگشت به خبرخوان
شمارهٔ ۰۲۰۶Chain Fusion۲ دقیقه۲ منبع

سولانا به هدفی واقعی برای ساخت روی ICP تبدیل شده است—اگر توسعه‌دهندگان محدودیت زمانی RPC را جدی بگیرند

کانستر RPC سولانا و امضای Ed25519 آستانه‌ای در ICP اکنون یک سطح عملی برای ساخت برنامه‌های سولانا در Chain Fusion فراهم می‌کنند؛ اما داده‌های سریعاً متغیر RPC و ساخت دستی تراکنش همچنان محدودیت‌های مهم مهندسی هستند.

سولانا به هدفی واقعی برای ساخت روی ICP تبدیل شده است—اگر توسعه‌دهندگان محدودیت زمانی RPC را جدی بگیرند
تصویر: تولید هوش مصنوعی

داستان Chain Fusion در ICP از این گزاره که «کانسترها می‌توانند روی سولانا امضا کنند» به سطحی رسیده است که توسعه‌دهندگان واقعاً می‌توانند روی آن برنامه بسازند. مستندات فعلی توسعه‌دهندگان، یک کانستر SOL RPC روی مین‌نت، امضای Ed25519 آستانه‌ای و مسیر کاملی برای خواندن وضعیت سولانا، ساخت نشانی تحت کنترل کانستر، امضای تراکنش و ارسال آن به سولانا را توضیح می‌دهند.

این معماری کار را به دو لایه تقسیم می‌کند. کانستر SOL RPC درخواست‌های JSON-RPC را به چند ارائه‌دهنده می‌فرستد و فقط پس از برآورده شدن راهبرد اجماع تنظیم‌شده، پاسخ را بازمی‌گرداند. مخزن رسمی Alchemy، Ankr، Chainstack، dRPC، Helius و PublicNode را به‌عنوان ارائه‌دهندگان پشتیبانی‌شده فهرست می‌کند. برنامه‌ها هزینه درخواست‌ها را با چرخه‌های ICP می‌پردازند و لازم نیست برای هر ارائه‌دهنده، کلید API جداگانه مدیریت کنند.

امضا به‌صورت جداگانه از طریق کانستر مدیریتی ICP انجام می‌شود. یک کانستر کلید عمومی Ed25519 را مشتق می‌کند، آن را به نشانی سولانا تبدیل می‌کند، پیام تراکنش را سریال‌سازی می‌کند و با الگوریتم Ed25519، امضای Schnorr آستانه‌ای می‌گیرد. هیچ‌یک از گره‌های زیرشبکه کلید خصوصی کامل را در اختیار ندارد. سپس امضای حاصل می‌تواند از طریق رابط SOL RPC ارسال شود.

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

نکته مهندسی مهم در مرز این دو شبکه قرار دارد. فراخوانی‌های HTTPS در ICP چند ثانیه زمان می‌برند، در حالی که پنجره بلاک‌هش سولانا حدود ۴۰۰ میلی‌ثانیه است. به همین دلیل، مخزن رسمی راهکارهایی مانند nonce پایدار، یا دریافت یک slot تازه و سپس واکشی بلاک متناظر را مستند کرده است. توسعه‌دهندگان نباید فرض کنند هر متد RPC سولانا مانند یک RPC کم‌تأخیر معمولی رفتار می‌کند.

یک caveat مهم دیگر نیز وجود دارد: مستندات رسمی صراحتاً می‌گویند پشتیبانی سولانا از پشتیبانی بیت‌کوین و اتریوم جدیدتر است، سطح API آن همچنان در حال تغییر است، helper رسمی برای توکن‌های SPL وجود ندارد و ساخت تراکنش هنوز دستی است. بنابراین این اتصال فعلاً بیشتر یک primitive پروتکلی قدرتمند و یک سطح توسعه است، نه یک SDK آماده و کامل سولانا.

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

برچسب‌هاChain FusionInternet ComputerSolanaThreshold CryptographyRPC
منابع مستند۲ مرجع
  1. [۰۱]Solana integration | ICP Developer Docsdocs.internetcomputer.org
  2. [۰۲]dfinity/sol-rpc-canister | GitHubgithub.com
خواندنی بعدی

خبرخوان را در ایمیل بگیرید

هر سیگنال تازه، مستقیم از خط تولید. بدون مزاحمت، لغو عضویت در هر زمان.

خوراک RSS در دسترس · بدون هرزنامه