A dark server room with illuminated equipment
ارز دیجیتال

MultiversX سوپرنوا را در تست‌نت راه‌اندازی کرد

این به‌روزرسانی اجماع را از اجرا جدا می‌کند و ادعا می‌کند که نهایی‌سازی درون‌تکه‌ای برای DeFi حساس به تأخیر بین ۱۰۰ تا ۲۵۰ میلی‌ثانیه است.

نوشته Emma Carter5 دقیقه مطالعه

MultiversX به‌روزرسانی "سوپرنوا" خود را در شبکه آزمایشی راه‌اندازی کرده است و تولید بلاک را به‌گونه‌ای طراحی کرده که اعتبارسنج‌ها بتوانند قبل از اجرای تراکنش‌ها بر روی بلاک‌ها توافق کنند. تیم هدف‌گذاری کرده است که بلاک‌ها حدود 600 میلی‌ثانیه و نهایی‌سازی درون‌شارد بین 100 تا 250 میلی‌ثانیه باشد، با فعال‌سازی شبکه اصلی که انتظار می‌رود در 10 سپتامبر 2026 انجام شود.

سوپرنوا به شبکه آزمایشی رسید با تغییر شبکه اصلی در 10 سپتامبر مورد انتظار

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

زمان‌بندی اعلام شده فشرده و مشخص است. سوپرنوا از 20 اوت بلاک‌های حدود 600 میلی‌ثانیه‌ای را در شبکه آزمایشی زنده و شبکه توسعه تولید کرده است و شبکه به سمت تاریخ فعال‌سازی شبکه اصلی مورد انتظار در 10 سپتامبر 2026 کار می‌کند.

این به‌روزرسانی به‌عنوان پاسخی به یک سقف مقیاس‌پذیری آشنا برای زنجیره‌های با عملکرد بالا چارچوب‌بندی شده است: زمانی که اجرای تراکنش در مسیر بحرانی توافق قرار می‌گیرد، کندترین محاسبه به خودی خود ماشین سرعت سیستم می‌شود. شرط‌بندی MultiversX این است که تغییر بعدی در تأخیر از تغییر ترتیب عملیات ناشی می‌شود، نه فقط بهینه‌سازی انتشار و نهایی‌سازی.

توافق و اجرای جداشده: اهداف تأخیر و مشکل جدید اعتبارسنجی

تغییر اصلی سوپرنوا مکانیکی است: این "توافق را از اجرا جدا می‌کند تا شبکه بتواند قبل از پردازش تراکنش‌ها بر روی بلاک‌ها توافق کند" و اجرای تراکنش‌ها را از مسیر بحرانی توافق خارج کرده و به مرحله‌ای ناهمزمان منتقل می‌کند که بعد از رأی‌گیری اعتبارسنج‌ها اجرا می‌شود.

قبل از به‌روزرسانی، جریان به‌صورت متوالی بود. یک پیشنهاددهنده تراکنش‌ها را انتخاب می‌کرد، آن‌ها را به‌صورت محلی اجرا می‌کرد و بلاکی با تغییرات حالت حاصل پیشنهاد می‌کرد، سپس اعتبارسنج‌ها آن تراکنش‌ها را دوباره اجرا می‌کردند قبل از رأی‌گیری.

تحت سوپرنوا، "پیشنهاددهنده تراکنش‌ها را انتخاب می‌کند و بلاک را بدون اجرای آن‌ها اول پیشنهاد می‌کند" و "اعتبارسنج‌ها تأیید می‌کنند که پیشنهاد مطابق با قوانین پروتکل است و می‌توانند بلافاصله رأی‌گیری کنند، در حالی که اجرا به‌طور ناهمزمان در پس‌زمینه ادامه دارد."

این تغییر ترتیب است که اهداف تأخیر را در نظریه قابل قبول می‌سازد. خروجی اجرا "معمولاً در هدر بلاک بعدی ارجاع داده و تأیید می‌شود"، که به این معنی است که اجرای تراکنش‌ها تقریباً یک بلاک از توافق عقب‌تر است، یا حدود 600 میلی‌ثانیه.

در عمل، معماری به دنبال یک ریتم لوله‌ای است که در آن توافق می‌تواند به تولید بلاک‌های ~600 میلی‌ثانیه‌ای ادامه دهد حتی اگر اجرا یک بلاک عقب‌تر باشد، به‌جای اینکه هر اعتبارسنج مجبور باشد همان محاسبه را قبل از نهایی شدن بلاک بعدی به پایان برساند.

برای سازندگان، ادعای اصلی این است که "نهایی‌سازی درون‌شارد به محض در دسترس بودن مدرک انجام می‌شود، معمولاً در همان دور در حدود 100 تا 250 میلی‌ثانیه،" همراه با "شرایط اجرایی قابل پیش‌بینی‌تر." موارد استفاده هدف، مواردی هستند که به سرعت در زمانی که تأخیر برای کاربر قابل مشاهده می‌شود، کاهش می‌یابند، از جمله اصول DeFi با فرکانس بالا و کتاب‌های سفارش زنجیره‌ای.

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

وضعیت مموپل مجازی، EIE و فشار معکوس: چگونه سوپرنوا سعی می‌کند بلاک‌ها را ایمن نگه دارد و گره‌ها را همگام کند.

اولین خط دفاع سوپرنوا در لایه پیشنهاددهنده است، از طریق یک "وضعیت مموپل مجازی" که فراتر از آخرین وضعیت اجرایی شده نگاه می‌کند و نانس‌های معلق، مصرف موجودی مورد انتظار و تراکنش‌هایی که قبلاً پیشنهاد شده‌اند اما هنوز از طریق اجماع اجرا یا نهایی نشده‌اند را پیگیری می‌کند. هدف این است که به پیشنهاددهندگان یک دید پیشرو از فعالیت‌های حساب بدهد تا بتوانند از گنجاندن تراکنش‌هایی که احتمال شکست دارند، اجتناب کنند.

طراحی همچنین دو محدودکننده صریح اضافه می‌کند که به منظور جلوگیری از عقب‌ماندن طولانی‌مدت سخت‌افزار شبکه ایجاد شده‌اند. تخمین‌زننده گنجایش نتایج اجرایی (EIE) تعداد نتایج اجرایی که می‌توان در یک بلاک ارجاع داد را بر اساس اینکه "گره‌های حداقل مشخص می‌توانند به‌طور ایمن پردازش کنند"، محدود می‌کند و فشار معکوس خودکار ظرفیت بلاک را کاهش می‌دهد اگر اجرا خیلی عقب بیفتد، به سیستم زمان می‌دهد تا به عقب برگردد.

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

همچنین، فراتر از وضعیت مموپل مجازی و محدودکننده‌ها، مشخص نمی‌کند که چگونه شکست‌های اجرایی پس از اجماع و تراکنش‌های نامعتبر به‌طور عملی در موارد حاد مدیریت می‌شوند.

مراحل ملموس بعدی بیشتر رویه‌ای هستند تا روایتی: تأیید یا تجدید نظر در تاریخ فعال‌سازی اصلی شبکه در 10 سپتامبر 2026، تولید پایدار بلاک‌های ~600 میلی‌ثانیه در تست‌نت/devnet به‌عنوان بار و پیچیدگی تراکنش‌ها افزایش می‌یابد، و هر معیار افشا شده‌ای که نشان دهد EIE چه‌قدر اغلب محدودیت‌ها یا کاهش فشار معکوس را تحت فشار فعال می‌کند.

خوانش من: این یک شرط UX/سازنده است—اما معامله‌گران باید به اعداد به‌عنوان موقتی نگاه کنند تا زمانی که شبکه اصلی فعال شود.

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

آستانه‌ای که اهمیت دارد این است که آیا تست‌نت/devnet می‌تواند بلاک‌های ~600 میلی‌ثانیه را در حالی که محدودکننده‌ها عمدتاً در پس‌زمینه باقی می‌مانند، نگه دارد، زیرا اگر EIE و فشار معکوس به‌طور مداوم درگیر باشند، خط لوله هنوز "سریع" روی کاغذ است اما در عمل محدود شده است. این زمانی به موضوع بازار تبدیل می‌شود که تاریخ شبکه اصلی تأیید شود و شبکه بتواند رفتار پایدار با تأخیر کم را بدون اینکه تأخیرهای اجرایی روتین محدودکننده غالب شود، نشان دهد.

منابع