Token Bridge Protocol
In this section, we describe our design for transferring ERC-20 tokens for Züs on the Ethereum blockchain to native tokens on the Züs blockchain.
Last updated
In this section, we describe our design for transferring ERC-20 tokens for Züs on the Ethereum blockchain to native tokens on the Züs blockchain.
Last updated
In this discussion, we refer to the ERC-20 [12] tokens as WZCN, and to native Züs tokens as ZCN. Our design is inspired by the Rainbow Bridge protocol [1]; reviewing their design can be beneficial to understanding our own. In our design, an Ethereum smart contract is needed to track the WZCN tokens, provably destroying (burning) them when a client wishes to convert to ZCN, and minting new WZCN when a client has provably destroyed ZCN. We refer to this smart contract as the WZCN mint. On the Züs end, Züs miners must verify special ZCN mint transactions and then generate new ZCN.
We also introduce the role of authorizers, trusted entities responsible for verifying transactions and sharing the results between the blockchains. The membership set of the authorizers must be maintained on both blockchains; we omit the details of tracking authorizer identities in this paper.
Figure 8 details the process of converting WZCN to ZCN. The steps are outlined below:
The client owning WZCN writes a transaction to the WZCN mint to burn tokens; we refer to this transaction as the WZCN burn transaction. This transaction contains: • The amount of WZCN burned. • The client’s ID on the Züs blockchain. • A sequential nonce. (This nonce is distinct from the nonce used in Ethereum’s protocol.)
The Ethereum network accepts the transaction and includes it in the blockchain. Note that it will only be accepted if the nonce is one greater than the previous nonce. The authorizers monitor the Ethereum blockchain for WZCN burn transactions.
Each authorizer verifies that the transaction has been accepted on the Ethereum blockchain. If the request is valid, the authorizer sends the client a proof-of-WZCN-burn ticket. This ticket contains: • The Ethereum transaction ID. • The amount of ZCN to be minted. • The client ID to receive the ZCN. • The nonce provided the client in step 1 above. • The authorizer’s signature.
Once the client has gathered sufficient tickets, they write a ZCN mint transaction containing these tickets. The Züs miners verify the validity of the tickets, checking the signatures and the nonces. If the ZCN mint transaction is valid, the miners accept the transaction and allocate new ZCN to the client’s account.
The reverse process is similar. A client burns ZCN and presents proof to the authorizers, who then authorize the generation of new WZCN tokens.
The steps for this process are as follows:
1. The client writes a ZCN burn transaction, destroying ZCN tokens. This transaction includes: • The amount of ZCN to burn. • The Ethereum address to receive the new WZCN. • The nonce value, using the same sequence as in Section 5.1.
The Züs miners accept this transaction if the nonce is valid and the client has sufficient ZCN.
Each authorizer monitors the Züs blockchain for a ZCN burn transaction. Once the transaction is accepted, the authorizer sends the client a proof of-ZCN-burn ticket, containing similar information as the proof-of-WZCN burn ticket: • The Züs transaction ID. • The nonce value. • The amount of WZCN to be minted. • The Ethereum address to receive the WZCN. • The authorizer’s signature.
4. Once the client has gathered sufficient tickets, they write a transaction to the WZCN mint, including the tickets from the authorizers.
5. The WZCN mint verifies the validity of the tickets, checking the signatures and the nonce values. If the transaction is valid, the WZCN mint creates new WZCN for the client.
It is possible that the process could break down due to a failure at one step. For instance, the client machine might crash, and be unable to collect the proof-of burn tickets. In these cases, it is possible for a client to request replacement tickets from the authorizers. The client must provide the transaction burning the ZCN or WZCN. The authorizers must verify that the transaction has been accepted, and then can re-issue the tickets. Note that the authorizers are not responsible for tracking the nonces or the funds, instead relying on the Züs miners or the Ethereum smart contract to do that work.
Each authorizer must stake some amount of both ether and ZCN to join the set of authorizers. The details of how authorizers are selected falls within the purview of our governance protocol [7]. Whenever a proof-of-WZCN-burn ticket from the authorizer is included in a ZCN mint transaction, the authorizers are rewarded with transaction fees paid in ZCN. The amount of these fees are likewise selected by the governance protocol, and not negotiable by either the authorizers or the clients. Similarly, when a proof-of-ZCN-burn ticket from the authorizer is included in a call to the WZCN smart contract, the authorizers are paid in ether by the WZCN mint smart contract. Again, the amount of these transaction fees are specified in the smart contract and non-negotiable.