Edit: The current repo for PeaceRelay is https://github.com/KyberNetwork/peace-relay.
Last week I attended the IC3-Ethereum bootcamp at Cornell University, Ithaca. The bootcamp was designed as an one-week long hackathon in which attendants, including both academic and industry people, were split into groups to work on different projects. I proposed and lead PeaceRelay, one of the ten selected projects. Project leaders pitched their projects to the attendants on the first day, after that people could register and select which project they want to work on for the rest of the bootcamp. I was fortunate to work with Nate Rush and Nicholas Lin on PeaceRelay during the bootcamp.
What is PeaceRelay
PeaceRelay is inspired by BTCRelay, a Bitcoin light-client running within a smart contract on Ethereum. BTCRelay allows Ethereum smart contracts to verify Bitcoin transactions, thus enabling Ethereum accounts to receive payment from Bitcoin.
PeaceRelay is built with a similar goal but for different chain: allowing communication/ interaction between two different Ethereum blockchains, i.e Ethereum and Ethereum Classic. Via PeaceRelay’s services, Ethereum contracts can read and verify transactions, account states on Ethereum Classic and vice versa. PeaceRelay is much more interesting than BTCRelay at the moment, since it enables two-way relay between Ethereum and Ethereum Classic, thus enabling what is also called “two way peg” in sidechain. Basically, PeaceRelay allows one to move ETC to Ethereum and move it back to Ethereum Classic network by deploying PeaceRelay on both Ethereum and Ethereum Classic networks.
How PeaceRelay works?
How PeaceRelay works is quite simple. Lets first discuss how BTCRelay or any general chain relay works. There is an Ethereum contract that stores all Bitcoin block headers relayed/ submitted by users, or relayers. In case you are new to the structure of a block header, it contains a data field called “Merkle root” that cryptographically commits all transactions in the block. Given a block header, one can easily verify if a transaction is included in the corresponding block by verifying the transaction Merkle proof. Since a block header is much smaller than a full block, and it is computationally intractable to generate a fake Merkle proof, a relay provides an efficient and secure way to verify facts like if transaction is included/ confirmed in the blockchain.
PeaceRelay follows the same protocol of a chain relay. For ease of discussion, lets assume we are relaying Ethereum Classic blocks to Ethereum, the reversed direction works similarly. There is an Ethereum, contract which stores all block headers of the relayed chain (e.g. Ethereum Classic). The contract verifies every submitted block header before adding the new header to the chain. The contract then allows users to submit a Ethereum Classic transaction with a Merkle proof to verify the validity of the transaction. Interestingly, since Ethereum block header also includes the Patricia merkle root of the current blockchain state, one can verify much more interesting facts including account balances, account storage at some block.
Challenges. It is worth noting that verifying the validity of an Ethereum/ Ethereum Classic block header was thought to be infeasible due to the memory requirement in the Ethash proof of work algorithm. Fortunately, thanks to SmartPool, we now can verify the correctness of a Ethash PoW with roughly 2.6 Million of gas. While this number is reasonably small, i.e. 40% of current block gas limit, it is large enough to make verifying every Ethash PoW in each block expensive. We discuss how to practically deploy PeaceRelay in our future blog post.
Another challenge is to verify a Patricia Merkle proof in Solidity. The Patricia Merkle tree is used in Ethereum, instead of a normal Merkle tree, for performance reasons. This is more of an engineering challenge, but took Nate most of the time during the bootcamp to do it right. The merkle-patricia-proof tool by Zac Mitton (i.e. zmitton) greatly helped simplify our job.
From one way relay to two way peg. To move from an one way relay to a two-way peg is quite straightforward. One can lock their ETC in a locking contract running on Ethereum Classic, and use this locking transaction to create new ETC tokens in a ETCToken contract running on Ethereum. In order to claim their ETC (on Ethereum Classic) from ETC tokens (on Ethereum), one needs to burn their ETC tokens in the ETCToken contract. The transaction that burns ETC tokens will be used to claim the owner’s ETC from the ETC locking contract running on Ethereum Classic. We explain the lock/ claim mechanism in the figure below.
ETH — ETC exchanges
One could imagine that our above ETC Token contract can be made as an ERC20 contract, thus PeaceRelay allows people to trade ETC just like any ERC20 token in Ethereum.
Private Chain — Public chain
Recently EEA has become the largest blockchain consortium, one expects that many enterprises/ organisations will develop and maintain their own private blockchain based on Ethereum. PeaceRelay does not stop at relaying between Ethereum Classic and Ethereum. Basically one can relay between any Ethereum-based blockchain to Ethereum. This enables interesting applications like moving a private tokenized currency (e.g. Singapore Dollars) from a private Ethereum blockchain (e.g. run by MAS Singapore) to public blockchains like Ethereum. Users now can trade SGD to ETH and/or any other tokens on Ethereum. We explore this application later in detail in a blog post by KyberNetwork.
As aforementioned, PeaceRelay allows verification of not only transactions, but also blockchain state. Thus, as proposed by Nate Rush, a contract can verify how full the recent blocks are (i.e. how much gas they consume) to automatically adjust the deadline for submission of, say, a reveal transaction for a commit-reveal protocol. Specifically, let us consider a scenario in which a contract is expecting some transaction from a user before some block, otherwise the user will be penalised. However, due to the heavy traffic on the blockchain, the user, although has sent the transaction much earlier before the deadline, will get penalised since his/ her transaction cannot get included in any block. The contract can query the gas oracle and extend the deadline in such cases to allow more time for the submission. Thus, the gas oracle helps guarantee fairness in cryptographic protocols. One can possibly use this gas oracle to trade gas futures/options. This may allow for ether holders to hedge their risk from rising gas prices.
The functional prototype of PeaceRelay has been developed during the one-week bootcamp at Cornell, thanks to Nate Rush and Nicholas Lin. The code is publicly available and currently allows relaying between Ropsten and Rinkeby testnets.
PeaceRelay will be further maintained and developed by the KyberNetwork team and the xRelay team at ConsenSys to support their cross-chain trading vision. More on how PeaceRelay and other chain relays are used in KyberNetwork will be available in the KyberNetwork’s next blog posts.
Acknowledgement. Prior to and during the bootcamp, we had helpful discussion with the xrelay team from Consensys, including Zac Mitton, Joseph Chow, Sam Mayo. We thank Vitalik Buterin, Casey Detrio and Christian Reitwießner from the Ethereum Foundation and Yaron Velner from SmartPool/ KyberNetwork for their help during the bootcamp. Nate Rush is an intern at Consensys, Nicholas Lin is a py-ethereum developer at the Ethereum Foundation and Loi Luu’s travel to the bootcamp was sponsored by the Ethereum Foundation.