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.