Вступ

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

Цей механізм може бути використаний сьогодні на OP Stack L2, таких як OP Основна мережа, Base і Blast, оскільки ініціатори блоків у цих ланцюжках дотримуються набору правил, які ми називаємо конкурентним пріоритетним порядком.

Щоб запровадити податок на MEV в одному з цих ланцюжків, смарт-контракт стягує комісію, яка є функцією пріоритетної комісії транзакції. Ми показуємо, що якщо додаток стягує з пошукачів податок на MEV у розмірі, скажімо, 99 доларів США за кожен 1 долар США пріоритетного збору, він може отримати 99% конкурентоспроможного MEV для цієї транзакції.

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

У дослідженні MEV ми показуємо, як MEV податки можуть бути використані для вирішення трьох основних проблем:

• Децентралізовані біржа (DEX) маршрутизатори, які оптимізують ціну, отриману своппером
• Автоматизовані маркет-мейкери (AMM), які мінімізують збитки та ребалансування (LVR), з якими стикаються постачальники ліквідності
• Гаманці, які дозволяють своїм користувачам фіксувати будь-які «зворотні» MEV, створені їхніми транзакціями

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

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

Пріоритетне замовлення

Коли хтось надсилає транзакцію на Ethereum L1 або L2, він вказує комісію за пріоритет, яку сплачує ініціатору блоку.1 Ви можете собі уявити, що це вказано як priorityFeePerGas, число, яке множиться на газ, використані в транзакції, щоб отримати builderPriorityFee — загальний платіж у ETH. 2

У Ethereum протокол немає правила, згідно з яким транзакції в блоці повинні бути впорядковані жадібно за спаданням priorityFeePerGas. Тим не менш, це популярний спосіб побудови блоків — наприклад, це алгоритм за замовчуванням, який використовується секвенсерами ланцюгів стеків OP, а також geth і reth. Пріоритетне замовлення не тільки дозволяє трансакторам ефективно висловлювати терміновість своїх транзакцій, але й природним чином спрямовує певні види MEV до ініціатора блоку.

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

У конкурентному сценарії, коли безризиковий прибуток зводиться до нуля, пошуковик-переможець повинен в кінцевому підсумку заплатити повну суму MEV у вигляді пріоритетних комісій. 3 Таким чином, якщо від взаємодії з контрактом можна отримати 100 ETH прибутку, то перша транзакція, яка претендує на нього, встановить пріоритетну комісію в розмірі 100 ETH. (Ми обговорюємо деякі застереження з цього приводу в розділі «Обмеження»).

MEV податки

Припустимо, смарт-контракт хоче захопити MEV з будь-якої транзакції, яка з ним взаємодіє. Існує величезна бібліотека досліджень щодо різних способів, специфічних для конкретних застосувань, які смартконтракти могли б спробувати зафіксувати власну MEV.

Але насправді нам не обов'язково щось знати про додаток. Якщо ми знаємо, що блок будується за допомогою конкурентного пріоритетного замовлення, то у нас є один універсальний сигнал для кількості MEV в транзакції: комісія за пріоритет.

Ми пропонуємо, щоб смарт-контракт міг дивитися на комісію за пріоритет транзакції та стягувати власну комісію як деяку її зростаючу функцію. Наприклад, контракт може вимагати від того, хто його викликає, перенести applicationPriorityFee = 99 * proposerPriorityFee в ETH до контракту. 4

Цю нову комісію сплачує шукач, який надсилає транзакцію, тому вона впливає на поведінку цього пошукача. Якщо в потенційній угоді є 100 MEV, виграшна транзакція тепер встановлюватиме лише пріоритетну комісію в розмірі 1 ETH, оскільки це призведе до загальної виплати 100 ETH (1 ETH ініціатору блоку та 99 ETH смарт-контракту). Будь-яка комісія з вищим пріоритетом зробить транзакцію невигідною; Будь-яка плата за нижчий пріоритет призведе до втрати можливості конкурента, який встановив вищу комісію. Це означає, що смарт-контракт захопив 99% MEV транзакції.

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

Якщо ця плата зростає досить швидко, як функція priorityFeePerGas, то ініціатору буде нараховано лише незначну суму MEV. Оскільки priorityFeePerGas номінований у wei (одна мільярдна частка однієї ETH), ми маємо велику точність для роботи. Наприклад, оскільки лонг податок на MEV є достатньо чутливим, щоб priorityFeePerGas у розмірі 50 000 призвела б до непомірно високого податку, тоді загальна сума платежу ініціатору становитиме менше 0,01 долара США. 5

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

Захоплення MEV однієї програми

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

DEX маршрутизатори У

протоколах маршрутизації DEX на основі намірів, таких як UniswapX і 1inch Fusion, користувач (Аліса) підписує намір здійснити обмін, а шукачі змагаються за маршрут або заповнення цього наміру за найкращою можливою ціною для Аліси.

Поточні версії UniswapX використовують два механізми для проведення цього конкурсу: голландський аукціон, де лімітна ціна Аліси змінюється з часом, доки її не заповнить пошукач, і початковий офчейн-аукціон із запитом на котирування (RFQ) для встановлення початкової ціни цього голландського аукціону.

На платформі, яка гарантує конкурентоспроможне пріоритетне замовлення, UniswapX може замінити їх єдиним механізмом: податком на MEV. Він може реалізувати це, змусивши користувача підписати ордер, який може бути негайно заповнений будь-ким, але з ціною виконання, яка встановлюється як функція пріоритету транзакції.

Наприклад, якщо Аліса має ордер UniswapX, щоб продати 1 ETH, вона може визначити ціну виконання ордер minimumPrice + ($0,01 * priorityFeePerGas). minimumPrice може бути деякою фіксованою вартістю, яка, як вона очікує, буде значно нижчою за поточну ціну.

Шукачі змагалися за заповнення ордер Аліси, надсилаючи транзакції. Будь-яка транзакція з найвищим пріоритетом і не скасовується, заповнить ордер, що має гарантувати, що своппер отримає найкращу ціну, яку можуть знайти шукачі. (Деякі винятки з цього правила обговорюються в розділі «Обмеження».)

Якщо мінімальна ціна Аліси становить 3 000 доларів, а поточна ціна ETH - 3 500 доларів, пріоритет FeePerGas у виграшній транзакції становитиме близько 50 000. (Зауважте, що транзакція, яка коштує 200 000 газ, призведе до виплати лише близько 10 мільярдів wei — близько 0,000035 долара — ініціатору блоку.)

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

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

На відміну від офчейн-запиту на комерційну пропозицію, аукціон для заповнення ордер, який використовує MEV податків, відбуватиметься атомарно з виконанням транзакцій ончейн. Це означає, що переможець торгів може бути гарантований, що він зобов'язується заповнити ордер лише в тому випадку, якщо його ончейн-транзакція буде успішною. Це може полегшити конкуренцію ончейн-ліквідності, як-от AMM, з офчейн-ліквідністю, а це означає, що UniswapX може служити ще ефективнішим маршрутизатором для багатопулових систем, таких як Uniswap v4.

AMM

Зазвичай AMM передають вартість арбітражникам, які торгують проти застарілих цін у верхній частині блоку, як обговорювалося в loss-vs-rebalancing papers. Ми можемо використовувати MEV податки, щоб AMM фіксували цю MEV. Щоб спростити завдання, ми обговоримо, як це може працювати на AMM без концентрованої ліквідності. (Якщо вас цікавить, як можна вирішити подібну проблему за допомогою концентрованої ліквідності, Sorella скоро опублікує одне рішення.)

AMM може захопити MEV, стягуючи додаткову комісію як функцію пріоритетної комісії за транзакцію, що дозволяє йому виставити на аукціон право торгувати першим у блоці. Існує багато способів обчислення та деномінації цього збору. Ми обговоримо один, можливо, нейтральний — деномінацію в одиницях ліквідності пулу, sqrt(xy). Виграшною транзакцією буде та, яка найбільше збільшить ліквідність пулу.

При виконанні першої транзакції в пулі в блоці, замість того, щоб застосовувати умову x_end y_end > x_start y_start, пул може примусово виконати умову (з a як деякою константою):

x_end y_end > (sqrt(x_start y_start) + a*priorityFeePerGas)^2

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

Після цієї першої транзакції угоди можуть працювати так само, як і на Uniswap v2, з фіксованою комісією за своп. Необізнані транзакції, які хочуть торгувати на пулі без сплати додаткового податку MEV, встановлюватимуть комісію з низьким пріоритетом.

Існує багато інших способів запровадження MEV податків на AMM, які матимуть різні наслідки. Наприклад, MEV податки можуть бути деноміновані у вхідному або вихідному токені свопу, можуть впливати на відсоток комісії за своп, що застосовується пулом, або можуть визначати мінімальну ціну угоди користувача. Ми вважаємо, що це цікавий простір для вивчення.

Backrunning auctions

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

Наприклад, коли Аліса здійснює велику транзакцію на AMM, вона іноді створює арбітражну можливість для «бекраннерів», щоб повернути ціну назад. Зазвичай це просочується до MEV, а не до Аліси.

MEV-Share і MEVBlocker - це два протоколи, які дозволяють користувачам отримувати MEV зі своїх транзакцій, але вони покладаються на складну систему офчейн-аукціонів. Простір дизайну аукціону Orderflow описує деякі інші рішення.

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

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

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

Інші випадки використання

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

• Протоколи, за допомогою яких оракули фіксують створену ними вартість оракула, як-от Аукціони овального
• рефінансування в протоколах кредитування із забезпеченням NFT, як-от Blend
• Lending протокол ліквідації, які менше витікають вартості, ніж голландські аукціони

Перехресне захоплення MEV додатків

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

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

Але що робити, якщо транзакція пошукача взаємодіє з двома додатками, які використовують MEV податки? Наприклад, що робити, якщо є деякі MEV, які можна отримати, лише заповнивши один із MEV оподатковуваних ордерів UniswapX, описаних вище, проти AMM, оподатковуваного MEV?

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

tax_1(priorityPerGas) + tax_2(priorityPerGas) = загальна MEV

(Технічно ми могли б додати третій термін для пріоритетуPerGas * gasВикористовується для рахунок для плати за пріоритет, що сплачується ініціатору блоку, але ми проігноруємо це, оскільки, як обговорювалося в Додатку А, вона, ймовірно, буде незначною за звичайних умов.)

У простому випадку MEV податків, які є лінійними за пріоритетомPerGas (так tax_1(priorityPerGas) = a_1 * priorityPerGas), можна вирішити для частки MEV, отриманих кожною заявкою:

a_1 priorityPerGas + a_2 priorityPerGas = MEV

priorityPerGas = MEV/(a_1 + a_2)

tax_1(priorityPerGas) = (a_1/(a_1+a_2))*MEV

tax_2(priorityPerGas) = (a_2/(a_1+a_2))*MEV

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

У багатьох випадках може існувати рівновага, коли два додатки розробляють свої MEV податки, ордер розподіляти MEV таким чином, щоб максимізувати кожен свій добробут. Наприклад, AMM з MEV податками, швидше за все, захоче отримати цінність від одного поінформованого трейдера у верхній частині блоку, але потім захоче надати ліквідність іншим трейдерам і додаткам (у тому числі тим, які використовують MEV податки) з низькою фіксованою комісією. У цьому випадку AMM, швидше за все, встановить відносно низький податок на MEV (скажімо, 0,00001 $ priorityFeePerGas), щоб арбітражна транзакція (якщо така є) відбувалася на початку блоку, а потім не стягувала MEV податку на наступні транзакції в блоці. Такі додатки, як UniswapX, які хочуть взаємодіяти з AMM, можуть встановити набагато вищий податок на MEV (скажімо, 0,01 долара США priorityFeePerGas), щоб гарантувати, що їхні транзакції будуть включені після того, як пул вже буде арбітражований. З цими відносними податками AMM в кінцевому підсумку опиниться першим, навіть якщо на ньому буде лише 1 долар з MEV і 50 000 доларів MEV у ордер UniswapX.

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

Обмеження

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

Несумісність стимулів

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

• Пріоритетне замовлення. Транзакції всередині блоку повинні бути впорядковані в спадному ордер priorityFeePerGas.
• Цензура-спротив. Якщо ініціатор блоку отримує транзакцію t1 під час блоку, і блок або не заповнений, або включає якусь транзакцію t2 таку, що t2.priorityFeePerGas < t1.priorityFeePerGas, тоді блок повинен включати транзакцію t1.
• Конфіденційність перед транзакцією. Ініціатор блоку повинен приймати транзакції через приватну кінцеву точку і не повинен ділитися такими транзакціями з будь-ким іншим, перш ніж взяти на себе зобов'язання щодо блоку, або використовувати вміст цих транзакцій як вхідні дані для побудови власних транзакцій.
• Без останнього погляду. Ініціатор блоку повинен встановити певний час blockTime, до якого він приймає транзакції від будь-кого, і після закінчення якого він не приймає транзакції ні від кого.

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

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

За відсутності правозастосування на рівень протоколу, одному секвенсеру, який дотримується цих правил, потрібно довіряти, щоб він не відхилявся від них, і якщо ініціатори передають створення блоків на аутсорсинг конкурентному аукціону з максимізацією доходу (наприклад, MEV-Boost Ethereum L1), блоки, швидше за все, не будуть їх дотримуватися.

Ці проблеми можуть бути «вирішені» за допомогою одного довіреного секвенсора, який зобов'язується використовувати конкурентне пріоритетне впорядкування для побудови блоків. Вони також можуть бути вирішені за допомогою децентралізованого механізму з використанням певної комбінації консенсусу, криптографії та/або довірених середовищ виконання, таких як Angstrom від Sorella, SUAVE від Flashbots, Аукціони без лідера, або Множинність.

Повні блоки Один

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

Скасовані транзакції

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

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

Витік намірів

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

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

Наприклад, припустимо, що Аліса хоче придбати токен з низькою ліквідністю за допомогою аукціону, описаного вище, протокол описано вище. Вона публікує підписаний намір для свого гаманця смарт-контракту придбати цей токен на AMM, встановлюючи певний допуск до прослизання. Пошукачі можуть наввипередки підштовхнути ціну цього токена до її толерантності до прослизання в транзакції з високим пріоритетом, не заповнюючи ордер користувача. Переможець, Боб, міг би поза конкуренцією задовольнити намір Аліси, включивши її в транзакцію з низьким пріоритетом, таким чином затиснувши угоду Аліси і давши їй гіршу ціну, ухилившись від сплати податку на MEV. Аналогічна проблема може статися і з купівлею NFT.

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

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

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

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

Обговорення та попередня робота

Пріоритетні газ аукціони. Деяка динаміка пріоритетного впорядкування в децентралізованих блокчейнах була вивчена в статті Flash Boys 2.0, в якій був введений термін "майнерська видобувна цінність". У цьому документі зазначалося, що Ethereum майнери (коли ця мережа використовувала proof-of-work) вже впорядковували транзакції за пріоритетом, і що арбітражери покладалися на цю поведінку для участі в «аукціонах пріоритетних газ», в яких вони робили ставки за право бути включеними першими в блок, що призвело до того, що більша частина MEV від децентралізованого арбітражу біржа нараховувалася майнерам.

Перший прийшов – перший обслужений. Деякі спроби пом'якшити MEV за допомогою правил упорядкування транзакцій, таких як Themis або Arbitrum Поточний секвенсор <a href="https://www.paradigm.xyz/2024/06/priority-is-all-you-need#user-content-fn-7">7 були зосереджені на забезпеченні дотримання іншого правила впорядкування, першим прийшов - першим обслужений (іноді це називається "справедливим порядком"), де ініціатори блоку повинні ордер транзакції в тому ордер, в якому вони їх бачать.

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

Першим прийшов – першим обслуженим важко забезпечити або навіть визначити в реальному мережевому середовищі з більш ніж одним валідатором. Це також може призвести до марнотратних затримка перегонів і спаму навіть з одним надійним секвенсором. Нарешті, MEV податки можуть бути в змозі усунути певні види MEV, які не можуть бути зроблені в порядку живої черги, наприклад, арбітражний прибуток від переривчастих «стрибків» цін на активи. Потенційні переваги пріоритетного замовлення перед замовленням у порядку живої черги певною мірою пов'язані з перевагами дискретного часу над безперервним обміном, розглянутими в Budish, Cramton, Shim (2015).

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

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

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

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

Було проведено значне попереднє обговорення кожного з інших об'єктів, необхідних для конкурентного пріоритетного замовлення. Наприклад, у Fox, Pai, Resnick (2023) автори обговорюють вразливості в ончейн-аукціонах за відсутності З спротивом до цензури та описують дизайн аукціону, стійкого до цензури, використовуючи кілька одночасних пропозицій. Однак вони не припускають конкретного порядку транзакцій.

Були й інші дослідження щодо побудови механізмів побудови блоків з мінімізацією довіри, зокрема Flashbots SUAVE, Sorella's Angstrom, Аукціони без лідерів, Espresso та Offchain Labs" @espressosys/espresso-systems-and-offchain-labs-release-r-d-roadmap-for-decentralized-timeboost-5d0007dff66d">decentralized Timeboost і обов'язкове включення публічних транзакцій Петером Сілагі (Péter Szilági).

Висновок

Ми сподіваємося, що ця публікація заохотить L2 розглянути можливість використання пріоритетного впорядкування (яке підтримується за замовчуванням у стеку OP) і надихне додатки спробувати MEV податки, де це підтримується.

Ми також сподіваємося, що це стимулюватиме подальші дослідження протоколів для мінімізованого до довіри порядку конкурентних пріоритетів як на L1, так і на L2. Якщо ви зацікавлені у співпраці над цією проблемою і читаєте це до четверга, 6 червня, ви все ще можете подати заявку на стипендію TLDR для роботи над MEV-стійкими секвенсерами L2 з Деном. Або не соромтеся просто звертатися до dan@paradigm.xyz та dave@paradigm.xyz з ідеями!

Примітки

1. У цій публікації ми використовуємо "offerer" для позначення суб'єкта або процесу, який визначає, які транзакції включаються в певний блок. На Ethereum L2 цю роль зазвичай виконує «секвенсор». На Ethereum L1 він заповнюється спеціальним валідатором Ethereum, який називається ініціатором, хоча часто ініціатор передає завдання зі створення блоку на аутсорсинг конкурентному аукціону, в якому беруть участь «ретранслятори» та «будівельники». Подробиці того, як розподіляються ці обов'язки, виходять за рамки цієї публікації. ↩
2. Комісія за пріоритет за газ фактично не вказується явно в транзакції, але може бути обчислена в ній. У транзакції вказується ціна на газ, але Ethereum також стягує базову комісію, яка виводиться з ціна на газ і спалюється. Базовий збір слід ігнорувати для цілей MEV податків, оскільки він не знаходиться під контролем трансактора. Комісія за пріоритет за газ — ціна за частину комісії за транзакцію, яка надходить ініціатору блоку — може бути обчислена в Solidity як priorityGasPrice = tx.gasprice - block.basefee. ↩
3. Крім того, ми могли б просто визначити "MEV", щоб виключити будь-який прибуток пошуковика, і посилатися лише на значення, яке надійде валідатору. ↩
4. Зверніть увагу, що proposerPriorityFee — дорівнює priorityFeePerGas, помноженому на загальну газ, використану в транзакції — фактично не може бути розрахована під час контракту, оскільки немає способу дізнатися, скільки газ в кінцевому підсумку буде використано транзакцією. Однак, як правило, це не має значення, оскільки все, що нам потрібно, це верхня межа для цього. Щоб перестрахуватися, ви можете помножити priorityFeePerGas на 30 мільйонів — поточний максимальний газ у Ethereum блоці. Завищення цього значення просто означатиме, що MEV податок захоплює ще більший відсоток MEV. ↩
5. Якщо припустити, що транзакція не може перевищувати 30 мільйонів газ, то priorityFeePerGas у розмірі 50 000 призведе до газ платежу в розмірі 1500 gwei — близько 0,006 долара США за ціною ETH 4000 доларів США. ↩
6. У випадку, коли priorityFeePerGas встановлено таким чином, що прибуток арбітражник дорівнює нулю, арбітражна угода, що максимізує прибуток, повинна відповідати тій самій угоді на -функція-максимізує AMM. Доведення цього залишається для читача вправою. ↩
7. Arbitrum обговорював заміну цього на форму пріоритетного впорядкування під назвою Timeboost, але на момент написання цієї статті вона не була запущена у виробництво. ↩

Відмова від відповідальності:

1. Ця стаття передрукована з [paradigm]. Усі авторські права належать оригінальному автору [Dan Robinson & Dave White]. Якщо є заперечення проти цього передруку, будь ласка, зв'яжіться з командою Gate Learn, і вони оперативно впораються з цим.

2. Відмова від відповідальності: Погляди та думки, висловлені в цій статті, належать виключно автору і не є жодною інвестиційною порадою.

3. Переклад статті на інші мови здійснює команда Gate Learn. Якщо не зазначено, копіювання, розповсюдження або плагіат перекладених статей заборонено.