Trustless Token Transfers with zkSNARKs

Loom Network
Aug 7, 2020 · 5 min read
Image for post
Image for post
Photo by Thought Catalog on Unsplash

Loom Network was one of the first to implement Plasma Cash to secure token transfers between Ethereum and side-chains built with the Loom protocol. Unfortunately Plasma Cash required end users to do far too much work in order to prevent fraud, and the resulting user experience turned out to be too tedious to be useful in practice. In lieu of Plasma Cash we decided to build our own Transfer Gateway that relied on multiple signatories to secure funds.

Recently there’s been some interesting research on using zero knowledge proofs to secure token transfers between Ethereum and side-chains, and there’s now a practical implementation of this research in the form of zkSync from Matter Labs. This is quite an exciting development because zero knowledge proofs (specifically zkSNARKs) will allow us to upgrade our Transfer Gateway to be completely trustless, while retaining a fairly simple user experience.

We won’t go into the gnarly details of knowledge proofs in this article, but if you’d like to learn more about how they work the list of resources at Awesome Zero Knowledge Proofs is a great starting point. Let’s take a look at what a Transfer Gateway based on the ZK Rollup architecture would look like.

Depositing from Ethereum to Basechain

Image for post
Image for post
Deposit Flow

Similarly to the current Transfer Gateway there will be a smart contract on Ethereum mainnet that accepts deposits of ETH and ERC20 tokens from users, this contract will retain custody of the tokens while they’re in circulation on Basechain. An Oracle will forward deposit events from the smart contract on Ethereum to the ZK Rollup contract on Basechain. The ZK Rollup contract will credit the tokens to the corresponding Basechain user accounts, and will add the deposits to the next rollup block. The Prover will continuously fetch rollup blocks created by the ZK Rollup contract and compute zkSNARK proofs for all the transactions within the blocks, it’s then up to the Oracle to submit the rollup blocks and proofs to the Ethereum Gateway contract. Since computing proofs is computationally expensive the Prover will likely run in a distributed fashion across multiple machines or multiple GPUs.

Transferring on Basechain

Image for post
Image for post
Transfer Flow

Token transfers between parties on Basechain will have to be initiated through the ZK Rollup contract so that they are included in the rollup blocks that are submitted to the Ethereum contract. The Prover will generate proofs for the transfers, just like it does for deposits, and an Oracle will submit the proofs to the Ethereum Gateway contract for verification.

Each token transfer effectively goes through three stages, in the first stage it’s committed to Basechain and secured by DPoS consensus, in the second stage it’s committed to Ethereum, and in the final stage it’s verified on Ethereum. Depending on how congested Ethereum is, and how many transactions end up in a rollup block it may take a few minutes before a transfer reaches the final stage. In practice most of the time end-users won’t need to wait for a transfer to reach the final stage before considering it finalized — the DPoS based consensus provides sufficient security in the vast majority of cases.

Withdrawing from Basechain to Ethereum

Image for post
Image for post
Regular Withdraw Flow

Regular withdrawals will have to be initiated by the user through the ZK Rollup contract on Basechain, similar to transfers. The withdrawal transactions will be included in a rollup block, which will eventually make it to the Ethereum Gateway contract along with the proofs of all transactions in the block, at that point the tokens that were withdrawn will be transferred to the user’s Ethereum account. Note that in this case the user won’t have to interact with the Ethereum Gateway contract at all.

Escape Hatches

To ensure that tokens transferred from Ethereum can’t be trapped on Basechain forever, be it intentional (by validators censoring withdrawals) or unintentional, the ZK Rollup based Transfer Gateway will allow users to initiate withdrawals directly through the Ethereum Gateway contract. When a withdrawal is initiated through the Ethereum Gateway contract Basechain will have to process the withdrawal within a predetermined period, if it does not then the Ethereum Gateway contract can enter an emergency shutdown mode — an irreversible state. In emergency shutdown is triggered the Ethereum Gateway contract will refuse to accept any further deposits, and will allow users to withdraw any tokens they can prove they owned as of the last verified rollup block.

Transaction Fees

The ZK Rollup Transfer Gateway will rely on an Oracle to push rollup blocks to the Gateway contract on Ethereum mainnet, this means that the Oracle will have to pay in ETH to submit transactions to Ethereum. The Ethereum transaction costs will have to be passed on to the users, so transactions initiated through the ZK Rollup contract on Basechain will have to incur a fee payable in ETH in addition to the transaction gas fee payable in LOOM. Requiring users to maintain a sufficient balance of both ETH and LOOM on Basechain in order to be able to transfer some tokens on-chain is not ideal, so we’ll need to come up with some way of funding the Oracle without forcing users to keep ETH on Basechain.

Conclusion

There’s often a tradeoff in system design between security and usability. The ZK Rollup Transfer Gateway can ensure that tokens can’t be trapped on Basechain but that security guarantee is only possible by syncing every token transaction with Ethereum. The synchronization process incurs additional costs in terms of time and money, and it’s unlikely users will want to incur those costs for low value transfers. Further research will need to be done to improve the usability of the ZK Rollup Transfer Gateway.

Academic research into zero knowledge proofs is advancing quite rapidly, and we’ll continue to monitor practical applications in this subject area to see if there are any novel capabilities we can integrate into the Loom protocol.

P.S.

Previously we’ve mentioned that there’ll be an article on the per-user transaction throttling and quota system that will ship in the next major version of the Loom protocol. We’re still working out some of the details so that article will be published a bit later.

Loom Network

Distributed Enterprise Platform for Healthcare Providers

Loom Network

Written by

We're building a distributed enterprise platform for healthcare providers.

Loom Network

Building a distributed enterprise platform for managing data — focused on healthcare providers and government departments.

Loom Network

Written by

We're building a distributed enterprise platform for healthcare providers.

Loom Network

Building a distributed enterprise platform for managing data — focused on healthcare providers and government departments.

Medium is an open platform where 170 million readers come to find insightful and dynamic thinking. Here, expert and undiscovered voices alike dive into the heart of any topic and bring new ideas to the surface. Learn more

Follow the writers, publications, and topics that matter to you, and you’ll see them on your homepage and in your inbox. Explore

If you have a story to tell, knowledge to share, or a perspective to offer — welcome home. It’s easy and free to post your thinking on any topic. Write on Medium

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store