Hey, leaving some feedback on this EIP!
I’ve built a few beacon chain proof verifier implementations in Solidity at EigenLayer, so I was initially excited to hear about a stable, forward-compatible merkleization scheme. When a hard fork changes beacon state containers, this almost always means we need to perform a smart contract upgrade to remain compatible - and it would be nice to lessen that load. However, after reviewing EIP-7688, I’m less convinced that this EIP would be useful for us in the short term.
From what it sounds like, a big part of this change involves:
- Making certain type definitions immutable (for example, the
Validatorcontainer, which we definitely care about) - Deciding on an upper bound on the capacity of certain types
… and the point of these changes is that if we ever need to, say, add more fields to the Validator container, we would need to define a new field outside of the Validator container to hold those fields. So I’m picturing a new field in BeaconState called validators_extended or something, that maps 1:1 with the validators in the standard validators field, but contains the data in these new fields.
If that’s roughly correct, I’d like to point out that the merklization changes we need to make to accommodate forks is actually on the lighter end of fork compatibility efforts. The harder stuff to account for tends to be changes in field semantics — or, changes to how the beacon chain fundamentally runs/processes operations.
As an example:
EIP-7251 changes how deposits are applied on the beacon chain by introducing pending balance deposits. Due to this change, processed deposits now register new validators on the beacon chain with a zero balance and create a pending balance deposit, which gets processed once per epoch to credit the deposit amount to the validator’s balance. This means there is now a period of time (>= 1 epoch) when newly-registered validators will have a zero balance.
If I understand EIP-7688 correctly, nothing in these changes would be prevented by forward-compatible merklization. This is introducing some new “pending_x” fields, and changing the semantics of how deposits are applied. However for us, this is actually a fairly annoying change to deal with - because:
- We’ve been accepting proofs that a validator’s withdrawal credentials are tied to an
EigenPodregardless of their current balance - We have followup proofs after withdrawal credentials are verified that assume a validator is fully withdrawn if they have a current balance of 0
Merkleization changes, on the other hand, are fairly minor changes to our on-chain/off-chain proofs libraries.
So to sum this up — I’m not convinced EIP-7688 would actually help us much, because we’re going to need to make compatibility changes to account for changing beacon chain semantics (regardless of merklization). Fundamentally, changes to the beacon chain spec will end up breaking us in some way, and merkleization specifically is extremely easy to deal with compared to the major semantic changes that tend to come with hard forks.
And if my understanding of 7688 is correct, the way you make changes to beacon chain fields in the future would be significantly more restricted, and possibly messier. I’m picturing something like “ah yes we deprecated Validator.effective_balance, you have to use Validator_Extension.new_effective_balance, instead, because we’re storing effective balances in wei now” 
On our end supporting this hypothetical change, it doesn’t matter that the merkleization of Validator.effective_balance is unchanged - because we now need to combine our existing Validator proofs with a secondary proof to validate this new field in Validator_Extension. Ultimately all this would really accomplish for us is doubling the gas cost to verify Validator-related proofs.
I would almost rather yall just change the semantics of Validator.effective_balance (though I shudder to think how we’d accommodate something like that!)