COZ Protocol: Cross-chain Synchronizer based on ZK-Rollup
Abstract
Coz Protocol is a universal layer which synchronizes states between multi-chain smart contracts. Current cross-chain synchronization has two major challenges. First, contracts from different main blockchains cannot communicate with each other, which makes it hard to establish a trustworthy communication channel to share and maintain a universal state between each other. Second, transactions on different blockchains can hardly be ordered so a novel way is needed to avoid and handle the conflicts. Coz Protocol is a ZK-Rollup based multi-blockchain synchronizer on top of which rich cross-chain applications can run safely and efficiently.
Background
As a new distributed computing paradigm, blockchain is rapidly evolving in areas such as decentralized finance and cryptocurrency. However, existing blockchain projects adopt different blockchain architectures and protocols, which results in the difficulty for value flow and communication between each other. Different blockchain systems have become isolated islands that brought limitations to the usable range, function and scalability for blockchain technology. In order to build trust between different blockchain networks, cross-chain technology has been proposed and received vast attention. Below are some previous cross-chain solutions:
Notary schemes
The main idea of notary schemes is to elect one or more trusted nodes as a notary public and verify transactions in different blockchain networks through notaries which can also prove to the nodes in the other blockchains. Therefore, the data exchange between different blockchains is completely managed by notaries. However, the notary scheme does not only rely on a single entity; it can be divided into Centralized Notary Schemes and multi-sig Notary Schemes. Current cross-chain projects using the notary scheme include Corda launched by R2 and The Interledger Protocol (ILP) proposed by Ripple Lab. The centralized notary schemes can reach high operation and processing efficiency but suffer from single point failure problems. Therefore, a multi-sig notary scheme has been proposed to reduce the centralized problem. However, this multi-sig notary scheme can only act as a temporary transition plan since it still has potential evil risks.
2-way peg
A 2-way peg (2WP) allows the transaction of assets from one blockchain to another and vice-versa. The assets are not transferred technically but temporarily locked on the source blockchain while the same number of tokens are released in the target blockchain. The transferred asset can be withdrawn when the equivalent number of tokens on the target blockchain is locked again. The problem with this scheme is that the transaction is not completed until the target blockchain has released the equivalent amount of assets. Therefore,any 2WP system must compromise and rely on assumptions of the honesty of the actors involved in the 2WP.
Sidechains
The concept of a sidechain was first proposed in 2014. The main goal of the sidechain is to extend the scalability and functionality of the blockchain system. When using a sidechain as a trusted centralized entity in a 2WP system, it can be used as a standalone transaction dealer. The sidechain can enforce the security of transactions by implementing a consensus-validated protocol. Since a sidechain needs to update state changes back to the underlying blockchains, the blockchains need to trust or verify the transactions sent out by sidechains. Usually, the cost of trust (a vulnerable sidechain) or verification (gas fee) is very high.
Cross Chain Gateway and relays
Blockchain relay schemes verify transactions across blockchains in a decentralized manner. While this enables blockchain interoperability applications like cross-blockchain token transactions, relays can become expensive since state-of-the-art relays require every single block header of the source blockchain to be stored by the destination blockchain.
COZ Protocol Architecture
Coz Protocol derives the basic ideas from multi-way sidechain (multiple blockchains with a shared sidechain) and solves the trustworthy problem of the third parties by verifying the computation on sidechain via ZK-Rollup proofs.
In order to achieve secure cross-chain operation, Coz Protocol ensures that the following two assumptions hold: 1) custody of locked tokens need to behave honestly (only perform transactions from instructions delivered from Layer 2); 2), the L2 needs to deliver transactions sincerely based on the published algorithms. The first assumption can be implemented by adding a transaction signature check into the smart contract on the Layer 1 blockchain. (This is expensive since performing hash functions on smart contracts involves heavy arithmetic calculation). The second assumption can be enforced by performing a ZK-Rollup proving and verifying scheme between the peg and the source blockchain. (This is also very expensive).
Coz Protocol uses batched transactions, a non-trivial solution, to reduce the cost of the signature check and snark proof check. We roll up large amounts of transactions together before pushing them back to the blockchains and batch their signature check and snark proof together.
The goal of Coz Protocol is to provide a universal way to manipulate and synchronize the asset state between various blockchains which support smart contracts. To achieve this, Coz Protocol introduces a side chain to process most of the transactions that query or alter the state. This side-chain invokes the bridge contract on each blockchain to broadcast the change of the state through batched atomic update functions. Those bridge contracts use a ZK-Rollup verification scheme to ensure the state updating is valid and then perform the updating accordingly.
Components in COZ-Protocol
Suppose we have two blockchains A and B. Four entities are involved to synchronize the state between blockchain and B
The idea behind this is that on each chain, there is a monitor and a bridge contract pair (M, C) that play together to handle the transaction requests from outside and broadcast the state change to outside. It is designed as a pair because bridge contract C does not have a way to contact the outside, however, it can broadcast an event that contains information it wants to send to another chain. Thus, a monitor M is needed to capture those events and synchronize them with outside.
Event notification from Smart contract to L2
Coz Protocol has two different types of transactions. We call transactions on main blockchains the native transactions and transactions on L2 the L2 transactions. Native transactions will change the global state locally in its own chain but cannot broadcast the change to others. Thus, a paired monitor is used to subscribe to the native events from the smart contract and then notify the L2 chain. Once L2 is notified of certain native transactions, it will update the global state and then broadcast the change of global states via batched update transactions.
Since smart contract C cannot ensure that the monitor M reports its event honestly, thus the monitor M needs to be trusted. (Zamyatin et al. [233] prove that “there exists no asynchronous cross-chain communication protocol tolerant against misbehaving nodes”.) The monitor M can be centralized or decentralized and in Coz Protocol we used a group of trusted monitors to form a fault-tolerant relay monitor M which makes sure that all events from smart contract C are reported to L2 honestly.
The only event that triggers smart contract C is the deposit event. Since Coz Protocol will not change the global state until the deposit event is sent to the L2, the deposit transaction will not change the global state in the first place.
State synchronization and batch update
Coz Protocol relies on snark-based batch updates to synchronize global states. Each batch update has a nonce and signature field. The batch updates together with the nonce are signed with a ring signature and this signature is verified in the L1 contract C to ensure that the batch updates are honest. After each batch update, the nonce in C will increase by one so that the order of batch updates is preserved.
COZ Protocol User Cases
Deposit
Transactions on L2
Withdraw from L2
Transaction Rollup Architecture
Suppose that we have a sequence of transactions each has input extraction functions {ei,k} k=1,2,··· which is of type state → uint256. Then the output of each transaction is a sequence of state update functions of type state → state.
Verification Contract
A verification contract is a solidity contract. It provides three interfaces:
With the Coz Protocol’s ZK-Rollup based multi-blockchain synchronizer, a vast number of cross-chain applications can run safely and efficiently on top of it.
Token Economy
$COZ is the native token issued by the Coz Protocol to implement community governance, capture the fee revenue generated by the system and incentivize protocol participants. $COZ can be acquired by trading with the protocol, providing liquidity, and actively participating in community governance. $COZ holders can share the fee revenue of the protocol and participate in community proposals and voting on ecosystem development, asset listing, etc.
Total Maximum Supply: 10,000,000,000 $COZ
Initial Circulating Supply: 8% (Liquidity excluded)
Transaction Mining Rewards (25%): Continuously distributed to users who trade with Coz bridge and DEX after mainnet launch following a yearly halving schedule.
Liquidity Mining Rewards (20%): Continuously distributed to early liquidity providers of featured token pairs after mainnet launch for 1 year.
Team & Ecosystem Development (25%): 500,000,000 $COZ unlocked at TGE with the remaining tokens evenly distributed monthly for 4 years.
Private Investors and Early Contributors (19%): 200,000,000 $COZ unlocked at TGE with the remaining tokens evenly distributed monthly for 4 years.
Public Sale (1%): 100,000,000 $COZ – 100% unlocked at TGE
Initial Liquidity and Marketing (10%): Provide initial liquidity and other marketing promotions
Roadmap
2021 Q2
2021 Q3
2021 Q4
2022