Closed jframe closed 3 weeks ago
GoQuorum implementation https://github.com/ConsenSys/quorum/pull/1433
Any update on when this might get implemented in Besu?
Please solve this one, it would help many people.
It's a really necessary feature and it will helps to save memory!
@siladu - status on PR ?
@siladu - status on PR ?
@non-fungible-nelson We had to pause it to prioritise Withdrawals/Shanghai
@siladu Is there any prevision about that?
Discussed with @siladu and I'm going to work on progressing the existing PR to see how far this is from being closeable.
are there any updates on this as it's now implemented for Clique https://github.com/hyperledger/besu/pull/6082 ?
I've not moved it along much as I've been focusing on other bug fixes & features that have taken priority. Working on https://github.com/hyperledger/besu/issues/5446 has helped get me into the BFT code more than I have before, so this might be a natural thing for me to pick up again once that PR is over the line but happy if someone else wants to pick up the empty block work in the mean time.
For now I'll remove my name from it, but will add it back once I'm actively working on it again.
Hi @matthew1001, I actually spent some time last weekend looking at some relevant parts of the code, in a discussion on the besu channel I said l may be able to help but then I didn't knew this issue was already created. So if I can help in any way I'll have some time to do it both off and on my working hours... 😃
I haven't spent time on this feature recently so if you're interested in contributing then that would be great. You could start by looking at https://github.com/hyperledger/besu/pull/4634 which was a draft, WIP PR by @siladu. I'm not expecting to have time to work on it in the near future.
Hi, yes I downloaded @siladu code, unfortunately I have to work with it on a very low end personal laptop but I'll do my best 😃.
Thank you guys...
Guys, I do now have an initial working version (untested and very basic) that I plan to put on a draft PR for review ASAIC, I'm actually eager to do it but even if I started doing this personally now I learned that my employer is actually a Hyperleger Foundation contributor, so now I'm doing it under their umbrella. That means I have to wait for their approvals which I expect will be early next week... 😀
It's based on the previous work by @siladu, so my kudos to him...
@amsmota I've updated the description with some more background details and the specification of the proposed solution. This is what both my implementation and the GoQuorum one are based on.
Note, this could be implemented for IBFT2 as well, but for now I would recommend only attempting to update QBFT. If someone wants to extend this to IBFT2 they can do that themselves or make a case for it. The scope of this issue was only intended to be QBFT and better to keep the changes as small as possible.
Hi, thanks for that. I'm still waiting for the authorization of my firm to be able to push what I have, it was working quite fine untilnow that I started to implement the support for transitions. It's quite complex because the blockTimer is started before the block is created so by that time the timer doesn't know if the block is empty or not. Yesterday I think I achieve that but couldn't test it yet. But I had to comment out the TimestampMoreRecentThanParent because of that too.
Just to clarify the emptyBlockPeriodSeconds is already implemented and working in the Fork and Options, including the Mutable ones, it's just that for now I can't test the empty/non-empty scenarios but because of code unrelated issues...
I'll let you know how it goes...
Well, I think this is almost done, I tested today the blockperiod/emptyblockperiod before and after a transition and it looks fine, but my tests were not very reliable due to the environment I'm using. I did quite a few changes, the most noticeable in the BlockTimer, I kind of moved the responsability of calculating those values from the QbftBlockHeightManager to it.
Anyway I got the approval from my company so I'll be able to create PR for review soon...
Cheers.
Guys, I just pushed my changes to our internal fork of Besu, so one last approval and I'll be able to push it to the main repo. One word of caution, I can't guarantee everything is OK, I had to do all the development on top of 23.10.2 due to several restrictions and copy&paste the changes to the main branch as of today. In a few hours I will be able to build and test this version.
The better part of the code was based on @siladu code, I've tried to limit my changes to the minimum possible and by adding code, not rewrite existing one, wherever possible. One big exception was commenting out the TimestampMoreRecentThanParent
validation rule. The core functionality was done on QbftBlockHeightManager
and the BlockTimer
. There is some code duplication there, it can be easily changed but I didn't want to change the previous implementation and it actually looks more clear that way.
And this is still a DRAFT version for review, I still have to do the unit tests and the like...
I hope I can push as soon as possible, but as a overview below are the classes the were changed. Note that whenever possible I changed the Bft classses, meaning it can probably be used by the Ibft code as well.
- besu/src/main/java/org/hyperledger/besu/controller/QbftBesuControllerBuilder.java
- config/src/main/java/org/hyperledger/besu/config/BftConfigOptions.java
- config/src/main/java/org/hyperledger/besu/config/BftFork.java
- config/src/main/java/org/hyperledger/besu/config/JsonBftConfigOptions.java
- consensus/common/src/main/java/org/hyperledger/besu/consensus/common/bft/BlockTimer.java
- consensus/common/src/main/java/org/hyperledger/besu/consensus/common/bft/MutableBftConfigOptions.java
- consensus/qbft/src/main/java/org/hyperledger/besu/consensus/qbft/QbftBlockHeaderValidationRulesetFactory.ja
- consensus/qbft/src/main/java/org/hyperledger/besu/consensus/qbft/QbftForksSchedulesFactory.java
- consensus/qbft/src/main/java/org/hyperledger/besu/consensus/qbft/statemachine/QbftBlockHeightManager.java
- consensus/qbft/src/main/java/org/hyperledger/besu/consensus/qbft/statemachine/QbftRound.java
Any question or suggestion please let me know.
Cheers.
Could you open a PR on the main repo so we can more easily review your code and test it against our test suite?
Hi, sorry for the delay, I'm still waiting for my manager's approval, which will be no later than this Friday. I'll do it right after it.
Cheers.
Hi, sorry for the delay, I'm still waiting for my manager's approval, which will be no later than this Friday. I'll do it right after it.
Cheers.
Any update, I have looked into this issue for a while.
I'm still waiting for my manager approval on our own PR, there was a internal peer-review that is done by now, I hope it'll be approved soon so I can do the PR to the Hyperledger Besu for review too... I'll post here as soon as I do it...
On Tue, Mar 19, 2024, 02:57 MASDXI @.***> wrote:
Hi, sorry for the delay, I'm still waiting for my manager's approval, which will be no later than this Friday. I'll do it right after it.
Cheers.
Any update, I have looked into this issue for a while.
— Reply to this email directly, view it on GitHub https://github.com/hyperledger/besu/issues/3810#issuecomment-2005655463, or unsubscribe https://github.com/notifications/unsubscribe-auth/AB3UF3LPKGKCO2RCP5CLSGLYY6SQHAVCNFSM5VPXNU2KU5DIOJSWCZC7NNSXTN2JONZXKZKDN5WW2ZLOOQ5TEMBQGU3DKNJUGYZQ . You are receiving this because you were mentioned.Message ID: @.***>
Guys, I'm completely blocked here, I need to run Besu with my code thru a Jenkins pipeline and all the checks it contains, this is a mandatory step for me. The build runs fine on my local computer, but in a java-gradle-build in the pipeline it ends with this strange error
FAILURE: Build failed with an exception.
- What went wrong: Gradle build daemon disappeared unexpectedly (it may have been killed or may have crashed)
- Exception is: org.gradle.launcher.daemon.client.DaemonDisappearedException: Gradle build daemon disappeared unexpectedly (it may have been killed or may have crashed)
Googling for it almost all replies say it has to do with memory available, I did tweaked that and other gradle setting (daemon on/off, parallel on/of) but the best I got was instead of havin3 of those FAILURE errors I'm now getting only one.
Anybody have a clue of what's happening here? My last config was
org.gradle.parallel=false
org.gradle.daemon=true
org.gradle.caching=true
org.gradle.jvmargs=-Xmx8G -Xms4G -XX:MaxMetaspaceSize=2048m -Dfile.encoding=UTF-8
Thanks all.
Guys, I'm completely blocked here, I need to run Besu with my code thru a Jenkins pipeline and all the checks it contains, this is a mandatory step for me. The build runs fine on my local computer, but in a java-gradle-build in the pipeline it ends with this strange error
FAILURE: Build failed with an exception.
- What went wrong: Gradle build daemon disappeared unexpectedly (it may have been killed or may have crashed)
- Exception is: org.gradle.launcher.daemon.client.DaemonDisappearedException: Gradle build daemon disappeared unexpectedly (it may have been killed or may have crashed)
Googling for it almost all replies say it has to do with memory available, I did tweaked that and other gradle setting (daemon on/off, parallel on/of) but the best I got was instead of havin3 of those FAILURE errors I'm now getting only one.
Anybody have a clue of what's happening here? My last config was
org.gradle.parallel=false org.gradle.daemon=true org.gradle.caching=true org.gradle.jvmargs=-Xmx8G -Xms4G -XX:MaxMetaspaceSize=2048m -Dfile.encoding=UTF-8
Thanks all.
Have you tired set caching to false?
I think I did but just in case I'll try again...
Cheers.
Have you tired set caching to false?
I think I did but just in case I'll try again...
Cheers.
Have you tired set caching to false?
Same thing...
@MASDXI are you still having this issue?
@MASDXI are you still having this issue?
I do, even if in another place in the flow... Anyway, this is not a blocker anymore, I expect that later today or tomorrow I can do a merge in our own github fork of Besu, and after some tests I'll create the draft PR for review. I'm planning to work over the weekend if needed.
Cheers.
glad to hear it's not a blocker @amsmota - I'm just curious since we have occasionally struck the "gradle daemon disappeared" issue and haven't found a good fix for it. There's not much helpful info to be found either
Guys, I am now able to work directly on my fork (well, of the company I work) and am now doing some corrections and tests, so I think I will be able to do a Draft PR somewhen tomorrow or the next day.
If youse guys have any recomendation or guidelines that I should follow please let me know.
Cheers.
.../java/org/hyperledger/besu/cli/BesuCommand.java | 12 +++++ .../besu/controller/QbftBesuControllerBuilder.java | 3 +- .../hyperledger/besu/cli/CommandTestAbstract.java | 7 ++- .../hyperledger/besu/config/BftConfigOptions.java | 7 +++ .../java/org/hyperledger/besu/config/BftFork.java | 13 +++++ .../besu/config/JsonBftConfigOptions.java | 11 ++++ .../besu/config/JsonBftConfigOptionsTest.java | 28 ++++++++++ .../besu/consensus/common/bft/BlockTimer.java | 61 ++++++++++++++++++++-- .../common/bft/MutableBftConfigOptions.java | 25 +++++++++ .../consensus/common/ForksScheduleFactoryTest.java | 6 +-- .../besu/consensus/common/bft/BlockTimerTest.java | 44 +++++++++++++--- .../consensus/qbft/support/TestContextBuilder.java | 2 + .../QbftBlockHeaderValidationRulesetFactory.java | 4 +- .../consensus/qbft/QbftForksSchedulesFactory.java | 1 + .../qbft/statemachine/QbftBlockHeightManager.java | 50 ++++++++++++++---- .../consensus/qbft/statemachine/QbftRound.java | 24 +++++++++ .../qbft/MutableQbftConfigOptionsTest.java | 20 +++++++ .../statemachine/QbftBlockHeightManagerTest.java | 21 ++++++++ .../validator/QbftForksSchedulesFactoryTest.java | 3 ++
One thing I'm in doubt is, in places like BesuCommand
and MiningParameters
, should I add the new emptyBlockPeriodSeconds
, since the existing blockPeriodSeconds
is there?
I added it, I removed it, and now I'm wondering again... BesuCommand
and MiningParameters
are not directly related with QBFT, so it makes sense NOT to put emptyBlockPeriodSeconds
there?
Same for CommandTestAbstract
...
And now I'm having this test errors that have nothing to do with the code I added, any ideas?
I'll try to debug the Assert ones... (the ones below with 🟢 and 🔴 are because I'm in a windows machine, right? Actually, maybe all are...)
Task :besu:test
Java HotSpot(TM) 64-Bit Server VM warning: Sharing is only supported for boot loader classes because bootstrap classpath has been appended PrivacyTest > flexibleEnabledPrivacy() FAILED java.io.IOException at TempDirectory.java:431
PrivacyTest > defaultPrivacy() FAILED java.io.IOException at TempDirectory.java:431 Java HotSpot(TM) 64-Bit Server VM warning: Sharing is only supported for boot loader classes because bootstrap classpath has been appended
BesuCommandTest > nativeLibrariesAreEnabledByDefault() FAILED org.opentest4j.AssertionFailedError at BesuCommandTest.java:2179 stty: /dev/tty: No such device or address
RunnerTest > fastSyncFromGenesis() FAILED java.io.IOException at TempDirectory.java:431
RunnerTest > fullSyncFromGenesis() FAILED java.io.IOException at TempDirectory.java:431 stty: /dev/tty: No such device or address
BesuCommandTest > callingWithConfigOptionButTomlFileNotFoundShouldDisplayHelp() FAILED java.lang.AssertionError at BesuCommandTest.java:275
PrivacyOptionsTest > privEnclaveKeyFileDoesNotExist() FAILED java.lang.AssertionError at PrivacyOptionsTest.java:427
TxParseSubCommandTest > smokeTest() FAILED org.opentest4j.AssertionFailedError at TxParseSubCommandTest.java:39
TxParseSubCommandTest > assertValidRlp() FAILED org.opentest4j.AssertionFailedError at TxParseSubCommandTest.java:58
TxParseSubCommandTest > assertInvalidChainId() FAILED org.opentest4j.AssertionFailedError at TxParseSubCommandTest.java:67
🟢"err: wrong chain id\n" 🔴"err: wrong chain id\r\n"
ConfigOptionSearchAndRunHandlerTest > handleWithEnvironmentVariable() FAILED java.io.IOException at TempDirectory.java:431 stty: /dev/tty: No such device or address stty: /dev/tty: No such device or address stty: /dev/tty: No such device or address
MiningOptionsTest > posBlockCreationMaxTimeOutOfAllowedRange() FAILED java.lang.AssertionError at MiningOptionsTest.java:309
🟢"--Xpos-block-creation-max-time must be positive and ≤ 12000" 🔴"--Xpos-block-creation-max-time must be positive and ? 12000"
OperatorSubCommandTest > shouldGenerateSECP256R1KeysWhenSetAsEcCurve() FAILED java.lang.NoClassDefFoundError at OperatorSubCommandTest.java:247 Caused by: java.lang.ExceptionInInitializerError at OperatorSubCommandTest.java:408
OperatorSubCommandTest > shouldImportSecp256R1Keys() FAILED java.lang.NoClassDefFoundError at OperatorSubCommandTest.java:353 Caused by: java.lang.ExceptionInInitializerError at OperatorSubCommandTest.java:408 stty: /dev/tty: No such device or address
And now I'm having this test errors that have nothing to do with the code I added, any ideas?
I'll try to debug the Assert ones... (the ones below with 🟢 and 🔴 are because I'm in a windows machine, right? Actually, maybe all are...)
Task :besu:test
Java HotSpot(TM) 64-Bit Server VM warning: Sharing is only supported for boot loader classes because bootstrap classpath has been appended PrivacyTest > flexibleEnabledPrivacy() FAILED java.io.IOException at TempDirectory.java:431
PrivacyTest > defaultPrivacy() FAILED java.io.IOException at TempDirectory.java:431 Java HotSpot(TM) 64-Bit Server VM warning: Sharing is only supported for boot loader classes because bootstrap classpath has been appended
BesuCommandTest > nativeLibrariesAreEnabledByDefault() FAILED org.opentest4j.AssertionFailedError at BesuCommandTest.java:2179 stty: /dev/tty: No such device or address
RunnerTest > fastSyncFromGenesis() FAILED java.io.IOException at TempDirectory.java:431
RunnerTest > fullSyncFromGenesis() FAILED java.io.IOException at TempDirectory.java:431 stty: /dev/tty: No such device or address
BesuCommandTest > callingWithConfigOptionButTomlFileNotFoundShouldDisplayHelp() FAILED java.lang.AssertionError at BesuCommandTest.java:275
PrivacyOptionsTest > privEnclaveKeyFileDoesNotExist() FAILED java.lang.AssertionError at PrivacyOptionsTest.java:427
TxParseSubCommandTest > smokeTest() FAILED org.opentest4j.AssertionFailedError at TxParseSubCommandTest.java:39
TxParseSubCommandTest > assertValidRlp() FAILED org.opentest4j.AssertionFailedError at TxParseSubCommandTest.java:58
TxParseSubCommandTest > assertInvalidChainId() FAILED org.opentest4j.AssertionFailedError at TxParseSubCommandTest.java:67
🟢"err: wrong chain id\n" 🔴"err: wrong chain id\r\n"
ConfigOptionSearchAndRunHandlerTest > handleWithEnvironmentVariable() FAILED java.io.IOException at TempDirectory.java:431 stty: /dev/tty: No such device or address stty: /dev/tty: No such device or address stty: /dev/tty: No such device or address
MiningOptionsTest > posBlockCreationMaxTimeOutOfAllowedRange() FAILED java.lang.AssertionError at MiningOptionsTest.java:309
🟢"--Xpos-block-creation-max-time must be positive and ≤ 12000" 🔴"--Xpos-block-creation-max-time must be positive and ? 12000"
OperatorSubCommandTest > shouldGenerateSECP256R1KeysWhenSetAsEcCurve() FAILED java.lang.NoClassDefFoundError at OperatorSubCommandTest.java:247 Caused by: java.lang.ExceptionInInitializerError at OperatorSubCommandTest.java:408
OperatorSubCommandTest > shouldImportSecp256R1Keys() FAILED java.lang.NoClassDefFoundError at OperatorSubCommandTest.java:353 Caused by: java.lang.ExceptionInInitializerError at OperatorSubCommandTest.java:408 stty: /dev/tty: No such device or address
I am glad to hear an update from you @amsmota , will fork the code from your repo/branch and take a look at your code, and helping you to find out.
Hi, I'm planning to create a Draft PR sometime today, I'm going to ignore those errors...
I'll post here when done.
Cheers.
This is the last test I did with this config in genesis file. It starts with blockperiodseconds=10 and emptyblockperiodseconds=0 (the default value, it behaves as it never existed, all blocks empty or not will be created every 10 seconds). Then at block 50 non-empty blocks will be created every 5 seconds and empty blocks every 30 seconds.
"config" : {
"chainId" : 1337,
"berlinBlock" : 0,
"qbft" : {
"blockperiodseconds" : 10,
"epochlength" : 30000,
"requesttimeoutseconds" : 4
},
"transitions" : {
"qbft" : [{
"block": 50,
"blockperiodseconds" : 5,
"emptyblockperiodseconds" : 30
}]
}
},
Before transition: (note 15:06:47 that is NOT a empty block but still is created in 10 secs)
2024-04-13 **15:06:17**.471+01:00 | QbftBesuControllerBuilder | Imported empty block #21 / 0 tx / 2 pending / 0 (0.0%) gas / (0x8d50644593d046a522903f12ad1de76125c2eb99e6146988f7a6f349b2f1c576)
2024-04-13 **15:06:27**.410+01:00 | QbftBesuControllerBuilder | Imported empty block #22 / 0 tx / 2 pending / 0 (0.0%) gas / (0xb5888b11f4afa6e9123d272707958064246c53ed5eeaeb11be01c7b8c010df95)
2024-04-13 **15:06:37**.359+01:00 | QbftBesuControllerBuilder | Imported empty block #23 / 0 tx / 3 pending / 0 (0.0%) gas / (0x6493052fb156218dbca9d95eec25434cc1210d6d05e15503e8ee3e4226d22110)
2024-04-13 **15:06:47**.537+01:00 | QbftBesuControllerBuilder | **Produced block #24 / 1 tx** / 2 pending / 3,000,000 (63.8%) gas / (0x955147e78facf34402c9bf6c3d55533a69ccc30d2f057307455e79ceb8763cef)
2024-04-13 **15:06:57**.246+01:00 | QbftBesuControllerBuilder | Imported empty block #25 / 0 tx / 2 pending / 0 (0.0%) gas / (0x8d216065533e00825096751b66506852c4253edb42c14f1585c2cee45d0333b2)
After transition: (after #49 the transition kicks in and enpty blocks take 30s to create, non-empty evry 5 sec, see block at 15:12:02)
2024-04-13 **15:10:57**.174+01:00 | QbftBesuControllerBuilder | Imported empty block #49 / 0 tx / 3 pending / 0 (0.0%) gas / (0x0ee851152f1a6faaa199d3f595234141c050966f7be46a65241f01908ce34d07)
2024-04-13 **15:11:27**.233+01:00 | PeerDiscoveryAgent | Writing node record to disk. NodeRecord{seq=2, publicKey=0x027c19f5309e268264c9a986704a2f24e01f466a541ef910f68cc831324ba1ee2c, udpAddress=Optional[/127.0.0.1:30303], tcpAddress=Optional[/127.0.0.1:30303], asBase64=-Je4QKHhLqyEBF13upUKqj-i_cALkD-_-h3yPWZgkdFdnsjZZZCyzpd63wDaWlVWriBpGu_JPciWtEhwgqy-XSiQp0YCg2V0aMfGhOcD3GaAgmlkgnY0gmlwhH8AAAGJc2VjcDI1NmsxoQJ8GfUwniaCZMmphnBKLyTgH0ZqVB75EPaMyDEyS6HuLIN0Y3CCdl-DdWRwgnZf, nodeId=0xc92329278474852a32bd72b721afbac4d309b7fa6e40862eaee847cc8f544045, customFields={tcp=30303, udp=30303, ip=0x7f000001, eth=[[0xe703dc66, 0x]], id=V4, secp256k1=0x027c19f5309e268264c9a986704a2f24e01f466a541ef910f68cc831324ba1ee2c}}
2024-04-13 **15:11:27**.258+01:00 | QbftBesuControllerBuilder | Imported empty block #50 / 0 tx / 3 pending / 0 (0.0%) gas / (0x4a43cebe16dc6a3c341cb92b109404580bb1bbe756cd2c855ecdc826d14ea9c1)
2024-04-13 **15:11:57**.359+01:00 | QbftBesuControllerBuilder | Imported empty block #51 / 0 tx / 3 pending / 0 (0.0%) gas / (0x02b83a1b6d33dcbafed7c6ceae9bd32cd757874151fb9232124681ac41befba1)
2024-04-13 **15:12:02**.377+01:00 | QbftBesuControllerBuilder | **Produced block #52** / 1 tx / 3 pending / 3,000,000 (63.8%) gas / (0x32dd8d703933b1de951c7f99d3a5e50b66e573494ecf8eafe003df578df1e204)
2024-04-13 **15:12:32**.236+01:00 | QbftBesuControllerBuilder | Imported empty block #53 / 0 tx / 3 pending / 0 (0.0%) gas / (0xc51bba3cc60545422f6f920827790ed5ba75306608e494501e970ae1cd84fbe9)
Guys, I just created a Draft PR, please let me know what are the next steps...
https://github.com/hyperledger/besu/pull/6944
Cheers.
Experimental support has been delivered under https://github.com/hyperledger/besu/pull/6965
testing with release 24.10.0 and genesis configs:
"qbft": {
"blockperiodseconds": 5,
"emptyblockperiodseconds": 30,
"epochlength": 30000,
"requesttimeoutseconds": 3
},
a block is generated every 5 seconds with no regard to the emptyblock time?!
I was testing on a local vm that I just fired up from scratch
@MCrypto It is an early access/experimental feature so the "x" is in front, i.e. xemptyblockperiodseconds
.
We don't normally document early access features, but I think we should make an exception for this one as likely to be widely used
@MCrypto It is an early access/experimental feature so the "x" is in front, i.e.
xemptyblockperiodseconds
.We don't normally document early access features, but I think we should make an exception for this one as likely to be widely used
Thank you so much, we have been waiting for this feature for our private blockchain implementation before we launch our mainnet! We are still on our testnet, so hopefully things will be stable enough by the time we come to our launch.
Thanks to everyone who worked on this!!
@MCrypto you might need requesttimeoutseconds
to be >= xemptyblockperiodseconds
as well
Background and specification document: https://docs.google.com/document/d/1UjefKBgnFnBqQGYZSfVr7LZxVOgrDjeO0uZVHtKSRQA/edit?usp=sharing
The QBFT consensus protocol creates new blocks on a regular basis with the time interval between blocks being a configurable parameter. This is also true in the case that none of the validating nodes has received any transaction not already included in the blockchain. Under these circumstances, since no new transaction is being received, the QBFT protocol ends up producing a continuous sequence of blocks void of any transaction, i.e. empty blocks.
In cases where the transaction volume is quite low, this is less than ideal as empty blocks end up occupying a lot of the node storage space compared to the space occupied by actual transactions.
The approach will be need to be co-ordinated with the implementation in GoQuoum as well so that the protocol remains compatible.
Tasks (TODO)
block.getBody().getTransactions().isEmpty()
instead of attempting to query the txpool directly.