ethereum-consensus icon indicating copy to clipboard operation
ethereum-consensus copied to clipboard

`ssz_rs` type constraints are not expressive enough when defining spec containers

Open ralexstokes opened this issue 3 years ago • 0 comments

Consider the current definition of a field like previous_epoch_attestations from the BeaconState:

https://github.com/ralexstokes/ethereum_consensus/blob/main/src/phase0/beacon_state.rs#L40

    previous_epoch_attestations: List<PendingAttestation, PENDING_ATTESTATIONS_BOUND>,

The List type from ssz_rs was defined with a const generic parameter of type usize to specify the bound on this SSZ list at the type-level. However, the spec defines constants like SLOTS_PER_EPOCH (which is used to compute PENDING_ATTESTATIONS_BOUND here) as a uint64 (with Rust type u64).

We get a compiler error if we try to use this type directly and I don't think const generics are expressive enough at the moment to express multiple types or some kind of trait bound (e.g. some Number trait that could cover both usize and u64).

This difference doesn't amount to much as we expect to run this code on platforms where usize is in fact the same size of u64 but it would be nice to conform to the spec where possible. I've gone ahead and simply defined the involved constants as usize but if anyone has any ideas on how to patch over this, it would be appreciated!

ralexstokes avatar Oct 30 '21 21:10 ralexstokes