FEVM-Boost

This project aims to make the storing of fraudulent commitments from the mev-boost protocol more secure and decentralized.

mev-boost is a solution that helps to split the roles of the block builder and the block proposer. It sits between the proposer and a Relay, which is an entity responsible for holding block builders' bids.

Using a commitment scheme, the Relay tells the proposer: Mr. Relay: Hey, here's the hash of the block you will propose. Don't worry, it's the most valuable for you out of the ones I have in memory."

Then, the proposer responds to the relay by sending a signature of the block's hash. Mr. Proposer: Alright Mr. Relay ! Here is my commitment to use this block and only this block when you will send me the full block."

Finally, once the Relay has received the commitment from the proposer, it will send the full block to him.

Mr. Relay: Cool ! Now I am able to know whether you will modify the block I have given you or not. Don't play with me kid, I'm exposing this data to everyone."

Right now, Relays are storing this data on their own storage platforms, which are not safe from failures. This is very important as these commitments, sent by the proposers in the first place, are used to detect when validators modify blocks they received from third party block builders.

We used the FEVM to record storage deals pointing to data which themselves store fraudulent commitments, i.e. commitments to use a certain block not proposed by a validator in the end.

There are two components in this project.

The first one asks the Relay the commitment it received for a given slot. It is using a golang SDK I built which queries the Flashbots Data Transparency API.

Once received, the commitment - which is just the block hash the proposer has promised to propose and more metadata about the exchange - is stored in a Filecoin Storage. This method is mocked for now, and the result of the mocked function is a fake storage deal with the block hash set as the deal's label.

I used a mapping to store the commitments based on their respective slots.

Then, the Relay can verify the commitment once the block has been proposed. If the block hash of the real proposed block is the same as the one previously stored in the storage deal's label, it means that the proposer has not lied, otherwise the fraudulent commitment is stored in a second mapping, which contains fraudulent commitments only.

These queries to the Smart Contract (the Actor deployed on the Filecoin EVM) are made using hardhat scripts, called in the golang program.