A platform for building private blockchains – Exonum - is calling to your attention with a fresh package of news from its team. Take a short break and get on a brief excursion over the framework updates.
The first notable change is associated with the review of the format of cryptographic proofs provided by the system. The proofs report on presence/absence of elements in the system storage and currently have been brought to a more compact state. Specifically, a hash sub-tree of the initial Merkle Patricia Tree was substituted by a set of key-value pairs corresponding to the “tree leaves” sufficient for restoring said tree.
Besides, the new format allows to retrieve confirmations not only for one but for an arbitrary number of keys at a time which also contributes to proofs compactness.
A worthwhile achievement is that the data structures utilized by the new proofs are much simpler compared to the old recursive ones. Thus, they can be comfortably deserialized and used in almost any programming language.
Finally, according to the recent benchmarks the new proofs have also turned out to be about 30% faster to generate and 5% faster to verify than their predecessors.
The detailed information on the new proofs structure is available in the corresponding Read me document.
Another item of the present release is our “Cryptocurrency Advanced” demo that is devised to demonstrate some additional functionality compared to the old simple version of said service as well as some best practices for writing Exonum services.
Just in the same way as its elder sibling, the advanced demo enables basic transactions associated with creating users and wallets and transferring money between them. However, the extra functionality offered therein refers to the following points:
- creation and review of wallets history which was absent in the simple demo
- creation of cryptographic proofs which will allow checking transactions availability in the blockchain.
Besides, unlike simple cryptocurrency demo, the advanced version offers the possibility to configure the network and launch several nodes at once creating a full-functioning blockchain.
The front part of the demo and the step-by-step service tutorial are still in progress and will come out soon. Meanwhile, the demo will be of great interest for service developers making their first steps in blockchain industry.
A regular part of attention was given to internal arrangements presented below.
SystemTimeRust type has been substituted for
chrono::DateTime<Utc>due to that the former one exposes different behavior on different platforms.
Previously used as a storage key or value
SystemTimestandard type turned out to have some troubles with cross-platform usage due to different ranges supported by them. For example, if you pretended some action took place a thousand years ago on Windows, the same value on Linux or iOS would simply get an error and cause a node shut down.
To avoid this,
chrono::DateTime<Utc>that works similarly in any environment is now used both in Exonum core and Exonum time oracle
Another contribution to configuration flexibility and system fairness has been done by introduction of
majority_count: Option<u16>parameter. Said parameter allows to adjust the threshold amount of votes required to commit a new configuration proposal. By default, the number of votes is calculated as
2/3 + 1of total validators count. However, now the absolute majority can be increased up to 100% to provide greater reliability.
Following the initiative started during the 0.6 release this internal Exonum core improvement covered another memory issue. Currently not only nodes store consensus messages in the database instead of keeping them in memory pool, the same is applied to non-committed transactions. A sudden node reload will no longer affect consensus execution when processing a new block proposal. The effect is achieved as the node does not need to request the lost transactions from other validators, thus, saving time for committing a new block
The network part of Exonum has been allotted a portion of safety – the
eventsmodule has become private and is no longer reachable from outside of the framework. The sandbox tests responsible for consensus testing have been also incorporated into Exonum core
TransactionsRequeststructure now allows providing a node with batches of the requested transactions at a time rather than sharing them one by one and, thus, avoiding message overload. The algorithm behind the option allows to split the transactions into batches depending on the message size
Blockchain explorer Rust API has been upgraded a bit to provide smoother UX. In particular, now there are more opportunities with regards to management of data returned via Rust API – a fuller support of blocks and transactions iteration, obtainment of transactions rather than their JSON representations, etc.
For those who want to keep up with the Exonum team pace, we have launched a Telegram channel reflecting the framework updates on weekly basis.
The exhaustive list of changes and migration paths for this and other releases is persistently available in our Changelog.