CPI part is untested.
Commitment level is hardcoded to "finalized", but can be refactored
to use both "committed" and "finalized" later.
certusone/wormhole#248
Change-Id: I5ae7711c306b33650367e6f7a417ab9d88753612
This allows requesting attestations for various commitment/confirmation levels. This is helpful for low-latency applications like Pyth.
Change-Id: Ib49ace163365106b227613d2f66b787b3e5f5461
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
* upgrade solana sdk version
Commitment levels were deprecated and the fastest confirmation level is `Processed`.
Also the upgradeable loader now requires the program to be writeable.
* Add deprecation comment
* update agent commitment level
This mitigates https://github.com/solana-labs/solana/issues/9909 by
polling GetProgramAccounts with a server-side filter. It also removes
the agent dependency for the lockup observation logic - the agent is now
used for transaction construction only.
This allows us to use UNIX filesystem permissions for access control.
Previously, any process in the network namespace could connect to it,
which is insecure for obvious reasons.
Verified that correct permissions are set:
```
# ls -lisa /run/bridge/
total 8
31996269 4 drwxrwxrwx 2 root root 4096 Nov 23 21:58 .
14676759 4 drwxr-xr-x 1 root root 4096 Nov 23 21:58 ..
31996306 0 srwx------ 1 root root 0 Nov 23 21:58 agent.sock
```
Fixes#119
Supervisor does not back off tasks that failed in a healthy state.
There are a couple places where we rely on supervisor for
application-level backoff, so we always want back-off. The distinction
is meant to enable runnables to implement their own specific back-off
logic, which we don't, so we can safely ignore it.
Fixes#37
ghstack-source-id: c756381b1b
Pull Request resolved: https://github.com/certusone/wormhole/pull/64
In particular, this fixes a race condition where the Solana devnet would
take longer to deploy than the ETH devnet to deploy and we'd end up
with an outdated guardian set on Solana.
We currently create a Goroutine for every pending resubmission, which
waits and blocks on the channel until solwatch is processing requests
again. This is effectively an unbounded queue. An alternative approach
would be a channel with sufficient capacity plus backoff.
Test Plan: Deployed without solana-devnet, waited for initial guardian
set change VAA to be requeued, then deployed solana-devnet.
The VAA was successfully submitted once the transient error resolved:
```
[...]
21:08:44.712Z ERROR wormhole-guardian-0.supervisor Runnable died {"dn": "root.solwatch", "error": "returned error when NODE_STATE_HEALTHY: failed to receive message from agent: EOF"}
21:08:44.712Z INFO wormhole-guardian-0.supervisor rescheduling supervised node {"dn": "root.solwatch", "backoff": 0.737286432}
21:08:45.451Z INFO wormhole-guardian-0.root.solwatch watching for on-chain events
21:08:50.031Z ERROR wormhole-guardian-0.root.solwatch failed to submit VAA {"error": "rpc error: code = Canceled desc = stream terminated by RST_STREAM with error code: CANCEL", "digest": "79[...]"}
21:08:50.031Z ERROR wormhole-guardian-0.root.solwatch requeuing VAA {"error": "rpc error: code = Canceled desc = stream terminated by RST_STREAM with error code: CANCEL", "digest": "79[...]"}
21:09:02.062Z INFO wormhole-guardian-0.root.solwatch submitted VAA {"tx_sig": "4EKmH[...]", "digest": "79[...]"}
```
ghstack-source-id: 1b1d05a4cb
Pull Request resolved: https://github.com/certusone/wormhole/pull/48
Leo
Hendrik Hofstadt
Hendrik Hofstadt