Wormhole: A deep dive
Before 2020, Blockchains had two major problems -
- Tokens are hard to move between blockchains without relying on centralized exchanges for bridging and swapping tokens.
- Decentralized applications (DApps) and smart contracts on different blockchains cannot communicate with each other.
So, how to solve these problems?
The solution is to make blockchain networks interoperable and make cross-chain communication possible.
In short, it is the capacity to observe and access data stored in another blockchain,
In this piece, we will explore -
- How Blockchain Networks Currently Communicate
- Problems with the Current Approach to Cross-protocol interactions
- Introduction to Wormhole
- Applications of Wormhole
- Portal Token Bridge
- Portal NFT Bridge
- Competition and Business Model
- Hottest Projects on Wormhole
- Future Use-cases and Applications
How Blockchain Networks Currently Communicate
Applications and smart contracts running on the same blockchain can synchronously communicate with one another by default.
They are unable to speak with one another directly if they reside on different chains.
So how does an application running on one chain communicate with another chain?
It sends a message from the source chain to the target chain,
The target chain now relays, verifies, and interprets it to continue with the intended action.
All instructions needed to carry out the requested actions on the target chain are included in this message.
Because of this messaging routine, composability is hampered. This is due to the requirement that several programs incorporate all of their instructions into a single message in order for synchronous actions to occur.
As a result, design patterns are emerging where dApps nest their many operations inside of one another to form a single, embedded message:
e.g.: User -calls> dApp -calls> Token Bridge -calls> Messaging Protocol
Problems with the Current Approach to Cross-Protocol Interactions
Trust: In the nested method, each subsequent protocol in the sequence of calls must trust each preceding protocol. In the above example, the destination chain’s call stack would be unpacked in reverse order, indicating that the dApp is relying on the Token Bridge to transmit its instructions.
If the chain’s weakest protocol fails, the entire system fails.
Integration Effort: Every dApp in the chain must integrate with the dApp that comes before and after in the chain of nested calls. The threshold for this is high due to the above-mentioned security issues.
Composability is constrained.
Complexity: The above message looks simple. It’s simply how one chain is sending a message to another chain. Meaning only two chains are involved.
When you think about three, four or more chains composable with each other with this method, it becomes very complex.
Security: In a single chain, it is very convenient to restore the chain, and everyone can restore assets to their initial state. But if there is a problem with assets in the case of multiple chains, the recovery of the chain will be a big problem.
Introduction to Wormhole: The solution
In 2020, Certus One (which was acquired by Jump Crypto) unveiled Wormhole V1, which was first intended to serve as a conventional token bridge connecting Ethereum and Solana. It was the first bridge on Solana and was in charge of establishing a significant portion of the early liquidity in the Solana and Serum ecosystems.
Wormhole quickly expanded past Solana and token transfers into a cross-chain messaging protocol.
As a decentralized generic interoperability framework for many blockchain ecosystems, Wormhole v2 was introduced in August 2021 with initial support for Solana, Terra, Ethereum, and Binance Smart Chain.
How does Wormhole achieve cross-chain communication?
Wormhole does this by emitting messages from one chain which are observed by a Guardian network of nodes and verified.
After verification, this message is submitted to the target chain for processing.
This simple message passing primitive enables cross chain functionality.
Users interact with xDapps (cross-chain decentralized applications) to transfer xAssets (cross chain assets) between networks or access their xData (cross chain data) to provide them services on their current network.
How does Wormhole Protocol Work?
How the Core Wormhole Bridge Works
The core Wormhole bridge operates by running smart contracts on both the Source Chain (where the data currently resides) and the Target Chain (where the data will be moved), and generally follows this workflow:
1) An end user or another smart contract publishes a message using the Bridge Contract on the Source Chain.
2) The Wormhole Network observes this transaction and issues a VAA once it crosses its confirmation threshold.
3) An off-chain process collects the VAA and submits it in a transaction to the Bridge Contract on the Target Chain, which can verify the message.
Wormhole Architecture
The ecosystem built around the protocol is complex as you can observe in the following diagram.
Let’s go over each component one by one :
On-Chain Components
xDapp Contracts — These are contracts developed by developers. They receive transactions from the end user and then interact with other xDapp contracts and Wormhole Ecosystem Contracts in order to provide their service.
Ecosystem Contracts — These contracts are a part of the Wormhole Ecosystem. They function as feature contractors of Wormhole to xDapp developers.
Core Contracts — These are the contracts that the Guardians observe and which fundamentally allow for cross-chain communication.
xAsset Contracts — These Contracts allow normal tokens to be converted to xAssets and enable these xAssets to be bridged.
Off-Chain Components
Guardian Network — The Guardian Network is designed to serve as Wormhole’s oracle component. Guardians observe the Core Contract on each supported chain and produce VAAs (signed messages) when those contracts receive an interaction.
Guardian — One of 19 validators in the Guardian Network that contributes to the VAA multisig.
VAAs — Verifiable Action Approvals (VAAs) contain the messages emitted by xDapps along with information such as what contract emitted the message. The VAAs are signed by the Guardians and need more than ⅔ of the total signatures to be considered authentic.
Specialized Relayers — Relayers that only handle VAAs for a specific protocol or xDapp. They can execute custom logic off-chain, which can reduce gas costs and increase cross-chain compatibility. Currently, xDapp developers are responsible for developing and hosting specialized relayers.
Applications of Wormhole Protocol
- Portal Token Bridge
- Portal NFT Bridge