1.4.0
Changelog
1.4.0
Private State Migration
Hyperledger Besu v1.4 implements a new data structure for private state storage that is not backwards compatible.
A migration will be performed when starting v1.4 for the first time to reprocess existing private transactions
and re-create the private state data in the v1.4 format.
If you have existing private transactions, see migration details.
Additions and Improvements
-
TLS support to secure client and server communication.
-
Multi-tenancy to enable multiple participants to use the same Besu and Orion node.
-
Plugin APIs to enable building of Java plugins to extend Hyperledger Besu.
-
Support for additional NAT methods.
-
Added
priv_call
which invokes
a private contract function locally and does not change the private state. -
Besu has moved from an internal Bytes library to the Apache Tuweni Bytes library.
This includes using the library in the Plugins API interfaces. #295 and #215
Early Access Features
Early access features are available features that are not recommended for production networks and may
have unstable interfaces.
-
Reorg compatible privacy
to enable private transactions on networks using consensus mechanisms that fork. -
Tracing API to obtain detailed information about transaction processing.
Bug Fixes
See RC and Beta sections below.
Known Issues
Fast sync defaulting to full sync
- When fast sync cannot find enough valid peers rapidly enough, Besu defaults to full sync.
Workarounds:
- To re-attempt fast syncing rather than continue full syncing, stop Besu, delete your database,
and start again. - When fast syncing, explicitly disable pruning using
--pruning-enabled=false
to reduce the likelihood
of encountering the pruning bug.
A fix to remove the default to full sync is in progress
and is planned for inclusion in v1.4.1.
Error full syncing with pruning
- Error syncing with mainnet on Besu 1.3.7 node - MerkleTrieException #BESU-160
The associated error isUnable to load trie node value for hash
and is caused by the combination of
full sync and pruning.
Workarounds:
- Explicitly disable pruning using
--pruning-enabled=false
when using fast sync. - If the
MerkleTrieException
occurs, delete the database and resync.
Investigation of this issue is in progress and a fix is targeted for v1.4.1.
Bootnodes must be validators when using onchain permissioning
- Onchain permissioning nodes can't peer when using a non-validator bootnode #BESU-181
Workaround -> When using onchain permissioning, ensure bootnodes are also validators.