Exonum 0.8 Is up for Grabs

15 June 2018

alt The first summer days have brought to you the new 0.8 Exonum release with a set of fresh useful changes. This latest version supports IPv6, encryption using Noise Protocol and so much more.

Improved Connection Security with Noise Protocol

Starting with Exonum 0.8, all network connections are encrypted using Noise Protocol – a framework used by WhatsApp, WireGuard and others. It is based on Diffie-Hellman (DH) key arrangement and defines a set of rules of message encryption. The Protocol starts with a handshake message exchange when the parties exchange DH public keys, perform a series of DH operations and, as a result, receive a shared secret key. This key can then be used to send encrypted messages.

Noise Protocol is envisioned as a substitution for our custom connectivity implementation applied so far. It would protect Exonum against a number of potential vulnerabilities, for example, traffic sniffing between nodes. For now, however, the implementation is not complete: the Noise channels are encrypted, but not authenticated.

Note that in view of Noise protocol, nodes compiled with previous versions of Exonum will not connect to nodes updated to 0.8.

New Possibilities for Time Management

You are already familiar with our Time Oracle service for Exonum. The 0.8 version takes operations with time a step further.

Firstly, Exonum’s chrono::Duration structure can now work with time units denominating intervals occupied by some action. In previous versions, additional efforts were required to describe the meaning of time values indicating duration. These struggles are now in the past and defining the business logic of time intervals has become much simpler.

Secondly, we have released a new sample service – the timestamping service. This service is pretty neat and might not only serve as an example of blockchain application, but also come in handy in your projects (with minor refactoring). It allows the system to indicate that a file with a certain hash was committed to the blockchain at a certain time. The system calculates time using the Time Oracle service.

The timestamping service includes both frontend and backend, with the frontend allowing you to upload a file into the system and obtain its hash with the indicated time of its inclusion into the blockchain.

before_commit Functionality

Blocks in Exonum are committed lightning fast, so the moment after a block is accepted and before it is committed is almost non-existent. But in our busy world we have tasks that are to be performed even in that fraction of a second. Exonum 0.8 adds the before_commit method to the Service trait which means that services will now be able to change the blockchain state in the interval that takes place after a new block is accepted by the consensus algorithm but before said block is committed to the blockchain.

Imagine a system with a number of wallets. A block which is to be committed contains operations with these wallets, and we wish to add these operations instantaneously to the wallet history, with their hash and status, despite whether the transaction was successful or not. Previously, this use case was difficult to implement, but now with the before_commit method it’s pretty easy. And it’s just one example! Try out the new method for your services to see the benefits you can get from it.

Frontend for ‘Cryptocurrency Advanced’

The ‘Cryptocurrency Advanced’ demo, announced in version 0.7, now includes a finalized frontend interface. In this new UI you can sign transactions, forward them to the server and then get cryptographic proofs for your data from the blockchain.

The frontend part of the tutorial also includes the embedded blockchain explorer that lets you get a glimpse of what is going on inside the blockchain. Using the explorer, you can see the list of blocks as well as study contents of both blocks and transactions.

New Ways of Configuring Timeouts

TimeoutAdjusterConfig has been removed, but this does not mean its functionality is gone. Previously, you had three timeout adjuster options: Constant, Dynamic and MovingAverage. Now, for simplicity and convenience, the following new values are available in the consensus config to replicate functionality provided by their predecessors: min_propose_timeout, max_propose_timeout and propose_timeout_threshold. In the new version:

  • to mimic the behavior of the Constant timeout adjuster, you just need to set both min_propose_timeout and max_propose_timeout to the same value
  • to emulate the Dynamic timeout adjuster, just use the values from the min, max and threshold values in min_propose_timeout, max_propose_timeout and propose_timeout_threshold correspondingly
  • it has become impossible to emulate the behavior of the MovingAverage timeout adjuster. Nevertheless, applying the same configuration as for the Dynamic timeout adjuster, as described above, may provide a somewhat similar result.

Other Pleasant Additions and Changes

  • Starting from Exonum 0.8, the framework supports not only IPv4 but also IPv6.
  • Exonum Private API now supports CORS.
  • We’ve added support for fixed-point numbers in Exonum.
  • The Time Oracle service has been refactored according to Exonum quality standards.

As always, our code is open to your comments and help. If you want to contribute to the development of Exonum, just choose one of the tasks from the ‘good first issue’ list on GitHub.

The full list of changes which comprise the Exonum 0.8 release can be found in our Changelog.

Other substantial framework updates are coming soon, so get ready for a new portion of news from Exonum in the near future.