May 15, 2020

By Cayle Sharrock

Base Node v0.2.4 release

We’re happy to announce v0.2.4 of the Tari base node has been tagged and binary versions will be available for download shortly.

Most improvements in this release are centred around removing redundant network traffic and improving peer-to-peer connectivity.


Some of the changes that have come in since the last release include:

  • Introduce temporary short term ban for peers that are providing chain metadata but do not respond to header and block requests.
  • The chain synchronisation mechanism is simpler and more robust. Previously it was possible that a node would unfairly ban a peer after an initial chain sync.
  • The check_db CLI command does more through checks, including block validation. Previously it was only checking the header chain.
  • Old store and forward messages are now removed from the DB after they have been queued to be sent to the destination node.
  • Connections are now closed earlier if a peer is banned.
  • Deprecated tables and code have been removed from wallet codebase.
  • The Store and Forward cache size now has a hard limit.
  • Add node version info to PingPong messages. This will help identify if network issues are related to peers running older software.
  • Introduce Hamming distance as distance metric. The XOR metric seems to cause clustering of nodes that are not able to communicate. Hamming distance seems to improve the clustering issue. The XOR metric is still the default, though will likely be replaced by the Hamming distance in an upcoming release following further testing.

The Transaction send logic in the wallet has been substantially streamlined:

  1. First a Direct send is attempted (previously the direct and SAF were both sent at the same time).
  2. A SAF message is only sent if a Discovery needs to be done or the Direct messages fails.
  3. A record is made in the DB if a direct send occurs because then we know the recipient DEFINITELY got the message and no repeat or SAF should be sent.
  4. If only a SAF message was sent then the Recipient is registered for monitoring by the liveness service.
  5. If a PONG is received then only a Direct send is attempted as a repeat sending of the transaction (so SAF is sent on repeats).
  6. As soon as a Direct send is successful no further repeats will be sent.
  • Multiplex substream counts have been added. This allows the connectivity manager to kill dormant connections.

Bug fixes

  • Temporarily removed randomx-rs (which was causing illegal instruction crashes on some chipsets).
  • Log rollovers were writing to the wrong directory in some cases.
  • Don’t panic if the logger is initialized twice in the Wallet FFI (#1863)
  • A few flaky tests were fixed.