How Skip Select Works

Introduction Video

The design goals of MEV-Tendermint are to allow & preserve:

🔒 Privacy for users submitting bundles
🎁 Atomicity for bundles of transactions
🐎 Priority guaranteed for highest paying bundles
🏛 No new security assumptions for validators and nodes running MEV-Tendermint, including removing the need for ingress or egress for locked-down validators. No new network assumptions are made
🔄 On-chain transaction submission via gossip, no need for off-chain submission like HTTP endpoints, endpoint querying, etc
💨 Impossible to slow down block time, i.e. no part of mev-tendermint introduces consensus delays

🏦 Auction

Prior to the creation of the first proposal for height n+1 , the Skip Sentinel infrastructure selects an auction-winning bundle (or bundles) to include at the top of block n+1
The auction-winning bundle is defined as the bundle that pays the highest bid to the Skip auction address, doesn’t include any reverting transactions, and respects protection preferences of the block proposer (currently this only includes frontrunning/sandwich protection)
The sentinel ensures it’s simulations of the bundle are accurate by simulating it against the version of state where it will actually run (by optimistically applying the proposals produced for height n )

🗣️ Gossip

Before the first proposal for height n+1 is created, the Skip sentinel gossips the auction-winning bundle(s) to whichever nodes belonging to that proposer it can access (e.g. sentries if the validator is using a sentry configuration, or validator replicas if it’s using horcrux)
The nodes that receive the winning bundle(s) gossip it to the other nodes belonging to that proposer to ensure the bundle(s) reach the validator
This selective gossiping is powered by new config options (personal_peer_ids) and takes place over a new channel, but it is secured using the same authentication handshake Tendermint uses to secure all other forms of p2p communication

🏒 Handling Transactions

Ordinary transactions received over traditional gossip are handled exactly the same way they are today in the mempool
Transactions received as part of bundles sent from the Skip sentinel are handled and stored in a new data structure called the sidecar
These transactions have additional metadata about the bundle in which they should be included (e.g. bundleOrder, bundleSize). The sidecar uses this data to reconstruct bundles as it receives individual transactions over gossip

[reinforce that we have a new transaction data structure]

🚜 Reaping

On reap, mev-tendermint first checks whether there are any fully-constructed bundles in the sidecar then reaps these first.
Next, it reaps from the ordinary mempool, with some additional checks to ensure that transactions reaped from the sidecar don’t get reaped again if they are also present in the standard mempool

[reinforce reaping of bundle goes to top if available]

#1 The Sidecar

A separate, private mempool that respects bundles of transactions
- Relevant files: mempool/clist_sidecar.go
Has selective gossiping, meaning it only gossips:
- Over its own SidecarChannel
- Only to peers that are added as its personal_peers
  - In practice, personal_peers for each node are set to be:
    - Sentry node → Skip sentinel & the other nodes you’re running that the sentry is aware of (e.g. validator or a layer of sentries closer to the validator)
    - Validator node → only its sentries

#2 The Mempool Reactor

#3 Selective Reaping

The regular mempool now considers sidecarTxs (i.e. bundles) in addition to regular txs, and orders the former before the latter
- Relevant files: mempool/clist_mempool.go, state/execution.go