Dev/test option for short BFT block periods#7588
Merged
matthew1001 merged 8 commits intobesu-eth:mainfrom Sep 20, 2024
Merged
Conversation
Signed-off-by: Matthew Whitehead <matthew1001@gmail.com>
Signed-off-by: Matthew Whitehead <matthew1001@gmail.com>
Signed-off-by: Matthew Whitehead <matthew1001@gmail.com>
matthew1001
changed the title
jframe
reviewed
Sep 12, 2024
consensus/common/src/main/java/org/hyperledger/besu/consensus/common/bft/BlockTimer.java
Outdated
Show resolved
Hide resolved
| this.queue = queue; | ||
| this.bftExecutors = bftExecutors; | ||
| this.currentTimerTask = Optional.empty(); | ||
| this.baseExpiryMillis = baseExpirySeconds * 1000; |
Contributor
There was a problem hiding this comment.
If the baseExpiryMillis type was changed to a duration, then we could handle both milliseconds and seconds without any special logic
...g/hyperledger/besu/ethereum/mainnet/headervalidationrules/TimestampMoreRecentThanParent.java
Outdated
Show resolved
Hide resolved
Contributor
Author
|
Thanks for the comments @jframe, agree with you on all counts. I'll update the PR shortly |
…ption Signed-off-by: Matthew Whitehead <matthew1001@gmail.com>
Contributor
Author
|
I've done some refactoring to the PR as follows:
|
Contributor
Author
|
Thanks for the comments @jframe See the latest commit & comment which hopefully resolves your comments |
Signed-off-by: Matthew Whitehead <matthew1001@gmail.com>
jframe
approved these changes
Sep 20, 2024
Wolmin
pushed a commit
to lukso-network/network-besu
that referenced
this pull request
Sep 27, 2024
* Dev mode for short BFT block periods Signed-off-by: Matthew Whitehead <matthew1001@gmail.com> * Refactoring Signed-off-by: Matthew Whitehead <matthew1001@gmail.com> * Fix comment Signed-off-by: Matthew Whitehead <matthew1001@gmail.com> * Refactor to make BFT block milliseconds an experimental QBFT config option Signed-off-by: Matthew Whitehead <matthew1001@gmail.com> * Update Json BFT config options Signed-off-by: Matthew Whitehead <matthew1001@gmail.com> --------- Signed-off-by: Matthew Whitehead <matthew1001@gmail.com> Signed-off-by: Wolmin <lamonos123@gmail.com>
This was referenced Oct 5, 2024
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
PR description
This is a test-only option to mine BFT blocks more quickly than once a second.
It is not designed to be used in production and I've added warnings to the logs when it is set.
The reason for adding it is for Web3 frameworks wanting to run tests against a Besu node, possibly as part of a CI/CD pipeline, where lots of transactions & receipts need round-tripping during the test. 1 second block periods mean a test could take a very long time to complete.
I've tested it down to
50msblocks and a single node is stable enough to mine transactions into blocks at that speed. I've also tested it in conjunction with draft PR #6965 withemptyblockperiodsecondsset to 10s (so while the test isn't driving TXN traffic Besu isn't spinning creating huge numbers of empty blocks) and the two work fine together - see the following logs with300msblocks: