Коротко: FOCIL – проект механизма, в котором выбранные валидаторы формируют списки транзакций для включения в блок Ethereum. Предложение EIP-7805 связывает эти inclusion lists с fork choice: аттестующие валидаторы должны учитывать, выполнил ли производитель блока список. Это ограничивает возможность систематически игнорировать транзакции, но не обещает мгновенное включение и не отменяет компромиссов между цензуроустойчивостью, доступностью сети и сложностью консенсуса.
Тема стала важной на фоне специализации производства блоков. Если право собирать блоки концентрируется у крупных builders, они могут получать экономическую выгоду, фильтруя часть публичного мемпула. Проблема заключается не только в отказе одного участника, но и в том, способен ли протокол предоставить включение, даже если текущий производитель не хочет включать транзакцию. FOCIL пытается распределить это требование между несколькими членами валидаторского комитета и механизмом голосования.
Как работают списки включения
В описании EIP-7805 для каждого слота выбирается комитет участников inclusion list. Каждый член строит собственный список, исходя из локального представления публичного мемпула, и распространяет его по сети. Это не одна центральная очередь и не гарантированный рейтинг транзакций. Списки могут немного различаться, поскольку узлы видят мемпул в разное время. Протокол определяет, какие данные валидны и какие действия следует предпринять при конфликтующих или запоздавших списках.
Производитель следующего блока получает доступные списки и должен включить подходящие транзакции в payload. Если блок строит внешний builder, proposer передаёт ему ограничения или проверяет результат до подписи. Аттестующие валидаторы, в свою очередь, учитывают сохранённые списки и голосуют только за блок, который удовлетворяет условиям включения. Так требование перестаёт быть простой просьбой комитету: от его выполнения зависит fork choice и поддержка блока консенсусом.
Пользователю полезно отличать FOCIL от механизма ускоренного включения. Список задаёт обязательства по определённым транзакциям, но не обещает конкретную комиссию, позицию или время для каждой заявки. Публичный мемпул и приоритеты остаются значимыми, а транзакция может стать недействительной до включения, например, если изменился nonce или баланс. Для общего понимания роли участников при формировании блоков прочитайте разбор разделения proposer и builder.
Почему это связано с цензуроустойчивостью
Обычная транзакция может быть проигнорирована отдельным builder. Но если несколько независимых участников фиксируют её в inclusion lists, а валидаторы не поддерживают блок, который игнорирует корректные обязательные данные, влияние одного производителя снижается. Протокол тем самым превращает включение в проверяемое условие согласия. Это важное различие между репутационным ожиданием и консенсусным правилом.
Идея особенно интересна для транзакций, которые не нравятся крупным посредникам по политическим или коммерческим причинам. Однако механизм не может заставить валидатора получать транзакцию, которой тот не видел, и не защищает от цензуры на уровне интернет-провайдера, RPC, кошелька или приложения. Пользователь может столкнуться с задержкой ещё до того, как заявка попадёт в публичный мемпул. Для реального результата важны разнообразие узлов, прямой доступ к сети и распространение транзакции.
Комитетная схема создаёт собственные вопросы. Чем больше список участников и обязательных транзакций, тем выше потенциальная нагрузка на распространение данных и проверку блока. Если члены комитета выбирают транзакции по разным локальным представлениям мемпула, протоколу нужны правила обработки расхождений. Если часть участников опаздывает, появляются условия liveness: должна ли цепочка ждать, считать список отсутствующим или продолжать с неполной информацией? Эти детали важны не меньше самой идеи принудительного включения.
Компромиссы и границы защиты
В EIP-7805 предусмотрено ограничение размера списка и правила проверки, поскольку неограниченная обязанность включать транзакции могла бы затруднить построение блока. Более плотные списки увеличивают конкуренцию за место и вычислительные ресурсы. Если обязательный элемент не укладывается в допустимые параметры, производитель и аттестаторы должны согласованно определить корректное поведение. В конечном счёте механизм требует подобрать лимиты, которые защищают включение, не делая сеть уязвимой к перегрузке.
Существуют и экономические стимулы. Сборщик списка должен разбираться с spam и недействительными операциями, не превращая участие в чрезмерно затратную обязанность. Внешний builder должен получать достаточно информации для соблюдения ограничений, но не все участники могут иметь одинаковую видимость мемпула. Механизм должен также обрабатывать equivocation – когда участник рассылает несовместимые списки. В черновике EIP обсуждаются роли комитетов, builders, proposers и attesters, и эти правила должны рассматриваться вместе.
FOCIL не равен приватному транзакционному каналу и не гарантирует, что операция окажется в ближайшем блоке. Он не отменяет базовую проверку комиссии, подписи и состояния аккаунта. Пользователю по-прежнему стоит понимать чем предварительное обещание включения отличается от финальности: даже подтверждение участника вне основного консенсуса не тождественно окончательному состоянию цепочки.
Статус предложения и практический вывод
EIP-7805 имеет статус Draft. Это означает, что опубликованная спецификация остаётся предметом разработки и обсуждения; использовать описанные правила как уже действующие на основной сети нельзя. Планирование включения в будущий сетевой апгрейд также не равнозначно активации. До того как механизм станет частью клиента и консенсуса, нужны тестирование, согласование параметров, аудит взаимодействий и обновления клиентских реализаций.
Следить за прогрессом стоит по самому EIP, протокольным репозиториям и официальным материалам Ethereum Foundation. Если спецификация изменится, детали комитетного отбора, сроков и лимитов могут поменяться. В сегодняшнем виде FOCIL лучше понимать как попытку сделать требования включения проверяемыми силами консенсуса. Его ценность будет зависеть от того, удастся ли сочетать распределённый контроль над транзакциями с устойчивым продвижением блоков при задержках, сбоях и конфликтующих взглядах участников.