MEV-Boost, поточний протокол супутника для видобутку MEV в Ethereum, сильно покладається на централізованих акторів, яких називають реле.
Ми пропонуємо альтернативну архітектуру, яка дозволяє пряму, криптографічно приватну комунікацію між будівельниками та пропонентами. Вона базується на новій, неінтерактивній формі «тихого» порогового шифрування, яке може використовувати існуючі BLS пари ключів валідаторів.
По суті, ми приєднуємося до комітету по атестації для забезпечення конфіденційності та доступності даних шляхом порогового шифрування пропозицій блоки до частини атестаторів для слоту. Їх атестації формують ключ для розшифрування; коли було атестовано потрібний поріг, блок може бути розшифрований.
Наша конструкція стосується конфіденційності між будівельниками та пропозиціями, але сама по собі не гарантує валідності блоку. Її можна поєднати з іншими механізмами для повного реплікування функцій, які забезпечуються реле — як конфіденційність, так і валідність блоку. Наприклад, докази схеми, такі як докази довіри до середовища виконання (TEE) або докази знань (ZK), або криптоекономічні механізми для забезпечення будівельників.
Видаливши потребу в реле для забезпечення конфіденційності будівельника та забезпечення валідності блоку, ми маємо на меті зменшити затримку та покращити децентралізацію та опір цензурі Ethereum.
Конфіденційність для розробників: Реле забезпечує, що пропозиції не можуть бачити вміст блоку та красти MEV, знайдений розробником.- Безпека для пропонувачів: Реле гарантує, що будівельник сплачує обіцяну вартість пропоненту в пропозиції будівельника і що блок є дійсним (наприклад, всі транзакції сплачують внутрішній газ).Залежність від реле, однак, викликає значну централізацію. Приблизно 90% блоків на Ethereum подаються через лише кілька реле. Це створює кілька ризиків:
Централізація: Розробники можуть бути ефективними з точки зору затримки шляхом співпраці з реле, а не відображенням географічного розподілу пропозицій. Це безпосередньо підриває географічну децентралізацію та опір цензурі, які ми інакше могли б отримати від великого, глобально розподіленого набору перевіряючих.- Дохід: середній час обробки блоку від кінця до кінця ефективних реле становить близько 5-20 мілісекунд. Потім є затримка комунікації між пропонувальником та будівельником. Пропускання реле зменшить затримку, знизить ризики виконання міждоменних операцій (наприклад, CEX/DEX) та врешті-решт збільшить нагороди MEV пропонувальників.## ТЕЕ-BoostОднією з провідних пропозицій по заміні реле є «TEE-Boost“, який ґрунтується на TEEs (Trusted Execution Environments). Зверніть увагу, що TEEs не є обов’язковими для нашої схеми; це просто корисно використовувати TEE-Boost як педагогічний приклад проблем, які ми маємо на меті вирішити.
Конкретно, TEE-Boost дозволяє будівельникам використовувати TEE для створення доказів, які демонструють пропонентам чесність їх пропозицій та валідність їх блоків, не розкриваючи фактичного вмісту блоків пропонентам. Пропоненти можуть перевірити ці докази, не запускаючи TEE самостійно на звичайному обладнанні.
Однак, у TEE-Boost є проблема доступності даних: будівники лише діляться доказами TEE та заголовками блоків з пропозиціями, а не фактичними вмістом блоків,[1]і може вирішити не розкривати вміст блоку навіть після того, як пропонент підписує заголовок (наприклад, якщо ринкові умови змінилися неблагоприятно). Запропоновані підходи до вирішення цієї проблеми DA:
[ ] TEE-Escrow: TEE-escrow отримує блок від будівника перед тим, як пропозиція його підписує і випускає його, як тільки вони бачать підписаний заголовок.- [ ] Рівні доступності даних: розробники розміщують зашифровані набори корисних даних блоків на рівні доступності даних (DA).Обидва підходи мають недоліки. Рішення з блокуванням TEE відтворює динаміку централізації затримки, схожу на ту, що існує в реле.[2] Використання зовнішнього рівня DA вводить позапротокольне припущення і несе динаміку затримки цього зовнішнього протоколу (яка також, ймовірно, є несприятливою).
Теоретично, якби ініціатори також мали доступ до TEE, розробники могли б зашифрувати свої блоки в TEE, яким керує той, хто пропонує. TEE ініціатора розшифровує блок лише після того, як він його підпише. Однак ми вважаємо, що TEE-Boost не розглядає цю конструкцію, оскільки вона вимагатиме від ініціаторів (валідаторів) запускати TEE. Ми хочемо, щоб валідатори могли працювати на товарному обладнанні. ↩
Динамічна затримка може бути уникнута, якщо пропозиції самі запускають TEE-Escrow як збіжний підпроцес до свого вузла перевірки. Однак, знову, ми не хочемо, щоб перевіряючі запускали TEEs.↩
Основна технологія, що забезпечуєШумовий поріг шифрування. Ця криптографічна техніка дозволяє виконувати порогове шифрування без необхідності інтерактивного етапу налаштування розподіленого генерації ключів (DKG), як це вимагалося в попередніх конструкціях. Замість цього, спільний публічний ключ визначається детерміновано з вже існуючих публічних ключів BLS атестанта плюс деякі "підказки" (про які буде розповідатися пізніше).
Це досягає прямого односкокового зв'язку між будівельником та валідатором з криптографічним приватністю. Валідаторам не потрібно самостійно запускати TEE або керувати будь-яким новим ключовим матеріалом.
Механіка:
Будівельник створює блок та шифрує його для комітету підтверджувачів.
Будівельник складає доказ TEE, демонструючи три речі комітету атестаторів: що ставка є чесною, блок є валідним, і він зашифрований правильно.
Будівельник передає зашифрований блок порогу та доказ TEE (який включає значення ставки) пропонентові.[3]
Пропонент підписує зашифрований блок переможного будівельника та розповідає це пропозицію набору перевіряючих.
Після того, як зазначений дріб (наприклад, n/2 або 2n/3) n-тестер для слота засвідчує блок, він розшифровується.
Розшифрований блок нормально проходить процес завершення.
n - це максимальний розмір комітету, який ми хочемо підтримувати, а t - поріг для розшифрування.
Як шифрування, так і часткове розшифрування відбуваються в постійний час. З необхідною реалізацією шифрування займає менше 7 мс - і це можна паралельно. Часткове розшифрування займає менше 1 мс.
Розмір шифротексту є постійним додатковим фактором, 768 байтів, більший, ніж звичайний текст (для будь-якого n та t).
Агрегація часткових розшифрувань (тобто розшифрування) залежить від розміру комітету. При n=1024 недбале втілення займає менше 200 мс. Ми очікуємо, що при n=128 (розмір комітету атестації для кожного слоту) це зменшиться в 10 разів, і що реалізацію можна подальше оптимізувати.
Найважливіше, час шифрування - це ключове показник продуктивності для порівняння затримки реле. Це те, що будівельник повинен обчислити в “critical path” виробництва блоків. Це менше, ніж поточна затримка обробки блоку реле й уникне багатопересилання.
Крім того, кожний перевіряючий з громадським ключем BLS у формі gsk публікує набір групових елементів, які ми називаємо "підказками": (gsk⋅τ,…,гsk⋅τn-t). Ці підказки потрібні лише для агрегування відкритих ключів та розшифрування шифротекстів. Шифрування використовує лише постійний агрегований відкритий ключ.
На момент написання цього посту близько 1 мільйона валідаторів. Якщо ми встановимо n=128 і t=n/2, кожен валідатор повинен надіслати приблизно 3 КБ підказок. Таким чином, зберігання підказок всіх валідаторів потребує 3 ГБ.
Ця вимога, ймовірно, значно зменшиться зактивація MaxEB, що дозволяє валідаторам, які контролюють >32 ETH , утримувати більші баланси за тим самим ключовим набором (замість розподілу їх на кілька 32 ETH депозитів). Зміцнення набору валідаторів, яке буде досягнуто, є предметом обговорення. Здається, що ми можемо зменшити його до ~1GB.
Наостанок, в залежності від майбутніх змін в архітектурі консенсусу Ethereum (наприклад, подальше скорочення розміру набору валідаторів або альтернативне фіналізація трубопроводів), розмір підказок, які потрібно зберігати, може подальше зменшитися.
Одне з рішень полягає в тому, щоб дозволити забудовнику прийняти рішення про прийнятну частку (t) комітету для розшифровки. Існує компроміс між конфіденційністю (можливістю анбандлінгу та крадіжки MEV) та ймовірністю того, що поріг комітету буде онлайн. Для будівельників максимізує дохід, щоб включити свої блоки, а не розщедритися, тому вони повинні з'ясувати оптимізоване встановлення порогового значення.[4]
Крім того, використання цієї схеми шифрування повинно бути вибірковим. У разі неблагоприятних мережевих умов, коли немає постійно доступного комітету прийнятного розміру, ініціатори та будівельники можуть повертатися до використання реле, самобудівництва або будь-якого іншого механізму, який є бажаним з урахуванням характеру неблагоприятного середовища.
З точки зору протоколу, розгалуження цих блоків не є проблемою. Більш широкий набір валідаторів просто не може засвідчити їх або будь-які блоки, які посилаються на них. Найкращий спосіб обробки цього типу помилок, ймовірно, полягає в тому, щоб зробити консенсусний клієнт обізнаним про можливість і здатним граціозно збоювати. Потрібне додаткове вивчення того, як саме це зробити.
Найкращим підходом, ймовірно, буде оновлення поруч або після MaxEB, в якому клієнти згоди будуть проінформовані про можливість зашифрованих блокових семантик, а валідатори будуть закликані публікувати підказки. Наприклад, після MaxEB може знадобитися, щоб нові валідатори публікували підказки, а старшим валідаторам може бути надана стимулююча допомога для оновлення.
Забудовники почнуть використовувати механізм, як тільки достатня частина набору валідаторів його прийме для отримання достатнього розміру комітетів (тобто задовільної конфіденційності та ймовірності розшифрування).
Якщо наш підхід дійсно має перевагу у латентності в порівнянні з багатохоповим ретрансляцією, ринок повинен його прийняти без потреби в протоколі забезпечувати використання або втілювати певну параметризацію.
Нам потрібно видалити реле і думаємо, що це досить елегантний спосіб зробити це. Це вимагає змін на рівні консенсусу, але не потребує нового обладнання або ключового матеріалу з боку валідаторів.
Недолік полягає в тому, що це складна зміна у рівень згоди для механізму, який (якщо вибірковий, як запропоновано) може бути прийнятий або не прийнятий ринком. Однак, багато потенційних змін у трубопроводі MEV стикаються з аналогічними питаннями стосовно прийняття та оптимізації доходів (наприклад, списки включення). Також може бути інші випадки використання у майбутньому, які залежать від наявності інфраструктури порогового шифрування в наборі перевіряючих.





