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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

2. От 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 (справедливые списки включения) и механизмы подотчетности делают цензурные действия крайне дорогими и непостоянными с экономической точки зрения.

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

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

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

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

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

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

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

Третье, что это означает для обычных пользователей?

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

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

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

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

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

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

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

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

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

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

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

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

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

В заключение

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

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

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

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

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

Это стоит ожидать.

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