Update EIP-7495: Cleanup reference implementation and tests

EIPS/eip-7495.md

@@ -124,16 +124,21 @@ Merkleization `hash_tree_root(value)` of an object `value` is extended with:
 
 ### `Profile[B]`
 
-`Profile[B]` also defines an ordered heterogeneous collection of fields, a subset of fields of a base `StableContainer[N]` `B`.
-
-The rules for construction are:
+`Profile[B]` also defines an ordered heterogeneous collection of fields, a subset of fields of a base `StableContainer` type `B` with the following constraints:
 
 - Fields in `Profile[B]` correspond to fields with the same field name in `B`.
-- Fields in `Profile[B]` must be in the same order as in `B`
-- Fields in the base type `B` MAY be kept `Optional` in `Profile[B]`
-- Fields in the base type `B` MAY be required in `Profile[B]` by unwrapping them from `Optional`
-- Fields in the base type `B` MAY be omitted in `Profile[B]`, disallowing their presence in the sub-type
-- Fields in the base type `B` of type `Optional[T]` with `T` being a nested `StableContainer` MAY have types `Optional[Profile[T]]` (if kept optional), or `Profile[T]` (if it is required)
+- Fields in `Profile[B]` follow the same order as in `B`.
+- Fields in the base `StableContainer` type `B` are all `Optional`.
+  - Fields MAY be disallowed in `Profile[B]` by omitting them.
+  - Fields MAY be kept optional in `Profile[B]` by retaining them as `Optional`.
+  - Fields MAY be required in `Profile[B]` by unwrapping them from `Optional`.
+- All field types in `Profile[B]` MUST be compatible with the corresponding field types in `B`.
+  - Field types are compatible with themselves.
+  - `byte` is compatible with `uint8` and vice versa.
+  - `Bitlist[N]` / `Bitvector[N]` field types are compatible if they share the same capacity `N`.
+  - `List[T, N]` / `Vector[T, N]` field types are compatible if `T` is compatible and if they also share the same capacity `N`.
+  - `Container` / `StableContainer[N]` field types are compatible if all inner field types are compatible, if they also share the same field names in the same order, and for `StableContainer[N]` if they also share the same capacity `N`.
+  - `Profile[X]` field types are compatible with `StableContainer` types compatible with `X`, and are compatible with `Profile[Y]` where `Y` is compatible with `X` if also all inner field types are compatible. Differences solely in optionality do not affect merkleization compatibility.
 
 #### Serialization
 
@@ -205,7 +210,7 @@ Typically, the individual `Union` cases share some form of thematic overlap, sha
 
 Furthermore, SSZ Union types are currently not used in any final Ethereum specification and do not have a finalized design themselves. The `StableContainer[N]` serializes very similar to current `Union[T, U, V]` proposals, with the difference being a `Bitvector[N]` as a prefix instead of a selector byte. This means that the serialized byte lengths are comparable.
 
-### Why not a `Container` full of `Optional[T]`?
+### Why not model `Optional[T]` as an SSZ type?
 
 If `Optional[T]` is modeled as an SSZ type, each individual field introduces serialization and merkleization overhead. As an `Optional[T]` would be required to be ["variable-size"](https://github.com/ethereum/consensus-specs/blob/4afe39822c9ad9747e0f5635cca117c18441ec1b/ssz/simple-serialize.md#variable-size-and-fixed-size), lots of additional offset bytes would have to be used in the serialization. For merkleization, each individual `Optional[T]` would require mixing in a bit to indicate presence or absence of the value.