We’ve Launched Exonum 1.0.0!

30 March 2020

alt After 3 years of productive and in-depth development, our Exonum blockchain team has released its 1.0.0 version of the framework! Exonum now boasts a rich set of features, supports multiple execution environments, and benefits from increased modularity and maintainability – making it an ideal blockchain framework for any organization or use case.

We will continue advancing the Exonum framework, but we have made its 1.0.0 release official because of its feature completeness and backward compatibility:

  • Feature completeness: Exonum provides all necessary tools to develop full-scale blockchain applications. Some of the Exonum features positively differentiate it from other frameworks (for example, service lifecycles, which we’ve covered previously).

  • Backward compatibility: Exonum developers can rely on the core framework interfaces knowing that they will be maintained in the successive releases. Exonum still has some experimental APIs, but they are relatively few and are clearly marked in the documentation. Below, we cover the main changes between version 1.0.0 and its first release candidate (that is, 1.0.0-rc.1). See our previous article for an overview of functionalities present in the release candidate and, of course, visit our the project changelog to see the complete list of changes.

More Complete Service Lifecycle

The 1.0.0 release adds two new operations for service lifecycle: artifact unloading and service freezing.
Artifact unloading allows you to free up node resources by commanding the nodes in the blockchain network to unload a service artifact which is not used by any service. For example, such a situation may occur if a service that previously used the artifact was migrated to a newer artifact revision. In this case, the old artifact will most probably consume node resources, such as RAM and disk space, without necessity – it is unlikely (although not impossible) that a new service would be instantiated from the old artifact once the newer one is readily available.

In spirit of separating mechanism and policy and blockchain transparency, the Exonum framework and/or separate nodes do not decide on their own when to unload unused artifacts. Instead, this operation is implemented through the supervisor service similarly to other lifecycle events. In this way, unloading is fully deterministic, ensuring it is properly authorized and agreed among all nodes in the network.

Service freezing allows you to “freeze” the service state without switching off its read-only interfaces (for example, HTTP API provided by both Rust and Java runtimes). This enables serving these interfaces while the service is being migrated to a newer artifact; the service downtime in this case may become close to zero, even if the data migration takes a very long time to complete. Another use case for service freezing is temporarily disabling transaction processing if a bug / vulnerability is discovered in service code. In this case, service remains mostly functional, and is guaranteed to stay immutable until a newer artifact with the patched bug is available.

Please note: Unloading artifacts and freezing services are not yet supported by the Java runtime.

Customized Block Proposals and Block Skips

Previously, Exonum did not offer an avenue for you to customize the logic regarding how transactions are included into blocks. With 1.0.0, Exonum allows you to customize which transactions a node should include into a block using a flexible interface. This could be used in a few different ways, including:

  • Whitelist / blacklist transactions by the public key that has authorized the transaction and/or by the service processing the transaction

  • Prioritizing transactions by the processing service or other criteria

  • Filtering transactions by proof-of-work or fee attached to the transaction

  • Decoupling “similar” transactions (for example, timestamps generated by the time service) with user-defined similarity criteria

This block proposal customization is made even more powerful by the ability of nodes to skip block creation at a specific iteration of the consensus algorithm. Such a block skip is considered an outcome of the consensus algorithm alterative to accepting a normal block with transactions. Correspondingly, introducing block skips has no influence on the security properties of the consensus algorithm.

Unlike normal blocks, block skips are saved in a separate section of the blockchain storage. No more than one block skip is saved by the node at any given time. (since skipping a block does not change the blockchain state in any way, it is easy to see that such “forgetful” storage is enough to keep node syncing functional.) Thus, block skips allow you to immensely save on blockchain storage if transactions appear in the blockchain network seldomly – instead of permanently saving a new empty block each second or so, the nodes can now generate block skips with the same frequency (this providing “heartbeat” for the network), but only save the latest skip.

Please note: The block proposal customization is an experimental feature as of now. As per Rust traditions, you don’t pay for this feature (in terms of safety and performance) if you don’t use it.

Async / Await Throughout Codebase

Exonum now extensively uses async / await syntax, which was recently shipped to stable Rust. This affects both public-facing interfaces (for example, the way HTTP endpoints are defined for Rust services) and internals (such as the network module within exonum-node crate).

Using async / await allows to make code more concise and readable and thus reduce the amount of inefficiencies and logic errors. In some cases, the refactoring associated with async / await has opened qualitatively new capabilities. As an example, sending transactions to the node (say, from an HTTP API handler of a service) was previously a synchronous operation which blocked internally if the capacity of the node to process transactions was exceeded. This could potentially lead to API hang-up. After refactoring, sending transactions is explicitly asynchronous so that there is no hidden cost to it.

A final note: Since our launch of Exonum in 2017, we’ve worked with several developers around the world who have made contributions, asked questions and advised us on our Exonum open-source blockchain framework. Thanks to all of you for your help – we would not be here today without you!

Elena Buzovska

Read more posts by this author.