Ethereum досліджує FOCIL та FairFIL для покращення механізмів проти цензури

У світі блокчейну ми часто чуємо слово: «опір цензурі».

Багато хто на перший погляд може сприйняти це як політизоване, навіть певного роду анархістське заклик, але для мережі розрахунків Ethereum, яка відкрита для користувачів по всьому світу, опір цензурі — це спочатку не політична позиція, а дуже конкретна технічна здатність.

Уявіть, що ви ініціюєте транзакцію у гаманці imToken.

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

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

Тому протягом останніх років Ethereum досліджує серію механізмів проти цензури, таких як FOCIL та FairFIL, щоб відповісти на наступне питання, яке здається простим, але насправді дуже важливе: як забезпечити, щоб будь-яка транзакція, що відповідає правилам протоколу, мала справедливу можливість потрапити до блоку?

Щоб зрозуміти, чому Ефіріуму потрібні ці механізми, спочатку треба з’ясувати, що відбувається з транзакцією після її відправлення з гаманця.

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

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

Проблема саме виникає на цьому етапі.

Після переходу Ethereum на механізм PoS (доказ власності) для запобігання економічному монополізму великих стейкінг-пулів за допомогою MEV (максимально витягувана вартість), Ethereum ввела систему PBS (Proposer-Builder Separation, розділення пропонента та будівельника). У цій архітектурі обробка кожної транзакції Ethereum розподіляється між двома ролями:

• Будівник (Builder): відповідає за збір угод, впорядкування послідовності угод, пошук арбітражних та клірингових можливостей та створення блоку з максимально можливим прибутком;
• Пропонент (Proposer): відповідає за вибір одного з кандидатів на блоки, поданих Builder, та його підтвердження в мережі;

Це розподілення обов’язків має дуже практичні переваги.

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

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

Але він також несподівано призвів до іншого побічного ефекту — надмірної концентрації права на побудову блоків. Наприклад, більше 90% блоків Ethereum у всій мережі виробляються лише декількома професійними Builder’ами, а оскільки ці Builder’и зазвичай мають чітку комерційну базу, вони піддаються зовнішньому тиску з боку законодавства певних країн або регіонів (наприклад, санкцій OFAC), що фактично створює ризик централізації.

Саме через це, коли ці основні Builder вибірково фільтрують транзакції деяких сенситивних контрактів (наприклад, Tornado Cash) або певних адрес, ці транзакції можуть застрягнути у довготривалому стані незабезпечення, а також стикнутися з ризиком «прихованого блокування».

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

Тому обговорення «антицензурності» Ефіру — це не лише велика концепція, пов’язана з політикою, регулюванням чи санкціями, а перш за все дуже конкретна технічна проблема:

Чи гарантує мережа, що транзакція, яка відповідає правилам протоколу, отримає можливість потрапити до блоку за розумний термін?

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

Для цього дослідники Ethereum запропонували Inclusion Lists, які зазвичай називають «списками включення».

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

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

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

Проте це все ще два питання, які потрібно вирішити: хто саме має складати список та що робити, якщо хтось навмисно пропустить угоду.

FOCIL і FairFIL, саме цими напрямками ми й рухаємося.

1. FOCIL: Більше не дозволяти одному Proposer-у створювати список окремо

FOCIL (Fork-Choice Enforced Inclusion Lists) передає право вирішувати, чи мають бути обов’язково включені транзакції, від окремого пропонувача до «комітету верифікаторів», що складається з кількох сторін.

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

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

Тому його перевага полягає в тому, що не потрібно вірити, що кожен член комітету залишається нейтральним.

Але одного списку недостатньо: якщо Builder отримає список, але все ще вирішить не виконувати його, список перетвориться на необов’язкову рекомендацію.

Тому FOCIL додав другий рівень дизайну, ввівши правило вибору форку (Fork-Choice Rule) для жорсткого обмеження, що змушує всі вузли, відповідальні за голосування та перевірку, строго перевіряти блоки, надіслані Builder. Якщо виявляється, що Builder порушує інтегрований список включення комітету, вся мережа безпосередньо відмовляється голосувати за цей блок.

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

2. FairFIL: потрібно не лише виправляти пропуски, а й забезпечити їх перевіряємість

Якщо FOCIL жорстко забороняє цензуру на рівні консенсусних правил, то FairFIL (Fair Forward Inclusion Lists) та механізми відповідальності роблять цензуру надзвичайно витратною і непостійною з економічної точки зору.

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

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

Його загальну логіку можна розуміти у три кроки.

• Спочатку протокол встановлює набір відкритих, перевіряємих опорних правил, які визначають, які транзакції у загальному пули транзакцій у нормальних умовах мають право потрапити до поточного блоку; якщо деякі транзакції, які за опорними правилами мали б мати право потрапити до блоку, на практиці не були оброблені, Builder повинен публічно включити їх до FairFIL;
• Після цього валідатори перевіряють, чи повний цей список; якщо Builder свідомо пропустив транзакції, що відповідають критеріям, і не включив їх у список, таку дію може бути виявлено, і це вплине на те, чи підтримають валідатори цей блок;
• Нарешті, дійсні угоди FairFIL стануть завданнями, які мають пріоритет для обробки в наступних блоках; наступний Builder все ще може визначити їхнє конкретне розташування в блоці, але не може продовжувати ігнорувати їх;

Якщо угоду пропущено кілька разів поспіль, відповідний блок може втратити підтримку верифікаторів, а будівельник може втратити весь дохід від блоку.

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

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

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

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

Те, що воно справді покращило — це визначеність процесу включення у торгівлю.

• Спочатку, транзакція, що відповідає правилам, більше не буде повністю залежати від вибору певного Buildera: навіть якщо поточний Builder не бажає обробляти її, інші верифікатори можуть встановити вимогу до включення на рівні протоколу за допомогою списку включення;
• По-друге, право на включення транзакцій і право на впорядкування транзакцій можуть поступово розділитися: Builder зможе й надалі використовувати професійні алгоритми для впорядкування транзакцій і підвищення прибутку від блоку, а також продовжуватиме конкурувати в сфері арбітражу та ліквідації, але його повноваження щодо визначення «хто має право увійти на ринок» будуть обмежені;

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

Користувачам не потрібно знати, яким Builder’ом створено поточний блок, і не потрібно вірити кожному Builder’у, що він буде активно залишатися нейтральним — вузли перевірки перевірятимуть блоки за однаковими правилами, роблячи складним для мережі прийняття блоків, що порушують зобов’язання щодо включення.

У майбутньому гаманці та браузери блоків можуть навіть надавати більш детальну інформацію про статус транзакцій.

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

Проте механізм опору цензурі не означає, що кожна транзакція буде успішно завершена одразу.

Транзакції з недостатнім балансом, конфліктом Nonce, занадто низьким Gas або вже недійсними умовами виконання контракту все ще можуть не потрапити в блок; під час перевантаження мережі та недостатку місця в блоках користувачім все ще потрібно чекати підтвердження через конкуренцію за комісії.

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

Згідно з прогресом, станом на серпень 2026 року EIP-7805, що відповідає FOCIL, все ще перебуває у статусі Draft, але був обраний розробниками Ethereum як головний елемент консенсусного рівня Hegotá та перейшов у фазу Scheduled for Inclusion, що означає, що команди клієнтів погодилися розробляти та тестувати мережу навколо нього, але точна дата запуску в основній мережі ще не визначена.

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

Об’єктивно кажучи, Ефір не може гарантувати, що кожен Builder, верифікатор та оператор інфраструктури завжди залишатиметься нейтральним.

Учасники можуть піддаватися регуляторному тиску, переслідувати власні інтереси або отримувати зовнішні стимули. Справді стійка децентралізована мережа не може ґрунтуватися на ідеалістичному припущенні, що «усі зроблять правильний вибір».

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

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

З цієї точки зору Ефір дійсно намагається перетворити цю обітницю з декларації цінностей на поступове втілення в самому протоколі.

Варто чекати.