Вступ

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

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

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

Фон

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

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

1. Неплавні виплати: Невеликі зміни в замовленні можуть спричинити великі зміни в MEV.
2. Не монотонні виплати: Невеликі зміни в порядку можуть як збільшити, так і зменшити MEV, але не послідовно в одному напрямку.

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

Як працює ASS?

Щоб зрозуміти ASS, спочатку огляньмо існуючий ланцюжок постачання транзакцій.

У нинішній системі:

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

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

Діаграма поточного ланцюжка поставок транзакцій

Застосунки, що підтримуються ASS, мають наступні властивості:

1. Обмежені Послідовні Права: Це обмеження забезпечує, що лише визначений послідовник або заставні перевіряючі можуть взаємодіяти з контрактом заявки на ланцюжок, до якого вона вирішує, запобігаючи підступному обхіду логіки заявки для внутрішнього перерозподілу вартості.
2. Mempools, специфічні для додатків: замість подання транзакцій до загального mempool, користувачі відправляють підписані повідомлення, що виражають їх намір до спеціального mempool для додатків. Ці наміри потім збираються та обробляються специфічним послідовником для додатків.
3. Результати, незалежні від порядку замовлень: Для забезпечення виконання правила послідовності та надання оптимальних економічних вигод цільовим користувачам, транзакції ASS повинні бути незалежними від порядку замовлень транзакцій будівників для решти блоку. Це досягається шляхом забезпечення того, що стан додатка є визначеним його механізмом консенсусу. Замовлення ASS потім об'єднуються в один пакет, який відправляється будівникам для включення. Оскільки цей пакет не створює конфліктів зі станом, до якого звертаються інші додатки, він не залежить від свого положення в блоку.

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

Враховуючи ці основоположні принципи, давайте використаємо Ангстрем як практичний приклад суверенного застосування. Ангстрем - це гачок UniswapV4, який захищає своїх постачальників ліквідності від небажаного вибору арбітражниками CEX-DEX, а також захищає обмінювачів від атак з сендвічем. Мережа вузлів Ангстрем доходить до згоди, паралельно з Ethereum, щодо набору транзакцій, які будуть виконані у наступному блоку. Загальний потік виглядає так:

1. Арбітражори CEX-DEX пропонують купівлю права на першу транзакцію, щоб обміняти через AMM (без комісії). Тим часом, користувачі надсилають свої намічені обміни як підписані лімітні ордери на пам'ять Angstrom.
2. Мережа Angstrom запускає свій протокол консенсусу і формує зв'язку, де перший своп - це арбітражна транзакція з найвищою ставкою. Згодом сума пропозиції пропорційно розподіляється між базовими LP в діапазоні свопу. Всі інші дійсні лімітні ордери разом з базовою ліквідністю AMM виконуються за тією ж єдиною кліринговою ціною.
3. Цей пакет потім надсилається розробникам Ethereum та загальному мемпулу від пропонуючого вузла Angstrom для слоту.
4. Будівельники можуть включити пакет Ангстрома в будь-яку позицію у блоку. Пакет просто повинен заплатити базову плату за включення через його конструкцію, яка не залежить від порядку.

Наведена нижче діаграма ілюструє роботу суверенного додатка.

Ланцюг постачання транзакцій в Ангстрьомі

Живість та Передбачення Довіри

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

Припущення про живість

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

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

Припущення довіри

Щоб переконатися, що секвенсери дотримуються встановлених правил секвенування, суверенні програми можуть використовувати криптоекономічні рішення (наприклад, PoS) або криптографічні методи (наприклад, TEE або MPC). Конкретний підхід може значно відрізнятися в залежності від потреб застосування; Деякі з них можуть вимагати консенсусу щодо оптимальності виконання, тоді як інші можуть зосередитися на забезпеченні конфіденційності перед виконанням за допомогою криптографічних механізмів. Існує безліч інструментів, доступних для зменшення накладних витрат на довіру секвенсерів і досягнення унікальних цілей кожної суверенної програми.

Стійкість до цензури

Екосистема Ethereum переслідує різні типи цензури:

1. Регулятивна цензура: Розробники та релецізорують транзакції на основі списку санкцій OFAC. Це одна з найбільш відомих форм цензури, присутніх на Ethereum сьогодні,переважно виконується реле.
2. Економічна цензура: вмотивований зловмисник може підкупити ініціатора блоку для цензури транзакцій жертв.
3. Цензура на рівні вузлів: Вузли в мережі P2P можуть відмовлятися від propaGate вхідних транзакцій. Це може стати серйозною проблемою, якщо протокол працює оптимально, виходячи з припущення, що більшість вузлів поділяють однаковий погляд на вхідні транзакції. Крім того, у таких протоколах зловмисник може бути зацікавлений у тому, щоб розділити локальні представлення чесних вузлів (надіславши транзакцію лише половині вузлів у самому кінці слота) і в результаті зупинити протокол.

Багато дослідників висловили необхідність кращого механізму опору цензурі на Ethereum. Деякі пропозиції, як-от Кілька одночасних пропозицій (MCP) і Список включення, забезпечений вибором гілки (FOCIL), спливли на поверхню і стали центром тривалої дискусії.

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

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

Цензуростійкість у децентралізованій суверенній програмі

Дилема компонування

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

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

Попередні підтвердження включення

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

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

Ілюстрація включення попередньої конфігурації з ASS

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

Спільні секвенсори для конкретних додатків і зобов'язання розробника

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

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

Ілюстрація прихильності розробника до атомарного компонування між суверенними та несуверенними dApps (праворуч) та спільного секвенсора для конкретного додатка для атомарного компонування між суверенними додатками (ліворуч)

В той час як залишаються питання щодо економічної динаміки зобов'язань будівельників, можливості включення передпідтвердження та потенційних побічних ефектів, ми впевнені, що проблеми композиції в ASS будуть вирішені з часом. Команди, подібні до Gate.io,AstriaіPrimevактивно досліджують і розробляють вдосконалені фреймворки для спільної послідовності та зобов'язань будівельників. По мірі того, як ці досягнення просуваються, композиційність більше не буде проблемою для суверенних додатків.

ASS проти спеціалізованих L2 та L1 додатків

В даний час dApps повинні створювати ланцюжки для конкретних додатків, якщо вони хочуть взяти під контроль послідовність своїх транзакцій. Такі поняття, як Власник протоколу будівельник (PoB)дозволяє Cosmos L1s мати більш виразні правила послідовності, які допомагають захоплювати та перерозподіляти MEV до їхніх додатків. Аналогічно, послідовник L2 з VSR також може виконувати такі операції. Хоча обидва рішення дозволяють більш виразне послідовне виконання та захоплення MEV їхніми додатками, ASS унікальний завдяки наступним характеристикам.

1. Виконання транзакції не потребує додаткового довірчого капіталу – ASS не виконує або не розраховує послідовну транзакцію. Делегується лише послідовність. Базове припущення про довіру поширюється з вихідного середовища виконання, такого як Ethereum або інші L2.
2. Доступ до ліквідності та потоку замовлень - Користувачам не потрібно моститися. dApps можуть безпосередньо використовувати потік та ліквідність у ланцюжку.
3. Активи залишаються в нативному середовищі виконання і не можуть бути заморожені - На відміну від L2, більшість ASS не вимагають від користувачів блокування своїх коштів у перехідних контрактах. Цей вибір дизайну забезпечує кращу безпеку: якщо секвенсор конкретної програми виходить з ладу, потенційна шкода обмежена, оскільки секвенсер може контролювати транзакції лише в межах, встановлених смарт-контрактом. У той час як деякі рішення L2 реалізують функції безпеки, такі як евакуаційні люки та примусове включення – ці заходи часто важко використовувати на практиці. Користувачам може доводитися чекати кілька днів, перш ніж вони зможуть активувати вихідний засіб після втрати зв'язку з оновленнями L2. Аналогічно, примусове включення через L1, як правило, передбачає принаймні деньзатримка. Можливо, найважливіше, ці заходи безпеки зазвичай потребують технічних знань, які в більшості користувачів відсутні, що робить їх непрактичними для пересічної людини.
4. Сильне припущення про активність - Активність L2 залежить від вузлів виконання, які зазвичай є послідовником rollup, якщо не базовий послідовний. Активність L1 залежить від чесної більшості вузлів, які повторно виконують відповідні функції переходу стану. Активність суверенної програми в основному залежить від базового середовища виконання, а розумні договори можуть вказати частини, які потрібно покладатися на специфічних для додатків послідовників.

Таблиця порівняння суверенних додатків, L2, заснованих L2 та L1

Висновок

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

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

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

Ми тут, щоб зробити DeFi більш стійким, по одному ASS за раз.

Відмова:

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