I think we should get started on the conversation of reducing trust towards relayers. They are low hanging fruits with relatively little overhead that can benefit not only the proposer-builder-relayer trifecta, but the network itself. I’ve got one going, and it basically leverage zero-knowledge encryption and participants incentives to reduce trust assumptions toward Optimistic relays.
Here is the link, it includes code and a more detailed explanation of the problematic as well as the upside of the proposed approach. Sorry for pointing to my repo, I actually had the write-up in here, but as a new forum member I can only post two links!
See yall in the mempool, in here, or hit me there.
By the way, this is roughly how the protocol works:
As currently done, builders share with relays the list of pubkeys they want to use for optimistic relaying. Added step is that they then commit to these addresses either when calling deposit or add by passing in the sha256 hash of each address. The relayer can verify that the list of addresses they received off-chain matches the on-chain commitment by calling getHashCommitedBlsAddress and verifying that the output is equal to what the getBuilderHashCommitedBlsAddress getter returns. Please note that builders need to interact with this smart contract using the same ETH1 address, and this address needs to be communicated to relayers as it serves as key for the BuilderMetaDatas mapping, in which commitments and balances are stored.
Builders’ withdrawals are time locked by 7 days to avoid collateral “spoofing”, i.e. remove collateral right when it is needed as the builder performed any kind of attack. Relayers can check if a withdrawal was initiated by calling the getBuilderReleaseTime getter and checking for a non-zero value.
If the builder submitted an invalid block, the relayer can call invalidBlockDispute. The function computes the bidTrace signing root as well as the beacon block header signing root. These variables can be used as circuit inputs together with their respective signing keys to trustlessly verify that the signatures are valid, they were both generated by the public keys given in the bidTrace object over the bidTrace and BeaconBlockHeader messages. If that’s the case, the block value passed in the bidTrace message is withdrawn from the builder balance to the eth1 address of the proposer.
Obviously, there is room for optimisation in that protocol. You could make it so that builders can use different ETH1 addresses, verify only one proof vs two to reduce transaction costs, decide which inputs are private or public, or even “shield” the whole protocol. Nonetheless, these are future considerations. What matters most at first is that it is agreed that this is a desirable solution and something worth exploring in further details!