Add EIP: SSZ PartialContainer #7495
Conversation
github-actions
bot
added
c-new
|
✅ All reviewers have approved. |
eth-bot
added
e-consensus
| - The maximum capacity `N` does not change | ||
| - The order of fields within `T` does not change | ||
| - New fields are always added to the end of `T` | ||
| - Required fields of `T` remain required `E`, or become an `Optional[E]` |
There was a problem hiding this comment.
can this happen?: required => optional => required (and so on...) as this and below points imply infinite change
There was a problem hiding this comment.
Yes, a new fork could relax validity constraints, while a subsequent fork could require the field to be present again. Whether that makes sense is up to the application, but the serialization format proposed here will be stable across both directions (from optional to required and vice versa), essentially providing maximum flexibility when it comes to future design space.
In fact, an implementation could simply treat all fields as optional always, if they prefer to enforce constraints in the application layer instead of the serialization library. Another implementation may go the other direction and also push down an invariant callback to ensure that only valid combinations are accepted; e.g., a receipt can contain either an intermediate state root, or a status code, but not both at the same time. Yet another implementation may try to use union types to represent various valid combinations; point being is, none of these implementation details leak into the serialization representation.
There was a problem hiding this comment.
--> https://ethereum-magicians.org/t/eip-7495-ssz-partialcontainer/15476 is a better location for discussing technical points.
|
|
||
| ### What are the problems solved by `PartialContainer[T, N]`? | ||
|
|
||
| Current SSZ types are only stable within one version of a specification, i.e., one fork of Ethereum. This is alright for messages pertaining to a specific fork, such as attestations or beacon blocks. However, it is a limitation for messages that are expected to remain valid across forks, such as transactions or receipts. In order to support evolving the features of such perpetually valid message types, a new SSZ scheme needs to be defined. |
No description provided.