Open in app

Sign in

Write

Sign in

Waterloo — a Decentralized Practical Bridge between EOS and Ethereum

Part 2: Ethereum →EOS

Tal Baneth
Kyber Network
8 min readJul 30, 2019

--

Connecting blockchains in a practical and decentralized manner might be considered as the holy grail of blockchain engineering. To tackle this challenge, Kyber has unveiled the Waterloo project for bidirectionally connecting a proof of work (POW) network and a delegated proof of stake (DPOS) network, namely Ethereum and EOS.

In the previous post we focused on one side of the equation — relaying payment data from EOS to Ethereum. This time we share our work for moving assets the other way around, from Ethereum to EOS. We demonstrate it by having the Kyber Experimental DAO move a KNC token to the EOS blockchain.

The bridge development itself took on some prominent challenges:

  • Implementing POW verification logic (Ethash) on an EOS contract.
  • Maintaining the longest chain of relayed blocks.
  • Verifying data authenticity through traversing modified Merkle Patricia tries.

In this post we first recap on what a relay bridge is, then dive into each of the above challenges. Finally, we describe the setup for transferring KNC cross chain and minting EOS based Waterlooed-KNC (WKNC).

For the code check out our github.

Relay Bridge

As we covered previously, a relay bridge implements a light client logic. This means that block headers of one blockchain are being submitted to a smart contract on another blockchain.

We showed that when relaying headers from a DPOS chain, it is possible to relay only a small percentage of the headers, specifically those that relate to block producers changes, as their signatures are enough to validate a block.

However, when relaying from a POW chain, the light client must constantly receive all headers. The reason for this is that the POW consensus model dictates to follow the block branch with the longest chain (in terms of accumulated difficulty).

Any user can prove that an action has occurred on the original chain by showing that the action details are part of a stored header’s Patricia Merkle root. If that header is also on the longest chain, and enough blocks have been mined on top of it, one can deduce that the action did occur on the original chain.

On an application level, DApps can do many things with such knowledge. Especially useful is the ability to identify events of locking tokens on the original chain, and as a result, DApps are able to mint (issue) new equivalent tokens on the receiving chain. This is exactly what we do in the current proof of concept work, detailed below.

Ethereum Light Client Building Blocks

We can now classify the building blocks of the bridge as:

  1. Proof of work verification.
  2. A data structure to maintain the longest chain.
  3. Verification of events inside a block header.

The first relayed header is the genesis block. It is submitted once and can not be later mutated. Afterwards anyone can relay headers, and the contract tracks the chain with the longest accumulated amount of work.

Assuming there is at least one honest relayer, a malicious relayer that aims to take over the chain has to reach enough hash power to create more work than Ethereum’s mainnet chain. This assumption is similar to the underlying assumption of the Ethereum blockchain itself (51% honest hash power).

We will now go a bit deeper to the content of each building block.

POW Verification

Mining an Ethereum block is in essence finding an arbitrary value (nonce) that is hashed along with the header to result in a low enough numeric result. Therefore, in order to validate a header, a light client must receive the nonce along with the header, calculate the Ethash result and compare it to the block’s required difficulty.

Implementing Ethash verification on a smart contract was considered non feasible on existing blockchains. This is mainly due to the vast memory resources needed for the calculation. The process requires calculating and accessing 64 elements in a dataset of over 1GB. Moreover, the dataset itself changes every epoch of 30K blocks (around 3 days). These datasets are undoubtedly too much to store on chain.

The solution we utilize was presented by Kyber’s co-founders in their previous Smartpool project. Instead of doing the entire Ethash calculation on chain, the light client deployers should pre-calculate each dataset off chain. They then pre-store on chain just the Merkle root of each such dataset’s elements.

Once the light client is running, each relayed block is provided with additional data:

  • The 64 dataset elements that are used for the specific header verification.
  • 64 Merkle proofs for the validity of the above dataset elements.

In the light client contract, an additional step is added for authenticating the elements with respect to the relevant block’s epoch Merkle root. Afterwards the elements can take part in the Ethash calculation.

Of course one can argue that users must trust the original pre-stored Merkle roots. However, this will be fully mitigated by both encouraging users to read the contract storage before relying on it, as well as having the roots audited by reputable parties.

Longest Chain Data Structure

Once a header is validated through Ethash, it is added to a data structure that stores the valid submitted headers. This data structure also keeps track of forked chains. Such chains can exist either because of actual temporary forks on Ethereum, or because of attempts for submitting fake blocks.

The longest chain (in terms of accumulated difficulty) can be retrieved in any given moment. The chain is then used to check whether a block is indeed on the main chain. Nevertheless, it is application-specific to determine how many blocks need to be mined on top of a given header in order to assume it is final.

The next step in the bridge development is to improve the longest chain data structure efficiency. This will allow better scaling of the supported amount of headers and also for quicker longest data chain verification. For this, the BTC Relay project uses a skip list data structure, which we might incorporate in Waterloo as well.

Implementing Ethereum Patricia Merkle Proofs

After Ethereum headers are verified and stored on the bridge contract, they can be used for verifying any action data, whether its transaction information, an event log or storage operation.

Since the headers contain Patricia Merkle roots for the data, it is possible to verify its authenticity.

The verification amounts to traversing a Patricia Merkle proof and authenticating the action against the relevant header root. We implemented this logic in the EOS bridge contract, relying on previous work done by PeaceRelay and eth-proof.

Proof Of Concept — Sending KNC Cross Chain

One Bridge, Many Applications

The bridge is aimed for a multi-application model. This means that once it is fully launched, anyone will be able to use the bridge infrastructure as a service and build applications above it. Each application will be able to authenticate actions from the Ethereum chain and utilize the data for its needs.

As an example that demonstrates the capabilities of the bridge, we chose to build an application that mints KNC-pegged tokens. The application identifies specific KNC lock events on an Ethereum smart contract and issues the same amount of tokens on the EOS chain. We symbolically called these EOS based tokens Waterlooed KNC (WKNC).

Issuing WKNC

Let’s describe the full WKNC creation sequence in chronological order:

  1. In block 8161443, a user locks 1 KNC on the Ethereum side, while specifying the EOS intended recipient as “multimultixx”. The locking data is also logged in an event, and the event receipt is included in the Ethereum database.
  2. On the EOS side, Ethereum blocks are constantly relayed to the bridge, including block 8161443.
  3. An EOS user calls the check_receipt() service function in Bridge.cpp in order to validate the receipt is included in relayed block 8161443.
  4. The user then calls the Issue.cpp contract’s issue() action to:
  • Assure the receipt was validated and its block is on the longest chain.
  • Parse the receipt.
  • Finally, issue the specified KNC amount (1) to the intended recipient (“multimmultix”), in the form of WKNC tokens.

Voilà! KNC was just transferred to EOS.

It is nice to note that the sender of the above KNC was actually the experimental Kyber DAO. The KNC locking was automatically triggered after a proposal for it was approved.

Indeed, decentralization everywhere!

Future Work

Concluding both the ETH->EOS and the EOS->ETH proof of concepts, there is still work to do in order to make Waterloo a production level working bridge.

For ETH->EOS, this includes scaling the longest chain data structure, improving RAM and CPU consumption, and packaging the backend scripts to a user friendly tool.

Also for EOS->ETH, most of the remaining work is on the backend system that relays blocks to Ethereum and keeps track of the EOS block producer changes.

There are also considerations for how to incentivize relayers, which should be finalized to a working scheme. For example, one option is that applications and users that want to use the bridge will pay fees, which will later be distributed to relayers.

Finally, we are in early stages of collaboration with other projects, as we are aiming for the bridge to become a collaborative community effort. Hopefully it can evolve like the WBTC project Kyber initiated.

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.

Blockchain
Featured
English
Ethereum

--

--

Tal Baneth
Kyber Network

Written by Tal Baneth

58 Followers

Help

Status

About

Careers

Press

Blog

Privacy

Terms

Text to speech

Teams