З ростом активності на ланцюгу та еволюцією й збагаченням інфраструктури на ланцюгу, MEV на ланцюгу завжди вважався найнебезпечнішою частиною темного лісу Ethereum, що безпосередньо призводить до втрат прибутків та погіршення досвіду користувачів у фінансових операціях на ланцюгу. Ця стаття має на меті проаналізувати природну централізацію та проблеми довіри, які виникають у цій системі, на основі механізму генерації блоків Ethereum 2.0 та технологічної еволюції розділення пропонента та будівельника (PBS), що має абсолютно протилежну реальність до цінностей Ethereum.
Зростання MEV в блокчейні дійсно є двосічним мечем, має свої позитивні та негативні зовнішні ефекти. Позитивні включають зменшення цінових розбіжностей на DEX, допомогу в ліквідації транзакцій; негативні включають шкоду від夹层交易 для користувачів. Тому рішення для MEV більше спрямовані на зменшення негативних зовнішніх ефектів, а не на їх повне усунення. В процесі дослідження механізмів зменшення негативних зовнішніх ефектів MEV та вирішення проблеми довіри до посередників третьої сторони (Relayer), основні заходи поділяються на три категорії: покращення аукціонних механізмів, покращення рівня консенсусу, покращення прикладного рівня. Ці три покращення в різній мірі вплинуть на сучасний ландшафт MEV, але частина рішень не може суттєво вирішити проблему атак типу sandwich, оскільки транзакції користувачів все ще знаходяться в public pool, тому необхідно впроваджувати більше технологій приватних пулів для захисту вибіркової приватності транзакцій користувачів, ці рішення MEV заслуговують на спробу комбінувати.
Окрім цього, MEV як невідворотний побічний продукт механізму дизайну в майбутньому ще більше ускладниться. Ми також досліджували в статті можливі додаткові технічні виклики та можливості MEV у контексті впровадження нових типів транзакцій, таких як архітектура Layer2 та абстракція облікових записів EIP-4337.
Нарешті, ми сподіваємося через цю статтю дослідити потенційні рішення для пом'якшення негативних зовнішніх ефектів MEV, а також всебічно усвідомити переваги та недоліки поточних MEV рішень, не лише щоб освітити темний ліс, в якому знаходяться користувачі в майбутньому, але й освітити темний ліс для дослідників галузі для подальшого дослідження MEV.
Ethereum 2.0
Після The Merge Ethereum перейшов на механізм POS для забезпечення мережевої безпеки, одночасно відмовившись від обчислювально інтенсивної конкуренції в виробництві блоків, перейшовши на доказ володіння. Після злиття Ethereum було розділено на виконавчий рівень та рівень консенсусу. Весь процес виробництва блоків також змінився, кожен Epoch є одним циклом POS, кожен Epoch ділиться на 32 слоти, кожен слот відповідає одиниці часу для виробництва блоку, що становить 12 секунд.
Вся мережа кожного разу в Epoch випадковим чином обирає комітет з валідаторів, пропозиція блоку робиться випадковим чином з членів комітету, пропонент блоку повинен упакувати транзакції та впорядкувати їх для виконання, в результаті чого буде створено один блок, інші валідатори комітету будуть контролювати цей процес, а потім голосувати за цей блок. І цей комітет буде переобиратись після кожного Epoch. Також на них накладається певний часовий обмеження на операції, щоб забезпечити ефективність генерації блоків і голосування. Тут ми стандартизували терміни для читачів, Payload — це виконуване навантаження, що означає зміни стану транзакцій, які можна вважати частиною виконання блоку. Пропонент блоку реалізує виконуване навантаження (Execution Payload, тобто реалізує зміни стану транзакцій ) та пропозицію блоку.
Архітектура PBS
Насправді, коли валідатори обираються на роль пропонента блоку, часто пропонент не має стимулу виконувати Payload, тобто впорядковувати транзакції та виконувати їх, оскільки це вимагає великої обчислювальної потужності для виконання зміни стану. Спочатку думали, що якщо ми оберемо комітет через децентралізовану виборчу процедуру, і якщо ми включимо виконання навантаження в цей процес, тоді впорядкування транзакцій стане децентралізованим. Але, здається, валідатори природно хочуть передати цю частину третій стороні, а самі пропоненти зосереджуються на пропозиції блоку. Тому виникла концепція PBS, яка полягає в тому, що пропозиція блоку і його побудова розділені: пропоненти лише відповідають за валідацію блоку, не беручи участі в його побудові. Розділення між пропонентами та будівельниками сприяє відкритому ринку, на якому пропоненти можуть отримувати блоки від будівельників. Ці будівельники конкурують один з одним у побудові блоків і пропонують пропонентам найвищі збори, ми називаємо це "аукціоном блоків".
Ми коротко представимо всю модель аукціону PBS(Proposer Builder Seperate) Seal перше. Коли користувач подає транзакцію через RPC-проксі, RPC фактично запускає вузол, який подає транзакцію в публічний Mempool, кілька Builder знаходять найкращі транзакції для сортування, щоб створити блок з максимізованим прибутком ( максимізація прибутку означає комісії за транзакції Base + Priority + MEV), а потім кілька Builder взаємодіють з Proposer через MEV-Boost Relayer, Relayer є мостом між кількома Builder та Proposer, Builder подає пропозиції Relayer, Relayer подає кілька заголовків блоків та відповідні пропозиції Proposer зазвичай приймає пропозицію з найвищим заголовком. При цьому Relayer реалізує специфікацію MEVBboost, це технічна специфікація, запропонована Flashbot, як регулювати взаємодію Builder та Proposer у торгах. У цьому процесі вся інформація є закритою, Relayer тільки подає заголовки блоків Proposer, тому Proposer має стійкість до цензури.
Учасники та гри в PBS
Його основними учасниками є Builder, Relayer, Proposer, MEVbot(Searcher).
Будівельник
Builder переважно відповідає за створення вмісту блоків. Використовуючи технологію MEV-Boost, він перебуває у більш вигідному становищі під час торгів, оскільки підтримує не тільки плати за газ, а й MEV-доходи. Builder може безпосередньо перевіряти транзакції користувачів і Searcher'ів, що завжди викликало критику, особливо після того, як уряд США оприлюднив OFAC. Після цього багато Builder'ів почали брати участь в OFAC Compliant. Хоча пропорція перевірки блоків нещодавно зменшилася, ми можемо бачити, що під час процесу створення блоків Builder має безпосередній вплив на перевірку транзакцій.
З огляду на поточну частку ринку Builder, такі платформи, як beaverbuild.org, що пропонують повністю безперешкодне будівництво, поступово розширюють свою частку на ринку, все зосереджено на отриманні прибутку.
Пошуковик
По суті, робота з максимізації прибутку потребує спільних зусиль Searcher та Builder. Searcher, як правило, співпрацює з конкретними Builder, що призводить до утворення Dark Pool або Private Pool, де торги Searcher відображаються лише для певного Builder. Деякі Builder отримують максимізовані прибутки від MEV-торгів, а потім конкурують за блоковий простір. З теоретичної точки зору, якщо Builder чинить зло або проводить цензуру, то Searcher може обрати інших Builder, що призведе до поступового зниження частки ринку Builder. Тому, підпорядковуючись Searcher, Builder зазвичай враховує приховані витрати від злочинних дій. На малюнку зображено дохід від MEV та щоденний Gas, де видно, що внесок Searcher в MEV-доходи під час значних коливань ринку може навіть вдвічі перевищувати щоденний дохід від Gas.
Для Searcher розрізняють CEX-DEX( арбітраж поза ланцюгом ) та дві основні категорії DEX, мезонін, ліквідація ( чисто в ланцюзі ).
Наразі Wintermute займає перше місце за часткою ринку арбітражної торгівлі між CEX та DEX.
Щодо чистих можливостей MEV на ланцюгу, спостерігається поступова тенденція до формування студій, де частка ринку jaredfromsubway.eth займає вражаючі 37,2%. Він спеціалізується на атаках-сандвічах на користувачів Ethereum, і став найбільшим споживачем газу на ланцюзі, витрачаючи близько 1,5% газу протягом цілого дня. З лютого 2023 року по червень 2024 року цей бот витратив у загальному 76,916 ETH, що за вартістю виконання цих транзакцій становить близько 175 мільйонів доларів. Оскільки зв'язок між Seacher та Builder є тісним, на практиці багато Seacher відправляють свої замовлення трьом найкращим Builder, хоча насправді могли б транслювати всім Builder. Проте деякі маленькі Builder можуть розділити замовлення Seacher, що призводить до збою стратегій MEV Seacher, а отже, до ризику збитків. Крім того, прив'язка до Builder також може підтримувати його вплив у екосистемі.
Релейер
Релейер відповідає за збирання аукціонів, а потім, як проміжна станція, передає Пропоненту заголовок блоку та ціну за аукціонний блок. У цей момент Пропонент не знає деталей транзакцій у блоці. Як тільки Пропонент вибирає і підписує заголовок блоку, Релейер випускає всі деталі транзакцій для Пропонента. Ми бачимо, що Релейер у цьому випадку виступає як третя сторона без економічних стимулів, здобуваючи величезну довіру, Будівельник покладається на пропозицію Пропонента, а Пропонент покладається на пропозицію Релейера та зміст блоку. В історії також були подібні проблеми; у Ultrasound Relayer існує потенційна уразливість, яка призвела до того, що Пропонент витягнув більше 20 мільйонів доларів MEV. Хоча ці уразливості можуть бути виправлені, Релейер сам по собі все ще може вибрати шахрайську поведінку та вкрасти MEV.
На зображенні вище показано ситуацію з часткою ринку Relayer, ми можемо помітити, що частка ринку Builder, який працює лише з MAX Profit, поступово зросла з часу Merge, отже, у вільному ринку неможливо штучно контролювати MEV через Builder.
Одночасно Relayer також стикається з проблемою, яка полягає в відсутності економічних стимулів. Тому Blocknative також вийшов з дослідження в напрямку Relayer. Наразі Relayer залежить від специфікацій MEVBoost, запропонованих Flashbots, Ethereum покладається на сторонні компанії для надання PBS, що завжди не є тривким рішенням, тому наразі спільнота Ethereum також досліджує можливість впровадження PBS на рівні протоколу.
Пропонент
Для Proposer алгоритмічно випадковим чином обирається група комітету серед усіх валідаторів, а в кожному слоті обирається пропозиція блоку. Пропонент блоку сам має здатність виконувати навантаження, але оскільки пропонент природно хоче передати цю частину на аутсорсинг, це може призвести до вертикальної співпраці між Builder і Proposer. Relayer MEV-boost має на меті виступати в ролі посередника в такій схемі, щоб зменшити вертикальну співпрацю і змову, що виникають через безпосереднє спілкування між ними. Оскільки наразі всі перебувають в майнінгових пулах як пулах валідаторів, ці майнінгові пули та пула валідаторів LSD мають дуже сильний ефект масштабу, особливо поява LSD, яка звільняє потенціал стейкованих токенів, підвищуючи капітальну ефективність, а також вплив блоків DEFI, валідаторський пул потрапляє в ще більш централізовану тенденцію.
Lido наразі займає близько 28,7% ринкової частки, Coinbase та Ether.fi посідають друге та третє місця. У минулому, коли не було впроваджено рішення MEV-BOOST PBS, Пропоненту потрібно було виконувати завдання Будівельника, тобто виконувати навантаження (Payload), але більшість Пропонентів відмовилися від своїх можливостей щодо виконання сортування транзакцій, оскільки це в умовах великої обчислювальної роботи серйозно знижує продуктивність перевірки, краще передати виконання навантаження на аутсорсинг, дозволивши третій стороні аукціонувати блоки.
Користувач
Нарешті, поговоримо про користувача. Користувачі часто є найслабшою ланкою в усій архітектурі, оскільки їхні транзакції потрапляють до Mempool, де різні MEV-боти заробляють MEV-прибуток, але ці прибутки не йдуть користувачам. Але це не лише погано, наприклад, у DEX, коли на ланцюзі коливання великі або обсяг транзакцій користувача перевищує ліквідність DEX, MEV-боти можуть зменшити сліпий ризик і різницю в цінах між платформами через арбітраж. Тому існування MEV має позитивні та негативні зовнішні ефекти, які потрібно обговорювати окремо, і це є частиною його складності.
Щоб не допустити моніторингу користувачів MEVbot'ом, що може завдати шкоди користувачам, багато постачальників RPC-нод можуть допомогти користувачам розміщувати транзакції в непублічному Mempool, наприклад, можна безпосередньо взаємодіяти з Builder через RPC. Існує досить новий спосіб компенсації MEV-прибутків для користувачів через OFA(Order Flow Auction), Оператори OFA RPC співпрацюють із Searcher.
Ця сторінка може містити контент третіх осіб, який надається виключно в інформаційних цілях (не в якості запевнень/гарантій) і не повинен розглядатися як схвалення його поглядів компанією Gate, а також як фінансова або професійна консультація. Див. Застереження для отримання детальної інформації.
Проблема MEV в Ethereum: погляд на темний ліс у блокчейні з архітектури PBS
Освітлення темного лісу: зняття завіси таємниці MEV
З ростом активності на ланцюгу та еволюцією й збагаченням інфраструктури на ланцюгу, MEV на ланцюгу завжди вважався найнебезпечнішою частиною темного лісу Ethereum, що безпосередньо призводить до втрат прибутків та погіршення досвіду користувачів у фінансових операціях на ланцюгу. Ця стаття має на меті проаналізувати природну централізацію та проблеми довіри, які виникають у цій системі, на основі механізму генерації блоків Ethereum 2.0 та технологічної еволюції розділення пропонента та будівельника (PBS), що має абсолютно протилежну реальність до цінностей Ethereum.
Зростання MEV в блокчейні дійсно є двосічним мечем, має свої позитивні та негативні зовнішні ефекти. Позитивні включають зменшення цінових розбіжностей на DEX, допомогу в ліквідації транзакцій; негативні включають шкоду від夹层交易 для користувачів. Тому рішення для MEV більше спрямовані на зменшення негативних зовнішніх ефектів, а не на їх повне усунення. В процесі дослідження механізмів зменшення негативних зовнішніх ефектів MEV та вирішення проблеми довіри до посередників третьої сторони (Relayer), основні заходи поділяються на три категорії: покращення аукціонних механізмів, покращення рівня консенсусу, покращення прикладного рівня. Ці три покращення в різній мірі вплинуть на сучасний ландшафт MEV, але частина рішень не може суттєво вирішити проблему атак типу sandwich, оскільки транзакції користувачів все ще знаходяться в public pool, тому необхідно впроваджувати більше технологій приватних пулів для захисту вибіркової приватності транзакцій користувачів, ці рішення MEV заслуговують на спробу комбінувати.
Окрім цього, MEV як невідворотний побічний продукт механізму дизайну в майбутньому ще більше ускладниться. Ми також досліджували в статті можливі додаткові технічні виклики та можливості MEV у контексті впровадження нових типів транзакцій, таких як архітектура Layer2 та абстракція облікових записів EIP-4337.
Нарешті, ми сподіваємося через цю статтю дослідити потенційні рішення для пом'якшення негативних зовнішніх ефектів MEV, а також всебічно усвідомити переваги та недоліки поточних MEV рішень, не лише щоб освітити темний ліс, в якому знаходяться користувачі в майбутньому, але й освітити темний ліс для дослідників галузі для подальшого дослідження MEV.
Ethereum 2.0
Після The Merge Ethereum перейшов на механізм POS для забезпечення мережевої безпеки, одночасно відмовившись від обчислювально інтенсивної конкуренції в виробництві блоків, перейшовши на доказ володіння. Після злиття Ethereum було розділено на виконавчий рівень та рівень консенсусу. Весь процес виробництва блоків також змінився, кожен Epoch є одним циклом POS, кожен Epoch ділиться на 32 слоти, кожен слот відповідає одиниці часу для виробництва блоку, що становить 12 секунд.
Вся мережа кожного разу в Epoch випадковим чином обирає комітет з валідаторів, пропозиція блоку робиться випадковим чином з членів комітету, пропонент блоку повинен упакувати транзакції та впорядкувати їх для виконання, в результаті чого буде створено один блок, інші валідатори комітету будуть контролювати цей процес, а потім голосувати за цей блок. І цей комітет буде переобиратись після кожного Epoch. Також на них накладається певний часовий обмеження на операції, щоб забезпечити ефективність генерації блоків і голосування. Тут ми стандартизували терміни для читачів, Payload — це виконуване навантаження, що означає зміни стану транзакцій, які можна вважати частиною виконання блоку. Пропонент блоку реалізує виконуване навантаження (Execution Payload, тобто реалізує зміни стану транзакцій ) та пропозицію блоку.
Архітектура PBS
Насправді, коли валідатори обираються на роль пропонента блоку, часто пропонент не має стимулу виконувати Payload, тобто впорядковувати транзакції та виконувати їх, оскільки це вимагає великої обчислювальної потужності для виконання зміни стану. Спочатку думали, що якщо ми оберемо комітет через децентралізовану виборчу процедуру, і якщо ми включимо виконання навантаження в цей процес, тоді впорядкування транзакцій стане децентралізованим. Але, здається, валідатори природно хочуть передати цю частину третій стороні, а самі пропоненти зосереджуються на пропозиції блоку. Тому виникла концепція PBS, яка полягає в тому, що пропозиція блоку і його побудова розділені: пропоненти лише відповідають за валідацію блоку, не беручи участі в його побудові. Розділення між пропонентами та будівельниками сприяє відкритому ринку, на якому пропоненти можуть отримувати блоки від будівельників. Ці будівельники конкурують один з одним у побудові блоків і пропонують пропонентам найвищі збори, ми називаємо це "аукціоном блоків".
Ми коротко представимо всю модель аукціону PBS(Proposer Builder Seperate) Seal перше. Коли користувач подає транзакцію через RPC-проксі, RPC фактично запускає вузол, який подає транзакцію в публічний Mempool, кілька Builder знаходять найкращі транзакції для сортування, щоб створити блок з максимізованим прибутком ( максимізація прибутку означає комісії за транзакції Base + Priority + MEV), а потім кілька Builder взаємодіють з Proposer через MEV-Boost Relayer, Relayer є мостом між кількома Builder та Proposer, Builder подає пропозиції Relayer, Relayer подає кілька заголовків блоків та відповідні пропозиції Proposer зазвичай приймає пропозицію з найвищим заголовком. При цьому Relayer реалізує специфікацію MEVBboost, це технічна специфікація, запропонована Flashbot, як регулювати взаємодію Builder та Proposer у торгах. У цьому процесі вся інформація є закритою, Relayer тільки подає заголовки блоків Proposer, тому Proposer має стійкість до цензури.
Учасники та гри в PBS
Його основними учасниками є Builder, Relayer, Proposer, MEVbot(Searcher).
Будівельник
Builder переважно відповідає за створення вмісту блоків. Використовуючи технологію MEV-Boost, він перебуває у більш вигідному становищі під час торгів, оскільки підтримує не тільки плати за газ, а й MEV-доходи. Builder може безпосередньо перевіряти транзакції користувачів і Searcher'ів, що завжди викликало критику, особливо після того, як уряд США оприлюднив OFAC. Після цього багато Builder'ів почали брати участь в OFAC Compliant. Хоча пропорція перевірки блоків нещодавно зменшилася, ми можемо бачити, що під час процесу створення блоків Builder має безпосередній вплив на перевірку транзакцій.
З огляду на поточну частку ринку Builder, такі платформи, як beaverbuild.org, що пропонують повністю безперешкодне будівництво, поступово розширюють свою частку на ринку, все зосереджено на отриманні прибутку.
Пошуковик
По суті, робота з максимізації прибутку потребує спільних зусиль Searcher та Builder. Searcher, як правило, співпрацює з конкретними Builder, що призводить до утворення Dark Pool або Private Pool, де торги Searcher відображаються лише для певного Builder. Деякі Builder отримують максимізовані прибутки від MEV-торгів, а потім конкурують за блоковий простір. З теоретичної точки зору, якщо Builder чинить зло або проводить цензуру, то Searcher може обрати інших Builder, що призведе до поступового зниження частки ринку Builder. Тому, підпорядковуючись Searcher, Builder зазвичай враховує приховані витрати від злочинних дій. На малюнку зображено дохід від MEV та щоденний Gas, де видно, що внесок Searcher в MEV-доходи під час значних коливань ринку може навіть вдвічі перевищувати щоденний дохід від Gas.
Для Searcher розрізняють CEX-DEX( арбітраж поза ланцюгом ) та дві основні категорії DEX, мезонін, ліквідація ( чисто в ланцюзі ).
Наразі Wintermute займає перше місце за часткою ринку арбітражної торгівлі між CEX та DEX.
Щодо чистих можливостей MEV на ланцюгу, спостерігається поступова тенденція до формування студій, де частка ринку jaredfromsubway.eth займає вражаючі 37,2%. Він спеціалізується на атаках-сандвічах на користувачів Ethereum, і став найбільшим споживачем газу на ланцюзі, витрачаючи близько 1,5% газу протягом цілого дня. З лютого 2023 року по червень 2024 року цей бот витратив у загальному 76,916 ETH, що за вартістю виконання цих транзакцій становить близько 175 мільйонів доларів. Оскільки зв'язок між Seacher та Builder є тісним, на практиці багато Seacher відправляють свої замовлення трьом найкращим Builder, хоча насправді могли б транслювати всім Builder. Проте деякі маленькі Builder можуть розділити замовлення Seacher, що призводить до збою стратегій MEV Seacher, а отже, до ризику збитків. Крім того, прив'язка до Builder також може підтримувати його вплив у екосистемі.
Релейер
Релейер відповідає за збирання аукціонів, а потім, як проміжна станція, передає Пропоненту заголовок блоку та ціну за аукціонний блок. У цей момент Пропонент не знає деталей транзакцій у блоці. Як тільки Пропонент вибирає і підписує заголовок блоку, Релейер випускає всі деталі транзакцій для Пропонента. Ми бачимо, що Релейер у цьому випадку виступає як третя сторона без економічних стимулів, здобуваючи величезну довіру, Будівельник покладається на пропозицію Пропонента, а Пропонент покладається на пропозицію Релейера та зміст блоку. В історії також були подібні проблеми; у Ultrasound Relayer існує потенційна уразливість, яка призвела до того, що Пропонент витягнув більше 20 мільйонів доларів MEV. Хоча ці уразливості можуть бути виправлені, Релейер сам по собі все ще може вибрати шахрайську поведінку та вкрасти MEV.
На зображенні вище показано ситуацію з часткою ринку Relayer, ми можемо помітити, що частка ринку Builder, який працює лише з MAX Profit, поступово зросла з часу Merge, отже, у вільному ринку неможливо штучно контролювати MEV через Builder.
Одночасно Relayer також стикається з проблемою, яка полягає в відсутності економічних стимулів. Тому Blocknative також вийшов з дослідження в напрямку Relayer. Наразі Relayer залежить від специфікацій MEVBoost, запропонованих Flashbots, Ethereum покладається на сторонні компанії для надання PBS, що завжди не є тривким рішенням, тому наразі спільнота Ethereum також досліджує можливість впровадження PBS на рівні протоколу.
Пропонент
Для Proposer алгоритмічно випадковим чином обирається група комітету серед усіх валідаторів, а в кожному слоті обирається пропозиція блоку. Пропонент блоку сам має здатність виконувати навантаження, але оскільки пропонент природно хоче передати цю частину на аутсорсинг, це може призвести до вертикальної співпраці між Builder і Proposer. Relayer MEV-boost має на меті виступати в ролі посередника в такій схемі, щоб зменшити вертикальну співпрацю і змову, що виникають через безпосереднє спілкування між ними. Оскільки наразі всі перебувають в майнінгових пулах як пулах валідаторів, ці майнінгові пули та пула валідаторів LSD мають дуже сильний ефект масштабу, особливо поява LSD, яка звільняє потенціал стейкованих токенів, підвищуючи капітальну ефективність, а також вплив блоків DEFI, валідаторський пул потрапляє в ще більш централізовану тенденцію.
Lido наразі займає близько 28,7% ринкової частки, Coinbase та Ether.fi посідають друге та третє місця. У минулому, коли не було впроваджено рішення MEV-BOOST PBS, Пропоненту потрібно було виконувати завдання Будівельника, тобто виконувати навантаження (Payload), але більшість Пропонентів відмовилися від своїх можливостей щодо виконання сортування транзакцій, оскільки це в умовах великої обчислювальної роботи серйозно знижує продуктивність перевірки, краще передати виконання навантаження на аутсорсинг, дозволивши третій стороні аукціонувати блоки.
Користувач
Нарешті, поговоримо про користувача. Користувачі часто є найслабшою ланкою в усій архітектурі, оскільки їхні транзакції потрапляють до Mempool, де різні MEV-боти заробляють MEV-прибуток, але ці прибутки не йдуть користувачам. Але це не лише погано, наприклад, у DEX, коли на ланцюзі коливання великі або обсяг транзакцій користувача перевищує ліквідність DEX, MEV-боти можуть зменшити сліпий ризик і різницю в цінах між платформами через арбітраж. Тому існування MEV має позитивні та негативні зовнішні ефекти, які потрібно обговорювати окремо, і це є частиною його складності.
Щоб не допустити моніторингу користувачів MEVbot'ом, що може завдати шкоди користувачам, багато постачальників RPC-нод можуть допомогти користувачам розміщувати транзакції в непублічному Mempool, наприклад, можна безпосередньо взаємодіяти з Builder через RPC. Існує досить новий спосіб компенсації MEV-прибутків для користувачів через OFA(Order Flow Auction), Оператори OFA RPC співпрацюють із Searcher.