* deps: Remove Go-Spew and add new debugging function for VAAs
- Removes go-spew (https://github.com/davecgh/go-spew) as it has not
been updated in 7 years.
- Replaces the Go Spew functionality with a new function
DebugString() that can be used to get a spew-like output.
* Mezo mainnet deployment
- Provides .env.mezo.mainnet used for deploying WH Core and Token Bridge
contracts to Mezo Mainnet
* Add Mezo mainnet values to node and SDK
Adds support for Mezo on mainnet.
Core contract here
Token bridge contract here
To enable Mezo on mainnet, use the following config parameters:
```
--mezoRPC YOUR_MEZO_RPC
--mezoContract 0xaBf89de706B583424328B54dD05a8fC986750Da8
```
Verification
~~~
|- go run verify.go --chainId 50
Verifying prod mezo...
Verifying EVM chain ID for prod mezo ✓
Verifying finality values for prod mezo ✓
Verifying contract address for prod mezo ✓
Verifying test mezo...
Verifying EVM chain ID for test mezo ✓
Verifying finality values for test mezo ✓
Verifying contract address for test mezo ✓
~~~
* Update mainnet_tokens_test.go
SeiEVM -> Mezo in comment
---------
Co-authored-by: Adam <20446095+aadam-10@users.noreply.github.com>
* deps: Remove miguelmota/go-ethereum-hdwallet; delete unused code
- Remove the pkg/devnet/constants.go file which was largely unused. Most
of this code has also not been updated in a long time, and it refers
to both Ganache and Truffle where we now use Foundry for testing.
- Move the "Ganache" constant to the new devnet constants file under
SDK
- Delete the rest of the unused code
- Ran `go mod tidy` and committed the results, which removed one direct
dependency and a couple of indirect ones
* change format of new SDK constant
- Updates SDK function and unit tests to return false for the empty
case. This is to prevent the function returning true trivially for
empty arguments. Either true or false may be 'correct', but returning
false is less likely to lead to failing open if empty arguments are
passed by mistake.
- Adds a comment warning that VerifySignatures is the wrong function to
use when actually validating a VAA. (This is a bug that has occurred
before but was caught in internal review.)
- Modifies a unit test case that was calling VerifySignatures twice per
run.
* ci: Bump golang linter version
* Fix initial set of lints
* Fixing more lints
* Fix more lints
* More linting updates
* More linting
* Almost there with the lints
* Last set of lints before rebase
* New lints with rebase
* PR feedback + fix test
* Update error string in algorand watcher
* Comments for watchers, revert adminserver change, remove unnecessary line in script
* Fix new lints from rebase
* Rebase fix
* Updating lints for Solana shim
* PR feedback
- Create a TxVerifier instance in the Run function of the EVM watcher
- Wrap all instances where a message would be published to the broadcasting msg channel with a new function, verifyAndPublish
- Messages are published with a new status: VerificationState.
- Modified the Transfer Verifier pkg API so that we can call the method with either an existing Receipt or a txHash.
- Added unit test in the watcher for new functionality
If Transfer Verifier is enabled:
- Messages that are token transfers will undergo Transfer Verification
- Message will be published with a status of Valid or Rejected depending on the result
- The calling code can then decide what to do based on this status
If Transfer Verifier is not enabled
- Existing behaviour will be preserved, but messages will be published with a status of NotVerified. No further actions are taken when a Message Publication has this status
Design Considerations
Modifying MessagePublication
This PR modifies MessagePublication to add a new status based on whether the Message Publication is verified. This decision was made to handle Transfer Verification cases across many chains. For example, the EVM logs are reliable enough that we can confidently rule a message as Valid or Rejected. Other ecosystems (i.e. Sui, but perhaps also Solana, etc.) are not so clear cut. In this case, we may want to mark a transaction as Anomalous rather than outright rejecting it.
Using this new enum allow us to do this.
Other potential benefits:
- Decouples the Verification of a Message from whether or not this can be published.
- Avoids scope-creep for the Watchers: they only watch messages, but do not need to reject them. (Instead this could be handled by the processor or some other security mechanism akin to the Governor or Accountant.)
- Allows configuring targeted action on a per-chain and per-status basis. For example, we may want to delay Anomalous messages but drop Rejected ones.
- Preserves a NotApplicable state that can be used as a fallback mechanism if the Transfer Verifier is disabled outright or on a particular chain
This status could be used in other cases beyond Transfer Verification, but should not interfere with existing message handling.
John Saigle
Hernán Di Pietro
Aaron Clark
Fernando Garcia
Jason Matthyser
Evan Gray
Maxwell "ꓘ" Dulin
bruce-riley
A5 Pickle
Dirk Brink
kev1n-peters
Joel Smith
Bruce Riley
cs
Artur Sapek
André Claro