Add EIP: Forward compatible consensus data structures #8439
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
✅ All reviewers have approved. |
eth-bot
added
e-consensus
etan-status
force-pushed
the
sz-consensus
branch
2 times, most recently
from
0876895
to
f33acc9
Compare
etan-status
changed the title
|
The commit f33acc9 (as a parent of 115a964) contains errors. |
abcoathup
reviewed
Apr 16, 2024
EIPS/eip-####.md
Outdated
| @@ -0,0 +1,291 @@ | |||
| --- | |||
There was a problem hiding this comment.
Suggested change
| --- | |
| --- | |
| eip: 7688 |
Assigning next sequential EIP/ERC/RIP number.
Please also update the filename.
abcoathup
reviewed
Apr 16, 2024
EIPS/eip-####.md
Outdated
| title: Forward compatible consensus data structures | ||
| description: Transition consensus SSZ data structures to StableContainer | ||
| author: Etan Kissling (@etan-status) | ||
| discussions-to: https://ethereum-magicians.org/t/eip-forward-compatible-consensus-data-structures/19673 |
There was a problem hiding this comment.
Suggested change
| discussions-to: https://ethereum-magicians.org/t/eip-forward-compatible-consensus-data-structures/19673 | |
| discussions-to: https://ethereum-magicians.org/t/eip-7688-forward-compatible-consensus-data-structures/19673 |
etan-status
force-pushed
the
sz-consensus
branch
from
f33acc9
to
32b0a49
Compare
github-actions
bot
added
c-new
gaudren
approved these changes
Apr 16, 2024
Co-authored-by: Nikki Gaudreau <[email protected]>
Co-authored-by: Nikki Gaudreau <[email protected]>
wemeetagain
reviewed
Apr 30, 2024
EIPS/eip-7688.md
Outdated
| For each converted data structure, a new `StableContainer` type `S` is introduced that serves as the primary definition of each data structure. | ||
|
|
||
| - Each `StableContainer` is assigned a capacity to represent its potential design space that SHALL NOT change across future forks; if it is later determined that it is insufficient, a new field can be added to contain additional fields in a sub-container. | ||
| - The historical forks are examined and fields that have not been present in all forks are marked as `Optional` in the new `StableContainer` type. |
There was a problem hiding this comment.
I think this might be a little confusing (and not particularly useful) considering we don't have backwards compatibility to forks before the conversion. IMO its just easier to make all fields non-optional when considering historical forks (before conversion).
| - To guarantee forward and backward compatibility, new fields from future forks MUST be appended to the end of the `StableContainer` definition. Existing fields MAY be converted to `Optional`. | ||
|
|
||
| Furthermore, a `Variant` type is defined that is specific to the fork at which the conversion is applied. This `Variant` is the equivalent of the legacy `Container` type, except that it inherits from `Variant[S]`. The SSZ serialization of `Variant` is compatible with `Container`, but the merkleization and `hash_tree_root` are computed differently. Furthermore, `Variant` MAY use fields of `Optional` type if necessary. | ||
|
|
There was a problem hiding this comment.
You might mention that a new Variant will be defined for every additional fork as needed, as fields are added or removed.
EIPS/eip-7688.md
Outdated
|
|
||
| Furthermore, a `Variant` type is defined that is specific to the fork at which the conversion is applied. This `Variant` is the equivalent of the legacy `Container` type, except that it inherits from `Variant[S]`. The SSZ serialization of `Variant` is compatible with `Container`, but the merkleization and `hash_tree_root` are computed differently. Furthermore, `Variant` MAY use fields of `Optional` type if necessary. | ||
|
|
||
| libp2p topics still exchange fork specific `Variant` definitions using the same serialization as the legacy `Container` type. Only merkleization and `hash_tree_root` are computed differently. |
There was a problem hiding this comment.
Not just libp2p, but all processing will be done with Variants, right? For spec purposes, just for better type safety.
g11tech
reviewed
May 1, 2024
There was a problem hiding this comment.
looks great, lemme know once suggestions by @wemeetagain are incorporated, will approve the draft
Co-authored-by: Cayman <[email protected]>
Co-authored-by: Cayman <[email protected]>
Co-authored-by: Cayman <[email protected]>
Co-authored-by: Cayman <[email protected]>
g11tech
reviewed
May 2, 2024
Co-authored-by: g11tech <[email protected]>
eth-bot
approved these changes
May 5, 2024
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
No description provided.