Dev Letter #24: Sidechain Approach
Sidechains used as scaling solutions has been one of the hottest topics in the crypto-space lately. This article will detail the first steps for iExec sidechain solution.
Then, the final part of this development letter will review some additional interesting achievements of the team including the successful deployment of ‘Kata-compatible’ worker pool.
iExec Sidechain Solution
The problem: Why would a sidechain be needed?
iExec V2, the first blockchain enabled Marketplace for cloud computing resources, was successfully released in May 2018. An important milestone for the team, we put the final pieces of the puzzle together and launched ‘the Marketplace’ live on Ethereum mainnet. The challenge for iExec now is to optimize and find a balance or a ‘trade-off’ between maximising the level of security while still having an acceptable and efficient level of performance for the end user.
As you may know, iExec uses the RLC token, on the Ethereum blockchain for its consensus protocol for all transactions on the Marketplace, this protocol is called Proof-of-Contribution. If you’re interested in this topic, please read the PoCo series that’s detailing how the iExec worker network verifies an off-chain computation.
We can use an analogy to demonstrate how transactions with the RLC token could be made more efficient: imagine if we were to store all orders for work deals on the iExec marketplace and all Proof-of-Contribution consensus transactions for each execution in the Mainnet Ethereum blockchain. This would be comparable to going to the notary offices each time you wanted to make a monetary transaction to buy a coffee. It is not viable for RLC to be validated by all nodes on the Ethereum main network, nor a practical solution.
We of course still want these transactions to remain auditable and accessible to the public, but rather on a dedicated chain, optimized specifically for these marketplace deals and Proof-of-Contribution consensus transactions. There is no need for these to be universally stored in all public nodes, being less efficient and more costly. This new dedicated chain is what we call sidechain or parachain in the future.
The ideal governance (regarding block confirmations by nodes on the network) for this sidechain is a governance that is closely linked to the RLC token. We will work on this token aspect governance for a sidechain to design the best and fair solution. This research goal is also shared by many others from within the Ethereum community, we learned after some interesting conversations at the ETH Berlin Hackathon for instance.
The target solution to reach
To relay the token on the sidechain, the ultimate solution we will be to use dedicated relay-chain, with there own incentives, to link messages between chains. For this reason, our lab team is actively testing the development of Parity technology’s Polkadot Pocs.
The main target for the Sidechain solution:
- A sidechain, using parity-substrate, for Marketplace work deal transactions and PoCo consensus transactions, with node governance based on RLC token economy.
- Use of Polkadot Relay chain to deposit/withdraw RLC token from and to the Ethereum main chain to keep the RLC market valuation.
The design of this inter-chain ecosystem remains a work-in-progress for the time being (see Polkadot POC release).
After the ETHBerlin Hackathon, we participated in the Parity workshop for running a polkanot node on testnet:
Our lab team continues to delve deeper into inter-chain solution research and explore the parity-substrate custom sidechain building tools that are currently being released.
At the same time, our delivery team is working to release an intermediary solution, with the first sidechain implementation described in the next chapter.
The First Step for iExec V3
We will first implement a bridge inspired by the existing Parity Bridge :
We will replace the ETh -> ERC20 token of the existing parity bridge to a RLC ERC20 <-> RLC ERC20 transfer. The Home Chain of the bridge will be the Ethereum Mainnet and we will run a sidechain with the Parity-ethereum client with PoA configuration. An available solution that is operational today. This sidechain will be designed to only be able to treat transactions for the smart contract marketplace deals or smart contracts for proof of contributions thanks to transactions restrictions in PoA configuration.
No impact will be seen for the end wallet user. Today, in V2, you already have to do a deposit/withdraw actions from the RLC ERC20 to the Marketplace Contract. Those deposit/withdraw will stay the same for the end user. But those deposit/withdraw will move asset between the Ethereum Mainnet chain to the sidechain
For security, the user will have the choice to deposit only what he needs for a week of usage as worker or users for instance.
For smart-contract that needs off-chain computation, there will be also dedicated bridge that will propagate callback to the main Ethereum chain. Those services will have to be pre-load by users with ethers to operate and pay the callback gas.
Other iExec Development Updates
Sandboxing
In the Dev Letter #23 we reviewed some sandboxing solutions and presented Kata containers. Here we want to announce that we have successfully deployed the first worker pool which uses Kata Containers for sandboxing on the kovan network.
Kata Worker Pool Information
- Name: Cloud And Heat Pool
- Dashboard: https://cloudandheat-pool.iex.ec
- Ethereum Address: 0xf1ed3013ffaac2d3cf5050c1a8ac13f2f66c10e0
Worker Execution Environments
To answer the question of which solution is suitable for you we need to look through existing execution environments. We defined two main worker execution environments. You can execute iExec worker on your bare metal machine or you can execute our worker in a virtual machine.
Bare metal environment
If you have a bare metal machine and you want to deploy an iExec worker using a sandboxing solution, you can choose between:
- Kata Containers — explained in Dev Letter #23
- Virtual Machine — used during Worker Drop
If we are looking for the best security, small footprint size and short startup time Kata container is the overall winner here.
Virtualized environment
If you are launching an iExec worker in an already virtualized environment, we can consider that your host machine is already protected by a virtualisation mechanism. So you can deploy your worker as a simple docker container.
Be aware that if you prefer virtual machine in a bare-metal environment or you have already virtualized environment your worker wallet will be protected only with docker engine security mechanism. We are currently researching a solution that will protect the worker wallet in any and all execution environments.
The team is getting ready for Devcon4 and the iExec Summit & Party that will start on Friday 02 Nov. 2 pm in Prague. We want to offer the best conditions to discuss about infrastructure, decentralization, and crypto-economics.
