certusone
/
xdapp-book
mirror of https://github.com/certusone/xdapp-book.git
1
0
Fork 0
Code Issues Projects Releases Wiki Activity

Update 6_relayers.md 

Copy revised for clarity, syntax and punctuation.
This commit is contained in:
Ian Traas 2022-07-19 11:07:55 -05:00 committed by GitHub
parent 9c4cf33504
commit e9c2b37d92
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
1 changed files with 32 additions and 36 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

68
src/wormhole/6_relayers.md
View File

@ -1,69 +1,65 @@
# Relayers # Relayers
Relayers are a major part of the Wormhole Ecosystem. Where the Guardian Network is effectively the 'read' portion of interoperability, relayers are the 'write'. Relayers are a major part of the Wormhole Ecosystem. Where the Guardian Network is effectively the 'read' portion of interoperability, relayers are the 'write' portion.
The first thing of note is that unlike other interoperability protocols, Wormhole **does not have a required relaying methodology**. The definition of a _Relayer_ in the context of Wormhole is: Any process which delivers VAAs to a destination.
In most designs there is a dedicated relaying mechanism which operates inside the protocol's trust boundaries. This means that the relayer either has an adversarial relationship to the oracle, or the relayer has trust assumptions and contributes to the protocol's security model. Thus, relayers are usually a trusted party, are often also privileged, and you are forced to use the relayer model which is built into the protocol. Unlike other interoperability protocols, Wormhole **does not have a required relaying methodology**.
In most designs there is a dedicated relaying mechanism which operates inside the protocol's trust boundaries. This means that the relayer either has an adversarial relationship to the oracle, or the relayer has trust assumptions and contributes to the protocol's security model. Relayers are usually a trusted party, are often also privileged, and developers are typically forced to use the relayer model built into the protocol.
In Wormhole, relayers are neither trusted nor privileged. This means relayers **cannot jeopardize security, only liveness**. Because Wormhole is designed to have a firm trust boundary at the level of the VAA, relayers have exactly the same capabilities as any regular, untrusted blockchain user. In Wormhole, relayers are neither trusted nor privileged. This means relayers **cannot jeopardize security, only liveness**. Because Wormhole is designed to have a firm trust boundary at the level of the VAA, relayers have exactly the same capabilities as any regular, untrusted blockchain user.
From this perspective, relayers are just dumb delivery trucks which deliver VAAs to their destination, and have no capacity to potentially tamper with the delivery outcome. VAAs either get delivered, or don't, which makes relayers analagous to the off-chain 'crank turners' of traditional Dapps. From this perspective, relayers are just delivery trucks that deliver VAAs to their destination, and have no capacity to tamper with the delivery outcome. VAAs either get delivered or don't, which makes relayers analagous to the off-chain 'crank turners' of traditional Dapps.
As a result of this design, Wormhole is able to fascilitate a variety of heterogenous relaying mechanisms, and the developer is able to choose whatever best suit their needs. As a result, Wormhole is able to facilitate a variety of heterogenous relaying mechanisms, and the developer is able to choose whatever best suit their needs.
The definition of a _Relayer_ in the context of Wormhole is:
Any process which delivers VAAs to a destination
Next, we'll go over a few of the most common relaying strategies. Next, we'll go over a few of the most common relaying strategies.
## Client-side Relaying ## Client-side Relaying
Client side relaying is kind of a good tutorial case, as it's relatively straight forward.
All simple processes on Wormhole essentially boil down to a three step process: All simple processes on Wormhole essentially boil down to a three step process:
1. Perform some action on chain A. 1. Perform an action on chain A.
2. Retrieve the resulting VAA from the Guardian Network. 2. Retrieve the resulting VAA from the Guardian Network.
3. Perform some action on chain B using the VAA. 3. Perform an action on chain B using the VAA.
Considering that the first step of this process is almost always initiated from a user-facing frontend such as a webpage or a wallet, it is possible to also perform steps 2 and 3 in the frontend as well. This is referred to as 'client-side relaying', and it has two major benefits: Considering that the first step of this process is almost always initiated from a user-facing frontend like a webpage or a wallet, it is possible to also perform steps 2 and 3 in the frontend as well. This is referred to as 'client-side relaying', and it has two major benefits:
- Low cost. Users pay exactly the transaction fee for the second transaction. - Low cost. Users pay exactly the transaction fee for the second transaction.
- No backend relaying infrastructure. - No backend relaying infrastructure.
For this reason, client-side relaying can be a tempting avenue to pursue, especially if you're just interested in getting an MVP running. However, client-side relaying has two notable drawbacks: That makes client-side relaying a tempting prospect, especially if you're just interested in getting an MVP running. However, client-side relaying also has two notable drawbacks:
- Users must sign all transactions required with their own wallet - Users must sign all transactions required with their own wallet.
- Users must have funds to pay the transaction fees on every chain involved. - Users must have funds to pay the transaction fees on every chain involved.
Overall, client-side relaying is a simple solution, but can make the user experience cumbersome. Thus, it's generally not recommended if your goal is a highly-polished user experience. Overall, client-side relaying is a simple solution, but can make the user experience cumbersome. It's generally not recommended if your goal is a highly-polished user experience.
## Specialized Relayers ## Specialized Relayers
Specialized Relayers solve the UX problems of client-side relayers by adding a backend component which can handle steps 2 and 3 on behalf of the user. Specialized relayers solve the UX problems of client-side relayers by adding a backend component which can handle steps 2 and 3 on behalf of the user.
In this model, relayers either listen directly to the Guardian Network via a spy (This is called **Spy Relaying**), or will simply provide a REST endpoint to accept a VAA which should be relayed (called **REST Relaying**). Once a relayer has the VAA, it simply performs any necessary off-chain calculations, and submits the VAA to the required destination. In this model, relayers either listen directly to the Guardian Network via a spy (This is called **Spy Relaying**), or will simply provide a REST endpoint to accept a VAA which should be relayed (called **REST Relaying**). Once a relayer has the VAA, it simply performs any necessary off-chain calculations and submits the VAA to the required destination.
An important consideration when developing a specialized relayer is that the relayer is still considered untrusted. VAAs are totally public, and can be submitted by anyone, so the off-chain relayer should not do any computation which is considered "trusted". However, doing things like deterministic data transforms, waiting for gas prices to drop, or various forms of 'batching' can be very useful cost-reduction strategies which do not impact security. An important consideration when developing a specialized relayer is that the relayer is still considered untrusted. VAAs are public and can be submitted by anyone, so the off-chain relayer should not do any computation which is considered "trusted." However, doing things like deterministic data transforms, waiting for gas prices to drop, or various forms of 'batching' can be very useful cost-reduction strategies that do not impact security.
Specialized Relayers have the following advantages: Specialized Relayers have the following advantages:
- Simplify user experience - They simplify user experience
- Allow off-chain calculations to be performed in the relayer, reducing gas costs. - They allow off-chain calculations to be performed in the relayer, reducing gas costs
- Generally easy to develop - They are generally easy to develop
However, they also have a couple notable downsides However, they also have a couple notable downsides
- Adds a backend relaying component which is responsible for liveness - They add a backend relaying component which is responsible for liveness
- Complicates fee-modeling, as relayers are responsible for paying target chain fees. - They can complicate fee-modeling, as relayers are responsible for paying target chain fees.
Because relayers are responsible for liveness, they become another dependency component for the xDapp. If the relayers are all down, your application has an outage, similarly to how other dependencies such as the frontend, blockchain nodes, blockchains, third party APIs, etc, also can cause outages. Because relayers are responsible for liveness, they become another dependency component for the xDapp. If the relayers are all down, your application has an outage. This is similar to how dependencies like the frontend, blockchain nodes, blockchains, third party APIs, etc, can also cause outages.
To mitigate this, many relayers can be run in order to provide redundancy. It's also possible to design specialized relaying solutions which are entirely decentralized, such that there are a network of relayers which run based off economic incentives. However, creating a robust model for decentralized relaying is generally application-specific and somewhat complex. To mitigate this, multiple relayers can be run in order to provide redundancy. It's also possible to design specialized relaying solutions which are entirely decentralized, such that there are a network of relayers which run based off economic incentives. However, creating a robust model for decentralized relaying is generally application-specific and complex.
Due to specialized relayers being such a common solution,there is a reference implementation provided in the main Wormhole repository, which stands up the infrastructure needed to provide both a Spy and REST interface, and to interact with each blockchain in the ecosystem. If you plan to develop a specialized relayer, consider starting from the reference implementation, and add modifications as needed. Due to specialized relayers being such a common solution, there is a reference implementation provided in the main Wormhole repository which stands up the infrastructure needed to provide a Spy interface, a REST interface and the ability to interact with each blockchain in the ecosystem. If you plan to develop a specialized relayer, consider starting from the reference implementation and add modifications as needed.
# Generic Relayers # Generic Relayers
@ -71,19 +67,19 @@ _Note: this feature is not yet available in mainnet_
Because relaying is such an integral component to xDapps, Wormhole has built a protocol which allows developers to utilize a decentralized network of untrusted relayers to deliver their messages, removing the specialized relayer as an infrastructure responsibility. Because relaying is such an integral component to xDapps, Wormhole has built a protocol which allows developers to utilize a decentralized network of untrusted relayers to deliver their messages, removing the specialized relayer as an infrastructure responsibility.
In order to utilize the generic relayer network, developers must request delivery from the Wormhole Relay Ecosystem Contract, and must also implement a "receiveRelay" function in their contracts, which will be called by the relayer. Once a delivery has been requested, the VAA is guaranteed to be delivered within a certain timeframe. The specifics of this vary by blockchain and smart contract runtime. In order to utilize the generic relayer network, developers must request delivery from the Wormhole Relay Ecosystem Contract and must also implement a "receiveRelay" function in their contracts, which will be called by the relayer. Once a delivery has been requested, the VAA is guaranteed to be delivered within a certain timeframe. The specifics of this vary by blockchain and smart contract runtime.
Generic relayers have the following benefits: Generic relayers have the following benefits:
- Simplified UX - They feature simplified UX
- No relayer infrastructure requirements for the developer - There are no relayer infrastructure requirements for the developer
Along with the following potential downsides: And potential downsides:
- Require all calculations to be done on-chain - They require all calculations to be done on-chain
- Less gas efficiency - They have less gas efficiency
- May not be supported on all chains - They may not be supported on all chains
--- ---
That's the main overview of how xData is emitted, verified, and delivered across the Wormhole ecosystem. In the next section we'll discuss the Portal Ecosystem contracts, which allow xAssets to be created and moved freely around the ecosystem. In the next section, we'll discuss the Portal Ecosystem contracts that allow xAssets to be created and moved freely around the ecosystem.