Our improvement methods considering the network performance.

Ubikiri
3 min readOct 11, 2019

--

Each network user expects the results of our speed test, so are we! However, it should be noted, despite the results that are reached, we still have huge reserves to increase network performance.

Today we are testing code that has not been optimized since it was written. But this can and will be done, and we will do speed tests further when we apply certain parts of the code.

So what optimization methods can we use?

1. Currently, the node processes the block two times. The first time when users vote for the block within the framework of the Consilium, the second time when they record it in the network storage, to their database. In fact, one check is enough if the block does not contain information related to smart contracts of a variable state. In most blocks there is no such information. Due to this, it is possible to halve the processing time of a block by a node.

2. At the moment, we have written code for a single-processor system, so, all operations are processed in a single thread. We want to finalize the code so that it runs in multiple threads on multiprocessor servers.

This will give a performance increase of 60% for each processor that will be processed by the code. This means the following: if within the framework of the Consilium we have productive multi-core processors deployed, this Consilium will become much more productive. To do this, we need to refine the code so that it works in multiprocessor systems.

3. Sharding. In what form can sharding be implemented? Our platform consists of many Consiliums. And when we have Consiliums that will be launched under the IoT, they will generate a fairly large number of transactions, greatly exceeding the number of transactions of the Monetary consilium. But at the moment, all this many transactions will be processed by the Monetary consilium and will be stored on its node. This is wrong and unnecessary.

Firstly, it clogs the nodes, it will require a much larger amount of space, which is needed to store all these transactions.

And secondly, it will slow down the work of the Monetary consilium itself, so that this does not happen, it is necessary to ensure that the Consiliums store only the information that they process.

Moreover, we have oracles in the network that provide information to the network and they are not included in the Consilium. Further, we have smart contracts, the results of which or they themselves should be called from different Consiliums and so on. So, in addition to sharding, it is also necessary to solve additional problems associated with cross sharding things, like the problem associated with inter-consilium interactions — this problem is no trivial, but it will be solved by us.

What performance gain does this give? Productivity will increase significantly. The more Conciliums we have, the more times we can increase productivity. Assuming more or less uniform workload. Due to the fact that the network supports a huge number of Consiliums, we understand that there is a rather large reserve here.

Once the code has been optimized, we will be able to increase the speed by 3–5 times and we are already in the process of doing so. Watch out for new speed tests in the near future.

P.S. And don’t forget to place new bids!

--

--