Twitter Telegram
Twitter Telegram

COZ Protocol: Cross-chain Synchronizer based on ZK-Rollup

Download Whitrpaper

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.

  • Features
  • Roadmap
  • Blog

 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

 

  1. A smart contract CA on A.
  2. A smart contract CB on B.
  3. An L2 chain handles transactions and sync between CA and CB.
  4. A monitor MA to monitor events for CA.
  5. A monitor MB to monitor events for CB.
  6. A monitor ML2 to monitor events for L2.

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

  1. Deposit is the only API of Seamless Cross that triggers on L1 bridge contract C. It transfers a certain amount of assets from the user into C.
  2. Deposit process is divided into three stages: At the first stage, the user calls the deposit function on L1 which transfers tokens to the Seamless Cross bridge contract. At the second stage, the monitor M notices the deposit event and reports it to L2 so that L2 can adjust the balance of the user by the same amount of wrapped token on L2. At the third stage, L2 broadcasts the transaction to other blockchains (through the next roll-up transaction) so that all the blockchains can have a synchronized global state.
  3. It is ML2’s responsibility to fire all the batch updates and collect all the ACKs from all L1 blockchains.

Transactions on L2

  1. L2 transactions in Coz Protocol include all transactions that only query or change the global state.
  2. L2 transaction process is divided into two stages. At the first stage, the user starts a transaction on L2 which may change the global state. At the second stage, L2 broadcasts the transaction to other blockchains (through the next roll-up transaction) so that all the blockchains can have a synchronized global state.
  3. It is ML2’s responsibility to fire all the batch updates and collect all the ACKs from all L1 blockchains.

Withdraw from L2

  1. L2 Withdraw transaction in Coz Protocol is used to withdraw a certain amount of token from L2 to an L1 recipient.
  2. L2 Withdraw transaction is divided into four stages. At the first stage, the user initiates a transaction on L2 which will reduce the balance of certain tokens in the global state. At the second stage, L2 broadcasts the transaction to other blockchains (through the next roll-up transaction). At the third stage, C receives the withdrawal request and transfers a certain number of tokens to the recipient account in L1. At the final stage, M sends ACK back to ML2
  3. It is ML2’s responsibility to fire all the batch updates and collect all the ACKs from all L1 blockchains.

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:

 

  1. The constructor encodes the Snark setup
  2. The verify function verifies the snark proof and produces the state update function.
  3. The info function returns the contract info.

 

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

  1. Project kick-off
  2. Coz Protocol whitepaper

2021 Q3

  1. Launch the official website
  2. Launch Coz cross-chain bridge Beta version

2021 Q4

  1. Coz cross-chain bridge based on Zk-Rollup
  2. Support more public chains (ETH, BSC, Solana, Polygon, Avalanche, Cardano, Tron, etc.)
  3. Coz cross-chain DEX Beta version

2022

  1. Coz cross-chain DEX based on Zk-Rollup
  2. Continue to expand the Coz ecosystem
Telegram Twitter Medium