Skip to content

v0.2.4

Pre-release
Pre-release
Compare
Choose a tag to compare
@CjS77 CjS77 released this 15 May 11:10
· 5212 commits to development since this release
v0.2.4
This tag was signed with the committer’s verified signature. The key has expired.
CjS77 Cayle Sharrock
GPG key ID: 6B503662F6B55CE2
Expired
Learn about vigilant mode.
e537b37
This commit was signed with the committer’s verified signature. The key has expired.
CjS77 Cayle Sharrock
GPG key ID: 6B503662F6B55CE2
Expired
Learn about vigilant mode.

Improvements

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 - 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.
Assets 2
Loading