Since the beginning of the year, we’ve been taking the final steps to enable the full-fledged testnet launch. We’ve worked on the development of our Proof-of-Service consensus, test node synchronization, voting mechanism implementation, and troubleshooting of transaction processing. We’ve also expanded our protocol with new libraries and introduced the ability for third parties to pay for certificates issued to users.
Here’s a quick summary of our major updates during this period.
Consensus algorithm
The consensus at the moment is capable of synchronizing blocks between nodes that are included in the network and voting for these blocks. Here’s how it works:
- Nodes offer their blocks.
- Nodes try to agree on which block they will vote in a pseudo-random manner.
- If more than ⅔ of nodes have agreed to accept one of the blocks, then a second and final vote takes place and then the block is recorded in the blockchain.
- At the output, we get the identifier of the block that was received and the list of nodes that voted for it.
We use Kubernetes for testing, which is enough to create a local cluster of two masternodes. But the performance of the local machine allows you to test no more than 2–3 nodes; the rest needs to be done in the cloud.
Masternodes voting mechanism
We have developed a mechanism for storing and exchanging votes between masternodes. Now they can vote for blocks. To do this, we use the protobuf framework, which works like a model in which you can enter data and send to other nodes. There is functionality for counting and informing all participants about the voting process and its results.
New library development
- Java library is already available for tests and integrations. It provides similar functionality as JS and .NET libraries. Check out our recent blog article about its release.
- We’ve continued expanding the functionality of our Python library. This time we’ve introduced some additional features:
- obtain information about blocks, batches, states, transactions in the blockchain,
- manage atomic swap transactions on the blockchain side,
- subscribe to and unsubscribe from real-time fetching information about transactions in the blockchain like tokens transferring, atomic swap transactions, batch and blocks arriving,
- create X.509 certificate, store and revoke its public key.
Transaction processing mechanism troubleshooting
We have improved transaction processing performance by reducing the number of database requests. The same types of transactions are saved in cash, which allows you to increase the throughput of the nodes and consequently speeds up the exchange of data in the network. The capacity of the protocol to process transactions has increased by 2.5x.
Paying for other key implementations
Any service that wants to integrate with the blockchain can allow its users to conduct transactions through this service, which will pay for them, and they will store their keys in the system for free or pay for them in fiat currency, depending on the business model.
Masternode calculator
We made a calculator for masternodes, where you can enter the initial values (balance, how much money will be on the masternode account, how will the money be withdrawn) and calculate the rate of return on investment.
Sawtooth upgrade with more mature Rust SDK
We are happy that Hyperledger Sawtooth has presented framework release 1.1 that contains a consensus engine and more mature Rust SDK. This is important for us due to the fact that we are at the stage of active implementation of our consensus.
Stay tuned and follow discussions in Gitter — spring promises to bring a lot of fruitful news for the tech community.
.png)
