3.7 KiB
Table of Contents
Inbox
TODO Bootstrap chain
The native token of the Wormhole chain is $WORM. This token is used both for staking (governance) and fees. These tokens are already minted on Solana, and they won't be available initially at the genesis of the chain. This presents a number of difficulties around bootstrapping.
At genesis, the blockchain will be set up in the following way
- The staking denom is set to the $WORM token (of which 0 exist on this chain at this moment)
- Producing blocks uses Proof of Authority (PoA) consensus (i.e. no tokens are required to produce blocks)
- Fees are set to 0
Then, the $WORM tokens can be transferred over from Solana, and staking (with delegation) can be done. At this stage, two different consensus mechanisms will be in place simultaneously: block validation and guardian set election will still use PoA, with each guardian having a singular vote. All other governance votes will reach consensus with DPoS by staking $WORM tokens.
TODO Onboarding guardians
The validators of wormhole chain are going to be the 19 guardians. We need a way to connect their existing guardian public keys with their wormhole chain addresses. We will have a registration process where a validator can register a guardian public key to their validator address. This will entail signing their wormhole address with their guardian private key, and sending that signature from their wormhole address. At this point, if the signature matches, the wormhole address becomes associated with the guardian public key.
After this, the guardian is eligible to become a validator.
Wormhole chain uses the ECDSA secp256k1 signature scheme, which is the same as what the guardian signatures use, so we could directly derive a wormhole account for them, but we choose not to do this in order to allow guardian key rotation.
priv = ... // guardian private key
addr = sdk.AccAddress(priv.PubKey().Address())
In theory it is possible to have multiple active guardian sets simultaneously (e.g. during the expiration period of the previous set). We only want one set of guardians to be able to produce blocks, so we store the latest validator set (which should typically by a pointer to the most recent guardian set). We have to be careful here, because if we update the guardian set to a new set where a superminority of guardians are not online yet, they won't be able to register themselves after the switch, since block production will come to a halt, and the chain becomes deadlocked.
Thus we must only change over block production due to a guardian set update if a supermajority of guardians in the new guardian set are already registered.
At present, Guardian Set upgrade VAAs are signed by the Guardians off-chain. This can stay off-chain for as long as needed, but should eventually be moved on-chain.
TODO Bootstraping the PoA Network
At time of writing, the Guardian Network is currently at Guardian Set 2, but will possibly be at set 3 or 4 by the time of launch.
It is likely not feasible to launch the chain with all 19 Guardians of the network hardcoded in the genesis block, as this would require the Guardians to determine their addresses off-chain, and have their information encoded in the genesis block.
As such, it is likely simpler to launch Wormhole Chain with a single validator (The guardian from Guardian Set 1), then have all the other Guardians perform real on-chain registrations for themselves, and then perform a Guardian Set upgrade directly to the current Guardian set.