-
Notifications
You must be signed in to change notification settings - Fork 300
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
[Merge] Spec v1.1.1 adoption #4445
Conversation
return new ExecutionPayloadHeader( | ||
Bytes32.ZERO, | ||
Bytes20.ZERO, | ||
Bytes32.ZERO, | ||
Bytes32.ZERO, | ||
Bytes.wrap(new byte[SpecConfig.BYTES_PER_LOGS_BLOOM]), | ||
blockHash, | ||
UInt64.ZERO, | ||
UInt64.valueOf(genesisParams.genesisGasLimit), | ||
UInt64.ZERO, | ||
UInt64.valueOf(genesisParams.genesisTime), | ||
Bytes.EMPTY, | ||
Bytes32.rightPad( | ||
Bytes.ofUnsignedLong(genesisParams.genesisBaseFee, ByteOrder.LITTLE_ENDIAN)), | ||
blockHash, | ||
Bytes32.ZERO); |
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 a little surprised we don't wind up needing to get the genesis payload from the EL client. The genesis state root won't be zero for example. I suspect if all CL clients use the same values it probably works fine but it could cause confusion if these zero'd values are sent as part of messages to the EL client as they won't match what it expects.
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.
TBH I was thinking of passing EL http API address to retrieve the head block and make genesis execution payload from it, but it seemed a bit kind of overcomplicated to have a EL running for generating genesis.
We discussed with Mikhail about should we pass the full ExecutionPayloadHeader
for genesis mock
or just a couple of additional params (genesisGasLimit
and genesisBaseFee
) and fill other with zeroes. Other fields don't affect anything than genesis state hash root. So if you are doing standalone mocking you shouldn't care about those fields. If you are doing some kind of interop you may always pick the genesis.ssz
from the other party.
…nt/previousVersion
…nesis epoch both fork versions should be the same
# Conflicts: # ethereum/spec/src/main/java/tech/pegasys/teku/spec/config/SpecConfigBuilder.java # ethereum/spec/src/main/java/tech/pegasys/teku/spec/config/SpecConfigMerge.java # ethereum/spec/src/test/resources/tech/pegasys/teku/spec/config/invalid/invalidPreset_unknown.yaml # ethereum/spec/src/test/resources/tech/pegasys/teku/spec/config/invalid/invalidPreset_wrongType.yaml # ethereum/spec/src/test/resources/tech/pegasys/teku/spec/config/invalid/multifile_dupFields/config.yaml # ethereum/spec/src/test/resources/tech/pegasys/teku/spec/config/standard/mainnet.yaml # ethereum/spec/src/test/resources/tech/pegasys/teku/spec/config/standard/minimal.yaml # teku/src/integration-test/resources/tech/pegasys/teku/cli/subcommand/test-spec.yaml # util/src/main/resources/tech/pegasys/teku/util/config/configs/mainnet.yaml # util/src/main/resources/tech/pegasys/teku/util/config/configs/minimal.yaml # util/src/main/resources/tech/pegasys/teku/util/config/configs/prater.yaml # util/src/main/resources/tech/pegasys/teku/util/config/configs/pyrmont.yaml # util/src/test/resources/tech/pegasys/teku/util/config/invalid/invalidPresetType.yaml # util/src/test/resources/tech/pegasys/teku/util/config/invalid/unknownPreset.yaml
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.
LGTM
PR Description
Adopt Spec v1.1.1 changes:
GENESIS_GAS_LIMIT
&GENESIS_BASE_FEE_PER_GAS
constants--genesis-gas-limit
and--genesis-base-fee
CLI options when generatinggenesis mock
Fork
is scheduled for the genesis epoch use same value forcurrent/previousVersion
Fixed Issue(s)
Part of the #4226
Documentation
documentation
label to this PR if updates are required.Changelog