Last week we released version 0.12 of our Exonum blockchain framework. This version incorporates several usability improvements, functionality normalizations, and groundwork for a unique independent storage for your blockchain projects. More details are included below, and the complete list of updates is available in our Changelog.

Simplified Bootstrapping Procedure

In the previous version of the Exonum platform (v.0.11), we made a system security improvement that resulted in the time consensus and service keys of the nodes being stored in separate files. Each file can be secured by a password at the administrator’s discretion. Such security measures prevent thefts of the secret keys of the nodes by third parties. At the same time, we expanded the “generate-config” command of the bootstrapping procedure. In version 0.11, the routes to both files had to be mentioned in the options of the command. An example of such a command is here:

Old Version of the `generate-config` Command

To optimize the flow of the project set-up, we placed all the configuration files (namely, the files with the public and secret node parameters and the two files with keys in question) into a separate folder. So only the name of the folder is used now when addressing the files within the “generate-config” command:

New Version of the `generate-config` Command

The mentioned principle also reduced the number of arguments for the “finalize” stage of the procedure. The routes to the public configuration files of each node are now organized into one as follows:

New Version of the Finalize Command

Exonum MerkleDB Storage

In this release, we have completed the first step in our development of an authentic storage for blockchain projects. Exonum MerkleDB is a persistent storage solution based on RocksDB. It provides APIs to work with Merkelized data structures characteristic of blockchain projects.

MerkleDB is an object database. The main MerkleDB objects internally are wrappers around key-value stores; they perform the same role as tables in relational databases (RDBMSs).These stores also meet specific requirements that blockchains have for data management (for example, building cryptographic proofs for checking presence/absence of particular information in the blockchain).

In the low level storage, all data and its keys are stored as a sequence of bytes in a single table called the “column family” in terms of RocksDB engine. It is also possible to apply different database engines at the developer’s discretion.

You can find the detailed description of the MerkleDB module in our documentation.

With regards to Exonum architecture, the storage module is now extracted into a separate crate. See the complete set of object stores we currently ship with Exonum.

We also advanced our data security while upgrading our storage. The hashing rules for the leaf and branch nodes of our “ProofList” objects now support the requirements of the Transparency Certificatepromoted by Google. Adoption of such a highly rated standard, in our opinion, should add to attractiveness of the framework as a safe and secure instrument.

Exonum API Extension

Beginning in Exonum v.0.10, you could connect to nodes through the REST API as well as through WebSockets. The idea here was that light clients could subscribe to network events and obtain information on the blockchain from the nodes. Previously, the light client could only be notified if there was a new block event. In other words, if using the socket, the client was notified with every new block accepted in the network.

In the present release, we extended the WebSocket API to also support subscription to transaction events. This means that you (through the light client) can be notified every time a transaction of a specified service is committed to the blockchain.

We also enabled multiple subscriptions with filters. You can subscribe simultaneously to various types of events (for example, to new transactions and blocks, and/or to transactions from various services and of different types).

We also extended the API to enable you to send transactions to the blockchain via WebSocket. This functionality is similar to the one underpinning the Exonum Blockchain Explorer. We expect this will be more suitable in some cases compared to the old workflow.

See our documentation for the full list of available sockets.

If you are developing on Exonum, you should also pay attention to the changes in the Exonum REST API. A couple of new endpoints were added to make node management more flexible and some old endpoints were updated to deliver the requested information more efficiently.

For any questions, or if you need assistance with our new features, feel free to contact us through our Gitter channels.