Introducing the Wormhole Bridge
Certus One is excited announce the Wormhole project, a bidirectional, decentralized ERC-20 ⇄ SPL token bridge between Ethereum and Solana.
Serum, the world’s first high-performance DeX with an on-chain order book, launched on the Solana chain last month. It takes advantage of Solana’s breakthrough performance and sub-second confirmation times.
However, bootstrapping a new ecosystem is hard and all foreign tokens currently traded on Serum are wrapped tokens issued by FTX. The remaining hurdle for bringing more DeFi apps and value to Solana are truly decentralized cross-chain assets that do not rely on a single point of failure.
There’s a lot of excitement around high-performance DeFi use cases on Solana and Serum, and many teams have started working on building decentralized and trustless bridges to bring assets and liquidity to Solana and Serum— including us!
Wormhole is the first of many such cross-chain bridges to come. It uses decentralized cross-chain oracles — called guardians — operated by a set of node operators that include top Solana validators and other ecosystem stakeholders whose incentives are strongly aligned with Solana and Serum.
Those guardians certify token lockups and burns on one chain in order to mint new tokens or release tokens on the other, and vice versa.
Watch it in action in a testing environment:
How does Wormhole work?
Wormhole is not a blockchain network — it doesn’t have to, instead, it can safely rely on consensus and finalization of the chains that it bridges.
It is leaderless — all guardians perform the same computation upon observing an on-chain event, and sign a so-called Validator Action Approval (VAA). If a 2/3+ majority of all guardian nodes have observed and signed the same event using their individual keys, then it is automatically considered valid by all Wormhole contracts on all chains and triggers a mint/burn.
All guardians have equal weight — there’s no Wormhole staking token. PoS economics are very hard to get right, and can easily get misaligned. With Wormhole being closely coupled to Solana, we believe that a PoA network that “borrows” identities and trust from the main chain is much less likely to be subtly broken or have misaligned incentives than a separate PoS chain.
We have successfully avoided the use of bleeding edge cryptography — instead, we use a plain M/N multisig scheme using secp256k1 signatures. It’s really quite boring, and in cryptography, boring is exactly what one wants!
Consensus is established asynchronously using a gossip network. Once a VAA has been signed by a sufficient number of nodes, it is posted to the Solana chain for data availability. It is then either immediately executed, or, for VAAs to be executed on Ethereum, retrieved by the user who triggered the transaction and submitted to Ethereum — and the fee paid for — by themselves (this happens transparently when using the Wormhole wallet). The fee for Solana transactions is paid for by the requestor by paying a slightly higher rent on the account that is created when requesting a token lock or burn.
VAAs are always generated in response to an on-chain event. The only exception are guardian set changes — nodes can agree on a new guardian set by submitting a special VAA that specifies the new guardian set, which has been established by an off-chain governance mechanism.
Alternatives to a m/n multisig scheme
Fast and efficient off-chain signature aggregation is a very active field of research, and before settling with m/n multisig, we investigated a number of alternatives to see if any of them could be more efficient:
- One-Round Threshold ECDSA with Identifiable Abort by Gennaro and Goldfeder, 2020 (informally known as “the GG20 paper”). It improves upon a previous threshold ECDSA scheme by the same authors. It’s a very recent, very exciting bleeding-edge scheme that uses homomorphic encryption, zero-knowledge proofs, and verifiable secret sharing to jointly generate a single ECDSA signature using a private key split across many different key holders (a “threshold signature”). GG20 and/or its precedessor are used by THORchain, Binance Chain and others. Is is very valuable when bridging to a “dumb” chain like Bitcoin, which only support ECDSA signatures. For our use case, which has fewer such constraints, it’s unnecessarily complex, very slow, and computational complexity increases non-linearly with number of signers.
- Schnorr Threshold Signatures, first introduced by Stinson and Strobl, 2001. Schnorr signatures are cheap to verify on Ethereum and Schnorr threshold signatures are well-studied, with multiple high-quality reference implementations (here’s a good intro by Chainlink). However, a distributed key generation scheme is required both for the initial node key generation as well as for generating each joint signature’s individual nonce, and there, the situation looks pretty bleak. The most commonly used Joint-Feldman DKG scheme requires three rounds, is not provably safe for concurrent rounds and can be biased. A newer, improved schema solves the bias, but at the expense of even more rounds. The bias wasn’t necessarily a deal-breaker, but implementation complexity and latency of interactive nonce generation made us drop this, too.
- FROST: Flexible Round-Optimized Schnorr Threshold Signatures by Komlo, 2020. FROST was invented by ZCash and improves upon existing Schnorr threshold signature schemes by optimizing the number of rounds required to produce a single signature. This is early stage research and no implementation or audit exists as of now — but we’ll keep an eye on it.
- BLS threshold signatures on a BN256 curve. It’s very cheap to generate and verify threshold and aggregate signatures using BLS, and the signing process is non-interactive. However, threshold BLS signatures still require an interactive distributed key generation step to initially generate the node keys, which needs to occur each time the guardian set changes. This is subject to the limitations discussed above — JF-DKG can be biased, New-DKG is even more complex, and we’d have to handle abort scenarios and other incentivization issues. Plus, we’re uneasy about the recent attacks on BN256 that downgraded its security to 100bit.
- BLS aggregate signatures on BN256 are much easier — you don’t have to generate a joint key, instead, one can literally just sum up all individual signatures. But, the signature is very expensive to verify on ETH since the public keys of all nodes have to be loaded in the contract.
The most promising choice beyond m/n signatures are BLS threshold signatures. The main concern with BLS threshold signatures can be solved by implementing New-DKG, which would be feasible to do for future iterations of Wormhole. BLS threshold signatures are cheaper than m/n signatures for guardian sets with more than 15 members.
The main design constraint of Wormhole are indeed fees on Ethereum — gas prices in the 100–200 Gwei range are considered cheap these days, with prices occassionally spiking above 500 Gwei!
There’s more to it than we could fit into this post. You can find a full specification of Wormhole and its contracts in the GitHub repo:
What’s the schedule for Wormhole to go live?
Wormhole is mostly feature-complete and is scheduled to undergo an in-depth security audit by the smart contract and cryptography experts at Kudelski, a basic precaution for such a critical piece of infrastructure.
Some of the changes needed in Solana to support Wormhole, like batch signature verification, are still in flight at the time of writing. Once these PRs have landed and backported to production branches, Wormhole is ready to be deployed, first to the TdS testnet, and later mainnet.
In the meantime, watch the video above, and if you’re a developer or otherwise interested in the inner workings, please check out the GitHub repository which includes a fully-functional local devnet you can play with:
Why is Certus One building this?
Certus One is an early Proof of Stake validation company. We have no investors and rely on your support and delegations — all of our revenue in reinvested into advancing the state of the art of the ecosystem.
Our work is impact-focused and we only work with a select few projects that we believe are the most likely to move the whole space forward. We dive deep into a chain’s architecture and code base, build and open source custom tooling, and engage with and otherwise support the validator community.
The current focus of Certus One beyond Wormhole is development of our SignOS blockchain key manager and k8s cluster operating system, with the goal of commoditizing high-quality blockchain operations — if we want true decentralization, we need everyone to be able to run a stable and secure validator, not just those who can afford a top-tier operations team.
