This will make is easier to separate modules and solitaire in the future.
We also get rid of the old bridge code.
Change-Id: I4d663c36739dfec77cd5d3f1ed6b51f422fe0c91
Derive message accounts from nonce and data vs sequence because sequence can lead to collision with parallel tx submission
Change-Id: I82d5b3a3c7fd96b5a6c74933c773a32e1c58bdd4
The first transaction acquires a pseudo-lock by setting
initial_creation = true, which will fail if a signature account
already exists. However, this is unsafe since the operation
consists of multiple operations and is not atomic - if the first
validator fails to submit a full set of signature transactions,
other guardians will not retry submitting signature verification txs.
We disable this mechanism to never set initial_creation, which
causes guardians to spend more fees in exchange for fault tolerance.
Instead of failing with an AlreadyExists error, duplicate transactions
will now succeed as a no-op and all nodes will attempt to submit
the full series of signature transactions.
Co-authored-by: Hendrik Hofstadt <hendrik@nexantic.com>
Change-Id: I0c418497f19cc97c9ae7a11b206035d6e70c1b66
This allows forcibly submitting a failing VAA on-chain in cases where
the preflight check would hinder debugging.
It does not change behavior of guardiand.
Co-authored-by: Hendrik Hofstadt <hendrik@nexantic.com>
Change-Id: I63df22049ad27f659dc0638190edd20628b7a338
Seeds currently did not account for the requirements of PDAs not being on the curve. This change
uses the `find_program_address` method to also be able to derive "bumped seeds" from types implementing
the Seeded trait. This is now also used for account creation.
Also the way we originally planned to pass through dependencies in Peel is not compatible with the client as some
of the context is not given there. I introduced a new method named "deps" with the same "chaining mechanic" that
can provide deps that are appended to the accounts passed into the instruction.
Change-Id: I116c8a3611e54b5a7fe5285310e4bc047119d656
This commit tackles two important problems with our contract code
- use of solana-sdk - I exile the code that relies on solana-sdk's
Keypair to a new solitaire-client crate that will conveniently handle
such client-only cases from now on
- Don't use `const-generics_defaults` - latest official release of
solana does not allow for using them and I don't find it practical to
install the experimental toolchain.
Change-Id: I3319db109de4ebcce9091e0284e756ce09264985
This commit introduces an anchor-bridge-client crate with a partially
working new() call. Still needs proper handling of seeds for some of
the accounts.
Change-Id: I73bfc4b7e23c45643776ba8f13946f1f8c7c65ed
Reisen
Hendrik Hofstadt
Leo
Stan Drozd