If there's a reason they are missing, then I didn't realize :-)
Ref #29
ghstack-source-id: 9052f64e7624fb32b50a46d24f66c618476dbfc2
Pull Request resolved: https://github.com/certusone/wormhole/pull/68
Reviewer note: Does not touch any of the business logic. Avoided
renaming files whereever possible to make it easier to spot differences.
Verbatim migration, in a future CL, we could replace some of the
flag validation code with cobra features and eliminate the global vars.
Moved the dlv tool definition out of the way for the top-level wrapper.
tools/bin/cobra is a helper utility that generates boilerplate
(we slightly deviate from their default scheme by having guardiand
in a separate package, rather than stuffing everything into cmd/)
ghstack-source-id: caec9a38a69c9c5b1baa982074b3375d153718e1
Pull Request resolved: https://github.com/certusone/wormhole/pull/67
- Metrics tracked in #11.
- Timeout and retransmits covered in #21.
- Dependency injection doesn't make sense at this scale.
- `-1` on `GenerateKeyPair` means "this doesn't make sense for Ed25519,
please crash if anyone ever tried to generate RSA keys".
ghstack-source-id: 895162835186df360bcc526a5fb904b1567b5da9
Pull Request resolved: https://github.com/certusone/wormhole/pull/66
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: c756381b1b1598305ae6d59b2967ca7ea35aa68f
Pull Request resolved: https://github.com/certusone/wormhole/pull/64
This increases modularity in preparation for integration testing
and addition of a CLI command hierarchy.
ghstack-source-id: 9c9437323610d3d3a4745b04928eb9fdb6566963
Pull Request resolved: https://github.com/certusone/wormhole/pull/63
Final missing piece of the aggregation mechanism - signatures are now
verified before storing them in the aggregation.
ghstack-source-id: 3bb57c488623454370ad1bf2a38e1278c65ce9e0
Pull Request resolved: https://github.com/certusone/wormhole/pull/59
The .run folder is a new IntelliJ feature to allow for run configuration
sharing without having to check in .idea.
ghstack-source-id: a1d6f70adcd363e70c399573165435a2ed6e783b
Pull Request resolved: https://github.com/certusone/wormhole/pull/57
VAAs are deduplicated by the on-chain contracts. For Ethereum,
submission happens outside of the bridge anyway, and for Solana, the
first tx to be confirmed wins. Subsequent attempts to submit it
will fail in preflight, so the fee won't be spent multiple times.
This eliminates the need for leader selection and fixes#20.
ghstack-source-id: 60388d532c
Pull Request resolved: https://github.com/certusone/wormhole/pull/51
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
This allows us to distinguish between temporary and permanent failure.
Unless we check the instruction error that occured, we can't know
whether the submission error is a permanent failure and Internal
is therefore the appropriate code to use.
ghstack-source-id: aff1de9516
Pull Request resolved: https://github.com/certusone/wormhole/pull/47
This removes the special case in the processor. The initial guardian set
is now treated like a regular guardian set update, and the devnet
update check is executed on every update.
Fixes an edge case where processing a guardian set update would fail
with a spurious `abi: attempting to unmarshall an empty string while arguments are expected`
error, leaving the node in a bad state since restarting ethwatch
wouldn't cause the guardian set to be re-fetched.
ghstack-source-id: e580a65e90
Pull Request resolved: https://github.com/certusone/wormhole/pull/46
Any error that can be recovered by restarting a runnable
can also be recovered from by restarting the entire process.
If we encounter a panic, it's safer to restart the process than
attempting to limp along by restarting the runnable.
We always assume that an external process manager will restart
our process if it crashes. We already rely on this behavior for
libp2p errors which we handle by terminating the process, since libp2p
maintains global state that we can't clear.
ghstack-source-id: 2f20ef764d
Pull Request resolved: https://github.com/certusone/wormhole/pull/45
Optional support for in-place debugging using an external
IDE debugger. Disabled by default.
The dlv binary is always compiled in the Dockerfile -
this is cheap due to it only depending on go.mod.
ghstack-source-id: 58532e3017
Pull Request resolved: https://github.com/certusone/wormhole/pull/44
...except for libp2p, which broke compatibility
between go-libp2p and go-libp2p-core:
https://github.com/libp2p/go-libp2p-core/issues/168
I explicitly updated all transitive dependencies using
go get -u ./..., so the top-level go.mod file grew to include those.
Wormhole is not trustless according to the commonly
accepted definition of the word. Wormhole itself is trusted,
unlike approaches like NEAR's Rainbow Bridge, which represent
a different set of tradeoffs.
This allows multiple guardians to submit the signatures in parallel without causing costs with all transactions because conflicting txs won't be mined.
Leo
Hendrik Hofstadt
Hendrik Hofstadt
Leopold Schabel