Blockchain in Travel Industry — Part 4: State Channels
This article is the fourth part of the article series made by TUI’s Blockchain Lab. It focuses on the basic mechanisms of the state channel technology and presents an example of how to make your own state channel on Ethereum. It is recommended to read the previous articles, but you can understand this article on its own, if you have a basic knowledge of how blockchains work.
Scalability limitations of blockchain
As mentioned in the earlier articles, blockchain technology is getting tremendous attention. Instead of discussing the reasons for this attention, I will concentrate on a limitation of the technology that has been highlighted by this popularity.
The limitation in question is scalability. While blockchain technology has a lot of well-known advantages, such as anonymity, immutability and trust granted by technology instead of a third party, it has strong limitations when it comes to speed or amount of validating transactions.
To demonstrate the size of this limitation, one of the best ways is to compare the transaction/second (tps) rate of famous blockchains and classic centralized banking solutions. BitCoin can handle around 7 transactions per second, while Ethereum is slightly faster, with a speed of 10 tps, but both are still magnitudes behind Visa’s ~2000 tps (sometimes referred to as 24.000 tps).
Possible solutions for scalability problems
It is getting increasingly urgent for blockchains to outgrow this scalability problem as decentralized applications are becoming more popular and more complex. Luckily there are multiple solutions for the problem. These solutions belong to two main categories, on-chain and off-chain solutions. I will mention some of these and give a very simplified, basic description of how they work. If you are interested in a more detailed description, you should read the article of ConsenSys.
On-chain solutions
Increase block size: One of the on-chain solutions could be to increase the block size, which would lead to an increased amount of transactions/block, and — assuming the blocktime is unchanged — an increased amount of tps. This would also make big, specified hardware houses even more compatible in mining, which could lead to damaging the decentralization of blockchains.
Sharding: Another on-chain solution is sharding. The idea of this technology is to divide the participating nodes into multiple groups and let transactions within these groups be verified simultaneously.
Off-chain solutions
Plasma: The main idea behind plasma is that, it allows multiple “child” blockchains to connect to the original chain. These child chains connect to the original chain only once, after which they can work on their own. This way they do not use the resources of the parent chain. Furthermore, they can be personalized based on their use-cases.
State channel: The idea of state channels is discussed in more details in the following chapters.
State channel 101
State channel has three main goals. Firstly, to disencumber the main chain it uses, secondly, to make payment as fast as possible and lastly, to decrease the price of transactions. These goals cannot be met using only the main-chain, therefore state channels are using their own infrastructure, which makes them off-chain solutions.
The concept is that two participating members who want to exchange crypto currencies with each other, and who have the desire to make these transactions faster and cheaper with the help of state channels, can open a channel between each other, make the transactions off-chain and then close the channel by uploading only one transaction, which reflects the latest state of their trade. This way, they only interact with the main chain when they are opening and closing the channel. This makes state channels ideal for frequent payments, or for cases in which it is not possible to wait for the verification of the main chain.
For example, if a customer is billed every month for a newspaper subscription, and annual payments are also allowed, they could open a state channel, make the transactions off-chain and only upload the end result on the main chain, when closing the channel. This way they have paid for the use of the main chain only twice, instead of twelve times.
Another possible use case is when a customer wants to buy a cup of coffee but does not have the time to wait in the coffee shop for the verification of the main chain.
To understand this mechanism better, we have to look into these three steps in more detail.
(I.) The first step is opening the channel. This means, that the two participants has to register their addresses and lock some funds in a smart contract on the main channel. Later on they can transfer the locked funds, and only the locked funds, to each other.
(II.) The second step is making the transactions. This part is completely off-chain. Users can make the transactions in almost any way they would like to. The important thing is, that they have to sign each and every transaction made and send these signed messages to each other.
For example, if Alice and Bob both locked 10 Ether in a channel and they agree that from the total 20 Ether Alice should receive 16 and Bob should receive 4, both of them should sign the message “Alice receives 16 Ether” and send the signed message to each other. The structure of the message is determined by the protocol the state channel uses.
These messages should be signed on a local machine, because the private key is required for signing, and that information should be kept secret. The last chapter shows two variations of signing, one in Python and one in JavaScript.
(III.) The last step is closing the channel. If payments have reached a conclusion and users want to close the channel, they have to upload the latest status between the participants. To use the example between Alice and Bob, if they decide to close the channel, and the last agreed upon statement was “Alice receives 16 Ether” then they would have to upload the signed version of that statement to the smart contract, which will then transfer 16 Ether to Alice and 4 to Bob.
This way they only interacted with the main-chain only twice, when opening and when closing the channel. All other transaction between the first and last will stay off-chain, which makes the series of transactions cheaper (having only used gas twice instead of using it after every transaction), and faster (the time between signing a transaction is only limited by the users, there is no need to wait for the main chain’s verification time.
Security considerations
To create a state channel would be quite easy, if one could be sure that the participants are trustworthy. One of the basic concepts of blockchain is that users want to have security without trusting or even knowing the other participants, only with the help of the technology. Therefore, we don’t have the luxury to assume the fairness of anyone who will be using a state channel. This means, when designing a state channel, we have to ask ourselves the following questions:
1) How can we guarantee that the transaction uploaded when closing the channel is really the last one?
If this criteria is not met, a cheating participant could upload an earlier state that was signed by both parties and suits the cheater better.
2) What happens if a participant leaves after we lock the funds?
If we don’t have a way to address this issue, it would be possible to have our locked funds stuck in the smart contract forever.
3) Can it cause any harm if one of the signed messages gets stolen?
This could be a problem, if Alice had two open channels, one with Bob and one with Carol. Let’s assume Alice signed the message “you will receive 16 Ether” for Bob and “you will receive 4 Ether” for Carol and Carol somehow got the message that was signed for Bob. If she could upload it, she would receive 16 Ether instead of the 4.
There are numerous ways to solve these security questions. In the last chapter, I will illustrate one of these solutions implemented in Solidity.
Existing state channels, Raiden
There already are existing state channels. Maybe the most famous one is Bitcoin’s Lightning Network, which has been online for quite some time now. Details about how it works can be found on its official webpage.
A more recent state channel is the Raiden Network. It is a state channel for Ethereum and it has gone online only on December 2018. It is still in early stages, but ready to use. It already has more than 50 channels open as of the writing of this article (March 2019). You can find more details about how it works on its official website.
The existence of an official state channel for Ethereum makes us wonder what advantages we would have by creating our own.
1) The first advantage is a deeper understanding of how the technology works. This could be an advantage even when we use Raiden or when we use the state channel of another blockchain.
2) The second advantage is customization. Raiden network is still in its early stages and it has limitations at the moment. For example, the amount of funds we can lock in a state channel is limited to 0,15 Ether. If we want to handle more than that in a state channel, we have to make our own.
3) The third advantage is price. The use of Raiden network is not free, we have to pay for the protocol and the peripheral fees. The peripheral fees are required to be paid in RDN, Raiden network’s own ERC 20 token. Meanwhile your own state channel is free of charge.
The next article shows you how to make your own state channel.
