Suterusu Yellowpaper Update Series: 2. Anonymous BTC cross-chain transfer module

Anonymous BTC cross-chain transfer module

The Suterusu yellowpaper [suter_yellowpaper] introduced how to anonymize the digital assets issued on a blockchain supporting smart contract through running a second-layer Suter anonymous payment scheme. This section will further describe how we can build a privacy-preserving BTC cross-chain transfer module based on the Suter anonymous payment functionality.

The general idea is partially inspired by the wrapped BTC framework [wrappedToken]. Our system also relies on a consortium of asset custodians and merchants who work together to map the user’s Bitcoin to sBTC token on Suter blockchain. However, the major difference between our design and theirs is that we leverage our zk-conSNARK technology to preserve the anonymity of BTC cross-chain transfer while privacy is not the major concern of the wrapped BTC framework.

The general idea is a user will run an anonymous atomic swap protocol with the merchant to exchange his/her Bitcoin asset with the merchant’s sBTC tokens. In a separate procedure, the merchant will initiate a minting transaction with an asset custodian, who will then create sBTC tokens minting contract after receiving equal amounts of BTCs from the merchant. The sBTC tokens can be transferred privately between different merchants. The user can also exchange his/her sBTC tokens with a merchant for equal amounts of BTCs. Since all the BTCs are eventually held by the asset custodian, the merchant and asset custodian need to run a burn contract every now and then so that sBTC token balance of the merchant’s account will be reduced in exchange for the asset custodian sending equivalent amounts of BTC to the merchant’s BTC address.

The Suter anonymous payment functionality will be invoked to guarantee transactional confidentiality during the token minting, transfer, and burning process. Since the exchange of BTC held by the users and the sBTC token held by Merchant requires an anonymous atomic swap, the anonymous multi-hop locks (AMHL) technique proposed in the whitepaper [suter_whitepaper] can be applied to guarantee the privacy of this process.

Our framework includes the following entities:

• Custodian: The entity that holds the secret keys of the mint token, i.e., sBTC.
• Merchant: The entity that receives the mint sBTC tokens and runs the CreateFundTx algorithm to invoke the minting contract and also CreateBurnTx algorithm to invoke the sBTC burning contract.
• User: The entity that receives the minted sBTC tokens of the value equivalent to the BTCs he/she exchanges with the Merchant.
• Suter DAO member: The entity responsible for the on-chain governance of contract changes and the addition/removal of custodians and merchants. It will control a multi-signature contract that dictates the governing process.

Related Suter contracts

The Suter payment framework mainly involves the following three smart contracts to implement the privacy-preserving BTC cross-chain functionality.

• Mint. The merchant initiates a transaction to authorize the custodian to mint X sBTC to the merchant’s address on the Suter chain. The merchant sends the custodian X BTC tokens. Custodian waits for 6 confirmations of the BTC transaction and then creates a transaction to mint X sBTC tokens on the Suter blockchain.
• Burn. This contract converts sBTC back to BTC. The merchant creates a burn transaction, burning X sBTC tokens. The custodian waits for a certain number of Suter block confirmations of the transaction. The Custodian releases X BTC to the merchants’ BTC address and makes a Suter transaction marking the burn request as completed.
• Transfer. This operation enables the anonymous transfer of sBTC tokens in the Suter blockchain. The proof of transfer makes sure that the ciphertext has the right form and the sender has enough money.

User algorithms

An entity will run one of the following algorithms to interact with the smart contract. The output of these algorithms is raw transactions. They will be signed using the public key of the Ethereum account from which they are sent and destined to the Suter smart contract.

• InitMint(adr, sk_Merchant): This algorithm takes the merchant’s secret key sk_Merchant to generate a signature that authorizes the custodian’s account pk to mint sBTC tokens to the merchant’s address adr. Note here the amount of sBTC tokens will be encrypted under the custodian’s public key and thus its confidentiality can be guaranteed.
• Mint(adr, amt) adds funds to an account. It takes a public key pk and an amount amt as inputs.
• CreateTransferTx(sk_from, pk_to, amt, st) transfers sBTC token from one account to another. It takes a secret key sk_from, a destination public key pk_to, an amount amt, and the state of the smart contract st at a certain block height h as inputs. It outputs tx_trans. (For anonymous transfers, this algorithm would also take a set AnonSet as input, which would contain the public keys of both the senders and receivers. AnonSet would be a part of the output too.)
• CreateBurnTx(sk, st) withdraws the entire sBTC balance from an account. It takes a secret key sk and a state st as inputs.
• ReadBalance(sk, st) reads the balance of an account. It takes a secret key sk and state st as inputs, and outputs an integer b.

Some of the above contracts and transactions, including Mint, CreateTransferTx and CreateBurnTx, are essentially identical to the counterparts of the original yellowpaper [suter_yellowpaper], which implies the transactional confidentiality can be guaranteed by the privacy-preserving nature of the underlying algorithms.

The more formal description of the main contracts and user algorithms mentioned in the above scheme will be provided in the next article.

[suter_yellowpaper] Dr. Lin. Suterusu yellowpaper v 0.2, 2020. https://github.com/suterusuteam/yellowpaper.

[wrappedToken] Republic Protocol Kyber Network, BitGo Inc. Wrapped tokens, a multi-institutional

framework for tokenizing any asset, 2019.

[suter_whitepaper] Dr. Lin. Suterusu whitepaper, 2020. https://github.com/suterusuteam/whitepaper.