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

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

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

Принципи дизайну та фактори, що враховуються

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

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

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

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

! Читайте поточну ситуацію та майбутнє MEV на Sui

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

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

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

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

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

1. Подати пакет транзакцій через м'яке пакування

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Захист користувацьких交易

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

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

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

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

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

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

( Швидкий шлях

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

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

Еволюція MEV Sui

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

![Один текст для розуміння стану та майбутнього MEV на Sui])https://img-cdn.gateio.im/webp-social/moments-6dae0c442b5d72296728a401858cf5ea.webp###