Вступ

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

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

Для впровадження податку MEV на одному з цих ланцюжків смарт-контракт бере плату, яка є функцією пріоритетної плати за транзакцію. Ми показуємо, що якщо додаток бере в пошуковиків податок MEV у розмірі (скажімо) 99 доларів за кожен долар пріоритетної плати, він може захопити 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 немає правила, що транзакції в блоках повинні бути упорядковані жадібно за спадаючим пріоритетомFeePerGas. Однак це популярний спосіб побудови блоків, наприклад, це типовий алгоритм, який використовується послідовниками Gate.OP Stackланцюги, а також geth та reth. Пріоритетне упорядкування дозволяє трансакціонерам ефективно виражати терміновість своїх транзакцій, а також природно направляє певні види MEV до пропонента блоку.

Це трапляється через те, що пріоритетне упорядкування перетворює конкуренцію за MEV впріоритетний газовий аукціон. Коли є можливість заробляти на взаємодії з ланцюжком, наприклад, арбітражуючи 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 виражений у вей (один мільярдний долю мільярдного долю одного ETH), у нас є багато точності для роботи. Наприклад, доки MEV-податок достатньо чутливий, що priorityFeePerGas у розмірі 50 000 призведе до надто високого податку, загальна виплата пропонентові буде менше $0.01.5

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

Захоплення MEV одним додатком

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

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

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

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

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

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

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

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

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

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

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

AMM

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

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

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

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

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

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

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

Аукціони з відступом

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

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

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

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

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

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

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

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

• Протоколи для оракулів, які захоплюють створену ними вартість, якОвальний
• Рефінансування аукціонів в протоколах кредитування з заставою в NFT, як Змішувати
• Протоколи кредитування ліквідації, які витік менше значенняніж голландські аукціони

Перехоплення MEV між додатками

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

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

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

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

tax_1(priorityPerGas) + tax_2(priorityPerGas) = total MEV

(Технічно ми могли б додати третій термін для priorityPerGas * gasUsed для врахування пріоритетної плати, яку сплачується пропоненту блоку, але ми ігноруватимемо це, оскільки, як вже обговорено в Додатку A, ймовірно, це буде знехтувати в звичайних умовах.)

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

a_1 priorityPerGas + a_2пріоритетPerGas = 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.00001priorityFeePerGas), щоб арбітражна транзакція (якщо така є) відбувалася на початку блоку, а потім не брати податок MEV з наступних транзакцій у блока. Додатки, які хочуть взаємодіяти з AMM, можуть встановити значно вищий податок MEV (скажімо, $0.01 priorityFeePerGas), щоб забезпечити включення їх транзакцій після того, як пул вже буде проарбітражований. З цими відносними податками AMM в кінцевому підсумку першим було б проарбітражувати навіть у випадку, якщо на ньому було лише $1 MEV і $50,000 MEV у замовленні UniswapX.

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

Обмеження

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

Несумісність заохочення

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

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

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

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

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

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

Повні блоки

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

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

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

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

Витікання намірів користувачів

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

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

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

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

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

Можливо, також можна поєднати податки MEV з функціями конструктора, які розроблені з урахуванням конфіденційності, як це передбачено в дизайнах Flashbots для СУАВЕ.

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

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

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

Перший прийшов, перший обслужений. Деякі спроби зменшення MEV за допомогою правил упорядкування транзакцій, такі як ТемідаабоПоточний послідовник Arbitrum One,7зосередилися на впровадженні іншого правила упорядкування, перший прийшов, перший послужив (іноді його називають «справедливим упорядкуванням»), де пропоненти блоків повинні упорядковувати транзакції в порядку, в якому вони їх бачать.

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

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

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

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

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

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

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

Існували інші дослідження з побудови механізмів для мінімізації довіри до блокування, включаючи Flashbots’sВИТОНЧЕНИЙ, Sorella's Ангстрем, Лідерлес аукціони, Espresso та Offchain Labs’ @espressosys/espresso-systems-and-offchain-labs-release-r-d-roadmap-for-децентралізований Timeboost, and обов'язкове включення публічних транзакцій by Péter Szilági.

Висновок

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

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

Примітки

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

Disclaimer：

1. Ця стаття перепечатана з [ парадигма], Усі авторські права належать оригінальному авторові [Ден Робінсон, Dave White]. Якщо є заперечення щодо цього перепублікування, будь ласка, зв'яжіться Gate Learnкоманда, і вони оперативно з цим впораються.
2. Відповідальність за відмову: Погляди та думки, висловлені в цій статті, є виключно тими автора і не становлять жодної інвестиційної поради.
3. Переклади статті на інші мови виконуються командою навчання Gate. Якщо не зазначено інше, копіювання, поширення або плагіатування перекладених статей заборонене.