Стан розвитку MEV в мережі Sui та перспективи на майбутнє

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

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

Принципи та міркування дизайну

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

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

Основні пріоритети Sui такі:

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

Подання угоди

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

Ключовими факторами, що сприяють пріоритетному аукціону газу, є кількісне виконання:

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

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

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

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

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

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

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

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

1. Пріоритетний аукціон газу

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

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

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

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

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

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

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

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

1. Клієнт подає транзакцію: Клієнт подає транзакцію на RPC повний вузол (, зазвичай обирається програмою ).
2. RPC-нотифікація транзакцій: RPC-нотифікація передає транзакцію до верифікаційних вузлів, верифікаційні вузли перевіряють дійсність транзакції та підписують її, RPC-нотифікація збирає сертифікат транзакції з колективного підпису верифікаційних вузлів.
3. RPC вузол розповсюджує сертифікат транзакції: RPC вузол розповсюджує сертифікат транзакції до вузлів верифікації.
4. Підтвердження вузлом транзакції: Визначений вузол підтвердження подає транзакцію для консенсусу. Консенсус Mysticeti транслює блоки між вузлами підтвердження, і блок, що містить цю транзакцію, буде подано протягом 3 раундів консенсусу. Виконання транзакції: транзакція виконується на кожному вузлі підтвердження.
5. Сертифікат ефекту угоди надсилається назад до RPC-нод і клієнта: сертифікат ефекту після виконання угоди буде повернуто RPC-нодам і клієнту.
6. Генерація контрольної точки: Протягом 1-3 раундів консенсусу кожен валідаційний вузол створить та підпише контрольну точку (. Контрольна точка є пакетною обробкою кількох подань консенсусу ).
7. Широке розповсюдження підписів контрольних точок: підписи контрольних точок будуть розповсюджуватися між вузлами перевірки, кожен вузол перевірки формує сертифікат контрольної точки.
8. Перевірка контрольних точок у протоколі синхронізації стану: Протокол синхронізації стану відповідає за поширення підтверджених контрольних точок через точку-точку. Зазвичай кожен верифікаційний вузол має прямий піринговий вузол, який не надає RPC-запити ------ повний вузол синхронізації стану, що отримує контрольні точки від цього верифікаційного вузла.
9. Завантаження контрольних точок з третіх сторін: третій повний вузол, підключений до повного вузла синхронізації стану, отримує контрольні точки та завантажує їх вміст. У цей час ми припускаємо, що третя сторона, яка безпосередньо підключена до повного вузла, може обробляти результати транзакцій і реагувати на них.

( Поширення інформації про угоду перед поданням угоди

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

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

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

( потік блоків консенсусу

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

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

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

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

Захист користувацьких транзакцій

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

( Зовнішні члени

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

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

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

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

( Швидкий шлях до Містикет

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

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

Еволюція MEV Sui

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

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