/3
Shared Sequencing Mechanics and Shared Sequencing Network.

Какие компоненты нам нужны для достижения Shared Sequencer?
● JSON-RPC: Занимается TXs постингом в ноды и работает как mempool перед исполнением TX.
● Block/Batch Builder: Занимается обработкой TXs из mempool/queue и создания блоков с ними + может включать в себя доп. сжатия данных для снижения размера финального блока (less data on L1 - less you pay).
Block-builder должен быть сделан отдельно от proposer, как это и описано в PBS. Такое разделение приводит к fair operation которое избегает MEV, а также оптимизирует всю структуру при этом улучшая censorship resistance.
● P2P Layer: Layer отвечающий за получение TXs от sequencers на других rollup-ах
● Leader Rotation Algorithm (example): Ссылка на Solana не просто так, ведь, если есть ротационный механизм, значит и consensus не нужен, так как single leader всегда будет отвечать за sequencing. Вместе с этим идет наличие цензуры и MEV-а. Однако это кратно повышает скорость сети.
● Consensus Algorithm: Есть Tendermint и HotStuff2 (потенциально основанные на лидерах для улучшения латентности) могут быть реализованы для обеспечения того, чтобы участвующие узлы были в согласии с предложенным порядком операций. В качестве альтернативы можно использовать алгоритм консенсуса для определения лидера. Может быть использован как выбиралка leader-a или чтобы просто node-ы приходили к консенсусу ордеринга TXs.
● RPC Client: часть помогающая block/batcher builder-у постить в DA layer или consensus layer, и которая также проверяет, что все было правильно на этом DA.

Пикча ниже объединяет все эти компоненты и очень понятно показывает как работает shared sequencer network. Разбираем:
● TXs передаются в shared mempool через JSON-RPC,
● Далее выстраиваются по block-building algorithm (PBS),
● После обращается к proposer-ам (SSS)
● Как только все передано на DA по условиям consensus algorith или leader rotation оно и передается на rollup node-ы для soft confirmation. Потом rollup node-ы получают hard finality от DA после того как блоки были провалидированы L1 consensus-ом.

● Напоминалочка: Soft Commitment - Чтобы юзер не ждал очень долго финализацию на L2, rollup node-ы просто получаю информацию напрямую от sequecer-а (data тоже отсылается на DA, смотрим пикчу еще раз). То есть этот block сделан, но финализирован на L1. Поэтому это и называется soft finality guarantee.

В чем смысл Shared Sequencer?
Подводим итоги. В будущем, эта модель поможет нам обойти множество проблем и ограничений, и благодаря таким решениям как Espresso (на лендосе в конце красивая анимка объясняет многое) мы получим:
● A modular plug & play solution: Они более оптимизированные и позволяют подключиться к сущестующим другим решениям почти мгновенно и без потерь. То есть по факту это middleware technology сервис, которую можно просто подключить и не разрабатывать с 0 целый сервис. Decentralization as a Service:)
● Proposer-builder Separaration - Исключение MEV ботов децентрализованным способом.
● Agnostic Ordering - Уход от нынешней системы First Come First Serve к MEV-optimized.
● Cross-Rollup Building - эту Sequencer Network можно понимать, и сама по себе она может быть определена как rollup-agnostic коллекция sequencers специально созданных для поддержки множества разных подключенных rollup-ов.
● Execution and Outcomes with Pooled security and Enhanced decentralization: - agnostic block-builders будут гарантировать user-ам, что их транзакция не будет зацензурирована, и будет исполнена на любом из подключенных rollup-ов.
Тем не менее есть проблемы с Optimistic rollups. Поскольку, несмотря что Soft commitment со стороны sequencer могут придти, нет никаких гарантий что придут Hard потому что Optimistic не являются asynchronously composable.