Resources

People often ask me "How did you learn how to hack?" The answer: by reading. This page is a collection of the blog posts and other articles that I have accumulated over the years of my journey. Enjoy!

Time, slots, and the ordering of events in Ethereum Proof-of-Stake- 1159

paradigmPosted 2 Years Ago
  • On April 2nd, a malicious network participant within the Flashbots eco-system "stole" (lost profits) $20M from a MEV searcher by abusing a vulnerability in the mev-boost-relay implementation. When the patches were released, this led to instability within the network and many reorgs.
  • mev-boot is a protocol designed by flashbots in order to mitigate the negative effects of Maximal Extractable Value (MEV) on the network. There are three main actors:
    • Relays: Mutually trusted auctioneers that connect the two other parties.
    • Builders: Entities who construct blocks in order to maximize MEV for themselves and the proposers.
    • Proposers: An Ethereum Proof-of-Stake validator who is about to create a block.
  • The ordering of an event for each block is as follows:
    1. A builder creates a block by looking at public and private orderflows.
    2. The builder submits the block to a relay.
    3. The relay validates that the block is valid (previous vulnerability lolz) and figures out how much to pay the proposer.
    4. The relayer sends a blinded header and a payment value to the proposer of the current slot.
    5. The proposer evaluates the bids they've received and signs the one with the highest payment.
    6. The proposer sends the signed header back to the relay.
    7. The blocker gets published by the relayer. The rewards are distributed as originally described.
  • The relayer is a mutually trusted third party that facilitates an exchange to benefit everyone. It prevents builders/proposers from stealing funds.
  • A fork choice rule is a function relating to reaching consensus on the state of the chain. In terms of time, the PoS system is broken down into 12 second increments called slots. A different set of nodes are assigned to vote on whether a block is legit or not for the head of the chain.
  • At 4 seconds, the block is proposed. At 8 seconds the voting occurs. At 12 seconds, the next proposer publishes their block. If a block isn't proposed after 4 seconds, they will vote for a previously accepted head of the chain. Why would somebody do this? Letting MEV accumulate is worthwhile because of the amount of funds that can be gained from it, but slows down the network.
  • How do we fix this problem of actors waiting and causing forks? Boosts! To minimize the amount of reorgs that occur, a fork-choice boost of 40% of the weight is given for a single slot for a single proposer. This prevents reorg balancing attacks. This allows the proposer to have more weight on the approval.
  • Honest reorgs are the other solution. If there is an attestation weight below 20%, a proposer can forcibly reorder the blocks to prevent a fork on the chain. By doing this, the forks are less likely to occur but the proposers are able to wait for a better proposed block.
  • An interesting post into the intricacies of MEV and the Flashbots protocol. I don't 100% understand everything here but watch direct adversaries attempt to make money without destroying the ecosystem is fascinating.