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

РозширенийSep 27, 2024
У цій статті розглядаються обмеження механізму примусового включення у вирішенні питань цензури транзакцій. Незважаючи на те, що системи, такі як Arbitrum та Optimism, використовують цей механізм, дозволяючи користувачам запитувати, щоб конкретні транзакції були включені протягом певного періоду часу, на ланцюжках з багатим станом, секвенсори все ще можуть призводити до невдалих транзакцій, модифікуючи спільний стан.
Практичні обмеження примусових механізмів для спротиву цензурі

Примітка авторів: init4 - це дослідницький колектив, що працює над інструментами наступного покоління Ethereum. Це дослідницька нотатка, а не документ про розкриття інформації. Хоча ми будемо обговорювати тонкості та прогалини в безпеці реалізованих та запропонованих систем, гіперболічним було б називати їх «вразливостями» або «раніше невідомими».

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

Доміно також йдуть по порядку :) Фото від Том ВілсоннаUnsplash

Визначення цензури

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

Механізми примусового включення

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

Сучасні ролапи, як правило, мають централізовану послідовність. Це означає, що цензура послідовника є тривіальною, оскільки вони можуть просто вибрати не включати будь-яку користувацьку транзакцію. Для зменшення цього ризику було створено кілька ролапів - включаючи Оптимізм та Arbitrum- мають механізми примусового включення. Ці механізми дозволяють користувачеві забезпечити виконання їх транзакції роллапом після певної затримки, незалежно від поведінки послідовника. Включення здійснюється за допомогою контракту, розгорнутого на L1. Тому транзакції з примусовим включенням (теоретично) мають такий самий спротив до цензури, як і інші транзакції Ethereum.

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

Також для Ethereum було запропоновано механізм примусового включення черезEIP-7547. Списки включення дозволили б пропозиціям блоків частково конкретизувати зміст наступного блоку. Якщо припустити, що ініціатори блоків мають менше стимулів до цензури, ніж розробники блоків, це забезпечить ефективне пом'якшення цензури.

Загалом кажучи, примусові механізми включення створюють нові обмеження для дійсних порядків. Вони роблять широкі класи порядків недійсними згідно з правилами протоколу.1. Примусове включення слід розглядати як можливість користувачу вказати підмножину майбутнього порядку. Усі дійсні порядки повинні розширювати примусову підмножину.

Розширення нашої моделі цензури

На жаль, підтвердження транзакції - це засіб, а не кінцева мета. Наша модель цензури неповна!

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

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

Півофіційно, ми можемо сказати, що для будь-якої взаємодії з ланцюжком є деякий предикат оцінювання f, який оцінює результати сортування і повертає 0 (не вдача мети) або 1 (досягнення мети). У цій моделі функція оцінювання цензора просто є запереченням: f’ = !f. Цензор досягає своєї мети, коли користувач її не досягає.3

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

Для простоти припустимо, що ми працюємо в стандартній моделі секвенсера «вперед»4. З примусовим включенням при обертанні секвенсера ми розберемося пізніше. У цій моделі секвенсор має повний контроль над послідовністю і може ідеально імітувати будь-який результат. Іншими словами, вони вільні вибирати з безлічі всіх можливих замовлень. Тоді наше напівформальне запитання про цензуру стає таким: «Чи існує якийсь дійсний порядок, над яким f дорівнює 0»? Якщо таке впорядкування існує, то секвенсор може його вибрати.

Звідти ми можемо розширити нашу модель, щоб врахувати примусове включення. «Чи існує деякий правильний порядок, який включає підпорядкування користувача, для якого f дорівнює 0?» Якщо існує такий порядок, послідовник може його вибрати. Примусове включення не заважає послідовнику контролювати порядок, воно лише обмежує їх поведінку. Нажаль, примусове включення має фундаментальні питання, які перешкоджають йому бути ефективним механізмом спротиву до цензури для багатьох транзакцій.

Проблема передачі

Механізми примусового включення означають, що сортування відбувається в одному з двох режимів: непримусовому або примусовому. Існує визначений момент, коли він переходить з непримусового на примусовий (і навпаки). Ця точка - передача. Передача становить складне питання для проектування механізмів примусового включення.

Повинен бути перехід від невимушеного до примусового включення.

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

Тому що творець партії може контролювати стан на момент передачі, він може впливати на результат примусової транзакції. Якщо він може впливати на результат, це потенційно може вплинути на результат оцінювання предиката. Наприклад, розгляньте просту взаємодію AMM. Користувач встановлює мінімальну прийнятну ціну, проте творець партії може забезпечити, що на момент передачі ринкова ціна буде нижче мінімальної прийнятної ціни. Це призводить до скасування транзакції користувача, ефективно цензурячи користувача.67

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

У практичних системах

[Б]удь-який користувач може повністю обійти Послідовника, щоб надіслати будь-яку транзакцію Arbitrum (включаючи ту, що, скажімо, ініціює повідомлення з L2 на L1 для виведення коштів) безпосередньо з рівня 1. Таким чином, цей механізм забезпечує спротив до цензури навіть у випадку, якщо Послідовник повністю не реагує або навіть зловмисницький.

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

Для EIP-7547, розробники вибирають місце, де відбуваються передачі блоку.8В результаті будівельник може вибрати місце передачі в межах блоку. Це означає, що вони можуть вільно вибирати префікс і постфікс.9доти, доки вони дотримуються правил блоку газу. Префікс може поставити ланцюг у стан, на якому транзакція повернеться, тоді як постфікс відновить ланцюг до нормального стану. Включення списків EIP-7547 не є достатнім для запобігання цензурі будь-якої транзакції, що отримує спірне стан. Проблема передачі унеможливлює ILs забезпечувати виконання транзакції у більшості випадків.

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

Випадок вивчення

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

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

Секвенцер або будівельник може маніпулювати станом при передачі.

Це вимагає, щоб секвенсер мав заставу, достатню для запозичення USDC, але це накладає лише надзвичайно малу вартість запозичення.10Крім того, застава може бути використана повторно для всіх випадків цензури, оскільки позика ніколи не залишається відкритою. В результаті, користувач AAVE або Compound на Optimism (або Arbitrum або будь-якому іншому централізованому послідовному ролапі) не має гарантії, що він зможе будь-коли вивести заставу. Послідовник може цензурувати будь-який виведення з будь-якого ринку позик у будь-який час. Примусове включення просто недостатньо для захисту користувачів від цензури.

Робота зі зворотнім зв'язком

У нас є кілька областей подальших досліджень.

По-перше, EIP-7547 можна легко покращити, вимагаючи, щоб угоди IL оброблялися в кінці наступного блоку. У контексті аукціону PBS цензура - MEV. Забудовник отримує деяку неекономічну цінність, яку вони повинні оцінити у суб'єктивній величині, вираженій в ETH. Цензура зі сторони забудовника спричиняє збільшення ставки блоку забудовника.11Це поширюється на пошуковиків, які можуть створювати цензурні пакети. Таким чином, частина економічної цінності цензури потрапляє до заявника, що надає стимул толерувати цензуру навіть тоді, коли він не бере в ній безпосередню участь. Розміщення примусових транзакцій у включення в кінець блоку позбавляє будівельника блоку можливості легко вкладати транзакції з примусовим включенням, і збільшує економічні витрати на спірну цензуру. Наприклад, цензура взаємодії AMM через спірний стан може потребувати відмови від деякого арбітражу AMM або високих витрат на виведення ринку за межі, які не можуть бути повернені, закриваючи сендвіч. Крім того, це обмежить цензурні пакети, створені Пошуковиками (а не будівельниками), до одного на блок.12Ми рекомендуємо виконання вверху блоку, оскільки префікс важливіший, ніж постфікс, проте це значно збільшило б вартість транзакції IL, оскільки це дозволило б видобуток MEV вверху блоку шляхом примусового включення.13 Вилучення права цензора атомарно постфіксувати транзакції IL є невеликим покращенням.

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

Третє, існує цікавий клас «незалежних від порядку» функцій оцінювання. Ці цілі не можуть бути цензуровані конфліктами між державою, або тому, що вони не мають доступу до конфліктного стану, або тому, що конфліктний стан, до якого вони мають доступ, має достатньо обмежень, щоб вважатися «надійним» у певному сенсі. До дій, незалежних від порядку, належить надсилання ETH до EOA, більшість ERC-20 відправок,14і деякі взаємодії DeFi, такі як додавання застави на ринок. Ці дії захищені від цензури через спротив. Цей клас цілей також має цікаві відповідності в безпечній міжланцюжковій комунікації та спротиву MEV і вартий більш глибокого вивчення. Додатки та протоколи можуть бути розроблені таким чином, що в деяких випадках включають тільки дії, що не залежать від порядку, але потрібне більше вивчення.

Висновок

Багата держава дозволяє зловмисникам цензурувати транзакції, включаючи їх. Проблема передачі є фундаментальною для механізмів примусового включення, і її можна лише пом'якшити. У централізованих послідовних зведеннях пом'якшення неможливе. Примусове включення не може вирішити проблему цензури в присутності держави, що сперечається. Великі класи економічно важливих операцій можуть піддаватися цензурі, навіть якщо вони включені силою. Проблема передачі даних є ендемічною для сучасних зведень і присутня в EIP Ethereum, які чинять опір цензурі. Як наслідок, примусове включення, хоча й корисне, ніколи не є достатнім для того, щоб забезпечити опір цензурі для мереж багатих держав. Rollups не «успадковують» властивості безпеки Ethereum, і нерозумно припускати, що вони це роблять. Коли ви перестаєте зациклюватися на інклюзивності, стає очевидним, що опір цензурі є окремим випадком опору MEV.

Ми б хотіли подякуватиМайк Нойдер, Тарун Чітра, та Брендон Кертіс для ознайомлення та зворотного зв'язку.

1

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

2

Це не пост про наміри, світ не потребує більше таких у цей момент.

3

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

4

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

5

Коли кілька користувачів хочуть отримати доступ до одного і того ж контракту, активу або стану, їх транзакції «конкурують» один з одним і потенційно впливають на результати один одного. Суперечка може виникати випадково або навмисно. Це нерозв'язна проблема багатого стану блокчейн-систем. Публічний доступ до спільної держави є коренем МЕВ, проблем масштабованості та занепаду цивілізованості в сучасному суспільстві.

6

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

7

Ми спеціально розглянули використання станової боротьби для скасування транзакцій у нашій статті 2017 року «Шахтарі – не ваші друзі”. Тоді термін «MEV» ще не використовувався.

8

Відомо, що PBS значно ускладнює забезпечення спротиву до цензури. Дивіться ВБ.@vbuterin/pbs_censorship_resistance">research note.

9

Префіксація та постфіксація транзакції зазвичай називається «сендвічем» і добре розуміється як метод використання суперечки про стан для вилучення MEV.

10

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

11

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

12

Зауважте, що це ґрунтується на правилах аукціону MEV, які запобігають чергуванню транзакцій з різних пакетів і не дозволяють транзакції "must revert". Якби ці правила були пом'якшені, щоб дозволити чергування txn пакетів, та/або якщо будівельники почнуть підтримувати блоки "must revert" у пачках, захист випарується б. Така динаміка виникає через те, що якщо транзакції IL повинні бути в кінці блоку, то непримусові транзакції не можуть бути перемежовані, а отже, може статися щонайбільше один пакет цензури шукача.

13

Ефективно дозволяючи будівельнику створювати обмежені пакети між блоками. Системи передконсенсусу, як FOCILможна було б зменшити це за допомогою Gate.

14

Для стандартного токена ERC-20 виклик переказу, як правило, не піддається цензурі через суперечку, оскільки треті сторони не можуть зменшити баланс користувача. Однак, розгляньте виклик transferFrom. Якщо схвалений переказувач - це контракт, який дозволяє суперечку власного стану, тоді дія може піддаватися цензурі через цю суперечку (споживання необхідної для виклику transferFrom схвалення непередбачуваним способом).

Відмова від відповідальності:

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

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

РозширенийSep 27, 2024
У цій статті розглядаються обмеження механізму примусового включення у вирішенні питань цензури транзакцій. Незважаючи на те, що системи, такі як Arbitrum та Optimism, використовують цей механізм, дозволяючи користувачам запитувати, щоб конкретні транзакції були включені протягом певного періоду часу, на ланцюжках з багатим станом, секвенсори все ще можуть призводити до невдалих транзакцій, модифікуючи спільний стан.
Практичні обмеження примусових механізмів для спротиву цензурі

Примітка авторів: init4 - це дослідницький колектив, що працює над інструментами наступного покоління Ethereum. Це дослідницька нотатка, а не документ про розкриття інформації. Хоча ми будемо обговорювати тонкості та прогалини в безпеці реалізованих та запропонованих систем, гіперболічним було б називати їх «вразливостями» або «раніше невідомими».

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

Доміно також йдуть по порядку :) Фото від Том ВілсоннаUnsplash

Визначення цензури

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

Механізми примусового включення

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

Сучасні ролапи, як правило, мають централізовану послідовність. Це означає, що цензура послідовника є тривіальною, оскільки вони можуть просто вибрати не включати будь-яку користувацьку транзакцію. Для зменшення цього ризику було створено кілька ролапів - включаючи Оптимізм та Arbitrum- мають механізми примусового включення. Ці механізми дозволяють користувачеві забезпечити виконання їх транзакції роллапом після певної затримки, незалежно від поведінки послідовника. Включення здійснюється за допомогою контракту, розгорнутого на L1. Тому транзакції з примусовим включенням (теоретично) мають такий самий спротив до цензури, як і інші транзакції Ethereum.

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

Також для Ethereum було запропоновано механізм примусового включення черезEIP-7547. Списки включення дозволили б пропозиціям блоків частково конкретизувати зміст наступного блоку. Якщо припустити, що ініціатори блоків мають менше стимулів до цензури, ніж розробники блоків, це забезпечить ефективне пом'якшення цензури.

Загалом кажучи, примусові механізми включення створюють нові обмеження для дійсних порядків. Вони роблять широкі класи порядків недійсними згідно з правилами протоколу.1. Примусове включення слід розглядати як можливість користувачу вказати підмножину майбутнього порядку. Усі дійсні порядки повинні розширювати примусову підмножину.

Розширення нашої моделі цензури

На жаль, підтвердження транзакції - це засіб, а не кінцева мета. Наша модель цензури неповна!

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

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

Півофіційно, ми можемо сказати, що для будь-якої взаємодії з ланцюжком є деякий предикат оцінювання f, який оцінює результати сортування і повертає 0 (не вдача мети) або 1 (досягнення мети). У цій моделі функція оцінювання цензора просто є запереченням: f’ = !f. Цензор досягає своєї мети, коли користувач її не досягає.3

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

Для простоти припустимо, що ми працюємо в стандартній моделі секвенсера «вперед»4. З примусовим включенням при обертанні секвенсера ми розберемося пізніше. У цій моделі секвенсор має повний контроль над послідовністю і може ідеально імітувати будь-який результат. Іншими словами, вони вільні вибирати з безлічі всіх можливих замовлень. Тоді наше напівформальне запитання про цензуру стає таким: «Чи існує якийсь дійсний порядок, над яким f дорівнює 0»? Якщо таке впорядкування існує, то секвенсор може його вибрати.

Звідти ми можемо розширити нашу модель, щоб врахувати примусове включення. «Чи існує деякий правильний порядок, який включає підпорядкування користувача, для якого f дорівнює 0?» Якщо існує такий порядок, послідовник може його вибрати. Примусове включення не заважає послідовнику контролювати порядок, воно лише обмежує їх поведінку. Нажаль, примусове включення має фундаментальні питання, які перешкоджають йому бути ефективним механізмом спротиву до цензури для багатьох транзакцій.

Проблема передачі

Механізми примусового включення означають, що сортування відбувається в одному з двох режимів: непримусовому або примусовому. Існує визначений момент, коли він переходить з непримусового на примусовий (і навпаки). Ця точка - передача. Передача становить складне питання для проектування механізмів примусового включення.

Повинен бути перехід від невимушеного до примусового включення.

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

Тому що творець партії може контролювати стан на момент передачі, він може впливати на результат примусової транзакції. Якщо він може впливати на результат, це потенційно може вплинути на результат оцінювання предиката. Наприклад, розгляньте просту взаємодію AMM. Користувач встановлює мінімальну прийнятну ціну, проте творець партії може забезпечити, що на момент передачі ринкова ціна буде нижче мінімальної прийнятної ціни. Це призводить до скасування транзакції користувача, ефективно цензурячи користувача.67

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

У практичних системах

[Б]удь-який користувач може повністю обійти Послідовника, щоб надіслати будь-яку транзакцію Arbitrum (включаючи ту, що, скажімо, ініціює повідомлення з L2 на L1 для виведення коштів) безпосередньо з рівня 1. Таким чином, цей механізм забезпечує спротив до цензури навіть у випадку, якщо Послідовник повністю не реагує або навіть зловмисницький.

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

Для EIP-7547, розробники вибирають місце, де відбуваються передачі блоку.8В результаті будівельник може вибрати місце передачі в межах блоку. Це означає, що вони можуть вільно вибирати префікс і постфікс.9доти, доки вони дотримуються правил блоку газу. Префікс може поставити ланцюг у стан, на якому транзакція повернеться, тоді як постфікс відновить ланцюг до нормального стану. Включення списків EIP-7547 не є достатнім для запобігання цензурі будь-якої транзакції, що отримує спірне стан. Проблема передачі унеможливлює ILs забезпечувати виконання транзакції у більшості випадків.

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

Випадок вивчення

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

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

Секвенцер або будівельник може маніпулювати станом при передачі.

Це вимагає, щоб секвенсер мав заставу, достатню для запозичення USDC, але це накладає лише надзвичайно малу вартість запозичення.10Крім того, застава може бути використана повторно для всіх випадків цензури, оскільки позика ніколи не залишається відкритою. В результаті, користувач AAVE або Compound на Optimism (або Arbitrum або будь-якому іншому централізованому послідовному ролапі) не має гарантії, що він зможе будь-коли вивести заставу. Послідовник може цензурувати будь-який виведення з будь-якого ринку позик у будь-який час. Примусове включення просто недостатньо для захисту користувачів від цензури.

Робота зі зворотнім зв'язком

У нас є кілька областей подальших досліджень.

По-перше, EIP-7547 можна легко покращити, вимагаючи, щоб угоди IL оброблялися в кінці наступного блоку. У контексті аукціону PBS цензура - MEV. Забудовник отримує деяку неекономічну цінність, яку вони повинні оцінити у суб'єктивній величині, вираженій в ETH. Цензура зі сторони забудовника спричиняє збільшення ставки блоку забудовника.11Це поширюється на пошуковиків, які можуть створювати цензурні пакети. Таким чином, частина економічної цінності цензури потрапляє до заявника, що надає стимул толерувати цензуру навіть тоді, коли він не бере в ній безпосередню участь. Розміщення примусових транзакцій у включення в кінець блоку позбавляє будівельника блоку можливості легко вкладати транзакції з примусовим включенням, і збільшує економічні витрати на спірну цензуру. Наприклад, цензура взаємодії AMM через спірний стан може потребувати відмови від деякого арбітражу AMM або високих витрат на виведення ринку за межі, які не можуть бути повернені, закриваючи сендвіч. Крім того, це обмежить цензурні пакети, створені Пошуковиками (а не будівельниками), до одного на блок.12Ми рекомендуємо виконання вверху блоку, оскільки префікс важливіший, ніж постфікс, проте це значно збільшило б вартість транзакції IL, оскільки це дозволило б видобуток MEV вверху блоку шляхом примусового включення.13 Вилучення права цензора атомарно постфіксувати транзакції IL є невеликим покращенням.

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

Третє, існує цікавий клас «незалежних від порядку» функцій оцінювання. Ці цілі не можуть бути цензуровані конфліктами між державою, або тому, що вони не мають доступу до конфліктного стану, або тому, що конфліктний стан, до якого вони мають доступ, має достатньо обмежень, щоб вважатися «надійним» у певному сенсі. До дій, незалежних від порядку, належить надсилання ETH до EOA, більшість ERC-20 відправок,14і деякі взаємодії DeFi, такі як додавання застави на ринок. Ці дії захищені від цензури через спротив. Цей клас цілей також має цікаві відповідності в безпечній міжланцюжковій комунікації та спротиву MEV і вартий більш глибокого вивчення. Додатки та протоколи можуть бути розроблені таким чином, що в деяких випадках включають тільки дії, що не залежать від порядку, але потрібне більше вивчення.

Висновок

Багата держава дозволяє зловмисникам цензурувати транзакції, включаючи їх. Проблема передачі є фундаментальною для механізмів примусового включення, і її можна лише пом'якшити. У централізованих послідовних зведеннях пом'якшення неможливе. Примусове включення не може вирішити проблему цензури в присутності держави, що сперечається. Великі класи економічно важливих операцій можуть піддаватися цензурі, навіть якщо вони включені силою. Проблема передачі даних є ендемічною для сучасних зведень і присутня в EIP Ethereum, які чинять опір цензурі. Як наслідок, примусове включення, хоча й корисне, ніколи не є достатнім для того, щоб забезпечити опір цензурі для мереж багатих держав. Rollups не «успадковують» властивості безпеки Ethereum, і нерозумно припускати, що вони це роблять. Коли ви перестаєте зациклюватися на інклюзивності, стає очевидним, що опір цензурі є окремим випадком опору MEV.

Ми б хотіли подякуватиМайк Нойдер, Тарун Чітра, та Брендон Кертіс для ознайомлення та зворотного зв'язку.

1

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

2

Це не пост про наміри, світ не потребує більше таких у цей момент.

3

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

4

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

5

Коли кілька користувачів хочуть отримати доступ до одного і того ж контракту, активу або стану, їх транзакції «конкурують» один з одним і потенційно впливають на результати один одного. Суперечка може виникати випадково або навмисно. Це нерозв'язна проблема багатого стану блокчейн-систем. Публічний доступ до спільної держави є коренем МЕВ, проблем масштабованості та занепаду цивілізованості в сучасному суспільстві.

6

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

7

Ми спеціально розглянули використання станової боротьби для скасування транзакцій у нашій статті 2017 року «Шахтарі – не ваші друзі”. Тоді термін «MEV» ще не використовувався.

8

Відомо, що PBS значно ускладнює забезпечення спротиву до цензури. Дивіться ВБ.@vbuterin/pbs_censorship_resistance">research note.

9

Префіксація та постфіксація транзакції зазвичай називається «сендвічем» і добре розуміється як метод використання суперечки про стан для вилучення MEV.

10

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

11

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

12

Зауважте, що це ґрунтується на правилах аукціону MEV, які запобігають чергуванню транзакцій з різних пакетів і не дозволяють транзакції "must revert". Якби ці правила були пом'якшені, щоб дозволити чергування txn пакетів, та/або якщо будівельники почнуть підтримувати блоки "must revert" у пачках, захист випарується б. Така динаміка виникає через те, що якщо транзакції IL повинні бути в кінці блоку, то непримусові транзакції не можуть бути перемежовані, а отже, може статися щонайбільше один пакет цензури шукача.

13

Ефективно дозволяючи будівельнику створювати обмежені пакети між блоками. Системи передконсенсусу, як FOCILможна було б зменшити це за допомогою Gate.

14

Для стандартного токена ERC-20 виклик переказу, як правило, не піддається цензурі через суперечку, оскільки треті сторони не можуть зменшити баланс користувача. Однак, розгляньте виклик transferFrom. Якщо схвалений переказувач - це контракт, який дозволяє суперечку власного стану, тоді дія може піддаватися цензурі через цю суперечку (споживання необхідної для виклику transferFrom схвалення непередбачуваним способом).

Відмова від відповідальності:

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