0.6 Exonum Framework Version Has Come Out

06 March 2018


Another milestone in the ongoing process of Exonum framework development has been reached. As the interest in product and the number of integration cases thereof are gradually increasing a greater attention to detail in terms of usability is paid. Hence, the current release mostly yielded in a batch of ergonomic improvements of which we will speak below.

Error Handling in Transactions

A TransactionResult enum has been implemented within the Transaction::execute method. The result provides info on transaction success and the kind of error occurred, if any.

Previously transactions execution was unconditional, i.e. they were executed without any status notification. In case of an error the transaction simply raised panic and the changes to the database were discarded without any notion. At the same time the transaction was included into some block as the one that had been executed and brought no changes to the database state.

Currently the mechanism has become more obvious. In case after transaction execution the code produces an error, the transaction is still included into the block and the produced changes are still discarded, but the corresponding info on the transaction execution error is recorded into the blockchain.

Naturally, v1/transactions endpoint that shows information on transactions execution has been extended to display the status of said execution as well. The option will provide users with an opportunity to swiftly obtain the above-mentioned results.

Transaction Definition

Another ergonomic improvement has been introduced into the code. Specifically, a message! macro for announcing the transactions has been substituted by a transaction! macro that automatically assigns IDs to transactions in order of their introduction. The service ID is introduced in the header of said macro once for all transactions further implemented therein.

The improvement made service coding much smoother allowing to add new transaction types almost on the go.

Log Output

Log output has been adjusted to be more comprehensible. In particular, the date of the logged actions now provides concise information on the time, when a particular action took place.

Technical Improvements

  • exonum::crypto::CryptoHash trait has been introduced. The trait contains hash method representing cryptographic hashing, which allowed to eliminate said method from StorageValue and Message traits. The current implementation corresponds to the preferred Rust syntax of small one-method traits.
  • The StorageKey trait has been re-implemented for signed integer types (i8, i16, i32 and i64) to achieve the natural ordering of the produced keys. The big-endian format previously used for encoding the types caused the negative integer types to be considered larger than the positive ones, so that they were placed in the end of the list. For example, -1i8 is encoded as 0xff and, thus, is considered greater than 127i8 encoded as 0x7f.

    After the change the ordering is done according to the sign and value of the corresponding integer, i.e. negative integer types go first followed by zero and positive ones.

    For those who already used signed integers as keys the change will be a breaking one, however, the old implementation may be emulated.

Apart from a great number of usability features, separate attention was given to internal improvements of the framework from the developers’ side. For example, node behavior with regards to running consensus algorithm has been fine-tuned.

A node which broadcasted some messages into the network and was for some reason unexpectedly restarted at that moment will no longer try to broadcast the new ones instead - such behavior is treated as byzantine and hinders smooth consensus operation. Thus, all the consensus messages are now persistently stored in the database, and the previously broadcasted messages are now recollected from the storage.

For full information on the changes and migration paths to the new version please refer to our Changelog.

At the same time, the core changes were accompanied by some service adjustments, the most of which addressed the service of configuration tightly bound with Exonum core. The detailed list of alterations and refactoring points can be found in the same Changelog.