The scalability of not only Ethereum, but basically every blockchain is a problem that nobody wanted to hear about and feared it till 2017, when the project Cryptokitties exponentially gathered popularity and started to slow down the network and got the prices of gas so high that everybody agreed that this should be the problem no.1.
Talking about Cryptokitties is beating a dead horse now, as this topic was spoken of in every crypto-news for months. Aside from its popularity, Cryptokitties has shown us one very important thing. The state of the Ethereum network has been shown to not be ready for an enormous number of users and traffic, which comes with the launch of a successful Dapplication. Thus, it is necessary to find the solution of this problem and that is the topic of this article.
Source: Unsplash.com
Trilemma
There is a theory of blockchain technology that the network can only support two of these three options at once: security, decentralization and scalability. This “trilemma” was and is a big challenge for Ethereum developers, as they always want to keep two basic principles of the blockchain technology — decentralization and security, while trying to adapt this technology and “humanize” it (UX) for the masses. There are some proposed solutions, but they are compromising the most basic principles, the aforementioned decentralization and security.
Utilizing altcoins was one of the first theorized solutions of the scalability problem. The principle is to abandon the idea of one blockchain, where all the operations are made, and instead utilize a model of several altcoins co-existing, of which every altcoin uses its own ledger. This reduction of operations per blockchain and creation of separate blockchains — sidechains for every dapplication should help the scalability of any blockchain. It doesn’t solve the trilemma problem though. Because of the lower number of nodes per network in every such sidechain comes the higher probability of attacks and noxious users in the network. Thus, such a solution, although solving the scalability problem, seriously compromises its security.
There is another proposed solution — Increasing block size. If the Ethereum community would vote for increasing the block size, all nodes on the network would process all the operations on the network as they were, but they would process more transactions in the same time. This would lead to a larger operation efficiency — in layman’s terms, increasing the speed of the network. The bigger block size requires more energy though. It would mean that only a small number of miners would be able to continue operating. The future would be that only a small group of supercomputers will run the network, leading to a centralized network.
The main goal of the blockchain technology has always been decentralization and security. The main obstacle now for scalability is the fact that every node in network processes every transaction. This process is undeniably secure and decentralized, but it doesn’t give us much space for growth. Here comes the trilemma problem. Are we able to adapt the Ethereum technology for our dapplications in such a way that we won’t compromise security and decentralization, and still be able to scale it?
There are four protocols in development right now, which are solving this problem right now — Sharding, Plasma, Raiden. The fourth one — Casper, is also noteworthy, but it’s developed within the Ethereum protocol, and that is a topic of its own.
In this article we will discuss sidechains and scalability solution named Plasma (briefly), introduced 10.8.2017 by Vitalik Buterin and Joseph Poon.
Plasma in a nutshell
Like Bitcoin Lightning Network, Plasma introduces the solution, or a method of processing off-chain transactions, while the security of these operations is provided by the “mother” blockchain, in case of Plasma technology the Ethereum blockchain. Plasma allows creation of “child” blockchains, which are still connected with the “mother” blockchain. These “child-chains” can also create their own “sun-child-chains”. Plasma and sidechains are in principle branches of several chains connected to their mother-chain. The processing of smart contracts will work the same way as on the Etherum network with the exception that only the result is saved on the main chain, i.e. only the outcome is projected on the main chain. We can imagine it as a hierarchical structure of blockchain, periodically processing information back to the mother chain.
Ultimately it shows us that thanks to the minimal number of nodes in the sidechain and because of the faster speed and negligible costs of gas we can process more complex operations, i.e. more complex code in smart contracts, where only the end results projects back into the main chain, Ethereum in case of Plasma. This enables developers to create whole applications based on the blockchain technology with thousands of users, without the issue of scalability or other limitations.
What are the main advantages of Plasma?
- Plasma helps Ethereum to process much bigger datasets that it is available to do now
- Thanks to the vast increase of transaction capacity/throughput it allows applications with more complex operations to run on blockchain
- Lower number of nodes processes only the transactions from sidechain, this leading to negligible per-transaction costs
- Plasma will allow us to get rid of useless data, for now stored on the main chain. This will save a vast amount of energy and the memory capacity on the main-chain nodes.
- Plasma is compatible with different on-chain scalability solutions such as sharding, different block sizes etc.
Plasma in use — Plasma Cash and DAppChain
Right now, the whole dapplication ecosystem suffers from inefficiency, in the way of mixing the financial transactions with transactions in the form of launching functions on smart contracts and interacting with dapplication functionality, be it an instruction in the smart contract or transferring millions of dollars between wallets, every such transaction is processed with the same level of security. This is not a problem in itself. The security is always on the first place, as a smart contract command can be worth millions. The problem is the scalability and situations, where commands in smart contracts aren’t just releasing funds, but also just data manipulation or some update. Is like paying for a premium functionality, whilst only needing a basic one. Not every transaction in dapplication requires the same level of security. Attacker or a hacker has much less interest in exploiting and harm transactions within dapplication where we talk about micro-transactions, than in for example attacks like double-spending, which can several million euros in value.
Loom Network
Exactly this problem — the scalability of Dapplications problem solves the Loom project and their DAppChain. DAppChain as another layer above Ethereum blockchain. The main philosophy of Loom DappChain is to create a separate sidechain for every dapp, which functions parallel to the Ethereum mainchain and with assets secured through the Plasma technology.
1 dapp = 1 sidechain
According the Loom sources, this philosophy 1dapp=1sidechain brings several advantages. First advantage can be the utilization of an alternative consensus mechanism, for example DPoS = Delegated proof of Stake, which will bring a significant optimization of the chain scalability. The second advantage is using the Ethereum blockchain as a core sidechain, which allow tokens as ERC20 and ERC721 to work on the sidechain and communicate with Ethereum blockchain thanks to Plasma. According to Loom, the implementation of the aforementioned Delegated Proof of Stake consensus allows to develop robust dapplications with transactions, which are “gas-less” meaning that they are without usual costs of gas, which is required on Ethereum mainchain and also these transactions go through in a split of a second. This setup allows to develop dapplications, which weren’t very effective on the ordinary chain, alternatively very expensive, such as games or token economy in games, or whole decentralized social networks.
The role of Plasma, in this case, is to secure the confidence between the main Ethereum chain and DAppChain, f.e. transferring ERC20 or ERC721 tokens from Ethereum mainchain to DAppChain and back again, without the need of putting the trust into the consensus mechanism on DAppChain. But let’s get away from theory and into practice, and let’s show this on the real example.
Loom Transfer Gateway
Author’s notice — this tutorial is written with more experienced blockchain and Ethereum developers in mind. If you are just starting, I’d recommend you to start with TruffleNetwork.
Transfer Gateway represents the gate between Ethereum blockchain and Loom DappChain The gate for token transfer on the sideway and their subsequent transfer back on Ethereum mainchain. According to the official Loom network documentation, only ERC721 token standard is supported right now, and the support for ERC20 should be implemented soon. With small changes although, we are able to transfer ERC20 already, which also means ERC223, between mainchain and sidechain. Before we proceed to the code, let’s start with explaining what exactly Transfer Gateway is and how it works.
- Gateway smart contract on the Ethereum blockchain side
- Gateway smart contract on Loom DAppChain side
- Address mapper smart mapper on Loom DAppChain side
- Loom Gateway Oracle as a standalone process
Every wallet address on the Ethereum blokchain that wants to interact with Loom DAppChain has to be paired with it. Basically, the token transfer automatically creates a pairing address of the wallet on the Loom DAppChain.
To allow user to transfer his tokens on DappChain, he has to transfer them first on the Gateway smart contract on the Ethereum blockchain, which then emits “deposits event” — the information that the user sent tokens on the Gateway smart contract. This deposit event is then picked up by the Gateway oracle, which role is to observe these events to the smart contract on the Ethereum blockchain and inform about these events the Gateway smart contract on the Loom DappChain side. As soon as the Gateway smart contract on the Loom side has an information about the deposited tokens on the Ethereum Gateway, Loom DappChain Gateway creates a clone of these tokens on the side of Loom DappChain.
Source: https://loomx.io/developers/docs/en/
If the user wants to transfer his tokens back to Etherum blockchain, he has to transfer them on Loom DappChain gateway first, which will create a demand for token withdrawal, ready to be signed. Gateway oracle will pick up this demand, signs it and forwards this signing information to Loom gateway, which notifies the user that his tokens are ready on Ethereum Gateway, and he is able sign the withdrawal of these tokens via transaction back to his wallet.
Source: https://loomx.io/developers/docs/en/
For better understatement how Loom chain works, let’s progress to the code. You can clone the source code to launch your own Dappchain from my Github repository.
Minimal requirements:
- node >= 8
- wget
- nc (to control occupied ports.)
- MetaMask
- Let’s start with cloning the repository:
After cloning the repository, we will see the file structure as
├── dappchain ├── truffle-ethereum ├── truffle-dappchain ├── transfer-gateway-scripts └── webclient
- dappchain — contains binary to loom dappchain, dappchain oracle and a config file
- transfer-gateway-scripts — JS script, which takes care of wallet address mapping
- truffle-dappchain — Ethereum core loom dappchain, contains source code for smart contracts and scripts for deploy
- truffle-ethereum — Local Ethereum chain na Ganache, for testing and mainchain simulation contains source code for smart contracts and scripts for deploy
- webclient — contains UI components and logic between mainchain and dappchain
After clong the repo we can install all the required components by launching a script:
After setting up all the packets goes without any issue, we are prepared to launch sidechain
Transfer gateway script and start command will launch local servers and launch deploy for Ganache Ethereum blockchain and Loom dappchain. Deploy is provided by Truffle. Who went across TruffleNetwork in the past, will easily understand how the sidechain works and how to modify it eventually.
To interact with dapplication we have to install Metamask. As we are going to interact with the local instance of blockchain, we must switch Metamask on localhost network, default setup on port 8545.
After switching the network, we import a default account automatically generated by Ganache instance with the help of this privatekey:
0xbb63b692f9d8f21f0b978b596dc2b8611899f053d68aec6c1c20d1df4f5b6ee2
There isn’t enough space to go through the whole source code here, otherwise this article would turn into a Dicken’s novel, so I will select several key parts, which I will describe in a nutshell. The structure and the code itself is very easy to understand, so more capable JS programmer will understand relations very quickly. Alternatively, the whole official Transfer Gateway documentation is available, which will surely help.
Let’s start with yaml file config from the first file “dappchain”. The file contains all the actual redirections and links, fundamental for the loom binary and the oracle binary, securing the connection between the two chains. From the commentaries it is clear which line belongs to which:
The most important part is the Gateway smart contract itself. It cares for emitting events right after the user makes a deposit of tokens. Emitted events are then taken by Loom Oracle, which forwards then as mentioned before, alternatively releases tokens for their withdrawal. This particular Gateway smart contract handles management of not only ERC721 but also ERC20 and Ether.
If we open smart contracts in the file folder truffle for loom dappchain and Ethereum, it’s just about the smart contract pairs for ERC tokens, which are not worth mentioning in this tutorial and are just the basics of operations. For us ERC20 is more important:
The fundamental modification of the contract in truffle-ethereum folder is the function for depositing on Gateway smart contract.
Back on the Truffle-dappchain side, the folder contains smart contracts for managing and minting tokens on the loom dappchain side. When the user deposits ERC20 token from Ethereum blockchain to dappchain, Gateway contract on the dappchain side mints the corresponding amount of tokens:
We have to remember that Gateway contract on the dappchain side must be authorized to mint tokens on its side. This means, that wallets have to be always paired and the wallet on the Ethereum blockchain must be a provable owner of tokens deposited Ethereum blockchain side of the Gateway.
For those who doesn’t want to run the whole app, I’m including several screenshots. First one is from the signing into the app, on which background happens the wallet address pairing.
After logging we see the balance of our tokens, which we can transfer to Loom dappchain. As we are still making transfer to Ethereum Gateway, we have to pay for the gas.
On the background, after depositing on Ethereum Gateway, the event is emitted on the basis of which the Loom oracle forwards the information about the deposit to the Gateway on the Loom side. Subsequently, the tokens are minted and ready to be used in the wallet on the Dappchain.
Conclusion
This tutorial is but a basic introduction to the issue of sidechains and the scalability solution on the Ethereum blockchain. I’ve only sourced my information from the available sources in the official Loom network documentation. The documentation is sadly very incomplete, and one must spend a lot of time to understand and implement. All this time could be saved by utilizing a well-written documentation, not just basic instructions provided by Loom right now. I hope this will improve in the future, as I personally view Loom as a project with huge potential and broad application in the future, not only in the game industry. We will see. If you have an interesting topic to talk about or you want to meet me in person, I know about great place for a meeting — in our ProgressBar coworking.