[SSZ] Are Lists limited to 0 values legal SSZ types?

[saltiniroberto]

List types limited to 0 values, i.e. List[type, 0], are not included in the list of illegal types in the SSZ specification.

However, line 177 of the py-ssz reference implementation, rules out LIst types limited to 0 values by requiring that the maximum length of homogenous composites must be at least 1.

[djrtwo]

I don't think these need to be strictly illegal, and in fact we used to have a type that was set to length 0 because it was essentially "disabled".

Using it as a "feature flag" of sorts is the main use case I can currently think of

[protolambda]

• 0-length vectors are illegal. (same for containers)
• 0-limit lists are legal.

The reasoning for the fixed-length types here is that fixed-length types do not have an offset if a dynamic type has a collection of them. Making it impossible to say how many there are: it's a scope / element_size = N / 0 case here.

However, lists will ALWAYS have an offset if any type wraps them, because they couldn't be presented otherwise (Well, except a list at top-most level type, which has a natural scope by input-length, e.g. a byte list doesn't have a length-encoding envelop in SSZ).

Besides, it is a previously used feature of configuring the lists of block-operations in the beacon block to have a 0 limit, to disable the use of that operation. Previously used in transfers. And currently we are considering disabling slashings in some testnets, as a fun way to stress the networks by publishing validator keys, and having everyone sign arbitrary things without retribution.

[hwwhww]

I think the spec is correct for flexible configuration as @protolambda mentioned, and py-ecc should be changed to follow the spec definition.

Opened an issue https://github.com/ethereum/py-ssz/issues/116

[protolambda]

I'm going to revisit the "new" (no changes, but more details) SSZ spec draft, and work on tests for a lot of these invalid/valid edge cases. :+1: