Розвиток MEV в екосистемі Sui: сучасний стан та перспективи

У сфері блокчейн MEV(, максимальна вилучена вартість) стає популярною темою, оскільки вона стосується впорядкування угод та можливостей арбітражу. Щоб забезпечити прозорість, захист угод, підтримку здоров'я мережі та винагороду учасників, Sui активно впроваджує цільові пропозиції щодо вдосконалення та інші механізми для регулювання діяльності MEV у мережі.

Окрім існуючих механізмів, Sui також планує створити більше механізмів, щоб забезпечити, що основні принципи керують еволюцією MEV.

Принципи дизайну та розгляду

Кожна транзакція на Sui вводить нову інформацію, що створює потенційні можливості для прибутку. Екосистема MEV Sui формується через кілька механізмів:

• Механізм подання MEV-транзакцій
• Механізм публікації можливостей MEV
• Механізм розподілу доходів MEV
• Механізм захисту угод користувачів

Загальні пріоритети такі:

• Захист транзакцій користувача має перевагу над кількістю вилучення вартості. Увага надається меншому спреду, щоб уникнути поза ланцюгових аукціонів без варіантів виходу.
• Прозорість мережі є пріоритетом перед приватними угодами з валідаційними вузлами або реле.
• Через аукціон пріоритетних зборів (PGA) сприяння конкуренції, стримування сміттєвих дій: в ідеалі, домінуюча стратегія шукачів полягає в тому, щоб надіслати транзакцію, пріоритетні збори якої визначаються витягнутою вартістю.
• Заохочення розподілу винагороди серед учасників, які відповідають екологічним стандартам: верифіковані вузли, стейкери, додатки та користувачі.

Подача угоди

Оскільки транзакції для зміни одного й того ж об'єкта виконуються в порядку, клієнти змагаються, щоб підвищити свої шанси на виконання. З системної точки зору, PGA є ефективним способом розподілу ресурсів, який запобігає сміттєвій поведінці, одночасно перерозподіляючи витрати на газ між учасниками.

Ключовими факторами PGA є кількісне виконання:

• Транзакції, відсортовані за консенсусом, обробляються в блоці. Торговці змагаються за пріоритет за допомогою аукціону газу.
• Це відрізняється від CEX маркет-мейкерів, у CEX пріоритет виконання повністю залежить від швидкості.
• Вища швидкість подачі консенсусу зменшила кількісний ефект, зробивши виконання більш ефективним, але також звузила вікно PGA.
• Наразі PGA для не завантажених об'єктів є найважливішим для найшвидших пошуковців. При швидкості подачі 15 разів на секунду перевага в 70 мілісекунд у швидкості подачі транзакції може визначити, чи буде транзакція завершена.
• Об'єкти заторів можуть затримувати виконання транзакцій, ще більше підкреслюючи важливість PGA, оскільки конкуренція може бути в 10 разів більшою, ніж звичайна подача консенсусу.

Існує два механізми для спрямування транзакцій до певного майбутнього подання Sui:

1. Подайте пакет транзакцій через м'яке бандлінг: SIP-19

• Торги, подані через м'яку упаковку, швидше за все, будуть включені в той же консенсусний внесок разом із дійсною упаковкою. Умови дійсності упаковки вимагають, щоб усі торгові ціни газу були однаковими.
• На практиці це дозволяє проводити поза мережею аукціони для початкових та подальших трансакцій.

2. Збільшення пріоритетних транзакцій через консенсус: SIP-45

• SIP-45 вирішує потенційні проблеми з коливаннями під час подання консенсусу, запобігаючи тому, щоб угоди з низькою ціною газу, які подаються одночасно, ставали після угод з високою ціною газу.
• Два природні коливання, що виникають під час подання консенсусу: ( вузли верифікації, що подають, відстають на кілька раундів консенсусу; ) лідер раунду має перевагу перед іншими вузлами верифікації в подачі.
• SIP-45 посилює подачу консенсусу шляхом збільшення газової ціни вище k x RGP. Транзакції з газовою ціною n x RGP будуть збільшені в n разів.
• Широке впровадження SIP-45 створить більш ефективну та справедливу конкурентну систему. Слід зазначити, що це не змінить основні властивості системи з точки зору клієнта, а скоріше зменшить неетичну поведінку, надаючи більш ефективні альтернативи.

Вибір відповідної ціни газу для торгівлі

Клієнт повинен враховувати такі основні фактори для визначення ціни газу для подання транзакції:

1. Аукціон пріоритетних витрат

У межах подання консенсусу транзакції для одного й того ж об'єкта впорядковані за ціною газу, що забезпечує справедливі можливості для конкурентів.

2. Розширення подачі консенсусу

Торги з ціною газу понад 5 x RGP подаються на консенсус через кілька валідаційних вузлів для підсилення. Будь-яка ціна газу, що перевищує порогове значення посилення, зменшить коливання неефективних подач. На практиці, коефіцієнт посилення в 5 достатній для усунення коливань, ціна газу в 100 x RGP, ймовірно, розблокує наступний раунд подачі лідера.

3. Уникати затримок і скасувань

Sui обмежує час виконання контрольних точок, контролюючи швидкість транзакцій для одного і того ж спільного об'єкта. Транзакції, що модифікують об'єкт заторів, сортуються за ціною газу; транзакції з низькою ціною будуть відкладені та в кінцевому підсумку скасовані, щоб обмежити максимальну довжину послідовного виконання для кожної контрольної точки.

Ціна газу для виконання та скасування транзакцій, що відслідковуються повними вузлами, особливо для транзакцій, що стосуються зміни об'єктів заторів. Через результати виконання транзакцій можна отримати ціну газу для транзакцій з найнижчою виконаною ціною та найвищою скасованою ціною. Використовуючи цю інформацію, клієнт може визначити необхідну ціну газу, щоб з високою ймовірністю уникнути затримок у транзакціях.

Публікація торгової інформації

Кожна транзакція на Sui відкриває потенційні можливості для прибутку. Розгляньте життєвий цикл торгівлі спільними об'єктами, від подання клієнтом до того, як третя сторона спостерігає за її впливом:

1. Клієнт подає транзакцію до RPC повного вузла
2. RPC-нотифікація транзакції для вузлів перевірки
3. RPC-узел транслює сертифікат транзакції
4. Вузли перевірки подають транзакції для консенсусу
5. Транзакції виконуються на кожному вузлі верифікації
6. Відправка сертифіката ефекту транзакції назад до RPC-вузла та клієнта
7. Генерація контрольної точки
8. Точка перевірки підпису трансляції
9. Перевірка контрольних точок протоколу синхронізації стану
10. Перевірка контрольної точки завантаження стороннім вузлом

( Поширення інформації про транзакцію перед подачею заявки

Sui має поза ланцюгова аукціонна система, призначена для подання м'яких пакетів, відповідно до SIP-19. Ці аукціони перехоплюють подання угод через поза ланцюговий протокол між додатком та аукціонною системою.

Ця інформація поширюється за припущенням, що аукційна система працює добре і може захистити угоди користувачів від потенційних атак з боку клептоманів. Аукційна система мотивована захищати угоди користувачів для збереження свого бізнесу, тому вона використовує деякі аукційні техніки, щоб послабити фінансові вигоди, які можуть бути отримані від потенційних клептоманських роботів.

Ця інформація поширюється поза межами Sui, є добровільним вибором додатка та користувачів, надає лише спекулятивну інформацію і не може гарантувати успіх торгових угод первинних користувачів.

) Трансляція блоку консенсусу

Для забезпечення низької затримки доступу користувачів до транзакцій розробляється система прямого потокового передавання блоків консенсусу. Повні вузли зможуть безпосередньо підписуватись на блоки консенсусу.

Таким чином, повні вузли можуть спекулятивно повідомляти про транзакції, які з високою ймовірністю будуть підтверджені. Мережна топологія використовує стандартний протокол виявлення пір для синхронізації відкритого стану.

Це повідомлення про спекуляцію може значно скоротити затримку передачі угод, всього за приблизно 160 мілісекунд ### два раунди консенсусу ###, після того як вузли перевірки подали.

Проект потокової передачі блоків консенсусу наразі перебуває на стадії проектування, і очікується, що в найближчі 1-2 місяці буде опубліковано пропозицію щодо вдосконалення.

Захист користувачів у торгах

Користувацькі交易 повинні бути захищені від впливу попередніх交易, тиску та ненавмисних затримок подання.

( Зовнішній учасник

Подання транзакцій Sui потребує залучення зовнішніх учасників, зазвичай виконується повними вузлами.

Якщо вузол перевірки отримує запит на подачу транзакції t і бажає розпочати нову транзакцію t', він буде відставати від оригінального драйвера учасників під час процесу складання сертифіката. Якщо тільки поданий повний вузол не має поганого з'єднання з учасниками Sui, вузол перевірки буде відставати від t під час процесу складання сертифіката t'.

Крім того, оскільки подання консенсусу t є децентралізованим, як тільки сертифікат t досягає консенсусу, його не можна надійно затримати. Тому, якщо сертифікат t досягає консенсусу Sui до t', t з великою ймовірністю буде завершено до t'.

Отже, зовнішній драйв учасників забезпечує природний попередній захист, припускаючи довіру до повних вузлів, відповідальних за подання транзакцій.

) Mysticeti швидкий шлях

Наразі реалізується проект, який змінює подання транзакцій на швидкий протокол, описаний у статті Mysticeti. Згідно з цим протоколом, транзакції користувачів можуть бути подані на один підтверджуючий вузол, який використовуватиме Mysticeti для збору та виконання сертифікатів транзакцій. Хоча це значно підвищує ефективність системи, це також надає підтверджуючому вузлу можливість отримувати транзакції користувачів через попередні транзакції.

Цей ризик є виключно теоретичним, оскільки наразі немає доказів того, що на Sui відбулися атаки з попередніми угодами. У новій системі ймовірність попередніх угод вища, але з іншого боку, завдяки визначеному розумінню верифікаційних вузлів, їх легше притягнути до відповідальності.

Еволюція MEV Sui

Екосистема MEV Sui все ще формується, і пізніше цього року будуть впроваджені нові механізми. Наразі пріоритетні аукціони зборів та консенсусна ампліфікація визначають поточну систему, а нововведення, такі як шифрування з тайм-локом і швидкий шлях Mysticeti, перетворять виконання угод та безпеку. З впровадженням цих механізмів MEV на Sui продовжить розвиватися, створюючи більш динамічну та прозору екосистему.

! [Читайте поточну ситуацію та майбутнє MEV на Sui]###https://img-cdn.gateio.im/webp-social/moments-6dae0c442b5d72296728a401858cf5ea.webp###