Remove fork_version from LightClientUpdate
#2916
Conversation
The `fork_version` field in `LightClientUpdate` can be derived from the `update.signature_slot` value by consulting the locally configured fork schedule. The light client already needs access to the fork schedule to determine the `GeneralizedIndex` values used for merkle proofs, and the memory layouts of the structures (including `LightClientUpdate`). The `fork_version` itself is network dependent and doesn't reveal that info.
tests/core/pyspec/eth2spec/test/altair/unittests/test_sync_protocol.py
Outdated
Show resolved
Hide resolved
|
iirc having the imagine there is some relayer node that does not have a locally configured fork schedule, they can still determine if this is a valid update or not (and hence to pass along or not) but it requires having the fork version to compute the right domain note this "relayer" could even be a smart contract where its better UX to not need to also bring along a fork schedule as ambient knowledge |
|
I think having the update self-contained wrt verification doesn't buy us much here. I'd argue that there is already ambient knowledge required in the current protocol, which amounts to knowing the config+preset, genesis values, and having fork awareness of the beacon state layout. So if we can derive the fork schedule from the config, we're not really requiring additional knowledge. Also would mention that the sync spec gives just one possible concrete protocol for syncing, but different relayers/consumers will have different requirements. The protocol likely doesn't need to support the lowest-common-denominator, but rather to just support the simplest approach. |
It is not self-contained, if you think about future forks that may change the The "relayer" could also just re-add the fork version if its consumers depend on it (and would likely also have to add more metadata than just that). |
There was a problem hiding this comment.
LGTM
@ralexstokes @wemeetagain
Do people still have objections? Please let us know. :)
|
|
||
| @with_all_phases | ||
| @spec_state_test_with_matching_config | ||
| def test_override_config_fork_epoch(spec, state): |
There was a problem hiding this comment.
very thoughtful @etan-status 👍
The
fork_versionfield inLightClientUpdatecan be derived from theupdate.signature_slotvalue by consulting the locally configured forkschedule. The light client already needs access to the fork schedule to
determine the
GeneralizedIndexvalues used for merkle proofs, and thememory layouts of the structures (including
LightClientUpdate). Thefork_versionitself is network dependent and doesn't reveal that info.