-
Notifications
You must be signed in to change notification settings - Fork 876
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
QBFT + shanghai support #6353
QBFT + shanghai support #6353
Conversation
|
7bb70c0
to
c1f726f
Compare
consensus/ibft/src/main/java/org/hyperledger/besu/consensus/ibft/statemachine/IbftRound.java
Outdated
Show resolved
Hide resolved
...us/ibft/src/main/java/org/hyperledger/besu/consensus/ibft/statemachine/IbftRoundFactory.java
Outdated
Show resolved
Hide resolved
...ft/src/main/java/org/hyperledger/besu/consensus/ibft/validation/MessageValidatorFactory.java
Outdated
Show resolved
Hide resolved
0ba4bda
to
3e4e682
Compare
Signed-off-by: Matthew Whitehead <[email protected]>
3e4e682
to
7cd7178
Compare
Signed-off-by: Matthew Whitehead <[email protected]>
f73e9e0
to
8195395
Compare
Signed-off-by: Matthew Whitehead <[email protected]>
8195395
to
e08527b
Compare
Signed-off-by: Matthew Whitehead <[email protected]>
Signed-off-by: Matthew Whitehead <[email protected]>
7766e1a
to
8665212
Compare
…age validator creation Signed-off-by: Matthew Whitehead <[email protected]>
8665212
to
41ab356
Compare
Signed-off-by: Matt Whitehead <[email protected]>
Signed-off-by: Matthew Whitehead <[email protected]>
10fe48f
to
b9caf13
Compare
Signed-off-by: Matthew Whitehead <[email protected]>
*/ | ||
public ProtocolSpec getByBlockNumber(final long number) { | ||
public ProtocolSpec getByBlockNumberAndTimestamp(final long number, final long timestamp) { |
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 think this getting a protocol spec by either the block number or timestamp. Better name would be getByBlockNumberOrTimestamp
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.
Done - updated to getByBlockNumberOrTimestamp
@@ -312,6 +315,11 @@ private void importBlockToChain() { | |||
blockToImport.getHash()); | |||
} | |||
LOG.trace("Importing block with extraData={}", extraData); | |||
final BlockImporter blockImporter = | |||
((BftProtocolSchedule) protocolSchedule) | |||
.getByBlockNumberAndTimestamp( |
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 think this could just use protocolSchedule.getByBlockHeader(blockToImport.getHeader())
instead. It will look up protocol schedules by both block timestamps and block numbers.
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.
Fixed
|
||
final BlockValidator blockValidator = | ||
((BftProtocolSchedule) protocolSchedule) | ||
.getByBlockNumberAndTimestamp( |
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.
Similar to the IbftRound
I think you could use the existing protocolSchedule.getByBlockHeader
method here instead
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.
Fixed
@@ -342,6 +346,11 @@ private void importBlockToChain() { | |||
blockToImport.getHash()); | |||
} | |||
LOG.trace("Importing proposed block with extraData={}", extraData); | |||
final BlockImporter blockImporter = | |||
((BftProtocolSchedule) protocolSchedule) |
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.
Same in the IbftRound think we get away with using the protocolSchedule.getByBlockHeader method here
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.
Fixed
Signed-off-by: Matthew Whitehead <[email protected]>
Signed-off-by: Matt Whitehead <[email protected]>
Signed-off-by: Matthew Whitehead <[email protected]>
Signed-off-by: Matthew Whitehead <[email protected]>
Signed-off-by: Matthew Whitehead <[email protected]>
Thanks for the latest comments @jframe. I think the latest commits resolve them - let me know what you think. |
Signed-off-by: Matt Whitehead <[email protected]>
...nsus/ibft/src/main/java/org/hyperledger/besu/consensus/ibft/validation/MessageValidator.java
Outdated
Show resolved
Hide resolved
consensus/qbft/src/integration-test/resources/genesis_validator_contract_shanghai.json
Outdated
Show resolved
Hide resolved
...t/src/main/java/org/hyperledger/besu/consensus/qbft/validation/ProposalPayloadValidator.java
Outdated
Show resolved
Hide resolved
...sus/qbft/src/main/java/org/hyperledger/besu/consensus/qbft/validation/ProposalValidator.java
Show resolved
Hide resolved
...rc/main/java/org/hyperledger/besu/consensus/qbft/validation/RoundChangeMessageValidator.java
Show resolved
Hide resolved
Signed-off-by: Matthew Whitehead <[email protected]>
checkState( | ||
protocolSchedule instanceof BftProtocolSchedule, | ||
"Wrong class type for protocol schedule, requires BftProtocolSchedule"); |
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.
nit: don't need this check anymore
Signed-off-by: Matthew Whitehead <[email protected]>
PR description
Implement shanghai support for QBFT and IBFT chains.
Main areas of change:
QbftRound
/IbftRound
, since the next block number was known ahead of time. With number-based milestones such aslondon
this is fine, but with timestamp-based milestones the type of EVM to use for a new round needs to be based on the time that the block is being created. As such, in many places aprotocolSchedule
is now passed down the stack instead of ablockValidator
or ablockImporter
to allow these to be created using theprotocolSchedule
when the timestamp is known.BftProtocolSchedule
was only designed to allow a protocol spec to be requested by block number, so a new methodgetByBlockNumberAndTimestamp
that takes both the block number and timestamp has replacedgetByBlockNumber
, and determines the fork spec based on whichever milestone is most recent.I don't think any docs changes are required since we don't currently make any mention of
shanghai
in the docs today.Fixed Issue(s)
Fixes #5446