Ultimate Wormhole Protocol Guide

Did you know that the BCH blockchain enables tokenization and creation of smart contracts? Discover all about the Wormhole protocol and join us for BCHDEVCON in Amsterdam!

A Word from the Editor

In view of the upcoming BCHDEVCON hackathon in Amsterdam, we wanted to take a deep dive into the mechanics and possibilities offered by the Wormhole protocol. We hope that this article will demystify this protocol; a meta-layer on top of the BCH blockchain that enables tokenization and creation of smart contracts, similarly to how the Omni layer functions on BTC.

1. What is the Wormhole Protocol?

Wormhole is a new meta-protocol that enables token issuance and smart contract creation on Bitcoin Cash without affecting the underlying BCH blockchain consensus. Thanks to the application of different programming languages including Javascript, it could easily be used by developers for the creation of tokens, ICOs, and digital assets on top of the Bitcoin Cash blockchain with the ERC-20 format enabled and the ERC-721 coming soon.

The Wormhole protocol has been forked from the Omni Layer with the collaboration of the Omni team, and then adapted to the BCH blockchain. It strongly benefits from BCH’s larger block sizes and uses Bitcoin opcodes to write arbitrary data into the blockchain via zero value transactions or clusters thereof.

The Wormhole network nodes recognize the right opcodes and can process these transactions selectively which dramatically increases Wormhole’s TPS (Transactions Per Second). The Wormhole network also benefits from the speed, the scalability, and the security incorporated within the Bitcoin Cash layer including the decentralized timestamping, PoW, transaction traceability, low fees, and larger block-sizes.

2. How did it all start?

2.1. Blockchain spamming and the block-size debate

The idea behind Wormhole can be traced back to the early debates about the Bitcoin block size and the smart contract functionality; these topics continue to galvanize the crypto community today.

Initially, Bitcoin did not have a block size limit, and many early users added non-transactional data into the blockchain by sending small amounts of Bitcoin and incorporating a binary code within the value of transactions, for example. Soon it became apparent that putting non-transactional data into the blockchain in such a way could have some repercussions like increasing block sizes and by extension also the transaction costs because of decreasing overall TPS.

Bitcoin network’s nodes (except for the lightweight nodes) need to store the full blockchain copies and download each new block within a specified time to stay up to date with the rest of the network. With a block-size increase, there is a greater potential for the exclusion of the nodes that run on lower internet speeds or don’t have enough storage space. Larger block sizes could also theoretically dis-incentivize nodes from processing large-sized or lower fee transactions, in favor of more profitable mining.

To keep the network more decentralized and accessible to all, early Bitcoin developers decided to curb the blockchain bloat and to introduce a 1MB size limit on BTC blocks. This tradeoff kept BTC’s blockchain small and minimal, but made BTC unsuitable to be used for non-transactional data registry necessary for important functionalities like token issuance, smart contract creation, or DApp building.

In summer 2017, the block-size discussion which divided the Bitcoin community resulted in a hard fork that split BTC and BCH and allowed Bitcoin Cash to increase its block-size, first to 8MB, and currently to 32MB. The larger block capacity improved BCH’s scalability and by extension decreased the fees whenever a large number of transactions compete for validation on the same block. It also granted the BCH blockchain more wiggle room for second-layer projects and DApps to be built on BCH versus BTC.

2.2. The smart contracts functionality

The ongoing discussion about whether blockchains should remain purely transactional records or carry more complex contractual information, inspired many projects in the crypto sphere including the creation of Ethereum by Vitalik Buterin. Ethereum is a blockchain explicitly designed to issue tokens and smart contracts, with built-in functionality to store more data.

Thanks to the issuance of tokens and smart contracts, Ethereum attracted many developers and projects, gained higher market capitalization, and wider adoption. However, as shown by the recent success of Crypto Kitties, the network still sometimes suffers from congestion and scalability issues, which results in high gas fees. Thousands of ETH worth of transactions remained unconfirmed during high transactional traffic and the crowdfunding of multiple ICOs.

Many believe that Bitcoin blockchains based on UTXO (Unspent Transaction Output) models could be more efficient, scalable, and less congested if the smart contract functionality could be somehow enabled on top of them. The incorporation of tokenization and smart contract features could also help BTC and BCH adoption and bring more projects to these networks.

2.3. The 2nd Layer Argument

In 2012 J. R. Willett published a white paper arguing that Bitcoin could be used as a protocol layer on which other layers with new and different rules could run. Willett thought his solution would allow for more diverse functionalities beyond transactional ledger, but without affecting the underlying blockchain. Subsequently, Mastercoin was launched in 2013, in 2015 and rebranded into the Omni Platform, a meta-protocol for the creation of custom digital assets on top of the Bitcoin core. The most widely known token issued on Omni is the dollar-pegged token Tether (USDT). Many developers are researching similar solutions for Bitcoin Cash, including Jiazhi Jiang’s team that announced a successful launch of the Wormhole protocol earlier this year.

3. How does it work?

The Wormhole protocol makes use of OP_RETURN instructions as well as Proof-of-Burn to enable issuance of new tokens and digital assets on the BCH blockchain.

3.1. The UTXO model

As we mentioned before, early blockchain development saw people introducing non-transactional data into the chain by sending tiny amounts of Bitcoin. This did not only affect the block and the blockchain size, but it also dramatically increased the UTXO register and caused congestion on the BTC network.

The Bitcoin derived chains are based on the UTXO model, where records with the unspent output are analyzed on nodes to validate transactions and keep track of the current coin’s status. In the UTXO model, no Bitcoin is ever really, physically transferred. Imagine that your friend sent you 2 BTC. The transaction registered an output that the BTC in his wallet became ‘spent.’ At the same time, a new ‘unspent’ 2 BTC was created in your own wallet. This ‘new’ 2 BTC is now represented not as a number of coins but as one unspent transaction. If you then want to send someone 0.5 BTC, this process will create two transactions. One of 0.5 BTC spent, and one of 1.5BTC unspent that you ‘send to yourself’ so that you are left with a ‘new’ unspent 1.5BTC in your wallet.

The nodes check the unspent transaction outputs to confirm that specified coins have never been used as an input in another valid-output transaction. If they were used as an input, it means that the BTC in question has already been spent and can’t be used in another operation. The UTXO based model is faster and more efficient than other models. However, the more unspent transactions, the more work the nodes need to perform to confirm the current status of all the transactions and the coins.

3.2. The OP_RETURN Solution

The Wormhole protocol uses OP_RETURN code to circumvents the network congestion due to excess UTXO. This opcode allows for a transaction’s output to be invalid with any coin amounts automatically returned to sender. In other words, it does not create an unspent register or adds to networks overhead, but still allows users to write small chunks of information into the blockchain without transferring any coins.

This opcode is currently used by multiple second-layer and meta-layer apps to build functionalities on top of the BTC and BCH blockchains without burdening the UTXO network, for example, Coinspark, Eternity Wall, Colu, Docproof, Memo Social Network, Omni Layer, and as of August 2018 also the Wormhole Protocol.

The limitation of the OP_RETURN is the space available for users, which is only 40 bytes per transaction for BTC and up to 220 bytes for BCH. With a larger block size limit, BCH allows for more room and creativity to build DApps on its blockchain.

3.3. The Proof-of-Burn

The Wormhole protocol uses Proof-of-Burn which requires burning of BCH to create native platform tokens — Wormhole Cash (WHC). The WHC can be used to launch ICOs, contribute to projects, and pay fees similarly to how gas works for Ethereum network. As a second layer, the tokens don’t directly compete with BCH, but they stimulate and incentivize the system, and can potentially increase the adoption of Bitcoin Cash.

Proof-of-Burn relies on the principle of ‘burn to create’ which requires participants to send their BCH to a specified burning address for which no one has a private or public key. The current burn address for the Wormhole PoB is:

qqqqqqqqqqqqqqqqqqqqqqqqqqqqqu08dsyxz98whc

The address conforms with the requirements of a burn address, in that it is fresh and new, and derived using a specific sequence of steps as explained in the Wormhole GitHub directory. This proves that the address has no known key. It’s also highly improbable to use brute force to find such key, as it would require computing power far beyond the current or even future world’s computing capacity.

By sending 1 or more of BCH to this burn address, you take them out of the circulation and allow the genesis of WHC tokens. The potential of rollback issues, if less than 1BCH would be sent to the burn address, is solved by requiring of 1000 validations for valid WHC tokens to be created.

3.4. Wormhole Tokenization and ICO Functionality

Wormhole saw the burning of over $1.2M in BCH and creation of 150+ tokens in the first days after the platform launched in August 2018. In October 2018 ViaBTC, the world’s third-largest mining pool raised over 30 million by issuing a mining token on the Wormhole network.

The network continues to update its token creation algorithms which can now produce any tokens compatible with ERC20, and later next year, also ERC721 tokens.

Types of tokens available on the Wormhole Network include:

Fixed number of tokens that all belong to the issuer upon creation.

Managed number of tokens that can be increased or decreased.

Crowdfunding tokens generated during an ICO using a Wormhole crowdfunding algorithms.

Any Wormhole account may create various types of tokens and many tokens at the same time, but the crowdfunding algorithm only allows for one active ICO, with a specified number of tokens available for investors. Similarly to the Ethereum network, Wormhole has settings for automated early bird pricing and token cap cutoffs. The ERC20 compatible tokens can be purchased using WHC which is then immediately credited to issuer account. Once the number of tokens exceeds the specified ICO cap, any subsequent the transactions fail and money return to senders.

In comparison to Ethereum, the BCH network holds a few advantages, as it is built on the Bitcoin Cash blockchain which some argue makes ICOs safer, more efficient, and congestion free. The network provides a more reliable payment system with fewer issues stemming from insufficient gas fees.

As a meta-layer, the Wormhole protocol not only benefits from BCH’s scalability, transaction speed, and block size, but it can selectively process only the Wormhole protocol transactions on its nodes making it infinitely more efficient.

3.5. Wormhole Smart Contract Beyond UTXO

The UTXO model dramatically limits BTC’s Smart Contract functionality, even when using OP_RETURN instruction because of the limited space of 40 bytes available for arbitrary data per transaction.

However, the Wormhole Protocol takes advantage of Bitcoin Cash increase in block-sizes to push the OP_RETURN limit to 220 bytes per transaction, enough to store smart contract metadata in the BCH opcode. In effect, the protocol can execute smart contracts using OP_RETURN and still benefit from the high speed and decentralization of the UXTO model.

The Jiazhi Jiang’s team is working on other smart contract solutions that would attract more developers and entrepreneurs to the project. In 2019, the Wormhole project plans to roll out a multi-language SDK (Software Development Kit) and create a platform for permissionless smart contracts outside of the Omni layer mechanics. They are also working on machine learning solutions for contractual language that could help developers create safer smart contracts more efficiently.

4. The Wormhole Roadmap

The official Wormhole roadmap is divided into 4 phases called Earth, Tropos, Ionize and Exosphere.

Earth phase August 2018

Wormhole successfully forked from the Omni layer protocol and adapted it to the BCH network to enable token issuance function. As of today, more than 200 tokens have been created using the Wormhole protocol. On August 1st, Wormhole also issued their own native token WHC, by burning 1.2M BCH on the first day.

Tropos November 2018

Implementing a decentralized exchange protocol for Wormhole.

Android, iOS, and PC wallets.

Ionize January 2019

Implementing ERC721 protocol.

Providing multi-language SDK to facilitate application development.

Cold wallet for Wormhole.

Exosphere June 2019

Smart contract platform for Permissionless smart contracts outside of Omni layer solutions.

Plasma protocol implementation.

A new generation of smart contract virtual machine.

Enabling building DApps in a developer-friendly programming language.

🌀 Want to know more? Read more on the Wormhole blog, Twitter, Github and official website.

5. BCHDEVCON Hackathon Amsterdam

The first Bitcoin Cash hackathon in Europe: BCHDEVCON Amsterdam, will take place from 27th to 28th October 2018 at Rockstart, in the center of Amsterdam, in the Netherlands. This hackathon is part of a global series of hackathons that was launched earlier this month in San Francisco by Permissionless Ventures.

During this 32 hour non-stop hackathon, attendees will be able to compete on the BCH track or on the General track. We will provide access to the Wormhole testnet and attendees can choose whether to hardcode their own functionalities or to use various sandboxes including Wormhole or the BITBOX SDK. We look forward to seeing what kind of projects the teams will build and may the best one win!

BCH track prize: €3500/in BCH

General track prize: €1500/in BCH

This event would not be possible without our wonderful panel of judges that will be evaluating the projects during BCHDEVCON Amsterdam: