[Proposal] Sequencer Selection: B52 — PBS with a federated prover network

Aztec
,
12

After speaking with @zac-williamson for a few hours, we have concluded that this proposal does have a flaw as mentioned by @spalladino. The proposal will need modelling to understand the likelihood of this and if tweaks to parameters can prevent this.

A 51% attack

If an entity purchase 51% of the stake, they will trend towards a 100% probability of always winning block auction. Furthermore as the incentives for the provers to compete is linked to winning blocks, the 49% of the network will only win uncle blocks and will further reduce their stake.

An example:

  1. There are 100 stakers (provers) and Bob controls 51 of those.

  2. Bob is a block builder and so is Sally, they both run the same building software and on average can make blocks with the same value, leading them to bid similarly for a given block. Lets assume 1 token for easy maths.

  3. Bob bids 1 token and receive 51 votes (as he owns 51% of the stake). Bob’s score is:132,652 = 51^3 * 1^2

  4. Sally will have to bid at least 1.062 tokens to win as the maximum amount of votes she can receive is 49 votes in this scenario. (~133,000 = 49^3*1.062^2).

Over time, this creates a centralising force towards Bob, likely causing Bob to end up with 100% of the staking network, as the provers getting paid on uncle blocks will diminish over time as it is less profitable.

Further modelling is needed to tweak the formula for SCORE, or the proposal will need modification to always pay all provers, regardless of the score of their block, or to bake a VRF into the provers votes to be secure.

Fair pay prover model

Instead of splitting the block reward in the agreed split with the provers who contributed to a specific block, split the block reward amongst all the provers who contributed to any block.

This will have the effect of incentivising provers to work on any block, and to work with smaller proposers to get that block on chain, in order to prevent 51% stake attacks.

Modification with a VRF

Further protection against 51% attacks can come from modifying this proposal with a VRF as used in Irish Coffee or Cookie jar.

Instead of the sequencer using a VRF, each staker in the proving network would use a VRF attached to their vote.

A signature over
1. The block hash 
2. The index of the binary proof tree they will make e.g `Depth 10:Index 4`
3. VRF output for current block hash, which weights their vote

This has some nice properties:

  1. The VRF logic can be consumed within the rollup circuit. This means each block comes with its own proof of the VRF output, for no additional cost as its baked into a proof.
  2. It gives an easy way for the block builder to assemble provers into a block transcript, based on the weight of their VRF in any given block. i.e they will pick votes with high weight.
  3. It ensures the maximum amount of MEV is always burnt per block, unlike other models.
  4. It incentivises coordination.A builder needs to pay provers with a high VRF output fairly for a given block, not attempt to gain stake to win a block.
7 Likes