per-validator suggested fee recipients

[tersec]

Inspired by https://lighthouse-book.sigmaprime.io/suggested-fee-recipient.html (--suggested-fee-recipient-file and the file format).

[zah]

I was thinking that we can store the fee recipient metadata within the validator directories (one file per validator) or more generally to treat the configuration as a set of database entries instead of it being a configuration file. I have two rationales for this:

1. It should be easy to change the fee recipient using the REST API (this is standardized in the Keymanager API).
2. Providing a command-line interface for the feature would be more user-friendly than describing a file format (we'll also have GUI for it in the future).

[jclapis]

The Rocket Pool stack is currently designed around this Lighthouse model, where there is a file that specifies the default fee recipient for all validators and then has individual overrides per pubkey. Lighthouse also reloads this file and updates itself every time it proposes a block, which is extremely helpful and highly desirable for us. Teku and Prysm use a similar approach, though they both share the same JSON spec for this file rather than have their own custom formats like Lighthouse.

[github-actions]

Unit Test Results

     12 files  ±0     842 suites  ±0   57m 3s ⏱️ - 3m 53s
1 699 tests ±0  1 647 ✔️ ±0    52 💤 ±0  0 ❌ ±0 
9 893 runs  ±0  9 765 ✔️ ±0  128 💤 ±0  0 ❌ ±0 

Results for commit 10079f8. ± Comparison against base commit faf4d4a.

♻️ This comment has been updated with latest results.

[tersec]

I was thinking that we can store the fee recipient metadata within the validator directories (one file per validator) or more generally to treat the configuration as a set of database entries instead of it being a configuration file.

b57eaa3

[arnetheduck]

shouldn't we have the same for graffiti?