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

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

Існуючі рішення, які не піддаються цензурі

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

Крім FOCIL спільнота також обговорювала схеми кількох одночасних пропозицій (MCP). Ця концепція спочатку була запропонована Макс РесниквMultiplicity механізм, який спрямований на розпорошення влади шляхом введення декількох паралельних пропозицій блоків, зменшуючи здатність будь-якого окремого вузла цензурувати транзакції. У механізмі Multiplicity кожен валідатор вибирає частину транзакцій зі свого власного мемпулу, щоб сформувати «спеціальний пакет транзакцій». Ці валідатори підписують вибрані ними пакети транзакцій і надсилають їх ініціатору поточного раунду. Ініціатор повинен включити принаймні 2/3 цих пакетів транзакцій у запропонований блок, щоб він вважався дійсним. Цей механізм гарантує, що ініціатори не можуть в односторонньому порядку визначати зміст блоку, тим самим зменшуючи можливість цензури. Щоб ще більше стимулювати ініціаторів до справедливого включення транзакцій, цей механізм реалізує правило «умовних чайових», згідно з яким комісію за транзакцію отримують лише ті, хто включає транзакцію. Комісія за транзакцію не призначається автоматично першому ініціатору за включення транзакції, а розподіляється між усіма ініціаторами, які фактично включають транзакцію на основі конкретних умов. Це збільшує витрати на цензуру, оскільки необхідно підкупити всіх ініціаторів, які включають транзакцію.

BRAID: Покращена реалізація MCP

Спираючись на концепцію Multiplicity, Макс Резнік представив BRAID, більш складну і витончену реалізацію MCP. Макс представлений КОСИЧКАна семінарі "DeFi в ері MEV", організованому Paradigm. BRAID досягає MCP, дозволяючи кільком пропонентам запропонувати блоки на різних паралельних ланцюгах та використовуючи механізм консенсусу синхронізації для підтримки узгодженості між цими ланцюгами. Кожен ланцюг має свого пропонента, і всі пропоненти випускають свої блоки одночасно в тому ж слоті. Виконавчий шар Ethereum агрегує блоки, згенеровані всіма під-ланцюгами в цьому слоті, формуючи виконавчий блок. Потім він виконує дедублікацію, сортує та виконує ці транзакції відповідно до попередньо визначених правил, зменшуючи можливість будь-якої окремої сутності маніпулювати записами транзакцій.

Дизайн BRAID уникає введення додаткових ролей, що уникне складнощів, пов'язаних з механізмами стимулювання / покарання. Однак його реалізація є досить складною, вимагає координації синхронізації та обробки даних кількох підланок.

Проблеми з механізмом BRAID

Jonahbчлен команди Blockchain Capital зазначив, щопроблема з механізмом BRAID: модель «умовних чайових» висуває вимоги до ліквідності, впливаючи на користувацький досвід. Ця модель є динамічною стратегією ціноутворення, яка вимагає від користувачів надання певної кількості ліквідності для забезпечення стійкості до цензури транзакцій. Під час надсилання транзакції користувачі повинні встановити два значення чайових (T і t). Фактична сума сплачених чайових залежить від кількості ініціаторів, які включають транзакцію.

1. Більше значення чайки, T, представляє максимальну комісію, яку користувач готовий заплатити, щоб забезпечити, що їхня транзакція не буде цензурною. Метою є надихнути пропонентів включити транзакцію, навіть якщо інші пропоненти не готові це зробити. Якщо тільки один пропонент включає транзакцію, вони отримують повну суму, T.
2. Мінімальне значення чайки, t, встановлюється користувачем. Якщо угода включається одночасно декількома пропонентами, користувачу потрібно оплатити лише t, яке буде розподілене серед пропонентів. Якщо користувачу менше цікаво опір цензурі, він може встановити T рівним t і відправити свою угоду лише одному пропоненту.

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

Щоб вирішити цю проблему, Джонас запропонував два рішення:

• Доказ ліквідності після стану: Користувачі надають доказ під час подання транзакції, вказуючи на те, що вони матимуть достатню ліквідність для виплати T після виконання транзакції (наприклад, користувач матиме 1 мільйон доларів США ліквідності після транзакції). Цей метод дозволяє користувачам продовжувати, навіть якщо у них недостатньо коштів для оплати T перед транзакцією. Складність цього підходу полягає в тому, що ініціатори повинні знати остаточний стан транзакції перед виконанням. Однак багато фінансових операцій включають спільні стани (наприклад, кілька транзакцій, що впливають на один і той же баланс рахунку), що ускладнює для ініціаторів точне визначення стану після транзакції до того, як замовлення транзакції буде завершено. Цей підхід вимагає індивідуальних доказів для кожного типу транзакцій, що робить його менш практичним.
• Страхування цензури: вводить страховиків цензури третьої сторони (постачальників СЦ), щоб гарантувати користувачеві T. Користувачі сплачують страховий внесок, rT, де r базується на ймовірності того, що транзакцію буде цензуровано. Цей підхід зменшує необхідність у користувачів негайно готувати велику кількість ліквідності та може попередити користувачів, якщо їх T занадто низький та перебуває під великим ризиком цензури. Однак встановлення ринку між користувачами та постачальниками СЦ займає час.

Думки спільноти щодо FOCIL проти BRAID

Розробник Ethereum-клієнта Prysm від GateТеренс нотаткиголовною перевагою BRAID є те, що вона не потребує додаткових учасників. Більшість моделей списку включення (IL), включаючи FOCIL, потребують додаткового учасника, що додає обмеження часу в межах слотів Ethereum, такі як час для подання IL, оновлення ставок та перевірки IL валідаторами. Однак FOCIL є простішою та більш гнучкою для реалізації порівняно з BRAID.

Дослідник парадигмиДен Робінсонцінує Дизайн BRAID для пріоритезації транзакцій, яка не визначається одним лідером (оферентом), таким чином ефективно пом'якшуючи MEV. Крім того, механізм умовних чайових BRAID стимулює поведінку без цензури, якої немає в FOCIL.

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

Дослідник Ethereumbarnabe.ethпоглядиFOCIL як досить загальний та масштабований механізм. Він визнає, що BRAID може покращити деякі з гарантій, наданих FOCIL, але обережно ставиться до повного відмови від моделі на основі лідера. Він вважає, що потрібно зробити більше роботи, щоб довести життєздатність BRAID.

заява:

1. Цю статтю відтворено з [Дослідження ChainFeeds], початковий заголовок — «Шлях Ethereum до опору на цензуру: Хто краще, BRAID чи FOCIL?», авторське право належить оригінальному автору [0XNATALIE], якщо у вас є будь-які зауваження щодо перепублікації, будь ласка, зв'яжіться з Команда Gate LearnКоманда якомога швидше вирішить це за відповідними процедурами.

2. Попередження: Погляди та думки, висловлені в цій статті, представляють лише особисті погляди автора і не становлять жодної інвестиційної поради.

3. Інші версії статті перекладені командою Gate Learn, не згадано в.Gate.io, перекладений матеріал не може бути відтворений, поширений або плагіатований.