Waterloo — a Decentralized Practical Bridge between EOS and Ethereum
Part I: EOS → Ethereum
Ethereum and EOS are, to date, the two biggest smart contract enabled blockchains, both by market cap and number of daily users metrics. In this post, we present the Waterloo bridge — an efficient and fully decentralized way to implement an EOS light client as an Ethereum smart contract, and an Ethereum light client as an EOS smart contract. Such implementations will enable cross-chain communication between the two blockchains, and will enable to transfer assets from Ethereum to EOS and vice versa. Such cross-chain interoperability is a long standing ambitious goal in the blockchain ecosystem in the last several years, with potential applications in finance, scalability and privacy.
In the next section, we formally define and explain the desired functionality of a relay bridge between two blockchains. Then, we introduce a relay algorithm of an EOS action into an Ethereum smart contract along with a proof of concept implementation (over Ethereum kovan testnet) to demonstrate the feasibility of the solution. After that we describe a solution for implementing a relay of Ethereum actions to EOS smart contracts. Finally, we discuss the next steps and survey related work.
Relay Bridge
A relay bridge implements a bi-directional relay of block headers between two blockchains. In such a bridge, block headers of blockchain A are constantly being submitted to a smart contract in blockchain B, which implements a light client logic to verify the validity of the headers. And analogously headers from blockchain B are submitted to a smart contract in blockchain A.
A simple example is the BTC relay which implements a uni-directional relay from Bitcoin to Ethereum. There, the Ethereum smart contract computes the difficulty of the submitted Bitcoin headers. A proof for the validity of each header amounts to checking it resides on the longest chain of submitted headers.
From headers to transactions
In all the blockchain protocols we are aware of, the block header contains a mathematically verifiable witness for every transaction in the block. Typically, this is in the form of a merkle root of all the included transactions. Hence, a smart contract that validates headers can be used also to validate the existence of a transaction in that header.
Once a smart contract can verify transactions, it can also verify an operation, e.g., token transfer, that was done by this action. We refer the reader to the peace relay report for a proof of concept on how to prove the action of a certain transaction.
Cross-chain asset transfer
A bridge can facilitate transfer of assets (e.g., tokens) between two blockchains by deploying locking, minting and burning contracts on each blockchain. When tokens are sent to a locking contract on blockchain A, the minting contract on blockchain B will mint a corresponding amount of wrapped tokens upon the submission of the token lock transaction on blockchain A. When the wrapped token is sent to the burn contract on blockchain B, the locking contract on blockchain A will unlock it upon a submission of a proof. This effectively pegs the wrapped token on blockchain B to the original token in blockchain A by a 1:1 ratio.
Light client security model
The smart contract serves as a light client, and as such does not verify the validity of the block content, but rather only the block header. As a result, in theory the contract could also approve invalid blocks. However, this problem is almost fully mitigated by crypto-economic incentives. For a more elaborated discussion on the light client security model, we refer the reader to this post.
EOS → ETH Relay
Instead of relaying all EOS block headers, we chose to only relay the changes in the set of EOS block producers (BP). We explain this approach in the subsequent sections. First we bring a brief background on the EOS consensus mechanism, then we discuss the EOS finality mechanism, after that we explain the EOS block header format, and finally we explain how the bridge works.
EOS consensus
The consensus protocol of EOS is delegated proof of stake (dPOS). EOS token holders are continuously voting (delegating) for their favorite block producer. The 21 block producers who receive the most votes produce blocks in a round robin manner. Each producer generates up to 12 blocks and send them to the network. Each block extends the last block in the chain and it is digitally signed by the block producer.
The voting process itself also occurs on chain, and the outcome of the voting is reflected in a block header. Namely, whenever the set of BP changes, the public keys of the new BP set are encoded in a dedicated block header, and another header attribute indicates when the new BP set becomes active.
The reader can find more details on the consensus protocol here.
EOS finality
The underlying security assumption of the EOS protocol is that 2/3+1 of the BP set is honest. I.e., 15 out of the 21 BPs are always honest. Hence, conceptually a block B is final when 15 of the BPs generated blocks that extend block B. Formally though, an extra round of BP extension during a specific time interval is needed. For the sake of simplicity we chose to omit these details from the scope of this work, however our approach can be extended to the full finality scheme. The reader can find further details on the finality of EOS block here.
EOS block header format
In order to understand how a client can relay BP set changes and prove finality of blocks, the EOS header format is presented (see EOS official reference client for more details):
struct block_header { account_name producer;
uint16_t confirmed;
checksum256_type action_mroot;
uint32_t schedule_version;
optional<producer_schedule_type> new_producers; ... // additional block header fields are not displayed as they are
// not relevant to the scope of this work
}
Each block header details its producer account. It must be one of the current producers set (schedule), as elected on-chain beforehand.
Once a block in which a new producer set election becomes final (irreversible) the new producers list appears in the block header’s new_producers field. The list includes the names and public keys of the new BPs.
Once also the block with the new producers list becomes final the new schedule actually becomes active and the schedule_version field increments. By committing proofs of the finality of the block with the new producers list, one can prove a BP set change has occurred.
The confirmed field is used for a BP to approve a range of previous blocks. The condition for a super majority (2/3+1) of BPs to approve a block as irreversible requires them to not only extend it with their additional produced blocks, but also for the block to be in all of these BPs confirmation range. For now we disregard this field in our initial POC and assume all previous blocks are confirmed.
Sharp readers would note that the previous block merkle root is not part of the block header. However, it is included implicitly as each producer signature input includes not only the header hash but also the merkle root of all previous headers. A client keeps track of the headers and thus can construct proofs based on such merkle root.
Finally, the action_mroot field is used to track the receipts of all the actions committed so far (e.g. EOS payments, token transfers).
A user can reconstruct such a receipt and show it is part of an irreversible block, thus proving the action had occurred.
EOS → ETH Relay
We construct a smart contract that verifies EOS actions in the following way:
- The contract starts with an initial set of genesis BPs.
- Whenever the set of BPs is changed, a proof for the finality of the change along with the new set of BPs is relayed to the contract. The contract verifies the proof and stores the new set if the proof is valid.
- To verify that an action occurred on the EOS chain, a proof consists of (i) a block header B signed by the current set of BPs; (ii) an earlier block header B’ that contains the action to verify along with a merkle branch that proves the action is included in the header; and (iii) a merkle branch to prove that B’ is in block B previous blocks merkle tree. (More details on how previous blocks are verified can be found here.)
We also construct a client to facilitate the relay in (2) and the proof construction for item (3). We note that in the worst case scenario the set of BPs could change every 2 minutes. However, at the time of writing, the set changed only 692 times since the inception of the EOS chain 9 months ago. Hence, on average, a change occurs once every 8 hours.
Proof of concept
To prove the feasibility of our approach, we deployed a proof-of-concept Ethereum smart contract on the Ethereum Kovan testnet. The relayed blocks are from the EOS Jungle2.0 testnet.
An initial schedule (version 1) was set in the contract, based on the first multi-producer set, as detailed in block #6713 (earlier blocks were all produced by one single eosio producer and therefore are of no real interest).
Later on a change of schedule (to version 2) was relayed by submitting a proof that includes verifying and linking block #9313 (which includes the new schedule details) and 14 corresponding unique blocks following it (#9325, #9337, #9349, #9361, …, #9481).
Based on the new schedule block #10800 was relayed and proved as final by submitting a proof that links it with 14 corresponding unique blocks (#10801, #10813, #10825, #10837, ..., #10945).
Once a block has been relayed, actions from earlier blocks can be verified. Indeed, in the final tx of the POC we prove that block #10776 is indeed linked to block #10800 and verify that an action of sending 100.0000 EOS from account junglefaucet to account megasuper333 has occurred. The actual proof is based on the action receipt hash of the above transfer operation, which was obtained from the local client we ran.
The smart contract code is available in https://github.com/KyberNetwork/bridge_eth_smart_contracts.
ETH → EOS Relay
The relay of Ethereum headers to an EOS smart contract is very similar to the BTCRelay technique. In this relay, Ethereum headers are submitted to the EOS smart contract, which calculates the proof-of-work difficulty of the header and maintains a tree of all submitted headers. A block header is valid if it resides on the longest branch in the tree (aka longest chain). One difficulty that arises is the complex Ethereum proof-of-work hash function which requires over 1 GB of data to compute. We plan to overcome this difficulty with the same novel techniques we used in SmartPool implementation. We will present more details and a proof of concept implementation in the coming weeks.
Another key enabler in our solution is the low computation costs (fees) in EOS network.
Conclusion and Future Work
We presented a practical relay bridge between EOS and Ethereum. The key enablers of the solution are:
- A light client for (delegated) proof of stake blockchain (i.e., EOS) only needs to maintain a set of block producers.
- Efficient algorithm to verify Ethereum proof of work hash function (based on the SmartPool algorithm).
- Low computation costs on EOS network.
The first item is the enabler for an efficient EOS →ETH relay and the last two items enable an efficient ETH →EOS relay.
Our next step is to implement a proof of concept EOS smart contract that verifies Ethereum block headers.
In the long run we plan to use such a bridge to transfer assets and tokens between Ethereum and EOS and enable a trading activity on both platforms using the advantages of each platform. E.g., the EOS chain has an advantage of enabling higher frequency trading due to its higher transaction-per-second rate. While Ethereum is considered more secure by bigger parts of the blockchain community and currently offers more advanced financial primitives, e.g, with the DeFi project.
Related Work
The first, and at the time of writing, only live relay project is BTCRelay, which relays Bitcoin block headers to Ethereum network. While this project allows Ethereum contracts to verify Bitcoin transfers, it cannot facilitate asset transfers between the chains since it is a uni-directional relay.
The peace relay is the first project that presented a bi-directional bridge between two smart contract supported blockchains, namely, Ethereum and Ethereum classic. However, the project was never implemented due to the impractical computation (gas) costs. Our approach exploits some of the unique EOS blockchain properties and thus allows a much more efficient implementation.
A proof-of-concept relay between Ethereum and EOS was implemented by Everipedia as a native C++ reference code. However, it suffers from heavy computation and storage (RAM) costs, which makes it impractical to run on EOS mainnet. The reason for the heavy costs is a full implementation of the proof-of-work algorithm, as oppose to our approach where we implement a light SmartPool verification algorithm.
The BancorX bridge between EOS and Ethereum and the recent WBTC DAO between Bitcoin and Ethereum took a more centralized approach where a trusted federation executes asset transfers from one chain to the other by freezing the asset on one chain and minting it on the other chain. Our approach is different as it is fully decentralized.
Finally, a line of solutions such as Wanchain, Polkadot and Cosmos aim to bridge blockchains by allowing to form a permission-less federation that facilitates asset transfer between chains. However the underlying security of the bridge is bounded by the underling security of the federation. In our approach, the security stems from the security of EOS and Ethereum chains, and hence has similar security level as the underlying chains.
About Kyber Network
Kyber’s on-chain liquidity protocol allows decentralized token swaps to be integrated into any application, enabling value exchange to be performed seamlessly between all parties in the ecosystem. Using this protocol, developers can build innovative payment flows and applications, including instant token swap services, ERC20 payments, and financial DApps — helping to build a world where any token is usable anywhere.
- Developer Portal: https://developer.kyber.network/docs/Start/
- Telegram Developer Group: https://t.me/KyberDeveloper
- Reddit: https://www.reddit.com/r/kybernetwork/
- Twitter: https://twitter.com/kybernetwork/
- Telegram group: https://telegram.me/kybernetwork
- Telegram announcement channel: https://telegram.me/officialkybernetwork
- Facebook: https://www.facebook.com/kybernetwork
- Blog: https://blog.kyber.network/
- Website: https://kyber.network/
