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