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

Автор: imToken

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

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

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

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

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

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

I. Откуда берется «цензура»?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

II. От FOCIL до FairFIL: как Ethereum ограничивает строителей блоков

На самом деле, когда мы говорим об этом, вопрос становится очень ясным: Строители могут повысить эффективность создания блоков, но если права на транзакции остаются сосредоточенными в руках немногих Строителей, Ethereum снова столкнется с риском новой централизации.

Для этого исследователи Ethereum предложили Inclusion Lists, обычно называемые «списками включения».

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

Например, автобусная остановка может быть понята как блок с ограниченным количеством мест.

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

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

FOCIL и FairFIL развиваются в этих двух направлениях.

1. FOCIL: больше не позволять одному Предложителю самостоятельно составлять список включения

FOCIL (Fork-Choice Enforced Inclusion Lists) передает полномочия решать, какие транзакции должны быть включены, от одного Предложителя к многостороннему «комитету валидаторов».

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

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

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

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

Поэтому FOCIL добавляет второй уровень дизайна, вводя правила выбора ветки (Fork-Choice Rule) для жесткого ограничения, заставляя узлы, ответственные за голосование и проверку, строго проверять блоки, представленные Строителем; как только они обнаруживают, что Строитель осмеливается нарушить интегрированный список включения комитета, вся сеть немедленно откажется голосовать за этот блок.

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

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

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

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

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

Его основная логика может быть понята в три шага.

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

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

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

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

III. Что это значит для обычных пользователей?

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

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

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

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

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

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

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

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

Тем не менее, механизмы антицензуры не означают, что каждая транзакция сможет сразу же успешно пройти.

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

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

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

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

Заключение

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

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

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

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

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

Это стоит ожидания.