diff --git a/docs/evm/tutorial/chain/run-archive-node.md b/docs/build/chain/run-archive-node.md similarity index 100% rename from docs/evm/tutorial/chain/run-archive-node.md rename to docs/build/chain/run-archive-node.md diff --git a/docs/evm/tutorial/chain/run-collator-node.md b/docs/build/chain/run-collator-node.md similarity index 97% rename from docs/evm/tutorial/chain/run-collator-node.md rename to docs/build/chain/run-collator-node.md index 2c368fe..f51c16f 100644 --- a/docs/evm/tutorial/chain/run-collator-node.md +++ b/docs/build/chain/run-collator-node.md @@ -153,19 +153,19 @@ It's important to note that there is a faster method to expedite the syncing pro 1. Once your node has finished syncing, ensure that it is still running. 2. Open the [staking app](https://staking.darwinia.network/#/?network=darwinia) in your browser and connect it to your wallet account. You have the option to choose between MetaMask or WalletConnect, as both wallets are now supported. - ![evm-tutorial-collator-node-1](../../../images/evm-tutorial-collator-node-1.png) + ![evm-tutorial-collator-node-1](../../images/evm-tutorial-collator-node-1.png) 3. Click on the `Join Collator` button and follow these steps: 1. Enter the session key that was generated earlier and click on `Set Session Key` to prompt the wallet for submitting an Ethereum transaction. 2. Enter the desired commission amount and click on `Set Commission` to prompt the wallet for submitting an Ethereum transaction. -![evm-tutorial-collator-node-2](../../../images/evm-tutorial-collator-node-2.png) -![evm-tutorial-collator-node-3](../../../images/evm-tutorial-collator-node-3.png) +![evm-tutorial-collator-node-2](../../images/evm-tutorial-collator-node-2.png) +![evm-tutorial-collator-node-3](../../images/evm-tutorial-collator-node-3.png) 1. To verify that your account is in the collator waiting pool, click on the `Select a collator` button. - ![evm-tutorial-collator-node-4](../../../images/evm-tutorial-collator-node-4.png) - ![evm-tutorial-collator-node-5](../../../images/evm-tutorial-collator-node-5.png) + ![evm-tutorial-collator-node-4](../../images/evm-tutorial-collator-node-4.png) + ![evm-tutorial-collator-node-5](../../images/evm-tutorial-collator-node-5.png) ## To be a real collator diff --git a/docs/evm/tutorial/chain/run-dev-node.md b/docs/build/chain/run-dev-node.md similarity index 89% rename from docs/evm/tutorial/chain/run-dev-node.md rename to docs/build/chain/run-dev-node.md index 742b905..b867a3d 100644 --- a/docs/evm/tutorial/chain/run-dev-node.md +++ b/docs/build/chain/run-dev-node.md @@ -1,6 +1,6 @@ # Run Development Testnet -While there is an established test network, namely the [Pangolin network](../../chains/pangolin.md), which serves as an ideal sandbox for your applications, eliminating any concern about initiating and connecting nodes, among other things. The official test network is designed to fulfill application developers' requirements. However, there may be scenarios where you want to perform low-level tasks. In such cases, creating your own development network can significantly enhance your development, testing, or debugging efficiency. This guide will walk you through the process of establishing a single-node development network. +While there is an established test network, namely the [Pangolin network](../../learn/chains/pangolin.md), which serves as an ideal sandbox for your applications, eliminating any concern about initiating and connecting nodes, among other things. The official test network is designed to fulfill application developers' requirements. However, there may be scenarios where you want to perform low-level tasks. In such cases, creating your own development network can significantly enhance your development, testing, or debugging efficiency. This guide will walk you through the process of establishing a single-node development network. ## Compile darwinia node @@ -95,5 +95,5 @@ To start the local Substrate node: Once the node is up and producing new blocks, you can connect to the Polkadot app to explore more advanced features, such as token transfer and more. -![evm-tutorial-dev-node-1](../../../images/evm-tutorial-dev-node-1.png) -![evm-tutorial-dev-node-2](../../../images/evm-tutorial-dev-node-2.png) \ No newline at end of file +![evm-tutorial-dev-node-1](../../images/evm-tutorial-dev-node-1.png) +![evm-tutorial-dev-node-2](../../images/evm-tutorial-dev-node-2.png) \ No newline at end of file diff --git a/docs/evm/tutorial/chain/run-evm-tracing-node.md b/docs/build/chain/run-evm-tracing-node.md similarity index 100% rename from docs/evm/tutorial/chain/run-evm-tracing-node.md rename to docs/build/chain/run-evm-tracing-node.md diff --git a/docs/evm/tutorial/chain/snapshot.md b/docs/build/chain/snapshot.md similarity index 100% rename from docs/evm/tutorial/chain/snapshot.md rename to docs/build/chain/snapshot.md diff --git a/docs/evm/tutorial/create-dao.md b/docs/build/getting-started/create-dao.md similarity index 100% rename from docs/evm/tutorial/create-dao.md rename to docs/build/getting-started/create-dao.md diff --git a/docs/evm/tutorial/governance.md b/docs/build/getting-started/governance.md similarity index 100% rename from docs/evm/tutorial/governance.md rename to docs/build/getting-started/governance.md diff --git a/docs/evm/tutorial/migration/generate-account.md b/docs/build/getting-started/migration/generate-account.md similarity index 96% rename from docs/evm/tutorial/migration/generate-account.md rename to docs/build/getting-started/migration/generate-account.md index cd1db19..8cd2ae8 100644 --- a/docs/evm/tutorial/migration/generate-account.md +++ b/docs/build/getting-started/migration/generate-account.md @@ -55,7 +55,7 @@ The current version of [Subscan](https://darwinia.subscan.io/) supports Darwinia ![evm-tutorial-migrate-general-8](../../../images/evm-tutorial-migrate-general-8.png) ![evm-tutorial-migrate-general-9](../../../images/evm-tutorial-migrate-general-9.png) -Also, you can refer to [here](../../chains/darwinia.md) and add the darwinia RPC to your wallet. Then you can see the transferrable `RING` on MetaMask. +Also, you can refer to [here](../../../learn/chains/darwinia.md#network-info) and add the darwinia RPC to your wallet. Then you can see the transferrable `RING` on MetaMask. ![evm-tutorial-migrate-general-10](../../../images/evm-tutorial-migrate-general-10.png) diff --git a/docs/evm/tutorial/migration/multisig-account.md b/docs/build/getting-started/migration/multisig-account.md similarity index 100% rename from docs/evm/tutorial/migration/multisig-account.md rename to docs/build/getting-started/migration/multisig-account.md diff --git a/docs/evm/tutorial/multisig-wallet.md b/docs/build/getting-started/multisig-wallet.md similarity index 99% rename from docs/evm/tutorial/multisig-wallet.md rename to docs/build/getting-started/multisig-wallet.md index 60a6377..8faa563 100644 --- a/docs/evm/tutorial/multisig-wallet.md +++ b/docs/build/getting-started/multisig-wallet.md @@ -12,7 +12,7 @@ 1. Open [DSafe Wallet](https://multisig.darwiniacommunitydao.xyz/) 2. Switch your MetaMask to the Darwinia Chain - DSafe Wallet consists of multiple owners. To create a multi-signature wallet, you first need to connect your regular wallet using MetaMask (or any other compatible wallet). If you haven't added the Darwinia Chain before, you can add it by visiting this [link](../chains/darwinia.md). + DSafe Wallet consists of multiple owners. To create a multi-signature wallet, you first need to connect your regular wallet using MetaMask (or any other compatible wallet). If you haven't added the Darwinia Chain before, you can add it by visiting this [link](../../learn/chains/darwinia.md#network-info). 3. Click "Create new Account" to initiate the process. diff --git a/docs/evm/tutorial/staking.md b/docs/build/getting-started/staking.md similarity index 100% rename from docs/evm/tutorial/staking.md rename to docs/build/getting-started/staking.md diff --git a/docs/evm/tutorial/transfer-token.md b/docs/build/getting-started/transfer-token.md similarity index 100% rename from docs/evm/tutorial/transfer-token.md rename to docs/build/getting-started/transfer-token.md diff --git a/docs/evm/tutorial/usdt.md b/docs/build/getting-started/usdt.md similarity index 100% rename from docs/evm/tutorial/usdt.md rename to docs/build/getting-started/usdt.md diff --git a/docs/evm/tutorial/indexer/subquery.md b/docs/build/indexer/subquery.md similarity index 97% rename from docs/evm/tutorial/indexer/subquery.md rename to docs/build/indexer/subquery.md index cc1fdaf..bf79b39 100644 --- a/docs/evm/tutorial/indexer/subquery.md +++ b/docs/build/indexer/subquery.md @@ -40,7 +40,7 @@ Select the network family as **Substrate** and the network as **Darwinia**, then The output: -![evm-tutorial-indexer-subquery-1](../../../images/evm-tutorial-indexer-subquery-1.png) +![evm-tutorial-indexer-subquery-1](../../images/evm-tutorial-indexer-subquery-1.png) The `ll example-with-subquery/`is: @@ -153,7 +153,7 @@ query { The indexing result is displayed in the right pane, as shown below: -![evm-tutorial-indexer-subquery-2](../../../images/evm-tutorial-indexer-subquery-2.png) +![evm-tutorial-indexer-subquery-2](../../images/evm-tutorial-indexer-subquery-2.png) ### Stop Indexing diff --git a/docs/evm/tutorial/smart-contract/interact-with-ethersjs.md b/docs/build/smart-contract/interact-with-ethersjs.md similarity index 100% rename from docs/evm/tutorial/smart-contract/interact-with-ethersjs.md rename to docs/build/smart-contract/interact-with-ethersjs.md diff --git a/docs/evm/tutorial/smart-contract/interact-with-foundry.md b/docs/build/smart-contract/interact-with-foundry.md similarity index 100% rename from docs/evm/tutorial/smart-contract/interact-with-foundry.md rename to docs/build/smart-contract/interact-with-foundry.md diff --git a/docs/evm/tutorial/smart-contract/interact-with-hardhat.md b/docs/build/smart-contract/interact-with-hardhat.md similarity index 100% rename from docs/evm/tutorial/smart-contract/interact-with-hardhat.md rename to docs/build/smart-contract/interact-with-hardhat.md diff --git a/docs/evm/tutorial/smart-contract/interact-with-web3js.md b/docs/build/smart-contract/interact-with-web3js.md similarity index 95% rename from docs/evm/tutorial/smart-contract/interact-with-web3js.md rename to docs/build/smart-contract/interact-with-web3js.md index 85ebf23..d6e137a 100644 --- a/docs/evm/tutorial/smart-contract/interact-with-web3js.md +++ b/docs/build/smart-contract/interact-with-web3js.md @@ -3,7 +3,7 @@ !!! note Familiarity with Linux/Javascript is essential. -[Web3.js](https://web3js.org/) is a comprehensive library that enables developers to communicate with Ethereum nodes using various protocols such as HTTP or WebSocket in JavaScript. Darwinia offers an [Ethereum-Compatible API](../../ethereum-compatibility/jsonrpc.md) that supports JSON RPC calls similar to Ethereum. As a result, developers can utilize the Web3.js library to interact with a Darwinia node in the same way they would interact with an Ethereum node. This compatibility simplifies the process of building applications that interact with Darwinia using familiar Ethereum tools and libraries. +[Web3.js](https://web3js.org/) is a comprehensive library that enables developers to communicate with Ethereum nodes using various protocols such as HTTP or WebSocket in JavaScript. Darwinia offers an [Ethereum-Compatible API](../../learn/ethereum-compatibility/jsonrpc.md) that supports JSON RPC calls similar to Ethereum. As a result, developers can utilize the Web3.js library to interact with a Darwinia node in the same way they would interact with an Ethereum node. This compatibility simplifies the process of building applications that interact with Darwinia using familiar Ethereum tools and libraries. ## Prerequisites diff --git a/docs/evm/tutorial/smart-contract/verify-contract.md b/docs/build/smart-contract/verify-contract.md similarity index 74% rename from docs/evm/tutorial/smart-contract/verify-contract.md rename to docs/build/smart-contract/verify-contract.md index 2064932..a971344 100644 --- a/docs/evm/tutorial/smart-contract/verify-contract.md +++ b/docs/build/smart-contract/verify-contract.md @@ -6,8 +6,8 @@ For Darwinia chains, Subscan is the most commonly used explorer, offering contra ## Verify Contracts -1. Navigate to the appropriate [Subscan](https://www.notion.so/Crab-Chain-7d27b58cb42a4315b878281da0043aa6?pvs=21) explorer, using the Crab chain as an example. Once there, open the contract page as demonstrated in the screenshot below. +1. Navigate to the appropriate [Subscan](../../learn/chains/crab.md#network-info) explorer, using the Crab chain as an example. Once there, open the contract page as demonstrated in the screenshot below. - ![evm-tutorial-verify-contract-1](../../../images/evm-tutorial-verify-contract-1.png) + ![evm-tutorial-verify-contract-1](../../images/evm-tutorial-verify-contract-1.png) 2. Verify the contract by submitting the concrete contract information or [standard input JSON](https://github.com/subscan-explorer/sourcify/blob/feat/doc/docs/Standard-Input-JSON.md), similar to the process used on Etherscan, then click `Verify & Publish`. \ No newline at end of file diff --git a/docs/evm/ethereum-compatibility/precompiles/commitment-token.md b/docs/evm/ethereum-compatibility/precompiles/commitment-token.md deleted file mode 100644 index ed4e05d..0000000 --- a/docs/evm/ethereum-compatibility/precompiles/commitment-token.md +++ /dev/null @@ -1,11 +0,0 @@ -# Commitment Token Precompile - -Before delving into the understanding of this precompile, it's essential to have knowledge about the [Commitment Token](../../darwinia-staking/commitment-token.md), within the Darwinia ecosystem. In the architecture of Darwinia, the native token is designed to be fundamentally compatible with Ethereum. This means that the native token can be seamlessly used in Ethereum-compatible environments without requiring extensive modifications or adaptations. It provides out-of-the-box compatibility, allowing users to interact with the native token using Ethereum tools and infrastructure. However, the commitment token in the Darwinia system operates differently. It is a separate standalone token that functions within the Darwinia ecosystem. The commitment token is implemented by a pallet called the [pallet-asset](https://marketplace.substrate.io/pallets/pallet-assets/), which is part of the Substrate ecosystem. The pallet-asset facilitates the management of the commitment token, including features such as token transfers, balances, and other related operations. - -Similar to the staking and deposit precompiles, the commitment token also requires a dedicated precompile to enhance its usability for users of Ethereum tools. This precompile acts as a bridge, simplifying the interaction between Ethereum users and the commitment token. By leveraging this precompile, Ethereum users can seamlessly interact with the commitment token using their familiar Ethereum workflows and tools, such as MetaMask. - -## Contract Info - -- The default contract address: 0x0000000000000000000000000000000000000402 -- [The interface](https://github.com/darwinia-network/darwinia/blob/main/precompile/metadata/sol/asset.sol) -- [The ABI](https://github.com/darwinia-network/darwinia/blob/main/precompile/metadata/abi/asset.json) \ No newline at end of file diff --git a/docs/evm/ethereum-compatibility/precompiles/deposit.md b/docs/evm/ethereum-compatibility/precompiles/deposit.md deleted file mode 100644 index c912600..0000000 --- a/docs/evm/ethereum-compatibility/precompiles/deposit.md +++ /dev/null @@ -1,9 +0,0 @@ -# Deposit Precompile - -The [Darwinia staking solution](../../darwinia-staking/staking.md) consists of two components, including the staking pallet and the deposit pallet. Each of these pallets has its own precompile functionality, which is specifically designed to facilitate interaction for Ethereum users. In this context, we will focus on the deposit precompile. By leveraging the deposit precompile, Ethereum users can conveniently deposit their assets into the Darwinia network and participate in the staking process. - -## Contract Info - -- The default contract address: 0x0000000000000000000000000000000000000600 -- [The interface](https://github.com/darwinia-network/darwinia/blob/main/precompile/metadata/sol/deposit.sol) -- [The ABI](https://github.com/darwinia-network/darwinia/blob/main/precompile/metadata/abi/deposit.json) \ No newline at end of file diff --git a/docs/evm/glossary.md b/docs/evm/glossary.md deleted file mode 100644 index 159df6f..0000000 --- a/docs/evm/glossary.md +++ /dev/null @@ -1,62 +0,0 @@ -# Glossary - -## Block - -A collection of data, such as transactions, that together indicate a state transition of the blockchain. - -## Block Explorer - -An application that allows a user to explore the different blocks on a blockchain. - -## Collator - -A node that maintains a parachain by collecting parachain transactions and producing state transition proofs for the validators. - -## Commission - -Collators and nominators get paid from block production on the network, where collators can set a variable commission rate, which is initially subtracted from the total rewards that collator is entitled to (for that period), where the commission determines the rate of distribution for the remaining rewards set out for the nominators that are backing that collator. - -## Dapps - -A generic term for a decentralized application, that is, one that runs as part of a distributed network as opposed to being run on a specific system or set of systems. - -## Epoch - -An epoch is a time duration in the BABE protocol that is broken into smaller time slots. Each slot has at least one slot leader who has the right to propose a block. In Kusama, it is the same duration as a [session](https://www.notion.so/Glossary-8967fc4aa6a046a69b525dff7bf70a50?pvs=21). - -## Era - -A (whole) number of sessions, which is the period that the validator set (and each validator's active nominator set) is recalculated and where rewards are paid out. - -## Parachain - -A blockchain that meets several characteristics that allow it to work within the confines of the Polkadot Host. Also known as "parallelized chain.” - -## Power - -Users participate in staking, and the rights and interests obtained by bonding RING or KTON are called power. - -## Power Share - -Power share is the percentage of Power held in total Power. The greater the power share, the greater the influence of the decision made on the entire chain. - -## Preimage - -The on-chain proposals do not require the entire image of extrinsics and data (for instance the WASM code, in case of upgrades) to be submitted, but would rather just need that image's hash. That preimage can be submitted and stored on-chain against the hash later, upon the proposal's -dispatch. - -## Relay Chain - -The chain that coordinates consensus and communication between parachains (and external chains, via bridges). - -## Session - -A session is a period of time that has a constant set of validators. Validators can only join or exit the validator set at a session change. It is measured in block numbers. - -## Session key - -A session key is actually several keys kept together that provide the various signing functions required by network authorities/validators in pursuit of their duties. - -## Substrate - -A modular framework for building blockchains. Darwinia network is built with Substrate. \ No newline at end of file diff --git a/docs/evm/overview.md b/docs/evm/overview.md deleted file mode 100644 index 7384e37..0000000 --- a/docs/evm/overview.md +++ /dev/null @@ -1,3 +0,0 @@ -# Overview - -The Darwinia EVM+ is a sophisticated smart contract platform built upon Polkadot's Ethereum compatibility layer, [Frontier](https://github.com/paritytech/frontier). It provides EVM compatibility and harnesses Polkadot's robust security features. Additionally, it utilizes the powerful capabilities of [Msgport](../msgport/overview.md) to interface with all EVM-compatible chains. As a Polkadot Parachain, it inherently supports the [XCMP protocol](https://wiki.polkadot.network/docs/learn-xcm), enabling seamless messaging across different parachains within the Polkadot ecosystem. Combining these elements, the Darwinia EVM+ effectively act as a conduit, linking Polkadot parachains with the broader EVM universe. \ No newline at end of file diff --git a/docs/evm/tutorial/chain/run-relay-chain-testnet.md b/docs/evm/tutorial/chain/run-relay-chain-testnet.md deleted file mode 100644 index ab0995d..0000000 --- a/docs/evm/tutorial/chain/run-relay-chain-testnet.md +++ /dev/null @@ -1,465 +0,0 @@ -# Run Relay Chain Testnet - -The Darwinia network is built upon the vision of the Polkadot. More specifically, the Darwinia chain functions as a parachain within the Polkadot Network, while the Crab chain operates as a parachain within the Kusama network. If you are not familiar with the relationship between the relay chain and the parachain, please read [Architecture Of Polkadot](https://wiki.polkadot.network/docs/learn-architecture) first. Sometimes, it becomes necessary to run a relay chain testnet to debug the interaction between the relay chain and parachain. This tutorial provides step-by-step instructions on setting up the environment to run a local relay chain testnet with registered parachains. - -## Start the relay chain node - -Before you can start block production for a parachain, you need to start a relay chain for them to connect to. - -1. Open a terminal shell on your computer. -2. Create a work dirctory. - - Let's create a directory called `run-relay-chain` to store everything needed for setting up a relay chain network. As of the time of writing this doc(2023-08-15), the latest version of the Polkadot node is `v1.0.0`. Please ensure that you check for **[the latest version](https://github.com/paritytech/polkadot/releases)** when running your own node. - - ```bash - wget https://github.com/paritytech/polkadot/releases/download/v1.0.0/polkadot - ``` - -3. Export the local relay chain testnet specification. - - ```bash - ./polkadot build-spec --chain rococo-local --disable-default-bootnode --raw > rococo-local.json - ``` - - You'll need to specify the path to the file in the commands to start the nodes. - -4. Start the first validator using the `alice` account by running the following command: - - ```bash - ./polkadot \ - --chain rococo-local.json \ - --alice \ - --validator \ - --base-path /tmp/relay/alice \ - --port 30333 \ - --rpc-port 9944 \ - --rpc-methods=Unsafe \ - --rpc-cors all \ - --rpc-external - ``` - - Make sure that the `--chain` command-line specifies the path to the chain specification you exported in the last step. This command also uses the default values for the port (`port`) and RPC port (`rpc-port`). The values are explicitly included here as a reminder to always check these settings. After the node starts, no other nodes on the same local machine can use these ports. - -5. Review the alice node log messages as the node starts and take note of the Local node identity. You need to specify this identifier to enable other nodes to connect. - - ```bash - 2023-08-15 15:18:49 Parity Polkadot - 2023-08-15 15:18:49 ✌️ version 1.0.0-1ed6e2e50a4 - 2023-08-15 15:18:49 ❤️ by Parity Technologies , 2017-2023 - 2023-08-15 15:18:49 📋 Chain specification: Rococo Local Testnet - 2023-08-15 15:18:49 🏷 Node name: Alice - 2023-08-15 15:18:49 👤 Role: AUTHORITY - 2023-08-15 15:18:49 💾 Database: RocksDb at /tmp/relay/alice/chains/rococo_local_testnet/db/full - 2023-08-15 15:18:51 🔨 Initializing Genesis block/state (state: 0x56f4…7e84, header-hash: 0xfdd2…5ec3) - 2023-08-15 15:18:51 👴 Loading GRANDPA authority set from genesis on what appears to be first startup. - 2023-08-15 15:18:51 👶 Creating empty BABE epoch changes on what appears to be first startup. - 2023-08-15 15:18:51 🏷 Local node identity is: 12D3KooWMcssN3am9BtmSkeDPtMtzC4AwfPTTdDiFGdqbxhDVY7N - ``` - - `12D3KooWMcssN3am9BtmSkeDPtMtzC4AwfPTTdDiFGdqbxhDVY7N` is the identity of the alice relay chain node in this tutorial. - -6. Open a new terminal and start the second validator using the `bob` account. - - The command similar to the command used to start the first node with a few important differences. - - ```bash - ./polkadot \ - --chain rococo-local.json \ - --bob \ - --validator \ - --base-path /tmp/relay/bob \ - --port 30334 \ - --bootnodes /ip4/127.0.0.1/tcp/30333/p2p/12D3KooWMcssN3am9BtmSkeDPtMtzC4AwfPTTdDiFGdqbxhDVY7N \ - --rpc-port 9945 \ - --rpc-methods=Unsafe \ - --rpc-cors all \ - --rpc-external - ``` - - Notice that this command uses a different base path ( `/tmp/relay/bob`), validator key (`--bob`), and ports (`30334` and `9945`). It is important to mention that you also need to specify the `bootnodes` options for the alice relay chain node identity. - -7. Verify your node is up and running successfully by reviewing the bob node output displayed in the terminal. The terminal should display output similar to this: - - ```bash - 2023-08-15 15:21:08 Parity Polkadot - 2023-08-15 15:21:08 ✌️ version 1.0.0-1ed6e2e50a4 - 2023-08-15 15:21:08 ❤️ by Parity Technologies , 2017-2023 - 2023-08-15 15:21:08 📋 Chain specification: Rococo Local Testnet - 2023-08-15 15:21:08 🏷 Node name: Bob - 2023-08-15 15:21:08 👤 Role: AUTHORITY - 2023-08-15 15:21:08 💾 Database: RocksDb at /tmp/relay/bob/chains/rococo_local_testnet/db/full - 2023-08-15 15:21:10 🔨 Initializing Genesis block/state (state: 0x56f4…7e84, header-hash: 0xfdd2…5ec3) - 2023-08-15 15:21:10 👴 Loading GRANDPA authority set from genesis on what appears to be first startup. - 2023-08-15 15:21:11 👶 Creating empty BABE epoch changes on what appears to be first startup. - 2023-08-15 15:21:11 🏷 Local node identity is: 12D3KooWPs5ALUGa9jmVnWkfmYKL86F7MeXtby7xXYWN7Faoon8f - 2023-08-15 15:21:11 💻 Operating system: linux - 2023-08-15 15:21:11 💻 CPU architecture: x86_64 - 2023-08-15 15:21:11 💻 Target environment: gnu - 2023-08-15 15:21:11 💻 CPU: AMD Ryzen 7 5700G with Radeon Graphics - 2023-08-15 15:21:11 💻 CPU cores: 8 - 2023-08-15 15:21:11 💻 Memory: 63576MB - 2023-08-15 15:21:11 💻 Kernel: 6.2.0-26-generic - 2023-08-15 15:21:11 💻 Linux distribution: Ubuntu 22.04.2 LTS - 2023-08-15 15:21:11 💻 Virtual machine: no - 2023-08-15 15:21:11 📦 Highest known block at #0 - 2023-08-15 15:21:11 Running JSON-RPC server: addr=0.0.0.0:9945, allowed origins=["*"] - 2023-08-15 15:21:11 🏁 CPU score: 1.34 GiBs - 2023-08-15 15:21:11 🏁 Memory score: 13.85 GiBs - 2023-08-15 15:21:11 🏁 Disk score (seq. writes): 1.72 GiBs - 2023-08-15 15:21:11 🏁 Disk score (rand. writes): 725.38 MiBs - 2023-08-15 15:21:11 Starting with an empty approval vote DB. - 2023-08-15 15:21:11 👶 Starting BABE Authorship worker - 2023-08-15 15:21:11 🥩 BEEFY gadget waiting for BEEFY pallet to become available... - 2023-08-15 15:21:11 discovered: 12D3KooWMcssN3am9BtmSkeDPtMtzC4AwfPTTdDiFGdqbxhDVY7N /ip4/192.168.31.52/tcp/30333 - 2023-08-15 15:21:16 💤 Idle (1 peers), best: #0 (0xfdd2…5ec3), finalized #0 (0xfdd2…5ec3), ⬇ 1.4kiB/s ⬆ 1.4kiB/s - 2023-08-15 15:21:18 🙌 Starting consensus session on top of parent 0xfdd25265d4c8a26c0c7a9ba6127d825f8b63343c8c239a1feea964d6f6ed5ec3 - 2023-08-15 15:21:20 ParentBlockRandomness did not provide entropy - 2023-08-15 15:21:20 ParentBlockRandomness did not provide entropy - 2023-08-15 15:21:20 🎁 Prepared block for proposing at 1 (1 ms) [hash: 0x609758e21dab765fa6d6b3bb20c0d0a3c86a15fe5d3909d1e68ba319fa6209a9; parent_hash: 0xfdd2…5ec3; extrinsics (2): [0xeefb…9ae0, 0x3bb3…d7f3] - 2023-08-15 15:21:20 🔖 Pre-sealed block for proposal at 1. Hash now 0xbb2709d6d328305210f45bc1807547949013feaaa9f15f0ce994d41947c83536, previously 0x609758e21dab765fa6d6b3bb20c0d0a3c86a15fe5d3909d1e68ba319fa6209a9. - 2023-08-15 15:21:20 👶 New epoch 0 launching at block 0xbb27…3536 (block slot 282014013 >= start slot 282014013). - 2023-08-15 15:21:20 👶 Next epoch starts at slot 282014023 - 2023-08-15 15:21:20 ✨ Imported #1 (0xbb27…3536) - 2023-08-15 15:21:21 💤 Idle (1 peers), best: #1 (0xbb27…3536), finalized #0 (0xfdd2…5ec3), ⬇ 0.3kiB/s ⬆ 0.5kiB/s - 2023-08-15 15:21:24 🙌 Starting consensus session on top of parent 0xbb2709d6d328305210f45bc1807547949013feaaa9f15f0ce994d41947c83536 - 2023-08-15 15:21:24 🎁 Prepared block for proposing at 2 (0 ms) [hash: 0xfa4410daa931cfe05874593793716720358c0ea87539f8806c4b9c552794fc30; parent_hash: 0xbb27…3536; extrinsics (2): [0x9135…0ae2, 0xef7a…1dac] - 2023-08-15 15:21:24 🔖 Pre-sealed block for proposal at 2. Hash now 0xff99c4d30c95d3c16dbda56be183e087410ddfc8c8d8f30afd8ba79735ad6eae, previously 0xfa4410daa931cfe05874593793716720358c0ea87539f8806c4b9c552794fc30. - 2023-08-15 15:21:24 ✨ Imported #2 (0xff99…6eae) - 2023-08-15 15:21:26 💤 Idle (1 peers), best: #2 (0xff99…6eae), finalized #0 (0xfdd2…5ec3), ⬇ 0.4kiB/s ⬆ 0.6kiB/s - 2023-08-15 15:21:30 ✨ Imported #3 (0x76de…bee4) - 2023-08-15 15:21:31 💤 Idle (1 peers), best: #3 (0x76de…bee4), finalized #0 (0xfdd2…5ec3), ⬇ 0.4kiB/s ⬆ 0.2kiB/s - 2023-08-15 15:21:35 🥩 BEEFY pallet available: block 1 beefy genesis 1 - 2023-08-15 15:21:35 🥩 Loading BEEFY voter state from genesis on what appears to be first startup. Starting voting rounds at block 1, genesis validator set ValidatorSet { validators: [Public(020a1091341fe5664bfa1782d5e04779689068c916b04cb365ec3153755684d9a1 (1CoWvCok...)), Public(0390084fdbf27d2b79d26a4f13f0ccd982cb755a661969143c37cbc49ef5b91f27 (1Mcq981h...))], id: 0 }. - 2023-08-15 15:21:35 🥩 write aux schema version 4 - 2023-08-15 15:21:35 🥩 run BEEFY worker, best grandpa: #1. - 2023-08-15 15:21:35 🥩 Round #1 concluded, finality_proof: V1(SignedCommitment { commitment: Commitment { payload: Payload([([109, 104], [232, 60, 50, 153, 220, 153, 174, 174, 237, 44, 103, 150, 160, 255, 190, 247, 13, 109, 168, 101, 231, 195, 64, 10, 19, 12, 24, 244, 235, 50, 80, 100])]), block_number: 1, validator_set_id: 0 }, signatures: [Some(Signature(f416d92165642d317f0415fa85c38930e7eacb5c8cde4f2018a6c45e1241036c170e7d3ce2c926b8db526baee33eb3268bb13aac029c5d02b18fe78dcd3a59c800)), Some(Signature(ca8b7adeaa1f362c70f1cda3ade270a1c92a5e3045af479cbde6063061f569600d71499195730c7d6975aeb10cd604b24e514310ff3f0e81cf6abf0e30fa4cd801))] }). - 2023-08-15 15:21:36 🙌 Starting consensus session on top of parent 0x76de07890819b17436cf870af294c97ed42f3f8e7735439668331fee7f32bee4 - 2023-08-15 15:21:36 🎁 Prepared block for proposing at 4 (0 ms) [hash: 0x5db1031ce3ee02ed6f48feacecc9df55d8db2aed07da1d2d60eb55fb7b153eb1; parent_hash: 0x76de…bee4; extrinsics (2): [0x87ba…1846, 0x01c5…034c] - 2023-08-15 15:21:36 🔖 Pre-sealed block for proposal at 4. Hash now 0x262ca95317722f692ae8b8f17f73489d3000a89ad9d9eda20f27fa13e2d70983, previously 0x5db1031ce3ee02ed6f48feacecc9df55d8db2aed07da1d2d60eb55fb7b153eb1. - 2023-08-15 15:21:36 ✨ Imported #4 (0x262c…0983) - 2023-08-15 15:21:36 💤 Idle (1 peers), best: #4 (0x262c…0983), finalized #1 (0xbb27…3536), ⬇ 0.3kiB/s ⬆ 0.5kiB/s - 2023-08-15 15:21:41 💤 Idle (1 peers), best: #4 (0x262c…0983), finalized #2 (0xff99…6eae), ⬇ 0.2kiB/s ⬆ 0.2kiB/s - 2023-08-15 15:21:42 🙌 Starting consensus session on top of parent 0x262ca95317722f692ae8b8f17f73489d3000a89ad9d9eda20f27fa13e2d70983 - 2023-08-15 15:21:42 🎁 Prepared block for proposing at 5 (1 ms) [hash: 0xb5a4cbcdae03fa1afde70bb4a38f66d83457986db20513374509cd40df2c650b; parent_hash: 0x262c…0983; extrinsics (2): [0x9aca…e288, 0xd0b4…1357] - 2023-08-15 15:21:42 🔖 Pre-sealed block for proposal at 5. Hash now 0x50bdeb60701859999234c0ef477e5bb46cb3530411d5aa5c5ca824805cb1f9b4, previously 0xb5a4cbcdae03fa1afde70bb4a38f66d83457986db20513374509cd40df2c650b. - 2023-08-15 15:21:42 ✨ Imported #5 (0x50bd…f9b4) - 2023-08-15 15:21:46 💤 Idle (1 peers), best: #5 (0x50bd…f9b4), finalized #2 (0xff99…6eae), ⬇ 0.4kiB/s ⬆ 0.6kiB/s - 2023-08-15 15:21:48 🙌 Starting consensus session on top of parent 0x50bdeb60701859999234c0ef477e5bb46cb3530411d5aa5c5ca824805cb1f9b4 - 2023-08-15 15:21:48 🎁 Prepared block for proposing at 6 (1 ms) [hash: 0xf77ac618582490e98aea6cc888a1aef3c909243b2a2b83f7af77c9a56a157b81; parent_hash: 0x50bd…f9b4; extrinsics (2): [0x67ac…bdcb, 0x8082…e872] - 2023-08-15 15:21:48 🔖 Pre-sealed block for proposal at 6. Hash now 0xdb65648db04783a9f7444d23c5640c440664ab474d13418191cf123b030d0b0b, previously 0xf77ac618582490e98aea6cc888a1aef3c909243b2a2b83f7af77c9a56a157b81. - 2023-08-15 15:21:48 ✨ Imported #6 (0xdb65…0b0b) - 2023-08-15 15:21:51 💤 Idle (1 peers), best: #6 (0xdb65…0b0b), finalized #3 (0x76de…bee4), ⬇ 0.2kiB/s ⬆ 0.5kiB/s - 2023-08-15 15:21:54 🙌 Starting consensus session on top of parent 0xdb65648db04783a9f7444d23c5640c440664ab474d13418191cf123b030d0b0b - 2023-08-15 15:21:54 🎁 Prepared block for proposing at 7 (1 ms) [hash: 0x68c53155adc645cfe47046fafda6dd06aebbe44a94a4909415f10f0a29aea9cc; parent_hash: 0xdb65…0b0b; extrinsics (2): [0xea6e…c7f4, 0x0cc5…f6ec] - 2023-08-15 15:21:54 🔖 Pre-sealed block for proposal at 7. Hash now 0xfc99b2d4e8aace9ee1f18e29925f7e0c891b8fbf4dd60a8dec1be0e4eb76e943, previously 0x68c53155adc645cfe47046fafda6dd06aebbe44a94a4909415f10f0a29aea9cc. - 2023-08-15 15:21:54 ✨ Imported #7 (0xfc99…e943) - 2023-08-15 15:21:56 💤 Idle (1 peers), best: #7 (0xfc99…e943), finalized #4 (0x262c…0983), ⬇ 0.4kiB/s ⬆ 0.6kiB/s - 2023-08-15 15:22:00 ✨ Imported #8 (0x7ff6…e18f) - 2023-08-15 15:22:01 💤 Idle (1 peers), best: #8 (0x7ff6…e18f), finalized #5 (0x50bd…f9b4), ⬇ 0.4kiB/s ⬆ 0.2kiB/s - 2023-08-15 15:22:06 ✨ Imported #9 (0xf440…367a) - 2023-08-15 15:22:06 💤 Idle (1 peers), best: #9 (0xf440…367a), finalized #6 (0xdb65…0b0b), ⬇ 0.5kiB/s ⬆ 0.2kiB/s - 2023-08-15 15:22:11 💤 Idle (1 peers), best: #9 (0xf440…367a), finalized #6 (0xdb65…0b0b), ⬇ 0.2kiB/s ⬆ 0.2kiB/s - - ``` - - ```bash - 2023-08-15 15:22:11 💤 Idle (1 peers), best: #9 (0xf440…367a), finalized #6 (0xdb65…0b0b), ⬇ 0.2kiB/s ⬆ 0.2kiB/s - ``` - - This log indicates that the relay chain has started to produce blocks and is working as intended. - - -## Start the parachain node - -With the local relay chain running, you are ready to start the parachain collator node and export information about its runtime and genesis state. - -1. Open a new terminal shell on your computer. -2. Prepare the darwinia parachain node binary - - As of the time of writing this doc(2023-08-15), the latest version of the Darwinia node is `v6.4.0`. Please ensure that you check for **[the latest version](https://github.com/darwinia-network/darwinia/releases)** when running your own node. - - ```bash - wget https://github.com/darwinia-network/darwinia/releases/download/pango-6400/darwinia-x86_64-linux-gnu.tar.bz2 - tar xvf darwinia-x86_64-linux-gnu.tar.bz2 - ``` - -3. Export the local parachain chain testnet specification. - - ```bash - ./darwinia build-spec --chain pangolin-local --disable-default-bootnode > darwinia-spec.json - ``` - - You'll need to specify the path to the file in the commands to start the nodes. - -4. Export the WebAssembly runtime for the parachain. - - The relay chain needs the parachain-specific runtime validation logic to validate parachain blocks. You can export the WebAssembly runtime for a parachain collator node by running a command similar to the following: - - ```bash - /darwinia export-genesis-wasm --chain darwinia-spec.json > genesis-wasm - ``` - -5. Generate a parachain genesis state. - - To register a parachain, the relay chain needs to know the genesis state of the parachain. You can export the entire genesis state—hex-encoded—to a file by running a command similar to the following: - - ```bash - ./darwinia export-genesis-state --chain darwinia-spec.json > genesis-state - ``` - -6. Start the first validator using the `alice` account by running the following command: - - ```bash - ./darwinia \ - --name "Alice" \ - --chain darwinia-spec.json \ - --base-path /tmp/para/alice \ - --rpc-methods=Unsafe \ - --rpc-cors=all \ - --rpc-external \ - --rpc-max-connections=1000 \ - --port 40335 \ - --rpc-port 10044 \ - --alice \ - --force-authoring \ - --collator \ - -- \ - --chain rococo-local.json \ - --port 30335 \ - --bootnodes /ip4/127.0.0.1/tcp/30333/p2p/12D3KooWMcssN3am9BtmSkeDPtMtzC4AwfPTTdDiFGdqbxhDVY7N \ - --rpc-port 9946 - ``` - - In this command, the arguments passed before the lone `--` argument are for the parachain collator. The arguments after the `--` are for the embedded relay chain node. Notice that this command specifies both the chain specification for the parachain and the chain specification for the relay chain. Ensure that the `bootnodes` option specifies one of the local relay chain nodes. - - In the terminal where you started the `alice` node, you should see output similar to the following: - - ```bash - 2023-08-15 16:21:45 Darwinia - 2023-08-15 16:21:45 ✌️ version 6.3.4-8c0457841c7 - 2023-08-15 16:21:45 ❤️ by Darwinia Network , 2018-2023 - 2023-08-15 16:21:45 📋 Chain specification: Pangolin2 Local - 2023-08-15 16:21:45 🏷 Node name: Alice - 2023-08-15 16:21:45 👤 Role: AUTHORITY - 2023-08-15 16:21:45 💾 Database: RocksDb at /tmp/para/alice/chains/pangolin2-local/db/full - 2023-08-15 16:21:45 ⛓ Native runtime: Pangolin2-6400 (DarwiniaOfficialRust-0.tx0.au0) - 2023-08-15 16:21:47 [pallet::staking] assembling new collators for new session 0 at #0 - 2023-08-15 16:21:47 [pallet::staking] assembling new collators for new session 1 at #0 - 2023-08-15 16:21:47 Parachain id: Id(2105) - 2023-08-15 16:21:47 Parachain Account: 5Ec4AhNxga1JYLioRBNxfRnovheDELVbZTRSnKMgvSVPvNcN - 2023-08-15 16:21:47 Parachain genesis state: 0x000000000000000000000000000000000000000000000000000000000000000000ce905c0de2026c714a75f2026a5a4fe7636d654b05ac76a9bc5c5bceed8e91dc03170a2e7597b7b7e3d84c05391d139a62b157e78786d8c082f29dcf4c11131400 - 2023-08-15 16:21:47 Is collating: yes - 2023-08-15 16:21:47 [Parachain] [pallet::staking] assembling new collators for new session 0 at #0 - 2023-08-15 16:21:47 [Parachain] [pallet::staking] assembling new collators for new session 1 at #0 - 2023-08-15 16:21:48 [Parachain] 🔨 Initializing Genesis block/state (state: 0xce90…91dc, header-hash: 0xe9fc…f482) - 2023-08-15 16:21:49 [Relaychain] 🔨 Initializing Genesis block/state (state: 0x56f4…7e84, header-hash: 0xfdd2…5ec3) - 2023-08-15 16:21:49 [Relaychain] 👴 Loading GRANDPA authority set from genesis on what appears to be first startup. - 2023-08-15 16:21:50 [Relaychain] 👶 Creating empty BABE epoch changes on what appears to be first startup. - 2023-08-15 16:21:50 [Relaychain] 🏷 Local node identity is: 12D3KooW9vfzADPPTXdrKfrXfiLLirUCFTLK3agW182xDdC22Km9 - 2023-08-15 16:21:50 [Relaychain] 💻 Operating system: linux - 2023-08-15 16:21:50 [Relaychain] 💻 CPU architecture: x86_64 - 2023-08-15 16:21:50 [Relaychain] 💻 Target environment: gnu - 2023-08-15 16:21:50 [Relaychain] 💻 CPU: AMD Ryzen 7 5700G with Radeon Graphics - 2023-08-15 16:21:50 [Relaychain] 💻 CPU cores: 8 - 2023-08-15 16:21:50 [Relaychain] 💻 Memory: 63576MB - 2023-08-15 16:21:50 [Relaychain] 💻 Kernel: 6.2.0-26-generic - 2023-08-15 16:21:50 [Relaychain] 💻 Linux distribution: Ubuntu 22.04.2 LTS - 2023-08-15 16:21:50 [Relaychain] 💻 Virtual machine: no - 2023-08-15 16:21:50 [Relaychain] 📦 Highest known block at #0 - 2023-08-15 16:21:50 [Relaychain] Running JSON-RPC server: addr=127.0.0.1:9946, allowed origins=["http://localhost:*", "http://127.0.0.1:*", "https://localhost:*", "https://127.0.0.1:*", "https://polkadot.js.org"] - 2023-08-15 16:21:50 [Relaychain] 🏁 CPU score: 1.33 GiBs - 2023-08-15 16:21:50 [Relaychain] 〽️ Prometheus exporter started at 127.0.0.1:9616 - 2023-08-15 16:21:50 [Relaychain] 🏁 Memory score: 14.97 GiBs - 2023-08-15 16:21:50 [Relaychain] 🏁 Disk score (seq. writes): 1.59 GiBs - 2023-08-15 16:21:50 [Relaychain] 🏁 Disk score (rand. writes): 751.41 MiBs - 2023-08-15 16:21:50 [Relaychain] Starting with an empty approval vote DB. - 2023-08-15 16:21:50 [Parachain] 🏷 Local node identity is: 12D3KooWMSB38GPZdSJNAYweQ7FisAL94qDLMA9SFMu8XNyNRcGj - 2023-08-15 16:21:50 [Relaychain] discovered: 12D3KooWPs5ALUGa9jmVnWkfmYKL86F7MeXtby7xXYWN7Faoon8f /ip4/192.168.31.52/tcp/30334 - 2023-08-15 16:21:50 [Relaychain] discovered: 12D3KooWMcssN3am9BtmSkeDPtMtzC4AwfPTTdDiFGdqbxhDVY7N /ip4/192.168.31.52/tcp/30333 - 2023-08-15 16:21:50 [Relaychain] ParentBlockRandomness did not provide entropy - 2023-08-15 16:21:50 [Parachain] 💻 Operating system: linux - 2023-08-15 16:21:50 [Parachain] 💻 CPU architecture: x86_64 - 2023-08-15 16:21:50 [Parachain] 💻 Target environment: gnu - 2023-08-15 16:21:50 [Parachain] 💻 CPU: AMD Ryzen 7 5700G with Radeon Graphics - 2023-08-15 16:21:50 [Parachain] 💻 CPU cores: 8 - 2023-08-15 16:21:50 [Parachain] 💻 Memory: 63576MB - 2023-08-15 16:21:50 [Parachain] 💻 Kernel: 6.2.0-26-generic - 2023-08-15 16:21:50 [Parachain] 💻 Linux distribution: Ubuntu 22.04.2 LTS - 2023-08-15 16:21:50 [Parachain] 💻 Virtual machine: no - 2023-08-15 16:21:50 [Parachain] 📦 Highest known block at #0 - 2023-08-15 16:21:50 [Parachain] Running JSON-RPC server: addr=0.0.0.0:10044, allowed origins=["*"] - 2023-08-15 16:21:50 [Parachain] 🏁 CPU score: 1.33 GiBs - 2023-08-15 16:21:50 [Parachain] 🏁 Memory score: 14.97 GiBs - 2023-08-15 16:21:50 [Parachain] 🏁 Disk score (seq. writes): 1.59 GiBs - 2023-08-15 16:21:50 [Parachain] 🏁 Disk score (rand. writes): 751.41 MiBs - 2023-08-15 16:21:50 [Parachain] discovered: 12D3KooWPs5ALUGa9jmVnWkfmYKL86F7MeXtby7xXYWN7Faoon8f /ip4/192.168.31.52/tcp/30334 - 2023-08-15 16:21:50 [Parachain] discovered: 12D3KooWMcssN3am9BtmSkeDPtMtzC4AwfPTTdDiFGdqbxhDVY7N /ip4/192.168.31.52/tcp/30333 - 2023-08-15 16:21:54 [Relaychain] ✨ Imported #607 (0x9c46…831a) - 2023-08-15 16:21:55 [Relaychain] 💤 Idle (2 peers), best: #607 (0x9c46…831a), finalized #604 (0x996f…86cd), ⬇ 120.3kiB/s ⬆ 3.0kiB/s - 2023-08-15 16:21:55 [Parachain] 💤 Idle (0 peers), best: #0 (0xe9fc…f482), finalized #0 (0xe9fc…f482), ⬇ 1.0kiB/s ⬆ 0.5kiB/s - 2023-08-15 16:22:00 [Relaychain] ✨ Imported #608 (0xa192…89c2) - 2023-08-15 16:22:00 [Relaychain] 💤 Idle (2 peers), best: #608 (0xa192…89c2), finalized #605 (0xfec8…0b57), ⬇ 1.6kiB/s ⬆ 0.8kiB/s - 2023-08-15 16:22:00 [Parachain] 💤 Idle (0 peers), best: #0 (0xe9fc…f482), finalized #0 (0xe9fc…f482), ⬇ 45 B/s ⬆ 45 B/s - 2023-08-15 16:22:05 [Relaychain] 💤 Idle (2 peers), best: #608 (0xa192…89c2), finalized #606 (0xa1e2…f4c4), ⬇ 1.1kiB/s ⬆ 0.5kiB/s - 2023-08-15 16:22:05 [Parachain] 💤 Idle (0 peers), best: #0 (0xe9fc…f482), finalized #0 (0xe9fc…f482), ⬇ 0.1kiB/s ⬆ 66 B/s - 2023-08-15 16:22:06 [Relaychain] ✨ Imported #609 (0x0a7f…85aa) - 2023-08-15 16:22:06 [Relaychain] ✨ Imported #609 (0xfb83…08ba) - 2023-08-15 16:22:10 [Relaychain] 💤 Idle (2 peers), best: #609 (0x0a7f…85aa), finalized #606 (0xa1e2…f4c4), ⬇ 1.4kiB/s ⬆ 0.7kiB/s - 2023-08-15 16:22:10 [Parachain] 💤 Idle (0 peers), best: #0 (0xe9fc…f482), finalized #0 (0xe9fc…f482), ⬇ 0.2kiB/s ⬆ 0.1kiB/s - 2023-08-15 16:22:12 [Relaychain] ✨ Imported #610 (0x883b…b5c2) - 2023-08-15 16:22:15 [Relaychain] 💤 Idle (2 peers), best: #610 (0x883b…b5c2), finalized #607 (0x9c46…831a), ⬇ 0.8kiB/s ⬆ 0.5kiB/s - 2023-08-15 16:22:15 [Parachain] 💤 Idle (0 peers), best: #0 (0xe9fc…f482), finalized #0 (0xe9fc…f482), ⬇ 0.1kiB/s ⬆ 61 B/s - 2023-08-15 16:22:18 [Relaychain] 👶 New epoch 61 launching at block 0x5f18…813e (block slot 282014623 >= start slot 282014623). - 2023-08-15 16:22:18 [Relaychain] 👶 Next epoch starts at slot 282014633 - 2023-08-15 16:22:18 [Relaychain] ✨ Imported #611 (0x5f18…813e) - 2023-08-15 16:22:20 [Relaychain] 💤 Idle (2 peers), best: #611 (0x5f18…813e), finalized #608 (0xa192…89c2), ⬇ 1.6kiB/s ⬆ 0.7kiB/s - 2023-08-15 16:22:20 [Parachain] 💤 Idle (0 peers), best: #0 (0xe9fc…f482), finalized #0 (0xe9fc…f482), ⬇ 0.1kiB/s ⬆ 0.1kiB/s - 2023-08-15 16:22:24 [Relaychain] ✨ Imported #612 (0xccbc…4c7d) - 2023-08-15 16:22:25 [Relaychain] 💤 Idle (2 peers), best: #612 (0xccbc…4c7d), finalized #609 (0x0a7f…85aa), ⬇ 0.9kiB/s ⬆ 0.6kiB/s - 2023-08-15 16:22:25 [Parachain] 💤 Idle (0 peers), best: #0 (0xe9fc…f482), finalized #0 (0xe9fc…f482), ⬇ 0.2kiB/s ⬆ 0.1kiB/s - 2023-08-15 16:22:30 [Relaychain] ✨ Imported #613 (0x58a1…81a1) - 2023-08-15 16:22:30 [Relaychain] 💤 Idle (2 peers), best: #613 (0x58a1…81a1), finalized #610 (0x883b…b5c2), ⬇ 1.0kiB/s ⬆ 0.6kiB/s - 2023-08-15 16:22:30 [Parachain] 💤 Idle (0 peers), best: #0 (0xe9fc…f482), finalized #0 (0xe9fc…f482), ⬇ 0.1kiB/s ⬆ 66 B/s - 2023-08-15 16:22:35 [Relaychain] 💤 Idle (2 peers), best: #613 (0x58a1…81a1), finalized #610 (0x883b…b5c2), ⬇ 0.4kiB/s ⬆ 0.3kiB/s - 2023-08-15 16:22:35 [Parachain] 💤 Idle (0 peers), best: #0 (0xe9fc…f482), finalized #0 (0xe9fc…f482), ⬇ 0.1kiB/s ⬆ 55 B/s - 2023-08-15 16:22:35 [Relaychain] 👴 Applying authority set change scheduled at block #611 - 2023-08-15 16:22:35 [Relaychain] 👴 Applying GRANDPA set change to new set [(Public(88dc3417d5058ec4b4503e0c12ea1a0a89be200fe98922423d4334014fa6b0ee (5FA9nQDV...)), 1), (Public(d17c2d7823ebf260fd138f2d7e27d114c0145d968b5ff5006125f2414fadae69 (5GoNkf6W...)), 1)] - ``` - - ```bash - 2023-08-15 16:23:45 [Relaychain] 💤 Idle (2 peers), best: #625 (0x421f…bad6), finalized #622 (0x84ca…8dcd), ⬇ 0.7kiB/s ⬆ 0.3kiB/s - ``` - - This log indicates that the relay chain node embedded in your parachain node has connected to the running relay chain validators. - -7. Open a new terminal and start the second validator using the `bob` account. - - The command similar to the command used to start the alice parachain node with a few important differences. - - ```bash - ./darwinia \ - --name "Bob" \ - --chain darwinia-spec.json \ - --base-path /tmp/para/bob \ - --rpc-methods=Unsafe \ - --rpc-cors=all \ - --rpc-external \ - --rpc-max-connections=1000 \ - --frontier-backend-type sql \ - --port 40336 \ - --rpc-port 10045 \ - --bootnodes /ip4/127.0.0.1/tcp/40335/p2p/12D3KooWMSB38GPZdSJNAYweQ7FisAL94qDLMA9SFMu8XNyNRcGj \ - --bob \ - --force-authoring \ - --collator \ - -- \ - --chain rococo-local.json \ - --bootnodes /ip4/127.0.0.1/tcp/30333/p2p/12D3KooWMcssN3am9BtmSkeDPtMtzC4AwfPTTdDiFGdqbxhDVY7N \ - --port 30336 \ - --rpc-port 9947 - ``` - - Notice that this command uses a different base path ( `/tmp/para/bob`), collator key (`--bob`), and ports. It is important to mention that you must specify the correct `bootnodes` options for both the parachain and the relay chain. - -8. Open a new terminal and start the second validator using the `charlie` account. - - The command similar to the command used to start the alice parachain node with a few important differences. - - ```bash - ./darwinia \ - --name "Charlie" \ - --chain darwinia-spec.json \ - --base-path /tmp/para/charlie \ - --rpc-methods=Unsafe \ - --rpc-cors=all \ - --rpc-external \ - --rpc-max-connections=1000 \ - --frontier-backend-type sql \ - --port 40337 \ - --rpc-port 10046 \ - --bootnodes /ip4/127.0.0.1/tcp/40335/p2p/12D3KooWMSB38GPZdSJNAYweQ7FisAL94qDLMA9SFMu8XNyNRcGj \ - --charlie \ - --force-authoring \ - --collator \ - -- \ - --chain rococo-local.json \ - --bootnodes /ip4/127.0.0.1/tcp/30333/p2p/12D3KooWMcssN3am9BtmSkeDPtMtzC4AwfPTTdDiFGdqbxhDVY7N \ - --port 30337 \ - --rpc-port 9948 - ``` - - Notice that this command uses a different base path ( `/tmp/para/charlie`), collator key (`--charlie`), and ports. It is important to mention that you must specify the correct bootnodes options for both the parachain and the relay chain. - - -## Register with the local relay chain - -With the local relay chain and collator node running, you are ready to register the parachain on the local relay chain. In a live public network, registration typically involves a [parachain auction](https://wiki.polkadot.network/docs/en/learn-auction). For this tutorial and local testing, you can use a Sudo transaction and the Polkadot/Substrate Portal. Using a Sudo transaction enables you to bypass the steps required to acquire a parachain or parathread slot. - -To register the parachain: - -1. Validate your local relay chain validators are running. -2. Open the [Polkadot/Substrate Portal](https://polkadot.js.org/apps/?rpc=ws%3A%2F%2F127.0.0.1%3A9944#/parachains/parathreads) in a browser. -3. Connect to a local relay chain node, and click **Developer** and select **Sudo**. - - ![evm-tutorial-relaychain-node-1](../../../images/evm-tutorial-relaychain-node-1.png) - -4. Select **paraSudoWrapper**, then select **sudoScheduleParaInitialize(id, genesis)** to initialize the reserved paraID at the start of the next relay chain session. - - For the transaction parameters: - - - `id`: Type your reserved `ParaId`. For this tutorial, the reserved identifier is `2105`. - - `genesisHead`: Click **file upload** and upload the genesis state you exported for the parachain. For this tutorial, select the `genesis-state` file. - - `validationCode`: Click **file upload** and upload the WebAssembly runtime you exported for the parachain For this tutorial, select the `genesis-wasm` file. - - `paraKind`: Select **Yes**. - - ![evm-tutorial-relaychain-node-2](../../../images/evm-tutorial-relaychain-node-2.png) - -5. Click **Submit Sudo**. -6. Review the transaction details, then click **Sign and Submit** to authorize the transaction. - - After you submit the transaction, click **Network** and select **Explorer**. Check the list of recent events for successful `sudo.Sudid` *and* `paras.PvfCheckAccepted` and click the event to see details about the transaction. - - ![evm-tutorial-relaychain-node-3](../../../images/evm-tutorial-relaychain-node-3.png) - -7. Click **Network** and select **Parachains** and wait for a new epoch to start. - - ![evm-tutorial-relaychain-node-4](../../../images/evm-tutorial-relaychain-node-4.png) - - The terminal where the parachain node is running also displays details similar to the following: - - ```bash - 023-08-15 17:07:06 [Parachain] Starting collation. relay_parent=0xc1597ee7e74d9b828cd4f5d0ee42e773ca2b0e71219d5c21dffeb25255f1a01e at=0x692ed576627e90c8761c1565ae462b775d846a7541b8ffcc4f23ad0b9da0ad69 - 2023-08-15 17:07:06 [Parachain] 🙌 Starting consensus session on top of parent 0x692ed576627e90c8761c1565ae462b775d846a7541b8ffcc4f23ad0b9da0ad69 - 2023-08-15 17:07:06 [Parachain] [pallet::message-gadget] invalid raw message root: [], return. - 2023-08-15 17:07:06 [Parachain] 🎁 Prepared block for proposing at 20 (0 ms) [hash: 0x8112f315abab76d492752d290adbea64a319257f7eabc11fb4bfe7360730364e; parent_hash: 0x692e…ad69; extrinsics (2): [0xfe56…3f8c, 0xe89f…8e0e]] - 2023-08-15 17:07:06 [Parachain] 🔖 Pre-sealed block for proposal at 20. Hash now 0x0fe9ae36a7f8ccd29b397782dfe3fe6e31cbd06f6b6bf8db5e95af8caf86fe5e, previously 0x8112f315abab76d492752d290adbea64a319257f7eabc11fb4bfe7360730364e. - 2023-08-15 17:07:06 [Parachain] ✨ Imported #20 (0x0fe9…fe5e) - 2023-08-15 17:07:06 [Parachain] PoV size { header: 0.2568359375kb, extrinsics: 3.16796875kb, storage_proof: 9.3154296875kb } - 2023-08-15 17:07:06 [Parachain] Compressed PoV size: 8.869140625kb - 2023-08-15 17:07:06 [Parachain] Produced proof-of-validity candidate. block_hash=0x0fe9ae36a7f8ccd29b397782dfe3fe6e31cbd06f6b6bf8db5e95af8caf86fe5e - 2023-08-15 17:07:10 [Parachain] 💤 Idle (2 peers), best: #19 (0x692e…ad69), finalized #18 (0x9f3f…c19f), ⬇ 0.2kiB/s ⬆ 1.8kiB/s - 2023-08-15 17:07:10 [Relaychain] 💤 Idle (4 peers), best: #1059 (0xc159…a01e), finalized #1057 (0xff17…58dc), ⬇ 2.6kiB/s ⬆ 3.8kiB/s - 2023-08-15 17:07:12 [Relaychain] ✨ Imported #1060 (0x63ad…f3f8) - 2023-08-15 17:07:15 [Parachain] 💤 Idle (2 peers), best: #19 (0x692e…ad69), finalized #18 (0x9f3f…c19f), ⬇ 0.6kiB/s ⬆ 0.3kiB/s - 2023-08-15 17:07:15 [Relaychain] 💤 Idle (4 peers), best: #1060 (0x63ad…f3f8), finalized #1058 (0x3da3…4eeb), ⬇ 1.8kiB/s ⬆ 1.4kiB/s - 2023-08-15 17:07:18 [Relaychain] 👶 New epoch 106 launching at block 0xa2c8…630e (block slot 282015073 >= start slot 282015073). - 2023-08-15 17:07:18 [Relaychain] 👶 Next epoch starts at slot 282015083 - 2023-08-15 17:07:18 [Relaychain] ✨ Imported #1061 (0xa2c8…630e) - 2023-08-15 17:07:18 [Parachain] Starting collation. relay_parent=0xa2c8678b48702db4ba7d2e686f5b31aaffc12c7ad69f973fb1258f41ae7b630e at=0x0fe9ae36a7f8ccd29b397782dfe3fe6e31cbd06f6b6bf8db5e95af8caf86fe5e - 2023-08-15 17:07:18 [Parachain] ✨ Imported #21 (0x8cf3…7acb) - 2023-08-15 17:07:18 [Relaychain] Trying to remove unknown reserved node: 12D3KooWPs5ALUGa9jmVnWkfmYKL86F7MeXtby7xXYWN7Faoon8f. - 2023-08-15 17:07:20 [Parachain] 💤 Idle (2 peers), best: #20 (0x0fe9…fe5e), finalized #18 (0x9f3f…c19f), ⬇ 1.2kiB/s ⬆ 0.3kiB/s - 2023-08-15 17:07:20 [Relaychain] 💤 Idle (4 peers), best: #1061 (0xa2c8…630e), finalized #1058 (0x3da3…4eeb), ⬇ 2.4kiB/s ⬆ 1.9kiB/s - 2023-08-15 17:07:24 [Relaychain] ✨ Imported #1062 (0x3de4…4529) - 2023-08-15 17:07:25 [Parachain] 💤 Idle (2 peers), best: #20 (0x0fe9…fe5e), finalized #19 (0x692e…ad69), ⬇ 0.1kiB/s ⬆ 0.1kiB/s - 2023-08-15 17:07:25 [Relaychain] 💤 Idle (4 peers), best: #1062 (0x3de4…4529), finalized #1059 (0xc159…a01e), ⬇ 1.6kiB/s ⬆ 0.9kiB/s - 2023-08-15 17:07:30 [Relaychain] ✨ Imported #1063 (0xd57c…50ce) - 2023-08-15 17:07:30 [Parachain] Starting collation. relay_parent=0xd57cbb8a510ef0a32b5028920f380342a259026ae2d0b922e5bd24cd4c4850ce at=0x8cf373c6450049ccf62b20f45f5e99e9d0f3af38ab64b87cb7c4273a4b677acb - 2023-08-15 17:07:30 [Parachain] ✨ Imported #22 (0x3150…bea7) - 2023-08-15 17:07:30 [Parachain] 💤 Idle (2 peers), best: #21 (0x8cf3…7acb), finalized #19 (0x692e…ad69), ⬇ 1.1kiB/s ⬆ 0.1kiB/s - 2023-08-15 17:07:30 [Relaychain] 💤 Idle (4 peers), best: #1063 (0xd57c…50ce), finalized #1060 (0x63ad…f3f8), ⬇ 2.4kiB/s ⬆ 1.8kiB/s - 2023-08-15 17:07:34 [Relaychain] 👴 Applying authority set change scheduled at block #1061 - 2023-08-15 17:07:34 [Relaychain] 👴 Applying GRANDPA set change to new set [(Public(88dc3417d5058ec4b4503e0c12ea1a0a89be200fe98922423d4334014fa6b0ee (5FA9nQDV...)), 1), (Public(d17c2d7823ebf260fd138f2d7e27d114c0145d968b5ff5006125f2414fadae69 (5GoNkf6W...)), 1)] - ``` - - When you see the message "Starting collation," it means that your collator has begun producing parachain blocks. This indicates that the parachain has been successfully registered in the relay chain. \ No newline at end of file diff --git a/docs/evm/tutorial/smart-contract/awesome-tutorial.md b/docs/evm/tutorial/smart-contract/awesome-tutorial.md deleted file mode 100644 index 82fbd89..0000000 --- a/docs/evm/tutorial/smart-contract/awesome-tutorial.md +++ /dev/null @@ -1,15 +0,0 @@ -In addition to the tutorials provided in the [Ethereum Compatibility](../../ethereum-compatibility/jsonrpc.md) chapter, it is worth noting that most tools commonly used with Ethereum are also compatible with Darwinia networks. This means that there are already numerous resources available that cover the skills typically employed by a blockchain engineer, such as writing, debugging, deploying smart contracts, and interacting with the blockchain. - -Given the wide range of existing resources, it would be impractical to provide a comprehensive guide covering all of these topics. Instead, we can recommend a selection of excellent tutorials for further reading and learning. It's important to note that all of these resources are applicable to Darwinia chains. - -## Understanding Smart Contracts - -- [Ethereum's introduction to smart contracts](https://ethereum.org/en/developers/docs/smart-contracts/) - - Provides a good starting point for beginners. It also recommends reading up on accounts, transactions, and the Ethereum virtual machine - before diving into smart contracts. -- [Solidity by Example](https://solidity-by-example.org/) - - An introduction to Solidity with simple examples. -- [A 101 Noob Intro to Programming Smart Contracts on Ethereum**](https://medium.com/@Consensys/a-101-noob-intro-to-programming-smart-contracts-on-ethereum-695d15c1dab4) - - Provides a comprehensive overview of key terms, Ethereum clients, smart contract languages, and current DApp frameworks and tools. -- [Smartcontract challenges](https://www.smartcontract.engineer/) - - Learn Solidity and Vyper with challenges \ No newline at end of file diff --git a/docs/images/evm-tutorial-relaychain-node-1.png b/docs/images/evm-tutorial-relaychain-node-1.png deleted file mode 100644 index d2e706b..0000000 Binary files a/docs/images/evm-tutorial-relaychain-node-1.png and /dev/null differ diff --git a/docs/images/evm-tutorial-relaychain-node-2.png b/docs/images/evm-tutorial-relaychain-node-2.png deleted file mode 100644 index 6a0c37b..0000000 Binary files a/docs/images/evm-tutorial-relaychain-node-2.png and /dev/null differ diff --git a/docs/images/evm-tutorial-relaychain-node-3.png b/docs/images/evm-tutorial-relaychain-node-3.png deleted file mode 100644 index 8190b84..0000000 Binary files a/docs/images/evm-tutorial-relaychain-node-3.png and /dev/null differ diff --git a/docs/images/evm-tutorial-relaychain-node-4.png b/docs/images/evm-tutorial-relaychain-node-4.png deleted file mode 100644 index c8be5f4..0000000 Binary files a/docs/images/evm-tutorial-relaychain-node-4.png and /dev/null differ diff --git a/docs/evm/chains/crab.md b/docs/learn/chains/crab.md similarity index 100% rename from docs/evm/chains/crab.md rename to docs/learn/chains/crab.md diff --git a/docs/evm/chains/darwinia.md b/docs/learn/chains/darwinia.md similarity index 100% rename from docs/evm/chains/darwinia.md rename to docs/learn/chains/darwinia.md diff --git a/docs/evm/chains/overview.md b/docs/learn/chains/overview.md similarity index 100% rename from docs/evm/chains/overview.md rename to docs/learn/chains/overview.md diff --git a/docs/evm/chains/pangolin.md b/docs/learn/chains/pangolin.md similarity index 100% rename from docs/evm/chains/pangolin.md rename to docs/learn/chains/pangolin.md diff --git a/docs/evm/chains/rollup.md b/docs/learn/chains/rollup.md similarity index 100% rename from docs/evm/chains/rollup.md rename to docs/learn/chains/rollup.md diff --git a/docs/evm/ethereum-compatibility/account-system.md b/docs/learn/ethereum-compatibility/account-system.md similarity index 100% rename from docs/evm/ethereum-compatibility/account-system.md rename to docs/learn/ethereum-compatibility/account-system.md diff --git a/docs/evm/ethereum-compatibility/evm-tracing.md b/docs/learn/ethereum-compatibility/evm-tracing.md similarity index 94% rename from docs/evm/ethereum-compatibility/evm-tracing.md rename to docs/learn/ethereum-compatibility/evm-tracing.md index 00a855d..f270db1 100644 --- a/docs/evm/ethereum-compatibility/evm-tracing.md +++ b/docs/learn/ethereum-compatibility/evm-tracing.md @@ -18,6 +18,6 @@ These APIs enable developers to examine and analyze the execution details of the It is worth noting that the EVM tracing features in Darwinia are specifically provided by a dedicated type of node. This design decision is made to ensure that the tracing feature is only enabled when needed, avoiding unnecessary overhead for production nodes. -The EVM tracing node in Darwinia has its own distinct binary and requires a separate setup command compared to the production node. For more detailed information on running an EVM tracing node, please refer to the [Run Evm Trace Node](../tutorial/chain/run-evm-tracing-node.md). +The EVM tracing node in Darwinia has its own distinct binary and requires a separate setup command compared to the production node. For more detailed information on running an EVM tracing node, please refer to the [Run Evm Trace Node](../../build/chain/run-evm-tracing-node.md). -To utilize the EVM tracing features in Darwinia, users should send requests to the dedicated node's RPC endpoint, which can be found in the corresponding [Network Info](../chains/darwinia.md#network-info). This ensures that the tracing capabilities are utilized effectively and efficiently within the Darwinia ecosystem. \ No newline at end of file +To utilize the EVM tracing features in Darwinia, users should send requests to the dedicated node's RPC endpoint, which can be found in the corresponding [Network Info](../chains/pangolin.md#network-info). This ensures that the tracing capabilities are utilized effectively and efficiently within the Darwinia ecosystem. \ No newline at end of file diff --git a/docs/evm/ethereum-compatibility/gas.md b/docs/learn/ethereum-compatibility/gas.md similarity index 100% rename from docs/evm/ethereum-compatibility/gas.md rename to docs/learn/ethereum-compatibility/gas.md diff --git a/docs/evm/ethereum-compatibility/jsonrpc.md b/docs/learn/ethereum-compatibility/jsonrpc.md similarity index 100% rename from docs/evm/ethereum-compatibility/jsonrpc.md rename to docs/learn/ethereum-compatibility/jsonrpc.md diff --git a/docs/learn/ethereum-compatibility/precompiles/commitment-token.md b/docs/learn/ethereum-compatibility/precompiles/commitment-token.md new file mode 100644 index 0000000..adb2e6f --- /dev/null +++ b/docs/learn/ethereum-compatibility/precompiles/commitment-token.md @@ -0,0 +1,11 @@ +# Commitment Token Precompile + +Before delving into the understanding of this precompile, it's essential to have knowledge about the [Commitment Token](../../stake/commitment-token.md), within the Darwinia ecosystem. In the architecture of Darwinia, the native token is designed to be fundamentally compatible with Ethereum. This means that the native token can be seamlessly used in Ethereum-compatible environments without requiring extensive modifications or adaptations. It provides out-of-the-box compatibility, allowing users to interact with the native token using Ethereum tools and infrastructure. However, the commitment token in the Darwinia system operates differently. It is a separate standalone token that functions within the Darwinia ecosystem. The commitment token is implemented by a pallet called the [pallet-asset](https://marketplace.substrate.io/pallets/pallet-assets/), which is part of the Substrate ecosystem. The pallet-asset facilitates the management of the commitment token, including features such as token transfers, balances, and other related operations. + +Similar to the staking and deposit precompiles, the commitment token also requires a dedicated precompile to enhance its usability for users of Ethereum tools. This precompile acts as a bridge, simplifying the interaction between Ethereum users and the commitment token. By leveraging this precompile, Ethereum users can seamlessly interact with the commitment token using their familiar Ethereum workflows and tools, such as MetaMask. + +## Contract Info + +- The default contract address: 0x0000000000000000000000000000000000000402 +- [The interface](https://github.com/darwinia-network/darwinia/blob/main/precompile/metadata/sol/asset.sol) +- [The ABI](https://github.com/darwinia-network/darwinia/blob/main/precompile/metadata/abi/asset.json) \ No newline at end of file diff --git a/docs/evm/ethereum-compatibility/precompiles/conviction-voting.md b/docs/learn/ethereum-compatibility/precompiles/conviction-voting.md similarity index 100% rename from docs/evm/ethereum-compatibility/precompiles/conviction-voting.md rename to docs/learn/ethereum-compatibility/precompiles/conviction-voting.md diff --git a/docs/learn/ethereum-compatibility/precompiles/deposit.md b/docs/learn/ethereum-compatibility/precompiles/deposit.md new file mode 100644 index 0000000..75cea6c --- /dev/null +++ b/docs/learn/ethereum-compatibility/precompiles/deposit.md @@ -0,0 +1,9 @@ +# Deposit Precompile + +The [Darwinia staking solution](../../stake/staking.md) consists of two components, including the staking pallet and the deposit pallet. Each of these pallets has its own precompile functionality, which is specifically designed to facilitate interaction for Ethereum users. In this context, we will focus on the deposit precompile. By leveraging the deposit precompile, Ethereum users can conveniently deposit their assets into the Darwinia network and participate in the staking process. + +## Contract Info + +- The default contract address: 0x0000000000000000000000000000000000000600 +- [The interface](https://github.com/darwinia-network/darwinia/blob/main/precompile/metadata/sol/deposit.sol) +- [The ABI](https://github.com/darwinia-network/darwinia/blob/main/precompile/metadata/abi/deposit.json) \ No newline at end of file diff --git a/docs/evm/ethereum-compatibility/precompiles/dispatch.md b/docs/learn/ethereum-compatibility/precompiles/dispatch.md similarity index 100% rename from docs/evm/ethereum-compatibility/precompiles/dispatch.md rename to docs/learn/ethereum-compatibility/precompiles/dispatch.md diff --git a/docs/evm/ethereum-compatibility/precompiles/ethereum.md b/docs/learn/ethereum-compatibility/precompiles/ethereum.md similarity index 100% rename from docs/evm/ethereum-compatibility/precompiles/ethereum.md rename to docs/learn/ethereum-compatibility/precompiles/ethereum.md diff --git a/docs/evm/ethereum-compatibility/precompiles/overview.md b/docs/learn/ethereum-compatibility/precompiles/overview.md similarity index 100% rename from docs/evm/ethereum-compatibility/precompiles/overview.md rename to docs/learn/ethereum-compatibility/precompiles/overview.md diff --git a/docs/evm/ethereum-compatibility/precompiles/staking.md b/docs/learn/ethereum-compatibility/precompiles/staking.md similarity index 57% rename from docs/evm/ethereum-compatibility/precompiles/staking.md rename to docs/learn/ethereum-compatibility/precompiles/staking.md index c567bba..f3e3e10 100644 --- a/docs/evm/ethereum-compatibility/precompiles/staking.md +++ b/docs/learn/ethereum-compatibility/precompiles/staking.md @@ -1,6 +1,6 @@ # Staking Precompile -To fully understand the concept of the precompile and its significance in the context of the Darwinia staking solution, it is important to have a grasp of the overall design of the staking solution. [The Darwinia staking](../../darwinia-staking/staking.md) solution is implemented as a pallet, which is a modular component in the Substrate framework. Pallets are native to Substrate and provide a way to encapsulate and organize blockchain logic. However, they are not inherently compatible with Ethereum tools and infrastructure. One consequence of this design is that accessing the staking API with tools like MetaMask, which are commonly used in Ethereum development, is not possible out of the box. This is because MetaMask expects to interact with Ethereum-compatible contracts and APIs, and the staking solution implemented as a pallet in Darwinia does not natively adhere to those standards. +To fully understand the concept of the precompile and its significance in the context of the Darwinia staking solution, it is important to have a grasp of the overall design of the staking solution. [The Darwinia staking](../../stake/staking.md) solution is implemented as a pallet, which is a modular component in the Substrate framework. Pallets are native to Substrate and provide a way to encapsulate and organize blockchain logic. However, they are not inherently compatible with Ethereum tools and infrastructure. One consequence of this design is that accessing the staking API with tools like MetaMask, which are commonly used in Ethereum development, is not possible out of the box. This is because MetaMask expects to interact with Ethereum-compatible contracts and APIs, and the staking solution implemented as a pallet in Darwinia does not natively adhere to those standards. To bridge this gap and enable interaction with the staking API using Ethereum tools, the staking precompile comes into play. The staking precompile refers to a specific implementation that exposes the staking API in a format that is compatible with Ethereum tools such as MetaMask. By utilizing the staking precompile, developers can seamlessly integrate the Darwinia staking solution with their Ethereum workflows and tools. diff --git a/docs/evm/ethereum-compatibility/precompiles/state-storage.md b/docs/learn/ethereum-compatibility/precompiles/state-storage.md similarity index 100% rename from docs/evm/ethereum-compatibility/precompiles/state-storage.md rename to docs/learn/ethereum-compatibility/precompiles/state-storage.md diff --git a/docs/evm/ethereum-compatibility/precompiles/usdt.md b/docs/learn/ethereum-compatibility/precompiles/usdt.md similarity index 100% rename from docs/evm/ethereum-compatibility/precompiles/usdt.md rename to docs/learn/ethereum-compatibility/precompiles/usdt.md diff --git a/docs/evm/faq.md b/docs/learn/faq.md similarity index 86% rename from docs/evm/faq.md rename to docs/learn/faq.md index 8f96257..0ce8612 100644 --- a/docs/evm/faq.md +++ b/docs/learn/faq.md @@ -2,15 +2,15 @@ ## What distinguishes the Darwinia, Crab and Pangolin networks from each other? -See [Chains And Explorers](../evm/chains/overview.md) +See [Chains](./chains/overview.md) ## Why is there a Darwinia 2.0? -Great question! Before the [Merge](https://medium.com/darwinianetwork/darwinia-2-0-merge-overview-96af96d668aa), the Darwinia 1.0 era included six networks within the Darwinia Ecosystem: the Darwinia Solo Network, Crab Solo Network, Darwinia Parachain Network, Crab Parachain Network, and two test networks. However, having so many networks caused confusion among users, making it difficult to understand their relationships. To address this, we decided to merge the Darwinia Solo Network into the Darwinia Parachain Network, and the Crab Solo Network into the Crab Parachain Network. This merge not only simplified the network structure but also resolved technical issues such as account system and crypto primitive compatibility with Ethereum. If you have an account in the Darwinia 1.0 network, we have developed a user-friendly application to assist you with migrating your assets to the Darwinia 2.0 network. Be sure to check out our [tutorial](../evm/tutorial/migration/generate-account.md) for more information. +Great question! Before the [Merge](https://medium.com/darwinianetwork/darwinia-2-0-merge-overview-96af96d668aa), the Darwinia 1.0 era included six networks within the Darwinia Ecosystem: the Darwinia Solo Network, Crab Solo Network, Darwinia Parachain Network, Crab Parachain Network, and two test networks. However, having so many networks caused confusion among users, making it difficult to understand their relationships. To address this, we decided to merge the Darwinia Solo Network into the Darwinia Parachain Network, and the Crab Solo Network into the Crab Parachain Network. This merge not only simplified the network structure but also resolved technical issues such as account system and crypto primitive compatibility with Ethereum. If you have an account in the Darwinia 1.0 network, we have developed a user-friendly application to assist you with migrating your assets to the Darwinia 2.0 network. Be sure to check out our [tutorial](../build/getting-started/migration/generate-account.md) for more information. ## Where can I buy Darwinia Tokens? -[Darwinia's native token](../ring.md), can be purchased from various centralized and decentralized cryptocurrency exchanges. According to [CoinMarketCap](https://coinmarketcap.com/currencies/darwinia-network/), the top exchanges for trading in Darwinia Network (RING tokens) are currently Huobi, Gate.io, MEXC, Poloniex, and CoinEx. [CoinGecko](https://www.coingecko.com/en/coins/darwinia-network) also lists MEXC, Gate.io, and CoinEx as popular exchanges for trading RING tokens. +[Darwinia's native token](../ring-dao.md), can be purchased from various centralized and decentralized cryptocurrency exchanges. According to [CoinMarketCap](https://coinmarketcap.com/currencies/darwinia-network/), the top exchanges for trading in Darwinia Network (RING tokens) are currently Huobi, Gate.io, MEXC, Poloniex, and CoinEx. [CoinGecko](https://www.coingecko.com/en/coins/darwinia-network) also lists MEXC, Gate.io, and CoinEx as popular exchanges for trading RING tokens. Here's an example of how to buy RING tokens: diff --git a/docs/evm/governance.md b/docs/learn/governance.md similarity index 96% rename from docs/evm/governance.md rename to docs/learn/governance.md index 68968b6..0e27f0b 100644 --- a/docs/evm/governance.md +++ b/docs/learn/governance.md @@ -4,7 +4,7 @@ Currently, Darwinia employs OpenGov for governance. For more details on how it f Darwinia plans to transition from OpenGov to Tally in the future. -Check out the [tutorial](./tutorial/governance.md). +Check out the [tutorial](../build/getting-started/governance.md). ## Parameters diff --git a/docs/evm/darwinia-staking/commitment-token.md b/docs/learn/stake/commitment-token.md similarity index 100% rename from docs/evm/darwinia-staking/commitment-token.md rename to docs/learn/stake/commitment-token.md diff --git a/docs/evm/darwinia-staking/deposit.md b/docs/learn/stake/deposit.md similarity index 100% rename from docs/evm/darwinia-staking/deposit.md rename to docs/learn/stake/deposit.md diff --git a/docs/evm/darwinia-staking/staking.md b/docs/learn/stake/staking.md similarity index 100% rename from docs/evm/darwinia-staking/staking.md rename to docs/learn/stake/staking.md diff --git a/docs/evm/wallets.md b/docs/learn/wallets.md similarity index 100% rename from docs/evm/wallets.md rename to docs/learn/wallets.md diff --git a/docs/msgport/api.md b/docs/msgport/api.md deleted file mode 100644 index b340dac..0000000 --- a/docs/msgport/api.md +++ /dev/null @@ -1,8 +0,0 @@ -# Msgport API - -!!! note - If you're looking to explore the workings of the Msgport API more thoroughly, there is [a runnable demo](../msgport/tutorial/script-demo.md) at your disposal. This practical example serves as an excellent resource to witness the Msgport API's functionality in real-time. - -The [Msgport API](https://github.com/darwinia-network/darwinia-msgport-api) serves as a specialized tool to assist Msgport Apps in acquiring additional information necessary for the message delivery process. **Its primary role is to provide an estimation of the cross-chain fee in the native token of the source chain.** This fee covers the various cross-chain expenses that Dapps are responsible for, encapsulating the costs associated with handling token value differences between chains and the delivery and execution fees incurred on both the source and destination chains. By offering the fee estimation in the source chain's native currency, the Msgport API simplifies these complexities, resulting in a seamless user experience. Users benefit from this approach as it eliminates the need for them to possess any tokens from the target chain to facilitate cross-chain transactions. - -Beyond providing fee information, the API also delivers associated parameter data. These parameters are necessary for the messaging layer, which is the cross-chain messaging protocol employed by Msgport. Simply put, these parameters are the directives required by the messaging protocol's relayer to carry out cross-chain operations on the destination chain. \ No newline at end of file diff --git a/docs/msgport/faq.md b/docs/msgport/faq.md deleted file mode 100644 index 0143eaf..0000000 --- a/docs/msgport/faq.md +++ /dev/null @@ -1,13 +0,0 @@ -# FAQ - -## Which networks are currently supported by the Darwinia Msgport? - -To find out which networks are currently compatible with the Darwinia Msgport, you can view the list of supported networks **[here](../msgport/networks.md)**. The Darwinia core team is actively working to expand this list and connect additional networks. Keep an eye on updates to stay informed about new integrations. - -## What are the network requirements to support Darwinia Msgport? - -The primary requirement for a network to support the Darwinia Msgport is EVM (Ethereum Virtual Machine) compatibility. This is because the Msgport protocol operates entirely on smart contracts that are built for the EVM environment. - -## How is the cross-chain message fee is calculated? - -The msgport interfaces operate independently of the specific messaging protocols, each of which determines the cross-chain message fee differently. For details on ORMP's fee calculation, please refer to the [ORMP Fee](../msgport/messaging-protocols/ormp.md#cross-chain-fee). \ No newline at end of file diff --git a/docs/msgport/glossary.md b/docs/msgport/glossary.md deleted file mode 100644 index d003a06..0000000 --- a/docs/msgport/glossary.md +++ /dev/null @@ -1,13 +0,0 @@ -# Msgport Glossary - -## Port - -The "port" is a fundamental concept in the msgport protocol, designating the access point where users or applications directly interact by sending or receiving messages. It is a pivotal element of the protocol's infrastructure. Each port is represented by an independent smart contract with a predefined address and can be uniquely identified by a combination of the chain_id and the port address. - -## PortRegistry - -Once the concept of a "port" is clear, it becomes easier to comprehend the role of the PortRegistry. This registry acts as a catalog for all ports that are recognized by a particular blockchain, and it is administered by a decentralized body known as **MsgDao**. Each port listed has to pass through a meticulous process of audit and registration, which is conducted through governance mechanisms. Upon successful registration, developers of decentralized applications (DApps) can tap into these verified ports to create sophisticated cross-chain applications. This decentralized registry process enhances the transparency and trustworthiness of the messaging infrastructure, empowering developers to integrate these ports into their applications with confidence. For more in-depth information, you're encouraged to review the [contract code](https://github.com/darwinia-network/darwinia-msgport/blob/main/src/PortRegistry.sol). - -## MsgHash - -MsgHash, as the only identifier for a cross-chain message, is returned if the message was successfully sent in the source chain. \ No newline at end of file diff --git a/docs/msgport/interfaces.md b/docs/msgport/interfaces.md deleted file mode 100644 index 6efc430..0000000 --- a/docs/msgport/interfaces.md +++ /dev/null @@ -1,93 +0,0 @@ -# Msgport Interfaces - -## IMessagePort - -The `IMessagePort` interface within the Msgport is crafted to simplify the complexities of underlying cross-chain messaging protocols for dApp developers. It offers a standardized interface to send cross-chain messages across various messaging protocols. The interface includes two critical functions: - -- **`send()`**: Serves as the gateway for users or applications to dispatch cross-chain messages. -- **`fee()`**: Retrieves the necessary fee information for utilizing the **`send()`** function. - -The Msgport layer accommodates a variety of messaging protocols that adhere to this interface, including ORMP, ICM, and XCMP, among others. The code for the interface furnishes detailed explanations of each function's use. - -```solidity linenums="1" title="IMessagePort.sol" -pragma solidity ^0.8.0; - -interface IMessagePort { - error MessageFailure(bytes errorData); - - /// @dev Send a cross-chain message over the MessagePort. - /// @notice Send a cross-chain message over the MessagePort. - /// @param toChainId The message destination chain id. - /// @param toDapp The user application contract address which receive the message. - /// @param message The calldata which encoded by ABI Encoding. - /// @param params Extend parameters to adapt to different message protocols. - function send(uint256 toChainId, address toDapp, bytes calldata message, bytes calldata params) external payable; - - /// @notice Get a quote in source native gas, for the amount that send() requires to pay for message delivery. - /// It should be noted that not all ports will implement this interface. - /// @dev If the messaging protocol does not support on-chain fetch fee, then revert with "Unimplemented!". - /// @param toChainId The message destination chain id. - /// @param toDapp The user application contract address which receive the message. - /// @param message The calldata which encoded by ABI Encoding. - /// @param params Extend parameters to adapt to different message protocols. - function fee(uint256 toChainId, address toDapp, bytes calldata message, bytes calldata params) - external - view - returns (uint256); -} -``` - -## IPortMetadata - -The `IPortMetadata` interface in the Msgport framework is intended to handle essential information regarding each port. It mandates the inclusion of two specific types of data: - -- **`name`**: Acts as a globally unique identifier for the port. -- **`uri`**: Serves as a reference to the location where detailed information about the port is stored, typically pointing to an IPFS link by default. For illustration, consider the [uri](https://ipfs.io/ipfs/bafybeid56lijczlbza2won2fhdjnf6qb7pmscgn7x3yr45kgvxvfjjh3pm) associated with the ORMP as an example. - -This interface enables the Msgport to maintain vital information that applications may need in order to utilize the ports effectively. - -```solidity linenums="1" title="IPortMetadata.sol" -pragma solidity ^0.8.0; - -interface IPortMetadata { - event URI(string uri); - - /// @notice Get the port name, it's globally unique and immutable. - /// @return The MessagePort name. - function name() external view returns (string memory); - - /// @return The port metadata uri. - function uri() external view returns (string memory); -} -``` - -## Application - -The `Application` contract is typically extended by the receiving application on the destination chain. This extension allows the receiving application to incorporate additional validation checks for the information contained in cross-chain messages. To see this implementation in action, you can examine the provided [runnable demo](https://github.com/darwinia-network/msgport-demo). - -```solidity linenums="1" title="Application.sol" -pragma solidity ^0.8.17; - -abstract contract Application { - function _msgPort() internal view returns (address _port) { - _port = msg.sender; - } - - /// @notice The cross-chain message source chainId - function _fromChainId() internal pure returns (uint256 _msgDataFromChainId) { - require(msg.data.length >= 52, "!fromChainId"); - assembly { - _msgDataFromChainId := calldataload(sub(calldatasize(), 52)) - } - } - - /// @notice Get the source chain fromDapp address. - function _xmsgSender() internal pure returns (address payable _from) { - require(msg.data.length >= 20, "!fromDapp"); - assembly { - _from := shr(96, calldataload(sub(calldatasize(), 20))) - } - } -} - -``` \ No newline at end of file diff --git a/docs/msgport/messaging-protocols/lcmp.md b/docs/msgport/messaging-protocols/lcmp.md deleted file mode 100644 index 585f44d..0000000 --- a/docs/msgport/messaging-protocols/lcmp.md +++ /dev/null @@ -1,192 +0,0 @@ -!!! Warning - LCMP protocol served as a foundational prototype and remains in a testing stage, not yet deployed in a live production environment. - - -# Overview - -LCMP, short for Light Client Cross-Chain Messaging Protocol, is a protocol meticulously designed and developed by the Darwinia core team. It is currently being actively utilized within Darwinia's chains. This protocol enables seamless communication between different blockchains by establishing messaging channels between them. - -![msgport-lcmp-1](../../images/msgport-lcmp-1.png) - -The LCMP protocol consists of two layers, as shown in the diagram above. The first layer, known as the truth layer, incorporates the light client functionality. This layer is responsible for ensuring the integrity and validity of the cross-chain messages. The protocol derives its name from this layer, which plays a crucial role in maintaining the trustworthiness of the communication. The second layer of the LCMP protocol is the message layer. This layer is specifically designed to handle various aspects related to cross-chain messages. It takes care of issues such as message formatting, transaction fees, and other relevant considerations. By addressing these concerns, the message layer streamlines the process of sending and receiving cross-chain messages, enhancing the overall efficiency and effectiveness of the protocol. - -## Message Flow - -To facilitate a comprehensive understanding of the message flow, it is important to establish the assumption that the truth layer is functioning as intended. Without a properly functioning truth layer, it becomes impractical to delve into the intricacies of the message layer. This is because the truth layer plays a critical role in providing essential validation services for the message layer. If the truth layer is compromised or broken, it renders the execution of cross-chain messages on the target chain impossible, even if the messages successfully reach their intended destination. - -![msgport-lcmp-2](../../images/msgport-lcmp-2.png) - -Let's break down and expand upon the steps depicted in the diagram: - -1. Dapps in the application layer initiate a cross-chain message transaction by invoking the `send_message(message)` function provided by the Message Layer in the source chain. This function allows Dapps to transmit the desired message across chains, enabling interoperability between different blockchain networks. -2. Upon receiving the cross-chain message transaction, the source chain's message layer performs necessary validations on the message. These validations include checks for staleness or duplication of the message. By conducting these validations, the source chain ensures the integrity and reliability of the cross-chain messaging system. Once the validations are successfully passed, the message is saved in the source chain, making it available for further processing. -3. A crucial role called the "relayer" actively monitors the movement of messages within the source chain. When a new cross-chain message is detected in the source chain, the relayer initiates the process of relaying this message from the source chain to the message layer in the target chain. Acting as a bridge between the two chains, the relayer facilitates the seamless transfer of cross-chain messages, enabling communication and interaction between different blockchain networks. -4. Once the target chain receives the cross-chain message from the relayer, it undergoes a validation process to ensure the authenticity and integrity of the message. It's important to note that some of these validations rely on the truth layer, which helps ensure the accuracy and trustworthiness of the message contents. If the message validations are successfully passed, the cross-chain message information is decoded and subsequently executed in the target chain. At this stage, the message that the Dapp initially sent has been executed in the target chain, regardless of whether it was successful or not. -5. Once the message is executed in the target chain, an event is triggered to inform the relayer. This event serves as a signal for the relayer to confirm the execution result and the latest status back to the source chain. This confirmation process is crucial for the source chain to accurately detect stale or duplicated messages and enables features like message flow control. By confirming the execution result and status, the source chain can maintain an up-to-date view of the cross-chain message's progress and take appropriate actions based on the outcome. -6. Upon receiving the confirm message from the target chain regarding the initial message, the source chain marks the end of the cross-chain message's lifecycle. This signifies the completion of the message's journey across different chains. At a predetermined time, the source chain clears the stored messages, making space for new incoming messages. This process ensures the efficient handling of subsequent cross-chain messages and helps maintain the scalability and performance of the overall system. - -## Message Status - -- `MessageAccepted` - *Message has been accepted and is waiting to be delivered.* -- `MessagesReceived` - *Messages have been received from the bridged chain.* -- `MessageDispathed` - *Message has been executed in the target chain.* -- `MessageDelivered` - *Messages in the inclusive range have been delivered to the bridged chain.* - -## Message Fee - -When discussing cross-chain message protocols, an important aspect to consider is the fee associated with these transactions. The fee calculation process is complex, involving various factors such as the tokens used in the source and target chains, the involvement of third-party entities like relayers, and the mechanism for incentivizing and collecting fees. - -Traditionally, fee systems have relied on integrating with an oracle to provide up-to-date token prices from the market. This information is then used within the message protocol to establish fee logic, including conversions based on the oracle's data. However, this approach has inherent flaws, as integrating an oracle introduces additional vulnerabilities and potential attack vectors. - -To address these challenges, the Darwinia Core team has designed a sub-protocol called FeeMarket. The FeeMarket protocol aims to tackle the issue of cross-chain fees in a different way. It provides a solution that reduces the reliance on oracles and mitigates the associated risks. The Fee Market is a cross-chain protocol that operates as a market-based system, incentivizing relayers to efficiently deliver cross-chain messages. By implementing a profitability mechanism, the Fee Market encourages active participation from relayers, leading to a more robust and sustainable cross-chain transaction system. - -In the context of calculating fees for cross-chain messages, the Fee Market differs from traditional Oracle solutions. Typically, determining the fee involves considering the token value exchange ratio between the source and target chains in real-time, a task often performed by Oracles. However, the Fee Market mechanism eliminates the need for real-time awareness of token value exchange ratios on the blockchain. Instead, it relies on quotes provided by relayers to generate the final fee for cross-chain transactions. This approach allows for flexibility and adaptability, as relayers play a crucial role in determining the fees based on market conditions. The relayer is the third off-chain role of the message carrier, responsible for delivering messages between the source and target chains. Before delivering a message, the relayer calculates its own costs and expected profits by combining the transaction fees of the source and target chains and finally submits its own quote to the fee market. When the fee market has received enough quotes, it selects a suitable quote as the cross-chain fee at that moment according to the pre-defined rules. - -## Design Principles - -- Users use native tokens of the source chain as the only method of cross-chain payment. We believe this approach provides the best user experience, eliminating the need for users to worry about target chain accounts and fees.” -- The cross-chain fees paid by users are generated by the fee market system and the final price quoted by the fee market is influenced by all relayers involved in the delivery of messages throughout the market. -- The cost on the target chain is at the expense of the relayer who claims the handling fee on the source chain with the proof of delivery after delivery is completed successfully. To incentivize relayers, the fee market system should ensure the relayers gain is greater than the cost in long term. If an automatic pricing mechanism is infeasible, relayers should be able to give their offers manually and shoulder the cost of offering. The relayers should be punished if they fail to relay the message as expected. -- Relayers and Users constitute a secondary supply-and-demand market, where quotes rise when relayers number is low and fall when relayers number is abundant. There are no access restrictions for relayers, and anyone can enter. Relayer should evaluate and quote at their own discretion as an economically rational person. An incomplete list of risks that relayers should take into account is as follows: - - Fluctuation in token prices and exchange ratios; - - Time delay between quoting and claiming; - - Loss of staking funds due to software or network failures; - -## Tiered Quotation Mechanism - -> 💡 This approach is suitable for scenarios with lower gas fee on the source chain and shorter finality time. It has better versatility, reliability, and robustness. Such networks include Heco, BSC, Polygon and Darwinia. - -First, the relayers must register in the fee market system and post their quotes based on the reference price and the expected profit on the blockchain at any time. An off-chain pricing system maintains the reference price. Each relayer should lock a sufficient default margin on the chain to guarantee the faithful execution of the deal. - -In this way, a series of quoted prices (price meanings fee per message) come into being in the ascending order on the blockchain. When the user initiates a cross-chain request on the source chain, the lowest n quoted prices are filtered out and the last one is used as the billing price. Those who make these prices are called *Assigned Relayers*. User can send cross-chain messages after paying billing price on the source chain, then wait for message execution on the target chain. The assigned relayers are responsible for ensuring the success of cross-chain message delivery and need to monitor their running relayer clients closely. If a cross-chain message is not executed in the specified time on the target chain, all assigned relayers will be penalised. The reason that we select n relayers as assigned relayers is that we want to have redundancy for executing the message delivery. Note that if the count of relayers in current market are less than n when some users sends cross-chain message, it means the fee market system fails to provide a price for user sending cross-chain message, and the dispatch call user sent on the source chain will simply fail and exit. - -In any time, the message delivery and confirmation relayer can be anyone, do not have be the assigned relayer. However, there is an additional bonus for being an assigned relayer as a reward for guarding the cross-chain messaging service. In order to better manage the responsibilities of the n assigned relayers, each assigned relayer is given a time slot (from the creation of the cross-chain message), meaning that the assigned relayer is obliged to deliver the cross-chain message in the allocated time slot. If a message is supposed to be delivered to the target chain in one of the assigned relayer's time slots, but it is not, the assigned relayer is considered to have acted badly and will be penalised for locked assets, or even removed from the set of assigned relayers. - -### Reward And Slash Rules - -### Key Parameters - -When calculating rewards and penalties, the following parameters are crucial. - -- `DutyRelayersRewardRatio` - *The reward ratio for the assigned relayer.* -- `MessageRelayersRewardRatio` -  *The reward ratio for the message relayer.* -- `ConfirmRelayersRewardRatio` - *The reward ratio for the comfirm relayer.* -- `AssignedRelayerSlashRatio` - *The slash ratio for the unduty assigned relayer.* -- `Slot` - *A fixed block period time to indicate the message confirmed time.* -- `CollateralPerOrder` - *The collateral that is deposited by the relayer for a transaction.* - -### Basic Rules - -After a user sends a cross-chain transaction, the fee market system calculates the penalty or reward according to the time the cross-chain transaction is confirmed, with the following rules: - -- The cross-chain transaction is confirmed before the last block of the n slot. - - As long as the order is confirmed before the last block of the nth slot, we consider it to be delivered on time, and the calculation of rewards and penalties varies depending on when the message is confirmed. - - Suppose the cross-chain message has n slots, the message is confirmed at the m-th slot, and `Pm` denotes the quote price of m-th slot. At this point, the assigned relayers from 0 to m slots will be penalized, and the penalty will be calculated as `AssignedRelayerSlashRatio * CollateralPerOrder`, while the assigned relayers from m to n slots will receive a reward for ensuring the message is completed on time `(DutyRelayersRewardRatio * (fee - Pm)) / (n - m)`. `Pm` plus the penalties for the other assigned relayers mentioned above will be distributed as new rewards to the message delivery relayer and the message confirm relayer, where the message delivery relayer receive the `MessageRelayersRewardRatio` of this reward, the message confirm relayer gets the `ConfirmRelayersRewardRatio` of this reward. The rest of the fee will be given to treasury. - -- The cross-chain transaction is confirmed after the last block of the n slot. - - We believe that this cross-chain transaction is severely delayed, in which case all assigned relayers will be heavily penalized by deducting the `AssignedRelayerSlashRatio` of the `CollateralPerOrder` and calculating an additional penalty amount based on the delay time. These penalty amounts, plus the cross-chain fees paid by users, will be distributed as new rewards to the message delivery relayer and the message confirm relayer, where the message delivery relayer receive the `MessageRelayersRewardRatio` of this reward, the message confirm relayer gets the `ConfirmRelayersRewardRatio` of this reward. - - -The following diagram shows how rewards are distributed: - -```bash - assigned offensive relayers collateral - | |---> messaage delivery relayer - | | - |- slot price + slot offensive slash(may have) = message reward --> | - | | -message fee - |---> message confirm relayer - | ---> treasury - | | - |- message surplus -| - | - ---> slot duty rewards -> assigned duty relayers -``` - -### An example - -1. Assume that relayers `R1`, `R2`, `R3`, `R4` and `R5` have registered with the fee market and are all running relayer clients capable of delivering messages with quote prices of `P1=10`, `P2=20`, `P3=30`, `P4=40` and `P5=50` and are registered with a locked asset of `300`. -2. Assume that the total number of assigned relayers specified by the fee market system is `3` (default). In this case, the fee market will generate a cross-chain fee of `30` (10 < 20 < 30 < 40 < 50) and the set of assigned relayers is `R1, R2, R3`. -3. Assume that the slot value is equal to `50` blocks and `CollateralPerOrder` is equal to `100` in the fee market runtime. - -In this case, suppose the source chain receives a cross-chain message at height `100` and the user pays a cross-chain fee of `30`. After the source chain receives the message, the fee market assigns `R1, R2 and R3` as the assigned relayers for the message, respectively, and their corresponding time slots are `(100, 150)`, `(150, 200)`, `(200, 250)` - -After that, all relayers clients will observe the message in the source chain and deliver it to the target chain first. - -The slash, reward analysis is divided into two cases. - -- *the message in time (confirmed before the end of the 3rd assigned relayer's slot)* - - Confirmed at block `110(the first slot)` - - No assigned relayers will be slashed in this case. - - Reward Summary: - - - To assigned relayers (R1, R2, R3): `(DutyRelayersRewardRatio * (30 - 10)) / 3 = 1` - - To treasury: `30 - 10 - 1 * 3 = 17` - - To message delivery relayer: `10 * MessageRelayersRewardRatio = 8` - - To message confirm relayer: `10 * ConfirmRelayersRewardRatio = 2` - - Confirmed at block `160(the second slot)` - - Since the message is confirmed at the second slot, the first assigned relayer will be slashed. - - Slash Summary: - - - R1: `100 * AssignedRelayerSlashRatio = 20` - - Reward Summary: - - - To assigned relayers (R2, R3) = `(DutyRelayersRewardRatio * (30 - 20)) / 2 = 1` - - To treasury: `30 - 20 - 1 * 2 = 8` - - To message delivery relayer: `(20 + 20) * MessageRelayersRewardRatio = 32` - - To message confirm relayer: `(20 + 20) * MessageRelayersRewardRatio = 8` - - Confirmed at block `210(the third slot)` - - Since the message is confirmed at the third slot, the first two assigned relayer will be slashed. - - Slash Summary: - - - R1: `100 * AssignedRelayerSlashRatio = 20` - - R2: `100 * AssignedRelayerSlashRatio = 20` - - Reward Summary: - - - To assigned relayers (R3) = `(DutyRelayersRewardRatio * (30 - 30)) / 1 = 0` - - To treasury: `30 - 30 - 0 = 0` - - To message delivery relayer: `(10 + 20 * 2) * MessageRelayersRewardRatio = 56` - - To message confirm relayer: `(10 + 20 * 2) * MessageRelayersRewardRatio = 14` -- *the message times out (confirmed after the end of the 3rd assigned relayer's slot)* - - Confirmed at block `260(Out of slot)` - - The message is confirmed out of slot 10 blocks, all the assigned relayer will be slashed. - - Slash Summary: - - - R1: `100 * AssignedRelayerSlashRatio + 10 * 2 = 40` - - R2: `100 * AssignedRelayerSlashRatio + 10 * 2 = 40` - - R3: `100 * AssignedRelayerSlashRatio + 10 * 2 = 40` - - Reward Summary: - - - To assigned relayers: `0` - - To treasury: `0` - - To message delivery relayer: `(30 + 40 * 3) * MessageRelayersRewardRatio = 120` - - To message confirm relayer: `(30 + 40 * 3) * MessageRelayersRewardRatio = 30` - -## Implementations - -Here are the two implementations of the LCMP that we discussed: - -- [Solidity LCMP](https://github.com/darwinia-network/darwinia-messages-sol) - - This implementation achieves the truth and message layer using smart contracts written in Solidity. It provides cross-chain capabilities for chains that are Ethereum Virtual Machine (EVM) compatible. By leveraging the power of smart contracts, the Solidity LCMP enables secure and reliable cross-chain communication between different EVM-compatible chains. - -- [Substrate LCMP](https://github.com/darwinia-network/darwinia-messages-substrate) - - This implementation achieves the truth and message layer using a substrate pallet written in Rust. It provides interaction capabilities for parachains and solo chains within the Polkadot system. It allows chains to send and receive messages, exchange data, and perform operations across the Polkadot ecosystem. - - -These two implementations cater to different blockchain ecosystems and provide cross-chain capabilities tailored to their specific requirements. The Solidity version focuses on EVM-compatible chains, while the Substrate version targets the Polkadot system, enabling interaction between various chains in that network. diff --git a/docs/msgport/messaging-protocols/ormp.md b/docs/msgport/messaging-protocols/ormp.md deleted file mode 100644 index 16514df..0000000 --- a/docs/msgport/messaging-protocols/ormp.md +++ /dev/null @@ -1,102 +0,0 @@ -# ORMP - -ORMP stands for Oracle Relayer Messaging Protocol. It is an omni-chain messaging protocol that can be used to build decentralized applications, or Dapps, that operate across multiple blockchains with minimal effort for developers. It's named after the two important roles involved in message cross-chaining: - -- The Oracle - - In this context refers to any source of credible off-chain data. In ORMP, this data refers specifically to the root of an incremental merkle tree composed of cross-chain messages. We refer to this as the `message root` or `msgroot` for short. The message root is used to verify the authenticity of the cross-chain messages. The Oracle can either be a traditional off-chain data service, or a data feed based on the light client. Both of these methods can be used to provide the message root of another chain. - -- The Relayer - - It’s an off-chain piece of software that's responsible for taking messages from one blockchain and relaying them to another. It queries the source chain to find messages that have not yet been relayed, and then relays the message and its proof to the target chain. Once the target chain receives the message, along with the msg_root provided by the Oracle, the target channel can verify the authenticity of the message and process it further if it is found to be valid. - - -These two roles play a vital role in the entire process of sending, verifying, and receiving messages. - -## Features - -- The cross-chain application provides the option to choose a different Oracle and Relayer if the user does not trust the ones provided by the official team. -- Messages are stored in an incremental Merkle tree, and the target chain relies on the tree root to validate the legitimacy of the received message. -- The protocol does not guarantee the ordering of messages. However, the application has the option to maintain a nonce or a unique identifier to ensure that messages are received in the correct order, if ordering is necessary. This allows for ordered delivery of messages, even if the protocol itself doesn't provide that guarantee. - -## Messaging Design - -![msgport-ormp-1](../../images/msgport-ormp-1.png) - -### Raw Message Structure - -Cross-chain message passing involves wrapping the source data with additional information and transmitting it via a logic channel over the cross-chain network. The accurate structure of the Message to be transmitted is defined as follows: - -```solidity linenums="1" -struct Message { - address channel; // The messages channel to another chain. - uint256 index; // The leaf index lives in channel's incremental mekle tree. - uint256 fromChainId; // The source chain's chain id. - address from; // The application address in the source chain. - uint256 toChainId; // The target chain's chain id. - address to; // The application address in the target chain. - uint256 gasLimit; // The gas limit for destination application used. - bytes encoded; // The eth-abi encoded message payload. -} -``` - -Please be aware that within the channel, all messages are organized in an incremental Merkle tree. The channel is also tasked with receiving and distributing messages, as well as overseeing the management of the message root and its status. - -!!! note - An [incremental Merkle Tree](https://arxiv.org/abs/2105.06009) is a [Merkle Tree](https://en.wikipedia.org/wiki/Merkle_tree) of fixed depth where each leaf start as a zero value, and non-zero values are added by replacing the zero leaves starting from the left-most leaf to the right-most leaf one-by-one. - **The Incremental Merkle Tree is a gas efficient Merkle Tree.** - -### Message Sending Flow - -1. The cross-chain application, built on the msgport interface **[IMessagePort](../interfaces.md#imessageport)**, invokes the **`send(from, toChainId, to, gasLimit, encoded_call)`** method of the ORMP. This method is a payable method, meaning it requires the payment of a specific fee to execute. The fee structure is further explained below. -2. Upon receiving the message, the ORMP contracts store it in an Incremental Merkle Tree, emit the `MessageAccepted` event and return msgHash to the sender as the an identifier for that message. -3. The ORMP contracts then invoke the specified relayer and oracle that have been previously registered with the protocol, emitting the `OracleAssigned` and `RelayerAssigned` event to signal the start of their respective tasks. - -Once these two steps are completed, the message sending process is considered finished. - -### Message Relaying Flow - -The message relaying consists of two crucial roles: the relayer and the oracle service. These components continuously monitor the on-chain ORMP events to determine if there are new tasks assigned to them. - -- When the relayer detects a new event, it retrieves the corresponding MessageAccepted event and extracts detailed information about the message from the ORMP contract. It then constructs a message proof using the incremental tree in the corresponding channel of the ORMP. The relayer invokes the `relay(Message calldata message, bytes calldata proof)` method on the relayer contract on the target chain, completing the relay of the message and its proof. -- When the oracle detects a new event, the oracle nodes fetch the corresponding `msg_root` which contains the message. They sign the `msg_root` and send it to a specific multisig contract, which collects all the oracle node signatures. Once the multisig contract gathers enough signatures (typically 3/5), the oracle network triggers the setting of the `msg_root` to the oracle component in the ORMP contracts, completing the relay of the `msg_root`. - -For the message to be executed in the ORMP target chain contracts, it requires both the message payload, proof, and a valid oracle `msg_root`. - -### Message Receiving Flow - -When the `relay` method of the target chain contract is invoked, it performs the following validations: - -- Verifies that the sender (relayer) is registered. -- Ensures the proof corresponds with the `msg_root`. -- Confirms that the message's `to` field matches the destination `chainId`. -- Checks whether the message has already been dispatched. - -If the validation is successful, the message is then sent to the corresponding user application. Unless an exception occurs, the user contract's method is invoked to complete the cross-chain task associated with the message. At this point, we can consider the cross-chain message to have reached its destination. - -## Cross-chain Fee - -The fee for cross-chain messaging is paid in the native token of the source chain. The application can retrieve the cross-chain fee by calling the **`fee`** function in the **[IMessagePort](../interfaces.md#imessageport)** interface. - -$$ -Fee = OracleFee + RelayingFee -$$ - - -The total cross-chain fee consists of two parts: the oracle fee and the relayer fee. The oracle fee covers the cost of the message root oracle service. The relayer fee includes both the fee for relaying the message and the fee for executing the message on the target chain. If the fee paid exceeds the actual required fee, the excess amount will be refunded to the application. - -### OracleFee - -The fee for an oracle on a specific chain is determined, see the [fee page](https://github.com/darwinia-network/ORMP/blob/main/script/input/1/fee.c.json#L2). - -### RelayerFee - -The relayer fee is composed of the execution fee and the payload fee, with various factors influencing the calculation as detailed on the [fee page](https://github.com/darwinia-network/ORMP/blob/main/script/input/1/fee.c.json#L10). - -$$ -ExecutionFee = dstGasPriceInWei * (baseGas+gasLimit) * dstPriceRatio -$$ - -$$ -PayloadFee = gasPerByte * size * dstGasPriceInWei * dstPriceRatio -$$ \ No newline at end of file diff --git a/docs/msgport/messaging-protocols/overview.md b/docs/msgport/messaging-protocols/overview.md deleted file mode 100644 index fbe8124..0000000 --- a/docs/msgport/messaging-protocols/overview.md +++ /dev/null @@ -1,17 +0,0 @@ -# Overview - -The cross-chain mcessage protocol serves as the underlying technology for cross-chain applications. It acts as a middleman, encapsulating the differences between various blockchains and providing easier support for building cross-chain applications. This protocol functions similarly to an operating system, which acts as a mediator between the machine and users, simplifying the interaction and enhancing compatibility. By leveraging this protocol, developers can seamlessly integrate different blockchains and unlock the full potential of cross-chain functionality. - -## Design principles - -- **Guaranteed Delivery:** The protocol must ensure that when a message is successfully committed on the source chain, it will be delivered to the target chain as long as both chains are actively producing blocks. This guarantees that important information is reliably transmitted between chains. -- **Trustless Interoperability:** Users can confidently interact with our system without having to trust any individual or party to act honestly. The protocol must ensure that transactions cannot be exploited by bad actors. This enhances the security and reliability of cross-chain communication. -- **Flexible Message Structure:** The protocol allows messages to be encoded and decoded in any desired way. This flexibility removes the complexity of building chain-specific integrations, making it easier to send messages across different blockchains. - -## Current supported protocols - -| Protocol | Description | -| -------- | ----------- | -| [ORMP](./ormp.md) | Oracle Relayer Messaging Protocol, based on the Oracle mechanism, as darwinia msgport's default messaging protocol. | -| [XCMP](./xcmp.md) | XCMP, which is based on Polkadot XCM, is on our [Roadmap](../../ecosystem.md#roadmap) for support. | -| [LCMP](./lcmp.md) | Light Client Cross-Chain Messaging Protocol, used for years in Darwinia, currently replaced by ORMP. | \ No newline at end of file diff --git a/docs/msgport/messaging-protocols/xcmp.md b/docs/msgport/messaging-protocols/xcmp.md deleted file mode 100644 index 1b4a9ad..0000000 --- a/docs/msgport/messaging-protocols/xcmp.md +++ /dev/null @@ -1,7 +0,0 @@ -# XCMP - -XCMP, or [Cross-Consensus Message Passing](https://wiki.polkadot.network/docs/learn-xcm), is a crucial technology for the Polkadot network. It makes it possible for the different blockchains within Polkadot, known as parachains, to talk to each other securely and without trouble. This is a big win for working together across the network. But sometimes, these parachains want to reach out beyond Polkadot, especially to talk with Ethereum's blockchain. To do this, they can't use XCMP and need a different kind of messaging bridge. - -Enter Darwinia. This network is tailored to fill this gap. It understands XCMP for communication within Polkadot and also speaks the language of Ethereum's blockchain (thanks to its compatibility with the EVM - Ethereum Virtual Machine). On top of that, Darwinia uses something called [Msgport](../overview.md), which is like an extra feature that makes this cross-chain conversation even smoother. It's like having a translator who's fluent in both communities' languages, making Darwinia the go-to connector for Polkadot parachains that want to interact with Ethereum's world. - -The support for XCMP within Msgport is a highly anticipated feature that our core development team is actively working on. It's on our to-do list and we plan to roll it out soon, so stay tuned for this promising update. \ No newline at end of file diff --git a/docs/msgport/networks.md b/docs/msgport/networks.md deleted file mode 100644 index 923ce18..0000000 --- a/docs/msgport/networks.md +++ /dev/null @@ -1,5 +0,0 @@ -# Supported Network - -The [Darwinia Msgport](../msgport/overview.md) is a robust and reliable communication protocol that has been deployed on various blockchains, including Ethereum and Arbitrum. This protocol has undergone careful revisions to enhance its developer and user-friendliness. - -You can find the comprehensive list of supported networks [here](https://github.com/darwinia-network/darwinia-msgport/blob/main/SUPPORTED.md). Please note that the specific port contract address is the same across all supported networks. \ No newline at end of file diff --git a/docs/msgport/overview.md b/docs/msgport/overview.md deleted file mode 100644 index bcc9279..0000000 --- a/docs/msgport/overview.md +++ /dev/null @@ -1,25 +0,0 @@ -# Overview - -In the evolving landscape of blockchain technology, the need for interoperability and seamless communication between diverse blockchains has never been more critical. Msgport, a groundbreaking initiative by Darwinia, stands at the forefront of this challenge, offering a robust solution for cross-chain messaging. With a focus on facilitating effortless asset and information transfer across blockchains, Msgport is revolutionizing the way applications communicate in web 3.0. - -## Core Components and Innovations -The Darwinia Msgport encompasses a collection of smart contracts that outline standardized interfaces for facilitating a cross-chain messaging protocol. - -At the heart of this system is the core interface, [IMessagePort](../msgport/interfaces.md#imessageport), which is designed with flexibility to support various implementations. - -![msgport-overview-1](../images/msgport-overview-1.png) - -Highlighting Msgport's versatility are its flagship integrations: - - - [ORMP](../msgport/messaging-protocols/ormp.md): Oracle Relayer Messaging Protocol leverages chain-independent components, such as oracles and DApp-preferred relayers, to verify cross-chain messages. This approach integrates diverse verification mechanisms, ensuring robust and flexible cross-chain communication. - - [LCMP](../msgport/messaging-protocols/lcmp.md): Light Client Cross-Chain Messaging Protocol employs blockchain consensus mechanisms and light clients as decentralized verifiers. This ensures the integrity and accuracy of message verification across different blockchains, fostering a secure and trustless environment for message passing. - - [XCMP](../msgport/messaging-protocols/xcmp.md): Developed by Polkadot, Cross-Consensus Message Passing facilitates seamless messaging between various parachains within the Polkadot network. Messages are exchanged directly by parachains, relayed and verified by the relay chain, exemplifying efficient inter-parachain communication and interoperability. - -These implementations underscore Msgport's commitment to fostering interoperability, ensuring that assets and information can navigate the complex landscape of blockchain technology smoothly. - -## Integration and Understanding -For developers and applications eager to leverage the power of Msgport, the journey begins with the [Msgport Workflow Documentation](../msgport/workflow.md) and a series of comprehensive [Tutorials](../msgport/tutorial/remix-demo.md). These resources are meticulously crafted to demystify the complexities of Msgport, offering a clear path to integration. From foundational knowledge to step-by-step guides, developers can expect a seamless onboarding experience, enabling them to harness the full potential of cross-chain messaging. - -## Embracing the Future - -As the digital world continues to evolve, Msgport stands as a beacon of innovation, guiding the way towards a more interconnected and efficient blockchain ecosystem. Whether you are looking to bridge assets or enhance the capabilities of your blockchain application, Msgport offers the tools and support needed to transcend traditional boundaries and embrace the future of cross-chain communication. diff --git a/docs/msgport/scan.md b/docs/msgport/scan.md deleted file mode 100644 index 2f5aa45..0000000 --- a/docs/msgport/scan.md +++ /dev/null @@ -1,3 +0,0 @@ -# Msgport Scan - -Navigating through the multiple stages of cross-chain message transmission can be time-consuming as messages are delivered and processed by the receiving chain. Having a mechanism to track message status is essential for identifying whether they have been successfully dispatched or have encountered failures. For this purpose, we offer a user-friendly message explorer tool [Msgport Scan](https://msgscan.darwinia.network/) that enables the searching and viewing of message statuses and outcomes. \ No newline at end of file diff --git a/docs/msgport/troublesome.md b/docs/msgport/troublesome.md deleted file mode 100644 index 2fd9f95..0000000 --- a/docs/msgport/troublesome.md +++ /dev/null @@ -1 +0,0 @@ -TBD \ No newline at end of file diff --git a/docs/msgport/tutorial/remix-demo.md b/docs/msgport/tutorial/remix-demo.md deleted file mode 100644 index ed08f0c..0000000 --- a/docs/msgport/tutorial/remix-demo.md +++ /dev/null @@ -1,115 +0,0 @@ -# Pangolin > Sepolia Remix Demo - -In this guide, we'll walk you through the process of **sending cross-chain messages from the Darwinia Pangolin testnet to the Ethereum Sepolia testnet** using the Darwinia msgport protocol with Remix. No extensive smart contract development expertise is necessary — as long as you're familiar with deploying and interacting with Solidity smart contracts in Remix, you'll be able to follow along. Let's dive in! - -## Prerequisites - -### Get Pangolin Test Token - -Before we proceed, it's important to understand that in our cross-chain communication, the Pangolin network serves as the source chain while the Sepolia network acts as the destination chain. It's crucial to have this distinction in mind. According to the msgport design, the fee for sending a cross-chain message is paid using the source chain's native token, which in this case is the Pangolin testnet token. Therefore, you'll need to acquire some test tokens beforehand. To do so, please use [the provided faucet](https://www.notion.so/Pangolin-Chain-1e9ac8b09e874e8abd6a7f18c096ca6a?pvs=21) and ensure you add the Pangolin network to your Ethereum wallet, such as MetaMask. - -### The TestReceiver Contract - -For ease of understanding, we'll be working with an existing contract on the Sepolia network named **`TestReceive`**. You can find the contract details at [Sepolia Etherscan](https://sepolia.etherscan.io/address/0xb115b479ef7cbaeae5a69aae93adb0287adaa32c#code). The contract has a straightforward design; it includes a variable named **`sum`** and offers a method to increment its value. - -```solidity linenums="1" title="TestReceiver.sol" - -pragma solidity ^0.8.17; - -import "lib/darwinia-msgport/src/user/Application.sol"; - -contract TestReceiver is Application { - event DappMessageRecv(uint256 fromChainId, address fromDapp, address localPort, uint256 num); - - // local port address - address public immutable PORT; - - uint256 public sum; - - constructor(address port) { - PORT = port; - } - - /// @notice You could check the fromDapp address or messagePort address. - function addReceiveNum(uint256 num) external { - uint256 fromChainId = _fromChainId(); - address fromDapp = _xmsgSender(); - address localPort = _msgPort(); - require(localPort == PORT); - sum += num; - emit DappMessageRecv(fromChainId, fromDapp, localPort, num); - } -} -``` - -The contract at address **`0xb115B479ef7cBAEae5a69Aae93ADb0287ADaA32c`** will serve as the destination in this tutorial. We will demonstrate how to increase the **`sum`** variable by calling the **`addReceiveNum(uint256 num)`** function through a cross-chain message from the Pangolin network in the upcoming steps. - -## Send Message From Pangolin - -### Prepare The TestSender Contract - -Create a new Solidity file named **`TestSender.sol`** and copy the contract code provided into it. Ensure that it compiles successfully without any errors. - -```solidity linenums="1" title="TestSender.sol" -// SPDX-License-Identifier: GPL-3.0 - -pragma solidity ^0.8.17; - -import "https://github.com/darwinia-network/darwinia-msgport/blob/main/src/interfaces/IMessagePort.sol"; - -contract TestSender { - event DappMessageSent(address localPort, bytes message); - - // local port address - address public immutable PORT; - - constructor(address port) { - PORT = port; - } - - function send(uint256 toChainId, address toDapp, bytes calldata message, bytes calldata params) external payable { - IMessagePort(PORT).send{value: msg.value}(toChainId, toDapp, message, params); - emit DappMessageSent(PORT, message); - } -} - -``` - -![msgport-tutorial-remix-1](../../images/msgport-tutorial-remix-1.png) - -### Deploy The TestSender - -After successfully compiling **`TestSender.sol`**, the next step is to deploy it on the Pangolin testnet. Switch your wallet to the Pangolin network, if you need information on how to do this, consult the [network details](../../evm/chains/pangolin.md#network-info). The contract requires a parameter for the constructor **`address port`**, which is the address of the ORMP port, a constant across all networks. Enter **`0x0000000005d961F950adA391C1511c92bbc64D9F`** as the parameter and click the deploy button to deploy the contract on the Pangolin testnet. To monitor the transaction status, you may also visit the [Pangolin Subscan](https://pangolin.subscan.io/). - - -![msgport-tutorial-remix-2](../../images/msgport-tutorial-remix-2.png) - -### Send Message - -![msgport-tutorial-remix-3](../../images/msgport-tutorial-remix-3.png) - -The most thrilling part of the process is invoking the **`send(uint256 toChainId, address toDapp, bytes calldata message, bytes calldata params)`** method on the TestSender contract, which will initiate the cross-chain message transmission. The parameters for this call are somewhat complex, so let's break them down for clarity: - -1. value: `2000000000000000000` - - The cross-chain message fee. For the purpose of this demonstration, we'll employ a hardcoded cross-chain message fee that exceeds the normal rate to ensure reliability. In practical scenarios, the fee should be determined by the [msgport API](https://www.notion.so/Msgport-API-a702936b4a8047bcb4f6bf95154b8809?pvs=21). -2. toChainId: **`11155111`** - - The Sepolia chain ID. -3. toDapp: **`0xb115B479ef7cBAEae5a69Aae93ADb0287ADaA32c`**, - - The address of the existing TestReceiver contract on Sepolia. -4. message: **`0x45847e25000000000000000000000000000000000000000000000000000000000000000a`** - - This is the encoded function call for **`addReceiveNum(uint256)`**. For example, if you want to add the number 10, the encoded message is . -5. params:`0x000000000000000000000000000000000000000000000000000000000000b20f000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000600000000000000000000000000000000000000000000000000000000000000000` - - This is the specific encoding required by the [msgport API](https://www.notion.so/Msgport-API-a702936b4a8047bcb4f6bf95154b8809?pvs=21) for additional message parameters. The example provided is the result you would obtain from the API for the given inputs. - -After setting up the required parameters, proceed to click the transact button to execute the **`send`** method, which will send the cross-chain message to Sepolia. Remember to note down the transaction hash `0x1fb1faa75c25ac00e5edb3fdff20b5d5bb2d4969576fc375a5855d789a2d5511` that appears in the Remix debug panel. We'll use this hash to track the status of the cross-chain operation in the following step. - -## Check Message Status - -A [msgport scan](https://www.notion.so/Msgport-Scan-20e10e1727de4b07baaee0c7e1e3f627?pvs=21) available to monitor the status of cross-chain messages, offering the ability to index messages by either the transaction hash or the msghash. Typically, querying with the transaction hash is the most convenient approach. - - -![msgport-tutorial-remix-4](../../images/msgport-tutorial-remix-4.png) - -## Check In The TestReceiver - -When the message status indicator turns green and shows **success**, it signifies that the cross-chain message process has been completed. At this point, you can verify the **`TestReceive`** contract to confirm that the **`sum`** value has incremented, or you can examine the [contract's events](https://sepolia.etherscan.io/address/0xb115b479ef7cbaeae5a69aae93adb0287adaa32c#events) for confirmation. \ No newline at end of file diff --git a/docs/msgport/tutorial/script-demo.md b/docs/msgport/tutorial/script-demo.md deleted file mode 100644 index 08be975..0000000 --- a/docs/msgport/tutorial/script-demo.md +++ /dev/null @@ -1,7 +0,0 @@ -# Pangolin > Sepolia Script Demo - -Hello, and welcome! Grasping the intricacies of cross-chain messaging protocols can be challenging. If you're someone who learns best through hands-on experience, you're in luck! We've created a runnable demo just for you, designed to simplify and demystify the process of cross-chain communication. - -This demo provides a practical way to see cross-chain messaging in action. You can access the demo at [msgport-demo](https://github.com/darwinia-network/msgport-demo). Follow the README to walk through sending a cross-chain message from the Pangolin testnet to the Sepolia network. It's a tailored experience to help you gain a deeper understanding of how cross-chain messaging works. - -After you've had a chance to explore the demo, we would love to hear your thoughts. Your feedback is invaluable to us, so please don't hesitate to share your experience and any insights you may have. Enjoy your journey through the world of cross-chain messaging! \ No newline at end of file diff --git a/docs/msgport/use-cases/order-xclearing.md b/docs/msgport/use-cases/order-xclearing.md deleted file mode 100644 index 0f5b431..0000000 --- a/docs/msgport/use-cases/order-xclearing.md +++ /dev/null @@ -1,25 +0,0 @@ -# Order XClearing - -Many use cases involve order clearing, such as order book DEXs, swap DEXs, equivalent swap, NFT markets, and more. These use cases can all be extended to cross-chain scenarios. Helix Bridge is one such example. It is a third-party token bridge that allows users to perform cross-chain swaps with liquidity relayers, serving as permissionless order takers and makers, essentially facilitating order based cross-chain equivalent swap. - -For example, [Helix Bridge](https://helixbridge.app/) leverages [Msgport](../overview.md) to do settements after users taking orders of liquidity relayer. Msgport can deliver messages indicating that whether liquidity relayer fullfill user's order successfullly or not, where truth of messages are verified by the underlining message protocols Msgport are integrating. - -!!! Quote - The advantage of using `Msgport` is that it is very easy to switch between different low-level message layers without making big changes to the code. — Helix Bridge - -## Helix Bridge Introduction - -Compared to [xToken bridge](./xtoken.md), Helix Bridge stands out for its exceptionally low cross-chain fees, enabled by its capacity for batch clearing through Msgport after accumulating several orders. - -The Helix Bridge protocol introduces a permissionless system for liquidity relayers to place orders. When users swap tokens between two chains, they select an order from a liquidity relayer offering favorable terms, including fees and transfer limits. The tokens are then sent to the Helix Bridge contract, where they await being fullfilled by relayer on target chain. Upon detecting a swap event, the liquidity relayer's node initiates the transfer of an equivalent amount of tokens to the user on the target chain, using a clearing contract that records the order match. To clear and withdraw funds from the source chain, the liquidity relayer merely needs to send a message through Msgport from the target chain to clear their matched orders. - -Should a liquidity relayer fail to fulfill the order promptly, a "slasher" can step in to complete the order. This action is recorded in the clearing contracts. Slashers can trigger a claim against the liquidity relayer's penalty reserve by sending penalty-related clearing messages. Settlement occurs when the liquidity relayer attempts to withdraw from the penalty reserve, also through a message-sending process. - -![msgport-token-bridge-1](../../images/msgport-token-bridge-1.png) - -## Summary -Msgport plays a pivotal role in Helix Bridge by enabling efficient batch clearing and communication for liquidity relayers, leading to significantly reduced cross-chain fees. It allows for the seamless execution of orders and the swift resolution of disputes through the intervention of "slashers" when orders are not fulfilled as expected. Beyond token swaps, the flexibility and efficiency of Msgport can be extended to a wide range of use cases in cross chain orders senarios. - -## Reference - -1. https://docs.helixbridge.app/helixbridge/liquidity_node_v3 \ No newline at end of file diff --git a/docs/msgport/use-cases/overview.md b/docs/msgport/use-cases/overview.md deleted file mode 100644 index 67da13c..0000000 --- a/docs/msgport/use-cases/overview.md +++ /dev/null @@ -1,20 +0,0 @@ -# Overview - -Welcome to the Msgport Use Cases Chapter! This section is meticulously crafted to guide you through the multifaceted realm of cross-chain functionalities unlocked by integrating Msgport services. - -When discussing use cases in the context of cross-chain technologies, the prefix "X" or "x" is often used to denote "cross-chain" aspects of a feature or tool. This nomenclature helps in quickly identifying functionalities that are designed to work across different blockchain networks, facilitating interoperability and seamless integration. - -As we explore this area, we'll look into different scenarios that highlight the capabilities of cross-chain technology, among others: - -- [Order XClearing](./order-xclearing.md): -Helix Bridge is a third-party token bridge designed to facilitate cross-chain swaps between users and liquidity relayers, operating on a permissionless basis for both order takers and makers. Through the integration of Msgport, Helix Bridge enhances its cross-chain clearing capabilities, ensuring efficient and seamless cross chain transactions for all participants involved. - -- [XToken](./order-xclearing.md): XToken is a cross-chain token issuance and mapping tool. - -- [XAccount](./xaccount.md): Exploring the concept of cross-chain accounts and their significance in a decentralized environment. - -- [XDAO](./xdao.md): An examination of decentralized autonomous organizations operating across multiple chains, fostering a new era of governance. - -Each topic is designed to expand your knowledge and inspire innovation in the cross-chain space. We highly value your insights and contributions and warmly invite you to propose additional use cases for inclusion. Together, let's embark on a journey to explore the vast potential and unlock new possibilities in the world of cross-chain technology! - -Your proposals and contributions are the keystones that enrich this guide. Let's explore the possibilities together and chart new territories in the cross-chain universe! diff --git a/docs/msgport/use-cases/xaccount.md b/docs/msgport/use-cases/xaccount.md deleted file mode 100644 index 234d980..0000000 --- a/docs/msgport/use-cases/xaccount.md +++ /dev/null @@ -1,7 +0,0 @@ -# XAccount - -XAccount, representing Cross-Chain Abstract Account, embodies a pioneering approach to account abstraction at the cross-chain level. This innovative concept introduces the creation of a counterpart account on the target chain for an existing account on the source chain, which remains under the exclusive control of the original address on the source chain. - -The XAccount DApp significantly simplifies and enhances the user experience by adopting this design of cross-chain abstract accounts. As a refined iteration of Msgport’s cross-chain functionalities, XAccount is meticulously crafted to streamline the process for users involved in cross-chain transactions, making it more accessible and user-friendly. - -The user interface for the XAccount DApp will be available shortly. In the meantime, you can get a preview of the XAccount design through its [protocol implementation and contracts](https://github.com/darwinia-network/darwinia-msgport/tree/main/src/xAccount). It is also seamlessly integrated with the [Safe Modules](https://docs.safe.global/advanced/smart-account-modules), developed on the most secure abstract account framework. \ No newline at end of file diff --git a/docs/msgport/use-cases/xdao.md b/docs/msgport/use-cases/xdao.md deleted file mode 100644 index 4f456a2..0000000 --- a/docs/msgport/use-cases/xdao.md +++ /dev/null @@ -1,7 +0,0 @@ -# XDAO - -XDAO represents Multi-Chain DAO Governance, with DAO standing for Decentralized Autonomous Organizations. Msgport empowers DAOs to establish unified governance mechanisms across multiple chains. - -Organizations like Uniswap, which may operate DApps across several chains, find their governance tokens distributed across different blockchains. Typically, a DAO conducts voting with its governance token on a single chain, making decisions on proposals that, once approved, are to be implemented across other chains. This scenario presents two main challenges: firstly, enabling governance tokens on other chains to participate in the voting, and secondly, implementing proposals across these diverse chains. - -To tackle the first challenge, the DAO's governor contract within voting systems (e.g. [Tally](https://www.tally.xyz/explore)) can be modified to enable cross-chain delegation or the configuration of votes via Msgport. As for the second challenge, proposals can be executed on different chains by creating and utilizing an [xAccount](./xaccount.md). This approach significantly simplifies decision-making and coordination for DAOs, eliminating the complexity of managing operations on multiple chains independently. \ No newline at end of file diff --git a/docs/msgport/use-cases/xtoken.md b/docs/msgport/use-cases/xtoken.md deleted file mode 100644 index 4e9d562..0000000 --- a/docs/msgport/use-cases/xtoken.md +++ /dev/null @@ -1,15 +0,0 @@ -#XToken - -XToken is a cross-chain token issuance and mapping tool. It can be used by issuers on the source/target chains to deploy and construct cross-chain bridge mappings for tokens. Additionally, it serves as a tool for custodian issuers to deploy Custodian DApps, enabling users to cross-chain the mapped tokens supported by that DApp. - -Msgport can be utilized by XToken to facilitate cross-chain issuance after the original token has been locked on the source chain, or to carry out cross-chain unlocking after the xToken has been burned on the target chain. - -References: - -1. [XToken](https://xtoken.helixbridge.app/) - -2. [XToken Docs](https://docs.helixbridge.app/helixbridge/mapping_token) - -3. [XToken Contracts](https://github.com/helix-bridge/contracts/tree/master/helix-contract/contracts/xtoken) - -4. [XToken Monorepo](https://github.com/helix-bridge/xtoken-monorepo) \ No newline at end of file diff --git a/docs/msgport/workflow.md b/docs/msgport/workflow.md deleted file mode 100644 index 7888ce5..0000000 --- a/docs/msgport/workflow.md +++ /dev/null @@ -1,113 +0,0 @@ -# Msgport Workflow - -Within the diverse landscape of today's blockchain technology, each blockchain possesses its unique architecture and set of features. This diversity often results in cross-chain messaging protocols that are multifaceted, involving numerous roles, and can appear daunting to comprehend in terms of message transmission and execution across different chains. - -For dApp developers looking to incorporate these cross-chain messaging protocols into their applications, a solid grasp of the underlying mechanics is crucial. This knowledge becomes particularly important when encountering unexpected issues during development, which can often be resolved with an awareness of how these complex systems operate. - -The purpose of this page is to provide you with a clear understanding of how the Msgport and [ORMP](../msgport/messaging-protocols/ormp.md) messaging protocols facilitate cross-chain interactions. By breaking down these protocols, we aim to demystify the process, making it more accessible for developers needing to integrate cross-chain functionality into their projects. - -## Verifying network support - -Before diving into the integration of the Darwinia Msgport protocol, the initial and critical step is to confirm whether the [Darwinia Msgport supports the network](../msgport/networks.md) you intend to use. If the network is supported, the integration process simplifies significantly, and your focus shifts to learning how to utilize the Msgport contract's capabilities for sending and receiving cross-chain messages. Typically, getting accustomed to these functions could take as little as half a day. - -On the other hand, if the network is not currently supported, your first course of action should be to [reach out to the Darwinia team](https://t.me/DarwiniaNetwork) to inquire about potential future support. Alternatively, if you prefer a more hands-on approach, you have the option to develop and deploy the necessary contracts yourself and register them with the PortRegister. - -## Messaging workflow - -!!! note - For those interested in gaining a more in-depth understanding of how Msgport operates, there is a [runnable demo available](https://github.com/darwinia-network/msgport-demo) for reference. This can be a valuable resource to see the message port in action. - -### Find the Port Contract Address - -After verifying that the Darwinia Msgport aligns with your project's objectives, the subsequent step is to locate the port contract address. If you're unfamiliar with the concept of a port contract, you can learn more by visiting **[this link](../msgport/glossary.md#port)**. There are two methods to acquire the appropriate port address: - -1. Check the [Supported Networks list](../msgport/networks.md) for the endpoint. The port addresses are standardized across all networks to enhance clarity and ease of use, and you can easily find this information there. -2. Use the  `get(uint256 chainId, string calldata name)` function to consult the [PortRegistry](../msgport/glossary.md#portregistry) contract. By supplying the chainId and the specific protocol name, you can retrieve the endpoint for the target network. The PortRegistry contract is a detailed ledger of all registered port contracts, providing a trustworthy reference point. - -### Build the receiver application in the target chain - -Integrating Msgport into the receiver application on the target chain is a straightforward process. Simply extend your contract to implement the [Application](../msgport/interfaces.md#application) interface, and then incorporate your business logic into the contract as usual. Below is a demo code snippet for your reference. - -```solidity linenums="1" title="TestReceiver.sol" -pragma solidity ^0.8.17; - -import "lib/darwinia-msgport/src/user/Application.sol"; - -contract TestReceiver is Application { - event DappMessageRecv(uint256 fromChainId, address fromDapp, address localPort, uint256 num); - - // local port address - address public immutable PORT; - - uint256 public sum; - - constructor(address port) { - PORT = port; - REMOTE_DAPP = remoteDapp; - } - - /// @notice You could check the fromDapp address or messagePort address. - function addReceiveNum(uint256 num) external { - uint256 fromChainId = _fromChainId(); - address fromDapp = _xmsgSender(); - address localPort = _msgPort(); - require(localPort == PORT); - sum += num; - emit DappMessageRecv(fromChainId, fromDapp, localPort, num); - } -} -``` - -The **`TestReceiver`** contains a public **`num`** variable and provides an **`addReceiveNum`** function that can be used to increment this value. Next, we will outline the steps for activating this function through Msgport to increase the **`num`** value from a different blockchain. - -### Setting Up the Message Content - -Prior to initiating a cross chain transaction, it's essential to determine the content of the message, which encompasses several key fields required for the message transmission process: - -- **`toChainId`**: This is the identifier of the destination chain where the message will be sent. -- **`toDapp`**: This refers to the contract address of the user application that will receive the message on the destination chain, in this example, the `TestReceiver` address. -- **`message`**: This is the ABI-encoded call data that contains the information or instructions for the receiving contract, in this example, `bytes memory message = abi.encodeCall(TestReceiver.addReceiveNum, 10);` - -### Estimate message fee in native token - -Message fees play a critical role in the design of a cross-chain messaging protocol. They represent not just the cost of incorporating cross-chain functionality into your applications, but they also impact the user experience of your application. A thoughtfully constructed fee mechanism is crucial for success. - -The fee structure for Msgport is implemented through the [Msgport API](https://github.com/darwinia-network/darwinia-msgport-api). For detailed information on the fee design, please refer to the [Msgport API Docs](../msgport/api.md). Additionally, you can explore the [Pangolin > Sepolia Message Demo](../msgport/tutorial/script-demo.md) to see how the fee mechanism is applied in practice. - -### Send message in source chain application - -With the preliminary setup out of the way, you're all set to send your cross-chain message. The process is quite simple—refer to the demo code below for guidance. - -```solidity linenums="1" title="TestSender.sol" -pragma solidity ^0.8.17; - -import "lib/darwinia-msgport/src/interfaces/IMessagePort.sol"; - -contract TestSender { - event DappMessageSent(address localPort, bytes message); - - address public immutable PORT; - - constructor(address port) { - PORT = port; - } - - function send(uint256 toChainId, address toDapp, bytes calldata message, bytes calldata params) external payable { - **IMessagePort(PORT).send{value: msg.value}(toChainId, toDapp, message, params);** - emit DappMessageSent(PORT, message); - } -} -``` - -The line **`IMessagePort(PORT).send{value: msg.value}(toChainId, toDapp, message, params);`** initiates the cross-chain messaging process. Here's a breakdown of its components: - -- **`PORT`**: This is the port contract address you've located in the previous "Find the Port Contract Address" step. -- **`toChainId`**, **`toDapp`**, and **`message`**: These are the variables you've established while preparing the message content, the -- **`msg.value`** and **`params`**: These represent the estimated message fee in the native token, as determined in the "Estimate Message Fee" step. - -By invoking the **`send`** function within the TestSender demo with the parameters you've prepared, your message is transmitted to the specified **`toChainId`** and will be executed by the **`toDapp`** contract on the destination chain. And that's the entire process. - -### Monitor the message status - -The delivery and execution of your message on the target chain may take approximately 5 to 15 minutes. To monitor the status of your message, we offer a scanning tool [Darwinia Messages Explorer](https://msgscan.darwinia.network/) that allows you to track the progress using your sent message's transaction hash or the message hash itself. - diff --git a/mkdocs.yml b/mkdocs.yml index e760146..f5478ee 100644 --- a/mkdocs.yml +++ b/mkdocs.yml @@ -130,88 +130,60 @@ plugins: nav: - Home: "index.md" - - Msgport: - - Overview: "msgport/overview.md" - - Glossary: "msgport/glossary.md" - - Interfaces: "msgport/interfaces.md" - - Workflow: "msgport/workflow.md" - - API Documentation: "msgport/api.md" - - Message Scan: "msgport/scan.md" - - Messaging Protocols: - - Overview: "msgport/messaging-protocols/overview.md" - - ORMP Protocol: "msgport/messaging-protocols/ormp.md" - - XCMP Protocol: "msgport/messaging-protocols/xcmp.md" - - LCMP Protocol: "msgport/messaging-protocols/lcmp.md" - - Supported Networks: "msgport/networks.md" - - Use Cases: - - Overview: "msgport/use-cases/overview.md" - - Order Clearing: "msgport/use-cases/order-xclearing.md" - - XToken Management: "msgport/use-cases/xtoken.md" - - XAccount Operations: "msgport/use-cases/xaccount.md" - - XDAO Functions: "msgport/use-cases/xdao.md" - - Tutorials: - - Hello Message Using Remix: "msgport/tutorial/remix-demo.md" - - Message Script Demo: "msgport/tutorial/script-demo.md" - - FAQs: "msgport/faq.md" - - Troubleshooting: "msgport/troublesome.md" - - EVM+: - - Overview: "evm/overview.md" + - Learn Darwinia: - Chains: - - Overview: "evm/chains/overview.md" - - Darwinia Chain: "evm/chains/darwinia.md" - - Crab Chain: "evm/chains/crab.md" - - Pangolin Chain: "evm/chains/pangolin.md" - - Rollup Testnet: "evm/chains/rollup.md" - - Available Wallets: - - Overview: "evm/wallets.md" + - Overview: "learn/chains/overview.md" + - Darwinia Chain: "learn/chains/darwinia.md" + - Crab Chain: "learn/chains/crab.md" + - Pangolin Chain: "learn/chains/pangolin.md" + - Rollup Testnet: "learn/chains/rollup.md" + - Wallets: "learn/wallets.md" + - Governance: "learn/governance.md" - Ethereum Compatibility: - - Account System: "evm/ethereum-compatibility/account-system.md" - - JSON-RPC APIs: "evm/ethereum-compatibility/jsonrpc.md" - - Gas Compatibility: "evm/ethereum-compatibility/gas.md" - - EVM Tracing: "evm/ethereum-compatibility/evm-tracing.md" + - Account System: "learn/ethereum-compatibility/account-system.md" + - JSON-RPC APIs: "learn/ethereum-compatibility/jsonrpc.md" + - Gas Compatibility: "learn/ethereum-compatibility/gas.md" + - EVM Tracing: "learn/ethereum-compatibility/evm-tracing.md" - Precompiled Contracts: - - Overview: "evm/ethereum-compatibility/precompiles/overview.md" - - Ethereum Precompiles: "evm/ethereum-compatibility/precompiles/ethereum.md" - - Staking Precompile: "evm/ethereum-compatibility/precompiles/staking.md" - - Deposit Precompile: "evm/ethereum-compatibility/precompiles/deposit.md" - - KTON Precompile: "evm/ethereum-compatibility/precompiles/commitment-token.md" - - USDT Precompile: "evm/ethereum-compatibility/precompiles/usdt.md" - - State Storage Precompile: "evm/ethereum-compatibility/precompiles/state-storage.md" - - Dispatch Precompile: "evm/ethereum-compatibility/precompiles/dispatch.md" - - Conviction Voting Precompile: "evm/ethereum-compatibility/precompiles/conviction-voting.md" + - Overview: "learn/ethereum-compatibility/precompiles/overview.md" + - Ethereum Precompiles: "learn/ethereum-compatibility/precompiles/ethereum.md" + - Staking Precompile: "learn/ethereum-compatibility/precompiles/staking.md" + - Deposit Precompile: "learn/ethereum-compatibility/precompiles/deposit.md" + - KTON Precompile: "learn/ethereum-compatibility/precompiles/commitment-token.md" + - USDT Precompile: "learn/ethereum-compatibility/precompiles/usdt.md" + - State Storage Precompile: "learn/ethereum-compatibility/precompiles/state-storage.md" + - Dispatch Precompile: "learn/ethereum-compatibility/precompiles/dispatch.md" + - Conviction Voting Precompile: "learn/ethereum-compatibility/precompiles/conviction-voting.md" - Darwinia Staking: - - Commitment Token: "evm/darwinia-staking/commitment-token.md" - - Staking Pallet: "evm/darwinia-staking/staking.md" - - Deposit Pallet: "evm/darwinia-staking/deposit.md" - - Governance: - - Overview: "evm/governance.md" - - Tutorials: - - Token Transfer: "evm/tutorial/transfer-token.md" - - Staking Guide: "evm/tutorial/staking.md" - - USDT Operations: "evm/tutorial/usdt.md" - - Multisig Wallet Setup: "evm/tutorial/multisig-wallet.md" - - Creating a DAO: "evm/tutorial/create-dao.md" - - Governance: "evm/tutorial/governance.md" - - Smart Contracts: - - Interacting with Web3.js: "evm/tutorial/smart-contract/interact-with-web3js.md" - - Interacting with Ethers.js: "evm/tutorial/smart-contract/interact-with-ethersjs.md" - - Using Hardhat: "evm/tutorial/smart-contract/interact-with-hardhat.md" - - Using Foundry: "evm/tutorial/smart-contract/interact-with-foundry.md" - - Verifying Smart Contracts: "evm/tutorial/smart-contract/verify-contract.md" - - Awesome Tutorial: "evm/tutorial/smart-contract/awesome-tutorial.md" - - Chain Operations: - - Database Snapshot: "evm/tutorial/chain/snapshot.md" - - Running a Collator Node: "evm/tutorial/chain/run-collator-node.md" - - Running an Archive Node: "evm/tutorial/chain/run-archive-node.md" - - Running an EVM Tracing Node: "evm/tutorial/chain/run-evm-tracing-node.md" - - Running a Development Node: "evm/tutorial/chain/run-dev-node.md" - - Running a Relay Chain Testnet: "evm/tutorial/chain/run-relay-chain-testnet.md" + - Commitment Token: "learn/stake/commitment-token.md" + - Staking Pallet: "learn/stake/staking.md" + - Deposit Pallet: "learn/stake/deposit.md" + - FAQs: "learn/faq.md" + - Build In Darwinia: + - Getting Started: + - Token Transfer: "build/getting-started/transfer-token.md" + - Staking: "build/getting-started/staking.md" + - Governance: "build/getting-started/governance.md" + - USDT Operations: "build/getting-started/usdt.md" + - Multisig Wallet: "build/getting-started/multisig-wallet.md" + - Creating a DAO: "build/getting-started/create-dao.md" - Darwinia 1.0 Migration: - - Account Generation: "evm/tutorial/migration/generate-account.md" - - Multisig Account Setup: "evm/tutorial/migration/multisig-account.md" + - Migrate Generate Account: "build/getting-started/migration/generate-account.md" + - Migrate Multisig Account: "build/getting-started/migration/multisig-account.md" + - Build In Darwinia: + - Smart Contracts: + - Interacting with Web3.js: "build/smart-contract/interact-with-web3js.md" + - Interacting with Ethers.js: "build/smart-contract/interact-with-ethersjs.md" + - Using Hardhat: "build/smart-contract/interact-with-hardhat.md" + - Using Foundry: "build/smart-contract/interact-with-foundry.md" + - Verifying Smart Contracts: "build/smart-contract/verify-contract.md" - Indexing Services: - - Using SubQuery: "evm/tutorial/indexer/subquery.md" - - Glossary: "evm/glossary.md" - - FAQs: "evm/faq.md" - - RING Overview: "ring.md" + - Using SubQuery: "build/indexer/subquery.md" + - Node Operator: + - Database Snapshot: "build/chain/snapshot.md" + - Running a Collator Node: "build/chain/run-collator-node.md" + - Running an Archive Node: "build/chain/run-archive-node.md" + - Running an EVM Tracing Node: "build/chain/run-evm-tracing-node.md" + - Running a Development Node: "build/chain/run-dev-node.md" + - RingDAO: "ring.md" - Ecosystem Collaboration: "ecosystem.md"