Exonum Files

This release marks the significant milestone in Exonum evolution – the minimum viable lifecycle for Exonum services. Besides dynamic deployment of services implemented in 0.13.0-rc.2 release, Exonum now supports stopping and upgrading service instances (including the possibility of data migrations). Like other lifecycle events, stopping and upgrades are implemented by the core and controlled by the supervisor service, providing flexibility and upgradeability of the control logic.

As a part of service upgrade workflow, Exonum now supports background (aka asynchronous) data migrations. This allows to migrate data from one schema to the other without stopping a node or the blockchain network; the whole process is performed in the background while the node continues processing transactions and other requests. Relevant migration support was added to the storage backend (MerkleDB) and can be used independently.

Other significant changes:

• The crate structure was significantly refactored. The node logic, Rust runtime, HTTP API wrapper, explorer endpoints and system endpoints, all of which were previously parts of the main crate, were moved to separate crates. This provides greater flexibility for core and service developers and allows to evolve downstream crates independently of the core.
• MerkleDB now performs fully automated state aggregation, requiring zero efforts from the core and services. The aggregation logic in core and runtimes was thus removed.
• MerkleDB now supports generic database accesses and shared iterator types for all indexes, allowing to simplify the support code for bindings.
• Service interfaces were reworked in the Rust runtime; now, they are fully represented by traits. These interface traits are automatically implemented for an assortment of stub types, such as keypairs; more stub types can be defined by a user. See the stubs module in the Rust runtime crate for a literary code explainer.
• Preparations have been made to make potential changes to the core interfaces non-breaking. Relevant structures and enumerations were made non-exhaustive, and some unstable interfaces were marked as such in the documentation (or hidden from the docs).

See more detailed list of changes in CHANGELOG.md.

Stability Notice

No changes to the core functionality are expected between this release candidate and the 1.0.0 release. At the same time, there may be breaking changes to the APIs documented as unstable (for example, data migration). Another kind of potential breaking changes is related to updating core dependencies. Right now, Exonum core targets compatibility with Rust 1.36 due to the problems of compiling the Java runtime with the more recent versions. If this restriction is lifted, some core dependencies will be updated, which could result in breaking changes (at least technically).