Exonum 0.9 Released – Get New Opportunities Seized


A new batch of updates, novelty features and improvements has been wrapped up into a fresh core release of which we present a short review below. Take a brief read to keep up with the pace of our framework development – try out new features and be the first to upgrade your own Exonum-based products.

From Iron to Actix Web

Going down in descending order, one of the considerable core changes in this release is a shift from the old Iron web framework that is no longer maintained to a new and dynamic one – Actix web framework. The change resulted in a new implementation of Exonum web API that made its code considerably simpler, more intelligible and easy to perceive at first glance even if you are not professional at Rust. Our updated documentation is a vivid demonstration of this upgrade.

At the same time, we introduced an abstraction layer that covers Actix and, in fact, allows developers to use it as an Exonum built-in functionality for writing end-points instead of dealing with Actix APIs directly. The option will allow developers in future to change the web framework, if necessary, without any considerable difficulty for the one they prefer best.

Updated Node Configuration Due to Noise Protocol

The previous 0.8 Exonum release was marked by the introduction of Noise Protocol in the system. The framework is targeted at secure encryption of messages exchanged among the network nodes. As a result, ConnectList module has substituted its predecessor - WhiteList, so that only the nodes present in their peer’s connect list may address it. With such a mapping between peers’ public keys and addresses, to connect to some node the initiator must specify the public key of the peer of interest. It is worth mentioning that within this substitute the Noise handshake pattern changed as well.
Additionally, as ConnectList is a local node option, it was decided that it will not be stored in the blockchain. As a consequence, in case the ConnectList configuration was updated, a node restart was required, otherwise the new configuration would not come into force. To avoid this, ConfigManager entity has been introduced to allow updating node configuration the moment a new ConnectList appears without restarting the node.

Consistency and Accuracy

Trying to make product development consistent, a number of changes presented in this release deal with polishing the issues that arose due to the continuous framework elaboration and application:

  • We made storage::base_index module private along with BaseIndex and BaseIndexIter types. As it stems from the module name a base_index is, so to say, a base class from which previously new indices could be elaborated by developers. The enhanced control over indices made it impossible to add new index types apart from those already provided by Exonum core (MapIndex, ProofMapIndex, etc.). The reason for such a restriction was the fact that different types of indices with the same name could be created which led to errors of data overwriting. To eliminate these errors, it is necessary to maintain metainformation about all indexes in the database (including index types), which requires knowing eligible index types in advance. As the practice has shown, the available list is sufficient for flexible development.

  • Two excessive endpoints - v1/healthcheck and v1/consensus_status - have been merged as another system optimization step. Previously, the former one returned information on the node status, i.e. whether it is active or not. The latter one has been, at first, added for information relating to the list of connections between the node and its peers – a sufficient number of connections witnesses of consensus stable operation while, for example, availability of only one connection means that consensus is not taking place at the moment. However, as the information on both endpoints turned out to be quite complementary, it was finally decided to unite it under the old v1/healthcheck endpoint.

Further, our team has made several more steps towards elaborating system migration processes. In this particular release, Exonum storage has become versioned. The initiative will make change log of storage versions clearer and ease the process of determining storage migration rules. For those cases where changes to the storage turn out to be backwards incompatible, an explicit message of an update being required will be issued.

The above-mentioned changes are all breaking ones, so be careful when implementing them into your product. Meanwhile, as usually, among new outstanding features there are also those that are less demanding in terms of migration process.

For example, another usability option added to the core is a new type of CLI commands - info command – that was introduced so that a developer could check the core version and its details (for example, the list of services embedded into the core) without running his node. In other words, the command is applied at the stage when administrator configures the node and the compiled Exonum core binary file is launched but before the node is actually started.

Currently info command supports two sub-commands that expose the following core data:

  • core-version - an option that indicates Exonum core version;
  • list-services - an option that extracts the list of services that will run on the node. The list is organized in the JSON format.

Finally, we also paid special attention to efficient memory use. Specifically, since this release BlockResponse request, that is responsible for providing a user with information on all the transactions from a particular block, returns only the hashes thereof and not the transactions themselves. This prevents the errors which occurred when, for example, the response was larger than the allowed message size.

The node parses the response and, in case it recognizes all the transactions in it, the corresponding block is added into the blockchain by the node. If some of the hashes (and, consequently, some of the relevant transactions) are missing in the pool of the node, it makes another request for transactions themselves.
The described case may sound a bit sophisticated, however, such an approach to the issue promoted faster message delivery and processing by the node.

Do not forget to refer to our Changelog for the full list of updates and migration paths.

Feel free to address our team on any development issues in our gitter channels providing practically 24/7 support.