2018 will be the year of infrastructure development for Ethereum. The popularity of the platform has revealed its problem areas, and now it is necessary to direct efforts to achieve system scalability.
Ethereum is still in its early stages of development. Today it is neither secure nor scalable, and this is clear to anyone who understands the technologies it uses. The prospect of Ethereum and Web3 - a secure and easy-to-use decentralized internet used by billions of people - is still looming on the horizon and will not become a reality until the key infrastructure is in place.
Projects whose goal is to develop the infrastructure and expand the capabilities of Ethereum are known as means of improving scalability. Such projects can affect different aspects of the platform and are often compatible with each other.
In this article, I want to consider in detail one of the categories of such tools - off-chain and second-level solutions.
Firstly we will discuss the scalability issues of Ethereum (and other public blockchains).
Secondly, we will look at various ways to solve this problem and understand the difference between layer 1 and layer 2 protocols.
Thirdly, we will look in more detail at specific examples of second-level solutions, namely, centralized channels (state channels), Plasma and Truebit.
1. Scalability Issues for Public Blockchains
First, you need to understand that scalability is not an isolated problem. These are a number of obstacles that prevent Ethereum from being useful to billions of people around the world.
Transaction processing speed is the most frequently discussed scalability issue. Currently, Ethereum can process approximately 15 transactions per second, while Visa has a throughput of 45,000 transactions per second. Last year, a popular game like Cryptokitties or ICO was enough to slow down network speeds.
The basis of this problem lies in the fact that public blockchains like Ethereum require every transaction to be processed by every node on the network. This is the fundamental limitation of the transaction processing speed in Ethereum - it cannot be higher than that established for each node.
We could “ask” each node to do more work. If we doubled the block size, this would roughly mean that each node would work twice as hard to process each block. In this case, decentralization suffers - by requiring more computing power from nodes, we thereby force many network participants with weaker computers to leave the network. Mining is becoming more centralized and controlled by large pools.
There are two possible solutions to this problem:
I. What if we do not require parallel processing of one transaction by all nodes?
What if we could build a blockchain where every node wasn't required to process every transaction? Instead, could it be possible, for example, to divide the network into two sections, each of which could operate semi-autonomously?
For example, section A would process one part of the transactions, and section B would process the other. If you divide the blockchain into many such sections, then the speed of its operation will increase significantly. This idea is the basis of sharding, a scalability tool that Vitalik Buterin, the Ethereum Research group, and many others are working on. Sharding is a layer-one solution because it is implemented at the base level of the Ethereum protocol itself.
II. What if we could modify operations while maintaining Ethereum's current processing speed?
The second approach is exactly the opposite of the first. Instead of increasing the throughput of the Ethereum blockchain, what if we could somehow change the operations being performed?
This is exactly what so-called off-chain technologies such as centralized channels, Plasma and Truebit do. While each of these technologies addresses different problems, they all operate “outside” the Ethereum blockchain with a reasonable level of security.
Such technologies are also known as second-layer solutions because they are a kind of “add-on” to the main Ethereum chain. These solutions do not require changes to the underlying protocol.
2. Second-level solutions in cryptoeconomics
Consensus in cryptoeconomics is one of the fundamental concepts in public blockchains. Using software and cryptography, we can create entire networks of computers that are guaranteed to agree on the internal state of the system. The consensus gives us confidence that unless something extreme happens, such as a 51% attack, then all operations such as payments and smart contracts will be carried out.
We could use these technologies that we trust as a fulcrum and add new economic mechanisms. Such second-layer economic mechanisms could allow us to transact off-chain, accessing it when needed. Of course, their level of reliability and completeness of operations is somewhat lower than that of the basic protocol, but such off-chain products could be very convenient.
I. Centralized channels
Centralized channels (state channels) are a technology for conducting off-chain transactions. At the same time, operations carried out inside such channels have a high degree of reliability and completeness.
Many readers are familiar with the idea of payment channels, which is used in Bitcoin through the lightning network. Centralized channels are a more general form of payment channels - they can be used not only for payments, but also for other actions, for example, making changes to smart contracts. Centralized channels were first described by Jeff Coleman in 2015.
Let's look at the principle of operation of these channels using a simple example. Let's say Alice and Bob are playing tic-tac-toe where the winner gets 1 eth. A naive way to do this is to create a smart contract on Ethereum, where you can enter all the rules of the game and the moves of your opponents. Every time someone walks, data needs to be sent to the contract. When a winner is determined, the contract pays him 1 eth. This method will work, but it is slow and inefficient, because Alice and Bob will use the entire Ethereum network. Moreover, when one of the players takes a step, they must wait for a new block to form before taking the next step. Instead, we can design a system in which Alice and Bob can play tic-tac-toe with a minimum number of on-chain transactions using a centralized channel.
To do this, we first create a smart contract called “Judge” in the Ethereum blockchain. This contract understands the rules of the game, knows the players and has a prize clause of 1 eth. Then, Alice and Bob start playing. Alice creates and signs a transaction describing her first step and sends it to Bob, who also signs it and sends back the signed version, keeping a copy for himself. Bob then creates and signs a transaction describing his first step and sends it to Alice, who also signs the transaction and sends it back, keeping a copy for herself. So, step by step, they update the progress of the game. Each transaction contains a nonce, so you can always track the sequence of steps.
As we can see, these transactions are not recorded on the main Ethereum chain, but all this information can be sent to the Judge contract. When the game is over, Alice and Bob simply close the channel by confirming the final result, and the data is sent to the Judge contract, while only one transaction is paid for. The judge verifies that the final result is signed by both parties, then pauses briefly and sends the reward to 1 eth. This pause is needed to check that there is no disagreement between the parties. If there is a disagreement, the nonce is used to calculate the latest version.
Despite all their usefulness, centralized channels have certain limitations and disadvantages.
For example, a continuous Internet connection is important to confirm the status before closing the channel. Centralized channels perform best in situations where frequent changes in states over a long period of time are necessary. Opening a channel is not free, but the cost of channel operations is very low. It is better if the number of participants is agreed upon in advance. Adding/removing participants requires changing the smart contract. Centralized channels have high confidentiality since only the first and last transactions are public. Finally, transactions in such a channel must be completed—once both parties sign off on a state change, it must be considered complete.
Our L4 team is developing an environment for creating universal centralized channels for Ethereum called Counterfactual. Raiden is another notable project working with centralized channels.
II. Plasma
On August 11, 2017, Vitalik Buterin and Joseph Poon published a working description of the project entitled Plasma: Autonomous Smart Contracts.
Like centralized channels, Plasma is based on off-chain transactions, using the main blockchain as a security guarantor. But Plasma works in a different direction, allowing the creation of child blockchains on the main Ethereum blockchain. In turn, these child blockchains can create their own child blockchains, and so on ad infinitum.
As a result, many complex calculations can be performed by child-level blockchains with minimal data exchange with the root network.
To understand how Plasma works, let's give a simple example. Imagine you are creating a card game on Ethereum. The cards are non-fungible ERC 721 tokens (like in Cryptokitties), but with these cards players can fight each other like in Hearthstone or Magic the Gathering. Performing such operations on the Ethereum blockchain is expensive, so Plasma comes to the rescue.
First, we create a number of root smart contracts in the main network, on the basis of which we will create our child blockchain. This child blockchain will have its own consensus algorithm, for example, PoA (Proof of Authority), in which only the validator has the right to write to blocks. Blocks are formed by a mechanism similar to mining using the PoW protocol. To simplify the example, let’s imagine that we are the only ones creating new blocks; let’s say our company has several nodes, which are validators in the child blockchain.
After the child blockchain starts operating, validators periodically send messages to smart contracts on the main network, in which they transmit information about the latest blocks generated in the child blockchain. Data about these blocks is recorded in the root blockchain as proof of transactions in the child.
The cards in our game will be ERC721 tokens created in the Ethereum root network and then moved to the child network. Here lies an important operating principle: Plasma allows you to effectively work with digital assets, but these assets must first be created on the Ethereum root blockchain. After this, we create a number of smart contracts in the child blockchain, which contain information about the rules of the game.
When a user wants to play our game, he will only interact with the child blockchain. Buying and selling cards, game rounds and other actions will take place without a direct connection to the main network, which will significantly reduce the cost of one transaction and increase the speed of work.
Is it secure?
Will transactions carried out on such a child blockchain actually be completed? In a situation where one company controls a subsidiary blockchain, decentralization is lost. Wouldn't it turn out that the company could easily take away the cards from its users at any time? Plasma provides for this situation, so users can always withdraw their funds to the main blockchain.
Consider a situation where a node on a child blockchain tries to create a block with false information that your funds are going to it. This block will need to be registered in the Plasma root contract. In this case, the user (rather, the application acting on his behalf) will be able to identify the attempted theft and withdraw funds before they are “stolen.” In addition, Plasma has a fraud reporting mechanism that every user can use. Such a statement is submitted to the root smart contract of the child blockchain, and if fraud is confirmed, the system rolls back to the previous block. In this case, the node that published such a block with false information is fined and loses its deposit in the main network.
The situation described above is possible if users have access to the history of block formation. What if validators do not provide information about previous blocks so that the user cannot use them as proof of fraud and submit a claim?
In this case, the user can only withdraw his funds and exit the child blockchain. The user provides “proof of funds” to the root contract. When withdrawing, time is given to challenge this evidence (for example, the user spent the funds, and information about this is contained in a valid block), after which the funds are returned to the main network.
There are also risks when withdrawing funds. Suppose , all users of the child blockchain will want to withdraw funds at the same time. The throughput of the main Ethereum blockchain simply may not be enough to process all transactions and there is a possibility of users losing funds. Finally, it is worth noting that in child blockchains, all validators are not necessarily controlled by one company. The process of creating new blocks can be decentralized and closer to public blockchains.
When comparing centralized channels and Plasma, you can find several significant differences. For example, centralized channels allow you to withdraw funds instantly as soon as the parties have reached such an agreement. This is not possible in Plasma, where the withdrawal process necessarily involves a temporary block. Centralized channels should be cheaper and faster than Plasma, so it is likely that centralized channels will be created within Plasma's child blockchains.
III. Truebit
Truebit is a technology that allows complex off-chain calculations. Truebit will not allow us to make more transactions, but it will allow applications on Ethereum to perform more complex actions that will be verified by the main network. This technology is suitable for transactions that are too expensive to perform on the main blockchain. For example, with Simplified Payment Verification (SPV) from other blockchains, Ethereum smart contracts could verify that such a transaction took place on another network (for example, bitcoin or dogecoin).
Let's look at this technology with an example. Imagine that you need to carry out some calculations, for example, an Ethereum application must include SPV. You can't just add such a check to your smart contract on the main blockchain because it requires serious computing power. Blocks in Ethereum have a maximum gas limit, which sets the amount of computation of all transactions in one block. But SPV requires such computing power that even if there was only one transaction in a block, the maximum gas limit would be exceeded several times. Instead, you simply pay a small fee to the solver to perform this off-chain operation. The solver transfers some funds as collateral for the smart contract, performs calculations and sends their result. If the result is correct, then he gets his deposit back. If the calculations were not made correctly due to an error or malicious intent, the deposit is lost.
To check the correctness of calculations Truebit has a verification mechanism (verification game). For this purpose, a group of validators (challengers) is created, which check the work of the solvers. If the validator was able to prove that the solver made a mistake, then he receives a reward, and the solver loses his deposit.
Conclusion
All second-layer solutions have a similar focus: they add functionality using the main blockchain as a guarantor of reliability. These solutions are designed to help Ethereum serve its huge customer base more efficiently. Solutions such as centralized channels and Plasma will increase system throughput, and Truebit opens new boundaries by expanding the capabilities of smart contracts and making complex calculations accessible.
The three technologies described are only a small part of the possible means of scalability in cryptoeconomics. This article does not cover proprietary inter-blockchain protocols such as Cosmos or Polkadot.
Layer 2 solutions are a powerful argument in favor of programmable blockchains like Ethereum—a scripting programming language is required to create applications that extend the capabilities of the network. It is much more difficult to create such applications on blockchains like Bitcoin due to the limited possibilities of using scripting languages.
Summary
Ethereum is at an early stage of development, so developing infrastructure and expanding the capabilities of the network are key tasks today. Layer 1 solutions such as sharding are implemented at the base layer of the Ethereum protocol itself. Off-chain solutions of the second level will significantly increase the network capacity without modifying the main blockchain.
Second-layer solutions such as centralized channels, Plasma and Truebit add functionality using the underlying blockchain as a guarantor of reliability. Centralized channels are especially suitable in situations where multiple transactions need to be carried out between pre-agreed participants over a long period of time. Plasma allows you to create child blockchains based on the main Ethereum blockchain. Truebit can expand the functionality of Ethereum applications by adding the ability to perform off-chain calculations that cannot be performed on the root network.
Second-layer solutions are a powerful argument in favor of programmable blockchains like Ethereum, where the use of scripting languages allows you to expand the capabilities of the network.
