While sending tokens to another address on the same chain via wormhole
is quite inefficient, it's not strictly disallowed and we do have some
VAAs on solana that do this. Explicitly check for this case and allow
it.
There are no restrictions on native tokens sent in this way but wrapped
transfers are still subject to some checks: the wrapped account for
the token must exist and it must have a balance larger than the amount
being transferred. If either of those checks fails then that means
that the sender acquired some wrapped tokens that did not go through
the accountant and so that transfer should be blocked and require manual
intervention.
Now that we can calculate the digest of an Observation there's no need
to store the whole thing on-chain. Instead only store the observation
digest, tx_hash, and emitter chain (the tx_hash is necessary because
it's not included in the digest and the emitter chain is used for
servicing missing observation queries). When adding new observations
we can check for equality by comparing the digests and tx hashes rather
than comparing the whole object.
This should further reduce the size of the on-chain state.
When submitting observations to the accounting contract, clients sign
the entire batch once. There's no point storing this signature in the
on-chain data for each observation because it's already stored as part
of the chain's transaction history and the signature would be different
if an observation was submitted as part of a different batch (or the
same batch in a different order) even if the observation itself didn't
change.
Also, nothing actually made use of this signature data. (Yes,
technically it was returned by some queries but the usefulness of
the signature by itself is questionable without the full batch of
observations that were signed).
All we really care about is the index of the guardian anyway so use
a bitset to keep track of the indices of all the guardians that have
signed an observation. We use a u128 for the bitset out of an abundance
of caution in case the number of guardians increases in the future.
Dealing with more than 128 guardians is left as a problem for future
wormhole contributors if we ever get to that point.
When submitting a batch of observations, we don't want an observation
for an already committed transfer to fail the entire batch. This leads
to more complexity in the guardian and also delays all the legitimate
observations by at least one more block (~5 seconds).
Fix this by returning the transfer status of each observation as part
of the response data. Observations for committed transfers will get
a `TransferStatus::Committed` response without failing the tx as long
as the digest of the observation matches the digest of the committed
transfer. Digest mismatches are still an error and will fail the entire
batch.
Add a test for digest calculation that uses a hardcoded digest. The
digest for this test was calculated using the `worm` CLI to ensure
interoperability.
bruce-riley
Justin Schuldt
Evan Gray
Evan Gray
Csongor Kiss
Bruce Riley
Paul Noel
Tony Jin
A5 Pickle
Chirantan Ekbote
Kevin Peters
Conor Patrick
njkumr
Bojan Angjelkoski
Josh Siegel
Jeff Schroeder