Skip to content

1.4.0

Compare
Choose a tag to compare
@joshuafernandes joshuafernandes released this 27 Feb 00:21
bce6e09

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.