“One more step to blockchain”: Bitfury Group presented 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 , both large companies (for example, IBM, which invested $ 200 million in IoT projects related to the blockchain) and small startups that adapt blockchains for various needs are involved in shaping the market.
Bitfury Group is releasing a new version of an open framework for developing Exonum blockchains. Exonum 0.2 contains regular fixes, as well as some constructive improvements. With Exonum, companies and government organizations can create functional blockchains that are safe, transparent, and controllable.
/ Exonum 0.2 release / exonum
')
Exonum implements a special algorithm of the Byzantine consensus (we wrote about this in one of our materials ). It does not require mining blocks and is faster - the blockchain processes 3 thousand transactions per second.
Additionally, Exonum is attached to the bitcoin blockchain. The network sends blockhech-supporting block hashs to increase security. To attack such a network, it will be necessary to overcome the mechanisms of consensus for both blockchains - supporting and closed.
The Exonum 0.2 release contains internal system improvements that simplify working with the framework, and fixes that “close” the most obvious flaws.
RocksDB is a key - value database with more features than LevelDB, which was originally used in Exonum.
We switched to RocksDB because it has a rich box functionality and is well supported by developers. Note that now Exonum works with both databases, but further work is aimed at introducing a new functionality with the final transition to RocksDB. Here are some of the planned additions:
1. Using column families . They will logically divide the database into parts (in fact, tables), streamline its appearance, ensure reliable storage and data management. In addition, changes to such a database can be applied atomically, that is, they can be registered simultaneously in several tables.
2. Using the built-in transactions in RocksDB is a handy boxed solution that was not available in LevelDB (it was implemented manually). Transactions also allow atomically applying changes to the database and have an interface like BEGIN / COMMIT / ROLLBACK. This makes it possible to manage changes in the event of problems, as well as edit data and simultaneously check conflicts.
It is worth noting that the database settings allow you to set a convenient type of parallelism at any time — pessimistic (the lines in the data source are blocked, prohibiting users from modifying data when another user is working with them) or optimistic (blocking is not performed, but the application determines whether the string has changed) .
3. Data backup (see Backups and Checkpoints ) - the ability to create a snapshot of the database. If necessary, such images can be used for both reading and reading and writing.
Backups can be performed completely, and can only for the part of the data that was changed after the last backup. Such flexible functionality makes it much easier to launch a new node in the system or update the data of the previous node after the “crash”.
4. Statistics collection - administrative functionality, which is the acquisition of dynamic characteristics of the database (volume, speed, etc.) in the form of history, and can be used for more efficient tuning, management and monitoring of the system. In particular, to select the optimal node settings.
Prior to the current release, the timeouts needed to be fixed in the configuration, and they remained unchanged in any system state. This led to the fact that the transaction blocks were accepted on the blockchain with a constant frequency, and at zero system load, the blockchain was littered with empty blocks.
For example, when setting a timeout of one second and zeroing the system, the size of one block for the system of four validator nodes averaged 472 bytes. During the day of work "idle" the system consumed 41 megabytes of disk space.
Hard fixation of the timeout led to the fact that, if its value was too low, the rate of adoption of new blocks increased. This increased the amount of resources spent on processing transactions for the formation of blocks, as well as cryptographic evidence when checking them. Accordingly, when the timeout value was set too high in the processing of incoming transactions, there were delays, and with a lot of traffic, there was a "stagnation" of raw transactions in the pool.
In the new implementation, two new options have been added for managing timeouts:
Now, based on the timeout value of the round in which the previous block was received, as well as 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, blockchains based on Proof-of-Work consensus (for example, Bitcoin) have a built-in principle of regulating intervals between blocks. Namely: in Bitcoin, the complexity of calculating a new block is automatically changed so that the block acceptance rate is always 1 block in 10 minutes. Thus, the higher the rate of adoption of blocks, the higher the complexity of the calculation and vice versa. As a result, the interval for adopting a new unit is practically independent of the total computing power of the network.
The functionality is associated with the optimization of working with memory. Previously, to encrypt data stored in different parts of the memory, it was necessary to first copy this data into random access memory (RAM), for which it additionally allocated space 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.
A complete list of changes can be found at the link . A guide to working with the platform is in the knowledge base Exonum. There you will find an example of creating services with code and comments.
Minor releases of Exonum 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 in our blog . You can ask questions to the team in Gitter (our GitHub ).
Bitfury Group is releasing a new version of an open framework for developing Exonum blockchains. Exonum 0.2 contains regular fixes, as well as some constructive improvements. With Exonum, companies and government organizations can create functional blockchains that are safe, transparent, and controllable.
')
Exonum implements a special algorithm of the Byzantine consensus (we wrote about this in one of our materials ). It does not require mining blocks and is faster - the blockchain processes 3 thousand transactions per second.
Additionally, Exonum is attached to the bitcoin blockchain. The network sends blockhech-supporting block hashs to increase security. To attack such a network, it will be necessary to overcome the mechanisms of consensus for both blockchains - supporting and closed.
What's new and change
The Exonum 0.2 release contains internal system improvements that simplify working with the framework, and fixes that “close” the most obvious flaws.
Added support for RocksDB
RocksDB is a key - value database with more features than LevelDB, which was originally used in Exonum.
We switched to RocksDB because it has a rich box functionality and is well supported by developers. Note that now Exonum works with both databases, but further work is aimed at introducing a new functionality with the final transition to RocksDB. Here are some of the planned additions:
1. Using column families . They will logically divide the database into parts (in fact, tables), streamline its appearance, ensure reliable storage and data management. In addition, changes to such a database can be applied atomically, that is, they can be registered simultaneously in several tables.
2. Using the built-in transactions in RocksDB is a handy boxed solution that was not available in LevelDB (it was implemented manually). Transactions also allow atomically applying changes to the database and have an interface like BEGIN / COMMIT / ROLLBACK. This makes it possible to manage changes in the event of problems, as well as edit data and simultaneously check conflicts.
It is worth noting that the database settings allow you to set a convenient type of parallelism at any time — pessimistic (the lines in the data source are blocked, prohibiting users from modifying data when another user is working with them) or optimistic (blocking is not performed, but the application determines whether the string has changed) .
3. Data backup (see Backups and Checkpoints ) - the ability to create a snapshot of the database. If necessary, such images can be used for both reading and reading and writing.
Backups can be performed completely, and can only for the part of the data that was changed after the last backup. Such flexible functionality makes it much easier to launch a new node in the system or update the data of the previous node after the “crash”.
4. Statistics collection - administrative functionality, which is the acquisition of dynamic characteristics of the database (volume, speed, etc.) in the form of history, and can be used for more efficient tuning, management and monitoring of the system. In particular, to select the optimal node settings.
Added support for dynamic timeouts
Prior to the current release, the timeouts needed to be fixed in the configuration, and they remained unchanged in any system state. This led to the fact that the transaction blocks were accepted on the blockchain with a constant frequency, and at zero system load, the blockchain was littered with empty blocks.
For example, when setting a timeout of one second and zeroing the system, the size of one block for the system of four validator nodes averaged 472 bytes. During the day of work "idle" the system consumed 41 megabytes of disk space.
Hard fixation of the timeout led to the fact that, if its value was too low, the rate of adoption of new blocks increased. This increased the amount of resources spent on processing transactions for the formation of blocks, as well as cryptographic evidence when checking them. Accordingly, when the timeout value was set too high in the processing of incoming transactions, there were delays, and with a lot of traffic, there was a "stagnation" of raw transactions in the pool.
In the new implementation, two new options have been added for managing timeouts:
- Dynamic - the choice takes place between the minimum and maximum timeout values depending on the system load.
- Moving Average - the option is similar to the previous one, however, it allows to determine 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 received, as well as 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, blockchains based on Proof-of-Work consensus (for example, Bitcoin) have a built-in principle of regulating intervals between blocks. Namely: in Bitcoin, the complexity of calculating a new block is automatically changed so that the block acceptance rate is always 1 block in 10 minutes. Thus, the higher the rate of adoption of blocks, the higher the complexity of the calculation and vice versa. As a result, the interval for adopting a new unit is practically independent of the total computing power of the network.
Streamline encryption implemented
The functionality is associated with the optimization of working with memory. Previously, to encrypt data stored in different parts of the memory, it was necessary to first copy this data into random access memory (RAM), for which it additionally allocated space 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.
A complete list of changes can be found at the link . A guide to working with the platform is in the knowledge base Exonum. There you will find an example of creating services with code and comments.
Minor releases of Exonum 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 in our blog . You can ask questions to the team in Gitter (our GitHub ).
Source: https://habr.com/ru/post/339142/
All Articles