rocketpool-research VS mev-boost-relay

What's to stop the authorities from outlawing all relays except the censoring ones? When you are forced to use MEV-boost trough threat of penalties (up to 80% of your stake!), then even those of us that "fell" for the decentralised promise of RP will be forced to be complicit in censorship.

Unfortunately RP is also starting to look more and more centralised. In the latest upgrade they introduce penalties which were not included in the original "dumb contract" between us, validators, and RP. What's worse, they speak of forcing validators use MEV-boost.

This surprised me a bit - I know this is how it works for a 16 eth node where it has to wait for another 16 eth to be matched and sent by the contract, but what about in my case? Am I still stuck waiting for the oDAO to confirm "everything looks right" (per here)? And if so, is there a way to see where I'm at on this queue? So is the contract holding the other 16 eth in the general pool and then will send it (basically "reserving" it for me)?

This is a better place to dive deeper into the research being done on this and other topics: https://github.com/rocket-pool/rocketpool-research

The minipool will wait for 12 hours while it gets vetted by the Oracle DAO to make sure it didn't abuse the Beacon Chain's withdrawal credentials exploit (this is known as the "scrub check")

We'll make sure to keep our awesome community updated as we go roll out our solution to this unexpected, but very welcomed addition to the protocol. https://github.com/rocket-pool/rocketpool-research/blob/master/Reports/withdrawal-creds-exploit.md

More info on this can be found here: https://medium.com/rocket-pool/the-merge-0x02-mev-and-the-future-of-the-protocol-c7451337ec40 and here: https://github.com/rocket-pool/rocketpool-research

Link to repository: https://github.com/rocket-pool/rocketpool-research/blob/master/delegate-upgrades.md

time="2023-06-11T19:51:35-04:00" level=info msg="best bid" blockHash=0xf2bd4f24d68a792c88cb5f885a5cd1682662fe26c0e0eb9e8b274e586df16681 blockNumber=17460239 method=getHeader parentHash=0x03beefa5530f40cec9c00119309838f5d3e82c007e1c98cc179ed269929a0f77 pubkey=0xa96f35d5a9d94d844e320ac284f7d86d9c5a238f7a1695bd7940290e6d964c11b8527763344b144d4e3f38a32f23c0ae relays="https://0xac6e77dfe25ecd6110b8e780608cce0dab71fdd5ebea22a16c0205200f2f8e2e3ad3b71d3499c54ad14d6c21b41a37ae@boost-relay.flashbots.net" slot=6641956 txRoot=0x63337111b810cd01e1ca5d9676831cc08c6da778ec1b9b462131efed5dd7b203 value=0.248591416663511916 version=v1.5.0 time="2023-06-11T19:51:35-04:00" level=info msg="http: GET /eth/v1/builder/header/6641956/0x03beefa5530f40cec9c00119309838f5d3e82c007e1c98cc179ed269929a0f77/0xa96f35d5a9d94d844e320ac284f7d86d9c5a238f7a1695bd7940290e6d964c11b8527763344b144d4e3f38a32f23c0ae 200" duration=0.147492 method=GET path=/eth/v1/builder/header/6641956/0x03beefa5530f40cec9c00119309838f5d3e82c007e1c98cc179ed269929a0f77/0xa96f35d5a9d94d844e320ac284f7d86d9c5a238f7a1695bd7940290e6d964c11b8527763344b144d4e3f38a32f23c0ae status=200 version=v1.5.0 time="2023-06-11T19:51:44-04:00" level=warning msg="error making request to relay, retrying" blockHash=0xf2bd4f24d68a792c88cb5f885a5cd1682662fe26c0e0eb9e8b274e586df16681 error="HTTP error response: 400 / {\"code\":400,\"message\":\"sent too late - 9234 ms into slot\"}\n" method=getPayload parentHash=0x03beefa5530f40cec9c00119309838f5d3e82c007e1c98cc179ed269929a0f77 slot=6641956 url="https://boost-relay.flashbots.net/eth/v1/builder/blinded_blocks" version=v1.5.0

I'm using boost-relay.flashbots.net and bloxroute.max-profit.blxrbdn.com

Relays have rolled out a quick fix that checks the user agent on getHeader calls and ignores requests from prysm users. Long story short again, this means that prysm users will fall back to local block production, so no MEV but still produce a block and get some rewards.

This the PR https://github.com/flashbots/mev-boost-relay/commit/84a943925e62f20b812c60688b6e433fba8e0da7

The relay fix to prevent this happening again is here (https://github.com/flashbots/mev-boost-relay/pull/330). This does has some significant side effects, the biggest of which is that ~10 sets of relay beacon nodes are now responsible for propagating all new blocks. Our (/u/austonst) relay (https://aestus.live) was taken offline for builders as soon as we became aware of the threat and will update before we come online again. Never a dull day in ethereum.

Interesting PR in the flashbots mev-boost-relay GitHub repo today, with a very interesting discussion in an earlier revision that I think is worth a read. It's a proposal to accept blocks from builders optimistically, assuming they are proper valid blocks, in order to reduce latency. Blocks are eventually validated, but only once the slot has passed and latency is no longer critical. Overall this increases the value of proposed blocks (compared to relays that don't implement this) and reduces mean transaction inclusion time.

We are currently using Flashbots' mev-boost-relay, and Flashbots' block-validation-geth for validating builder-submitted blocks. Flashbots' OFAC censorship is coded into block-validation-geth, and for the moment we have simply emptied their ofac_blacklist.json file with no intent to ever place anything in there.

Flashbot's relay is open source and written in GO. Create your own fork, load the Docker container and start testing and learning. https://github.com/flashbots/mev-boost-relay

Code: Flashbots' mev-boost relay code is open source. Blocknative and Eden both have their relays open-sourced as well, so it's possible to see if there's anything important. Eden's seems vanilla, Blocknative's is actually a completely separate implementation.