New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add capella hardfork and types #4568
Conversation
Performance Report✔️ no performance regression detected Full benchmark results
|
c850ac5
to
5161b99
Compare
@@ -36,6 +36,9 @@ export const chainConfig: IChainConfig = { | |||
// Bellatrix | |||
BELLATRIX_FORK_VERSION: b("0x02000000"), | |||
BELLATRIX_FORK_EPOCH: 144896, // Sept 6, 2022, 11:34:47am UTC | |||
// Capella | |||
CAPELLA_FORK_VERSION: b("0x03000000"), | |||
CAPELLA_FORK_EPOCH: Infinity, | |||
// Sharding | |||
SHARDING_FORK_VERSION: b("0x03000000"), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should not have the same fork_version
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Remove, SHARDING_* fields, no longer in upstream spec
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
should i rename them to EIP4844 something, thats what the new spec calls them
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
rebased/removed
}, | ||
altair: { | ||
BeaconBlockBody: altair.BeaconBlockBody, | ||
BeaconBlock: altair.BeaconBlock, | ||
SignedBeaconBlock: altair.SignedBeaconBlock, | ||
BeaconState: altair.BeaconState, | ||
Metadata: altair.Metadata, | ||
// Not used in altair but added for type consitency | ||
ExecutionPayload: bellatrix.ExecutionPayload, | ||
ExecutionPayloadHeader: bellatrix.ExecutionPayloadHeader, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
to be dropped after rebase right?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
i plan to move them to a separate allTypesExecution as some fork based usage is there
ba4dc64
to
90c80fb
Compare
withdrawableEpoch: FAR_FUTURE_EPOCH, | ||
effectiveBalance, | ||
slashed: false, | ||
fullyWithdrawnEpoch: FAR_FUTURE_EPOCH, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Note, this property is likely to be removed
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
awesome, will simplify processing deposits back to original, will comment it
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@dapplion should i remove this fullyWithdrawnEpoch
from here ?
* handle capella state upgrade case * fix more spec tests * lint params * add the new domain for constants check * rebase fixes
d557a64
to
d7ff4a0
Compare
|
||
// Union at the TreeViewDU level | ||
// - Works well as function argument and as generic type for allForks functions | ||
// | ||
// Quasy equivalent to | ||
// CompositeViewDU<typeof ssz.phase0.BeaconState | typeof ssz.altair.BeaconState | typeof ssz.bellatrix.BeaconState> | ||
export type BeaconStateAllForks = BeaconStatePhase0 | BeaconStateAltair | BeaconStateBellatrix; | ||
export type BeaconStateAllForks = BeaconStatePhase0 | BeaconStateAltair | BeaconStateBellatrix | BeaconStateCapella; | ||
export type BeaconStateExecutions = BeaconStateBellatrix | BeaconStateCapella; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Might call this BeaconStatePostMerge
(somehow easier than post-bellatrix) or BeaconStateWithExecution
or BeaconStateWithEL
. 🤷
We're probably going to have more types of beacon states over time with different capabilities, so maybe we can figure out a naming convention that can suit.
Just brainstorming:
Naming after fork:
BeaconStatePostB
- beacon states bellatrix and after
BeaconStatePostC
- beacon states capella and after
or
postBellatrix.BeaconState
, postCapella.BeaconState
Naming by capability:
BeaconStateWithExecution
- beacon states bellatrix and after
BeaconStateWithWithdrawals
- beacon states capella and after
thoughts?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
i like capability idea since that makes code more intutive 🙂
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Both BeaconStatePostBellatrix or BeaconStateWithExecution sound good
Add capella hardfork and types
Dependent on
base is set master to run the github workflows
Part of