Перед тем как вы погрузитесь в изучение статьи, обратите внимание на тот факт что всё упомянутое в ней не является финансовой рекомендацией для принятие более взвешенного решения просьба провести свое собственное исследование.
Кратко рассмотрим основные механизмы координации для Preconf:
Inclusion Lists (IL)
Inclusion Lists позволяют предлагающим валидаторам принудительно включать определенные транзакции в текущий или последующий блок. Благодаря IL, предлагающие валидаторы могут передавать на аутсорсинг создание блока, при этом обеспечивая включение определенных транзакций.
Execution Tickets (ET)
В Execution Tickets валидаторы выбираются случайным образом для двух основных задач посредством лотереи на основе суммы застейканного ETH. ET предлагается как решение для разделения двух обязанностей, защищая валидаторов от централизующих сил и позволяя большему количеству валидаторов-одиночек участвовать в качестве валидаторов специальных блоков, тем самым стимулируя децентрализацию процесса. Однако такой подход всё же создает некие риски централизации.
Mev-commit by Primev
Mev-commit — это P2P-сеть, разработанная для того, чтобы все посредники MEV могли эффективно и без доверия координировать свои действия, и где обязательства по выполнению транзакций Ethereum могут быть записаны вместе с логикой вознаграждения/сокращения поставщиков. Концепция позволяет участникам торгов (таким, как Searchers, Solvers, Telegram Bots, AA Bundlers, Wallets, Transaction Aggregators и конечным пользователям) указывать свои предпочтения по выполнению транзакций и получать обязательства от поставщиков выполнения (таких, как Block Builders, Validators).
Большинство Rollups управляют упорядочивание и выполнением, полагаясь на Ethereum L1 для доступности данных и расчетов. В настоящее время Rollups используют централизованные секвенсоры для сортировки транзакций. Затем валидатор/prover генерирует конечное состояние на основе этих транзакций и размещает его в мостовом контракте L1.
Централизованные секвенсоры могут предоставлять пользователям обязательства о включении транзакций до проверки на L1. Пользователи не могут принудительно выполнять эти обязательства (через программный slashing или арбитраж), но они могут доверять обязательствам секвенсора, поскольку именно он отвечают за сбор и сортировку транзакций. Это обязательство можно назвать Preconfirmation. Однако, если валидатор/prover не публикует конечное состояние на L1, то это доверие может быть скомпрометировано.
Централизованные секвенсоры предлагают Preconfirmation, но они также создают риски: цензуры, отдельных точек отказа и извлечения MEV. Децентрализация секвенсоров является сложной задачей, особенно в поддержке Preconfirmation для пользователей.
Чтобы использовать существующую сеть L1 для создания и секвенирования блоков L2, все тот же Джастин Дрейк предложил использовать концепцию Based Rollups в марте 2023 года, которая убирала необходимость использования централизованных секвенсоров.
Узнать о слабых местах централизованных секвенсоров вы можете по ссылке на нашу статью.
Джастин Дрейк дал определению Based Rollup:
«Rollup называется Based или L1-sequenced, когда его процесс секвенирования транзакций управляется L1. Более конкретно, Based Rollup — это то, где следующий L1 proposer, предлагающий следующий блок L1, может, в сотрудничестве с Searchers и Builders L1, без разрешения включать следующий блок Rollup, как часть следующего блока L1».
Для уточнения:
По сути, Builder L1 или Searcher L1 может играть роль Builder блоков L2, выбирая транзакции из mempool L2, создавая блок L2 и включая его в bundle L1. Поскольку большая часть MEV поступает к валидаторам L1, предлагающие L1 заинтересованы в том, чтобы включать блоки Rollup в L1.
Тем самым мы получаем:
Как мы поняли, для внедрения Preconfirmations в существующие Rollups потребуется значительное изменение механизмов работы, которые были названы Based Preconfirmations. Необходим механизм координации между всеми посредниками (пользователями, ботами, Searchers, Builders, ретрансляторами и валидаторами), чтобы обеспечить надежную и не требующую доверия коммуникацию.
Подумаем, как потенциально это может выглядеть:
Так называемый провайдер должен иметь возможность включать транзакции, для которых было дано предварительное подтверждение. Подход зависит от того, кто является провайдером. Если валидаторы предлагают Preconfirmation, им нужен механизм для включения транзакций в блок. Это можно сделать, самостоятельно построив блок, а не получив извне самый прибыльный блок.
При предоставлении Preconfirmation со стороны Block Builders возможно реализовать аукцион. Builders могут обеспечить выполнение обязательств, если выиграют ставку на аукционе mev-boost. Builders могут гарантировать выполнение, но они не могут быть уверены в победе в аукционе.
Если участники торгов получают Preconfirmation от достаточного количества Builders, они могут быть достаточно уверены, что их условие будет выполнено. В настоящее время участники торгов, получающие Preconfirmation от трех лучших Builders, имеют более 90% вероятности выполнения.