When we fail to handle an observation in a batch, include the transfer
key as part of the error context so that it's easier to figure out which
observation caused the error.
Add a query for guardians to check if there are any pending transfers
with missing observations. The guardians can use this information to
trigger re-observations of those transactions.
This field doesn't actually appear in `GuardianSetUpgrade` governance
messages and was already being skipped by serde so just remove it
completely. Contracts that need to keep track of this information can
encapsulate the `GuardianSetInfo` inside another struct that has an
`expiration_time` field.
Ensure that converting `Chain` to/from a u16 or to/from a string is
always isomorphic. This requires changing the `FromStr` impl so that in
can handle strings like "Unknown(27)".
Now that we're keeping track of transfer digests, initializing any on-
chain state through the `InstantiateMsg` doesn't make a lot of sense:
any state initialized this way is unverified and this message doesn't
contain enough information to generate the transfer digests.
Rather than trying to add in the necessary fields, just drop the message
completely since it won't be used in production. It's currently only
used to initialize on-chain state for tests but the same thing can be
accomplished through the `ModifyBalance` and `SubmitVAAs` methods.
Keep track of the digests of committed transfers so that they can be
used later when handling duplicate observations / VAAs. When processing
an observation or VAA with the same (chain, address, sequence) tuple as
a committed transfer, return a "message already processed" error when
the digests match and a "digest mismatch" error when they don't. The
latter implies a very serious issue because transfer details shouldn't
change once they have been observed by a quorum of guardians.
Add a test to ensure that calculating the digest from the structured
body, serialized data, or partial body + serialized payload all give the
same result.
Now that the accounting contract can handle chain registrations on
its own, there's no need to query the tokenbridge contract. Remove
references to it from `InstantiateMsg` and the internal state.
Add support for handling chain registration VAAs for the tokenbridge
contract. This will let us deploy accounting without also having to
deploy the tokenbridge.
Add the `Body::with_payload` method, which can be used to change the
type of the payload for a `Body`. This is useful when parsing the
payload needs to be deferred until after the body is parsed.
The tokenbridge chain registration query returns a
`ChainRegistrationResponse` struct and not a `Vec<u8>`. Use the proper
return type when sending the query.
Add a mechanism to backfill missing transfer messages by submitting
signed VAAs. This will also be used to initialize the on-chain state
as there is too much data to initialize the contract via the normal
`instantiate` mechanism.
Fixes#1883, fixes#1884.
Use the `Signature` type from the core SDK to avoid unnecessary
type conversions. Cosmwasm requires its message types to implement
`JsonSchema` so also derive that impl for the `Signature` type behind a
feature flag.
This change uncovered a separate issue where the fake `WormholeKeeper`
was using regular ecdsa signatures rather than recoverable signatures
so fix the signing and verification methods to use the recoverable
signatures.