Developer Update: Lition Testnet 0.8 live [DevBlog]

Here at Lition, we are always focused on moving forward and we are pleased to announce that our private testnet v0.8 is now live and running. Our development team has been hard at work over the last few months, and have successfully tested the private testnet over the last couple of weeks without any major problems.

The environment consists of 4 nodes deployed on either Microsoft Azure or DigitalOcean, and to find out more on our smart contract interactions, consensus algorithms considerations, and dynamic account whitelisting, please read our update article. As ever, stay tuned to our social media channels to keep updated with all the latest developments.

What we have accomplished so far:

Simplified deployment

The core instrument of the whole deployment process is a docker image with all the necessary binaries for running a Lition node, and these images will be prepared before each announced release. The only thing that users need to do is to run the Lition setup script, which takes care of downloading the latest image, creating configuration files, asking for some required input like the sidechain ID you want to connect to, your IP address, and starting up the node.

BFT instead of RAFT consensus algorithm

There are multiple articles that explain RAFT and BFT algorithms in great details. We decided that BFT is more reasonable for our use case than the RAFT because of several reasons:

• Anyone who vested into the sidechain can join as validator — therefore it is not strictly closed-membership consortium
• Validators might be malicious
• Validators can be trusted only partially
• BFT provides protection against malicious behaviour while RAFT provides protection only against node crashing

“Semi-”automated sidechain creation and joining

Two different levels should be considered when thinking about sidechain creation and joining.

One is the “smart-contract” level, where every sidechain must be manually registered in the Lition Registry contract and everyone who wants to take part must either vest (validators) or deposit (users) LIT tokens into it.

The other is the “node” level, which is fully automated. When a user starts up the node, his account is automatically validated against smart-contract. Only those who vested can create or join as validators in the sidechain and only those who deposited can join as users.

Dynamic accounts whitelisting

In Lition there are basically no transaction fees on the “Node” level. However, there is a gas limit for each transaction, only the gas price is zero :) One might ask, if there is no transaction fee, what if i just send hundreds of thousands of transactions into the network every second and fill up all blocks with spam?

Here is where the Lition Registry contract comes in. Transactions fees are calculated in the contract at the end of each notary window (see explanation below) based on the gas limit of the original transactions. Validators are rewarded and users pay fees in LIT tokens. As mentioned in the previous section, if someone wants to join the network as a user, he must deposit LIT tokens into the sidechain. The minimum required amount is big enough to cover all transactions the user might send into the network that would fill up every block during one notary window so it would be quite expensive to do.

As soon as the user runs out of deposited tokens, every node receives a signal from the Lition Registry contract and removes his account from the whitelist. All his new transactions are then rejected on the “Node” level. If he wants to use the sidechain again, he must deposit more LIT tokens and so on…

Notary Window

The term “Notary Window” in Lition represents a period of time, exactly 1 hour (720 blocks). After this period, a “Notary” function on the Lition Registry contract is called, where mining rewards are calculated and transferred to the validators + users deposits are reduced based on their usage.

Microsoft Azure TCP connection bug

There is a pretty nasty bug in Azure that took us many many working hours to figure out. It was particularly hard to debug as there was no obvious pattern to when it was happening.

When we deployed a node on Azure, everything was working well, but after a few minutes the connection implemented through websockets to the Lition Registry smart-contract stopped working. We couldn’t figure out where the problem was because cases such as lost connections or any kind of error were correctly handled in the code and there was no error message, simply nothing…

We tried a bunch of fixes that led nowhere. After a few days we found out that it is not happening on DigitalOcean and that was the start of finding the right solution. Thankfully, someone had to solve the same problem before and we came across this article which describes the core of the problem.

In short, Azure keeps a stateful NAT table even for public IPs for connections to/from the VM instance. Such connections are cleaned-up from this table after 4 minutes of inactivity, but client’s packets are acknowledged even if they aren’t going to be delivered. As a result, a client thinks his connection is totally ok, but nothing is delivered and it hangs in this weird state where nobody knows what is going to.

On top of that, we found out during this marathon for finding the proper solution that there is also a problem in golang net library with sending KeepAlive messages, which might cause some troubles too.

The solution was to use setsockopt through golang and set KeepAlive messages period on TCP Stack level. Finally, everything is working like a charm.

Outlook for the future

Our developers are currently in the process of finalizing some of the described features, especially the “notary” functionality. The next release should include:

• Publishing repositories with source code
• Providing proper documentation with tutorials
• Small fixes and improvements