Connecting Z.com Blockchain to the Ethereum Main Chain

こんにちは、次世代システム研究室のN.M.です。

Intro

 Why would we want to do it?

Sidechains have gained popularity recently as a way around the scalability and volatility problems of the main blockchain.

Peak requests on the main blockchain can slow transactions down. Volatile transaction fees on the main blockchain can make applications that transact on the blockchain too expensive to use.

Sidechains can offer higher throughput and more stable transaction fees.

 

What if we had an easy way to move our main chain currency onto a faster chain to use there, and whenever needed we could move it back to the slower main chain?

 

The diagram shows the main chain and a sidechain, they are connected by a bridge. The bridge provides a way to move main chain currency to and from our sidechain.

Since we are talking about Ethereum, our main chain currency is Ether (ETH). Bridge Ether Token (BETH) is used on the sidechain as a placeholder for main chain ETH.

Introducing Parity Bridge

Parity Bridge is developed by Parity Technologies as part of the Polkadot project. Polkadot is being developed to allow various different blockchains to communicate with each using a shared consensus system. It also needs to connect to other fully independent Ethereum chains. This is the reason for Parity Bridge, but basically it can be used to connect any two Ethereum networks. It is shown here at the bottom right of the polkadot concept image in the Ethereum Bridgechain part.

We will discuss using Parity Bridge to build a bridge between Ropsten (an Ethereum test network),  our “main chain”, and Z.com Cloud Blockchain, our “sidechain”.

Owners of ETH on Ropsten you can use the bridge to obtain BETH on Z.com. Subsequently owners of the BETH can exchange it for ETH on Ropsten. Owners of ETH, deposit ETH into the bridge and receive newly minted BETH on Z.com Cloud Blockchain. Owners of BETH can withdraw BETH to receive ETH on Ropsten. The withdrawn BETH is burnt.

Parity Bridge consists of 3 components: the MainBridge contract (runs on the main chain), the SideBridge contract (runs on the sidechain) and the bridge relay. The contracts are written in Solidity and the bridge relay is written in Rust.

The bridge relay is designed to work with parity both blockchain clients on the same machine, since it uses an IPC named pipe to communicate with these clients.

The bridge relay uses event filters to pickup events fired by the bridge contracts and responds by calling other functions on the bridge contracts.

The SideBridge contract is the sidechain token used in the bridge. There are standards defined for tokens in Ethereum, the most common being the ERC20 standard. The SideBridge contract implements this standard.

Deploying the Bridge

The parity bridge project provides a deployment tool. Use the tool as shown below to deploy the contracts.

RUST_LOG=debug ./target/release/parity-bridge-deploy --config env/demo/bridge_config.toml --database env/demo/bridge.db

This uses the file env/demo/bridge_config.toml as the bridge configuration, and deploys the bridge contracts to the main chain and the sidechain. After deployment it records the addresses of the contracts within env/demo/bridge.db. You need to define your own config file and set these deployment parameters appropriately.

Deposits

Deposits happen when ETH is sent to the MainBridge contract. What follows is how the bridge handles the deposit.

Whenever ETH is sent to a contract, without a matching contract function to be called, the default fallback method is invoked. This is the MainBridge contract’s fallback function.

    function () public payable {
        require(maxSingleDepositValue == 0 || msg.value <= maxSingleDepositValue);
        // the value of `this.balance` in payable methods is increased
        // by `msg.value` before the body of the payable method executes
        require(maxTotalMainContractBalance == 0 || this.balance <= maxTotalMainContractBalance);
        Deposit(msg.sender, msg.value);
    }

This method is quite simple. There is some code to check preset limits maxSingleDepositValue and maxTotalMainContractBalance are not exceeded. Then the Deposit event is emitted. This event contains the sender and the value. Because msg.value of Ether automatically becomes under the ownership of the MainBridge contract this Ether is essentially locked until it can be freed again by a withdraw.

When the bridge relay receives a Deposit event, it calls the SideBridge contract deposit function

On receiving the event, the bridge relay calls the SideBridge contract’s deposit function and the depositor’s balance on the SideBridge token is increased by the sent amount. So on the MainBrige contract we locked msg.value of ETH and on the SideBridge contract we minted msg.value of BETH.

Withdrawals

Withdrawals happen with thetransferToMainViaRelay function is called on the SideBridge contract. What follows is how the bridge handles the withdrawal.

    function transferToMainViaRelay(address recipient, uint256 value, uint256 mainGasPrice) public {
        require(balances[msg.sender] >= value);
        // don't allow 0 value transfers to main
        require(value > 0);

        uint256 estimatedWeiCostOfWithdraw = estimatedGasCostOfWithdraw * mainGasPrice;
        require(value > estimatedWeiCostOfWithdraw);

        balances[msg.sender] -= value;
        // burns tokens
        totalSupply -= value;
        // in line with the transfer event from `0x0` on token creation
        // recommended by ERC20 (see implementation of `deposit` above)
        // we trigger a Transfer event to `0x0` on token destruction
        Transfer(msg.sender, 0x0, value);
        Withdraw(recipient, value, mainGasPrice);
    }

The method above transfers msg.sender‘s local balance (on the sidechain) to the recipient on the main chain. It immediately decreases the msg.sender‘s local balance, thereby destroying (or “burning”) value of BETH. Then it emits a Withdraw event which will be picked up by the bridge relays. The relays will then sign off (by calling submitSignature) on a message containing value, recipient and the hash of the transaction on the sidechain containing the Withdraw event. Once the number of signatures received equals requiredSignatures a CollectedSignatures event will be emitted. A bridge relay will pick up the CollectedSignatures event and call MainBridge.withdraw which transfers value – relayCost to recipient completing the transfer.

Running the Bridge Relay Process

After deploying the contracts you need to start the bridge process daemon. I used the command below.

RUST_LOG=info ./target/release/parity-bridge --config env/demo/bridge_config.toml --database env/demo/bridge.db

You need to use your own config file and bridge.db, and set these deployment parameters appropriately.

Making Deposits and Withdrawals

On Ropsten you can send ETH to the MainBridge contract to receive the equivalent value of BETH on Z.com Cloud Blockchain.

For this operation you can use Metamask as shown below.

Simply send the desired amount of ETH to the address of the MainBridge contract. You will find the address of the MainBridge contract in the bridge.db file created during deployment.

Withdrawals are a little more complicated because the method to be invoked on the SideBridge contract to initiate a withdrawal is not part of an interface that Metamask knows about. We can call this method using code, or use Remix. If we use remix (we still connect via Metamask) we can then invoke the transferToMainViaRelay function directly. Choose the Run tab/Environment/Injected Web3 option to use Remix via Metamask. You will need to add the contract code to Remix using the + icon on the upper left corner.

 

Summary

Parity Bridge provides a way to use main chain Ether on the sidechain.

The sidechain can be created for a specific DAPP or shared among multiple DAPPs.

By running applications on a bridged sidechain such as Z.com Cloud Blockchain, and connecting to the main chain with Parity Bridge, users can enjoy higher throughput, less volatility and stable transaction fees, and move their Ether to and from the main chain as needed.

Although user’s will experience much better usability on the sidechain, there is ofcourse the additional cost of the deposit and withdraw operations on the main chain. This will be more worthwhile if the usecase involves more than a few transactions involving BETH on the sidechain.

 

For more information on parity bridge see: https://github.com/paritytech/parity-bridge

For more information on Z.com Cloud Blockchain see: https://cloud.z.com/jp/products/blockchain/

 

次世代システム研究室では、グループ全体のインテグレーションを支援してくれるアーキテクトを募集しています。インフラ設計、構築経験者の方、次世代システム研究室にご興味を持って頂ける方がいらっしゃいましたら、ぜひ募集職種一覧からご応募をお願いします。

皆さんのご応募をお待ちしています。