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!

In April of 2023, a malicious proposer tricked the Ultrasound relay into revealing the contents of a block by committing an invalid block initially. This allowed for the attacker to perform an unbundling attack to reorder the transactions against the builder's MEV attempts to get a heavy profit of $50M. Troy found a variant of this attack on the Titan relay implementation.

Running validators and building optimal MEV blocks are entirely different specializations. So, the validator (proposer) can outsource their block building to another entity called a builder. The relayer is an intermediary that can take multiple proposals (aka how much they will pay the validator to make the block how they want). The secrecy of the built block is of the utmost importance to the builder, as we learned with the 2023 attack.

During a proposer's slot, it will request a payload from the relay. It will then sign and thereby commit to proposing this block without seeing the entire payload, which is called blinded. The proposer will then send the signed block back to get the relay to send back the unblinded block, revealing its contents.

This blinding approach works because of duplicate block slashing. If the proposer signs the commitment, gets back the other block, and frontruns the original with their own malicious and unbundled block, then it will get slashed (lose funds) for doing this. To make this even harder, the relayer delays responses to line up with their proposal windows end in order to make it harder to perform unbundling attacks.

Ethereum blocks contain a blob sidecar (additional blob information). When a Beacon Node receives this, it will reject it if the commitments do not correspond to the blob contents. The function validate_header_equality() verifies the contents of the signed execution payload match what the builder supplied but it does NOT check the KZG commitments.

Since invalid KZG commitments can be provided, the block will be rejected when propagated but the relayer doesn't know this. So, when the block is returned, it can be unbundled when sent back to the proposer to do the same attack as from 2023. To fix this, the code now verifies that the builders and proposers have matching KZG commitments.

Overall, an excellent blog post that is rich in context for those (like myself) unfamiliar with the MEV builder and proposer market.