Inclusion lists в Ethereum: как списки включения помогают бороться с цензурой транзакций

Контекст: MEV, PBS и цензура

После перехода Ethereum на Proof-of-Stake и массового внедрения MEV-инфраструктуры (searcher’ы, билдеры, релеев) возникла проблема:

• блок строит не сам валидатор-пропозер, а внешний билдер, оптимизирующий доход (MEV);
• билдер и релей могут цензурировать транзакции:
  • не включать операции определённых адресов;
  • игнорировать неудобные для них или для регуляторов tx;
• у обычного пользователя нет гарантий, что его транзакция когда-либо пройдёт, если она «невыгодна» билдеру или кому-то ещё.

PBS и особенно ePBS пытаются формализовать роль билдера и пропозера в протоколе. Inclusion lists добавляют к этому второй слой: минимальная гарантированная доступность для транзакций, которые “не устраивают” билдеров.

Что такое inclusion list простыми словами

Inclusion list — это:

• список транзакций, который блок-пропозер может опубликовать заранее (например, в одном из предыдущих слотов/эпох);
• билдер, конструируя блок для этого пропозера, обязан включить все транзакции из списка, если они всё ещё валидны (подписи, nonce, баланс, лимит газа);
• порядок остальных транзакций, MEV-стратегии и аукцион за место в блоке остаются на усмотрение билдера.

Ключевая цель:

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

Как списки включения должны работать

Конкретная реализация ещё обсуждается, но общая схема выглядит так:

• Пользователь отправляет транзакцию в сеть как обычно.
• Если транзакция долго не включается (считанные блоки/слоты), она может:
  • быть замечена пропозером;
  • или “подписана” самим пользователем в отдельном канале (подробности зависят от дизайна).
• Пропозер формирует inclusion list — набор tx, которые:
  • кажутся «цензурируемыми» (давно в мемпуле, мало попыток включения);
  • или попадают под определённые критерии (например, “каждый tx имеет право быть включённым за N слотов”).
• В одном из блоков/слотов пропозер публикует inclusion list:
  • в консенсусном блоке;
  • или в специальной структуре, на которую опираются будущие билдера и пропозеры.
• Следующие билдеры обязаны включить эти транзакции, если они:
  • ещё валидны;
  • не были включены в предыдущие блоки;
  • не конфликтуют друг с другом (в противном случае действуют дополнительные правила).

Таким образом, inclusion lists превращают «мягкие» ожидания в формальное обязательство протокола: если транзакция попала в такой список, у неё появляется верхняя граница по времени до включения (при условии валидности).

Какие задачи решают inclusion lists

Основные цели механизма:

• Защита от долговременной цензуры.

Даже если крупные билдеры не хотят включать конкретные транзакции (регуляторные или экономические причины), inclusion lists на уровне протокола заставляют их это сделать.

• Сохранение роли пропозера.

В модели PBS пропозер частично теряет контроль над содержимым блока. Inclusion lists возвращают ему минимальный рычаг влияния: «этот набор tx вы обязаны включить».

• Усиление гарантий для пользователей.

Возникает понятный ментальный контракт:

• если твоя транзакция валидна;
• и она попала в inclusion list;
• то через ограниченное число слотов/эпох она будет включена.

• Повышение устойчивости сети к внешнему давлению.

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

Ограничения и открытые вопросы

При всех плюсах inclusion lists поднимают новые вопросы проектирования:

• Как формировать списки и ограничивать размер?

Если пропозеры смогут добавлять неограниченное число транзакций, это:

• создаст угрозу DoS для билдера;
• увеличит сложность и размер блоков;
• сломает экономику газа.

Поэтому обсуждаются:

• лимиты по размеру списка;
• критерии отбора (старые транзакции, приоритетные типы).

• Кто решает, что транзакция “цензурируется”?

Механизм должен быть:

• достаточно простым;
• максимально объективным (основанным на времени пребывания в мемпуле, количестве «пропущенных» слотов и т.п.),

чтобы исключить злоупотребления.

• Взаимодействие с MEV и аукционами билдеров.

Inclusion lists отнимают у билдера часть свободы:

• он обязан включить определённые tx, даже если они «портят» его MEV-стратегию;
• нужно аккуратно проектировать компенсации и правила аукциона.

• Риски griefing-атак.

Недобросовестные участники могут пытаться использовать inclusion lists:

• для создания конфликтующих транзакций;
• для перегрузки памяти и блок-спейса;

поэтому требуются защиты от спама и конфликтов.

Inclusion lists и ePBS в дорожной карте Ethereum

Inclusion lists чаще всего обсуждаются в связке с:

• ePBS — вшитым в протокол разделением пропозера и билдера;
• будущими апгрейдами Ethereum (см. дорожную карту апгрейдов);
• изменениями в архитектуре EL/CL (см. Архитектура Ethereum — как устроена сеть под капотом).

На момент написания статьи inclusion lists остаются исследовательской концепцией:

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

Практическое значение для пользователей и операторов

Для обычного пользователя:

• inclusion lists — это скорее фоновый механизм защиты:
  • в нормальные периоды сеть работает как сейчас;
  • при попытках цензуры минимальные гарантии включения усиливаются.

Для валидаторов и операторов инфраструктуры:

• inclusion lists потребуют:
  • обновления клиентов;
  • поддержки новых типов сообщений/структур;
  • учёта новых правил в сетевой и экономической логике.

Для разработчиков протоколов и DeFi:

• важно следить за развитием PBS/ePBS и inclusion lists,
• особенно если протоколы чувствительны к цензуре (мультичейн-мосты, приватные tx, протоколы финансовой доступности и т.п.).

См. также

• PBS (Proposer-Builder Separation)
• ePBS (enshrined PBS)
• MEV — maximal extractable value
• Архитектура Ethereum
• Дорожная карта апгрейдов Ethereum
• Danksharding и EIP-4844