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:

1. To re-attempt fast syncing rather than continue full syncing, stop Besu, delete your database,
   and start again.
2. 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 is Unable to load trie node value for hash and is caused by the combination of
  full sync and pruning.

Workarounds:

1. Explicitly disable pruning using --pruning-enabled=false when using fast sync.
2. 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.