Solitaire parses accounts using two traits, FromAccounts and Peel. The
FromAccounts derive macro generates a function, `FromAccounts::from()`,
which calls `Peel::peel` to construct each field in the struct:
```
let example = Example {
foo: Peel::peel(next_account_iter(accs)?),
bar: Peel::peel(next_account_iter(accs)?),
baz: Peel::peel(next_account_iter(accs)?),
...,
}
```
The FromAccounts derivation also attempts to implement Peel for the
structure itself however, which means `Example` itself is embeddable as
a field in another accounts struct. This is only used in ClaimableVAA
which is a large source of confusion and the complexity is not worth
maintaining.
This commit removes the recursion by:
1) Removing the `impl Peel` derived by FromAccounts.
2) Removes the AccountInfo iterator from Context as it is no longer needed.
3) Adds the current parsed account to Context instead, safe thanks to (2)
4) Move message out of ClaimableVAA and pass in to verify everywhere instead.
5) Removes Peel/FromAccounts from ClaimableVAA.
* Implement message posting with account reuse
Change-Id: I195f493f6816048f5f8f76e1f0f6e561fa0fe692
* Use different magic for unreliable messages
* guardiand: Ignore solana instructions with empty data
Co-authored-by: Csongor Kiss <ckiss@jumptrading.com>
Fix all the tests for the solana bridge program so that we can start
running it in CI.
Use the `solana-program-test` crate as the test framework. Previously,
running the tests required spinning up a test validator and manually
deploying the program there. Now developers can just do `cargo test-bpf`
to run the tests without needing any additional setup (beyond installing
the solana tools). This also lets us split out the tests so that they
can be run separately rather than having to run everything sequentially
in a single integration test.
Merge all the separate solana crates into a single workspace. This is
the same thing we do for terra and will make it easier to check / lint /
test all the crates together.
The type of the `ix_data` binding withing the solitaire! macro expansion
is explicitly annotated with its type, which comes from the macro's
pattern binding `$kind`. However, this type annotation is entirely
optional, since `ix_data` is passed in as an argument to `$fn`, whose
type forecs `ix_data` anyway, and rust will happily infer that from the
application. So we remove the explicit annotation which makes the entry
point macro easier to use.
commit-id:d428306c
* ethereum: p2w contract -> p2w emitter, fill in essential envs
Change-Id: I6fa9364a96738d2cc02ec829a31fedba0586d8e8
commit-id:0a56f1f8
* Add p2w-relay, a p2w-sdk integration test
commit-id:6bfab639
* p2w-sdk: Expand README
Change-Id: I17cb547d6aaddc240588923561c26d11a787df2e
commit-id:6ebd6a22
* p2w-sdk: don't build ETH contracts, only the types
Change-Id: I7cbd18328227700635d7688aa24a9671e8919fcd
commit-id:adf079f7
* p2w: configurability and sane envs
commit-id:f10fd90e
* Solitaire: Implement Option<T> support in structs
commit-id:31aa12d6
* bridge/governance.rs: Stop pestering about EMITTER_ADDRESS
commit-id:d5bd7234
* p2w-attest: price batching
This commit introduces support for multiple Pyth product/price pairs
per call. The initial maximum batch size is 5 and is enforced using a
`P2W_MAX_BATCH_SIZE` constant.
solana/pyth2wormhole/program:
* On-chain batching logic
* Batch message parsing logic
solana/pyth2wormhole/client:
* Off-chain batching logic - divides any number of symbols into
largest possible batches
* Use a multi-symbol config file instead of CLI arguments
third_party/pyth/p2w-sdk:
* Expose batch parsing logic
third_party/pyth/p2w-relay:
* Comment out target chain calls until ETH contract supports batching
* Test the batch parsing function
third_party/pyth/p2w_autoattest.py:
* Generate and use the symbol config file with pyth2wormhole-client
third_party/pyth/pyth_publisher.py:
* Add a configurable number of mock Pyth symbols
* Adjust HTTP endpoint for multiple symbols
commit-id:73787a61
* p2w-attest: mention attestation size in batch
This commit ensures that no matter the attestation format, a batch
will never contain attestations of different sizes. This guarantee
enables forward compatibility by adding new constant-size fields at
the end of a batch at all times. An older implementation will simply
not consume the remaining newer values while respecting the stated
batch member alignment.
commit-id:210da230
* pyth2wormhole-client: use fresh blockhashes, harden batch errors
This commit makes sure we don't have to deal with expired transactions
due to stale blockhashes. The problem existed with larger symbol
configs as well as on Solana mainnet. Additionally, the attestation logic
now treats transaction errors as non-critical - a failure for a batch
does not prevent attestation attempts for batches farther in the queue
commit-id:5e704f8b
This commit takes the selected Pyth Price struct account and after
serialization places them inside a PostMessage cross-program
call to Wormhole.
Change-Id: If04123705290f4749de318c0dfaa8f1d840ed349
Hendrik Hofstadt
Chirantan Ekbote
Stan Drozd
bruce-riley
Reisen
Csongor Kiss
Csongor Kiss
justinschuldt
Reisen