In order to allow Wormhole to be extended and new message types to be handled we allow external contracts and programs to verify VAAs and implement their own handler logic.
In order to allow this design the following functionality is required:
Reserved VAA Action ID 0x20 with the following body as EE-VAA (External Entity VAA)
uint8 emitter_chain_id // Chain the event was emitted on
[32]uint8 emitter_address // Address of the event emitter
[]uint8 data
All Wormhole contracts need an externally callable function that allows to verify external entity VAAs. The signatures for this function will be parseAndVerifyVAA(vaa bytes) -> (valid bool, emitter_chain_id uint8, emitter_address [32]byte, timestamp uint32, hash [32]byte, data []byte)
Wormhole contracts need to ignore 0x20 VAAs that are posted to them.
Wormhole contracts need a method to emit EE-VAAs emitEEVAA(data []byte).
The guardian software needs to handle calls to emitEEVAA and subsequently produce the EE-VAA in a deterministic manner.
This design allows multiple third party contracts to handle VAAs themselves. Since the core Wormhole contract does not track VAA hashes, they can be replayed to many different recipients/handlers which need to individually implement their own replay prevention mechanism (preferably using the hash).
It also allows anyone to trigger the creation of an EE-VAA by calling the method/instruction on the contract (either directly or via CPI).
Depending on the chain, the Wormhole contract might require a payment for a successful call to emitEEVAA to prevent spam.
E.g. an oracle contract on Solana could request the an EE-VAA. The said contract will be the emitter and attach pricing data to the body.
Lending protocols on any chain could then have relayers provide this VAA to them and handle the price update by verifying the validity and emitter of the VAA using the respective Wormhole contract.
leoluk
commented
3 years ago
In order to allow Wormhole to be extended and new message types to be handled we allow external contracts and programs to verify VAAs and implement their own handler logic.
In order to allow this design the following functionality is required:
0x20with the following body as EE-VAA (External Entity VAA)parseAndVerifyVAA(vaa bytes) -> (valid bool, emitter_chain_id uint8, emitter_address [32]byte, timestamp uint32, hash [32]byte, data []byte)0x20VAAs that are posted to them.emitEEVAA(data []byte).emitEEVAAand subsequently produce the EE-VAA in a deterministic manner.This design allows multiple third party contracts to handle VAAs themselves. Since the core Wormhole contract does not track VAA hashes, they can be replayed to many different recipients/handlers which need to individually implement their own replay prevention mechanism (preferably using the hash).
It also allows anyone to trigger the creation of an EE-VAA by calling the method/instruction on the contract (either directly or via CPI). Depending on the chain, the Wormhole contract might require a payment for a successful call to
emitEEVAAto prevent spam.E.g. an oracle contract on Solana could request the an EE-VAA. The said contract will be the emitter and attach pricing data to the body. Lending protocols on any chain could then have relayers provide this VAA to them and handle the price update by verifying the validity and emitter of the VAA using the respective Wormhole contract.