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

Інтент

Поточний досвід використання транзакцій блокчейну

Беручи транзакції Ethereum як приклад, припускаючи, що користувач хоче обміняти свої USDT на ETH, він може перейти на веб-сторінку Uniswap, щоб перевірити ціну, і після встановлення дозволеного коефіцієнту ціни, підписати та відправити транзакцію, а потім чекати результату транзакції.

Його трансакція, ймовірно, виглядатиме так: «Я підписую та надсилаю цю трансакцію зі значенням Nonce 23 та платою за газ у розмірі 30 Гвей. Вона виконає контракт Uniswap для обміну моїх 1000 USDT на 0,5 ETH з максимальним зривом в 1%.»

△ Ні? Gwei? Джерело зображення:https://www.reddit.com/r/MemeRestoration/comments/ejcvd3/confused_math_lady_4080x2663px

Припустимо, що Еліс - новачок, і їй просто потрібно обміняти свої USDT на ETH, але для втілення цього маленького бажання їй доведеться перестрибувати багато порогів:

• Перше - знайти канал обміну. Припустимо, вона робить пошук в Google та знаходить сторінку Uniswap (принаймні, там є чітке меню цифрових активів та кнопка Swap), а потім їй потрібно зрозуміти та встановити slippage (або використовувати значення за замовчуванням).
• Після натискання кнопки Swap з'являється екран підпису транзакції, який містить Nonce та Gwei оплату обробки.
• Нарешті вона відправляє транзакцію, але, ймовірно, нічого не відбувається, і Еліс може лише чекати в збентеженні та молитися, що транзакція буде успішно виконана.

Кожен рівень - це питання, яке початківці насправді не потребують розуміти, але їм доводиться зробити вибір: Де викупити? Чи хочете ви встановити зміщення? Який відсоток слід встановити для зміщення? Чи хочете ви налаштувати плату за газ (комісію)? На яку кількість Гвей вона повинна бути налаштована? Чому транзакція не вдалася? Чому транзакція так довго застрягла там (можливо, це проблема з Nonce або комісією за обробку)? Що мені робити?

Досвід використання транзакцій наміру

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

У намірі Елліс вказала, що 1000 USDT мають бути обмінені на 0,5 ETH, але з урахуванням комісії ціна була скоригована на 0,495 ETH, після чого замовлення було підписано та відправлено. Транзакція Елліс буде виглядати так: "Я підписую та відправляю це замовлення. Я хочу обміняти 1000 USDT на 0,495 ETH. Це замовлення є дійсним, поки я можу отримати 0,495 ETH."

Це дуже просто, чи не так? Це досвід використання лімітного ордера (Limit Order), а також загальний досвід використання DEX агрегаторів (таких як 1inch та Tokenlon).

△ Різниця між транзакцією (вверху) та наміром (внизу). З наміром користувачам потрібно лише вказати умови й не турбуватися про те, як їх досягти. Підпис:https://www.paradigm.xyz/2023/06/intents

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

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

Наміри значно покращать досвід роботи з блокчейном.

Порада щодо читання 1: Насправді, вже є багато прикладів використання Intent, таких як підпис гаманця з мультипідписом, концепція Session Key, яка надає третій стороні конкретні дозволи на виконання та часові обмеження, або механізм транзакції пакетного зіставлення, такий як CowSwap. Навіть у світі Web2 є сліди наміру, такі як пошукові системи (я вводжу те, що хочу запитати, а пошукова система знаходить релевантну для мене інформацію через різні канали) або онлайн-зйомка електронної комерції (я вводжу, що хочу купити) Щось, компанія електронної комерції знайшла це через різні канали та доставила мені). Просто слово Intent лише нещодавно стало популярним у світі Web3.

Підказка 2: У англійській мові слово “Imperative” (“наказове”) використовується для опису використання транзакції, яка полягає в видачі повної команди для досягнення мети; тоді як слово “Declarative” (“Заява”) використовується для опису використання наміру. Описово, вказуючи, що воно використовується шляхом визначення умов виконання та результатів виконання.

Намір у світі міжланцюжкової взаємодії

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

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

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

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

Вишуканий

Повна назва SUAVE - Єдиний Об'єднаний Аукціон для Вираження Вартості, мета - стати єдиною ринковою мережею MEV на кількох ланцюгах. На цьому ринку користувачі можуть ефективно виражати умови закриття та винагороди угоди. Тим часом, виконавці (Executors) будуть змагатися між собою та ефективно співпрацювати для виконання запитів користувачів.

SUAVE може служити пулом транзакцій для блокчейну, а також виступати в ролі розробника, відповідального за створення блокового контенту цього блокчейну. Однак SUAVE не призначений для заміни існуючого пулу транзакцій і функціональності Builder блокчейну, а скоріше для безперешкодного підключення до існуючого блокчейну за принципом plug and play.

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

Від Flashbot до MEV-Boost до SUAVE

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

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

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

Ще одним явищем, яке вплине на централізацію та безпеку, є Private Order Flow: транзакції користувачів надходять не до публічного пулу транзакцій, а безпосередньо до Searcher або Builder. Приватний потік замовлень може надходити від Пошукача або Будівельника, який купує право отримувати дохід від транзакцій користувачів, або Будівельника, що надає привабливі послуги, такі як (1) безкоштовне скасування транзакцій або ордерів DEX, надісланих користувачами, або (2) надання попереднього підтвердження, перш ніж транзакція буде отримана, користувач впевнений, як швидко транзакція буде отримана, Щоб користувачеві не потрібно було турбуватися про те, чи буде отримана транзакція і скільки часу займе її отримання.

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

Чому блоки від транзакцій користувача до бандла, створеного Searcher, повинні збиратися через Private Order Flow? Це пов'язано з тим, що транзакція та вміст пакета є публічними та незашифрованими. Якщо їх побачать і отримають інші, це може завдати шкоди користувачеві або Шукачу. Наприклад, інші можуть витягти MEV транзакції користувача за допомогою атаки кліщів або розібрати Bundle, вихопивши MEV. Ось чому і користувачі, і Шукачі наразі повинні довіряти Конструктору, оскільки їм потрібно передати оригінальний вміст транзакції та Бандл Конструктору та вірити, що Конструктор не завдасть жодної шкоди.

Поява SUAVE спрямована на вирішення ризиків централізації, спричинених міжкраїним MEV та приватним потоком замовлень.

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

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

Порівняно з повністю зашифрованими транзакціями, транзакції, які розкривають конкретну інформацію, можуть бути ефективніше та швидше включені в пакети або блоки, і навіть отримувати винагороду, як детально описано в розділі MEV-Share четвертого статті. Розкриваючи конкретну інформацію, Пошуковці навіть можуть співпрацювати один з одним. Пошуковець B може побудувати на основі пакету пошуковця A: пакет пошуковця A відстежує транзакцію користувача для арбітражу, а пакет пошуковця B відстежує пакет пошуковця A для арбітражу. Приватність є важливою для відкритого потоку замовлень. Приватність дозволяє Пошуковцям мати можливість співпрацювати один з одним, користуючись один одним, а не конкуруючи за можливості MEV.

Інші переваги SUAVE

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

архітектура SUAVE

Дошка оголошень для користувачів

SUAVE можна описати як «дошка оголошень користувачів». Термін «Користувач» тут не обов'язково відноситься до загальних користувачів блокчейну, але Пошукові також можуть бути Користувачами SUAVE. У подальшому термін «Користувач» буде відноситися до загальних користувачів блокчейну, а «Користувач SUAVE» буде відноситися до користувачів SUAVE.

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

• «Я хочу, щоб мою транзакцію впорядковано перед транзакцією 0xabcd та включено перед блоком 110050». Фактично, це схоже на умови, вказані Бандлом Пошукача при використанні Flashbot.
• "Я хочу, щоб мій пакет був включений і приніс мені дохід у розмірі 0,05 ETH."
• "Я хочу, щоб Намір А і Намір Б були включені в блок 1001 ланцюжка X і блок 50900 ланцюжка Y відповідно." \

Порада з читання: Користувачі також можуть надсилати загальні транзакції блокчейну (без вказівки будь-яких уподобань) до SUAVE, тобто просто використовувати SUAVE як загальний торговий пул або Flashbot, наприклад, безпосередньо відправляти свої транзакції з переказом ETH або транзакції Uniswap до SUAVE.

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

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

• «Я хочу, щоб моя транзакція була відсортована перед транзакцією 0xabcd і була включена до блоку 110050. Якщо це буде досягнуто, я дам вам 3 ETH».
• «Я хочу, щоб мій пакет був включений і приносив мені 0,05 ETH доходу. Якщо це буде досягнуто, я дам вам 0,02 ETH».
• «Я хочу, щоб Намір А і Намір Б були включені в 1001-й блок ланцюжка X і 50900-й блок ланцюга Y відповідно. Якщо це буде досягнуто, я дам вам 1.8 ETH"。

Архітектура

SUAVE можна розглядати як складову з трьох компонентів: Середовище Вибору, Ринок Виконання та Децентралізована Побудова Блоків.

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

△ PE зліва збирає Наміри та арбітражні транзакції на різних ланцюгах, а потім Виконавці посередині намагаються задовольнити ці Вподобання та упаковують їх у пакети, і передають ці пакети ролі справа, яка має право виробляти блоки для збирання блоків. Джерело зображення:https://writings.flashbots.net/the-future-of-mev-is-suave

SUAVE матиме власний ланцюг та пул транзакцій. SUAVE називає ланцюг Шаром розрахунків та пул транзакцій Шаром повідомлень.

Розумні контракти можуть бути розгорнуті на ланцюжку для укладання контрактів між Preference та винагородами. Пул транзакцій буде заповнений транзакціями, в яких користувач SUAVE декларує Preference, а Виконавець отримує винагороду.

Цикл життя транзакції SUAVE

1. Вираз уподобань: Користувач SUAVE вказує уподобання та робить ставку на одне або кілька своїх намірів/транзакцій.
2. Оптимізація виконання: Виконавець знаходить шлях виконання, який задовольняє вимоги користувача, і навіть може знайти оптимальний шлях для цього.
3. Уподобання розрахунків: Пакет(и) Виконавця успішно включені в блок цільового ланцюжка та відповідають уподобанням, вказаним користувачем SUAVE.
4. Вирівнювання платежів: Оракул повертає статус цільового ланцюжка на ланцюжок SUAVE, а Виконавець виконує смарт-контракт. Після того, як контракт підтверджує, що Уподобання було задоволено, винагорода користувачеві SUAVE надається Виконавцю.

△ Вибір чотирьох кроків від створення до виконання до врегулювання. Джерело зображення:https://dba.mirror.xyz/NTg5FSq1o_YiL_KJrKBOsOkyeiNUPobvZUrLBGceagg

MEVM

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

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

Приклад програмного коду на малюнку нижче пише алгоритм побудови блоків ефективної ціни газу (EGP) з використанням контрактів Solidity та MEVM Precompile.

EGP Блоків будівництва сортує пакети відповідно до Газової Ціни, вказаної в кожному пакеті. Пакети з вищою Газовою Ціною будуть розташовані впереді блоку:

△ Рожева функція на зображенні - це попередньо скомпільована функція MEVM, спеціально призначена для використання MEV. Джерело зображення:https://writings.flashbots.net/mevm-suave-centauri-and-beyond

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

Через композабельність контракту EVM, Пошуковик та Пошуковик або Пошуковик та Білдер зможуть співпрацювати через контракти, замінюючи оригінальні односторонні взаємовідносини довіри. Співпраця також подальш покращить ефективність пакета та видобуде більше MEV, що може бути корисним для кожного учасника ланцюга постачання MEV. Крім того, учасники можуть безпосередньо використовувати інструменти розробки на основі EVM та інфраструктуру, такі як постачальник RPC, інструменти тестування, такі як Foundry, тощо, а досвід розробки буде дуже хорошим.

Крім того, MEVM буде надавати функцію конфіденційності транзакції, оскільки без конфіденційності неможлива співпраця. Без конфіденційності Пошукові доведеться турбуватися про те, що їх MEV може бути вкрадено. На початковому етапі ця конфіденційність буде досягнута за допомогою довіреного апаратного забезпечення SGX. Транзакція буде зашифрована, а потім відправлена на виконання до SGX. Вважається, що SGX виконає свій призначений програмний код, не крадучи MEV за власним бажанням. У майбутньому, коли інші передові криптографічні технології поступово дозріватимуть, криптографія може бути використана для заміни довіреного апаратного забезпечення. Для отримання більш детальної інформації, будь ласка, зверніться до попередньої статті наЗашифровані Mempools.

Порада з читання: Однак на основі EVM також є недоліки, такі як те, що EVM є занадто виразним: Насправді, для написання функцій, необхідних для MEV, в EVM не потрібно багато опкодів. Дозволити використання цих опкодів може дозволити людям, які готові писати дуже складні виконання, а потім дозволити транзакції не вдалося в кінці виконання, що призводить до того, що вузол витрачає купу обчислювальних ресурсів, що є атакою DoS. Проект Anoma перепроектує мову програмування та середовище виконання спеціально для вираження та виконання намірів. У майбутньому SUAVE також може використовувати архітектуру Anoma для заміни MEVM.

Підключення та грати SUAVE

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

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

Виклики міжланцюжкового MEV

Кожен ланцюг має свого власного розробника блоків та валідатора. Блок B1 SUAVE, який був отриманий ланцюгом X, не означає, що блок B2 також буде успішно отриманий Валідатором ланцюга Y. Механізми та ринки виробництва блоків ланцюгів X та Y є незалежними. Якщо лише обидва ланцюги X та Y використовують Shared Sequencer, і той самий Sequencer виробляє блоки для обох ланцюгів одночасно, то тільки поєднуючи SUAVE ми можемо забезпечити Атомарне Включення: обидва ланцюги не повинні «збирати вказані транзакції (або блоки) разом». Юань)”, або «жодного доходу взагалі».

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

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

Беручи наведене нижче зображення як приклад, користувач SUAVE хоче здійснити арбітраж транзакцій між ланцюгами між Rollup 1 та Rollup 2: купити один ETH за нижчу ціну на Rollup 1 та продати один ETH за вищу ціну на Rollup 2.

Якщо обидва угоди оплачуються в реальному часі та успішно виконуються, Користувач SUAVE може заробити різницю в ціні. Сценарії 1 і 2 у таблиці на картинці - «Користувач SUAVE готовий нести ризик самостійно» та «Виконавець готовий нести ризик» відповідно.

Нижні три стовпці таблиці - «винагороди за обидва успіхи», «винагороди за лише один успіх» та «кінцевий результат лише одного успіху»:

• Винагорода за обидві успішні операції (користувач SUAVE заробляє різницю в ціні):
  • Сценарій 1: Користувач SUAVE сплачує виконавцю комісію у розмірі 50 доларів.
  • Сценарій 2: Користувач SUAVE сплачує комісію в розмірі $70 Виконавцю (дорожче, оскільки Виконавець несе ризик).
• Є лише одна винагорода за успіх (користувач SUAVE не заробив різницю):
  • Сценарій 1: Користувач SUAVE сплачує виконавцю плату в розмірі $25. Користувачі SUAVE самостійно несуть ризики.
  • Сценарій 2: Користувач SUAVE не має платити комісії або ризикувати.
• Є лише один успішний результат (користувач SUAVE не заробив розподіл):
  • Сценарій 1: Користувач SUAVE сплачує виконавцю комісію у розмірі 25 доларів і має додатковий ETH в руках.
  • Сценарій 2: Користувач SUAVE не повинен платити комісію виконавцю і не матиме додаткових ETH в наявності. А виконавець має ще один ETH у своїй руці.

△ Різні результати виконання в різних ситуаціях. Джерело зображення:https://dba.mirror.xyz/NTg5FSq1o_YiL_KJrKBOsOkyeiNUPobvZUrLBGceagg

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

Навіщо SUAVE потрібна власна мережа?

Чому ми не можемо просто передавати та ділитися уподобаннями через мережу P2P? Тому що чиста мережа P2P не може запобігти тому, щоб мережу не засипало безліч уподобань (тобто атаки DoS). Якщо це ланцюг, атаки DoS можна запобігти за допомогою комісій за обробку.

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

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

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

Порада з читання: Покищо немає багато деталей про те, чи буде у SUAVE власний токен, чи потрібно переказувати активи на Ланцюг SUAVE для використання, або як переказати на Ланцюг SUAVE. Це згадується лише в відео та статті „Користувачі SUAVE спочатку повинні переказати активи з інших ланцюгів на Ланцюг SUAVE, перш ніж вони зможуть його використовувати.“

Дизайн та модель безпеки самого ланцюга SUAVE все ще обговорюються. Якщо SUAVE Chain - це Rollup на Ethereum, то ви можете безпосередньо використовувати власний механізм Rollup для передачі активів та читання іншої інформації Rollup. Це буде краще, ніж покладатися на інші rollup. Технологія міжланцюжкових транзакцій та послуги Oracle приносять багато безпеки.

Якщо валідатор Ланцюга SUAVE може бути поєднаний з Eigenlayer, буде безпечніше та надійніше безпосередньо використовувати Валідатор Ethereum як Валідатор Ланцюга SUAVE, ніж генерувати набір Валідаторів від самого SUAVE. Але, звісно, ці конструкції також мають відповідні недоліки. Для більш докладної дискусії про дизайн Ланцюга SUAVE, будь ласка, зверніться до цієї статті.

Огляд викликів SUAVE

• Час блоку SUAVE Chain: Час блоку SUAVE Chain повинен бути достатньо коротким, щоб користувач SUAVE мав змогу заявити свої Вподобання виконавцю, який бачить. Якщо час SUAVE Chain довший, ніж той, з яким він пов'язаний (наприклад, з Solana або іншим Rollup), користувачеві SUAVE легко не вистачить часу, щоб дати знати Виконавцю SUAVE, що він бажає, щоб транзакцію включили в наступний блок певного ланцюжка. Був створений блок.
• Ризик Oracle: Oracle відповідає за надання інформації про інші ланцюги, і також може бути відповідальним за передачу активів користувачів SUAVE на ланцюг SUAVE, тому важливість Oracle не мала річ.
• Досвід використання міжланцюжковий: Користувач SUAVE потрібно перекласти активи на ланцюг SUAVE, що також є недоліком в досвіді використання.
• Економічна модель: Чи потрібно SUAVE випускати власні активи, як заохочувати SUAVE Валідатора, як запобігти тому, щоб економічний стимул SUAVE не впливав на економічну безпеку інших ланцюгів тощо.
• Технологія конфіденційності: На короткий термін SUAVE буде змушена покладатися на довірче апаратне забезпечення, таке як SGX, для забезпечення функцій конфіденційності транзакцій, але на довгий термін їй доведеться перейти до більш децентралізованого та безпечного підходу для зменшення ризиків.
• Відповідна мова переваг: Чи є EVM відповідним засобом вираження та виконання переваг?

Огляд та основні моменти

• Поява SUAVE — це (1) відповідь на ризик централізації, спричинений різницею в перевагах будівельників, яка може виникнути внаслідок Cross Domain MEV, та (2) відкриття можливості співпраці між пошуковиками / будівельниками за допомогою впровадження програмованої приватності, зменшуючи ризик централізації, який може виникнути внаслідок Приватного Потоку Замовлень.
• Повністю приватні транзакції ускладнюють роботу пошукачів, оскільки вони не можуть ефективно виконувати транзакції користувачів Back-Run, що призводить до зниження ефективності ончейн. Однак користувачам не доведеться вибирати між «конфіденційністю» та «ефективністю». Замість цього вони можуть використовувати програмовану конфіденційність, щоб вибрати часткове розкриття інформації, що полегшує роботу пошукачів і підвищує ефективність ончейн і винагороди за зворотний запуск.
• З SUAVE Користувачі SUAVE можуть вказати свої наміри/передплати та різні умови, тоді як решта обробляється професійними Виконавцями для досягнення умов та отримання обіцяних нагород, які обіцяли користувачі SUAVE при виконанні.
• SUAVE матиме власний ланцюг, оскільки чистий P2P не може запобігти атакам DoS, і SUAVE матиме свої унікальні функції та налаштування для ланцюга (MEV), тому існуючі ланцюги не можуть бути безпосередньо використані. Цей ланцюг буде базуватися на модифікації EVM, додавання необхідних функцій для MEV, який називається MEVM.
• Перехресний MEV є високо викликом операції, оскільки вимагає забезпечення атомної включеності та гарантії "успішного виконання" транзакцій. Користувачі SUAVE можуть вказати стани, щоб вимагати, щоб транзакції були виконані успішно перед тим, як винагородити Виконавця, тим самим передаючи ризик Виконавцю. Спільний послідовник може забезпечити атомну включеність, але не гарантує, що транзакції будуть виконані "успішно".
• Те, що SUAVE є власним ланцюжком, означає, що користувачам SUAVE потрібно перекласти активи на ланцюжок SUAVE, перш ніж вони зможуть використовувати SUAVE. Крім того, для перевірки виконання Уподобань потрібний безпечний Оракул, який передає інформацію з інших ланцюжків на ланцюжок SUAVE.
• SUAVE все ще стикається з багатьма технічними та дизайнерськими викликами, такими як безпечний Oracle, безпечні техніки конфіденційності, мова уподобань та економічні моделі, серед іншого.

Disclaimer:

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