wormhole-foundation / wormhole Goto Github PK

https://github.com/certusone/wormhole/blob/935411c0363861161678353057b5201c63d14a5f/bridge/cmd/guardiand/nodekeys.go#L29

• YubiHSM support?
• Option to enter mnemonic at startup using systemd-ask-password?
• Instructions on how to set up a ramfs and recover key to it.

https://github.com/certusone/wormhole/blob/7d617095e2bf00bc3be12c8e1638b773c3df484f/bridge/pkg/terra/watcher.go#L142

Every node will have a different timestamp, and fail consensus.

• We need to make sure that all external dependencies we pull in are pinned to exact version such that it doesn't randomly start failing or become compromised.
• If it's easy to do, builds should be byte-by-byte reproducible.

There's nothing in the spec preventing this - test this.

https://github.com/certusone/wormhole/blob/c370a94911c3b06237fd5e92837739ff2f98d191/bridge/cmd/guardiand/processor.go#L202-L203

• Once a VAA has been pending for a certain time, retransmit our signature to help it reach consensus.
• Clean up old vaaState entries after a given timeout if we failed to reach consensus.

Blocked by:

• #12

The various pieces of guardiand are decoupled such that they can be individually tested.

returned error when NODE_STATE_NEW: panic: hash is required to be exactly 32 bytes (31)

Full log w/ stacktrace: https://gist.github.com/leoluk/17ee8ca1b742bb6994a11790876f798d

https://github.com/certusone/wormhole/blob/9bb44eb0f56bb15a5edfa46c8925a2e01bb5bc75/bridge/cmd/guardiand/ethwatch.go#L136

As part of our test suite, we need to test with very high tx rates on Solana.

All ERC20 tokens are currently called WWT, which might confuse the heck out of block explorers, wallets, and users.

The reason for this is that SPL tokens do not have names on-chain, but we can do the next best thing and include the truncated SPL token address to make them easier to distinguish.

• Lack of game theoretical incentivization
• ...

Need to include decimals field in VAA? (we need to know for the WrappedAsset)

A guardian set update with 20 guardians exceeds transaction size limits, effectively limiting the set to 19.

Either update docs, or figure out how to mitigate it.

• List pending VAAs
• List active gossip talkers (via heartbeat)

Requires #27

https://github.com/certusone/wormhole/blob/b663e2dc560d30c0823d24bb8b3d7e756e8c66c0/bridge/cmd/guardiand/p2p.go#L80

Nodes shouldn't fail to start if the entrypoint is down.

https://github.com/certusone/wormhole/blob/b663e2dc560d30c0823d24bb8b3d7e756e8c66c0/proto/gossip/v1/gossip.proto#L21-L31

Necessary for network observability.

https://github.com/certusone/wormhole/blob/c370a94911c3b06237fd5e92837739ff2f98d191/bridge/cmd/guardiand/processor.go#L82

We'll need to charge fees for ETH relayers (gas fees).

Challenges:

• How to determine who relayed the tx (successfully)?
• How much to charge?

• #79

We currently re-submit submission lockups that met quorum each time we receive an additional signature.

This is excessive, let's be more clever about it.

This is a placeholder ticket for ERC-721 NFT wrapping support. Our team is not planning to implement this, but the project is open to contributions that add such support. If you plan to work on this, please reach out first (like by commenting on this issue or the #wormhole channel on the Solana Discord server).

Rough outline on what is needed:

• A stable and generally accepted ERC-721 equivalent on Solana.
• Wrapper contracts on Ethereum and Solana.
• A new VAA message type and implementations in the Eth and Solana contracts.
• Bridge node support for the new message type.
• Auditing the changes.

Depending on what mainnet upgrade paths will look like, it may also require a separate bridge contract on Ethereum (#13).

In order to reduce fees on Solana and reduce the storage usage of the bridge system, temporary accounts can be evicted.

Accounts that can be evicted:

• ClaimedVAA
• TransferOutProposal (Lockup)

The ClaimedVAA is created and paid for by the guardians, the TransferOutProposal is paid for by the user locking the tokens.

In order to incentivize guardians and cover their SOL costs, all "rent refunds" go to the bridge program. The balance of the bridge is used to subsidize the creation of ClaimedVAAs (to reduce the cost that guardians have to cover). If there is any excess balance on the bridge, we can consider paying it out to the guardians.

To still guarantee data-availability and prevent replay attacks, we need to make sure that the ClaimedVAA and TransferOutProposal accounts live for at least the VAA validity period.

VAAs need to stay valid while the guardian set is valid to allow users to resubmit dropped VAAs.

The Terra devnet needs some improvements to bring it up to the level of the Eth & Solana integrations:

• Remove the big ConfigMap blob from the k8s YAML and use a layered Dockerfile instead (optional, not required)
• Deterministic generation of addresses/key.
• Containerize devnet setup steps and run them automatically as a sidecar container, remove outside deps.
• Initial guardian set needs to be submitted in checkDevModeGuardianSetUpdate.
• terrad spams errors: terra-terrad │ E[2020-11-19|01:26:22.936] Failed to save AddrBook to file module=p2p book=/root/.terrad/config/addrbook.json file=/root/.terrad/config/addrbook.json err="open /root/.terrad/config/write-file-atomic-05346018749820359876: read-only file system"

Determinism and automated setup is required to run automated tests for the Terra integration.

• Native tokens locked on Solana
  • ...to Ethereum
  • ...to Solana
  • ...to Terra
  • ...to invalid chain
• Native tokens locked on Eth
  • ...to Ethereum
  • ...to Solana
  • ...to Terra
  • ...to invalid destination
• Wrapped tokens locked on Solana
  • ...to Ethereum
  • ...to Solana
  • ...to Terra
  • ...to invalid chain
• Wrapped tokens locked on Eth
  • ...to Ethereum
  • ...to Solana
  • ...to Terra
  • ...to invalid destination
• Repeated guardian set updates
  • on Ethereum
  • on Solana
  • on Terra
• Large guardian set updates
  • on Ethereum
  • on Solana
  • on Terra
• Retrying lockups after a gossip network outage
  • on Ethereum
  • on Solana
  • on Terra
• Guardian set expiration
  • on Ethereum (tested via unit test)
  • on Solana
  • on Terra (tested via unit test)
• VAAs cannot be executed twice (including across guardian set updates and in different consensus rounds)
  • on Ethereum
  • on Solana
  • on Terra
• Retrieve VAA from Solana to submit to Eth
• Dust refund
• Transaction fee refund
• Quorum on all chains
• Contract upgrades on Solana
• Guardian set updates with full subsidizer pool

A used should be able to submit their VAA from Solana to ETH.

The Terra VAA submission currently blocks the observation loop.

This needs to be refactored to submit asynchronously like Solana to avoid stalls when the terra request takes longer than expected.

https://github.com/certusone/wormhole/blob/f072e8c36af5619611292c3bd4cbe936a2c69612/bridge/pkg/processor/observation.go#L203

Anyone can talk on the p2p gossip channel and send invalid lockup observations.

• Figure out what protections libp2p provides.
• Channel pressure in guardiand at high rates.
• Inbound VAAs should only create a vaaState entries if they're valid.
• How expensive is the validation?
• Whitelist libp2p peers? We already verify those signatures anyway.

https://github.com/certusone/wormhole/blob/c370a94911c3b06237fd5e92837739ff2f98d191/bridge/cmd/guardiand/processor.go#L221

http://phab/T756 (internal SignOS task) showed up when my overnight test run crashed:

2020-08-20T22:54:23.460Z        ERROR    wormhole-guardian-1.supervisor  Runnable died   {"dn": "root.ethwatch", "error": "returned error when NODE_STATE_NEW: panic: hash is required to be exactly 32 bytes (31), stacktrace: goroutine 90 [running]:\nruntime/debug.Stack(0xc000144ab0, 0x10acc40, 0xc000227330)\n\t/usr/local/go/src/runtime/debug/stack.go:24 +0x9d\ngithub.com/certusone/wormhole/bridge/pkg/supervisor.(*supervisor).processSchedule.func1.1(0xc0005b4f80, 0xc0002d2330)\n\t/app/pkg/supervisor/supervisor_processor.go:140 +0x6e\npanic(0x10acc40, 0xc000227330)\n\t/usr/local/go/src/runtime/panic.go:969 +0x166\nmain.ethLockupProce
ssor.func1(0x15a5c80, 0xc0005b5100, 0x10c9120, 0xc0000ff380)\n\t/app/cmd/guardiand/ethwatch.go:136 +0x4d24\ngithub.com/certusone/wormhole/bridge/pkg/supervisor.(*supervisor).processSchedule.func1(0xc0005b4f80, 0xc0002d2330, 0xc00001b2d0)\n\t/app/pkg/supervisor/supervisor_processor.go:147 +0x6a\ncreated by github.com/certusone/wormhole/bridge/pkg/supervisor.(*supervisor).processSchedule\n\t/app/pkg/supervisor/supervisor_processor.go:133 +0xae\n"}                                                                                                                                                                                             2020-08-20T22:54:23.462Z        INFO     wormhole-guardian-1.supervisor  rescheduling supervised node    {"dn": "root.ethwatch", "backoff": -0.000000001}

https://github.com/certusone/wormhole/blob/e0533c70c5483a5e88fdd2bba9e12182c22d0f7b/ethereum/contracts/Wormhole.sol#L4

We'll need a delegatecall proxy in front of the Ethereum bridge to allow upgrades.
The upgrades will be implemented as VAA 0x02 - UpgradeEthereumBridge.

https://github.com/certusone/wormhole/blob/ef2aab599890b2501f2204dfbc8ff82b8d5e1d24/bridge/cmd/guardiand/main.go#L52-L53

If a user mistakenly sends tokens to an invalid chain ID, they're stuck forever.

We could be nice and send them back, either manually or automatically.

The spec says 2/3+, implementation is 2/3. Fix this and align across all components.

More of a formality due to how our consensus works.

https://github.com/certusone/wormhole/blob/b663e2dc560d30c0823d24bb8b3d7e756e8c66c0/proto/gossip/v1/gossip.proto#L21-L31

Necessary for network observability.

This is required for off-chain governance.

https://github.com/certusone/wormhole/blob/c370a94911c3b06237fd5e92837739ff2f98d191/bridge/cmd/guardiand/processor.go#L306-L308

We need at-least-once delivery of signed VAAs to the chain.

Complications:

• We need a fallback/retry mechanism if the tx fails to be published.
• The requirements state that non-guardian nodes may wish to aggregate signatures and act as fallback submitters, how will this work?