The software team of the Bitfury Group saw off the first month of 2018 with another Exonum framework release. The product has undergone considerable changes in the core part as well as acquired some new external functionality. So, this time exclusive attention from Exonum-based service developers will be required.
Time Oracle Service
Having raised numerous discussions among the developers, the service has become the most eye-catching item of the latest release. The oracle is aimed to meet the needs of the designers of the practical blockchain solutions who required that the calendar time should be included into the blockchain.
First of all, implementation of the oracle as a separate plug-in service ascertained its modularity without overloading the framework core code. The service operates by collecting authenticated timestamps from the validator nodes and aggregating them into a single consolidated timestamp, which can be used in business logic by other services. In the same way as Exonum consensus, the service is tolerant to the Byzantine behavior of up to 1/3 of its validator nodes. It counts upon the fact that in the system with no more than
f Byzantine nodes (where
f = (n - 1) / 3), a timestamp with the 1-based index in the
[f + 1, 2f + 1] interval from the vector of timestamps, ordered by decreasing time value, is reliable. Reliability means that there exists an honest validator with the timestamp lesser or equal to the consolidated timestamp, and one with the timestamp greater or equal to it.
Besides, the time determination algorithm was designed in the way to ensure similar time values on all nodes that would be fairly accurate and allow for its monotonous increase. All this simplifies use of the oracle when implementing the business logic of a particular blockchain-based service.
Meanwhile, it should be noted that as far as the time value is indicated as an index in the Exonum storage, the service end-users might require an extra opportunity to check accuracy thereof. Such proofs should be implemented independently in the form of cryptographic checks.
You can find more information on the time oracle service and its algorithm on GitHub.
Further, as forecasted above, a bunch of usability improvements relating to the framework core code have been introduced so far. Below we provide a quick overview of the most outstanding ones.
- Use of
encoding_struct!macros for declaring transactions has been simplified. Previously transaction fields sizes and offsets were indicated manually, thus, representing quite a challenge during coding. Currently, although being a breaking change, with said functionality implemented within the macros, the coding has become impressively smoother;
infomethod has been removed from the
Transactiontrait which now inherits from
ExonumJson. In other words, currently on receiving a request, blockchain explorer automatically obtains information relating to the transaction from the blockchain, while previously absence of the
infomethod within the trait resulted in the
- The maximum message size has become configurable as opposed to being hardcoded as a constant, which introduced some additional flexibility in service development. The idea behind the implementation was to avoid situations when valuable service messages are ignored due to their excessive size and, consequently, the service code has to be considerably reworked;
- Cross-Origin Resource Sharing (CORS) support has been introduced to assist developers of web-applications written in Java Script. CORS is a mechanism that uses additional HTTP headers to provide the web-application of interest with the permission to access the selected resource from a server on a different domain (e.g. Exonum) than the one currently used by the application. For instance, this enables a JS-based web-application to send a request for the wallet status to the Exonum server and get an immediate response without any restriction.
There are also a couple of introductions that are still to be further elaborated but, nonetheless, are worth to be mentioned so far:
- A new healthcheck endpoint has been introduced to determine the status of a node, whenever required. Currently the check provides a binary (“true”/ “false”) response corresponding to the “active”/”inactive” node status. The issue is to be further addressed and amplified in future software versions;
- An experimental serialization support of floating-point types has been added along with the fixed-point arithmetic. This feature provides end users with greater flexibility in scaling their data stored in the blockchain.
Finally, the full list of Exonum core updates is available at its regular page on GitHub, however, this time in a diverse and more deterministic manner. The new changelog format provides better understanding of the quality and nature of the introduced features, fixes and adjustments.
We suggest that developers should pay particular attention to the “Breaking changes” section of the Changelog as the issues addressed therein should get particular treatment in the frame of existing services support.