مسیر جدید واریز ckSOL، فرادادهٔ برداشت سولانا را به دروازهٔ مینت تبدیل میکند
توسعهٔ اخیر ckSOL، واریز SOL را به چرخهای مبتنی بر sweep منتقل میکند؛ در این چرخه ICP تنها پس از تطبیق تراکنش نهایی سولانا با فرادادهٔ برنامهریزیشده، واریز را اعتباردهی میکند.

مهمترین تغییر اخیر در یکپارچهسازی سولانا در ICP، الگوریتم امضای جدید نیست؛ بلکه تصمیمی سختگیرانهتر دربارهٔ زمان تبدیل واریز به ckSOL است.
تغییرات اخیر در مخزن dfinity/cksol، واریزها را به سمت چرخهای مبتنی بر sweep میبرد. کاربر deposit_sol را فراخوانی میکند، مینتر واریز را در صف قرار میدهد و یک زمانسنج، وجوه را از آدرسهای واریز به آدرس اصلی مینتر در سولانا منتقل میکند. این sweep میتواند حداکثر ۱۰ واریز را در یک دسته پردازش کند و موجودی لازم برای معافیت از rent را در آدرسهای مبدأ باقی بگذارد.
مرز مهم پس از نهاییشدن تراکنش ایجاد میشود. در PR شمارهٔ ۲۲۲ که merge شده است، مینتر تراکنش نهایی را دریافت میکند، پیام اجراشده را با برنامهای که قبلاً ثبت کرده مقایسه میکند، تغییر موجودی آدرسهای واریز را بررسی میکند، باقیماندن حسابهای مبدأ در وضعیت معاف از rent را تأیید میکند و مطمئن میشود آدرس اصلی مقدار مورد انتظار را دریافت کرده است. تنها پس از این بررسیها، sweep اعتباردهی میشود و مینتهای متناظر در صف قرار میگیرند.
در این طراحی، فرادادهٔ تراکنش بخشی از مسیر حسابداری است. مینتر، امضای ارسالشده را بهتنهایی مدرک اجرای انتقال موردنظر نمیداند؛ بلکه از دادهٔ اجرای تراکنش نهایی استفاده میکند تا پیش از مینتکردن توکنی در ICP که با SOL پشتیبانی میشود، مقدار واقعاً دریافتشده را تطبیق دهد.
این تغییر همچنین یک خطای ظریف سولانا را پوشش میدهد. آدرس واریز را نمیتوان تا کمتر از حداقل موجودی لازم برای باقیماندن روی شبکه تخلیه کرد. بنابراین طراحی ckSOL مقدار لازم برای معافیت از rent را باقی میگذارد و با درنظرگرفتن کارمزد sweep، مقدار قابل انتقال را محاسبه میکند. مستندات سولانا این حداقل موجودی را یک الزام قابلبازپرداخت برای نگهداری حساب، متناسب با اندازهٔ آن، توصیف میکند.
مدیریت خطا در مخزن نیز قابل توجه است. PR باز شمارهٔ ۲۱۸ پیشنهاد میکند واریزهای مربوط به sweepهای ناموفق یا منقضیشده حذف شوند تا دوباره در صف قرار گیرند؛ اما sweepهای نهاییشدهای که فرادادهٔ آنها با مدل مینتر سازگار نیست، قرنطینه شوند. در این حالت هیچ توکنی مینت نمیشود و واریز به مداخلهٔ دستی نیاز دارد. این رویکرد، یک استثنای عملیاتیِ آشکار را به حسابداری خاموش و نادرست ترجیح میدهد.
در PR شمارهٔ ۲۲۷ که merge شده، آدرس اصلی مینتر نیز از آدرسهای واریز مشتقشدهٔ کاربران جدا شده است. این اصلاح مانع آن میشود که آدرس خزانه بهاشتباه یک حساب واریز کاربر تلقی شود و sweep خودکار، موجودی را دوبارهشماری کند.
برای توسعهدهندگان Chain Fusion، درس عملی روشن است: مینت بینزنجیرهای فقط مسئلهٔ امضا نیست؛ مسئلهٔ تطبیق و حسابرسی است. وضعیت نهایی زنجیرهٔ مقصد، رفتار کارمزد، قواعد rent و روش مشتقسازی آدرس، همگی باید بخشی از قرارداد حسابداری canister باشند.
در زمان راستیآزمایی، این موارد توسعههای مخزنی هستند، نه عرضهٔ production: PR شمارهٔ ۲۱۸ هنوز باز است، PR شمارهٔ ۲۲۱ هنوز در وضعیت draft قرار دارد و خود مخزن اعلام میکند که مینتر و ledger مربوط به محیط production هنوز deploy نشدهاند. بااینحال، مسیر فنی روشن است: ckSOL تراکنش سولانا را به مدرکی تبدیل میکند که پیش از اعتباردهی ارزش در ICP لازم است.
- [۰۱]feat(minter): credit the deposits of a finalized sweep from the transaction metadata — PR #222github.com ↗
- [۰۲]feat(minter)!: drop failed sweeps and quarantine sweeps with mismatching metadata — PR #218github.com ↗
- [۰۳]Solana integration — ICP Developer Docsdocs.internetcomputer.org ↗
- [۰۴]Accounts — Solana Documentationsolana.com ↗
خبرخوان را در ایمیل بگیرید
هر سیگنال تازه، مستقیم از خط تولید. بدون مزاحمت، لغو عضویت در هر زمان.


