-
Notifications
You must be signed in to change notification settings - Fork 977
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
Parent root reconstruction + granular state roots + body/header segregation #649
Conversation
(Draft—don't merge yet. Thanks to @vbuterin for pushing to remove the `Proposal` object and for @djrtwo for taking down past proposals.) Main feature: The state transition function now only depends on the current `BeaconState` and the latest `BeaconBlock`. (As opposed to also requiring `previous_block_root` to populate `latest_block_roots`.) **Cleanups** * Removed `Proposal`, `BeaconBlockBody`, `BEACON_CHAIN_SHARD_NUMBER`. * More consistent signature verification handling of beacon blocks (now done via a `BeaconBlockMetadata` object which also avoids the duplication of `signature` and `slot` across multiple objects). * Be explicit about per-block `block_root` checks. * Reworked the section on the genesis block and state for clarity. * Misc fixes along the way (e.g. missing `transfers=[]` in the genesis block). Todo: Is `genesis_eth1_data` defined properly?
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'm finding the slot processing section difficult to understand/debug. Made a few comments/questions to start.
also, once we get this phase 0 doc locked down, I'll clean up the validator doc before mergning
Co-Authored-By: JustinDrake <drakefjustin@gmail.com>
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.
No quite sold yet 😬
comments/questions below
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.
Sorry for that I didn’t follow this PR these days! High-level quick recap:
Before this PR:
- On genesis:
- Use Eth1 chain logs to generate genesis state.
- Use
genesis_state
to generategenesis_block
.
- Start from
(genesis_block, genesis_state)
. - If slot 1 is not skipped:
state_transition_function(genesis_state, block_1, previous_block_root) -> state_1
- If slot 1 is skipped:
per_slot_transition(genesis_state, previous_block_root) -> state_1
After this PR:
- On genesis:
- Use empty block + Eth1 chain logs to generate
genesis_state
. - Use
genesis_state
to generategenesis_block
.
- Use empty block + Eth1 chain logs to generate
- Start from S:
(genesis_block, genesis_state)
.state.latest_block_header
is the empty block header, and will track the last block header.
- If slot 1 is not skipped:
state_transition_function(genesis_state, block_1) -> state_1
- If slot 1 is skipped:
per_slot_transition(genesis_state) -> state_1
We gain:
- Parent root reconstruction
- Granular state roots
- Body/header segregation
And, extra costs
- Two more fields in
BeaconState
:latest_block_header: BeaconBlockHeader
historical_batchings: ['bytes32']
, wherehistorical_batchings
is an unlimited size list contains8192
slots/per log.
Is that correct? Is there any other extra cost that we should consider?
Co-Authored-By: JustinDrake <drakefjustin@gmail.com>
Yes! :) |
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.
Some brief comments/questions. Close to merge time
Co-Authored-By: JustinDrake <drakefjustin@gmail.com>
Co-Authored-By: JustinDrake <drakefjustin@gmail.com>
@djrtwo Can we just do |
close in favor of #711 |
This PR introduces three significant changes:
state
and (latest)block
.Proposal
and related things.