new changes
This commit is contained in:
Madhav Goyal
parent
58d4cfd91d
commit
29ab773b46
|
|
@ -17,6 +17,6 @@
|
|||
"repelStrength": 10,
|
||||
"linkStrength": 1,
|
||||
"linkDistance": 250,
|
||||
"scale": 0.6493400927534805,
|
||||
"scale": 1.4575693367925815,
|
||||
"close": true
|
||||
}
|
||||
|
|
@ -11,20 +11,32 @@
|
|||
"id": "604b0d9743956ba9",
|
||||
"type": "leaf",
|
||||
"state": {
|
||||
"type": "markdown",
|
||||
"state": {
|
||||
"file": "src/dapps/3_xdataxassets.md",
|
||||
"mode": "source",
|
||||
"source": false
|
||||
}
|
||||
"type": "graph",
|
||||
"state": {}
|
||||
}
|
||||
},
|
||||
{
|
||||
"id": "aa41487bb3a3fd31",
|
||||
"type": "leaf",
|
||||
"state": {
|
||||
"type": "graph",
|
||||
"state": {}
|
||||
"type": "markdown",
|
||||
"state": {
|
||||
"file": "src/development/messages/receiving/overview.md",
|
||||
"mode": "source",
|
||||
"source": false
|
||||
}
|
||||
}
|
||||
},
|
||||
{
|
||||
"id": "ba4c7ef0ed51fb68",
|
||||
"type": "leaf",
|
||||
"state": {
|
||||
"type": "markdown",
|
||||
"state": {
|
||||
"file": "src/development/messages/registration/overview.md",
|
||||
"mode": "source",
|
||||
"source": false
|
||||
}
|
||||
}
|
||||
},
|
||||
{
|
||||
|
|
@ -35,7 +47,8 @@
|
|||
"state": {}
|
||||
}
|
||||
}
|
||||
]
|
||||
],
|
||||
"currentTab": 2
|
||||
}
|
||||
],
|
||||
"direction": "vertical"
|
||||
|
|
@ -101,7 +114,7 @@
|
|||
"state": {
|
||||
"type": "backlink",
|
||||
"state": {
|
||||
"file": "src/dapps/3_xdataxassets.md",
|
||||
"file": "src/development/messages/registration/overview.md",
|
||||
"collapseAll": false,
|
||||
"extraContext": false,
|
||||
"sortOrder": "alphabetical",
|
||||
|
|
@ -118,7 +131,7 @@
|
|||
"state": {
|
||||
"type": "outgoing-link",
|
||||
"state": {
|
||||
"file": "src/dapps/3_xdataxassets.md",
|
||||
"file": "src/development/messages/registration/overview.md",
|
||||
"linksCollapsed": false,
|
||||
"unlinkedCollapsed": true
|
||||
}
|
||||
|
|
@ -141,7 +154,7 @@
|
|||
"state": {
|
||||
"type": "outline",
|
||||
"state": {
|
||||
"file": "src/dapps/3_xdataxassets.md"
|
||||
"file": "src/development/messages/registration/overview.md"
|
||||
}
|
||||
}
|
||||
}
|
||||
|
|
@ -162,21 +175,39 @@
|
|||
"command-palette:Open command palette": false
|
||||
}
|
||||
},
|
||||
"active": "604b0d9743956ba9",
|
||||
"active": "ba4c7ef0ed51fb68",
|
||||
"lastOpenFiles": [
|
||||
"src/development/messages/registration/evm.md",
|
||||
"src/development/messages/receiving/overview.md",
|
||||
"Screenshot 2023-06-12 at 12.39.16 AM.png",
|
||||
"src/development/messages/receiving/evm.md",
|
||||
"src/dapps/3_xdataxassets.md",
|
||||
"src/dapps/4_whatIsanXdapp.md",
|
||||
"Pasted image 20230611142509.png",
|
||||
"src/dapps/2_crossChainInteroperability.md",
|
||||
"src/dapps/1_defiBasics.md",
|
||||
"src/dapps/0_xdappOverview.md",
|
||||
"src/dapps/xDex/stablecoinHighway.md",
|
||||
"src/dapps/5_advantages.md",
|
||||
"src/dapps/xDex/remoteStaking.md",
|
||||
"src/dapps/xDex/designOverview.md",
|
||||
"projects/evm-messenger/README.md",
|
||||
"src/technical/typescript/attestingToken.md",
|
||||
"src/technical/relayer/overview.md",
|
||||
"src/technical/solana/core.md",
|
||||
"src/technical/solana/nft.md",
|
||||
"src/technical/solana/overview.md",
|
||||
"src/technical/solana/xasset.md",
|
||||
"src/technical/relayer/genericRelayer.md",
|
||||
"SVM.md",
|
||||
"src/development/messages/receiving/SVM",
|
||||
"Untitled",
|
||||
"src/wormhole/3_coreLayerContracts.md",
|
||||
"src/wormhole/2_architectureOverview.md",
|
||||
"src/wormhole/5_guardianNetwork.md",
|
||||
"src/wormhole/4_vaa.md",
|
||||
"src/wormhole/1_whatIsWormhole.md",
|
||||
"src/wormhole/0_wormholeOverview.md",
|
||||
"README.md",
|
||||
"Pasted image 20230606142510.png",
|
||||
"src/SUMMARY.md"
|
||||
"src/dapps/1_defiBasics.md",
|
||||
"src/development/scaffold/overview.md",
|
||||
"src/dapps/xDex/remoteStaking.md",
|
||||
"src/dapps/xDex/governance.md",
|
||||
"src/dapps/xDex/simpleSwaps.md",
|
||||
"src/diagrams/images/architecture.PNG",
|
||||
"src/development/tilt/mac.md",
|
||||
"Pasted image 20230606142510.png"
|
||||
]
|
||||
}
|
||||
Binary file not shown.
|
After Width: | Height: | Size: 180 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 86 KiB |
|
|
@ -8,7 +8,7 @@ Now that we've established the idea of an xAsset, you might think they're an exc
|
|||
|
||||
xData is akin to an xAsset in that it exists in its own layer independent of any blockchain, which makes xData accessible by _all_ blockchains. The difference is that xData represents arbitrary data rather the token information represented by an xAsset.
|
||||
|
||||
Cross-chain interoperability then becomes a matter of creating, consuming and managing xData. Once blockchains have the ability to read and write data into a shared, global reservoir, application design can take on innovative new dimensions.
|
||||
Cross-chain interoperability then becomes a matter of creating, consuming and managing xData. Once blockchains have the ability to read and write data into a shared, global reservoir, application design can take on innovative new dimensions.
|
||||
|
||||
---
|
||||
|
||||
|
|
|
|||
|
|
@ -1,10 +1,11 @@
|
|||
# What is an xDapp?
|
||||
|
||||
The term **xDapp** is short for "Cross-Chain Decentralized Application". At first glance, this might give the impression that xDapps are simply Dapps that do cross-chain things. However, once you start building decentralized products designed to operate across a variety of blockchains and runtimes, it becomes clear that these applications are architected in a fundamentally different way than traditional Dapps.
|
||||
The term **xDapp** is short for "Cross-Chain Decentralized Application". At first glance, this might give the impression that xDapps are simply Dapps that do cross-chain things(eg transfers or swaps). However, once you start building decentralized products designed to operate across a variety of blockchains and runtimes, it becomes clear that these applications are architected in a fundamentally different way than traditional Dapps.
|
||||
|
||||
xDapps have the capacity to perform all the operations of traditional Dapps, but they are also able to utilize xData. xData allows xDapp developers to build from a top-down, message-passing approach, rather than the bottom-up world of Dapp development. The Wormhole Core Layer implements xData, which acts as a shared repository of data across the entire Wormhole ecosystem.
|
||||
xDapps have the capacity to perform all the operations of traditional Dapps, but they are also able to utilize xData. xData allows xDapp developers to build from a top-down, message-passing approach, rather than the bottom-up world of Dapp development which utilises the Wormhole's messaging modules. The Wormhole Core Layer implements xData, which acts as a shared repository of data across the entire Wormhole ecosystem.
|
||||
|
||||
Something we'll explore further in the upcoming xDapp Architecture chapter is the philosophy of [**Protocol-First Design**](./architecture/3_protocolDesign.md). Protocol First Design is an approach to building decentralized applications where the first order of business is to lay out your application into a series of data structures, APIs and message payloads. Once you've laid out your application into a high-level protocol, the protocol acts as an agreement to which all components must adhere. From there, the smart contracts underlying the protocol can be considered an implementation detail.
|
||||
In Layman terms Wormhole works as a Middleware that has access to data from every chain and can communicate with them allowing a user to interact with them simultaneously. ![[Pasted image 20230611142509.png]]
|
||||
|
||||
If you're familiar with web2 development, you might notice that this philosophy is analogous to microservice architecture. This is no coincidence, as similar problems should expect to be solved by similar solutions, and the Wormhole Core Layer has a number of parallels to the OSI Network Model.
|
||||
|
||||
|
|
|
|||
|
|
@ -2,9 +2,9 @@
|
|||
|
||||
Here are a few xDapp features that are making an impact across blockchain technologies:
|
||||
|
||||
- **Expanded User Base** - Rather than being limited to the users of one blockchain, any user on any blockchain in the ecosystem can interact with an xDapp with Wormhole work
|
||||
- **Expanded User Base** - Rather than being limited to the users of one blockchain, any user on any blockchain in the ecosystem can interact with an xDapp which Wormhole supports.
|
||||
|
||||
- **Unified Liquidity** - Liquidity fragmentation is a major problem in the current ecosystem. Unlike traditional tokens, xAssets can be pooled and moved anywhere.
|
||||
- **Unified Liquidity** - Liquidity fragmentation is a major problem in the current ecosystem. Unlike traditional tokens, xAssets can be pooled and moved anywhere.
|
||||
|
||||
- **Decentralization** - Cross-chain solutions today usually involve centralized exchanges or bridges. However, Wormhole has been designed to be decentralized from day one, and eventually totally trustless.
|
||||
|
||||
|
|
@ -13,6 +13,7 @@ Here are a few xDapp features that are making an impact across blockchain techno
|
|||
- **Broader Market Reach** - Because xAssets move freely through the ecosystem, they can be listed on a variety of exchanges and custodied on any blockchain.
|
||||
|
||||
- **Increased Extensibility and Composability** - xDapps can utilize anything across the ecosystem, including other xDapps, expanding upon the composability and openness of smart contracts.
|
||||
It abstracts the chain away focusing the user experience towards the dapp.
|
||||
|
||||
- **Futureproofing** - As new environments and protocols join the decentralized ecosystem, the connected nature of the Wormhole ecosystem allows existing protocols to expand and support them.
|
||||
|
||||
|
|
|
|||
|
|
@ -0,0 +1 @@
|
|||
[[src/projects/summary|summary]]
|
||||
|
|
@ -2,7 +2,7 @@
|
|||
|
||||
Receiving messages requires you (or a relayer) to submit the VAA to your application contract. This contract then calls the Core Bridge on the receiving chain to check the message signatures against the stored Guardian set signatures.
|
||||
|
||||
If those checks pass, then the application can see if it's a message that's already been processed by checking its sequence number against a store list of processed message sequence numbers.
|
||||
If those checks pass, then the application can see if it's a message that's already been processed by checking its sequence number against a store list of processed message sequence numbers. ![[Screenshot 2023-06-12 at 12.39.16 AM.png]]
|
||||
|
||||
The final optional check is to make sure that the message came from an application from the source chain that we were expecting. Usually this is our own application, and should be registered during initialization steps (see [registration](../registration/overview.md)).
|
||||
|
||||
|
|
|
|||
|
|
@ -17,3 +17,4 @@ This file parses command line args and filters calls to chain management handler
|
|||
|
||||
### xdapp.config.json
|
||||
The config file contains all the information about the network rpc nodes, accounts, and other constants used to communicate with contracts deployed to the selected chains.
|
||||
[[remoteStaking]]
|
||||
|
|
|
|||
|
|
@ -3,3 +3,5 @@
|
|||
This chapter will help you with relayer development in the Wormhole ecosystem.
|
||||
|
||||
The two broad categorizations of relayers are [Generic Relayers](./genericRelayer.md) and [Specialized Relayers](./specializedRelayers.md).
|
||||
|
||||
Relayer transfers the data or in the case of a blockhain a transaction to the selected leader or block builder for inclusion in the ledger.
|
||||
|
|
@ -0,0 +1 @@
|
|||
Solana uses Berkely packet filter as its execution environment aka Virtual Machine to execute arbitrary smart contract logic in a secure way.
|
||||
|
|
@ -7,3 +7,6 @@ The deployed contract addresses can be found on the [Contracts page](../../refer
|
|||
Solana is a rust-based programming environment. You'll likely find the [Wormhole Rust SDK](https://github.com/wormhole-foundation/wormhole/tree/main/sdk/rust) useful.
|
||||
|
||||
The Solana integration is also fully supported by the [Wormhole Typescript SDK](https://github.com/wormhole-foundation/wormhole/tree/main/sdk/js).
|
||||
|
||||
To get started on Solan devloplment you [can start here ](https://soldev.app/course)
|
||||
|
||||
|
|
|
|||
|
|
@ -0,0 +1 @@
|
|||
xAssets are
|
||||
|
|
@ -38,6 +38,8 @@ Wormhole is a complex ecosystem with several noteworthy components. Before we go
|
|||
|
||||
\*Features listed as _in development_ are not yet available.
|
||||
|
||||
**To learn more about the trust and Secruity assumpitonos of wormhol[e head to this page](https://github.com/wormhole-foundation/wormhole/blob/main/docs/assumptions.md)**
|
||||
|
||||
---
|
||||
|
||||
In the next section, we'll give an overview of how the Wormhole Guardian network creates VAAs along with a look at the key design considerations that underpin the network.
|
||||
|
|
|
|||
|
|
@ -4,9 +4,9 @@ The Guardian Network is designed to serve as Wormhole's oracle component, and th
|
|||
|
||||
To understand not just _how_ the Guardian Network works, but _why_ it works the way it does, let's first take a step back and go over the key design considerations. To become the best-in-class interoperability platform, there were five critical features Wormhole needed to have:
|
||||
|
||||
1. **Decentralization** - Control of the network needs to be distributed amongst many parties.
|
||||
2. **Modularity** - Disparate parts of the ecosystem such as the oracle, relayer, applications, etc, should be kept as separate and modular as possible so they can be designed, modified and upgraded independently.
|
||||
3. **Chain Agnosticism** - Wormhole should be able to support not only EVM, but also chains like Solana, Algorand, Cosmos, and even platforms that haven't been created yet. It also should not have any one chain as a single point of failure.
|
||||
1. **Decentralization** - Control of the network needs to be distributed amongst many parties to prevent malicious intent of one party.
|
||||
2. **Modularity** - Disparate parts of the ecosystem such as the oracle, relayer, applications, etc, should be kept as separate and modular as possible so they can be designed, modified and upgraded independently withut halting or effecting the entire entwork.
|
||||
3. **Chain Agnosticism** - Being Chain agnostic and abstracti g the chain specifity allowing users to seemlelsy itneract with the dapp is at the heart of the Omichain thesis. Wormhole should be able to support not only EVM, but also chains like Solana, Algorand, Cosmos, and even platforms that haven't been created yet. It also should not have any one chain as a single point of failure.
|
||||
4. **Scalability** - Wormhole should be able to secure a large amount of value immediately and be able to handle the large transaction volume.
|
||||
5. **Upgradeability** - As the decentralized computing ecosystem evolves, Wormhole will need to be able to change the implementation of its existing modules without breaking integrators.
|
||||
|
||||
|
|
|
|||
Loading…
Reference in New Issue