В мире блокчейнов мы часто слышим термин: «Противодействие цензуре».
Многие при первом упоминании могут воспринять его как политизированный лозунг, даже окрашенный в анархистские тона. Но для такой глобальной расчетной сети, как Ethereum, противодействие цензуре — это в первую очередь не политическая позиция, а конкретная техническая способность.
Представьте: вы инициируете транзакцию в кошельке imToken.
Подпись корректна, баланс счета достаточен, комиссия Gas тоже не низкая, но транзакция упорно не записывается в блок, статус в кошельке остается на отметке «Pending». В то же время другие транзакции с сопоставимыми или даже меньшими комиссиями постоянно добавляются в блокчейн.
Тогда возникает вопрос: кто в конечном итоге имеет право решать, попадет ли транзакция в блок? Ведь если Ethereum по-прежнему будет нуждаться в нескольких централизованных участниках, определяющих, какие транзакции могут быть включены, то между ним и традиционной финансовой системой не будет никакой принципиальной разницы.
Поэтому Ethereum в последние годы исследует такие механизмы противодействия цензуре, как FOCIL, FairFIL и другие, пытаясь ответить на кажущийся простым, но на самом деле ключевой вопрос: как гарантировать, что любая транзакция, соответствующая правилам протокола, получит справедливый шанс попасть в блок?
1. Откуда вообще берется «цензура»?
Чтобы понять, зачем Ethereum нужны эти механизмы, сначала нужно разобраться, что происходит с транзакцией после ее отправки из кошелька.
Когда пользователь подписывает и отправляет транзакцию в кошельке, она обычно сначала попадает в публичный пул транзакций Ethereum, также известный как мемпул (Mempool). Это скорее зона ожидания, где хранится множество еще не записанных в блок транзакций.
Но попадание в зону ожидания не означает, что транзакция уже попала в блокчейн. Кто-то должен отобрать транзакции из этого пула, определить их порядок, сформировать полный блок и передать его сети для подтверждения.
Проблема возникает именно на этом этапе.
После перехода Ethereum на механизм Proof-of-Stake (PoS), чтобы предотвратить экономическую монополию крупных стейкинг-пулов, использующих MEV (максимально извлекаемую ценность), Ethereum внедрил архитектуру PBS (Proposer-Builder Separation, разделение предложителей и сборщиков). В этой системе процесс обработки каждой транзакции Ethereum фактически разделен между двумя ролями:
- Сборщик (Builder): отвечает за сбор транзакций, определение их порядка, поиск возможностей для арбитража и ликвидации, а также за построение блока с максимально возможной доходностью;
- Предложитель (Proposer): отвечает за выбор одного из кандидат-блоков, предоставленных Builder, и его предложение сети.
Такое разделение труда имеет очевидные практические преимущества.
Как известно, стратегии MEV становятся все сложнее. Если бы от каждого обычного валидатора требовалось самостоятельно выполнять сортировку транзакций и оптимизацию блока, это неизбежно дало бы преимущество крупным узлам с большими капиталами, данными и техническими возможностями.
Поэтому, передавая сложную работу по построению блоков профессиональным Builder, обычные валидаторские узлы, даже не обладая продвинутыми возможностями для арбитража, могут участвовать в предложении блоков и получать соответствующее вознаграждение, тем самым смягчая влияние MEV на децентрализацию стейкинга.
Однако это непреднамеренно привело к другому побочному эффекту — чрезмерной концентрации права на построение блоков. Например, в настоящее время более 90% блоков в сети Ethereum производятся всего несколькими профессиональными Builder. Поскольку эти Builder обычно имеют четкую юридическую базу и легко могут подвергаться внешнему давлению со стороны законов и правил конкретных стран или регионов (например, санкционных списков OFAC), это фактически создает риск централизации.
Именно поэтому, если несколько ведущих Builder выборочно отфильтруют транзакции, связанные с определенными чувствительными контрактами (такими как Tornado Cash) или адресами, эти транзакции могут надолго застрять в ожидании и даже столкнуться с риском «скрытой блокировки».
В общем, с точки зрения обычного пользователя, Ethereum — это открытая сеть, к которой может подключиться любой для перевода средств или вызова смарт-контрактов. Но с точки зрения работы протокола, отправка транзакции — это только первый шаг. Чтобы транзакция действительно вступила в силу, она должна быть выбрана, упорядочена и записана в блок каким-либо сборщиком блоков.
Таким образом, «противодействие цензуре» в контексте Ethereum — это не просто глобальная концепция, связанная с политикой, регулированием или санкциями. В первую очередь, это очень конкретная техническая проблема:
Когда транзакция соответствует правилам протокола, может ли сеть гарантировать, что у нее будет возможность попасть в блок в разумные сроки?
2. От FOCIL до FairFIL: Как Ethereum ограничивает сборщиков блоков
Фактически, на этом этапе проблема становится ясна: Builder повышают эффективность построения блоков, но если право включения транзакций надолго останется сосредоточенным в руках нескольких Builder, Ethereum снова столкнется с риском новой централизованной монополии.
Для решения этой проблемы исследователи Ethereum предложили Inclusion Lists, обычно называемые «списками включения».
Это название может показаться абстрактным, но его основная логика не сложна: Builder по-прежнему отвечает за создание блока, но не может единолично решать судьбу всех транзакций. Обычные валидаторские узлы, участвующие в стейкинге Ethereum, также должны сохранить часть полномочий, позволяя им перечислять некоторые транзакции, которые обязательно должны быть обработаны.
Приведем аналогию с автобусной остановкой: блок можно представить как рейс с ограниченным количеством мест.
Builder определяет, как большинство пассажиров будут стоять в очереди и на каких местах сидеть, чтобы за счет более эффективного размещения повысить доходность всего рейса. Но валидаторские узлы также могут подать «список обязательных пассажиров». Пока транзакции в этом списке остаются действительными, готовы платить разумную комиссию и в блоке есть достаточно места, Builder не может бесконечно отказывать им, руководствуясь лишь собственными предпочтениями.
Однако вопросы о том, кто именно составляет такой список включения и что делать, если кто-то намеренно пропускает транзакции, остаются проблемами, требующими дальнейшего решения.
FOCIL и FairFIL — это как раз разработки, идущие в этих двух направлениях.
1. FOCIL: Отказ от составления списка включения одним единственным Proposer
FOCIL (Fork-Choice Enforced Inclusion Lists) передает право решать, какие транзакции должны быть обязательно включены, от отдельного предложителя «комитету валидаторских узлов», состоящему из нескольких сторон.
В каждом цикле создания блока сеть случайным образом выбирает группу валидаторских узлов для формирования временного комитета. Каждый член комитета независимо наблюдает за сетевым мемпулом и отправляет свой локальный список включения.
Это означает, что даже если 99% Builder и предложителей в сети попытаются подвергнуть цензуре какую-либо транзакцию, достаточно, чтобы в комитете был хотя бы один честный узел, включивший эту транзакцию в список, и у нее появится шанс попасть под действие ограничений протокола. Если цензоры захотят продолжить ее исключать, им придется обойти не одного участника, а нескольких независимых.
Таким образом, его преимущество в том, что не нужно полагаться на то, что каждый член комитета будет сохранять нейтралитет.
Но одного только наличия списка недостаточно. Если 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 все еще может определить их конкретное положение в блоке, но не может продолжать делать вид, что их не видит;
Если транзакция пропускается несколько раз подряд, связанные блоки могут лишиться поддержки валидаторов, а Builder может потерять вознаграждение за весь блок.
Другими словами, «подотчетность», на которой настаивает FairFIL, фактически вводит постепенно возрастающие экономические штрафы: Builder, постоянно подвергающий цензуре транзакции, столкнется с риском лишения всего вознаграждения за блок или даже потери части стейкингового депозита.
Это также направление постепенного углубления механизмов противодействия цензуре в Ethereum, целью которого является создание более реалистичных ограничений: даже если у небольшого числа участников есть намерение цензурировать, им будет трудно долго контролировать вход для транзакций; даже если кто-то намеренно пропускает транзакции, ему придется оставлять следы и платить все более высокую цену за продолжение цензуры.
3. Что это значит для обычного пользователя?
Для обычных пользователей, которые ежедневно переводят средства, обменивают активы или используют DeFi через кошельки, эти базовые механизмы, даже если они будут реализованы в будущем, не потребуют изменения существующих привычек.
Пользователи по-прежнему будут вводить сумму, подтверждать Gas, завершать подпись в кошельке и ждать, пока транзакция попадет в блокчейн. Но на невидимом базовом уровне протокола логика того, сможет ли транзакция попасть в блок, может претерпеть важные изменения.
Что это действительно улучшает, так это определенность процесса включения транзакций.
- Во-первых, транзакция, соответствующая правилам, больше не будет полностью зависеть от выбора конкретного Builder: даже если текущий Builder не хочет ее обрабатывать, другие валидаторы через список включения могут установить для нее требование о включении на уровне протокола;
- Во-вторых, право на включение транзакций и право на их упорядочение могут постепенно разделиться: Builder по-прежнему может использовать профессиональные алгоритмы для определения порядка транзакций и повышения доходности блока, а также продолжать конкурировать в области арбитража и ликвидации, но его власть, решающая, «кто имеет право войти на рынок», будет ограничена;
Если взглянуть глубже, доверенная нейтральность Ethereum также может постепенно превратиться из ценностного предложения, зависящего от обещаний участников, в набор правил протокола, автоматически исполняемых клиентом.
Пользователям не нужно знать, какой Builder создал текущий блок, им не нужно безоговорочно доверять, что эти Builder будут активно сохранять нейтралитет. Валидаторские узлы будут проверять блоки по одному и тому же набору правил, блоки, нарушающие обязательства по включению, будет трудно получить одобрение сети.
В будущем кошельки и обозреватели блоков, возможно, смогут предоставлять более подробный статус транзакций на этой основе.
Транзакция больше не будет просто отображаться с общим статусом «в обработке». Вместо этого пользователю могут сообщить, попала ли она уже в список включения, получила ли обязательство на включение в последующие блоки, и происходит ли дальнейшее ожидание из-за недостаточного Gas, недействительности транзакции или аномалии на этапе построения блока.
Однако механизмы противодействия цензуре не означают, что каждая транзакция будет немедленно успешной.
Транзакции с недостаточным балансом, конфликтом Nonce, слишком низким Gas или с условиями выполнения контракта, которые уже устарели, по-прежнему могут не попасть в блок. Когда сеть перегружена и пространство блоков ограничено, пользователям все равно придется конкурировать за комиссии, чтобы дождаться подтверждения.
Но эти механизмы в основном улучшают ситуацию с транзакциями, которые изначально были действительны, имели разумную комиссию и уже распространились в публичный пул транзакций, но не должны бесконечно откладываться из-за субъективного выбора нескольких сборщиков блоков.
Что касается прогресса, по состоянию на август 2026 года, EIP-7805, соответствующий FOCIL, все еще находится в статусе черновика (Draft). Однако он уже выбран разработчиками ядра Ethereum в качестве ключевого нововведения (Headliner) уровня консенсуса для обновления Hegotá и перешел в стадию «Запланировано к включению» (Scheduled for Inclusion). Это означает, что команды, разрабатывающие клиенты, согласились продвигаться в реализации и тестировании в сети, но конкретная дата запуска в основной сети еще не определена окончательно.
FairFIL находится на более ранней стадии. В настоящее время это в основном исследовательское предложение, опубликованное в июле 2026 года. Потребуются более широкие обсуждения, реализация и проверки безопасности, прежде чем оно сможет войти в дорожную карту Ethereum.
В заключение
Объективно говоря, Ethereum не может гарантировать, что каждый Builder, валидатор и оператор инфраструктуры всегда будет сохранять нейтралитет.
Участники могут подвергаться давлению со стороны регуляторов, могут преследовать собственные интересы, могут получать внешние стимулы. По-настоящему устойчивая децентрализованная сеть не может строиться на идеалистическом предположении, что «все будут поступать правильно».
Подлинное противодействие цензуре заключается в том, что даже если часть участников пытается влиять на транзакции, другие участники все равно способны преодолеть этот контроль; даже если кто-то отходит от принципа нейтральности, протокол может сделать такое поведение видимым, дорогостоящим и трудно поддерживаемым.
От изначальных списков включения до FOCIL, который с помощью распределенного комитета совместно ограничивает Builder, и до FairFIL, требующего, чтобы пропуски можно было публично проверить. От возможности для любого отправить транзакцию до гарантии, что транзакция любого будет замечена.
С этой точки зрения Ethereum действительно пытается превратить это обещание из декларации о ценностях в неотъемлемую часть самого протокола, шаг за шагом.
Есть чего ждать.
