Today Bitfury® launched version 0.10 of our Exonum blockchain platform. This version has many new features and improvements to the functionality of the Exonum blockchain system. We’ve summarized some of the most significant upgrades below.
From Custom Serialization to Protobuf
The Exonum system previously featured its own custom serialization mechanism. With version 0.10, we are pleased to announce that the Exonum framework is now using Protocol Buffers (Protobuf) as its serialization format. Protobuf is the industry-endorsed language-neutral and platform-neutral automated mechanism for serializing data developed by Google. This serialization format supports many programming languages and has a well-defined specification. The new serialization format makes it possible to develop light clients in any of the programming languages supported by Protobuf. All the consensus messages and internal structures in Exonum are now serialized with Protobuf.
To apply the Protobuf serialization to structures in Exonum, structures in a file with .proto extension must be described using the Protobuf interface description language. These .proto files are then used to generate Rust modules, which handle the (de)serialization of structures described in them. Exonum 0.10 has tools to help users easily generate .rs files when building applications with Exonum and, if necessary, add validations to Protobuf-generated structures. All Exonum example services have been updated according to the new Protobuf serialization.
New Messages Format
All Exonum messages will now have a single expected format, and transactions are now a separate entity within messages. The message structure now consists of the following elements:
· The public key of the message author.
· The numeric identification of the message class and its type within the class.
· Message body containing the payload of the message, which can differ depending on the class and type of the message. Transactions now constitute one of the variants of such message payload.
· The signature of the message author.
Transactions also have the following elements that come after the identification of the message class and type:
· ID of the service for which the transaction is intended.
· ID of the transaction.
· Service transaction payload.
When defining a new transaction with the Transaction macro, users need to describe only the fields that will constitute the payload. All the other fields (e.g. signature, public key, etc.) are automatically added and handled by the Exonum Core.
The Transaction::verify method has been removed as now the validation of the message signature is performed by the core. Currently, any additional validations users require can be set up using Transaction::execute. However, an extended version of the verify method is scheduled for implementation by our team.
Flexible Round Timeouts
The timeout is no longer the same for all the rounds. The round_timeout parameter has been renamed to first_round_timeout and the timeout value for the round r is calculated according to the formula: first_round_timeout + (r-1)*round_timeout_increase. The round_timeout_increase value is a certain percentage of the first_round_timeout. It is defined in the ConsensusConfig::TIMEOUT_LINEAR_INCREASE_PERCENT constant, which is set to 10%. As a result, the timeout for each new round is slightly larger than for the previous one. If the consensus cannot be reached during the first round, the network probably is experiencing issues. The flexible timeout gives the system time to recover, not by increasing the number of rounds, but by slightly increasing their duration. It is worth mentioning that as soon as the block is finally accepted, and the consensus moves to the following height, the round_timeout parameter restores to its initial value.
Configurable Majority when Voting for Configuration
The generate-template and generate-testnet commands, which create and change the configuration, now include the majority_count parameter, meaning that users can configure the number of votes required during the consensus process when voting for changes in the configuration. By default, the majority constitutes 2/3+ of the validators in the network; however, using majority_count this value can be adjusted for cases when the configuration requires modification.
Bitcoin Anchoring to Adopt Segwit
Exonum 0.10 brought considerable changes not only to the framework core, but also to one of the most important framework instruments — the Bitcoin anchoring service. The improvement tackles service optimization through incorporation of segwit by the bitcoin anchoring transactions instead of the old knotty algorithm that required agreement of validators on the latest Exonum transaction anchored to bitcoin.
Now, the votes of the validators are separated from the anchoring transaction body. This means that they cannot affect the transaction hash and, correspondingly, cannot alter the transaction ID. In this way, the problem of transaction malleability is solved in a simpler and more consistent way than in the previous implementation. No matter what the order and number of validators signatures is, the transaction payload is always the same. This, nevertheless, does not alter the fact that 2/3+1 votes are still required to accept the transaction.
Interaction with the service has also become more user-friendly. Firstly, the information on the anchored transactions is now stored in the service database. This means the anchoring chain or information on a particular anchoring transaction can easily be extracted from the database any time by a simple API request. Previously, it had to be restored with an external observer service from the information retrieved from the Bitcoin Blockchain.
Secondly, there is no need to connect each Exonum node to the bitcoind. The anchoring transactions are generated deterministically and independently from the connection to the Bitcoin Blockchain. New anchoring transactions are constantly monitored by a separate method and forwarded to the Bitcoin Blockchain whenever they occur.
You can find more information on the updated service in the corresponding GitHub repository.
Other Core Improvements
· The v1/peers endpoint now returns more than just the addresses of peer nodes, but the hostnames and public keys of peers.
· Now users can indicate domain names instead of IP addresses as peer addresses. If the need arises to assign a new IP address to an existing domain, it can be easily done without making changes to the list of peers.
· The new version features the /v1/blocks/subscribe endpoint, which through WebSockets can notify users every time a new block has been committed.
· Peers no longer need to establish two connections — one to send requests and one to receive them. Messages can now be both sent and received through a single connection.
· The new version includes a number of bug fixes to make Exonum even more stable and secure.
The full list of features, improvements and bug fixes that constitute the Exonum 0.10 release is available in our Changelog.
As always, in case of any questions, our team is happy to help in Gitter.
Stay tuned for more upcoming news from the Exonum framework and the Bitfury Group on our Medium page.
