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

ارتقای تراکنش ۴ کیلوبایتی سولانا مرز سریال‌سازی ICP را دوباره آشکار می‌کند

قالب تراکنش v1 سولانا که به‌زودی ارائه می‌شود، سقف تراکنش را از ۱۲۳۲ به ۴۰۹۶ بایت افزایش می‌دهد. برای سازندگان ICP، مسئله فقط پشتیبانی از امضا نیست؛ تمام مسیرهای RPC، رمزگشایی و اجماع نیز باید بتوانند این قالب جدید را ایمن حمل کنند.

ارتقای تراکنش ۴ کیلوبایتی سولانا مرز سریال‌سازی ICP را دوباره آشکار می‌کند
تصویر: تولید هوش مصنوعی

سولانا در حال آماده‌سازی تغییری در قالب تراکنش‌هاست که برای برنامه‌های ICP استفاده‌کننده از Chain Fusion اهمیت دارد. قالب v1 پیشنهادی سقف اندازه تراکنش را از ۱۲۳۲ به ۴۰۹۶ بایت افزایش می‌دهد و فضای بیشتری برای چندامضایی‌های بزرگ، عملیات دارای داده‌های اثبات و فراخوانی‌های اتمیک پیچیده فراهم می‌کند.

این تغییر فقط افزایش ظرفیت نیست. راهنمای رسمی سولانا می‌گوید تراکنش‌های v1 پوشش جدیدی دارند، تنظیماتی مانند محدودیت محاسبات و کارمزد اولویت را در transactionConfig قرار می‌دهند و از Address Lookup Table پشتیبانی نمی‌کنند. سازندگان تراکنش‌های v1 باید محدودیت واحد محاسبه و داده حساب‌های بارگذاری‌شده را صریحاً تعیین کنند، برای تراکنش‌های بزرگ‌تر از ۱۲۳۲ بایت از base64 استفاده کنند و کارمزد اولویت را مجموع لامپورت‌ها بدانند، نه قیمت به‌ازای هر واحد محاسبه.

این موضوع مرز تازه‌ای برای یکپارچه‌سازی در ICP ایجاد می‌کند. کانستر SOL RPC هم‌اکنون دسترسی به سولانا را از طریق فراخوانی‌های HTTPS فراهم می‌کند، اجماع قابل‌تنظیم برای پاسخ‌ها دارد و در مستندات خود sendTransaction را پشتیبانی‌شده معرفی می‌کند. همان مستندات هشدار می‌دهند که فراخوانی‌های شبکه اصلی به‌صورت replicated انجام می‌شوند و پاسخ‌های بسیار سریع‌التغییر ممکن است در اجماع شکست بخورند. به‌طور مشخص، getLatestBlockhash برای مسیر مستقیم معمول مناسب نیست، چون سریع‌تر از آن تغییر می‌کند که replicaهای subnet بتوانند به‌طور قابل اتکا درباره آن توافق کنند؛ راه‌های پیشنهادی شامل durable nonce یا دریافت یک slot اخیر و سپس بازیابی block مربوط به آن است.

نتیجه عملی این است که برنامه ICP نباید تراکنش بزرگ‌تر سولانا را جایگزینی بی‌دردسر برای payload نسخه v0 فرض کند. برنامه مهاجرت ایمن باید شامل این موارد باشد:

  • سریال‌سازی و رمزگشایی آگاه از نسخه، از جمله تشخیص‌دهنده v1؛
  • برآورد صریح محدودیت منابع از طریق شبیه‌سازی؛
  • آزمون انتقال payloadهای بزرگ با base64؛
  • بررسی اینکه کنترل‌های کارمزد و بودجه محاسباتی تنظیمات v1 را می‌خوانند، نه اینکه فقط دستورهای ComputeBudget را اسکن کنند؛ و
  • آزمون روی mainnet و در برابر SOL RPC تکثیرشده، نه فقط یک replica محلی.

این caveat فعلی مهم است: قالب v1 سولانا هنوز به‌عنوان قابلیتی در آینده معرفی شده و وضعیت feature gate آن برای mainnet «فعال نشده» اعلام شده است. مستندات فعلی مخزن ICP SOL RPC نیز ثابت نمی‌کند که کانستر مستقرشده از همین حالا فیلدهای اختصاصی v1 را می‌خواند، می‌سازد یا منتقل می‌کند. بنابراین تیم‌ها باید برای آماده‌سازی از validatorهای محلی و ماتریس نسخه رسمی سولانا استفاده کنند و در تولید فقط به قالب‌ها و روش‌هایی تکیه کنند که کل مسیر ICP آن‌ها را تأیید کرده است.

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

برچسب‌هاChain FusionSolanaICPRPC
منابع مستند۲ مرجع
  1. [۰۱]Larger Transaction Sizessolana.com
  2. [۰۲]SOL RPC canister — dfinity/sol-rpc-canistergithub.com
خواندنی بعدی

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

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

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