Adds mev commit support to flashbots relay

[ckartik]

📝 Summary

This PR integrates MEV-Commit functionality into the relay, enabling support for MEV-Commit registered validators and builders. Key changes include:

Add new MevCommitClient to interact with MEV-Commit contracts
Update Housekeeper to periodically sync MEV-Commit validator and builder registrations
Modify block submission handling to check MEV-Commit registration status
Add Redis caching for MEV-Commit registration data

Key implementation details:

New mevcommitclient package to interface with MEV-Commit contracts
Updated Housekeeper to sync MEV-Commit registrations every epoch
Modified handleSubmitNewBlock to reject submissions from unregistered builders
Added Redis caching for quick lookups of MEV-Commit registration status
New database migrations for MEV-Commit related tables

Testing:

Unit tests added for MevCommitClient
Existing tests updated to account for new MEV-Commit checks

This change allows the relay to support MEV-Commit while maintaining backwards compatibility with non-MEV-Commit validators and builders. Further testing and monitoring will be needed when deploying to production.

Diagram to assist understanding of changes related to pulling information from new data sources and caching.

sequenceDiagram
    participant API as Relay API
    participant HK as Housekeeper
    participant MC as MEV-Commit Clients
    participant MCC as MEV-Commit Chain
    participant BN as Beacon Nodes
    participant Redis

    Note over HK,BN: Startup
    HK->>BN: Get head slot (only on startup)
    BN-->>HK: Return head slot
    HK->>BN: Subscribe to head events

    Note over HK,MCC: Every 32 slots
    loop Every 32 slots
        HK->>MCC: Get active MEV-Commit validators for current and next epoch
        MCC-->>HK: Return active MEV-Commit validators
        HK->>Redis: Update active MEV-Commit validators
    end

    HK->>BN: Get proposer duties
    BN-->>HK: Return proposer duties
    HK->>Redis: Update proposer duties
    
    API->>Redis: Check for initialized data
    Redis-->>API: Data ready
    API->>MC: Initialize connection
    
    Note over API,MC: API ready to serve requests

    Note over HK,BN: Continuous operation
    BN->>HK: Stream head events
    HK->>Redis: Update head slot

    Note over HK,MCC: Every slot
    loop Every slot
        HK->>MCC: Get active builders
        MCC-->>HK: Return active builders
        HK->>Redis: Update active builders
    end

Loading

⛱ Motivation and Context

📚 References

---

✅ I have run these commands

• make lint
• make test-race
• go mod tidy
• I have seen and agree to CONTRIBUTING.md

[shaspitz]

Per conversation today this should just be for the current epoch, correct?

[ckartik]

The relay already employees this as their strategy, I'm guessing it's so that at the start of the epoch they still have some semblance of which validator needs to go next. Though this is def a confusing thing for me. Because the relay auction needs to run before the slot starts. That means a validator with a proposer duty to produce at slot 0 of the next epoch, must run the auction in the previous epoch. But how would that be possible, given that we've shown the proposer duties are only stable in the current epoch.

[shaspitz]

Isn't this already obtained in hk.updateProposerDuties?

[ckartik]

That stores a different representation of the data.

[shaspitz]

Don't need this imo and should purely use current epoch (where duties are finalized)

[ckartik]

I don't think it hurts, in the case of a reorg in proposer duties, we'll have slightly more data in the cache. I think that's worth it for the latency benefits we're getting. Especially for the first validator in the new epoch.

[ckartik]

Continuing to add more unit testing, but would appreciate a review on the new approach for builder monitoring. I think the more stable solution is to adapt the contracts themselves. But that would require a new release, which I want to avoid for this iteration of the relay. @shaspitz @aloknerurkar

[aloknerurkar]

Its fine to do this once in the start. But we need to monitor FundsSlashed event. Based on this event we need to Delete the registration. Currently we only check when we initially set it, however we might see providers getting their stakes slashed while this is running. So we need to handle that.

[aloknerurkar]

This is not really good design as if the application is closed then this goroutine is blocked. Ideally there should be some mechanism to close this, like passing a context to the start/having a channel which will be closed on stop and adding a check for this channel here.

Or you can close the newBuilderRegistered channel on close and then check it here:

builder, more := <-newBuilderRegistered
if !more {
    return
}

or

for builder := range newBuilderRegistered {}

[ckartik]

Thanks for the detailed advice. There's no context available to pass at the top-level, I don't think the housekeeper service itself handles shutdowns gracefully.

[ckartik]

I've opted for the second option you described. I could close the channel, but there's really no single on the application shutdown.

[aloknerurkar]

It might be better to have 2 goroutines here, 1 to listen for registrations and other to listen for funds slashed and then updating it to redis here itself instead of returning a channel. Then the housekeeper can just call a function here to check.

[ckartik]

Sure for now, ideally, we should emit a provider de-registered event as well.

[ckartik]

I'll update the contracts and do simplifications after, but I'll go with the approach you're suggesting for now.