Protocol Owned Builder V1

[terpayyo]

Authors: @terpayyo, @aleksbez, @mag, @barry

Introduction

In our previous posts we introduced Skip’s Sovereign MEV toolkit, where we outlined how to make blockspace markets fully sovereign. We shared our plans for how we wanted to deliver this to app-chains through a set of Cosmos SDK and ABCI++ primitives that recapture and direct MEV in an on-chain, governable manner. It’s an ambitious vision, as this has not been attempted before.

But now the code has finally caught up.

Presenting: our first, open-source release of Protocol Owned Builder (POB) to Cosmos!

Overview of POB V1

Why use POB?

1. Turn on a new, non-inflationary source of revenue and real-yield for your chain

2. Allow permissionless, healthy MEV recapture for your chain, in <20 mins

3. Define where MEV rewards go, via governance-controlled parameters

4. Control / disable extractive forms of MEV like frontrunning or sandwiching

5. In base version, no external dependencies on any off-chain infrastructure - it’s fully sovereign

Overview

The first release is broken up into four major components:

1. New ABCI++ PrepareProposal and ProcessProposal handlers for a top-of-block auction

2. Custom application-side Mempool to support transaction bundles

3. New x/builder module for required AnteHandlers

4. Custom CheckTx handler that gives applications the ability to perform MEV-aware transaction validation.

How it Works

1. Utilizes ABCI++ to transparently, fairly host top of block auctions by ingressing bids and storing them in each validator’s mempool.

2. Does not rely on any outside participant, infrastructure, auction, or builder. Everything is in-protocol, run by the validators.

3. Searcher’s bid for top of block bundles by submitting a special AuctionTx that includes their bundle of transactions, bid and timeout. Bids are verified through the x/builder’s AnteHandlers.

4. Chains can enforce preferences for how auctions are held and the types of bids are permitted (frontrunning protection, auction fee distribution, etc).

5. Auctions finalize when the current proposer starts to construct the block for the next height. The winning bid will be included at the top of block, verified in consensus to ensure the bid is not invalid, and executed in the subsequent block.

How to Integrate POB

POB is open-source software licensed under MIT. It is free to use, takes < 20 mins to set up, and immediately adds a healthy MEV market to your network with no extra work!

Integrating POB into a new Cosmos chain can be done in under 20 minutes. At a high level, chains must:

1. Be using Cosmos SDK version v0.47.0 or higher (ABCI++).

2. Import and configure the POB mempool into their base app.

3. Import and configure the POB PrepareProposal and ProcessProposal handlers into their base app.

4. Add the x/builder module to their set of SDK modules.

5. Import and configure the custom CheckTx handler into their base app.

6. Configure the desired auction parameters.

7. [Optional] Configure a custom implementation of AuctionFactory, which determines how searchers can bid, and allows applications to use bid information for unique auction flows.

Auction Parameters to Adjust

There are a few different auction configurations (governance controlled) that chains should set up according to their wishes.

1. MaxBundleSize specifies the maximum number of transactions that can be included in a bundle where a bundle is an ordered list of transactions.

   • Basic recommendation: 2

2. ReserveFee specifies the bid floor to participate in the auction. Bids that are lower than the reserve fee are ignored.

   • Basic recommendation: your min fee for the chain

3. MinBidIncrement specifies how much greater each subsequent bid must be in order to be considered. If the bid is lower than the highest current bid + min bid increment, the bid is ignored.

   • Basic recommendation: your min fee for the chain

4. FrontRunningProtection determines whether front-running and sandwich protection is enabled. If this is configured to be true and a bid includes a bundle that sandwiches a user, the bid will be ignored.

   • Basic recommendation: true

How to Bid For Top Of Block Execution

Searchers bid for MEV opportunities by creating and broadcasting a special auction transaction AuctionTx. If the bid wins, the bundle will get atomic execution at the top of the block.

AuctionTx

POB defines an AuctionTx (auction bid transaction) to be a sdk.Tx that includes a single MsgAuctionBid. Searchers submit bundles by broadcasting this bid transaction in the same way they broadcast any other transaction (via any RPC or node).

A few important things to note:

• When a MsgAuctionBid message is included in a transaction, no other sdk.Msg can be present.

• Interfacing with the auction may be different across POB chains.

• Bidding may involve interacting with a dedicated auction house smart contract instead of including this special message type.

• In the future, explore the POB chain directory to make sure the default interface is the correct one for the chain searchers want to submit bundles on.

Default Auction Bid Transaction

MsgAuctionBid

There are four basic things users must specify to participate in an auction:

1. The Transactions they want executed at the top of block.

   • Transactions will be executed in the order they are specified in the message.

   • The transactions included must be the raw bytes the transaction.

2. The Bidder who is bidding for top of block execution.

   • This must be the same account that signs the transaction.

3. The Bid they want to send alongside the bundle.

4. The Timeout which specifies how long the bid is valid for i.e. height.

// MsgAuctionBid defines a request type for sending bids to the x/builder
// module.
type MsgAuctionBid struct {

   // bidder is the address of the account that is submitting a bid to the
   // auction.
   Bidder string `protobuf:"bytes,1,opt,name=bidder,proto3" json:"bidder,omitempty"`

   // bid is the amount of coins that the bidder is bidding to participate in the
   // auction.
   Bid types.Coin `protobuf:"bytes,3,opt,name=bid,proto3" json:"bid"`

   // transactions are the bytes of the transactions that the bidder wants to
   // bundle together.
   Transactions [][]byte `protobuf:"bytes,4,rep,name=transactions,proto3" json:"transactions,omitempty"`
}

V1 Limitations

MEV Stealing & Censorship

Although POB V1 is a fully end-to-end tested solution for in-protocol top of block auctions/execution, it is not fully censorship resistant. Since bids are selected from the current proposer’s mempool, a validator can choose to reject all bids and select their own bid to be included at the top of block.

While bid replacement is possible, POB enforces that if a block includes a bid, the bid and it’s bundle of transactions must be the first transaction(s) in the block - meaning a validator cannot reorder a block and misplace bids.

Note that this was always a problem with Skip’s original design, but we never saw this problem play out in practice. Validators are, for the vast, vast majority, honest.

Solution: this is cryptographically solved in V2 via vote extensions, but until then, it is fairly easy for us to monitor validator behaviour and understand which, if any, validators are actively censoring or replacing transactions.

MEV Privacy

In POB, searchers submit their MEV bundles in the public mempool. Naturally, this can lead to search-and-replace strategies where searchers will engage in a public auction for opportunities. We believe the short-term strategies with POB will evolve around finding direct routes to submit to validators (so that bundles are not exposed publicly), and, to some extent, a preference for submitting bundles as late as possible.

Solution: this is cryptographically solved in V3 via encryption. These problems are notoriously difficult to solve in-protocol (they are solved in our original off-chain builder). However, they can be resolved by implementing threshold encrypted for at least some part of the mempool, support for which is coming in V3.

POB Future Versions

POB V2

POB V2 will be implemented using vote extensions which builds on top of the current implementation but is censorship resistant as bids will be collected across all validators’ mempools.

Each validator will select the top bid from their mempool and add it to their vote on the current proposal. This ensures that the next proposer will have to include at least 2/3+ of the vote extensions, and therefore the top bids associated with them.

In V2, in order for the top bid to be censored and not included, over 1/3 of the validators will have to censor the transaction, which is the same security properties as Tendermint itself for a liveness failure.

When auctions are held in the subsequent block, the auction will only utilize the signed vote extensions from the previous block. When block proposals are verified, each validator will verify the auction was run correctly on the same set of vote extensions.

If there are discrepancies on what the winning bid should have been between when the block was proposed and verified, the entire proposal will be rejected.

Discussions on a redesign of vote extensions are on-going and will facilitate an implementation where POB V2 can prevent MEV-stealing and provide censorship resistance guarantees.

POB V3

Although V2 is censorship resistant, it is still susceptible to MEV stealing as validator’s can similarly inject their own signed vote extension which would outbid other vote extensions. Additionally, searchers can still find competing bundles in the mempool and copy them.

V3 fixes this by having either full or partial-mempool threshold encryption. We plan to work with Ferveo and Fairblock to implement and support this. This will enable private bid submission for next-block bundles.