# B52

[Introduction](#Introduction)
[Background and Rational](#Background-and-Rational)
[How It Works](#How-it-works)

## Introduction

This proposals goal is to enshrine MEV into the protocol in order to maximise the value capture of the network and to tackle the centralising forces that arise from PBS head on.

Enshrining an MEV auction, forces builders to take part in a first price auction for profitable blocks.

***It was previously stated that this proposal enshrined PBS but that is not true. This proposal explicitly removes the need for the proposer, by allowing builders to directly submit blocks.***

***Instead this can be thought of as builder prover seperation***

## Background and Rational

### What is PBS on Ethereum?

Proposer builder seperation, refers to the fact that the same entity that is eligible to propose the next block, is not the same entity that builds the block.

On Ethereum, PBS is currently implemented via flashbots, with discussions about enshrining in the [protocol](https://ethresear.ch/t/why-enshrine-proposer-builder-separation-a-viable-path-to-epbs/15710).

**Responsibilities of a proposer**

1. Putting a block on chain.
2. Ensuring the rules of the system are followed
3. Liveness.
4. Censorship resistance.
5. Accountable for the block being correct.

**Responsibilities of a builder**

1. Transaction ordering.
2. Executing all transactions.
3. Building the block

### Why doesn't B52 need a proposer?

On Ethereum, the block proposer can lie about the a block's state updates. Ethereum's proof of stake consensus and validators checks their work to ensure this does not happen.

For a ZK based L2, the proposer can not lie. Each block will only become the head of the chain when accompanied with a valid proof of correctness.

Therefore ZK based L2's do not need a traditional block proposing entity as they do not have consensus on the correct record of events.

The block builder can freely put forward the most profitable block.

**Note**

*A decentralised proposing mechanism does contribute to the liveness, censorship resistance, and resilience properties of a network. If the proposer is removed, these properties must not be neglected*

B52's design goals are to use a based rollup style system that allows block builders to submit blocks and the most profitable block to always win, assuming it doesn't censor, or break any other rules of the protocol.

Flashbots has done some research on the negative effects of combining the proposer and builder entity. This applies when the protocol defines a proposer, who can't produce the best block. In B52, the builder can produce the best block via searchers and private auctions for inclusion rights in that block.

## How it works?

1. Block production has two actors:
* Block builders -- anybody
* Provers -- who must register on L1 with a public key and stake.
3. The block proposal process is administered by an L1 smart contract.
4. Anybody can be a builder and take part in the block proposal process.
5. The smart contract splits up block production into 6 sequential phases.
1. Block Proposal Phase
2. Voting + Commitment Phase
3. Block Reveal Phase
4. Proof Acceptance + Ranking Phase
5. State Advancement + Rewards Phase
6. The smart contract decides which block is the head of the chain via a ranking function with two weights.
1. The amount of native token the builder is willing to burn
2. The number of staker's who voted on the block via a proving commitment

## **Detailed breakdown of the phases**

### Block Proposal Phase

The `BLOCK_PROPOSAL_PHASE` lasts `N` seconds and starts at the end of the last `BLOCK_PROPOSAL_PHASE`, + an offset `T`.

The offset `T` can be zero if pre-confirmations are desired or the length of the `PROOF_ACCEPTANCE_PHASE` if not.

Block builders, pick transactions from the public P2P pool and their private pool. They assemble transactions into a block with the goal of making the most profitable block for them.

Once complete, the proposer broadcasts the block header to the **L2 P2P network** so stakers can see it.

The block header consists of:

:::info
**Block Commitment Hash**: The hash of the contents of the block and potentially a random commitment for additional privacy on ordering e.g `hash(hash(tx1, tx2, tx3, tx4),secret)`
**Burn**: The amount of native token that will be burnt by the builder if the block becomes the head of the chain.
**Prover Fee**: The amount that the prover network will receive if the block becomes canonical
**Built From**: The block the builder will build from. (*Only required when `T` is shorter than the `PROOF_ACCEPTANCE_PHASE`*)
:::

Multiple proposers will submit block headers to the L2 P2P network as shown below.


### Block Voting and Commitment Phase

Stakers vote on which block they will help contribute to making as they see block headers appear on the L2 network. They will vote for the block that pays them the most and has the highest chance of becoming the head of the chain. Their vote includes a commitment to build part of the block should it win the auction.

An Aztec rollup proof consists of a binary tree as follows. The proof index, denotes which part of the tree the staker will build. The staker will likely vote on multiple parts of the tree.


A block vote is submitted to the L2 P2P network and consists of:

:::info
**Block Commitment Hash**: The hash of the block they are voting on.
**Proof Index**: The height and index of the proof they commit to building
***VRF Output**: The stakers VRF output for the block. In this case the attacks can be prevented by multiplying the vote by each VRF output value as the votes are summed.*
**Signature**: A signature over the block vote from the stakers private key.
:::

The vote is broadcast to the L2 P2P network.

#### Block Commitments

The block builder collects votes from the L2 p2p network and assembles them into a block transcript. The block transcript defines which staker will produce which part of the proof binary tree.

The builder is incentivised to create a transcript that maximises the total number of unique votes on their block based on the scoring function the smart contract will apply.

`Score = PROVER_VOTE (x)^3 * BURN_BID(z) ^ 2`


The builder then submits their block commitment hash to L1, before the end of the `BLOCK_PROPOSAL_WINDOW`. Fixing the maximum score for the block and the ordering of transactions.

### Block Reveal Phase

Once the `BLOCK_PROPOSAL_WINDOW` has ended, the block with the highest theoretical score will be known. This block can be built when the builder reveals:

1. The pre-image to the block contents hash, detail the ordering of transactions, and if the transactions come from a private tx pool, the proofs that accompany those transactions.
4. The pre-image to the transcript hash, detailing which stakers are involved in prooving.

This data can be broadcast on L2 as the block proposer needs specific stakers to build the proof in order to win due to the VRF weighting of prover votes.

### Proof Acceptance + Ranking Phase

Once the block data is revealed, the proving network can safely get to work building the winning blocks.

The smart contract will incentivise an uncle block for liveness guarantees.

The proposer will submit the final block and proof to L1, within the `PROOF_ACCEPTANCE_WINDOW`. If the block proof is valid, the following will occur:

1. The zk-snark block proof, proves correctness of the proposed state transition.
2. The zk-snark proof, proves the score of the block is correct based on the transcript the builder commited to, and the entities that made up proofs.
3. The block will be ranked based on it's score and marked as valid but not canonical on the rollup contract.

### State Advancement + Rewards Phase

Once the `PROOF_ACCEPTANCE_WINDOW` has ended, the winning proven block can be marked canonical. This requires an L1 transaction to update the state roots to the highest scoring block, and rewards payments to be issued to the builder and proving network.

The cannonical block and uncle block(s) receive a block reward.

The process repeats from this point. NB, if the off set `T` used to determine transaction pre-confirmation time is set to 0, some proposed blocks will become invalid once the previous block's `PROOF_ACCEPTANCE_WINDOW` ends and the winning block is known.