Add validator relay selection from configuration file

[0xpanoramix]

📝 Summary

This PR adds support for loading a configuration file used by mev-boost to understand which validator trusts which relay. The configuration file currently follows this format (this can change in the future):

interface configuration {
    builder_relays_groups: {
        [key: string]: string[];
    };
    proposer_config: {
        [key: string]: {
            fee_recipient: string;
            builder_registration: {
                enabled: boolean;
                builder_relays: string[];
                gas_limit: string;
            }
        };
    },
    default_config: {
        fee_recipient: string;
        builder_registration: {
            enabled: boolean;
            builder_relays: string[];
        }
    }
}

Any input on implementation is welcomed ! But for consistency purposes, any high-level ideas should go to #154.

Goals:

• [x] Support configuration extraction from raw JSON content.
• [x] Add support default configuration extraction.
• [x] Support configuration extraction from a JSON file.
• [x] Determine the way to store proposer configurations.
• [x] Add sanity checks for configuration values.
  • [x] Relay endpoints must be valid.
  • [x] Reference to groups must be valid.
• [x] Add a new CLI flag to provide the configuration filename.
• [x] Add a new field in the Boost Configuration struct.
• [x] Use the proper relays in the handlers.
• [x] Write tests to cover these cases.

Optional:

• [ ] Groups' names must match a pattern / are not empty.
• [ ] Remove duplicates after extraction.
• [ ] What should the default configuration file look like ?

⛱ Motivation and Context

For more context, see #154.

📚 References

---

✅ I have run these commands

• [x] make lint
• [x] make test
• [x] make run-mergemock-integration
• [x] go mod tidy

[codecov-commenter]

Codecov Report

Merging #186 (8c53e1b) into main (b5a28c5) will decrease coverage by 0.22%. The diff coverage is 85.36%.

@@            Coverage Diff             @@
##             main     #186      +/-   ##
==========================================
- Coverage   84.52%   84.30%   -0.23%     
==========================================
  Files           5        6       +1     
  Lines         614      739     +125     
==========================================
+ Hits          519      623     +104     
- Misses         71       87      +16     
- Partials       24       29       +5     

Flag	Coverage Δ
unittests	84.30% <85.36%> (-0.23%)	:arrow_down:

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files	Coverage Δ
server/config.go	74.73% <74.73%> (ø)
server/service.go	86.87% <100.00%> (+1.97%)	:arrow_up:

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

[metachris]

This looks great! 👍

Left a few minor comments, and needs a rebase. I think we might move the logic into it's own directory, like /proposerconfig, to keep things cleanly separated, and it's enough code to split up the entry and storage into separate files.

[jmcruz1983]

Any update here?

[ricardolyn]

it will be nice to have this ready for testing long before Mainnet as we need to prepare our staking platform for it. thank you :)

[metachris]

Started some simplifications here: https://github.com/flashbots/mev-boost/commit/00c4f8ad9df5121715bbd600fb7de490e8ba4565

A test fails and carrying the proposer pubkey into getPayload has an issue, but that's the general direction i'd like to move. Trying to simplify things a little.

Ideally the proposer config would be in it's own package rather than part of the server package, but i tried to extract it and it led to a huge refactoring which is too much (#270). Not sure if there's an easy and clean way to do this without more changes, i'm afraid of this PR getting too big then and unreviewable.

Sadly can't open a PR against this PR because it's in another repo where I don't have write access.

[metachris]

After consulting with @0xpanoramix we're closing this for now, and may revisit this feature again later on.

[metachris]

This feature adds extensive complexity around the choice of relays, and is impacting the getPayload calls significantly.

To get this feature over the line, a first step would be to refactor mev-boost to move common functionality into a common package, and then extract the config part into it's own package.

This PR gets a lot of things right, and much of it could be reused to implement this feature eventually.

If someone wants to pick this up, the effort would be supported.