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.
* solana/devnet_setup.sh: Build CLI instead of JITing it
This makes the registration process a few seconds faster.
* solana/Dockerfile: Don't copy devnet_setup.sh at the beginning
This is unnecessary, and inefficient, because each time the file
changes, a lot of things get rebuilt/reinstalled.
* solana/Dockerfile: cache cargo registry
this allows skipping rebuilding cargo dependencies. Small contract
changes now rebuild in 20s, down from 60s before
* Remove unnecessary debian depencies
* Rename rust-toolchain.toml to rust-toolchain (rustup in the container
didn't recognise it with .toml extension) and use in containers
instead of manually specifying rust version
* solana/Dockerfile: Use prebuilt docker image
* solana: Add docs on docker base images
* solana: Add "msg.sender" and remove fee from payload3
* solana: update payload3 instruction to include the sender account
* solana: allow sending payload 3s to program ids directly
Co-authored-by: Csongor Kiss <ckiss@jumptrading.com>
* 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>
The integration tests were previously just copied over from the
token-bridge directory and not changed at all (they still referenced the
token-bridge crate).
Clean up the files and add tests for basic functionality like sending
and receiving native + wrapped NFTs.
Refactor the solana Dockerfile so that the solana release installation
is a separate stage and have the builder stage derive from it. Add a
new "ci_tests" stage that also derives from the solana stage but runs
the integration tests instead.
Invoke the solana ci_tests stage from the Tiltfile when ci_tests are
enabled.
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
wasm-bindgen 0.2.74 generates JavaScript bindings for SystemInstruction
exported from solana-program 1.9.4. The generated JavaScript references
a non-existent function (wasm.__wbg_systeminstruction_free) that
leads to an attempted import error when importing the wasm packed for
bundler. SystemInstruction isn't used in the sdk, so we remove the non-existent
function reference as a workaround.