Зі збільшенням активності в блокчейні та еволюцією та збагаченням інфраструктури блокчейну, MEV в блокчейні завжди вважався найнебезпечнішою частиною темного лісу Ethereum, що безпосередньо призвело до втрати прибутку та погіршення досвіду користувачів у фінансовій діяльності в блокчейні. Метою цієї статті «Освітлення темного лісу» є підкреслити проблеми природної централізації та довіри, які виникають у результаті механізму генерації блоків Ethereum 2.0 та технологічного прогресу розділення пропозиційників та будівельників (PBS), які мають абсолютно протилежну ситуацію з цінностями Ethereum.
Посилення MEV в блокчейні справді є двосічним мечем, має свої позитивні та негативні зовнішні ефекти. Позитивні включають зменшення цінових різниць на DEX, допомогу в ліквідації угод; негативні включають шкоду від атаки через вкладення для користувачів. Отже, рішення для MEV більше зосереджені на зменшенні негативних зовнішніх ефектів, а не на їх повному усуненні. У процесі дослідження механізмів, які зменшують негативні зовнішні ефекти MEV та вирішують нинішні проблеми з довірою до посередників, ми поділяємо заходи на три категорії: покращення механізму аукціонів, покращення рівня консенсусу, покращення на рівні додатків. Ці три поліпшення в різній мірі вплинуть на сучасну картину MEV, проте деякі рішення не можуть суттєво вирішити проблему атак через вкладення, оскільки угоди користувачів залишаються в загальному пулі. Тому необхідно впровадити більше технологій приватного пулу для захисту вибіркової конфіденційності угод користувачів, ці рішення для MEV заслуговують на те, щоб їх спробувати поєднати.
Крім того, MEV, як невідворотний побічний продукт механізму дизайну, в майбутньому стане ще більш складним. Ми також досліджували в тексті можливі технічні виклики та можливості для MEV, які можуть виникнути в умовах впровадження нових типів транзакцій, таких як архітектура Layer2 і абстракція облікових записів EIP-4337.
Насамкінець, ми сподіваємось, що ця стаття дослідить потенційні рішення проблеми зменшення негативних зовнішніх ефектів MEV, а також забезпечить всебічне розуміння переваг і недоліків поточних рішень MEV, не лише для освітлення темного лісу, в якому перебувають користувачі, але й для освітлення темного лісу для дослідників у галузі для подальшого вивчення MEV.
Ethereum 2.0
З моменту The Merge Ethereum впровадив механізм POS для забезпечення безпеки мережі, одночасно відмовившись від конкурентної боротьби, що вимагає великих обчислювальних ресурсів, і перейшовши на доказ частки. Після злиття Ethereum було поділено на виконавчий шар та шар консенсусу. А також відбулося зміна у виробництві блоків, кожен Epoch є одним циклом POS, кожен Epoch поділяється на 32 слоти, кожен слот відповідає одиниці часу для створення блоку, що становить 12 секунд.
Уся мережа кожного етапу (Epoch) випадковим чином обирає комітет з валідаторів, пропонент блоку випадковим чином обирається з цього набору комітету. Пропонент блоку повинен упакувати транзакції та виконати їх у певному порядку, щоб в результаті отримати блок. Інші валідатори комітету контролюють цей процес, після чого голосують за блок. Цей комітет буде переобраний після кожного етапу. Одночасно накладаються певні обмеження за часом виконання, щоб гарантувати ефективність генерації блоків і голосування. Тут ми стандартизуємо терміни для читачів: Payload – це виконуване навантаження, що означає зміну статусу транзакцій, його можна розглядати як частину виконання блоку. Пропонент блоку реалізує виконуване навантаження (Execution Payload, що є реалізацією зміни статусу транзакцій ) та пропозицією блоку.
Архітектура PBS
Насправді, коли валідатор обирається на роль пропозиції блоку, часто пропонент не має мотивації виконувати Payload, тобто виконувати сортування транзакцій та їх виконання, оскільки це потребує великої обчислювальної потужності для виконання змін стану. Спочатку думали, що якщо ми оберемо децентралізовану комісію, і якщо включимо виконання навантаження, тоді сортування транзакцій стане децентралізованим процесом. Але валідатори, здається, природно хочуть передати цю частину на виконання третім особам, а самі зосередитися на пропозиції блоку. Таким чином, виникла концепція PBS, яка полягає в тому, що пропозиція блоку і побудова відокремлені: пропоненти лише відповідають за верифікацію блоку, не беручи участі в побудові блоку. Розділення між пропонентами та будівельниками сприяє відкритому ринку, на якому пропоненти блоку можуть отримати блок від будівельників. Ці будівельники змагаються один з одним за побудову блоків і пропонують пропонентам найвищу винагороду, що ми називаємо "аукціоном блоків".
Ми коротко представимо всю модель першого аукціону PBS(Proposer Builder Seperate). Коли користувач подає транзакцію через проксі, проксі фактично виконує функцію вузла, подаючи транзакцію до публічного Mempool. Кілька Builder знаходять найбільш підходящі транзакції для сортування з метою створення блоку з максимізацією прибутку(, що означає максимізацію прибутку від комісій за транзакції Base+Priority+MEV). Потім кілька Builder взаємодіють з Proposer через MEV-Boost, що є мостом між кількома Builder і Proposer. Builder подає пропозиції, подаючи Proposer кілька заголовків блоків і відповідні пропозиції, зазвичай Proposer приймає блок з найвищою пропозицією. У цьому процесі реалізується специфікація MEVBboost, яка є технічною нормою, що визначає, як нормувати взаємодію між Builder та Proposer під час аукціону. У цьому процесі вся інформація є закритою, і лише заголовки блоків подаються Proposer, тому Proposer має стійкість до цензури.
Учасники та ігри в рамках PBS
Основними учасниками є Builder, Proposer, MEVbot(, Searcher).
Будівельник
Builder, в першу чергу, відповідає за створення вмісту блоку. Використовуючи технологію MEV-Boost, він має більш вигідну позицію в торгах, оскільки підтримує не лише Gas Fees, але й прибутки від MEV. Builder може безпосередньо перевіряти транзакції користувачів і Searcher'ів, що завжди викликало критику, особливо після того, як уряд США оприлюднив OFAC. Після цього багато Builder'ів взяли участь в OFAC Compliant. На відміну від початку, хоча частка перевірки блоків в останній час зменшилася, ми можемо побачити, що в процесі створення блоку Builder безпосередньо впливає на перевірку транзакцій.
З огляду на поточну частку ринку Builder, чисті безперевірені Build поступово розширюють свою частку ринку, все орієнтоване на прибуток.
Пошуковик
По суті, робота з максимізації прибутку вимагає спільних зусиль Searcher і Builder. Searcher часто співпрацює з конкретними Builder, в результаті чого формується Dark Pool або Private Pool, де угоди Searcher відображаються лише для конкретного Builder. Деякі Builder отримують MEV-угоди з максимізованим прибутком, що дозволяє їм конкурувати за блочний простір. Теоретично, якщо Builder чинить зло або проводить цензуру, Searcher може вибрати інших Builder, що призведе до поступового зниження ринкової частки Builder. Тому, підпорядковуючись Searcher, Builder зазвичай враховує приховані витрати на злочин. На наведеній вище графіці показано, як виглядає прибуток від MEV та щоденний Gas, можна побачити, що внесок MEV від Searcher у випадках значних коливань ринку може навіть удвічі перевищувати щоденний прибуток від Gas.
Для Searcher розрізняють CEX-DEX( арбітраж поза ланцюгом) та DEX, девелоперський, ліквідаторський два основні категорії( чисто ланцюговий).
На даний момент одна з торгових платформ займає перше місце за часткою ринку арбітражної торгівлі між CEX та DEX.
Що стосується чистих можливостей MEV на блокчейні, то спостерігається поступова тенденція до формування студій, де частка певного рахунку досягає вражаючих 37.2%, спеціалізуючись на виконанні сандвіч-атак на користувачів блокчейну, що зробило його найбільшим споживачем газу на блокчейні, який витрачав приблизно 1.5% газу за весь день. З лютого 2023 року по червень 2024 року цей бот витратив усього 76,916 ETH, що за значенням під час виконання цих транзакцій становить приблизно 175 мільйонів доларів. Оскільки між Seacher і Builder існує тісний зв'язок, на практиці багато Seacher надсилають свої замовлення трьом найкращим Builder, хоча насправді можна було б транслювати всім Builder, але деякі менші Builder можуть розподілити замовлення Seacher, що призводить до невдачі MEV-стратегії Seacher і, отже, до ризику збитків. Крім того, прив'язка до Builder також може допомогти підтримувати вплив у екосистемі.
Відповідає за збирання аукціонів, а потім як проміжна зупинка передає Proposer заголовок блоку та ціну на аукціон блоку, у цей момент Proposer не знає деталей транзакцій у блоці. Як тільки Proposer вибирає і підписує заголовок блоку, вся транзакційна інформація буде надана Proposer. Ми помічаємо, що в цьому процесі, як третя сторона без економічних стимулів, отримала величезну довіру, Builder залежить від Poposer для визначення цін, а Proposer покладається на ці ціни та зміст блоку. В історії також відбувалися подібні проблеми, існувала потенційна вразливість, яка призвела до того, що Proposer витягнув понад 20 мільйонів доларів MEV. Хоча ці вразливості можна виправити, сама система все ще може вибрати зловмисну поведінку та викрасти MEV.
На зображенні наведено ситуацію з часткою ринку, ми побачимо, що ринкова частка Builder, який працює виключно з MAX Profit, поступово зростає з моменту Merge, тому в умовах вільного ринку неможливо штучно контролювати MEV через Builder.
Одночасно існує проблема, а саме відсутність економічних стимулів. Тому деяка компанія також вийшла з розробки в цьому напрямку. Наразі все залежить від запропонованого стандарту MEVBoost, щоб побудувати, Ефір залежить від третіх сторін для надання PBS, що завжди не може бути довготривалою стратегією, тому наразі спільнота Ефіру також досліджує можливість включення PBS на рівні протоколу.
Пропозер
Для Пропозера алгоритмічно випадково обирається група комітету серед усіх валідаторів, а в кожному слоті обирається один блок-пропонент, при цьому сам блок-пропонент має можливість виконувати навантаження. Однак, оскільки пропонент природно прагне делегувати цю частину, це може призвести до вертикальної співпраці між Builder та Пропозером. MEV-boost має на меті стати проміжною ланкою в цьому процесі, щоб зменшити вертикальну співпрацю та змову, що виникають внаслідок прямого спілкування між ними. Оскільки зараз всі знаходяться в майнінгових пулах як валідатори, ці майнінгові пули та пула валідаторів LSD мають сильний масштабний ефект, особливо з появою LSD, яка розкриває потенціал закладених токенів, підвищуючи капітальну ефективність, а також вплив складових DEFI, валідаторські пули опиняються під більшим тиском централізації.
Деяка платформа наразі займає близько 28,7% ринкової частки, деяка біржа, деяка платформа займає друге-третє місце. У минулому, коли не було активно впроваджено рішення MEV-BOOST PBS, Пропозер мав виконувати завдання Будівельника, тобто виконувати навантаження (Payload), але більшість Пропозерів відмовилися від власної здатності виконувати сортування транзакцій, оскільки це вимагає значних обчислювальних потужностей, що серйозно вплине на продуктивність верифікації, і краще передати виконання навантаження на аутсорсинг, щоб третя сторона могла аукціонувати блоки.
Користувач
Нарешті, поговоримо про користувача. Користувачі часто перебувають у найслабшій позиції в усій архітектурі, оскільки їхні транзакції потрапляють до Mempool, звідки різні MEV-боти отримують прибуток від MEV. Однак цей прибуток не потрапляє до користувачів. Але це не завжди погано. Наприклад, на деяких DEX, коли ринкові коливання в мережі значні або обсяги торгівлі користувача перевищують ліквідність DEX, MEV-боти можуть використовувати арбітраж для зменшення слippage та цінових різниць між платформами. Таким чином, існування MEV має як позитивні, так і негативні зовнішні ефекти, які потрібно розглядати окремо, і це є його складною частиною.
Щоб не дозволити користувачам бути під спостереженням MEVbot, що може завдати шкоди користувачам, багато постачальників вузлів можуть допомогти користувачам розміщувати транзакції в непублічному Mempool, наприклад, можна безпосередньо взаємодіяти з Builder через Builder. Існує досить новий спосіб - через OFA(Order Flow Auction.
This page may contain third-party content, which is provided for information purposes only (not representations/warranties) and should not be considered as an endorsement of its views by Gate, nor as financial or professional advice. See Disclaimer for details.
18 лайків
Нагородити
18
5
Поділіться
Прокоментувати
0/400
BearWhisperGod
· 07-09 16:42
Хто ж не був обкрадений?
Переглянути оригіналвідповісти на0
RektDetective
· 07-07 04:39
Граємо зрозуміло, не можемо ухилитися, не втечемо, ха-ха
Переглянути оригіналвідповісти на0
GameFiCritic
· 07-07 04:33
Замість того, щоб говорити про pbs, краще спочатку оптимізувати газ.
Переглянути оригіналвідповісти на0
TokenGuru
· 07-07 04:30
MEV цю справу 15 років переходять BTC старі майнери розуміють
Переглянути оригіналвідповісти на0
WhaleWatcher
· 07-07 04:26
Темний ліс дуже страшний. Новачок, обережно входьте.
Розкриття темного лісу MEV: можливості та виклики для торгівлі на у блокчейні Ethereum
Освітлення темного лісу: зняття таємниці MEV
Зі збільшенням активності в блокчейні та еволюцією та збагаченням інфраструктури блокчейну, MEV в блокчейні завжди вважався найнебезпечнішою частиною темного лісу Ethereum, що безпосередньо призвело до втрати прибутку та погіршення досвіду користувачів у фінансовій діяльності в блокчейні. Метою цієї статті «Освітлення темного лісу» є підкреслити проблеми природної централізації та довіри, які виникають у результаті механізму генерації блоків Ethereum 2.0 та технологічного прогресу розділення пропозиційників та будівельників (PBS), які мають абсолютно протилежну ситуацію з цінностями Ethereum.
Посилення MEV в блокчейні справді є двосічним мечем, має свої позитивні та негативні зовнішні ефекти. Позитивні включають зменшення цінових різниць на DEX, допомогу в ліквідації угод; негативні включають шкоду від атаки через вкладення для користувачів. Отже, рішення для MEV більше зосереджені на зменшенні негативних зовнішніх ефектів, а не на їх повному усуненні. У процесі дослідження механізмів, які зменшують негативні зовнішні ефекти MEV та вирішують нинішні проблеми з довірою до посередників, ми поділяємо заходи на три категорії: покращення механізму аукціонів, покращення рівня консенсусу, покращення на рівні додатків. Ці три поліпшення в різній мірі вплинуть на сучасну картину MEV, проте деякі рішення не можуть суттєво вирішити проблему атак через вкладення, оскільки угоди користувачів залишаються в загальному пулі. Тому необхідно впровадити більше технологій приватного пулу для захисту вибіркової конфіденційності угод користувачів, ці рішення для MEV заслуговують на те, щоб їх спробувати поєднати.
Крім того, MEV, як невідворотний побічний продукт механізму дизайну, в майбутньому стане ще більш складним. Ми також досліджували в тексті можливі технічні виклики та можливості для MEV, які можуть виникнути в умовах впровадження нових типів транзакцій, таких як архітектура Layer2 і абстракція облікових записів EIP-4337.
Насамкінець, ми сподіваємось, що ця стаття дослідить потенційні рішення проблеми зменшення негативних зовнішніх ефектів MEV, а також забезпечить всебічне розуміння переваг і недоліків поточних рішень MEV, не лише для освітлення темного лісу, в якому перебувають користувачі, але й для освітлення темного лісу для дослідників у галузі для подальшого вивчення MEV.
Ethereum 2.0
З моменту The Merge Ethereum впровадив механізм POS для забезпечення безпеки мережі, одночасно відмовившись від конкурентної боротьби, що вимагає великих обчислювальних ресурсів, і перейшовши на доказ частки. Після злиття Ethereum було поділено на виконавчий шар та шар консенсусу. А також відбулося зміна у виробництві блоків, кожен Epoch є одним циклом POS, кожен Epoch поділяється на 32 слоти, кожен слот відповідає одиниці часу для створення блоку, що становить 12 секунд.
Уся мережа кожного етапу (Epoch) випадковим чином обирає комітет з валідаторів, пропонент блоку випадковим чином обирається з цього набору комітету. Пропонент блоку повинен упакувати транзакції та виконати їх у певному порядку, щоб в результаті отримати блок. Інші валідатори комітету контролюють цей процес, після чого голосують за блок. Цей комітет буде переобраний після кожного етапу. Одночасно накладаються певні обмеження за часом виконання, щоб гарантувати ефективність генерації блоків і голосування. Тут ми стандартизуємо терміни для читачів: Payload – це виконуване навантаження, що означає зміну статусу транзакцій, його можна розглядати як частину виконання блоку. Пропонент блоку реалізує виконуване навантаження (Execution Payload, що є реалізацією зміни статусу транзакцій ) та пропозицією блоку.
Архітектура PBS
Насправді, коли валідатор обирається на роль пропозиції блоку, часто пропонент не має мотивації виконувати Payload, тобто виконувати сортування транзакцій та їх виконання, оскільки це потребує великої обчислювальної потужності для виконання змін стану. Спочатку думали, що якщо ми оберемо децентралізовану комісію, і якщо включимо виконання навантаження, тоді сортування транзакцій стане децентралізованим процесом. Але валідатори, здається, природно хочуть передати цю частину на виконання третім особам, а самі зосередитися на пропозиції блоку. Таким чином, виникла концепція PBS, яка полягає в тому, що пропозиція блоку і побудова відокремлені: пропоненти лише відповідають за верифікацію блоку, не беручи участі в побудові блоку. Розділення між пропонентами та будівельниками сприяє відкритому ринку, на якому пропоненти блоку можуть отримати блок від будівельників. Ці будівельники змагаються один з одним за побудову блоків і пропонують пропонентам найвищу винагороду, що ми називаємо "аукціоном блоків".
Ми коротко представимо всю модель першого аукціону PBS(Proposer Builder Seperate). Коли користувач подає транзакцію через проксі, проксі фактично виконує функцію вузла, подаючи транзакцію до публічного Mempool. Кілька Builder знаходять найбільш підходящі транзакції для сортування з метою створення блоку з максимізацією прибутку(, що означає максимізацію прибутку від комісій за транзакції Base+Priority+MEV). Потім кілька Builder взаємодіють з Proposer через MEV-Boost, що є мостом між кількома Builder і Proposer. Builder подає пропозиції, подаючи Proposer кілька заголовків блоків і відповідні пропозиції, зазвичай Proposer приймає блок з найвищою пропозицією. У цьому процесі реалізується специфікація MEVBboost, яка є технічною нормою, що визначає, як нормувати взаємодію між Builder та Proposer під час аукціону. У цьому процесі вся інформація є закритою, і лише заголовки блоків подаються Proposer, тому Proposer має стійкість до цензури.
Учасники та ігри в рамках PBS
Основними учасниками є Builder, Proposer, MEVbot(, Searcher).
Будівельник
Builder, в першу чергу, відповідає за створення вмісту блоку. Використовуючи технологію MEV-Boost, він має більш вигідну позицію в торгах, оскільки підтримує не лише Gas Fees, але й прибутки від MEV. Builder може безпосередньо перевіряти транзакції користувачів і Searcher'ів, що завжди викликало критику, особливо після того, як уряд США оприлюднив OFAC. Після цього багато Builder'ів взяли участь в OFAC Compliant. На відміну від початку, хоча частка перевірки блоків в останній час зменшилася, ми можемо побачити, що в процесі створення блоку Builder безпосередньо впливає на перевірку транзакцій.
З огляду на поточну частку ринку Builder, чисті безперевірені Build поступово розширюють свою частку ринку, все орієнтоване на прибуток.
Пошуковик
По суті, робота з максимізації прибутку вимагає спільних зусиль Searcher і Builder. Searcher часто співпрацює з конкретними Builder, в результаті чого формується Dark Pool або Private Pool, де угоди Searcher відображаються лише для конкретного Builder. Деякі Builder отримують MEV-угоди з максимізованим прибутком, що дозволяє їм конкурувати за блочний простір. Теоретично, якщо Builder чинить зло або проводить цензуру, Searcher може вибрати інших Builder, що призведе до поступового зниження ринкової частки Builder. Тому, підпорядковуючись Searcher, Builder зазвичай враховує приховані витрати на злочин. На наведеній вище графіці показано, як виглядає прибуток від MEV та щоденний Gas, можна побачити, що внесок MEV від Searcher у випадках значних коливань ринку може навіть удвічі перевищувати щоденний прибуток від Gas.
Для Searcher розрізняють CEX-DEX( арбітраж поза ланцюгом) та DEX, девелоперський, ліквідаторський два основні категорії( чисто ланцюговий).
На даний момент одна з торгових платформ займає перше місце за часткою ринку арбітражної торгівлі між CEX та DEX.
Що стосується чистих можливостей MEV на блокчейні, то спостерігається поступова тенденція до формування студій, де частка певного рахунку досягає вражаючих 37.2%, спеціалізуючись на виконанні сандвіч-атак на користувачів блокчейну, що зробило його найбільшим споживачем газу на блокчейні, який витрачав приблизно 1.5% газу за весь день. З лютого 2023 року по червень 2024 року цей бот витратив усього 76,916 ETH, що за значенням під час виконання цих транзакцій становить приблизно 175 мільйонів доларів. Оскільки між Seacher і Builder існує тісний зв'язок, на практиці багато Seacher надсилають свої замовлення трьом найкращим Builder, хоча насправді можна було б транслювати всім Builder, але деякі менші Builder можуть розподілити замовлення Seacher, що призводить до невдачі MEV-стратегії Seacher і, отже, до ризику збитків. Крім того, прив'язка до Builder також може допомогти підтримувати вплив у екосистемі.
Відповідає за збирання аукціонів, а потім як проміжна зупинка передає Proposer заголовок блоку та ціну на аукціон блоку, у цей момент Proposer не знає деталей транзакцій у блоці. Як тільки Proposer вибирає і підписує заголовок блоку, вся транзакційна інформація буде надана Proposer. Ми помічаємо, що в цьому процесі, як третя сторона без економічних стимулів, отримала величезну довіру, Builder залежить від Poposer для визначення цін, а Proposer покладається на ці ціни та зміст блоку. В історії також відбувалися подібні проблеми, існувала потенційна вразливість, яка призвела до того, що Proposer витягнув понад 20 мільйонів доларів MEV. Хоча ці вразливості можна виправити, сама система все ще може вибрати зловмисну поведінку та викрасти MEV.
На зображенні наведено ситуацію з часткою ринку, ми побачимо, що ринкова частка Builder, який працює виключно з MAX Profit, поступово зростає з моменту Merge, тому в умовах вільного ринку неможливо штучно контролювати MEV через Builder.
Одночасно існує проблема, а саме відсутність економічних стимулів. Тому деяка компанія також вийшла з розробки в цьому напрямку. Наразі все залежить від запропонованого стандарту MEVBoost, щоб побудувати, Ефір залежить від третіх сторін для надання PBS, що завжди не може бути довготривалою стратегією, тому наразі спільнота Ефіру також досліджує можливість включення PBS на рівні протоколу.
Пропозер
Для Пропозера алгоритмічно випадково обирається група комітету серед усіх валідаторів, а в кожному слоті обирається один блок-пропонент, при цьому сам блок-пропонент має можливість виконувати навантаження. Однак, оскільки пропонент природно прагне делегувати цю частину, це може призвести до вертикальної співпраці між Builder та Пропозером. MEV-boost має на меті стати проміжною ланкою в цьому процесі, щоб зменшити вертикальну співпрацю та змову, що виникають внаслідок прямого спілкування між ними. Оскільки зараз всі знаходяться в майнінгових пулах як валідатори, ці майнінгові пули та пула валідаторів LSD мають сильний масштабний ефект, особливо з появою LSD, яка розкриває потенціал закладених токенів, підвищуючи капітальну ефективність, а також вплив складових DEFI, валідаторські пули опиняються під більшим тиском централізації.
Деяка платформа наразі займає близько 28,7% ринкової частки, деяка біржа, деяка платформа займає друге-третє місце. У минулому, коли не було активно впроваджено рішення MEV-BOOST PBS, Пропозер мав виконувати завдання Будівельника, тобто виконувати навантаження (Payload), але більшість Пропозерів відмовилися від власної здатності виконувати сортування транзакцій, оскільки це вимагає значних обчислювальних потужностей, що серйозно вплине на продуктивність верифікації, і краще передати виконання навантаження на аутсорсинг, щоб третя сторона могла аукціонувати блоки.
Користувач
Нарешті, поговоримо про користувача. Користувачі часто перебувають у найслабшій позиції в усій архітектурі, оскільки їхні транзакції потрапляють до Mempool, звідки різні MEV-боти отримують прибуток від MEV. Однак цей прибуток не потрапляє до користувачів. Але це не завжди погано. Наприклад, на деяких DEX, коли ринкові коливання в мережі значні або обсяги торгівлі користувача перевищують ліквідність DEX, MEV-боти можуть використовувати арбітраж для зменшення слippage та цінових різниць між платформами. Таким чином, існування MEV має як позитивні, так і негативні зовнішні ефекти, які потрібно розглядати окремо, і це є його складною частиною.
Щоб не дозволити користувачам бути під спостереженням MEVbot, що може завдати шкоди користувачам, багато постачальників вузлів можуть допомогти користувачам розміщувати транзакції в непублічному Mempool, наприклад, можна безпосередньо взаємодіяти з Builder через Builder. Існує досить новий спосіб - через OFA(Order Flow Auction.