Sebastián Claudio Nale
This speeds up the CI pipeline considerably.
|5 hours ago|
|.github/workflows||5 hours ago|
|ethereum||5 hours ago|
|offchain-gas-oracle||5 months ago|
|relayer_engine||2 days ago|
|scripts||5 months ago|
|sdk||2 days ago|
|.gitignore||5 days ago|
|.prettierrc||4 weeks ago|
|LICENSE||4 months ago|
|Makefile||3 weeks ago|
|README.md||4 months ago|
|WHITEPAPER.md||4 months ago|
Develop a common standard for a cross-chain relaying system that any application can interface with on-chain to enable better composability.
In the current design of Wormhole, user applications have 2 options to relay messages across chains - (1) users manually redeem messages and (2) applications build and mantain a specialized relayer network.
Both of these paradigms present shortcomings for users and integrators respectively. For users, there is an added friction in the UX in the form of an additional interaction and requirement of owning assets on both the source and destination chain to pay for gas. For integrators, specialized relayers represent another piece of infrastructure that represents additional liveness and potential legal responsiblity.
A decentralized network of generic relayers can address the shortcomings of both of the two current relaying methods by handling the cross-chain message redemption and submission on behalf of users and be a separate decentralized service that integrators can leverage.
Fundamentally, the relayer service should require no additional trust assumptions from the integrating contract's perspective. This service should merely serve as a third delivery mechanism option without changing any composing protocol's messaging. See the best practices for protocol design.
- Allow developers to send and receive cross-chain messages through on-chain entrypoints to Wormhole.
- Develop relayers that are capable of redeeming and submitting full or subset of Batch VAAs.
- Provide a composable, trustless relaying service in line with the Wormhole ecosystem.
- Design the economic incentives on how relayers should be incentivized in systems. We support a multitude of solutions to compete for the best solutions.
- Provide modularity that allows developers to specify additional off-chain computation on VAAs prior to submission on-chain.
Generic relayers consist of three components:
CoreRelayercontract lives on all chains that integrators interact with to request for a generic relayer to deliver a cross-chain message.
GasOraclecontract lives on all chains that provides an estimate to the gas costs associated with a particular cross-chain message. This is a critical function to ensure that users/applications are appropriately covering the costs that relayers face when submitting a transaction on the destination chain.
- Off-chain Relayer that listens for VAAs that it is assigned to, redeem the VAA from the Guardian Network, and submit the VAA on the destination chain.
The interface to the Generic Relayer can be found here
Local Node Tests
In the ethereum directory, run
make build then
make test to perform both Forge and local validator tests.
To run the Forge tests only, run
To run the local node (anvil) tests, run
Tilt Integration Tests
To deploy everything to Tilt, run
Bring up tilt from the
scratch/batch_vaa_integration branch found here
make tilt-test to start the off-chain relayer, and run the integration tests