wormhole: minor formatting
This commit is contained in:
Eric Wong
parent
851947dea9
commit
ba3964b736
|
|
@ -10,4 +10,6 @@ Over the past year, Wormhole has evolved to support an ever-growing list of bloc
|
|||
|
||||
While Wormhole is a generic interoperability protocol, it is also an ecosystem and platform for developers to grow the decentralized computing space. Wormhole consists of multiple modular swap-in components that can be leveraged independently and supports a increasing number of composible applications built by numerous teams.
|
||||
|
||||
---
|
||||
|
||||
In the next section, we'll go over the major components of the Wormhole ecosystem and how they fit together to enable the cross-chain functionality required to develop xDapps.
|
||||
|
|
|
|||
|
|
@ -10,13 +10,15 @@ Wormhole is a complex ecosystem with several noteworthy components. Before we go
|
|||
|
||||
- **Ecosystem Contracts** - Contracts subject to Wormhole governance which live inside the Wormhole Ecosystem. Their job is to provide the feature suite of Wormhole to xDapp developers.
|
||||
|
||||
- **Core Contracts** - Primary ecosystem contracts. These are the contracts which the Guardians observe and which fundamentally allow for cross-chain communication.
|
||||
- **Core Contracts** - Primary ecosystem contracts. These are the contracts which the Guardians observe and which fundamentally allow for cross-chain communication.
|
||||
|
||||
- **Portal xAsset Contracts** - Contracts that allow normal tokens to be converted to xAssets and enable these xAssets to be bridged.
|
||||
- **Portal xAsset Contracts** - Contracts that allow normal tokens to be converted to xAssets and enable these xAssets to be bridged.
|
||||
|
||||
- **Relay Contracts** - _in development\*_ - Contracts that allow xDapps to send messages to a specific blockchain via the decentralized Generic Relayer network.
|
||||
- **Relay Contracts** - _in development\*_ - Contracts that allow xDapps to send messages to a specific blockchain via the decentralized Generic Relayer network.
|
||||
|
||||
- **Gas Oracle** - _in development\*_ - Oracle for recommended fair gas prices across the ecosystem.
|
||||
- **Gas Oracle** - _in development\*_ - Oracle for recommended fair gas prices across the ecosystem.
|
||||
|
||||
- **Worm Router Contracts** - _in development\*_ - Contracts that allow developers to make their Dapp an xDapp that users on any Wormhole supported chain can interac with purely through clientside code.
|
||||
|
||||
### Off-Chain Components
|
||||
|
||||
|
|
@ -26,12 +28,16 @@ Wormhole is a complex ecosystem with several noteworthy components. Before we go
|
|||
|
||||
- **Spy** - Validators on the Guardian Network which are not part of the Guardian set. A spy can observe and forward network traffic, which helps scale up VAA distribution.
|
||||
|
||||
- **Wormchain** - _in development\*_ - A purpose-built cosmos blockchain which aids the Guardian Network and allows for formal interaction with the Guardians.
|
||||
- **VAAs** - Verifiable Action Approvals (VAAs) are the key piece of data in the Wormhole ecosystem, containing the messages emitted by xDapps along with information such as what contract emitted the message. The VAAs are signed by the Guardians and need 13/19 signatures to be considered authentic.
|
||||
|
||||
- **Specialized Relayers** - Relayers that only handle VAAs for a specific protocol or xDapp. This allows them to execute custom logic off-chain, which can reduce gas costs and increase cross-chain compatibility. Currently, xDapp developers are responsible for developing and hosting specialized relayers.
|
||||
- **Specialized Relayers** - Relayers that only handle VAAs for a specific protocol or xDapp. They can execute custom logic off-chain, which can reduce gas costs and increase cross-chain compatibility. Currently, xDapp developers are responsible for developing and hosting specialized relayers.
|
||||
|
||||
- **Generic Relayers** - _in development\*_ - A decentralized relayer network which delivers messages that are requested on-chain via the Wormhole Relay Contract.
|
||||
|
||||
- **VAAs** - Verifiable Action Approvals (VAAs) are the key piece of data in the Wormhole ecosystem, containing the messages emitted by xDapps along with information such as what contract emitted the message. The VAAs are signed by the Guardians and need 13/19 signatures to be considered authentic.
|
||||
- **Wormchain** - _in development\*_ - A purpose-built cosmos blockchain which aids the Guardian Network and allows for formal interaction with the Guardians.
|
||||
|
||||
\*\*Features listed as _in development_ are not yet available in mainnet.
|
||||
\*Features listed as _in development_ are not yet available in mainnet.
|
||||
|
||||
---
|
||||
|
||||
In the next section, we'll go over the Core Contracts of Wormhole.
|
||||
|
|
@ -4,11 +4,11 @@ The Core Contracts are the mechanism by which all Wormhole messages are emitted.
|
|||
|
||||
The Wormhole Core Contracts are one of the most pivotal pieces of the Wormhole ecosystem. They serve as a great place to start when learning about how data flows through the ecosystem.
|
||||
|
||||
In general, Core Contracts are simple with only a few public-facing functions, which we'll define next.
|
||||
In general, Core Contracts are simple and can be broken down to a **sending** and **receiving** side, which we'll define next.s
|
||||
|
||||
---
|
||||
### Sending
|
||||
|
||||
First, we have the 'sending' side of the Core Contract:
|
||||
Below is the foundational mechanism by which Wormhole Messages (aka Verified Action Approval, VAA) are emitted:
|
||||
|
||||
publishMessage(
|
||||
int nonce,
|
||||
|
|
@ -16,30 +16,29 @@ First, we have the 'sending' side of the Core Contract:
|
|||
int consistencyLevel
|
||||
) returns int sequenceNumber
|
||||
|
||||
This is the foundational mechanism by which Wormhole Messages are emitted. Let's break it down a bit:
|
||||
Let's break it down a bit:
|
||||
|
||||
- **payload** - The content of the emitted message and an arbitrary byte array. It may be capped to a certain maximum length due to the constraints of individual blockchains.
|
||||
|
||||
- **consistencyLevel** - The number of blocks which the Guardians should wait prior to emitting a VAA for this message. This number is usually either 1 or equal to the chain's finality period. This is a defense against transactions being orphaned.
|
||||
|
||||
- **nonce** - If multiple messages in the same transaction have the same nonce, a batch VAA will be produced alongside the individual VAAs on chains that allow them. This reduces gas costs and simplifies composeability.
|
||||
- **nonce** - If multiple messages in the same transaction have the same nonce, a batch VAA will be produced alongside the individual VAAs on chains that allow them. This reduces gas costs and simplifies composability.
|
||||
|
||||
- **sequenceNumber** - A unique index number for the message. When combined with the emitter contract address and emitter chain ID, the corresponding VAA can be retrieved from a guardian network node.
|
||||
|
||||
The implementation strategy for publishMessage differs by chain, but the general strategy consists of the Core Contract posting the emitterAddress (the contract which called publishMessage), sequenceNumber, and consistencyLevel into the blockchain logs. Once the desired consistencyLevel has elapsed, the Guardian Network will produce the requested VAAs.
|
||||
The implementation strategy for `publishMessage` differs by chain, but the general strategy consists of the Core Contract posting the emitterAddress (the contract which called publishMessage), sequenceNumber, and consistencyLevel into the blockchain logs. Once the desired consistencyLevel for non-fraudulent messages has elapsed, the Guardian Network will produce the requested VAAs.
|
||||
|
||||
Currently there are no fees to publish a message (with the exception of publishing on Solana) but this is not guaranteed to always be the case in the future.
|
||||
|
||||
---
|
||||
### Receiving
|
||||
|
||||
Next, we have the 'receiving' side of the Core Contract.
|
||||
Below is the basic mechanism by which Wormhole Messages are received.
|
||||
|
||||
parseAndVerifyVAA( byte[] VAA )
|
||||
|
||||
parseAndVerifyVM( byte[] VM )
|
||||
|
||||
When passed a VAA, this function will either return the payload and associated metadata for the VAA or throw an exception. An exception should only ever throw if the VAA fails signature verification, indicating the VAA is invalid or inauthentic in some form.
|
||||
|
||||
---
|
||||
|
||||
## Multicasting
|
||||
|
||||
Let's take a moment to point out that there is no destination address or chain in these functions.
|
||||
|
|
@ -48,8 +47,10 @@ VAAs simply attest that "this contract on this chain said this thing." Therefore
|
|||
|
||||
This multicast-by-default model is integral to the design. Having this multicast capacity makes it easy to synchronize state across the entire ecosystem, because a single blockchain can make its data available to every chain in a single action with low latency. This reduces the complexity of the n^2 problems encountered by routing data to a large number of blockchains.
|
||||
|
||||
Use cases where the message has an intended recipient or is only meant to be consumed a single time must be handled in logic outside the Core Contract. There are standard practices for accomplishing these features later on in the code examples, and some ecosystem contracts (namely Portal & the Relaying contract) handle this on behalf of downstream consumers.
|
||||
Use cases where the message has an intended recipient or is only meant to be consumed a single time must be handled in logic outside the Core Contract. There are standard practices for accomplishing these features later on in the code examples, and some ecosystem contracts (namely Portal & the Relaying contract) handle this on behalf of downstream consumers.
|
||||
|
||||
Lastly, because the VAA creation is separate from relaying, there is _no additional cost_ to the multicast model when a single chain is being targetted. If the data isn't needed on a certain blockchain, don't relay it there, and it won't cost anything.
|
||||
|
||||
---
|
||||
|
||||
In our next section, we'll dive into the technical specfications of the VAA.
|
||||
|
|
|
|||
|
|
@ -23,11 +23,11 @@ The Header is used by the Core Contract to determine the authenticity of the VAA
|
|||
u8 consistency_level (How many blocks were waited before emitting this VAA)
|
||||
[]byte payload (VAA message content)
|
||||
|
||||
The Body is the relevant information for consumers and is handed back from parseAndVerifyVAA. Because the emitterAddress is included as part of the Body, the developer is able to tell if this VAA originated from a trusted contract.
|
||||
The Body is the relevant information for consumers and is handed back from `parseAndVerifyVM`. Because the emitterAddress is included as part of the Body, the developer is able to tell if this VAA originated from a trusted contract.
|
||||
|
||||
VAAs are uniquely indexed by their emitterChain, emittedAddress and sequence. They can be obtained by querying a node in the Guardian Network with this information.
|
||||
|
||||
Because baseline VAAs have no destination, they are effectively multicast. They will be verified as authentic by any Core Contract on any chain in the network, and it is entirely the responsibility of relayers to deliver VAAs to the appropriate place.
|
||||
Because baseline VAAs have no destination, they are effectively multicast. They will be verified as authentic by any Core Contract on any chain in the network -- the responsibility to deliver VAAs to the appropriate place is entirely that of relayers.
|
||||
|
||||
## Batch VAAs
|
||||
|
||||
|
|
|
|||
Loading…
Reference in New Issue