Если вы пользуетесь Ethereum и L2 (Arbitrum, Optimism, Base и др.), вы редко думаете о том, как именно формируется блок. Но именно там живут ответы на “вечные” вопросы:

• Почему мою транзакцию иногда “не берут” даже с нормальной комиссией?
• Почему MEV (сэндвичи/арбитраж) так сложно победить?
• Насколько Ethereum устойчив к цензуре транзакций?
• Что будет с L2, когда Ethereum всё сильнее становится “слоем расчётов и данных”?

Три термина, которые чаще всего всплывают в обсуждениях будущего Ethereum, — это PBS, ePBS и inclusion lists. На первый взгляд звучит как “внутренняя кухня”, но на практике это про качество включения транзакций, устойчивость к цензуре и то, как справедливо распределяется MEV — а значит, влияет и на пользователей, и на L2.

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

Для справки по терминам в нашей вики: PBS, ePBS, inclusion lists.

Почему эти темы стали ключевыми именно сейчас

У Ethereum постепенно фиксируется “целевой образ”: L1 — максимально надёжный слой расчётов (settlement) и данных (data), а массовая активность уходит в L2. На этом фоне важны две вещи:

• Кто и как решает, какие транзакции попадут в блок? Это вопрос цензуроустойчивости и справедливого доступа.
• Как устроен рынок “порядка транзакций” (MEV)? Потому что порядок — это деньги, а деньги порождают централизацию.

Именно поэтому PBS/ePBS/inclusion lists — это не “про скорость” в лоб. Это про то, чтобы блоки формировались качественно, предсказуемо и с меньшим влиянием закрытых центров силы — при сохранении экономики валидаторов и безопасности сети.

Как формируется блок в Ethereum: роли и мотивации

В каждый слот (короткий временной интервал) сеть выбирает пропозера — валидатора, который предложит блок. У пропозера есть две “естественные” мотивации:

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

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

PBS: что это и какую проблему решает

PBS (Proposer-Builder Separation) — это дизайн, в котором роль “предложить блок” (proposer) и роль “собрать блок” (builder) разделяются. По сути, появляется более чёткое разделение труда:

• Builder собирает блок: выбирает транзакции, упорядочивает их, оптимизирует под комиссии и MEV.
• Proposer выбирает “лучшее предложение блока” (обычно по выплате) и публикует его в сеть.

Что PBS пытается улучшить

Почему пользователю это вообще важно

Потому что “кто собирает блок” определяет:

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

В реальной жизни многие пользователи уже слышали про “MEV-инфраструктуру” вроде MEV-Boost (для контекста — не обязательно углубляться), но ключевой смысл PBS именно в том, чтобы сделать этот слой более формальным и менее опасным для устойчивости сети.

ePBS: чем отличается от “обычного PBS”

ePBS (enshrined PBS) — это идея “встроить PBS на уровне протокола”. То есть сделать так, чтобы разделение proposer/builder и правила их взаимодействия поддерживались самим Ethereum (консенсусом), а не внешними соглашениями и инфраструктурой.

Почему это важно? Потому что “PBS как социально-технический слой” может зависеть от:

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

ePBS стремится уменьшить эту зависимость: если правила “как выбирается блок builder’а” встроены в протокол, у сети больше формальных гарантий, а у пользователей — больше уверенности, что включение транзакций не определяется “частной инфраструктурой”.

Inclusion lists: что это и зачем нужно

Inclusion lists — это механизм, который усиливает цензуроустойчивость: он позволяет (в той или иной форме) задать список транзакций, которые должны быть включены в блок при соблюдении базовых условий (валидность, достаточная комиссия и т.д.).

Зачем это нужно, если “рынок сам всё отрегулирует”? Потому что в мире MEV и централизованной инфраструктуры может возникать ситуация, когда:

• часть транзакций “невыгодна” builder’ам;
• часть транзакций сознательно игнорируется (по разным причинам, включая внешнее давление);
• пользователь платит, но всё равно получает нестабильное включение.

Inclusion lists добавляют “страховочный слой”: даже если builder не хочет включать вашу транзакцию, у протокола/пропозера появляется механизм повысить вероятность включения “корректных” транзакций.

Почему inclusion lists обсуждают вместе с PBS/ePBS

Потому что PBS усиливает роль builders (они лучше умеют собирать блоки), а inclusion lists — способ не дать этому рынку превратиться в “закрытый клуб”, где можно выборочно игнорировать пользователей.

Что меняется для пользователей: комиссии, “точно дошло”, приватность

Давайте честно: средний пользователь хочет три вещи — быстро, предсказуемо, без сюрпризов по цене. PBS/ePBS/inclusion lists не обещают “всегда дешевле”, но могут улучшить важные свойства пользовательского опыта.

1) Более предсказуемое включение транзакций

Когда рынок сборки блоков формализован и конкурирует за “лучший блок”, транзакции с адекватной комиссией получают более стабильные шансы на включение. Inclusion lists дополнительно создают механизм против “выборочного игнора”.

2) Меньше “странных задержек” без объяснений

Часть задержек — это просто рыночная динамика (перегрузка, пик активности). Но когда появляется слой выборочного включения, пользователи ощущают “рандом”: одинаковая комиссия, но разный результат. Inclusion lists нацелены на снижение этого эффекта.

3) MEV и качество исполнения в DeFi

PBS напрямую не “отключает MEV”. Но он влияет на то, как MEV извлекается и кто контролирует инфраструктуру. В идеале это уменьшает стимулы к “тёмным” практикам и снижает системные риски централизации вокруг отдельных точек.

4) Цензуроустойчивость как пользовательское свойство

Для пользователя цензуроустойчивость — это не политический термин, а простая вещь: “если транзакция корректна и я плачу комиссию, её нельзя бесконечно игнорировать”. Inclusion lists как раз про это.

5) Что с комиссиями?

Комиссия в Ethereum — это рынок. PBS/ePBS не обязаны “снижать базовую цену газа”. Но они могут улучшить эффективность включения и уменьшить поводы для “искусственных” искажений на уровне порядка транзакций. Для пользователя это чаще выражается не в “вдвое дешевле”, а в “меньше неожиданных потерь и меньше необходимости переплачивать ради уверенности”.

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

L2 зависят от L1 в двух ключевых точках: публикация данных/пакетов и финальная безопасность (споры/доказательства/коммит состояния). Поэтому правила включения транзакций в L1 важны не только “людям со свапами”, но и инфраструктуре L2.

1) Надёжность публикации L2-данных в L1

Если транзакции L2-секвенсора (публикация батчей/данных) начинают зависеть от “неформальных” правил включения, L2 может испытывать нестабильность: задержки, скачки стоимости, ухудшение UX. Более формализованный рынок сборки блоков + механизмы против цензуры помогают сделать публикацию более предсказуемой.

2) Снижение системного риска “узких горлышек” инфраструктуры

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

3) Цензуроустойчивость для L2-пользователей

Даже если вы живёте в L2, “последняя инстанция” — L1. Если L1 допускает длительную выборочную цензуру, это может влиять на:

• возможность “доказать” состояние или оспорить его (в моделях со спорами);
• возможность вывести средства обратно в L1 в ожидаемые сроки;
• устойчивость к нештатным ситуациям в случае проблем у секвенсора.

Inclusion lists в широком смысле — это попытка укрепить базовую гарантию: корректные транзакции и важные сообщения (включая системные) не должны “пропадать” из включения на длительное время.

Компромиссы и побочные эффекты: что может стать сложнее

Любое усиление гарантий в блокчейне — это компромисс. PBS/ePBS/inclusion lists могут добавлять:

• сложность протокола (больше правил, больше поверхностей для багов);
• сложность реализации (инфраструктура, совместимость, переходные решения);
• новые экономические стимулы (рынок builders, конкуренция, возможные новые формы “гонок”).

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

Практика: как действовать пользователю уже сегодня

Даже если PBS/ePBS/inclusion lists — часть более долгой дорожной карты, пользователю полезно выстроить “правильные привычки” уже сейчас, особенно если вы активно пользуетесь DeFi.

• 1) Разделяйте “комиссию” и “качество исполнения”. Иногда вы теряете не на gas, а на порядке транзакций и MEV.
• 2) Не ставьте широкий slippage “на всякий случай”. Это главный триггер для потерь в DeFi.
• 3) Для важных транзакций выбирайте предсказуемость. Если действие критичное (вывод/погашение/ликвидации), лучше избегать “тонких” условий.
• 4) Для L2 помните про зависимость от L1. В стресс-сценариях важнее всего способность L2 корректно публиковать данные и финализировать действия на L1.
• 5) Если вас волнует цензура — следите за улучшениями протокола. Именно под эту проблему и обсуждаются inclusion lists.

FAQ

Полезные ссылки

• PBS: разбор термина и логики
• ePBS: что значит “enshrined”
• Inclusion lists: зачем и какие варианты обсуждаются
• MEV: базовые понятия
• MEV-Boost: контекст инфраструктуры сборки блоков