Chainswap Solana Initiative
ERC20 -- SPL token bridge live soon!
(Working with Wormhole on this)
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.
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!
Last modified 2yr ago