-
Notifications
You must be signed in to change notification settings - Fork 998
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
initialize_beacon_state_from_eth1 for pre-transition merge #2640
Conversation
bea4b3c
to
af262be
Compare
6b95a5b
to
34fd3ef
Compare
34fd3ef
to
789eea0
Compare
@@ -17,7 +19,7 @@ def eth1_init_data(eth1_block_hash, eth1_timestamp): | |||
} | |||
|
|||
|
|||
@with_merge_and_later | |||
@with_phases([MERGE]) |
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 changed it to @with_phases([MERGE])
because I think for the subsequent forks, the execution_payload_header
field would be required?
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 personally think the transition logic might just stay in there, but we can debate it further down the line
dd82ba3
to
e235aa8
Compare
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 cleaned up the tests & testgen. I've tested that I can generate the new test vectors successfully.
Signing my approval now so that you can review & merge. :)
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.
Looks good to me! 👍
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.
Thank you @hwwhww !!
@@ -17,7 +19,7 @@ def eth1_init_data(eth1_block_hash, eth1_timestamp): | |||
} | |||
|
|||
|
|||
@with_merge_and_later | |||
@with_phases([MERGE]) |
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 personally think the transition logic might just stay in there, but we can debate it further down the line
|
||
```python | ||
def initialize_beacon_state_from_eth1(eth1_block_hash: Bytes32, | ||
eth1_timestamp: uint64, | ||
deposits: Sequence[Deposit]) -> BeaconState: | ||
deposits: Sequence[Deposit], | ||
execution_payload_header: ExecutionPayloadHeader=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.
Why do we still need eth1_block_hash
& eth1_timestamp
? They should be both in the passed execution_payload_header
initialize_beacon_state_from_eth1
on the Merge fork should work for two cases:(2) is very valuable for testnets that are built to test the merge transition logic
TODO: