Ethereum исследует FOCIL и FairFIL для улучшения механизмов против цензуры

В мире блокчейна мы часто слышим слово: «сопротивление цензуре».

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

Представьте, что вы инициируете транзакцию в кошельке imToken.

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

Тогда вопрос сводится к тому, кто именно имеет право решать, может ли транзакция попасть в блок? Ведь если Эфириум в конечном итоге всё ещё будет зависеть от нескольких централизованных участников, определяющих, какие транзакции могут быть добавлены в цепочку, то между ним и традиционной финансовой системой не будет никакой существенной разницы.

Поэтому за последние годы Ethereum исследует ряд механизмов против цензуры, таких как FOCIL и FairFIL, пытаясь ответить на вопрос, который кажется простым, но на самом деле крайне важен: как обеспечить справедливый шанс для любой транзакции, соответствующей протокольным правилам, попасть в блок?

Чтобы понять, почему Эфириуму нужны эти механизмы, сначала нужно разобраться, что происходит с транзакцией после того, как она отправляется из кошелька.

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

Но попадание в очередь не означает, что транзакция уже записана в блокчейн; необходимо, чтобы кто-то выбрал транзакции, определил их порядок, сформировал полный блок и передал его на подтверждение сети.

Проблема возникает именно на этом этапе.

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

• Строитель (Builder): отвечает за сбор транзакций, упорядочивание транзакций, поиск возможностей для арбитража и ликвидации, а также создание блока с максимально возможной прибылью;
• Предлагатель (Proposer): отвечает за выбор одного из кандидатов на блок, представленных Builder, и его отправку в сеть;

Это разделение труда имеет реальные преимущества.

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

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

Однако это также неожиданно привело к другому побочному эффекту — чрезмерной концентрации прав на создание блоков. Например, более 90% блоков Ethereum в сети производятся лишь несколькими профессиональными билдерами. Поскольку эти билдеры обычно имеют четко определенную коммерческую базу, они подвержены внешнему давлению со стороны законодательства конкретных стран или регионов (например, санкционным спискам OFAC), что фактически создает централизованный риск.

Именно поэтому, как только эти основные строители выбирают фильтрацию определенных чувствительных контрактов (например, Tornado Cash) или транзакций с конкретных адресов, такие транзакции попадают в длительное состояние, когда они не могут быть включены в блок, и подвергаются риску «скрытого блокирования».

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

Таким образом, обсуждаемая в Ethereum «цензура» — это не просто абстрактная концепция, связанная с политикой, регулированием или санкциями; это прежде всего очень конкретная техническая проблема:

Когда транзакция соответствует правилам протокола, может ли сеть гарантировать, что она получит возможность попасть в блок в разумные сроки?

На самом деле,说到这里，问题已经很清楚了：Builder 可以提高区块构建效率，但如果交易包含权长期集中在少数 Builder 手中，以太坊将再次面临新的中心化垄断风险。

Для этого исследователи 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 нарушает интегрированный комиссией список допущенных, вся сеть немедленно откажется голосовать за этот блок.

Это означает, что нарушительские блоки будут мгновенно признаны недействительными протоколом, и Билдер понесет огромные потери из-за неудачной генерации блока.

2. FairFIL: нужно не только устранять пробелы, но и обеспечивать их проверяемость

Если FOCIL жестко запрещает цензуру на уровне консенсусных правил, то FairFIL (Fair Forward Inclusion Lists) и механизмы подотчетности делают цензуру чрезвычайно дорогостоящей и неустойчивой с экономической точки зрения.

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

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

Его основную логику можно понять в три шага.

• Сначала протокол устанавливает набор открытых и проверяемых Referentных правил, определяющих, какие транзакции в общем пуле транзакций в нормальных условиях имеют право попасть в текущий блок; если какие-либо транзакции, которые изначально имели право попасть в блок согласно Referentным правилам, в итоге не были обработаны, Builder должен публично включить их в FairFIL;
• Затем валидаторы проверят, полный ли этот список; если билдер намеренно не включил в список соответствующие транзакции, такое поведение может быть обнаружено и повлиять на решение валидаторов о поддержке этого блока;
• Наконец, действительные транзакции FairFIL станут задачами, которые необходимо обрабатывать в приоритетном порядке в последующих блоках; следующий Builder по-прежнему может определять их конкретное расположение в блоке, но не может продолжать игнорировать их;

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

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

Это также направление постепенного углубления механизма цензуры против Ethereum, направленное на создание более реалистичных ограничений, при которых даже небольшое количество участников с намерением цензурировать с трудом сможет долгосрочно контролировать вход транзакций; даже если кто-то намеренно пропустит транзакцию, это оставит след и потребует все более высоких затрат для постоянной цензуры.

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

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

Оно действительно улучшает определенность процесса включения в сделку.

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

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

Пользователям не нужно знать, каким Builder-ом построен текущий блок, и не нужно доверять каждому Builder-у, что он будет добровольно сохранять нейтральность — валидационные узлы проверяют блоки по одним и тем же правилам, делая трудным получение сетевого одобрения для блоков, нарушающих обязательства по включению.

В будущем кошельки и блокчейн-браузеры могут даже предоставлять более подробную информацию о статусе транзакций на основе этого.

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

Однако механизм сопротивления цензуре не означает, что каждая транзакция будет успешной сразу.

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

Однако он в первую очередь улучшает транзакцию, которая изначально была действительной, имела разумную комиссию и уже была распространена в публичный пул транзакций, и не должна бесконечно задерживаться из-за субъективного выбора небольшого числа строителей блоков.

На данный момент, по состоянию на август 2026 года, EIP-7805, соответствующий FOCIL, все еще находится в статусе Draft, однако он был выбран основными разработчиками Ethereum в качестве главной функции консенсусного уровня для апгрейда Hegotá и перешел в этап «Запланировано для включения», что означает, что команды клиентов согласились продвигать реализацию и разработку сетевых тестов вокруг него, но окончательная дата запуска на основном сети еще не определена.

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

Объективно говоря, Эфириум не может гарантировать, что каждый строитель, валидатор и оператор инфраструктуры будут всегда нейтральны.

Участники могут подвергаться регуляторному давлению, преследовать собственные интересы или реагировать на внешние стимулы; по-настоящему устойчивая децентрализованная сеть не может строиться на идеализированном предположении, что все будут делать правильные вещи.

Настоящая цензура-устойчивость означает, что даже если часть участников пытается вмешаться в транзакции, другие участники остаются в состоянии преодолеть этот контроль; даже если кто-то решит отклониться от принципа нейтралитета, протокол делает такое поведение видимым, дорогостоящим и трудным для поддержания.

От первоначального списка включений до FOCIL, где строители совместно контролируются распределённым комитетом, и далее до FairFIL, требующего, чтобы пропущенные действия могли быть публично проверены — от разрешения любому отправлять транзакции до гарантии того, что транзакции любого пользователя имеют шанс быть увиденными.

С этой точки зрения Эфириум действительно постепенно превращает это обещание из декларации ценности в сам протокол.

Стоит ожидать.