ساعت ۴۰۰ میلی‌ثانیه‌ای سولانا، آزمون واقعی Chain Fusion در ICP است

<p>یکپارچگی سولانای Chain Fusion اکنون یک ابزار عملی برای توسعه‌دهندگان کانستر است: کانستر عمومی SOL RPC دسترسی نوع‌دار به JSON-RPC سولانا ارائه می‌دهد و مستندات ICP سولانا را در میان شبکه‌هایی قرار می‌دهد که با کانستر RPC اختصاصی پشتیبانی می‌شوند. نکتهٔ مهم فقط این نیست که یک کانستر می‌تواند به سولانا برسد؛ بلکه محدودیت طراحی‌ای است که این خواندن‌ها را برای اجرای تکثیرشده به‌اندازهٔ کافی قابل اتکا می‌کند.</p><p>هر فراخوان HTTPS از سوی نودهای یک زیرشبکهٔ ICP انجام می‌شود. نتیجه‌ها باید همگرا شوند، نه اینکه فقط با سرعت به یک سرور برسند. این محیط با بک‌اند متعارفی که یک نقطهٔ RPC را فراخوانی می‌کند تفاوت دارد. همچنین روشن می‌کند چرا SOL RPC تنظیم اجماع پاسخ دارد و چرا پشتیبانی از برخی متدها گاه پاسخ‌ها را تبدیل می‌کند.</p><h2>تازگی، خودبه‌خود ترکیب‌پذیر نیست</h2><p>مستندات مخزن، <code>getLatestBlockhash</code> را متدی مسئله‌دار معرفی می‌کند. هش بلاک سولانا تقریباً هر ۴۰۰ میلی‌ثانیه تغییر می‌کند، در حالی که فرایند فراخوان بیرونی در حد چند ثانیه طول می‌کشد. در نتیجه، نودها ممکن است مقادیر متفاوت ببینند و به اجماع نرسند. این نشانهٔ خراب‌بودن پشتیبانی سولانا نیست؛ بلکه مرزی مفید برای طراحی برنامه است.</p><p>برای <code>getSlot</code>، کانستر می‌تواند اسلات دیده‌شده را—طبق مخزن، به‌طور پیش‌فرض در بازه‌های ۲۰ اسلاتی—گرد کند تا احتمال توافق نودها بیشتر شود. این مصالحه آشکار است: پاسخ در ازای احتمال بالاترِ توافق تکثیرشده، دقت کمتری پیدا می‌کند. توسعه‌دهندگان باید برای هر خواندن تصمیم بگیرند که آیا این کاهش جزئیات قابل قبول است یا نه، و نباید همهٔ پاسخ‌های JSON-RPC را قابل‌جایگزینی فرض کنند.</p><h2>ساخت تراکنش به مسیر متفاوتی نیاز دارد</h2><p>جایگزین‌های مستند برای ارسال تراکنش سولانا، استفاده از durable nonce یا دریافت اسلات اخیر با <code>getSlot</code> و سپس دریافت بلاک، شامل هش بلاک، با <code>getBlock</code> است. این توالی یک جزئیات ظاهراً کوچک RPC را به یک تصمیم معماری بدل می‌کند. سرویسی که از طرف کاربران تراکنش می‌سازد باید دریافت هش بلاک، انقضا، تلاش مجدد و مدیریت خطا را جزء اصلی طراحی بداند.</p><p>همین مستندات هشدار می‌دهند که آزمون محلی می‌تواند نتیجهٔ مثبت گمراه‌کننده‌ای بدهد. استقرار محلی فراخوان‌های IPv4 را می‌پذیرد، اما ICP Mainnet به IPv6 نیاز دارد. اجرای محلی همچنین تک‌تکثیره است و رفتار اجماع مین‌نت را بازتولید نمی‌کند. بنابراین آزمودن مجموعهٔ ارائه‌دهندگان و جریان تراکنش مورد نظر روی مین‌نت بخشی از کار یکپارچه‌سازی است، نه تشریفات نهایی استقرار.</p><h2>«بدون بریج» چه معنایی دارد و چه معنایی ندارد</h2><p>Chain Fusion نگه‌داری کلید و اجرا را تغییر می‌دهد: رمزنگاری chain-key در ICP به کانسترها اجازه می‌دهد کلید مشتق کنند و امضای آستانه‌ای بخواهند، بی‌آنکه یک کلید خصوصی در یک نود بازسازی شود. اما دسترسی به وضعیت سولانا همچنان به فراخوان‌های HTTPS و ارائه‌دهندگان خارجی RPC وابسته است؛ این یکپارچگی مستقیمِ نود سولانا در سطح پروتکل نیست. مستندات خود Chain Fusion این مدل RPC اختصاصی را از یکپارچگی‌های مستقیم بیت‌کوین و دوج‌کوین جدا می‌کند و می‌گوید دسترسی مبتنی بر RPC یک فرض مربوط به ارائه‌دهندهٔ RPC می‌افزاید که مقایسهٔ چند ارائه‌دهنده می‌تواند آن را کاهش دهد.</p><p>همین قید، تیتر اصلی است. SOL RPC زمانی بیشترین ارزش را دارد که برنامه از منطق سمت ICP، امضای کنترل‌شده با آستانه، و مسیر خواندنی که با دقت طراحی شده بهره ببرد؛ نه زمانی که فرض کند هر ابزار کم‌تأخیر سولانا مانند یک فراخوان RPC محلی رفتار می‌کند. فرصت کنونی برای سازندگان، طراحی آگاهانه بر پایهٔ اجماع است: خواندن‌های پایدار را برگزینند، هرجا مناسب است پاسخ را استانداردسازی کنند، و جریان تراکنشی به کار گیرند که به یک پاسخ به‌سرعت متغیر و یکسان در همهٔ نسخه‌ها وابسته نباشد.</p>