---
title: 'rough mid game (ePBS + MEV Burn + SSF)'
disqus: hackmd
---
**PBS Proposal Popery**
:::success
Popery not potpourri because this is a vision to head towards, not a fully fleshed out plan.
:::

<center>
<img src="https://hackmd.io/_uploads/BJ506v_E2.png" width="350" height="300">
</center>
</br>

The vision for eth `v2.5` is a dynamcially available protocol that can: handle block auctions natively, burn majority of MEV, and come to finality within a slot. While daunting, each of these pieces compliment each other in interesting ways.

## Table of Contents
[TOC]

## Diagram
- how to visually communicate different message types being passed around?

## Slot Stages
### 1. Proposal
#### Description
Proposer publishes best bid from `builder-bid` topic which proposes `builder_pubkey` allowed to publish the next builder block

#### Open Questions
- Missing this block means we miss 3 blocks total and 20s of protocol time, is this bad?
- Incentivizes as late as possible block reveal by builders

### 2. Proposal Attestations

#### Description
Attestors begin attesting to which proposer block they consider valid. The major thing to check for here is attestations for the builder to reveal their payload. Whoever has the most attestations will get proposer boost in the payload reveal

- [total eclipse of the relay](https://hackmd.io/@dmarz/total-eclipse-of-the-relay)
- [equivocation attacks in mev-boost and ePBS](https://ethresear.ch/t/equivocation-attacks-in-mev-boost-and-epbs/15338)
#### Open Questions

### 3. Payload Reveal

#### Description
Builder's who believe their block will become canonical if revealed do so.

#### Open Questions

### 4. Payload Attestations

#### Description
Attestors attest to seeing the payload.

#### Open Questions

### 5. Finality Attestations

#### Description
Attestors attest to seeing the attestations of the payload.

#### Open Questions

## Research Areas
### ePBS

- [2 Slot PBS w/ Unconditional Payments](https://hackmd.io/@vianq8jgSjC9fiZvnjcAvw/r1wrQ7UMn?utm_source=preview-mode&utm_medium=rec)

following is directly from : [towards enshrined PBS](https://github.com/michaelneuder/optimistic-relay-documentation/blob/main/towards-epbs.md)

"
#### Proposal
*enshrined PBS recap*

* **builder balances**: Builders have an onchain ETH balance.
* **builder addresses**: Builder balances are held in EOA addresses.
* **builder bids**: Builders gossip bids which contain:
* *payload commitment*: a commitment to an execution payload
* *payload tip*: an amount no larger than the builder balance
* *builder pubkey*: the ECDSA pubkey for the builder address
* *builder signature*: the signature of the builder bid
* **winning bid**: The proposer has a time window to select a bid to include in their proposal.
* **payload reveal**: The winning builder has a subsequent time window to reveal the payload.
* **attester enforcement**: Attesters enforce timeliness:
* *bid selection*: an honest proposer must propose a timely winning bid
* *payload reveal*: an honest winning builder must reveal a timely payload
* **payload tip payment**: The payload tip amount is transferred to the proposer, even if the payload is invalid or revealed late.
* **payload tip maximisation**: Honest proposers select tip-maximising winning bids.

"
#### Open Questions

- how do unconditional payments work?
- beacon txn (?)
- execution txn (?)
- p2p analysis + builder sybil resistance

### MEV Burn
[MEV Burn - Design and Benefits](https://notes.ethereum.org/qmOPTEBJQLOKeje9JMLlhg?view)
#### Background
MEV burn is desirable because it:
- Disarms the centralizing effects of MEV ("whoa my block had 1000 Eth in it, let's spin up 31 more validators!")
- Intimately related to mev-smoothing, which lessens the impact of spikey mev rewards
- We have dynamic reserve pricing for overall congestion, mev burn now allows us to create dynamic reserve pricing for state contention. (base fee only prices arbitrary block space usage)

#### Proposal
"
*MEV burn add-on*

* **payload base fee**: Bids specify a payload base fee no larger than the builder balance minus the payload tip.
* **payload base fee burn**: The payload base fee is burned, even if the payload is invalid or revealed late.
* **payload base fee floor**: During the bid selection attesters impose a subjective floor on the payload base fee.
* *subjective floor*: Honest attesters set their payload base fee floor to the top builder base fee observed D seconds (e.g. D = 2) prior to the time honest proposers propose.
* *gossip delay*: D is a protocol parameter greater than the bid gossip delay.
* **payload base fee maximisation**: Honest proposers select winning bids that maximise the payload base fee.

"

#### Paths forward

### SSF
#### Background
- "In the context of Ethereum, the available ledger is output by LMD-GHOST. However, in the process of formalizing the security requirements of Gasper, Neu et al. show that the (original version of) LMD-GHOST is actually [not secure even in a context of full-participation](https://arxiv.org/abs/2009.04987), by presenting [a balancing attack](https://ethresear.ch/t/a-balancing-attack-on-gasper-the-current-candidate-for-eth2s-beacon-chain/8079)"
- "The [proposer boost technique](https://notes.ethereum.org/@vbuterin/lmd_ghost_mitigation) was later introduced as a mitigation, though the [resulting protocol falls short](https://ethresear.ch/t/balancing-attack-lmd-edition/11853) of being dynamically available.""
- "To cope with the problems of LMD-GHOST, D’Amato et al. devise Goldfish 4, a synchronous protocol that enjoys safety and liveness under fully variable participation, and thus that is dynamically available."" Goldfish is based on two techniques:
- [view-merge](https://ethresear.ch/t/view-merge-as-a-replacement-for-proposer-boost/13739), which allows validators to join the sets of the messages they received (at some point during the execution) before making any protocol’s decision
- [vote expiry](https://arxiv.org/abs/2209.03255), where only messages received within a specific time window influence the protocol’s behavior
- "However, Goldfish is not considered practically viable to replace LMD-GHOST in Ethereum, due to its brittleness to temporary asynchrony: even a single slot of asynchrony can lead to a catastrophic failure, jeopardizing the safety of any previously confirmed block."
- "We overcome the limitation of Goldfish with RLMD-GHOST 3, a protocol that generalizes both LMD-GHOST and Goldfish. As the former, RLMD-GHOST implements the latest message rule (LMD). As the latter, it implements view-merge and vote expiry. Differently from Goldfish, where only votes from the most recent slot are considered, RLMD-GHOST is parameterized by a vote expiry period `η` , i.e., only messages from the most recent `η` slots are utilized. For `η = 1`, RLMD-GHOST reduces to Goldfish, and for `η = ∞` to (a more secure variant of the original) LMD-GHOST."

#### New Justification Round
- To achieve SSF, "we can add another FFG voting round, or, as we decide to do in the paper, we can ask that validators send a different type of message *acknowledging* the justification. For example, if the checkpoint (B,t) (B,t)(B,t) is justified at slot t tt , validators can send the acknowledgment message ((B,t), t) ((B,t),t)((B,t), t) , confirming their knowledge of the justification of (B,t) (B,t)(B,t) . This way, they signal that in future slots they will never cast an FFG vote with a source from a slot earlier than t tt . We can attach a slashing condition to this, almost identical to surround voting: it is slashable to cast an acknowledgment ((C,t),t) ((C,t),t)((C,t),t) and an FFG vote (A,t') \to (B,t'') (A,t′)→(B,t′′)(A,t') \to (B,t'') with t' < t < t'' t′<t<t′′t' < t < t'' , i.e., where the FFG vote *surrounds* the acknowledged checkpoint. Then, if 2/3 of the validators cast an acknowledgment, we can finalize the acknowledged checkpoint.""

#### Dynamic Availability
- "A major requirement for the consensus protocol of Ethereum is that it should be available (or, dynamically available), meaning that its functioning should not depend on some arbitrary participation threshold, like requiring 2/3 or 1/2 of the validator set to be online. This is partly what motivated the hybrid design of the current consensus protocol, Gasper 3, which combines an available protocol, LMD-GHOST 3, with a finality gadget, Casper-FFG. The purpose of the first is precisely to always produce an available chain, preventing the consensus protocol from merely halting when there are not enough validators online. When 2/3 of the validators are online, Casper-FFG finalizes portions of the available chain, endowing them with economic finality, also known as accountable safety, the guarantee that no conflicting finalization can happen without 1/3 of the validator set being slashable."

#### Path Forward
- "Once we have an appropriate available chain at our disposal, creating a single slot finality protocol turns out to be suprisingly easy."
- "In Gasper, the fork-choice starts from the latest justified checkpoint, so we need justifications to not interfere with the available chain"
- "a key property of RLMD-GHOST turns out to be that it supports fast confirmations, so that honest proposals are confirmed during their proposal slot, when at least 2/3 honest validators are online. This is crucial for single slot finality, because fast confirmed honest proposals can then be immediately justified and finalized"
- "To ensure that this happens whenever a proposer is honest and network synchrony holds, we once again exploit the view-synchronization allowed (under network synchrony) by the view-merge technique 4, in order to get all honest voters to agree on what the latest justified checkpoint is, to be used as source of their FFG votes.""

### Inclusion Lists
- [Proposer suffixes](https://ethresear.ch/t/how-much-can-we-constrain-builders-without-bringing-back-heavy-burdens-to-proposers/13808)
- [Forward Inclusion Lists](https://notes.ethereum.org/@fradamt/forward-inclusion-lists)

The mechanics to enable inclusion lists in current PBS flows exists today, with perhaps the exception of fast arbitrary zkp's. The difficulties as eloquently stated in "[How much can we constrain builders without bringing back heavy burdens to proposers](https://ethresear.ch/t/how-much-can-we-constrain-builders-without-bringing-back-heavy-burdens-to-proposers/13808)" are:

1. Who computes the post state root - proposer, builder, or some third party ?
2. When are the transactions included - at time of commitment, or in the next block ?
3. Where does the inclusion list exist relative to execution payload - before or after ?

Below we can see the two general flavors of proposal.

#### Proposer Provided Tx List


#### Proposer Commitment w/ 3rd Party


### Discussion

The simplest approach would be: proposer adds a list to mev-boost registration for it's slot + transaction trie root. The builder who wins the auction will only be included if they provide a merkle proof of tx inclusion.

So why dont we go with this approach? It's not incentive compatible for starters. A builder can chose to simply ignore a proposer if they are requiring an OFAC txn and not build on that block. This actually maybe isn't the worst because someone will offer the txn.

But even worse, all of these designs expose surface area for MEV. A suffix inclusion list can get probabilistically sandwiched and same with a prefix. If the builder has full control over the transaction, they can also play ordering games.

## Random Questions
- should we add a block type data field? `proposer, builder, finality`
- need to think through what were to happen at each stage if it were to fail to reach majority attestation consensus etc
- go through and find specific time limits for each stage

Potential Section: What overlays / new gossip sub topics are needed for this to go live?
-

# View Merge + Dist Erasure Coding
- freeze view
- view starts recording
- receives proposer commitment to block
- receives encrypted chunks
- props encrypted chunks
-