Closed jynnantonix closed 1 year ago
@kcsongor @hendrikhofstadt @conorpp for API review
Overall looks good, what does the block_time
mean in the VerifySignature
query?
block_time
is the value of env.block.height
. Maybe it would be better if it was renamed to block_height
?
block_height
sounds a little better. Is the idea there to verify if a VAA was valid at a given time in the past (to account for guardian set upgrades)?
The block height is used to check if the guardian set has expired. If there's a way for the native module to independently fetch the current block height while handling this query then we can remove this field completely.
The handler in the native module will have access to the Context
struct https://github.com/wormhole-foundation/cosmos-sdk/blob/9f2b91495bcea23d427170597b4136673008cb56/types/context.go#L25-L42 which in turn contains the BlockHeight
https://github.com/wormhole-foundation/cosmos-sdk/blob/9f2b91495bcea23d427170597b4136673008cb56/types/context.go#L50
This looks okay to me.
I think another approach would be to query just the guardian sets and calculate quorum and verifications locally. Reimplementing this logic is risky, but I believe we already have audited/tested implementations for it in cosmwasm from the Terra token bridge contract? Basically just import the guardian sets into that implementation then do similar checks. I'm not 100% sure if we'd ever need to extend/change this API, but if we had the guardian set information we could extend it without needing a wormchain update.
I think another approach would be to query just the guardian sets and calculate quorum and verifications locally.
I thought about this but I figured doing signature verification in wasm would be a lot slower than doing it in native code. Since we have to send a query to fetch the guardian set anyway, it seemed better to have the native module just handle everything.
I've updated the bindings in #1917 to drop the block_time
field completely since the query handler should be able to fetch the block height independently.
This was fixed by #2108
Proposed API: