Bitfury, the full-service blockchain technology company, announced last week the release of version 0.12 of its Exonum blockchain framework. This version incorporates several usability improvements, functionality normalizations, and groundwork for unique independent storage for blockchain projects.
Those interested can check out more details below and view all changes on GitHub.
Simplified Bootstrapping Procedure
In the previous version of the Exonum platform (v.0.11), Bitfury 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, the development team 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.
To optimize the flow of the project set-up, Bitfury 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:
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.
Exonum MerkleDB Storage
In this release, the Bitfury team has completed the first step in the development of 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 the 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 the RocksDB engine. It is also possible to apply different database engines at the developer’s discretion. With regards to Exonum architecture, the storage module is now extracted into a separate crate.
The Exonum developers also advanced data security while upgrading storage. The hashing rules for the leaf and branch nodes of the platform’s “ProofList” objects now support the requirements of the Transparency Certificate promoted by Google. Adoption of such a highly rated standard, should add to the attractiveness of the framework as a safe and secure instrument.
Exonum API Extension
Beginning in Exonum v.0.10, users 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, the development team has extended the WebSocket API to also support subscription to transaction events. This means that users (through the light client) can be notified every time a transaction of a specified service is committed to the blockchain.
The team also enabled multiple subscriptions with filters. Users can subscribe simultaneously to various types of events (for example, to new transactions and blocks, to transactions from various services and of different types).
Further, the API was also extended to enable users to send transactions to the blockchain via WebSocket. This functionality is similar to the one underpinning the Exonum Blockchain Explorer.
Discussion about this post