LIL-BOOST

https://github.com/eserilev/il-boost

Local Inclusion List Boost aka LIL-Boost

All my homies outsource block production to censorship resistant MEV marketplaces
-Big Sean (real)

LIL-Boost is a sidecar that runs alongside an Ethereum node. It leverages Commit-Boost to identify set constraints on builder relays and verify the constraints inclusion.

What is Commit-Boost

https://github.com/Commit-Boost

Commit-Boost is an open-source public good that is fully compatible with MEV-Boost, but acts as a light-weight validator platform to safely make commitments. Specifically, Commit-Boost is a new Ethereum validator sidecar focused on standardizing the last mile of communication between validators and third-party protocols. It's being developed in Rust from scratch, and has been designed with safety and modularity at its core, with the goal of not limiting the market downstream including stakeholders, flows, proposer commitments, enforcement mechanisms, etc.

LIL-Boost Features

The LIL-Boost sidecar has the following features:

Signer module

Leverages the built-in Commit-Boost Signer Module to sign data using a connected validators keys

Check this link out for more details:
https://commit-boost.github.io/commit-boost-client/developing/commit-module#requesting-signatures

Using the signer module, the LIL-Boost sidecar has the ability to extend block proposer functionality without making changes to the core protocol

Extended MEV Boost server

On start up, an extended MEV-Boost server is launched. From the BN's perspective, it interacts with MEV-Boost as it normally does during the block proposal flow. From the sidecars perspective the following endpoints are added or extended

• set_constraints: this endpoint is added to allow the sidecar to express constraint requirements to the builder relay before calling get_header
• get_header: this endpoint is extended to implement get_header_with_proof. This allows for the sidecar to verify, via a merkle proof, that the transactions in set_constraints are included in the builders payload before the proposer commits to it.

More documentation can be found here: https://right-knife-e11.notion.site/Aligning-Preconfirmation-APIs-db7907d9e66e41718e6bc2cff19604e4

Lookahead service

The lookahead service, on startup, subscribes to the local BN. At each epoch it fetches any upcoming block proposal duties for the validators listed in the LIL-Boost config. If it finds a block proposer duty at slot N:

• At slot N-1, builds a list of censored transactions from the local mempool
• Sumits the inclusion list via set_constraints

Identifying censored transactions

LIL-Boost, at startup, subscribes to the local EL's mempool. To build a list of censored transactions for Slot N, it checks for transactions in the mempool that pay the base fee and have a non-zero tip. If those checks pass and there is enough gas remaining in block N-1 to include a subset of those transactions, we assume that subset to be censored.

A quick example

To tie it all together heres a quick example:

Assume we have a validator with block proposal duties at slot N.

LIL-Boost identifies that our validator has block proposal duties at Slot N. At some time during Slot N-1 it builds a list of censored transactions from the local mempool. It then signs (via the commit-boost signer module) and sends the list to the builder relay via the set_constraints endpoint

At Slot N, the validator begins its block proposal flow. When it calls get_header to LIL-Boost's extended MEV-Boost server, the server makes a call to get_header_with_proof. This returns a block header from the builder relay w/ a merkle proof. The merkle proof is used to verify incluson of censored transactions that were forwarded via set_constraints. If the proof is succesfully verified, the block header is forwarded to the validator. The validator then continues on with its normal proposal flow.