Context
Summit's consensus state stores validator accounts and scheduled validator additions in keyed collections. The keys are consensus-relevant: validator-account keys identify the node public key the account belongs to, and added_validators keys identify the epoch when a scheduled activation should be applied.
The SSZ state tree is used to produce state roots and membership proofs for downstream consumers. Its normal invariant should be that a proof binds both a collection value and the key that gives that value consensus meaning.
Claim
The SSZ tree commits keyed consensus collections as value-only lists, so validator-account and scheduled-activation proofs bind values without binding their node-pubkey or epoch keys.
A malicious SSZ proof or state-root producer can present a state variant where a validator account or scheduled validator addition has a different map key but the committed value sequence is unchanged; because the SSZ tree commits only the keyed collection values, the producer presents the same root for semantically different consensus states and misbinds proofs about validator accounts or activation epochs.
Flow
- A proof or state-root producer starts from consensus state containing
validator_accounts or added_validators.
- The canonical consensus-state codec treats the map keys as part of the serialized state, but the SSZ tree rebuild uses only the ordered values.
- The producer can change a validator-account key or scheduled-activation epoch while preserving the value-only positional tree content.
- The resulting SSZ root and proof branch remain valid for the value, but the root does not authenticate the key that gives the value its consensus meaning.
Impact
External proof consumers cannot authenticate "this account belongs to pubkey X" or "this activation is for epoch E" from the state root alone. This is distinct from pending-execution-request root omission: these collections are included, but their keys are not.
Root Cause
The SSZ tree models keyed maps as value-only positional lists, while the canonical storage codec treats the keys as consensus state data.
Code
Related Issues/PRs
Related issues cover adjacent keyed collection, validator-key, state-proof, and SSZ root omissions that can weaken identity or proof binding.
Fix
Merkleize keyed collections as key/value pairs or sparse maps, not value-only lists. Include validator node pubkeys in validator-account leaves or proof paths, include added_validators epoch keys in the committed structure, and add tests that change only a map key or scheduled epoch and assert the SSZ state root changes.
Context
Summit's consensus state stores validator accounts and scheduled validator additions in keyed collections. The keys are consensus-relevant: validator-account keys identify the node public key the account belongs to, and
added_validatorskeys identify the epoch when a scheduled activation should be applied.The SSZ state tree is used to produce state roots and membership proofs for downstream consumers. Its normal invariant should be that a proof binds both a collection value and the key that gives that value consensus meaning.
Claim
The SSZ tree commits keyed consensus collections as value-only lists, so validator-account and scheduled-activation proofs bind values without binding their node-pubkey or epoch keys.
A malicious SSZ proof or state-root producer can present a state variant where a validator account or scheduled validator addition has a different map key but the committed value sequence is unchanged; because the SSZ tree commits only the keyed collection values, the producer presents the same root for semantically different consensus states and misbinds proofs about validator accounts or activation epochs.
Flow
validator_accountsoradded_validators.Impact
External proof consumers cannot authenticate "this account belongs to pubkey X" or "this activation is for epoch E" from the state root alone. This is distinct from pending-execution-request root omission: these collections are included, but their keys are not.
Root Cause
The SSZ tree models keyed maps as value-only positional lists, while the canonical storage codec treats the keys as consensus state data.
Code
ConsensusStatestoresvalidator_accountsasBTreeMap<[u8; 32], ValidatorAccount>andadded_validatorsasBTreeMap<u64, Vec<AddedValidator>>: https://github.com/SeismicSystems/summit/blob/ed2c5c8/types/src/consensus_state.rs#L28.added_validatorsepoch keys before their vectors: https://github.com/SeismicSystems/summit/blob/ed2c5c8/types/src/consensus_state.rs#L1028.accounts.values()and merkleizes account fields, not the[u8; 32]map key: https://github.com/SeismicSystems/summit/blob/ed2c5c8/types/src/ssz_state_tree.rs#L265, https://github.com/SeismicSystems/summit/blob/ed2c5c8/types/src/ssz_state_tree.rs#L278.ValidatorAccount::hash_tree_rootomits the node pubkey/map key: https://github.com/SeismicSystems/summit/blob/ed2c5c8/types/src/ssz_hash.rs#L121.SszProofcontains onlygindex,leaf, andbranch, with no committed key path: https://github.com/SeismicSystems/summit/blob/ed2c5c8/types/src/ssz_state_tree.rs#L1545.added_validatorsvalues and mixes only item count/root, not epoch keys: https://github.com/SeismicSystems/summit/blob/ed2c5c8/types/src/ssz_state_tree.rs#L805, https://github.com/SeismicSystems/summit/blob/ed2c5c8/types/src/ssz_state_tree.rs#L835.Related Issues/PRs
Related issues cover adjacent keyed collection, validator-key, state-proof, and SSZ root omissions that can weaken identity or proof binding.
Fix
Merkleize keyed collections as key/value pairs or sparse maps, not value-only lists. Include validator node pubkeys in validator-account leaves or proof paths, include
added_validatorsepoch keys in the committed structure, and add tests that change only a map key or scheduled epoch and assert the SSZ state root changes.