Documentation for Hyperledger Besu enterprise-grade Java-based, Apache 2.0 licensed Ethereum client https://wiki.hyperledger.org/display/besu
With this release the previously experimental Layered txpool is marked stable and enabled by default, so please read the following instructions if you used to tune txpool behaviour, otherwise you can simply go with the default and enjoy the improved performance of the new txpool.
If you do not specify any txpool option, then you can skip this section.
If you have tuned the txpool using one of these options: tx-pool-retention-hours
, tx-pool-limit-by-account-percentage
or tx-pool-max-size
,
then you need to update your configuration as described below:
tx-pool-retention-hours
: simply remove it, since it is not applicable in the Layered txpool, old transactions will eventually expire when the memory cache is full.tx-pool-limit-by-account-percentage
: replace it with tx-pool-max-future-by-sender
, which specify the max number of sequential transactions of single sender are kept in the txpool, by default it is 200.tx-pool-max-size
: the Layered txpool is not limited by a max number of transactions, but by the estimated memory size the transactions occupy, so you need to remove this option, and to tune the max amount of memory* use the new option tx-pool-layer-max-capacity
as described below.You can still opt-out of the Layered txpool, setting tx-pool=legacy
in config file or via cli argument, but be warned that the Legacy implementation will be deprecated for removal soon, so start testing the new implementation.
By default, the txpool is tuned for mainnet usage, but if you are using private networks or want to otherwise tune it, these are the new options:
tx-pool-max-future-by-sender
: specify the max number of sequential transactions of a single sender are kept in the txpool, by default it is 200, increase it to allow a single sender to fit more transactions in a single block. For private networks, this can safely be set in the hundreds or thousands if you want to ensure future transactions (with large nonce gaps) remain in the pool.tx-pool-layer-max-capacity
: set the max amount of memory* in bytes, a single memory limited layer can occupy, by default is 12.5MB, keep in mind that there are 2 memory limited layers, so the expected memory consumption is twice the value specified by this option, so 25MB by default. Increase this value if you have spare RAM and the eviction rate is high for your network.tx-pool-max-prioritized
: set the max number of transactions allowed in the first layer, that only contains transactions that are candidate for inclusion in the next block creation task. It makes sense to limit the value to the max number of transactions that fit in a block in your network, by default is 2000.*: the memory used by the txpool is an estimation, we are working to make it always more accurate.
--Xlayered-tx-pool
is gone, to select the implementation use the new --tx-pool
option with values layered
(default) or legacy
--Xlayered-tx-pool-layer-max-capacity
, --Xlayered-tx-pool-max-prioritized
and --Xlayered-tx-pool-max-future-by-sender
just drop the X
and keep the same behavior--tx-pool=legacy
.
By default, the new transaction pool is capped at using 25MB of memory, this limit can be raised using --layered-tx-pool-layer-max-capacity
options #5772
besu-untuned
start scripts to run without any specific G1GC flags #5879
engine_forkchoiceUpdatedV?
response time by asynchronously process block added events in the transaction pool #5909
https://hyperledger.jfrog.io/artifactory/besu-binaries/besu/23.10.0/besu-23.10.0.tar.gz / sha256: 3c75f3792bfdb0892705b378f0b8bfc14ef6cecf1d8afe711d8d8687ed6687cf
https://hyperledger.jfrog.io/artifactory/besu-binaries/besu/23.10.0/besu-23.10.0.zip / sha256: d5dafff4c3cbf104bf75b34a9f108dcdd7b08d2759de75ec65cd997f38f52866
This is an optional release, it is only required if you are running a Holesky node.
OperationTracer
to capture contexts enter/exit #5756
eth_call
and eth_estimateGas
responses #5705
Transaction
interface #5732
benchmark
subcommand to evmtool
#5754
--json-pretty-print-enabled
CLI option. #5766
eth_getBlockReceipts
JSON-RPC method to retrieve all transaction receipts for a block in a single call #5771
OperationTracer
to capture contexts enter/exit #5756
evmtool
launcher binaries now ship as part of the standard distribution. #5701
execution-spec-tests
via the t8n
and b11r
. See the README in EvmTool for more instructions.admin_addPeer
and admin_removePeer
#5584
NewPooledTransactionHashes
to other clients, using unsigned int for encoding size. #5640
https://hyperledger.jfrog.io/artifactory/besu-binaries/besu/23.7.1/besu-23.7.1.tar.gz / sha256: 85dce66c2dbd21b4e5d3310770434dd373018a046b78d5037f6d4955256793cd https://hyperledger.jfrog.io/artifactory/besu-binaries/besu/23.7.1/besu-23.7.1.zip / sha256: dfac11b2d6d9e8076ab2f86324d48d563badf76fd2a4aadc4469a97aef374ef5
Besu release: https://github.com/hyperledger/besu/releases/tag/23.4.1
--ethstats-cacert-file
by @alexandratran in https://github.com/hyperledger/besu-docs/pull/1331
Full Changelog: https://github.com/hyperledger/besu-docs/compare/23.4.0...23.4.1
This quarterly update should be carefully reviewed by private network users before upgrading. This quarterly release contains a lot of new improvements but many breaking changes. We have deprecated GoQuorum-compatible privacy modes in this release, as well as IBFT1.0. If you require these, please consider migrating to new consensus algorithms or waiting for future releases.
Highlights in this release include:
Lastly, this release formalizes a deprecation notice for GoQuorum -compatible permissioning modes in Besu. These will be removed in the 23.7 series, unless otherwise stated.
This update is strongly recommended for anyone running Nimbus with Besu. Due to the way Nimbus send request data, this can lead to a missed block proposal in certain circumstances.
This update is a mainnet-compatible Shanghai/Capella upgrade and is recommended for all Mainnet users. This update contains a small number of overall improvements and fixes but a large refactor of Bonsai. We have heard your issues loud and clear with the storage format and have taken the time to craft a new architecture that keeps the benefits (low storage, lightweight nodes) without the tradeoffs (worldstate issues, exceptions processing transactions, broken databases). Expect more details on this in a forthcoming blog post. We have also continued our cleanup of backwards sync and RPC.
--rpc-max-logs-range
#5209
This update is required for the Goerli Shanghai/Capella upgrade and recommended for all Mainnet users. If you use Besu on Goerli, update to 23.1.1. If you previously used 23.1.1-RC1, update to test 23.1.1 on Goerli.
Besu 23.1.0 is a recommended update for Mainnet users. Thank you all for your patience as we crafted this quarterly release.
This is a rather large release with some breaking changes, so please be sure to read these notes carefully before you upgrade any Besu instances. We are including a move to Java 17 LTS. To build and run Besu, please make sure you have Java 17 on the host machine. Additionally, there are a host of spec compliance changes that change existing formats, so please check the specific RPC updates. Lastly, this release formalizes a deprecation notice for GoQuorum privacy modes and IBFT1.0 in Besu. These will be removed in the 23.4 series, unless otherwise stated.
From the improvements and fixes side, we have a host of execution performance improvements and fixes for defects with bonsai storage. We have also included an error detection and auto-heal capability for nodes that encounter state issues. This should keep nodes online and validating that may have previously required a resync.
One final note. 23.1.0 is not a Shanghai ready release. If you intend to test Besu on the long-lived testnets like Zhejiang, please follow the instructions here. We will have more to share on our official Shanghai releases soon.
blockCount
to accept hexadecimal string (was accepting plain integer) #5047
excess_data_gas
field to block header #4958
max_fee_per_data_gas
field to transaction #4970
safe
and finalized
strings for the RPC methods using defaultBlock parameter #4902
--Xchain-pruning-enabled
, --Xchain-pruning-blocks-retained
and --Xchain-pruning-frequency
[#4686](https://github.com
/hyperledger/besu/pull/4686)