feat(contracts): registry updates

[mempirate]

• Closes feat(contracts): add RPC in operator registration #252
• Closes Holesky deployment plan #273

[merklefruit]

small nits, overall I love the design and how much it simplifies our current middlewares. great!

[thedevbirb]

Amazing work! Just some notes

[thedevbirb]

Just one performance consideration: we're already concerned about the gas usage of the challenger and while some of these variables should be upgradable, some of them instead are pretty much known and immutable once the contract has been deployed.
In particular those are the ones that don't require an admin method:

• EPOCH_DURATION
• SLASHING_WINDOW
• ETH2_GENESIS_TIMESTAMP
• SLOT_TIME.
  These are used in the Challenger contract via a static call that consumes more gas than it should. I'd personally prefer rely on those via a library whose constant values are set manually before deploying. Ugly yes, but we can get around it with a script reminding us to do that before deploying.

[merklefruit]

One note is that gas usage in the challenger is way less of a concern than the registry.

I think this is fine as is for this use case.

fwiw, there is much lower hanging fruit for optimizing the opening / resolution process than this, so I suggest leaving it here as it makes the whole deployment simpler!

[mempirate]

Good point. My thinking was that other contracts might also need these values, but we can have a BoltConstants library per network (mainnet, holesky, helder, ...) that we can just use in all those contracts. Will update!

[merklefruit]

Looking very good!

[merklefruit]

note: when counting storage layout, each variable should be counted for the amount of storage it uses.
In this case, EnumerableSet.Bytes32Set is defined as Set under the hood:

    struct Set {
        bytes32[] _values;
        mapping(bytes32 value => uint256) _positions;
    }

this occupies 2 slots: 1 for the array (pointer to its mem address) and 1 for the mapping.
reference: https://docs.soliditylang.org/en/latest/internals/layout_in_storage.html#mappings-and-dynamic-arrays

so TL;DR: storage layout marker would be 4 instead of 3 slots here. I didn't check other contracts but this is a good check to make everywhere

[mempirate]

Good catch

[mempirate]

Validated all storage layouts with forge inspect BoltParameters storage-layout --pretty

Added instructions on how to do it in the contract natspec documentation. The OpenZeppelin foundry upgrades toolkit can also validate it every time we do a new deployment.

[merklefruit]

LGTM