EPF Project Updates

In reverse chronological order - most recent updates up top.

Table of Content

Final Project Update

Project abstract

Prysm, GETH, and Lodestar are collaborating on a design for enshrined proposer-builder separation with an inclusion list for Ethereum’s core protocol. This design is based off of discussions with Mike Neuder and Vitalik which can be referenced here:
https://ethresear.ch/t/payload-timeliness-committee-ptc-an-epbs-design/16054
https://ethresear.ch/t/no-free-lunch-a-new-inclusion-list-design/16389

PBS is a form of MEV resistance whilst an Inclusion List is a form of censorship resistance. The implementation of these aspects into the core protocol make sense and increases the resiliency of Ethereum against MEV and censorship.

Roadmap / Overview

In terms of the current design the fellows supported the client teams on, the next step is to begin coding a version for any of the clients that can serve as a devnet POC. Potuz and Terence have completed the design write-up and high-level specifications for the teams and Manav has begun work on GETH.

My support for this project has been understanding the design from a research perspective i.e. searcher/adversarial mindset approach. To this end, I am working toward three deliverables as discussed with the rest of the team:

  1. Gap analysis of Potuz’s design write-up and the high-level specifications. This should serve as a general PR review of the specs, analysis of the design from both a fundamental and details perspective, extraction of open research questions and/or design vulnerabilities/incompleteness, and vice versa cross-reference for missing specifications or on the design publication;
  2. Design analysis of Potuz’s write-up against Mike’s post on the fundamental design. There should be contradictions here, though we recognise the current client design is not the same;
  3. A finalised comprehensive write-up of the design including rationale.

Status report (state of the project)

I’m only about 40% complete with #1, though I would say that this work incorporates important information, insight, and understanding gained that will accelerate the work and work timeline for #2 and #3.

As I continue looking at this from a research perspective, there are already gaps in the design that are clear which currently include:

  1. What the relay / relay aggregator replacement looks like from a core protocol perspective;
  2. Rationale / explanation of trade-offs in this particular design;
  3. A serialised inclusion list implies new MEV opportunities (intrablock v interblock) and likely unforeseen consequences e.g. extra-protocol bribery or validator-lead arbitrage since the IL is published one block ahead of the inclusions.

Future of the project

As potential next steps and improvements for the project I would like to work on the following:

  1. Complete deliverables #1, #2, and #3;
  2. Research missing gaps in the design as noted in the above;
  3. Complete any further required specifications resulting from research.

Self-evaluation & EPF feedback

I overwhelmingly enjoyed the EPF! I can’t stop thinking about how cool it is to have the opportunity to work with core Ethereum researchers and developers on a live project. The vibes were immaculate and I believe in Ethereum’s vision and ethos more than ever. Not only was the programme team just amazing but the client teams and core Ethereum research teams as well. Everyone was extraordinarily kind, patient, supportive, and helpful and I also really enjoyed working with other cohort members and learning more about the interesting projects people across the protocol are working on.

Important learnings for me included the following:

  • How to successfully work productively and efficiently in a highly independent and decentralised fashion;
  • Strong affirmation of Ethereum as a true public good and mission-driven organisation including Ethereum culture and values;
  • The state of PBS and ePBS proposals;
  • Ethereum organisational infrastructure e.g. I listened into core dev calls and understood better what the organisation actually looks like and how it works together;
  • Meet and greets and conversations with core Ethereum teams on the organisational front (e.g. Tim), research front (e.g. Hsiao-Wei, Toni, Barnabe), and client team front (e.g. SigmaPrime, Lodestar, Prysm, Nethermind, etc.).

Although I think that in the beginning I had a slow start, I feel that I'm becoming more comfortable and familiar working within the EF orbit and I cannot imagine spending my time anywhere else.

Week 15 + 16 (Vacation + Dev Connect)

Empty weeks :(

Week 14 | Update 14

  • Completed gap analysis document.
  • To review clarification / understanding questions with the rest of the team this week in walk-through.

Week 13 | Update 13

  • Continued working on gap analysis document.

Week 12 | Update 12

Week 11 | Update 11

  • Completed the transfer of high level requirements over for the inclusion list design. Working through the line-by-line spec gap analysis. Added in rationale in order to think through the design further.
  • Generated table of variables and definitions from all available specs.

Week 10 | Update 10

Tasks to be completed this week:
(1) Transfer over high level requirements line-by-line interpretation from design posts.
(2) Generate table of variables from all current specs.
(3) Start on PR reviews, matching specs v requirements as a gap check.
(4) Look for design flaws / improvement areas.

Week 9 | Update 9

  • Felt a blocker in making active contribution. I've been reading and re-reading the content but felt there was an unknown gap between understanding and applying this to the PR reviews and specifcation designs.
  • Spoke to potuz about it and he was able to clarify that the current spec design is indeed an open interpretation. It is possible to help improve the specs and we do need to confirm that the specs follow the requirements as laid out in the high-level design.
  • We also clarified a point in regards to the split view attack which is an open research question (but the same attack in principle applies to general CL).
  • With the confirmatino that the specs are client-agnostic I will be doing the following in the upcoming week:
    • Using ChatGPT (1) grab the variables from the specs (2) review syntax / typos in the python (pseudo)code
    • Lay out requirements per the high-level designs
    • Verify that the specs follow the high-level designs (PR review)

Week 8 | Update 8

Week 7 | Update 7

  • Read through all of potuz and Terence's Github markdown files to review the live specs for Prysm's ePBS flavour.
  • Extracted the information that would be required for explaining high level requirements and rationale for PePBS. It's quite high level right now and I have clarification questions.
  • Shared the draft in the Discord.

Week 6 | Update 6

  • Discussed with potuz how I can best contribute to Prysm as a researcher. I can either review the PRs i.e. live markdowns or work on the execution specifications.
  • I didn't know what the requirements / vision for Prysm ePBS looked like especially since it's different from the current research proposals published. Agreed with potuz I can work on Prysm ePBS documentation to get started.

Week 5 | Update 5

  • Continued having trouble finding the right thing to work on. I felt part of the complexity for me was it being my first time contributing to a hefty public project in full flight v my previous experience which was either corporate or working on public projects from scrach which is has very different working styles and starting ooints.
  • I also found it challenging trying to contribute to Ethereum as a junior researcher. Per Barnabe's suggestion it makes more sense to pick an existing proposal. The time spent the past two months exploring Ethereum research resources was still quite useful and I'm excited to review them once again when I'm a bit more seasoned!
  • Very grateful to potuz for giving me the chance and time to work on Prysm ePBS with him!! 🙏
  • Caught up on the Prysm Discord channel for EPF and other readings that were pinned.
  • Caught up on Prysm ePBS specs.

Week 4 | Update 4

Week 3 | Update 3

  • Caught up on latest MEV upates from EthCC and MEV Day recordings.
  • Continued reading through relevant consensus content.
  • Started thinking more formally about the potential proposal.

Week 2 | Update 2

  • Had a good conversation with Marius which confirmed the feeling that there is a low level of interestingness in doing an analysis of the consensus protocol vulnerabilites against attack vectors. MEV and attacks on proposer validators such as the deanonymisation attacks are more interesting. I've decided to pursue a proposal that piqued some interest during the conversation which is coming up with a series of rules for block selection that would mitigate if not eliminate MEV.
  • https://flashbots.notion.site/flashbots/MEV-Week-Paris-A-Hitchhiker-s-Guide-6522b2aa9c2f4acabbc648c9965f0751.
  • Continue with the readings to fully understand the Ethereum roadmap including single slot finality, proposer selection, committee reorgs, and sharding impact.

Week 1 | Update 1

  • Made a list of whom to speak to not only as a mentor but generally industry-wide. Will contact them only if questions come up but so far still working on understanding and thinking through. To start with: Alex Stokes (EF Consensus Research), Hsiao-Wei Wang (EF Consensus Research), Joachim Neu (Stanford Blockchain Research).
  • Are there any other skills I should work on in order to perform my best for this particular project topic?
  • Continue to work on pre-work reading list.

Week 0 | Update 0

  • Strongly considering researching Ethereum fork-choice implementation - pre-work, digging, thinking. It might be interesting to explore attack vectors especially in light recent attacks on the Ethereum consensus.
  • Spent time reflecting on the fundamentals of Etheruem consensus i.e. overlap with current BFT studies / work and what more I should cover in reading / understanding. Decided that the most specifically relevant readings have been identified and to use that as a starting point.
  • Created a reading list pertinent to beginning research on fork-choice and single-slot finality on Ethereum / blockchain at large.

Random Thoughts

  • MEV is bad for user experience on Ethereum because (1) it drives up network fees due to contention and congestion resulting in higher tips required -> expensive (2) economics-aside the average user transaction getting crowded out or censored due to MEV searching is unfair -> ethics.
  • MEV's greatest threat to network destabilisation is the potential for collusion during consensus if the MEV reward for validators exceeds the anticipated round's rewards.
  • Solutions account for MEV mitigation by distributing rewards to the validators instead of solely to the searcher (either a party or an individual) but it does not account for improving the user experience since in the quest for MEV user txn fees are still heightened especially for intrablock strategies.
  • From the beginning - simplistic review of blockchain design. There exist basic requirements.
    • Basic requirements / outline
      • Incentive mechanisms for p2p participation - nodes to run the blockchain
        • Nodes in most blockchains invest their energy (PoW), time, and money (PoS) -> this means the rewards must provide more benefit or higher economic value than what is expensed
        • Nodes need to maintain liveness, safety / security, efficiency / speed / scale, decentralisation, permissionlessness, and fairness.
      • Defense mechanisms against malicious behaviour (attacks that slow, stop, or impact the integrity of work)
        • Penalties
        • Built into consensus mechanisms
      • Byproducts
        • MEV - creative loopholes that earn participants or users economic rewards
      • Users should be able to submit transactions and have a high level of confidence the transaction will get included as quickly as possible.
      • Primary block-building activities are block creation (including user txns), agreeing on which block will append the head of the chain, and appending the latest block to the chain.
    • Consensus-specific requirements
      • Nodes agree on what a valid next block is - this is also best done in the most ethical way which means rewards distributed to all participants (at minimum these should be all particiapnts that successfully tried)
      • MEV takes advantage of the block-building exercise by front running / sandwiching / liquidating participants for arbitrage from semi-privileged information/position in the network as a block-builder
    • Optimisation constraints / bounds
      • Decentralisation - node communication non-proximity and the lack of a central authority is the overlaying challenge and advantage of distributed systems.
      • Liveness / efficiency / speed / scale
      • Safety / security / permissionlessness / fairness
    • Partial right to build blocks is not out of the question.
  • Anti-MEV: Proposals / Issues to consider
    • Defining Fair Transaction ordering specifications. Aside from time-stamping. In accounting for the time delay what if we stipulate that validators must come to consensus on a certain percentage of transactions that must be increased? >85% is one criteria for an acceptable block?
    • Schelling Point is an idea that we return to. What are the best ways to prevent validators from gathering data amongst each other and only enough to do their particular part of the assembly line job? Rationale for PBS.
    • What if when txns are submitted they automatically get marked by the core protocol for a certain block? According to the current consensus mechanism there is practically two-slot finality. Block-builders are still incentivised by earning native currency but every block that would be built would be expected to be uniform.
    • Block builders can submit take transactions that dirty the pool and their own block.
    • ^ What are all the ways in which we can trick the core algorithm?
    • Any type of price-auctioning is in reality inequitable because it penalises users with less funds, defeating a fundamental part of blockchain ethos. Incentivising network participants should not be a burden placed back to the user at least not from an economic perspective.
    • A general principle of blockchain design should be as little reliance on external protocols as possible - as a general design rule. Third parties are OK as this could encourage a more creative and diverse ecosystem opening up new opportunities unbound by the L1. However if the core protocol relies on external/other protocols (aside from external people as general participants) it introduces contagion risk from those protocols and increases its own risk. Although this could be mitigated from monitoring tools and fallback mechanisms there should be a clear and sufficiently beneficial reason for the amount of work that would be needed to monitor and mitigate the risk mentioned here.
    • In 1559 the gas costs are pegged and fluctuate according to demand in order to best calculate marginal impact of the user to blockchain traffic.
    • In terms of prioritising blockchain problems, it might make sense to have a bottom line an 'acceptable' bottom.
    • Slippage and priority fees are part of the problem and not part of the solution <- there is misalignment of incentives on part of users, searchers/builders on this front.
    • IS the world of MEV relatively limited to commotidised MEV? This is what this proposal would mitigate the most of.
    • Drake's final formula is total block rewards = - base fees + priority fees <- where does the builder balance come into play?
    • I guess the point of burning the MEV is to tell searchers that the more expensive the block either the txn fees or MEV value would be futile because they will get burned and you can't bribe (higher values don't win in this case) -> is there a case in which certain types of other MEV strategies would win then where the txn searching would get split up interblock. You will get smoother reward distribution but txn pricing could still be high due to congestion just not per block instead for strategies they would be distributed across the blocks (is this feasible for certain types of arb
    • Remember that the existence of MEV comes from the ability of block builders to order and censor transactions.
    • How do proposers know whether or not which transactions are MEV-induced and which are toxic?
    • What is the builders balance?
    • The two-second time bound under Drake's proposal challenges builders with the available time to build as well. How long does it take to build an honest block without MEV but still sync and come into the view? If we shorten the amount of time for blocks to pool it could add another layer of less MEV.
    • Is there a way to incorporate the concept of stock splits into validator stakes that would secure the network and enable further decentralistaion and participation from the average individual?
    • Is the ultimate solution not a selection for the lesser of all evils? Optimisation game for rational searchers, proposers, and attestors. Rational can also be dishonest when it pays.
    • How can builders guess what the base payload will be?
    • Don't understand why late bidding is relevant since if the block wasn't submitted as part of the bidding process then it should not be eligible for inclusion. If the collusion is that all block-builders participate in this then it is almost impossible since as long as there is one honest block-builder then that builder will win. In a prisoner's dilemma the searcher that submits a block would win more by outing accomplices.
    • To look up
      • Sealed bids
      • Second-price auctions
    • Issues
      • Issue #1 . A searcher who is highly performant could dominate MEV capture which results in a monopoly on MEV (although most of the rewards will be redistributed to the wider community). Could we enforce a high percentage of the payload to be redistributed and let this be a better version of the current evil?
      • Issue #2 . Deanonymisation attacks (more relevant as an issue in the case Ethereum does not enforce PBS). The IP address for the next proposer can be predicted and a DoS attack is organised.
      • Honouring out-of-protocol (essentially off-chain) market for blockspace
  • Important to note
    • When proposers do not propose their own-built block it is considered "selling" off the right for the that block. Ideally a proposer can be fairly unsophisticated and achieve most of the value their position confers upon them.

Many notes may be kept offline on printed paper copies. Notes I want to work with will be preserved in written analyses rather thanthe notes below.

Validator (MEV) Attacks

MEV Burn - Justin Drake

  • https://ethresear.ch/t/mev-burn-a-simple-design/15590
  • https://www.youtube.com/watch?v=jlGc0npwkeU
  • EIP 1559 but for MEV
  • Two use cases for blockspace
    • Include txns - get confirmations
      • competing for inclusion gets congestion
    • Get an ordering of txns
      • contention
  • Block value is the sum of contention + congestion value
  • EIP 1559 - burn congestion fee
  • MEV spikes randomly
  • MEV burn benefits
    • Smoothing (rewards smoothing); MEV spikes bring volatility/variance to rewards; comes with security benefits as well
    • Cash flow redistribution (economic benefits) - redirect cash reward from stakers to holders
  • Construction of the proposal
    • Proposer Builder Separation: builders create pools and bid in a bid pool which is maintained through relayers which are semi-trusted operators (tells proposers when they have a valid bid); proposer will generally take the highest paying top bid and commit by signing it then broadcast the signature <- guarantees some sort of payment of the bid value from the builder to the proposer
    • Enshrined PBS: build this into L1 consensus -> bidding before the slot starts then at the beginning proposer commits to a bid and then the reveal payload -> attestors enforce the PBS liveness after proposal and again after reveal of payload (attest to timeliness)
    • MEV Burn: ask attestors to observe bidpool 2 seconds before the start of the slot and calculate the burn floor (top bid) and enforce the burn floor at the proposal level. If the proposer picked a bid that didn't respect the burn floor and didn't maximise value then it own't be included in the chain. This would maximise the block base fee (MEV) maximising the value of the block and the burn. The bid value would get destroyed rather than going to the proposer.
      • builder balances: Builders have an onchain ETH balance.
      • payload tip: an amount no larger than the builder balance
      • payload tip payment: The payload tip amount is transferred to the proposer, even if the payload is invalid or revealed late.
      • 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.
        • synchrony assumption: D is a protocol parameter greater than the bid gossip delay.
      • block bid = payload base fee (capped by builder balance) - priority tip
        • payload base fee is then burned
        • capped by builder balance in order to ensure builder balance can be used as collateral for the pyaload base fee?
        • is the payload base fee basically what a builder is willing to give up / burn? how is this determined or how would a builder practically calculate this?
      • for exceptionally large MEV spikes the most capitalised builder has the power to capture all MEV above the second-largest builder balance. This design flaw can be patched with a L1 zkEVM that provides post-execution proofs.
      • optimisation game: Rational proposers will want to maximise the payload tip by guessing the payload base fee floor and accepting bids with non-zero tips after the payload base fee floor has been established. This creates a second optimisation game for rational proposers, in addition to the existing optimisation game with proposal timeliness.
  • Benefits
    • Enshrining
      • (1) MEV oracle - the Ethereum is now aware of how much MEV there is. Can be used for blockspace futures for example. Enshrining ETH because people have to use it - privileged unit of account.
      • (2) Forces the market towards a more trustless equilibrium bc of a new bidpool that is optional to use. Builders and validators can still use relays (which should be used when the vid value is greater than collateral posted by the builder -> if collateral is not sufficient) MEV burn removes the option for the proposal to go through relay.
      • (3a) Censorship. Bidpool is built on censoring txns and those who don't. Some proposers might only listen to censored bidpools. Force them to listen to both pools <- forcing the hand against censorship.
      • (3b) Cost of censorship. Before 1559 if you didn't include a specific txn then you need to pay the txn fee for that txn. With EIP 1559 you only had to forgo the tip. Full cost of censorship being the full cost of txn fee.
    • Smoothing
      • MEV can upset the stability of L1. Median MEV return is significantly smaller than average (which is 3x larger). Need to pool in order to remain relevant for smaller players. MEV burn removes centralisation pressures whilst still providing equity.
      • MEV goes to malicious proposer by DoS'ing other proposers.There are other attacks to steal MEV from other participants.
      • Rug-pulling - delegated operators rug the stakers (Lido is based on reputation and Rocketpool uses collateral so there are incentive alignemnts). Operators may be incentivised when the MEV rewards are higher than the collateral. Decentralised pools are competing to lower collateral for efficiency -> this makes decentralised staking pools more robust.
      • Toxic MEV - MEV where there is a clear victim that is losing value. Shoudl we return the MEV?
      • Systemic MEV - huge amounts of toxic MEV.
      • Unlocks Stake capping -
    • Redistribution

Combining GHOST and Casper [arXiv:2003.03052v3 May 22 2020]

  • Notations
    • V = view
    • B = block
    • j = epoch
    • C = slot
    • p = permutation
    • ep() = local property of epoch boundary
    • aep() = context of the chain epoch boundary
    • α = attestation
    • (V,T) = view at a given time T = set of all accepted msgs validator has seen
    • (NW, T) = network view = God's eye view = set of accepted msgs a hypothetical validator that has seen, with no latency all msgs any validator has broadcast at any time (includes msgs sent by malicious validator to only subset of network) = virtual validator
    • (NW, T) incorporates (V,T) but msg timestamps may mismatch
    • M ∈ view(V,T) = V has seen and accepted M
    • M ∉ view(V,T) = V has seen but not accepted M
    • w(V) = validator stake
    • N = total validator stake
    • F(G) = set of finalised blocks
    • fork(G) = chain(B)
    • p = 1/3 byzantine
    • ep(i) = j = [i/C] = epoch j of slot i = blocks belonging to epoch j have slot numbers jC + k
    • (ii) = reference to partial synchrony
    • H = block height
    • h(B) = checkpoint height for a block B
    • A J-> B = supermajority link = at least 2/3 total validator stake weight attestations voted for A -> B and A is justified and now B is justified.
  • HLMD GHOST fork choice takes the weights of subtrees during forking as a heuristic with the heaviest subtree the "right" one. Heaviest means the highest number of attestations voted.
  • Finalisation gadget refers to the establishment of periodic checkpoints that "mark" blocks that are finalised lending a quick parse to decide the historical canonical chain and from which establishes a two-block finalisation period.

Literature

In line with the scope of studying / current work I've been on, my project will likely consist of an analysis of current single-slot finality proposals in particularly researching potential new attack vectors to watch out for. I feel this work is probably relevant and likely important considering the infinitely creative ways in which hackoors work, especially in context of the recent attacks on the consensus protocol.

List of readings on MEV and MEV mitigation proposals.
https://ethresear.ch/t/mev-burn-a-simple-design/15590
https://collective.flashbots.net/t/to-burn-or-not/647
https://ethresear.ch/t/burning-mev-through-block-proposer-auctions/14029

List of readings on consensus. Mix of core Ethereum dev analyses on single slot finality proposals, recent attacks / issues, and current Ethereum infrastructure / specs.

https://notes.ethereum.org/@vbuterin/single_slot_finality#
https://ethresear.ch/t/a-model-for-cumulative-committee-based-finality/10259
https://ethresear.ch/t/decoy-flip-flop-attack-on-lmd-ghost/6001
https://vitalik.ca/general/2018/12/05/cbc_casper.html
https://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=9547320
https://arxiv.org/pdf/2102.02247.pdf
https://notes.ethereum.org/6EAsltAXSIeMHeRztEGRdg
https://eips.ethereum.org/assets/eip-2982/ef-Discouragement-Attacks.pdf
https://ethresear.ch/t/balancing-attack-lmd-edition/11853
https://www.paradigm.xyz/2021/07/ethereum-reorgs-after-the-merge
https://eips.ethereum.org/EIPS/eip-4844
https://notes.ethereum.org/@vbuterin/proto_danksharding_faq#What-is-Danksharding
https://notes.ethereum.org/@vbuterin/serenity_design_rationale#Why-32-ETH-validator-sizes
https://medium.com/@VitalikButerin/parametrizing-casper-the-decentralization-finality-time-overhead-tradeoff-3f2011672735
https://eips.ethereum.org/EIPS/eip-1011
https://arxiv.org/pdf/2003.03052.pdf
https://arxiv.org/pdf/1710.09437.pdf
https://notes.ethereum.org/@djrtwo/Bkn3zpwxB
https://github.com/ethereum/annotated-spec/blob/master/phase0/beacon-chain.md
https://github.com/ethereum/consensus-specs
https://ethereum.org/en/developers/docs/networking-layer/
https://github.com/ethereum/devp2p
https://github.com/libp2p/specs
https://github.com/ethereum/consensus-specs/blob/dev/specs/phase0/p2p-interface.md#enr-structure
https://vac.dev/kademlia-to-discv5
https://eth2book.info/capella/contents/

Prior readings and discussions - mix of completed and in-flight.
On a separate Notion page - unavailable to share.

Select a repo