October 2, 2017 at 14:22“Another step towards the blockchain”: Bitfury Group introduced Exonum 0.2
According to analytical agencies, the blockchain technology market will grow from $ 210 million in 2016 to $ 2.3 billion by 2021. The average annual growth will be 61.5%. At the same time, large companies (for example, IBM, which invested $ 200 million in blockchain-related IoT projects) and small startups that adapt blockchains to different needs participate in the market formation .
Bitfury Group Releases New Exonum Blockchain Development Framework
. Exonum 0.2 contains regular corrections, as well as some design improvements. With Exonum, companies and government organizations can create functional blockchains that are safe, transparent and controlled.
/ Exonum 0.2 Release / Exonum
Exonum implements a special Byzantine consensus algorithm (we wrote about this in one of our materials ). It does not require block mining and works faster - the blockchain processes 3 thousand transactions per second.
Additionally, Exonum is tied to the Bitcoin blockchain. The network sends block hashes to the supporting blockchain to increase security. To attack such a network, it will be necessary to overcome the consensus mechanisms for both blockchains - supporting and closed.
The release of Exonum 0.2 contains internal system improvements that simplify working with the framework, and fixes that “close” the most obvious drawbacks.
RocksDB is a key - value database with more features than LevelDB, which was used in Exonum initially.
We switched to RocksDB because it has rich box functionality and is well supported by developers. Note that now Exonum works with both databases, but further work is aimed at introducing new functionality with the final transition to RocksDB. Here are some of the planned additions:
1. The use of columns families ( column Families ) . They will allow you to logically divide the database into parts (essentially tables), streamline its appearance, provide reliable storage and data management. In addition, changes to such a database can be applied atomically, that is, be registered simultaneously in several tables.
2. Using the built-in transactions in RocksDB is a convenient boxed solution that was not available in LevelDB (it was implemented manually). Transactions also allow atomic changes to be applied to the database and have an interface like BEGIN / COMMIT / ROLLBACK. This makes it possible to manage changes in the event of a problem, as well as edit data and simultaneously check for conflicts.
It is worth noting that the database settings allow you to set a convenient type of parallelism at any time — pessimistic (rows in the data source are blocked, preventing users from modifying data when another user is working with them) or optimistic (blocking is not performed, however, the application determines whether the row was changed) .
3. Data backup (see Backupsand Checkpoints ) - the ability to create a snapshot of the state of the database. If necessary, such pictures can be used both for reading and for reading and writing.
Backup can be performed in full, or maybe only for that part of the data that has been changed since the last backup. Such flexible functionality greatly facilitates the launch of a new node in the system or updating the data of the previous node after a “fall”.
4. Statistics collection - administrative functionality, which is the receipt of the dynamic characteristics of the database (volume, speed, etc.) in the form of history, and can be used for more efficient configuration, management and monitoring of the system. In particular, to select the optimal settings for nodes.
Prior to the current release, timeouts had to be fixed in the configuration, and they remained unchanged in any state of the system. This led to the fact that transaction blocks were accepted into the blockchain with a constant frequency, and when the system was zero loaded, the blockchain was “littering” with empty blocks.
For example, when setting a timeout of one second and zero loading the system, the size of one block for a system of four validator nodes averaged 472 bytes. During the day of work "idle" the system spent 41 megabytes of disk space.
The tight fixation of the timeout led to the fact that when its value was too low, the speed of adoption of new blocks increased. This increased the amount of resources spent on processing transactions to form blocks, as well as cryptographic evidence when checking them. Accordingly, when the timeout value was set too high, there were delays in the processing of incoming transactions, and when there was a lot of traffic, “stagnation” of unprocessed transactions in the pool began.
In the new implementation, two new options for managing timeouts were added:
Now, based on the timeout value of the round in which the previous block was accepted, as well as on the number of transactions in this block, the system selects the optimal timeout value for the next block. It is expected that this will make the management of the system flexible and efficient, as it will allow to regulate its load.
Unlike Exonum, Proof-of-Work consensus blockchains (e.g. Bitcoin) have a built-in principle for regulating the intervals between blocks. Namely: in Bitcoin, the complexity of computing a new block automatically changes so that the block adoption rate is always 1 block in 10 minutes. Thus, the higher the block adoption rate, the higher the computational complexity and vice versa. As a result, the interval of adoption of a new block is practically independent of the total computing power of the network.
The functionality is associated with the optimization of work with memory. Previously, to encrypt data stored in various memory areas, it was necessary to first copy this data into random access memory (RAM), for which additional space was allocated in it corresponding to the size of the encrypted data. With the introduction of the ability to encrypt fragmented data "on the fly", additional copying to RAM was avoided, and, consequently, increased system performance.
You can find the full list of changes here . Guidance on working with the platform is in the Exonum knowledge base. There you will find an example of creating services with code and comments.
Exonum minor releases are expected once a month. The next update is scheduled for mid-October 2017. You can follow the news on product development by subscribing , or on our blog . You can ask questions to the team in Gitter (our GitHub ).
. Exonum 0.2 contains regular corrections, as well as some design improvements. With Exonum, companies and government organizations can create functional blockchains that are safe, transparent and controlled.
Exonum implements a special Byzantine consensus algorithm (we wrote about this in one of our materials ). It does not require block mining and works faster - the blockchain processes 3 thousand transactions per second.
Additionally, Exonum is tied to the Bitcoin blockchain. The network sends block hashes to the supporting blockchain to increase security. To attack such a network, it will be necessary to overcome the consensus mechanisms for both blockchains - supporting and closed.
What's new and change
The release of Exonum 0.2 contains internal system improvements that simplify working with the framework, and fixes that “close” the most obvious drawbacks.
Added support for RocksDB
RocksDB is a key - value database with more features than LevelDB, which was used in Exonum initially.
We switched to RocksDB because it has rich box functionality and is well supported by developers. Note that now Exonum works with both databases, but further work is aimed at introducing new functionality with the final transition to RocksDB. Here are some of the planned additions:
1. The use of columns families ( column Families ) . They will allow you to logically divide the database into parts (essentially tables), streamline its appearance, provide reliable storage and data management. In addition, changes to such a database can be applied atomically, that is, be registered simultaneously in several tables.
2. Using the built-in transactions in RocksDB is a convenient boxed solution that was not available in LevelDB (it was implemented manually). Transactions also allow atomic changes to be applied to the database and have an interface like BEGIN / COMMIT / ROLLBACK. This makes it possible to manage changes in the event of a problem, as well as edit data and simultaneously check for conflicts.
It is worth noting that the database settings allow you to set a convenient type of parallelism at any time — pessimistic (rows in the data source are blocked, preventing users from modifying data when another user is working with them) or optimistic (blocking is not performed, however, the application determines whether the row was changed) .
3. Data backup (see Backupsand Checkpoints ) - the ability to create a snapshot of the state of the database. If necessary, such pictures can be used both for reading and for reading and writing.
Backup can be performed in full, or maybe only for that part of the data that has been changed since the last backup. Such flexible functionality greatly facilitates the launch of a new node in the system or updating the data of the previous node after a “fall”.
4. Statistics collection - administrative functionality, which is the receipt of the dynamic characteristics of the database (volume, speed, etc.) in the form of history, and can be used for more efficient configuration, management and monitoring of the system. In particular, to select the optimal settings for nodes.
Added support for dynamic timeouts
Prior to the current release, timeouts had to be fixed in the configuration, and they remained unchanged in any state of the system. This led to the fact that transaction blocks were accepted into the blockchain with a constant frequency, and when the system was zero loaded, the blockchain was “littering” with empty blocks.
For example, when setting a timeout of one second and zero loading the system, the size of one block for a system of four validator nodes averaged 472 bytes. During the day of work "idle" the system spent 41 megabytes of disk space.
The tight fixation of the timeout led to the fact that when its value was too low, the speed of adoption of new blocks increased. This increased the amount of resources spent on processing transactions to form blocks, as well as cryptographic evidence when checking them. Accordingly, when the timeout value was set too high, there were delays in the processing of incoming transactions, and when there was a lot of traffic, “stagnation” of unprocessed transactions in the pool began.
In the new implementation, two new options for managing timeouts were added:
- Dynamic (Dynamic) - the choice occurs between the minimum and maximum timeout value depending on the system load.
- Moving Average - the option is similar to the previous one, however, it allows you to define intermediate timeout values in accordance with the rule of the same name .
Now, based on the timeout value of the round in which the previous block was accepted, as well as on the number of transactions in this block, the system selects the optimal timeout value for the next block. It is expected that this will make the management of the system flexible and efficient, as it will allow to regulate its load.
Unlike Exonum, Proof-of-Work consensus blockchains (e.g. Bitcoin) have a built-in principle for regulating the intervals between blocks. Namely: in Bitcoin, the complexity of computing a new block automatically changes so that the block adoption rate is always 1 block in 10 minutes. Thus, the higher the block adoption rate, the higher the computational complexity and vice versa. As a result, the interval of adoption of a new block is practically independent of the total computing power of the network.
Stream encryption implemented
The functionality is associated with the optimization of work with memory. Previously, to encrypt data stored in various memory areas, it was necessary to first copy this data into random access memory (RAM), for which additional space was allocated in it corresponding to the size of the encrypted data. With the introduction of the ability to encrypt fragmented data "on the fly", additional copying to RAM was avoided, and, consequently, increased system performance.
You can find the full list of changes here . Guidance on working with the platform is in the Exonum knowledge base. There you will find an example of creating services with code and comments.
Exonum minor releases are expected once a month. The next update is scheduled for mid-October 2017. You can follow the news on product development by subscribing , or on our blog . You can ask questions to the team in Gitter (our GitHub ).