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
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
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
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.
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.
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.
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.
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.