Wormhole: A Smart contract implementation based on Bitcoin Cash

Author: Chia Chi, Jiang Heping, Wen Long

Abstract

Born at the block height of 478,558, Bitcoin Cash (BCH) has been dedicated to bringing a reliable electronic cash to the world and fulfilling satoshi’s original vision as a "peer-to-peer electronic cash." It enjoys global seamless circulation, permissionless innovation and other features. How to issue token on the Bitcoin Cash blockchain? Many developers have brought up with ideas such as Coloured-Coins. And Andrew Stone proposed to increase OP_GROUP to implement the token scheme as he mentioned in Enable representative tokens via OP_GROUP on Bitcoin Cash. The OP_GROUP solution can only be realized by altering consensus rules of Bitcoin Cash. More specifically, it enables functions similar to that of ERC20 token protocol on the Ethereum network.

Any proposals enabling token issuance that requires certain consensus upgrades will inevitably cause problems, including technical risks, harsh conflicts and huge controversy among community developers. The concerns of the opponents in the dispute are likely to be true. Regardless right and wrong side in this controversy, this could help prevent “radical” initiatives being implemented to ensure the stability and security of the network protocol. However, it makes it harder to promote innovation. The controversy that led to the expansion of the independent block of the Bitcoin Cash community, the prolonged and unconstrained generation, is an even more unavoidable evidence of social psychology.

Innovation requires a PERMISSIONLESS community. We have also been exploring ways to implement smart contracts on Bitcoin Cash blockchain without changing the consensus rules. After tremendous research effort, we have paid attention to the OmniLayer protocol, a scheme to realize token issuance through the OP_RETURN opcode. It is the technical basis for daily distribution and circulation of USDT. The Omni Layer runs on top of Bitcoin blockchain. Since the Omni Layer protocol uses the MIT license (open source), we forked the Omni Layer protocol and implemented the tech feature on Bitcoin Cash blockchain to achieve token issuance. We named this technical solution Wormhole protocol, and the original token in the protocol is named Wormhole Cash.

Term

• OP_RETURN: One of the opcodes in Bitcoin Cash. Any transaction outputs containing it is

Un-spendable, and nodes can safely move it out of the UTXO collection without affecting the total volume of the UTXO collection. After the protocol upgrade in May 2018, BCH increased its default data-carrier-size to 220 bytes.

• Wormhole protocol: It is based on the Omni Layer protocol that make protocol specs for smart contracts on the Bitcoin Cash blockchain possible.

• Wormhole Cash: The base currency used in the Wormhole protocol, or "WHC" in short.

Theory

Wormhole Cash is based on the Bitcoin Cash blockchain and is attached to the Bitcoin Cash block,

transferring and burning into the BCH blockchain without changing the current BCH consensus rules.

The metadata information of the transaction is written on OP_RETURN. Based on the Wormhole protocol, its issuance, transferring and burning are all done through the Bitcoin Cash transaction, and through recognizing(reading) data stored in OP_RETURN.

Wormhole protocol multiplexes Bitcoin Cash's transaction transfer system to read transactions, addresses, and OP_RETURN data on Bitcoin Cash blockchain.

Wormhole protocol is a superset of the Bitcoin Cash network consensus. The metadata it identifies is only the OP_RETURN data in the consensus protocol of the Bitcoin Cash blockchain, and consensus rules of Bitcoin Cash do not need to understand data in OP_RETURN.

Implementation

Wormhole protocol is implemented by integrating into Bitcoind. But the consensus rules of Bitcoin Cash themselves do not need to be changed. Bitcoind clients that integrates the Wormhole protocol are called Wormhole clients. Nodes running the Wormhole client will be able to recognize the OP_RETURN Wormhole protocol.

Security and consensus rules

Wormhole Cash represents a two-layer security approach.

The first layer is Bitcoin Cash's transaction security. Bitcoin Cash adopts POW algorithm as a decentralized timestamp server. The algorithm has been working stably for nearly 10 years. Here are some of the benefits of the UTXO model:

• UTXO requires no balance maintenance

• UTXO serves as an independent data logger that can speed up transaction verification.

• UTXO model only “cares” locking scripts and unlocking scripts.

• UTXO has high performance when processing transactions.

Wormhole protocol multiplexes the entire UTXO security model of BCH and its decentralized timestamp server model.

The second layer of security is that nodes running the Wormhole protocol will not analyze data that does not conform to the Wormhole protocol. Each node has the ability to reanalyze transaction data and calculate the most “recent legal final state” of Wormhole Cash.

Wormhole Cash（WHC）

Wormhole Cash (WHC) is the base currency in the Wormhole agreement. The reason why WHC was introduced is for:

When the smart contract is implemented in Wormhole protocol, Wormhole protocol layer cannot control Bitcoin Cash, so transactions can't be implemented in the Wormhole protocol layer. And

when implementing smart contracts Gas needs to be introduced as a protective measure against network abuse, and there is also a need for the Wormhole protocol to have a raw base currency.

The generation of WHC

WHC is generated by the mechanism of Proof-of-Burn, and users who hold BCH can use

the Bitcoincash:qqqqqqqqqqqqqqqqqqqqqqqqqqqqu08dsyxz98whc address to send 1 BCH to generate the WHC when the Wormhole protocol is officially launched. If less than one BCH is sent to the address, then no WHC will be generated. This “burn to generate” process is subject to risks of rollback of the BCH blockchain. Therefore, WHC can only be generated when 1,000 confirmations are finished. 1 BCH can get 100 WHC.

Based on known cryptography theory and engineering practice and research, nobody owns the private keys of the address bitcoincash:qqqqqqqqqqqqqqqqqqqqqqqqqqqqqu08dsyxz98whc. And no one used this address in the history of Bitcoin Cash blockchain before we started working on the development of Wormhole protocol.

In order to prevent the theoretical extreme situation

[censored paragraph] - In the future, if any methods be used to create the private key of this address - the BCH protocol might prohibit coins in this address from being transferred. Of course, this is not in the concerned part of this article and me.

If there are market demands around WHC and liquidity is high, users who need WHC can purchase WHC from the market.

Why not implement two-way anchoring with BCH? This question has made countless engineers study the two-way anchoring since the sidechain theory was proposed. Unfortunately, there is no feasible two-way anchoring method that are safe, decentralized, and can effectively deal with the inevitable rollback risk of blockchain. When discussing about Star Trek, Elon Musk said that he is not coming back after immigrating to Mars. Wormhole protocol implements a smart contract, with a programming different language with Bitcoin Cash, is very similar to the one-way ticket for Star Trek. Each satoshi (BCH) burned will not be back. This type of "burning to issuing" is like a one-way ticket to Mars.

The process of burning to generate WHC has no deadline.

WHC use cases

Fees are often used to prevent abuse of the network, or the use of the network exceeds current technology and the blockchain infrastructure that allows. The implementation of smart contracts in the Wormhole protocol requires BCH transactions. The Bitcoin Cash transaction itself will cause fees can effectively cope with DoS attacks. Therefore, in the early implemented Wormhole protocol, no WHC fees are demanded for transfer.

The situations that need to pay WHC transaction fee:

1. Newly created token is set pay 1 WHC. Transaction fees will be burned directly and thus the total supply of WHC will be reduced. Creating a Token requires the consumption of computing resources. WHC fees are designed to prevent malicious attacks to Wormhole nodes.

2. one-to-many transfers. For example, sending token to all addresses that have a certain token, you need to pay WHC transaction fee

3. Smart Contract's Gas

4. Other transactional operations, or activities might fall into DoS risks.

Token issuance

Anybody is free to create a token on the system after paying the normal BCH transaction fee and the WHC creation fee. Currently, the WHC protocol supports three types of Token creation:

1. Fixed Token

• After creation, the creator automatically owns all tokens immediately

• Cannot be increased, cannot be burned

• Cannot start a crowdfunding

2. Token can be crowdfunded

• Automatically trigger Crowdfunding after creation

• After creation, the creator does not own all tokens

• After closing the crowdfund, Token left automatically goes to the creator's address

• Cannot be increased, cannot be burned

3. Manageable Token

• When created, total number of the tokens is 0

• Cannot be used for crowdfunding

• Can be increased, can be burned

Token transfer

Both tokens issued on Wormhole protocol and Wormhole Cash itself can be transferred. 1-to-1 transfer will only cost BCH transaction fee, no additional fees needed. TX Fees will be decided by BCH protocol.

In addition to BCH fees, one-to-many transfer also requires certain WHC fees, which is denominated and charged by the WHC. The one-to-many transfer is mainly used for Token airdrops. The WHC fees charged will be burned directly.

Token burning

Manually managed token supports direct burning, and the total number of the token (after burning) will be shown on the Wormhole protocol.

Wormhole Road Map

The development of the Wormhole protocol is divided into four phases: Earth, Tropos, Ionize,

Exophere

Earth (beginning)

Forked from the Omni Layer protocol, Wormhole protocol aims to implement smart contracts on BCH and will first focus on decentralized token issuance management.

To ensure the security and to implement it ASAP, we do not support decentralized trading on the Omni Layer protocol.

Tasks to be completed:

• Wormhole Core implementation: Adding token issuance onto Bitcoin ABC (version 0.17.2), which will be updated accordingly with the upgrade of Bitcoin ABC.

• Release the Wormhole protocol white paper

• Estimated completion time August 2018

Tropos

Tasks to be completed:

• Wormhole protocol-based decentralized exchange protocols will be re-implemented after enormous testing

• Wormhole's Android wallet reference implementation

• Wormhole's iOS wallet reference implementation

• Wormhole of the PC wallet reference implementation

• Estimated completion time November 2018

Ionize

Tasks to be completed:

• Implement ERC721 in the Wormhole protocol

• Develop the multi-language SDK. In order to make it easier for developers to develop at Wormhole, we will provide a multi-language SDK for analysing Wormhole.

• Wormhole Cash's cold wallet solution

• Estimated completion time January 2019

Exophere

Tasks lists:

• permissionless smart contract. The Omni Layer itself is not a mechanism for permissionless innovation. Any new type of contracts must be integrated into the code to be recognized. We will implement an unlicensed smart contract platform in the Exophere phase. In other words, any developers can deploy a smart contract into the network when complying with necessary rules for maintaining protocol security.

• Implement the Plasma protocol for further scaling. After huge internal research, we may have discovered an effective approach to realize Plasma. We may be able to implement it after further research. Meanwhile, Vitalik also announced on Twitter that they have discovered a way to implement Plasma. We can also implement Vitalik's upcoming approach.

• A new generation of smart contract virtual machines. Solidity, as a programming language that turns the concept of smart contracts into reality, has been extensively reviewed by computer experts. There have been some better ideas in recent years. We will probably work to develop some virtual machines using some new programming languages ​​to make the most efficient and developers-friendly computer languages ​​available for building DApps.

Estimated completion time June 2019

Summary

First of all, I want to give credit to Omni Layer. Its extensive use on USDT gives us confidence that more things can be done based on Bitcoin Cash. The Omni protocol is a complete protocol that takes full advantage of the features of the UTXO model and enables token management without changing the consensus rules and the protocol. The Omni team helped us a lot in developing Wormhole. Meanwhile, Omni Layer sticks to the spirit of open source and uses the MIT license, which makes permissionless innovation possible.

The UTXO model-based public chains have been struggling to realize smart contracts. The Wormhole protocol will enbale smart contracts on BCH and open new possibilities to Bitcoin Cash.

Document history

1.Version 0.1 Wormhole Cash Completion of Phase 1 （May 23, 2018）

2.Version 0.2 Wormhole Cash Roadmap （June 20, 2018）

3.Version 0.3 Wormhole Cash alpha version （July 15, 2018）

[1] Satoshi Nakamoto. Bitcoin: A Peer-to-peer Electronic Cash System. https://bitcoin.org/bitcoin.pdf ,Oct 2008

[2] OP_RETURN

[3] OmniLayer

[4] ERC20 Token Standard

[5] The Colored Coins Protocol