لبهٔ سقوط ۴۰ میلیارد دستور: آزمون تازهٔ قابلیت اطمینان برای دیفای چندزنجیره‌ای ICP

یک ارزیابی عمومی تازه از نمونهٔ اولیهٔ MULTI/DEX متعلق به DFINITY، یک حالت خرابی را گزارش کرده است که فقط به یک صرافی محدود نمی‌شود: یک دستهٔ نقدسازیِ بدون سقف، در صورت رشد مجموعهٔ وام‌ها، سرانجام می‌تواند از سقف ۴۰ میلیارد دستور در هر پیام ICP عبور کند و با خطا متوقف شود.

این گزارش که در ۱ اوت ۲۰۲۶ منتشر شده، می‌گوید مشکل در runLiquidationBatch قرار دارد؛ تابعی که در سه مرحله، کل مجموعهٔ وام‌ها را بدون سقف، شارد، مکانیزم ادامه‌دهنده یا بودجهٔ محاسباتی پیمایش می‌کند. ارزیاب حدود ۱ تا ۱٫۲ میلیون دستور برای هر وام اندازه‌گیری کرده است. در بازتولید آن‌ها، ۳۴ هزار وام آخرین اندازهٔ آزمایش‌شدهٔ زیر سقف بود، اما در ۳۶ هزار و ۴۰ هزار وام، پیام با خطای IC0522 متوقف شد.

جزئیات خطرناک فقط شکست یک پیام نیست. طبق گزارش، عملیات نقدسازی در یک پیام ناهمگام جداگانه و پس از آن اجرا می‌شود که heartbeat زمان‌سنج‌های خود را جلو برده است. بنابراین heartbeat می‌تواند سالم به نظر برسد، در حالی که پیام نقدسازی شکست خورده و برگشت داده شده است. برای یک سامانهٔ وام‌دهی، این یک مشکل پایش ایجاد می‌کند: شاخص‌های زنده‌بودن ممکن است همچنان حرکت کنند، حتی وقتی موتور حفظ توان پرداخت دیگر نقدسازی‌ها را انجام نمی‌دهد.

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

مشخصات MULTI/DEX این پروژه را یک صرافی درون‌زنجیره‌ای با دفتر سفارش، AMM، حسابداری مارجین و اهداف چندزنجیره‌ای برای دارایی‌هایی مانند BTC، ETH و SOL توصیف می‌کند. مخزن پروژه می‌گوید استقرار فعلی یک نمونهٔ پژوهشی است و هشدار می‌دهد که نباید با سرمایهٔ واقعی از آن استفاده کرد. گزارش همچنین می‌گوید وضعیت زندهٔ #play از موجودی‌های آزمایشی استفاده می‌کند؛ بنابراین اندازهٔ سرقت احتمالی ارزش محدود است، اما نگرانی‌های مربوط به دسترس‌پذیری و یکپارچگی همچنان پابرجاست.

برای سازندگان، چک‌لیست عملی روشن است: هر پیمایش دوره‌ای باید سقف سخت برای هر فراخوانی، cursor قابل ادامه و مسیر تلاش مجددِ محدود داشته باشد؛ شاخص‌های سلامت باید پیشرفت زمان‌بند را از موفقیت واقعی نقدسازی جدا کنند؛ و ارتقاها باید شامل آزمون بار نزدیک به مرز پیام باشند. کانستری که در سراسر زنجیره‌ها تراکنش را امضا یا ارسال می‌کند، یک وظیفهٔ اضافی هم دارد: وقتی حسابداری یا حلقهٔ نقدسازی آن قدیمی شده است، باید به‌صورت ایمن متوقف شود.

این مقاله بر پایهٔ ارزیابی عمومی پژوهشگران و مستندات مخزن نوشته شده، نه یک ممیزی رسمی یا اصلاحیهٔ تأییدشده. شواهد، این مسئله را یک هشدار جدی طراحی نشان می‌دهند، اما ثابت نمی‌کنند که در MULTI/DEX از سرمایهٔ واقعی سوءاستفاده شده است. نتیجهٔ گسترده‌تر روشن است: در Chain Fusion، کنترل رمزنگاری‌شدهٔ دارایی‌های خارجی فقط نیمی از ایمنی است. نیمهٔ دیگر این است که هر حلقهٔ خودکارِ ایمنی محدود، قابل‌راه‌اندازی مجدد و چنان شفاف باشد که توقف آن هرگز با سلامت اشتباه نشود.