1, Background
Vitalik Buterin recently wrote an article on Ethresear.ch on the idea of a cross roll-up dex, that would allow users to exchange tokens between two roll-ups in a decentralized manner. The purpose of this article is, in essence, a brief report on the progress we have made at the Class ZZ (CZZ) community on this topic.

Over the past two years, we have developed a decentralized cross chain transaction protocol called Te Waka. Te Waka is a kind of canoe that early Polynesian settlers used to travel between otherwise islands of the archipelago. This is very similar to the current state of the blockchain space.

Te Waka protocol has been running since April 2021, there’s already a fully developed application called czzswap that allow users to trade native tokens between Ethereum, BSC and Heco. Connect metamask wallet to your browser, and you can start swapping at https://classzz.com/swap. The same protocol would also enable users to engage in cross rollup transactions in an efficient and decentralized manner. Specifically, it will not require any intermediary, nor will it require any slow process to run on L1.

2, Basic protocol
Here’s a very high-level description of how Te Waka works. For a detailed documentation, please see https://docs.classzz.com/czz.whitepaper.v4.pdf (Section 3).

First we describe the basic protocol, which allow for the cross chain transfer of CZZ tokens that exist on different blockchains. The Class ZZ network is a PoW main net with zero pre-mined tokens. It also recognizes a list of community addresses, there are addresses with extremely simple public keys such as 000…000101. We can assume extremely high confidence that nobody knows the private keys to these addresses.

For every CZZ token sitting on
• 000…000101, one ECZZ token is issued on Ethereum;
• 000…000102, one HCZZ token is issued on HECO;
• 000…000103, one BCZZ token is issued on BSC
• …

A multi-sig cross chain smart contract is also deployed on every main net, where it is responsible for mint / burn of *CZZ tokens. Custodian of these smart contracts must stake main net CZZ tokens, and their staking could be slashed by PoW miners in an event of misconduct.

When Alice wish to convert 1000 of her ECZZ to BCZZ for example, she would
• send her 1000 ECZZ to the cross chain contract on Ethereum, where it will be burnt.
• Alice then broadcast her Ethereum transaction hash to CZZ main net (in reality, this step is done by dapp developers)
• PoW miners will give -1000 CZZ to 000…000101 and 999 CZZ to 000…000103 as mining reward in the following block (40s per block). 1 CZZ will be sent to 000…000000 to be destoyed permanently.
• PoS custodians will vote in a BFT committee to mint 999 BCZZ on BSC, based on the fact that 000…000103 has just received 999 CZZ main net tokens.
• 999 BCZZ is sent to Alice after its minted on BSC.

3, General protocol
Next, we describe the general protocol, which will allow cross chain transaction of any native tokens between two smart contract enabled blockchains. The general protocol exist as a smart contract that calls a
• dex contract, and
• the basic cross chain contract.

Specifically, if Alice wish to purchase UNI (lives on Ethereum) using her BNB (lives on BSC). All she need to do is deposit her BNB to the general cross chain contract on BSC, wait, and receive UNI on Ethereum. Here’s what goes under the hood,
• General contract (BSC) calls a dex, say Pancake swap, to convert BNB to BCZZ.
• General contract (BSC) calls basic contract to burn BCZZ.
• Class ZZ PoW miners operate on community addresses through mining reward
• General contract (Ethereum) mint ECZZ
• General contract (Ethereum) calls a dex (e.g. Uniswap) and buy UNI with ECZZ
• General contract (Ethereum) send UNI to Alice.

4, Insurance
Since the general protocol need to wait for CZZ miners to mine at least 1 block, many users in the community have asked for a tool to hedge against exchange rate fluctuation during that time. Here we briefly describe how the insurance contract works.
Insurer: The community is encouraged to deposit ECZZ, HCZZ and BCZZ to an contract pool, those who deposit will receive a fraction of the insurance premium paid by the user.

Insurance contract: Since users are incentivized to deposit, we assume the insurance contract is pre-loaded with some *CZZ tokens on each blockchain. If Alice indicate her intent to use insurance on her BNB -> UNI transaction, here’s what will happen:
• Alice send her BNB to the general contract (BSC), indicating she want insurance
• General contract (BSC) buy and burn BCZZ
• Insurance contract (Ethereum) buy UNI with pre-loaded ECZZ ahead of time, but the UNI tokens are withheld.
• PoW miners update community address through mining reward
• General contract (Ethereum) mint ECZZ and send ECZZ to insurance contract (Etherem)
• Insurance contract release UNI to Alice after receiving ECZZ.

This procedure will minimize exchange risk for the user, reduce market supply of CZZ through staking, and also provide the community participants an income stream.

Applications to Ethereum Layer 2
A key problem to Ethereum’s layer 2 rollup’s is the inability to cross communicate with one another without either
• Going through layer 1
• Rely on a somewhat centralized intermediary
We believe the Te Waka protocol can provide a cross rollup solution to Ethereum layer 2 networks with some additional modifications. This would completely eliminate the throughput problem that layer 1 is currently facing.
Specifically, we require each rollup to have
• Ability to issue ERC-20 tokens
• Ability to host a dex
• Even if VM’s of ZK-rollup is not Turing complete, but it’s command set is rich enough to host dex’s)

This will allow us to deploy Te Waka general contract to each roll-up, and users can directly purchase native tokens of any rollup from anywhere. We can deploy Te Waka on Plasma and Op-rollups quite quickly, while ZK-rollups may require some additional work.

Second order bridge problem
Te Waka protocol does not require users to deposit native tokens to a bridge contract and trade with bridge tokens. This will vastly improve user experience, as users no longer have to juggle between mapped tokens of different networks. More fundamentally, Te Waka protocol solves the second order bridge problem, which is at the crux of why decentralization of cross rollup is so difficult.
Here’s a brief description of the problem. Suppose you have a token ABC lives on Ethereum L1. OP1 and OP2 are two different L2 rollups, such that ABC1 lives on OP1 and ABC2 lives on OP2, and both are connected to ABC via a bridge contract on L1. If Alice wish to convert her ABC1 on OP1 to ABC2 on OP2, a naïve approach is to deploy a bridge contract on OP1, where if Alice deposit her ABC1 she will get ABC2 on OP2. The reason why this approach won’t work is that ABC2 tokens are backed on ABC tokens deposited in a bridge contract living on L1. Therefore, a deposit of ABC1 to a OP1/OP2 bridge, technically is not the same as a deposit of ABC to a L1/OP2 bridge. Alice would be getting something like ABC12, as opposed to ABC2. This is what we call the second order bridge problem.

In reality, equivalence is often drawn by a centralized intermediary, but it would be nice if Alice could receive ABC2 directly without having to resort to a potentially centralized third party. If Alice wish to strictly abide by decentralized route, she must first destroy her ABC1 and claim ABC on L1, and then re-deposit that to the L1/OP2 bridge to get ABC2.

This problem is completely resolved through the Te Waka protocol, as it offers direct exchange between native tokens of each rollup.

Why PoW?
The Class ZZ community is devoted to the pursue of decentralization. We can roughly put all blockchain protocols to date into three catagories.
• Proof of work
• Decentralized Proof of Stake (e.g. Eth 2.0)
• Quasi-decentralized Proof of Stake (e.g. DPoS blockchains where block producing nodes never change)
Since our community is dedicated to focus on developing cross chain capabilities, we neither have the time or resources to innovate something like Eth 2.0 at the consensus level. On the other hand, we also don’t want to exist as a quasi-decentralized blockchain, like those DPoS networks where block producing nodes never seem to change. Therefore, we are currently left with little choice but to use proof of work. We are open to modifying our consensus in the direction of proof of stake, but not at the expense of decentralization.