From 33f7be27fb9709408b9539e3ddc0d0738b9e6ffa Mon Sep 17 00:00:00 2001 From: Erin Shaben Date: Fri, 22 Mar 2024 16:35:37 -0400 Subject: [PATCH 01/26] move cryptoWaitReady into async function --- .../xcm/remote-execution/remote-evm-calls/send.js | 9 +++++---- 1 file changed, 5 insertions(+), 4 deletions(-) diff --git a/.snippets/code/builders/interoperability/xcm/remote-execution/remote-evm-calls/send.js b/.snippets/code/builders/interoperability/xcm/remote-execution/remote-evm-calls/send.js index 0b9973502..5ac95b642 100644 --- a/.snippets/code/builders/interoperability/xcm/remote-execution/remote-evm-calls/send.js +++ b/.snippets/code/builders/interoperability/xcm/remote-execution/remote-evm-calls/send.js @@ -35,12 +35,13 @@ const instr3 = { }; const message = { V3: [instr1, instr2, instr3] }; -// 2. Create Keyring instance -await cryptoWaitReady(); -const keyring = new Keyring({ type: 'sr25519' }); -const alice = keyring.addFromUri(privateKey); const sendXcmMessage = async () => { + // 2. Create Keyring instance + await cryptoWaitReady(); + const keyring = new Keyring({ type: 'sr25519' }); + const alice = keyring.addFromUri(privateKey); + // 3. Create Substrate API Provider const substrateProvider = new WsProvider(providerWsURL); const api = await ApiPromise.create({ provider: substrateProvider }); From fbaede0acc8edd0926c3ce3122632fa258a5ccba Mon Sep 17 00:00:00 2001 From: "mikelberlin.eth" <113072676+mikelberlin@users.noreply.github.com> Date: Mon, 25 Mar 2024 18:06:29 +0100 Subject: [PATCH 02/26] dia.md Need to update our Discord link asap due to a problem with Discord's custom link system --- builders/integrations/oracles/dia.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/builders/integrations/oracles/dia.md b/builders/integrations/oracles/dia.md index 8cbdf7065..e5c866cbb 100644 --- a/builders/integrations/oracles/dia.md +++ b/builders/integrations/oracles/dia.md @@ -281,7 +281,7 @@ To learn how to deploy a randomness-consuming contract on Moonbeam, please refer ## Resources {: #resources } - [Twitter](https://twitter.com/DIAdata_org){target=\_blank} -- [Discord](https://discord.gg/dia-dao){target=\_blank} +- [Discord](https://discord.gg/ZvGjVY5uvs){target=\_blank} - [Website](https://diadata.org/){target=\_blank} - [Docs](https://docs.diadata.org/){target=\_blank} - [Explore data](https://www.diadata.org/app/){target=\_blank} From 3d7a29e1de7687aea4acecf49c65368a08da30d8 Mon Sep 17 00:00:00 2001 From: Erin Shaben Date: Fri, 29 Mar 2024 14:23:22 -0400 Subject: [PATCH 03/26] update moonriver for 2801 --- builders/build/runtime-upgrades.md | 2 +- builders/interoperability/xcm/core-concepts/weights-fees.md | 2 +- variables.yml | 2 +- 3 files changed, 3 insertions(+), 3 deletions(-) diff --git a/builders/build/runtime-upgrades.md b/builders/build/runtime-upgrades.md index 5b459b6da..fc1d896cc 100644 --- a/builders/build/runtime-upgrades.md +++ b/builders/build/runtime-upgrades.md @@ -75,4 +75,4 @@ Not all runtime upgrades are released on each network, as sometimes after releas | [2601](https://forum.moonbeam.network/t/runtime-rt2600-schedule/1372/5){target=\_blank} | - | - | [5474345](https://moonbase.subscan.io/block/5474345){target=\_blank} | | [2602](https://forum.moonbeam.network/t/runtime-rt2600-schedule/1372/13){target=\_blank} | [4977160](https://moonbeam.subscan.io/block/4977160){target=\_blank} | [5638536](https://moonriver.subscan.io/block/5638536){target=\_blank} | [5576588](https://moonbase.subscan.io/block/5576588){target=\_blank} | | [2700](https://forum.moonbeam.network/t/runtime-rt2700-schedule/1441/3){target=\_blank} | [5504531](https://moonbeam.subscan.io/block/5504531){target=\_blank} | [6041969](https://moonriver.subscan.io/block/6041969){target=\_blank} | [5860584](https://moonbase.subscan.io/block/5860584){target=\_blank} | -| [2801](https://forum.moonbeam.network/t/runtime-rt2801-schedule/1616/4){target=\_blank} | - | - | [6209638](https://moonbase.subscan.io/block/6209638){target=\_blank} | +| [2801](https://forum.moonbeam.network/t/runtime-rt2801-schedule/1616/4){target=\_blank} | - | [6411588](https://moonriver.subscan.io/block/6411588){target=\_blank} | [6209638](https://moonbase.subscan.io/block/6209638){target=\_blank} | diff --git a/builders/interoperability/xcm/core-concepts/weights-fees.md b/builders/interoperability/xcm/core-concepts/weights-fees.md index 4dbfad7b9..299d032b8 100644 --- a/builders/interoperability/xcm/core-concepts/weights-fees.md +++ b/builders/interoperability/xcm/core-concepts/weights-fees.md @@ -236,7 +236,7 @@ For each XCM instruction, the weight units are converted to balance units as par | Moonbeam | Moonriver | Moonbase Alpha | |:-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------:|:--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------:|:-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------:| -| [{{ networks.moonbeam.xcm.instructions.wei_per_weight.display }}](https://github.com/moonbeam-foundation/moonbeam/blob/{{networks.moonbeam.spec_version}}/runtime/moonbeam/src/lib.rs#L141){target=\_blank} | [{{ networks.moonriver.xcm.instructions.wei_per_weight.display }}](https://github.com/moonbeam-foundation/moonbeam/blob/{{networks.moonriver.spec_version}}/runtime/moonriver/src/lib.rs#L143){target=\_blank} | [{{ networks.moonbase.xcm.instructions.wei_per_weight.display }}](https://github.com/moonbeam-foundation/moonbeam/blob/{{networks.moonbase.spec_version}}/runtime/moonbase/src/lib.rs#L148){target=\_blank} | +| [{{ networks.moonbeam.xcm.instructions.wei_per_weight.display }}](https://github.com/moonbeam-foundation/moonbeam/blob/{{networks.moonbeam.spec_version}}/runtime/moonbeam/src/lib.rs#L141){target=\_blank} | [{{ networks.moonriver.xcm.instructions.wei_per_weight.display }}](https://github.com/moonbeam-foundation/moonbeam/blob/{{networks.moonriver.spec_version}}/runtime/moonriver/src/lib.rs#L142){target=\_blank} | [{{ networks.moonbase.xcm.instructions.wei_per_weight.display }}](https://github.com/moonbeam-foundation/moonbeam/blob/{{networks.moonbase.spec_version}}/runtime/moonbase/src/lib.rs#L148){target=\_blank} | This means that on Moonbeam, for example, the formula to calculate the cost of one XCM instruction in the reserve asset is as follows: diff --git a/variables.yml b/variables.yml index cc466dbe1..0a0a902e7 100644 --- a/variables.yml +++ b/variables.yml @@ -433,7 +433,7 @@ networks: tracing_tag: moonbeamfoundation/moonbeam-tracing:v0.36.0-2801-7ae4 chain_spec: moonriver block_explorer: https://moonriver.moonscan.io/ - spec_version: runtime-2700 + spec_version: runtime-2801 binary_name: moonbeam min_gas_price: 1.25 block_time: 12 From 289d6c866e9b572186148f7cbaf65c0abaf9bb2c Mon Sep 17 00:00:00 2001 From: Erin Shaben Date: Mon, 1 Apr 2024 23:55:32 -0400 Subject: [PATCH 04/26] fix spacing --- .../substrate-calls/xcm-transactor-precompile.md | 9 +++++---- 1 file changed, 5 insertions(+), 4 deletions(-) diff --git a/builders/interoperability/xcm/remote-execution/substrate-calls/xcm-transactor-precompile.md b/builders/interoperability/xcm/remote-execution/substrate-calls/xcm-transactor-precompile.md index 146f8152f..c4944d8d7 100644 --- a/builders/interoperability/xcm/remote-execution/substrate-calls/xcm-transactor-precompile.md +++ b/builders/interoperability/xcm/remote-execution/substrate-calls/xcm-transactor-precompile.md @@ -87,10 +87,11 @@ The interface varies slightly from version to version. You can find an overview === "Returns" - The transact information for: - - The three XCM instructions associated with the external call execution (`transactExtraWeight`) - - The extra weight information associated with the `DescendOrigin` XCM instruction for the transact through signed extrinsic (`transactExtraWeightSigned`) - - The maximum allowed weight for the message in the given chain + The transact information for: + + - The three XCM instructions associated with the external call execution (`transactExtraWeight`) + - The extra weight information associated with the `DescendOrigin` XCM instruction for the transact through signed extrinsic (`transactExtraWeightSigned`) + - The maximum allowed weight for the message in the given chain ```js [ 173428000n, 0n, 20000000000n ] From c5f38451af6784217bcc143636d27adf7cd2aed7 Mon Sep 17 00:00:00 2001 From: Erin Shaben Date: Tue, 2 Apr 2024 00:18:56 -0400 Subject: [PATCH 05/26] fix spacing --- .../xcm-transactor-precompile.md | 17 +++++++---------- 1 file changed, 7 insertions(+), 10 deletions(-) diff --git a/builders/interoperability/xcm/remote-execution/substrate-calls/xcm-transactor-precompile.md b/builders/interoperability/xcm/remote-execution/substrate-calls/xcm-transactor-precompile.md index c4944d8d7..da777823e 100644 --- a/builders/interoperability/xcm/remote-execution/substrate-calls/xcm-transactor-precompile.md +++ b/builders/interoperability/xcm/remote-execution/substrate-calls/xcm-transactor-precompile.md @@ -88,7 +88,7 @@ The interface varies slightly from version to version. You can find an overview === "Returns" The transact information for: - + - The three XCM instructions associated with the external call execution (`transactExtraWeight`) - The extra weight information associated with the `DescendOrigin` XCM instruction for the transact through signed extrinsic (`transactExtraWeightSigned`) - The maximum allowed weight for the message in the given chain @@ -158,10 +158,11 @@ The interface varies slightly from version to version. You can find an overview === "Returns" - The transact information for: - - The three XCM instructions associated with the external call execution (`transactExtraWeight`) - - The extra weight information associated with the `DescendOrigin` XCM instruction for the transact through signed extrinsic (`transactExtraWeightSigned`) - - The maximum allowed weight for the message in the given chain + The transact information for: + + - The three XCM instructions associated with the external call execution (`transactExtraWeight`) + - The extra weight information associated with the `DescendOrigin` XCM instruction for the transact through signed extrinsic (`transactExtraWeightSigned`) + - The maximum allowed weight for the message in the given chain ```js [ 173428000n, 0n, 20000000000n ] @@ -190,12 +191,10 @@ The interface varies slightly from version to version. You can find an overview - `transactRequiredWeightAtMost` - the weight to buy in the destination chain for the execution of the call defined in the `Transact` instruction. The `transactRequiredWeightAtMost` structure contains the following: - `refTime` - the amount of computational time that can be used for execution - `proofSize` - the amount of storage in bytes that can be used - It should be formatted as follows: - ```js [ INSERT_REF_TIME, INSERT_PROOF_SIZE ] - ``` + ``` - `call` - the call to be executed in the destination chain, as defined in the `Transact` instruction - `feeAmount` - the amount to be used as a fee - `overallWeight` - the total weight the extrinsic can use to execute all the XCM instructions, plus the weight of the `Transact` call (`transactRequiredWeightAtMost`). The `overallWeight` structure also contains `refTime` and `proofSize`. If you pass in the maximum value for a uint64 for the `refTime`, you'll allow for an unlimited amount of weight to be purchased, which removes the need to know exactly how much weight the destination chain requires to execute the XCM @@ -210,9 +209,7 @@ The interface varies slightly from version to version. You can find an overview - `transactRequiredWeightAtMost` - the weight to buy in the destination chain for the execution of the call defined in the `Transact` instruction. The `transactRequiredWeightAtMost` structure contains the following: - `refTime` - the amount of computational time that can be used for execution - `proofSize` - the amount of storage in bytes that can be used - It should be formatted as follows: - ```js [ INSERT_REF_TIME, INSERT_PROOF_SIZE ] ``` From 18ed93d25262689c482645a17ef962067e2ec122 Mon Sep 17 00:00:00 2001 From: Wuzhong <144415646+wuzhong-papermoon@users.noreply.github.com> Date: Tue, 2 Apr 2024 23:59:13 +0800 Subject: [PATCH 06/26] Adding relay data verifier precompile article --- .../precompiles/relay-data-verifier/abi.js | 97 ++++++++++++++++ .../ethers-relay-data-verifier.js | 40 +++++++ .../web3js-relay-data-verifier.js | 49 ++++++++ .../web3py-relay-data-verifier.py | 47 ++++++++ .../relay-data-verifier-parameters.md | 10 ++ .../pallets-precompiles/precompiles/.pages | 1 + .../precompiles/relay-data-verifier.md | 108 ++++++++++++++++++ 7 files changed, 352 insertions(+) create mode 100644 .snippets/code/builders/pallets-precompiles/precompiles/relay-data-verifier/abi.js create mode 100644 .snippets/code/builders/pallets-precompiles/precompiles/relay-data-verifier/ethers-relay-data-verifier.js create mode 100644 .snippets/code/builders/pallets-precompiles/precompiles/relay-data-verifier/web3js-relay-data-verifier.js create mode 100644 .snippets/code/builders/pallets-precompiles/precompiles/relay-data-verifier/web3py-relay-data-verifier.py create mode 100644 .snippets/text/builders/pallets-precompiles/precompiles/relay-data-verifier/relay-data-verifier-parameters.md create mode 100644 builders/pallets-precompiles/precompiles/relay-data-verifier.md diff --git a/.snippets/code/builders/pallets-precompiles/precompiles/relay-data-verifier/abi.js b/.snippets/code/builders/pallets-precompiles/precompiles/relay-data-verifier/abi.js new file mode 100644 index 000000000..f1fa7cf87 --- /dev/null +++ b/.snippets/code/builders/pallets-precompiles/precompiles/relay-data-verifier/abi.js @@ -0,0 +1,97 @@ +[ + { + "inputs": [], + "name": "latestRelayBlockNumber", + "outputs": [ + { + "internalType": "uint32", + "name": "relayBlockNumber", + "type": "uint32" + } + ], + "stateMutability": "view", + "type": "function" + }, + { + "inputs": [ + { + "internalType": "uint32", + "name": "relayBlockNumber", + "type": "uint32" + }, + { + "components": [ + { + "internalType": "bytes32", + "name": "at", + "type": "bytes32" + }, + { + "internalType": "bytes[]", + "name": "proof", + "type": "bytes[]" + } + ], + "internalType": "struct RelayDataVerifier.ReadProof", + "name": "readProof", + "type": "tuple" + }, + { + "internalType": "bytes[]", + "name": "keys", + "type": "bytes[]" + } + ], + "name": "verifyEntries", + "outputs": [ + { + "internalType": "bytes[]", + "name": "values", + "type": "bytes[]" + } + ], + "stateMutability": "nonpayable", + "type": "function" + }, + { + "inputs": [ + { + "internalType": "uint32", + "name": "relayBlockNumber", + "type": "uint32" + }, + { + "components": [ + { + "internalType": "bytes32", + "name": "at", + "type": "bytes32" + }, + { + "internalType": "bytes[]", + "name": "proof", + "type": "bytes[]" + } + ], + "internalType": "struct RelayDataVerifier.ReadProof", + "name": "readProof", + "type": "tuple" + }, + { + "internalType": "bytes", + "name": "key", + "type": "bytes" + } + ], + "name": "verifyEntry", + "outputs": [ + { + "internalType": "bytes", + "name": "value", + "type": "bytes" + } + ], + "stateMutability": "nonpayable", + "type": "function" + } +] \ No newline at end of file diff --git a/.snippets/code/builders/pallets-precompiles/precompiles/relay-data-verifier/ethers-relay-data-verifier.js b/.snippets/code/builders/pallets-precompiles/precompiles/relay-data-verifier/ethers-relay-data-verifier.js new file mode 100644 index 000000000..33561fb6c --- /dev/null +++ b/.snippets/code/builders/pallets-precompiles/precompiles/relay-data-verifier/ethers-relay-data-verifier.js @@ -0,0 +1,40 @@ +import * as fs from 'fs'; // For reading local ABI file +import { ethers } from 'ethers'; // Import Ethers library, to interact with Moonbeam networks +import { ApiPromise, WsProvider } from '@polkadot/api';; // Import Polkadot library, to interact with relay chain + +var ABI= JSON.parse(fs.readFileSync('./RelayChainDataVerifierABI.json')); +const privateKey = 'INSERT_PRIVATE_KEY'; +const precompileAddress = '0x0000000000000000000000000000000000000819'; +const moonbeamURL = 'https://rpc.api.moonbase.moonbeam.network'; +const relayURL = 'wss://frag-moonbase-relay-rpc-ws.g.moonbase.moonbeam.network'; + +// Create Ethers provider and signer +const provider = new ethers.JsonRpcProvider(moonbeamURL); +const signer = new ethers.Wallet(privateKey, provider); +const precompileContract = new ethers.Contract( + precompileAddress, + ABI, + signer +); + +// Create provider for relay chain +const wsProvider = new WsProvider(relayURL); +const api = await ApiPromise.create({ provider: wsProvider }); + +async function run(){ + // Get the storage key for a random account on relay chain + let key = await api.query.system.account.key( + '5CBATpb3yvEM4mhX9Dw3tyuqiWKhq9YBG6ugSbodRUSbodoU' + ) + // Find the latest available block number(relay chain) from moonbeam + let blockNum = await precompileContract.latestRelayBlockNumber() + + // Get the blockHash and storage proof from relay chain + let blockHash = await api.rpc.chain.getBlockHash(blockNum); + let proof = await api.rpc.state.getReadProof([key],blockHash); + + // This tx will be rejected if the verification failed + await precompileContract.verifyEntry(blockNum, proof, key) +} + +await run(); \ No newline at end of file diff --git a/.snippets/code/builders/pallets-precompiles/precompiles/relay-data-verifier/web3js-relay-data-verifier.js b/.snippets/code/builders/pallets-precompiles/precompiles/relay-data-verifier/web3js-relay-data-verifier.js new file mode 100644 index 000000000..d3f3b0d86 --- /dev/null +++ b/.snippets/code/builders/pallets-precompiles/precompiles/relay-data-verifier/web3js-relay-data-verifier.js @@ -0,0 +1,49 @@ +import * as fs from 'fs'; // For reading local ABI file +import { Web3 } from 'web3'; // Import web3js library, to interact with Moonbeam networks +import { ApiPromise, WsProvider } from '@polkadot/api';; // Import Polkadot library, to interact with relay chain + +var ABI= JSON.parse(fs.readFileSync('./RelayChainDataVerifierABI.json')); +const privateKey = 'INSERT_PRIVATE_KEY'; +const precompileAddress = '0x0000000000000000000000000000000000000819'; +const moonbeamURL = 'https://rpc.api.moonbase.moonbeam.network'; +const relayURL = 'wss://frag-moonbase-relay-rpc-ws.g.moonbase.moonbeam.network'; + +// Create Web3js provider and signer +const web3 = new Web3(moonbeamURL); +const precompileContract = new web3.eth.Contract(ABI, precompileAddress) + +// Create provider for relay chain +const wsProvider = new WsProvider(relayURL); +const api = await ApiPromise.create({ provider: wsProvider }); + +const account = web3.eth.accounts.privateKeyToAccount(privateKey); + +async function run(){ + // Get the storage key for a random account on relay chain + const key = await api.query.system.account.key( + '5CBATpb3yvEM4mhX9Dw3tyuqiWKhq9YBG6ugSbodRUSbodoU' + ) + // Find the latest available block number(relay chain) from moonbeam + const blockNum = await precompileContract.methods.latestRelayBlockNumber().call() + + // Get the blockHash and storage proof from relay chain + const blockHash = await api.rpc.chain.getBlockHash(blockNum); + const proof = await api.rpc.state.getReadProof([key],blockHash); + + const callObject = { + to: precompileAddress, + data: precompileContract.methods.verifyEntry(blockNum, proof, key).encodeABI(), + gas: await precompileContract.methods.verifyEntry(blockNum, proof, key).estimateGas(), + gasPrice: await web3.eth.getGasPrice(), + nonce: await web3.eth.getTransactionCount(account.address), + } + + // This tx will be rejected if the verification failed + const tx = await web3.eth.accounts.signTransaction(callObject, account.privateKey); + web3.eth.sendSignedTransaction(tx.rawTransaction) + .on('receipt', console.log) + .on('error', function(error){ console.log(error) }); + +} + +await run(); \ No newline at end of file diff --git a/.snippets/code/builders/pallets-precompiles/precompiles/relay-data-verifier/web3py-relay-data-verifier.py b/.snippets/code/builders/pallets-precompiles/precompiles/relay-data-verifier/web3py-relay-data-verifier.py new file mode 100644 index 000000000..47fc672dc --- /dev/null +++ b/.snippets/code/builders/pallets-precompiles/precompiles/relay-data-verifier/web3py-relay-data-verifier.py @@ -0,0 +1,47 @@ +# Import packages +import json +from substrateinterface import * +from web3 import Web3 +from eth_account import Account + +# Initialize variables +ABI = [{'inputs':[],'name':'latestRelayBlockNumber','outputs':[{'internalType':'uint32','name':'relayBlockNumber','type':'uint32'}],'stateMutability':'view','type':'function'},{'inputs':[{'internalType':'uint32','name':'relayBlockNumber','type':'uint32'},{'components':[{'internalType':'bytes32','name':'at','type':'bytes32'},{'internalType':'bytes[]','name':'proof','type':'bytes[]'}],'internalType':'structRelayDataVerifier.ReadProof','name':'readProof','type':'tuple'},{'internalType':'bytes[]','name':'keys','type':'bytes[]'}],'name':'verifyEntries','outputs':[{'internalType':'bytes[]','name':'values','type':'bytes[]'}],'stateMutability':'nonpayable','type':'function'},{'inputs':[{'internalType':'uint32','name':'relayBlockNumber','type':'uint32'},{'components':[{'internalType':'bytes32','name':'at','type':'bytes32'},{'internalType':'bytes[]','name':'proof','type':'bytes[]'}],'internalType':'structRelayDataVerifier.ReadProof','name':'readProof','type':'tuple'},{'internalType':'bytes','name':'key','type':'bytes'}],'name':'verifyEntry','outputs':[{'internalType':'bytes','name':'value','type':'bytes'}],'stateMutability':'nonpayable','type':'function'}] + +privateKey = 'INSERT_PRIVATE_KEY'; +precompileAddress = '0x0000000000000000000000000000000000000819'; +moonbeamURL = 'https://rpc.api.moonbase.moonbeam.network'; +relayURL = 'wss://frag-moonbase-relay-rpc-ws.g.moonbase.moonbeam.network'; + +# Create provider for Moonbeam network +web3 = Web3(Web3.HTTPProvider(moonbeamURL)) +account = Account.from_key(privateKey) +precompileContract = web3.eth.contract(address=precompileAddress,abi=ABI) + +# Create provider for relay chain +substrate = SubstrateInterface(url= relayURL) + +# Get storage key +key = substrate.generate_storage_hash(storage_module = "System",storage_function = "Account",params = ["5CBATpb3yvEM4mhX9Dw3tyuqiWKhq9YBG6ugSbodRUSbodoU"]) + +# Find the latest available block number(relay chain) from moonbeam +blockNum = precompileContract.functions.latestRelayBlockNumber().call() + +# Get the blockHash from relay chain +blockHash = substrate.get_block_hash(blockNum); + +# Get the storage proof from relay chain +response = substrate.rpc_request("state_getReadProof",[[key],blockHash]) +proof = response["result"] + +# Call smart contract +tx = precompileContract.functions.verifyEntry(blockNum,proof,key).build_transaction( + { + "from": Web3.to_checksum_address(account.address), + "nonce": web3.eth.get_transaction_count( + Web3.to_checksum_address(account.address) + ), + } +) +tx_create = web3.eth.account.sign_transaction(tx, privateKey) +tx_hash = web3.eth.send_raw_transaction(tx_create.rawTransaction) +tx_receipt = web3.eth.wait_for_transaction_receipt(tx_hash) \ No newline at end of file diff --git a/.snippets/text/builders/pallets-precompiles/precompiles/relay-data-verifier/relay-data-verifier-parameters.md b/.snippets/text/builders/pallets-precompiles/precompiles/relay-data-verifier/relay-data-verifier-parameters.md new file mode 100644 index 000000000..ac37581c4 --- /dev/null +++ b/.snippets/text/builders/pallets-precompiles/precompiles/relay-data-verifier/relay-data-verifier-parameters.md @@ -0,0 +1,10 @@ +- ***uint32* relayBlockNumber** - The relay block number for which the data is being verified. The latest relay block number can be obtained from the `latestRelayBlockNumber()` function +- ***ReadProof* calldata readProof** - A struct defined in the precompile contract, containing the storage proof used to verify the data. The `ReadProof` struct is defined as: + ``` + struct ReadProof { + // The block hash against which the proof is generated + bytes32 at; + /// The storage proof + bytes[] proof; + } + ``` \ No newline at end of file diff --git a/builders/pallets-precompiles/precompiles/.pages b/builders/pallets-precompiles/precompiles/.pages index e8a69210f..d3a393cd0 100644 --- a/builders/pallets-precompiles/precompiles/.pages +++ b/builders/pallets-precompiles/precompiles/.pages @@ -16,6 +16,7 @@ nav: - 'Proxy': 'proxy.md' - 'Randomness': 'randomness.md' - 'Referenda': 'referenda.md' + - 'Relay Data Verifier': 'relay-data-verifier.md' - 'Staking Functions': 'staking.md' - 'X-Tokens': '/builders/interoperability/xcm/xc20/send-xc20s/xtokens-precompile/' - 'XCM Transactor': '/builders/interoperability/xcm/remote-execution/substrate-calls/xcm-transactor-precompile/' diff --git a/builders/pallets-precompiles/precompiles/relay-data-verifier.md b/builders/pallets-precompiles/precompiles/relay-data-verifier.md new file mode 100644 index 000000000..49eb769e0 --- /dev/null +++ b/builders/pallets-precompiles/precompiles/relay-data-verifier.md @@ -0,0 +1,108 @@ +--- +title: Relay Data Verifier Precompile Contract +description: Learn how to verify data availability and authenticity on relay chain via a Solidity interface with Moonbeam's Relay Data Verifier Precompile contract. +keywords: solidity, ethereum, verify, proof, relay chain, transaction, moonbeam, precompiled, contracts +--- + +# Interacting with the Relay Data Verifier Precompile + +## Introduction {: #introduction } + +Polkadot's multi-chain architecture relies on state proofs to guarantee data integrity across its various components, especially between the relay chain and parachains. A state proof is a concise, cryptographic data structure that represents a specific subset of transactions or state data within a trie. It consists of a set of hashes that form a path from the target data to the root hash stored in the block header. + +By providing a state proof, a client can independently reconstruct the root hash and compare it with each other. If the reconstructed root hash matches each other, it confirms the authenticity, validity and inclusion of the target data within the blockchain. + +Moonbeam‘s [relay data verifier precompiled](https://github.com/moonbeam-foundation/moonbeam/blob/master/precompiles/relay-data-verifier/RelayDataVerifier.sol){target=\_blank} contract provide a easy way to verify Merkel proof between Moonbeam network and its relay chain. This functionality is readily available at the following contract addresses: + +=== "Moonbeam" + + ```text + {{networks.moonbeam.precompiles.relay_data_verifier }} + ``` + +=== "Moonriver" + + ```text + {{networks.moonriver.precompiles.relay_data_verifier }} + ``` + +=== "Moonbase Alpha" + + ```text + {{networks.moonbase.precompiles.relay_data_verifier }} + ``` + +--8<-- 'text/builders/pallets-precompiles/precompiles/security.md' + +## The Relay Data Verifier Solidity Interface {: #the-relay-data-verifier-solidity-interface } + +[`RelayDataVerifier.sol`](https://github.com/moonbeam-foundation/moonbeam/blob/master/precompiles/relay-data-verifier/RelayDataVerifier.sol){target=\_blank} is a Solidity interface that allows developers to interact with the precompile's methods: + +- **latestRelayBlockNumber**() — Retrieves the most recent relay chain block that has its storage root stored on the blockchain itself +- **verifyEntry**(*uint32* relayBlockNumber, *ReadProof* calldata readProof, *bytes* callData key) — Verifies a storage entry in the relay chain using a relay block number, a storage proof and the storage key. It returns the value associated with the key if the verification is successful +- **verifyEntries**(*uint32* relayBlockNumber, *ReadProof* calldata readProof, *bytes[]* callData keys) — Verifies a set of entries in the relay chain and returns the corresponding values. This function takes a relay block number, a storage proof, and an array of storage keys to verify. It returns an array of values associated with the keys, in the same order as the keys + +Function verifyEntry() and verifyEntries() contains the following parameters: + +--8<-- 'text/builders/pallets-precompiles/precompiles/relay-data-verifier/relay-data-verifier-parameters.md' + +## Interact with the Solidity Interface {: #interact-with-the-solidity-interface } + +A typical workflow to verify relay chain data involves the following steps: + +1. **Moonbeam RPC Call**: Call the `latestRelayBlockNumber` function to get the latest relay block number tracked by the chain in the `pallet-storage-root` + +2. **Relay RPC Call**: Call the `chain_getBlockHash(blockNumber)` RPC method to get the relay block hash for the block number obtained in step 1. + +3. **Relay RPC Call**: Call the `state_getReadProof(keys, at)` RPC method, where at is the relay block hash obtained in step 2, to get the ReadProof of the entries. + +4. **Moonbeam RPC Call**: Submit an Ethereum transaction to call the `verifyEntry` or `verifyEntries` function to verify the data against the relay block number. The call data should contain the relay block number obtained in step 1, the read proof generated in step 3, and the key(s) to verify. + +The following sections will cover how to interact with the Identity Precompile using Ethereum libraries, such as Ethers.js, Web3.js, and Web3.py. The examples in this guide will be on Moonbase Alpha. + +### Checking Prerequisites {: #checking-prerequisites } + +To follow along with this tutorial, you will need to have: + +- Create or have an accounts on Moonbase Alpha to test out the different features in the precompile +- At least one of the accounts will need to be funded with `DEV` tokens. + --8<-- 'text/_common/faucet/faucet-list-item.md' + +### Using Ethereum Libraries {: #using-ethereum-libraries } + +To interact with the Solidity interface using an Ethereum library, you'll need the precompile's ABI (Application Binary Interface). The ABI for the Relay Chain Data Verifier Precompile is as follows: + +??? code "Relay Data Verifier Precompile ABI" + + ```js + --8<-- 'code/builders/pallets-precompiles/precompiles/relay-data-verifier/abi.js' + ``` + +Once you have the ABI, you can interact with the precompile using the Ethereum library of your choice, such as [Ethers.js](/builders/build/eth-api/libraries/ethersjs/){target=\_blank}, [Web3.js](/builders/build/eth-api/libraries/web3js){target=\_blank}, or [Web3.py](/builders/build/eth-api/libraries/web3py){target=\_blank}. The general steps are as follows: + +1. Create a provider +2. Create a contract instance of the precompile +3. Interact with the precompile's functions + +The provided code example demonstrates how to use the Ethers.js library to interact with the Moonbase Alpha network and its relay chain, verifying a data entry using the verifyEntry function. + +!!! note + The code snippets presented in the following sections are not meant for production environments. Please make sure you adapt it for each use-case. + +=== "Ethers.js" + + ```js + --8<-- 'code/builders/pallets-precompiles/precompiles/relay-data-verifier/ethers-relay-data-verifier.js' + ``` + +=== "Web3.js" + + ```js + --8<-- 'code/builders/pallets-precompiles/precompiles/relay-data-verifier/web3js-relay-data-verifier.js' + ``` + +=== "Web3.py" + + ```py + --8<-- 'code/builders/pallets-precompiles/precompiles/relay-data-verifier/web3py-relay-data-verifier.py' + ``` \ No newline at end of file From 525094183f430405df1af14b65a651a0bc171218 Mon Sep 17 00:00:00 2001 From: Erin Shaben Date: Wed, 3 Apr 2024 11:25:47 -0400 Subject: [PATCH 07/26] fix broken link --- learn/dapps-list/dapp-directory.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/learn/dapps-list/dapp-directory.md b/learn/dapps-list/dapp-directory.md index 4bb2f5aad..bc7046048 100644 --- a/learn/dapps-list/dapp-directory.md +++ b/learn/dapps-list/dapp-directory.md @@ -302,7 +302,7 @@ As your project evolves, you may need to update your project's listing or images If you are no longer using a logo or screenshot, please remember to remove it from the `logos` or `screenshots` directory. -Once your changes have been made, you must follow the same instructions in the [Submit a Pull Request](#submit-a-pull-request) section so the changes can be [reviewed](review-process) by the Moonbeam Foundation. Please note that pull requests are reviewed on a bi-weekly basis, so if the update is urgent, you can create a [forum post](https://forum.moonbeam.foundation/){target=\_blank} asking for assistance. +Once your changes have been made, you must follow the same instructions in the [Submit a Pull Request](#submit-a-pull-request) section so the changes can be [reviewed](#review-process) by the Moonbeam Foundation. Please note that pull requests are reviewed on a bi-weekly basis, so if the update is urgent, you can create a [forum post](https://forum.moonbeam.foundation/){target=\_blank} asking for assistance.
--8<-- 'text/_disclaimers/user-generated-content.md' From 9ad1cf08bb640bf57299a53553b7033d79ca8285 Mon Sep 17 00:00:00 2001 From: Erin Shaben Date: Wed, 3 Apr 2024 11:26:12 -0400 Subject: [PATCH 08/26] shorten meta descriptions and title --- .../interoperability/xcm/xc20/send-xc20s/xtokens-precompile.md | 2 +- tutorials/eth-api/chat-gpt.md | 2 +- tutorials/eth-api/using-tenderly.md | 2 +- 3 files changed, 3 insertions(+), 3 deletions(-) diff --git a/builders/interoperability/xcm/xc20/send-xc20s/xtokens-precompile.md b/builders/interoperability/xcm/xc20/send-xc20s/xtokens-precompile.md index 5aed20492..a920ad54a 100644 --- a/builders/interoperability/xcm/xc20/send-xc20s/xtokens-precompile.md +++ b/builders/interoperability/xcm/xc20/send-xc20s/xtokens-precompile.md @@ -1,6 +1,6 @@ --- title: Send XC-20s to Other Chains -description: Learn how to send XC-20s to other chains using the X-Tokens Precompile, which enables you to send XC-20s cross-chain using Ethereum libraries like Ethers and Web3. +description: Learn how to send assets cross-chain via Cross-Consensus Messaging (XCM) using the X-Tokens Precompile with familiar Ethereum libraries like Ethers and Web3. --- # Using the X-Tokens Precompile To Send XC-20s diff --git a/tutorials/eth-api/chat-gpt.md b/tutorials/eth-api/chat-gpt.md index 2fc045270..6a57baa3e 100644 --- a/tutorials/eth-api/chat-gpt.md +++ b/tutorials/eth-api/chat-gpt.md @@ -1,5 +1,5 @@ --- -title: Using GPT-4 to Write and Debug Solidity Smart Contracts +title: Use GPT-4 to Develop Smart Contracts description: Learn how you can use OpenAI's ChatGPT (GPT-4) generative AI LLM to write, debug, and deploy Solidity smart contracts on the Moonbeam network. --- diff --git a/tutorials/eth-api/using-tenderly.md b/tutorials/eth-api/using-tenderly.md index b10eedf9c..9ab52dc27 100644 --- a/tutorials/eth-api/using-tenderly.md +++ b/tutorials/eth-api/using-tenderly.md @@ -1,6 +1,6 @@ --- title: Using Tenderly to Debug and Simulate Transactions -description: Follow a step-by-step tutorial on how to get started with Tenderly including using the Debugger, forking and simulating transactions, and monitoring smart contracts. +description: Follow a step-by-step guide on getting started with Tenderly, including using the debugger, forking and simulating transactions, and monitoring smart contracts. --- # Using Tenderly to Simulate and Debug Transactions From fb965dd2ccce7a338102d01ce3c348f4d30f5662 Mon Sep 17 00:00:00 2001 From: Erin Shaben Date: Wed, 3 Apr 2024 11:54:11 -0400 Subject: [PATCH 09/26] fix 404s --- builders/build/eth-api/dev-env/tenderly.md | 4 ++-- builders/build/eth-api/dev-env/thirdweb.md | 2 +- builders/integrations/indexers/subsquid.md | 4 ++-- builders/interoperability/protocols/wormhole.md | 14 +++++++------- learn/features/governance.md | 2 +- learn/features/treasury.md | 2 +- tutorials/eth-api/using-tenderly.md | 4 ++-- tutorials/integrations/nft-subsquid.md | 2 +- 8 files changed, 17 insertions(+), 17 deletions(-) diff --git a/builders/build/eth-api/dev-env/tenderly.md b/builders/build/eth-api/dev-env/tenderly.md index 6c0564b60..5c4b6fe60 100644 --- a/builders/build/eth-api/dev-env/tenderly.md +++ b/builders/build/eth-api/dev-env/tenderly.md @@ -13,9 +13,9 @@ The Tenderly platform provides the following features: - **[Contract Verification](https://docs.tenderly.co/monitoring/smart-contract-verification/){target=\_blank}** - as it is essential to verify your smart contracts to take full advantage of all of Tenderly's features, Tenderly provides several methods of verification. You can verify smart contracts through [the Tenderly dashboard](https://docs.tenderly.co/monitoring/smart-contract-verification/verifying-a-smart-contract#verifying-a-smart-contract){target=\_blank}, [the Tenderly CLI](https://docs.tenderly.co/monitoring/smart-contract-verification/verifying-contracts-using-cli){target=\_blank}, or [the Tenderly Hardhat plugin](https://docs.tenderly.co/monitoring/smart-contract-verification/verifying-contracts-using-the-tenderly-hardhat-plugin){target=\_blank} -- **[Debugger](https://docs.tenderly.co/debugger/how-to-use-tenderly-debugger){target=\_blank}** - use the visual debugger to inspect transactions and get better insight into the behavior of your code. With the debugger, you can review a transaction's stack trace, view the calls made in a transaction, step through a contract, and review decoded inputs, outputs, and state variables. You can use the debugger on the Tenderly dashboard or the [Tenderly Debugger Chrome Extension](https://docs.tenderly.co/simulations-and-forks/how-to-simulate-a-transaction){target=\_blank} +- **[Debugger](https://docs.tenderly.co/debugger){target=\_blank}** - use the visual debugger to inspect transactions and get better insight into the behavior of your code. With the debugger, you can review a transaction's stack trace, view the calls made in a transaction, step through a contract, and review decoded inputs, outputs, and state variables. You can use the debugger on the Tenderly dashboard or the [Tenderly Debugger Chrome Extension](https://docs.tenderly.co/simulations-and-forks/how-to-simulate-a-transaction){target=\_blank} -- **[Gas Profiler](https://docs.tenderly.co/debugger/how-to-use-tenderly-debugger#gas-profiler){target=\_blank}** - view how much gas you're spending on a granular level, so you can optimize your smart contracts and reduce transaction gas costs +- **[Gas Profiler](https://docs.tenderly.co/debugger#gas-profiler){target=\_blank}** - view how much gas you're spending on a granular level, so you can optimize your smart contracts and reduce transaction gas costs - **[Simulator](https://docs.tenderly.co/simulations-and-forks/how-to-simulate-a-transaction){target=\_blank}** - simulate transactions in a forked development environment to learn how your transactions will behave without having to send them on-chain. This way, you can know the outcome of the transaction and make sure it works as expected before sending it to the network. You can experiment with different parameters, simulate historical and current transactions, and edit the contract source code. You can access the simulator from the Tenderly dashboard or you can use the [Tenderly Simulation API](https://docs.tenderly.co/simulations-and-forks/simulation-api){target=\_blank} to take advantage of the simulator programmatically diff --git a/builders/build/eth-api/dev-env/thirdweb.md b/builders/build/eth-api/dev-env/thirdweb.md index e1400fd3a..076c55a63 100644 --- a/builders/build/eth-api/dev-env/thirdweb.md +++ b/builders/build/eth-api/dev-env/thirdweb.md @@ -118,7 +118,7 @@ thirdweb offers SDKs for a range of programming languages, such as React, React ## Interact With a Contract {: #interact-with-a-contract } -thirdweb provides several SDKs to allow you to interact with your contract including: [React](https://portal.thirdweb.com/react){target=\_blank}, [React Native](https://portal.thirdweb.com/react-native){target=\_blank}, [TypeScript](https://portal.thirdweb.com/typescript){target=\_blank}, [Python](https://portal.thirdweb.com/python){target=\_blank}, [Go](https://portal.thirdweb.com/go){target=\_blank}, and [Unity](https://portal.thirdweb.com/unity){target=\_blank}. +thirdweb provides several SDKs to allow you to interact with your contract including: [React](https://portal.thirdweb.com/react){target=\_blank}, [React Native](https://portal.thirdweb.com/react-native){target=\_blank}, [TypeScript](https://portal.thirdweb.com/typescript){target=\_blank}, and [Unity](https://portal.thirdweb.com/unity){target=\_blank}. This document will show you how to interact with your contract deployed to Moonbeam using React. You can view the [full React SDK reference](https://portal.thirdweb.com/react){target=\_blank} in thirdweb’s documentation. diff --git a/builders/integrations/indexers/subsquid.md b/builders/integrations/indexers/subsquid.md index c42c4ccea..8c8e8648a 100644 --- a/builders/integrations/indexers/subsquid.md +++ b/builders/integrations/indexers/subsquid.md @@ -64,7 +64,7 @@ To get started indexing Substrate data on Moonbeam, you'll need to create a Subs "specVersions": "https://v2.archive.subsquid.io/metadata/moonbase", ``` -4. Modify the `src/processor.ts` file, which is where Squids instantiate the processor, configure it, and attach handler functions. The processor fetches historical on-chain data from an [Archive](https://docs.subsquid.io/archives/overview/){target=\_blank}, which is a specialized data lake. You'll need to configure your processor to pull data from the Archive that corresponds to the [network](https://docs.subsquid.io/substrate-indexing/supported-networks/){target=\_blank} you are indexing data on: +4. Modify the `src/processor.ts` file, which is where Squids instantiate the processor, configure it, and attach handler functions. The processor fetches historical on-chain data from an [Archive](https://docs.subsquid.io/glossary/#archives/){target=\_blank}, which is a specialized data lake. You'll need to configure your processor to pull data from the Archive that corresponds to the [network](https://docs.subsquid.io/substrate-indexing/supported-networks/){target=\_blank} you are indexing data on: === "Moonbeam" @@ -147,7 +147,7 @@ To get started indexing EVM data on Moonbeam, you'll need to create a Subsquid p npm ci ``` -3. Modify the `src/processor.ts` file, which is where Squids instantiate the processor, configure it, and attach handler functions. The processor fetches historical on-chain data from an [Archive](https://docs.subsquid.io/archives/overview/){target=\_blank}, which is a specialized data lake. You'll need to configure your processor to pull data from the Archive that corresponds to the [network](https://docs.subsquid.io/evm-indexing/supported-networks/){target=\_blank} you are indexing data on: +3. Modify the `src/processor.ts` file, which is where Squids instantiate the processor, configure it, and attach handler functions. The processor fetches historical on-chain data from an [Archive](https://docs.subsquid.io/glossary/#archives/){target=\_blank}, which is a specialized data lake. You'll need to configure your processor to pull data from the Archive that corresponds to the [network](https://docs.subsquid.io/evm-indexing/supported-networks/){target=\_blank} you are indexing data on: === "Moonbeam" diff --git a/builders/interoperability/protocols/wormhole.md b/builders/interoperability/protocols/wormhole.md index b8cf906bb..831baaf6d 100644 --- a/builders/interoperability/protocols/wormhole.md +++ b/builders/interoperability/protocols/wormhole.md @@ -66,13 +66,13 @@ First things first, the code in this smart contract is based off of [Wormhole’ To deploy on each chain, you will need the local instance of the Wormhole core bridge and the chain ID of the chain mentioned. All of this data has been provided for a select few TestNets in the table below. You can find other networks’ endpoints on Wormhole’s [documentation site](https://docs.wormhole.com/wormhole/blockchain-environments/evm#testnet-contracts-moonbase-alphanet-1287){target=\_blank}. Keep in mind that you should only use EVMs for this demonstration, since the smart contract and relayer designed for this demonstration only supports EVMs. -| Network & Faucet | Core Bridge Address | Wormhole Chain ID | -|:----------------------------------------------------------------------------------------------------------------------------:|:------------------------------------------:|:-----------------:| -| [Polygon Mumbai](https://faucet.polygon.technology/){target=\_blank} | 0x0CBE91CF822c73C2315FB05100C2F714765d5c20 | 5 | -| [Avalanche Fuji](https://faucet.avax.network/){target=\_blank} | 0x7bbcE28e64B3F8b84d876Ab298393c38ad7aac4C | 6 | -| [Fantom TestNet](https://faucet.fantom.network/){target=\_blank} | 0x1BB3B4119b7BA9dfad76B0545fb3F531383c3bB7 | 10 | -| [Goerli](https://goerlifaucet.com/){target=\_blank} | 0x706abc4E45D419950511e474C7B9Ed348A4a716c | 2 | -| [Moonbase Alpha](https://faucet.moonbeam.network/){target=\_blank} | 0xa5B7D85a8f27dd7907dc8FdC21FA5657D5E2F901 | 16 | +| Network & Faucet | Core Bridge Address | Wormhole Chain ID | +|:--------------------------------------------------------------------:|:------------------------------------------:|:-----------------:| +| [Polygon Mumbai](https://faucet.polygon.technology/){target=\_blank} | 0x0CBE91CF822c73C2315FB05100C2F714765d5c20 | 5 | +| [Avalanche Fuji](https://faucet.avax.network/){target=\_blank} | 0x7bbcE28e64B3F8b84d876Ab298393c38ad7aac4C | 6 | +| [Fantom TestNet](https://faucet.fantom.network/){target=\_blank} | 0x1BB3B4119b7BA9dfad76B0545fb3F531383c3bB7 | 10 | +| [Sepolia](https://www.sepoliafaucet.io/){target=\_blank} | 0x4a8bc80Ed5a4067f1CCf107057b8270E0cC11A78 | 10002 | +| [Moonbase Alpha](https://faucet.moonbeam.network/){target=\_blank} | 0xa5B7D85a8f27dd7907dc8FdC21FA5657D5E2F901 | 16 | 1. Ensure that the contract chosen is **SimpleGeneralMessage** 2. Open up the deploy menu with the arrow button diff --git a/learn/features/governance.md b/learn/features/governance.md index d9544789d..8f8fbb9bf 100644 --- a/learn/features/governance.md +++ b/learn/features/governance.md @@ -39,7 +39,7 @@ Some of the main components of this governance model include: - **Council & Technical Committee Governance V1** — a group of community members who have special voting rights within the system. With the deprecation and removal of Governance v1, both of these committees were dissolved as of the [runtime 2800 release](/builders/build/releases/runtime-2800){target=\_blank} - **OpenGov Technical Committee** — a group of community members who can add certain proposals to the Whitelisted Track -For more details on how these Substrate frame pallets implement on-chain governance, you can checkout the [Walkthrough of Polkadot’s Governance](https://polkadot.network/a-walkthrough-of-polkadots-governance/){target=\_blank} blog post and the [Polkadot Governance Wiki](https://wiki.polkadot.network/docs/learn-governance){target=\_blank}. +For more details on how these Substrate frame pallets implement on-chain governance, you can checkout the [Walkthrough of Polkadot’s Governance](https://polkadot.network/a-walkthrough-of-polkadots-governance/){target=\_blank} blog post and the [Polkadot Governance Wiki](https://wiki.polkadot.network/docs/learn-polkadot-opengov){target=\_blank}. ## Governance v2: OpenGov {: #opengov } diff --git a/learn/features/treasury.md b/learn/features/treasury.md index e4296f961..1c1ac0bfe 100644 --- a/learn/features/treasury.md +++ b/learn/features/treasury.md @@ -68,7 +68,7 @@ The Treasury is funded by a percentage of each block's transaction fees. The rem To deter spam, proposals must be submitted with a deposit, also known as a proposal bond. The proposal bond is a percentage (check the table above) of the amount requested by the proposer, with a minimum amount and no upper limit (compared to Polkadot and Kusama, which have a maximum bond amount). A governance proposal can change these values. So, any token holder with enough tokens to cover the deposit can submit a proposal. If the proposer doesn't have enough funds to cover the deposit, the extrinsic will fail due to insufficient funds, but transaction fees will still be deducted. -Once a proposal has been submitted, a Treasury Council member may motion for a vote on the proposal. The Treasury Council then votes on it during the motion duration. The threshold for accepting a treasury proposal is at least three-fifths of the treasury council. On the other hand, the threshold for rejecting a proposal is at least one-half of the treasury council. If any member(s) of the Treasury Council fails to vote during the motion duration, the vote of the Treasury Council member that holds the "Default Vote" position acts as the default. The "Default Vote" position mirrors that of [Polkadot's "Prime Member"](https://wiki.polkadot.network/docs/learn-governance#prime-members){target=\_blank}. Please note that there is no way for a user to revoke a treasury proposal after it has been submitted. +Once a proposal has been submitted, a Treasury Council member may motion for a vote on the proposal. The Treasury Council then votes on it during the motion duration. The threshold for accepting a treasury proposal is at least three-fifths of the treasury council. On the other hand, the threshold for rejecting a proposal is at least one-half of the treasury council. If any member(s) of the Treasury Council fails to vote during the motion duration, the vote of the Treasury Council member that holds the "Default Vote" position acts as the default. The "Default Vote" position mirrors that of [Polkadot's "Prime Member"](https://wiki.polkadot.network/docs/learn/learn-governance#prime-members){target=\_blank}. Please note that there is no way for a user to revoke a treasury proposal after it has been submitted. If approved by the treasury council, the proposal enters a queue to be placed into a spend period. If the spending queue happens to contain the number of maximum approved proposals, the proposal submission will fail similarly to how it would if the proposer's balance is too low. If the proposal gets rejected, the deposit is non-refundable. diff --git a/tutorials/eth-api/using-tenderly.md b/tutorials/eth-api/using-tenderly.md index 9ab52dc27..97e9e2217 100644 --- a/tutorials/eth-api/using-tenderly.md +++ b/tutorials/eth-api/using-tenderly.md @@ -128,7 +128,7 @@ Tenderly also generates a custom RPC url for your fork, which looks something li ## Debugging {: #debugging } -The [Debugger](https://docs.tenderly.co/debugger/how-to-use-tenderly-debugger){target=\_blank} is one of the most powerful and acclaimed features of Tenderly. It's also quite fast and requires minimal setup. In fact, if the contract you're investigating is already verified on chain, firing up the debugger is as easy as searching for the transaction hash on Tenderly. Let's try it out. +The [Debugger](https://docs.tenderly.co/debugger){target=\_blank} is one of the most powerful and acclaimed features of Tenderly. It's also quite fast and requires minimal setup. In fact, if the contract you're investigating is already verified on chain, firing up the debugger is as easy as searching for the transaction hash on Tenderly. Let's try it out. In the upper search bar, you can paste a contract address or a transaction hash. Recall that Tenderly supports Moonbeam and Moonriver but does not currently support Moonbase Alpha. Here's an example transaction hash of a GLMR / FRAX swap on StellaSwap: @@ -156,7 +156,7 @@ Finally, you'll see a **Gas Profiler**, which will give you a visual representat ![Debugger 4](/images/tutorials/eth-api/using-tenderly/tenderly-13.webp) -For a more detailed look at how to use the Tenderly Debugger, be sure to check out [Tenderly's Debugger guide](https://docs.tenderly.co/debugger/how-to-use-tenderly-debugger){target=\_blank}. And that's it! You're well on your way to mastering Tenderly, which is sure to save you time and simplify your development experience building dApps on Moonbeam. +For a more detailed look at how to use the Tenderly Debugger, be sure to check out [Tenderly's Debugger guide](https://docs.tenderly.co/debugger){target=\_blank}. And that's it! You're well on your way to mastering Tenderly, which is sure to save you time and simplify your development experience building dApps on Moonbeam. --8<-- 'text/_disclaimers/educational-tutorial.md' diff --git a/tutorials/integrations/nft-subsquid.md b/tutorials/integrations/nft-subsquid.md index 3a6c7cd29..5ea0aeca0 100644 --- a/tutorials/integrations/nft-subsquid.md +++ b/tutorials/integrations/nft-subsquid.md @@ -117,7 +117,7 @@ The results will be stored at `src/abi`. One module will be generated for each A ## Define and Bind Event Handler(s) {: #define-event-handlers } -Subsquid SDK provides users with the [`SubstrateBatchProcessor` class](https://docs.subsquid.io/substrate-indexing/){target=\_blank}. Its instances connect to chain-specific [Subsquid archives](https://docs.subsquid.io/archives/overview/){target=\_blank} to get chain data and apply custom transformations. The indexing begins at the starting block and keeps up with new blocks after reaching the tip. +Subsquid SDK provides users with the [`SubstrateBatchProcessor` class](https://docs.subsquid.io/substrate-indexing/){target=\_blank}. Its instances connect to chain-specific [Subsquid archives](https://docs.subsquid.io/glossary/#archives/){target=\_blank} to get chain data and apply custom transformations. The indexing begins at the starting block and keeps up with new blocks after reaching the tip. The `SubstrateBatchProcessor` [exposes methods](https://docs.subsquid.io/substrate-indexing/configuration/){target=\_blank} to "subscribe" to specific data such as Substrate events, extrinsics, storage items or, for EVM, logs and transactions. The actual data processing is then started by calling the `.run()` function. This will start generating requests to the Archive for [*batches*](https://docs.subsquid.io/basics/batch-processing/){target=\_blank} of data specified in the configuration, and will trigger the callback function, or *batch handler* (passed to `.run()` as second argument) every time a batch is returned by the Archive. From 460809dd6ddedaad8e437f3a0ad38e40071cbb19 Mon Sep 17 00:00:00 2001 From: Wuzhong <144415646+wuzhong-papermoon@users.noreply.github.com> Date: Thu, 4 Apr 2024 16:28:06 +0800 Subject: [PATCH 10/26] Edit --- .../relay-data-verifier/RelayDataVerifier.sol | 74 ++++++++++++++++++ .../ethers-relay-data-verifier.js | 41 +++++----- .../web3js-relay-data-verifier.js | 39 +++++----- .../web3py-relay-data-verifier.py | 31 ++++---- .../precompiles/relay-data-verifier.md | 77 ++++++++++++++----- 5 files changed, 193 insertions(+), 69 deletions(-) create mode 100644 .snippets/code/builders/pallets-precompiles/precompiles/relay-data-verifier/RelayDataVerifier.sol diff --git a/.snippets/code/builders/pallets-precompiles/precompiles/relay-data-verifier/RelayDataVerifier.sol b/.snippets/code/builders/pallets-precompiles/precompiles/relay-data-verifier/RelayDataVerifier.sol new file mode 100644 index 000000000..a9063461b --- /dev/null +++ b/.snippets/code/builders/pallets-precompiles/precompiles/relay-data-verifier/RelayDataVerifier.sol @@ -0,0 +1,74 @@ +// SPDX-License-Identifier: GPL-3.0-only +pragma solidity >=0.8.3; + +/// @dev The RelayDataVerifier contract's address. +address constant RELAY_DATA_VERIFIER_ADDRESS = 0x0000000000000000000000000000000000000819; + +/// @dev The RelayDataVerifier contract's instance. +RelayDataVerifier constant RELAY_DATA_VERIFIER_CONTRACT = RelayDataVerifier( + RELAY_DATA_VERIFIER_ADDRESS +); + +/// @author The Moonbeam Team +/// @title Relay Proof Verifier Interface +/// @dev The interface that Solidity contracts use to interact with the Relay Proof Verifier +/// precompile. +/// A typical workflow to verify relay chain data is the following: +/// 1. Moonbeam RPC Call: Call `latestRelayBlockNumber` function to get the latest relay +/// block number tracked by the chain in `pallet-storage-root`. +/// 2. Relay RPC Call: Call `chain_getBlockHash(blockNumber)` RPC method to get the relay block hash +/// for the block number obtained in step 1. +/// 3. Relay RPC Call: Call `state_getReadProof(keys, at)` RPC method where `at` +/// is the relay block hash obtained in step 2 to get the 'ReadProof` of the entries. +/// 4. Moonbeam RPC Call: Submit an ethereum transaction (directly or through a SC) to call the +/// `verifyEntry` or `verifyEntries` function to verify the data against the relay block +/// number. The call data contain the relay block number obtained in step 1, and the read +/// proof generated in step 3, along with the key/s to verify. +/// @custom:address 0x0000000000000000000000000000000000000819 +interface RelayDataVerifier { + /// @dev ReadProof struct returned by the `state_getReadProof` RPC method. + struct ReadProof { + // The block hash against which the proof is generated + bytes32 at; + /// The storage proof + bytes[] proof; + } + + /// @dev Verifies a storage entry in the Relay Chain using a relay block number and a storage + /// proof. This function takes a relay block number, a storage proof, and the key of the storage + /// entry to verify. It returns the value associated with the key if the verification is + /// successful. + /// @custom:selector 27001faa + /// @param relayBlockNumber The relay block number against which the entry is being verified. + /// @param readProof The storage proof used to verify the entry. + /// @param key The key of the storage entry to verify. + /// @return value The value associated with the key, returned as a bytes array. + function verifyEntry( + uint32 relayBlockNumber, + ReadProof calldata readProof, + bytes calldata key + ) external returns (bytes memory value); + + /// @dev Verifies a set of entries in the Relay Chain and returns the corresponding values. + /// This function takes a relay block number, a storage proof, and an array of keys for the + /// storage entries to verify. It returns an array of values associated with the keys, in the + /// same order as the keys. + /// @custom:selector 2da33a45 + /// @param relayBlockNumber The relay block number for which the data is being verified. + /// @param readProof The storage proof used to verify the data. + /// @param keys The keys of the storage entries to verify. + /// @return values The values associated with the keys, returned in the same order as the keys. + function verifyEntries( + uint32 relayBlockNumber, + ReadProof calldata readProof, + bytes[] calldata keys + ) external returns (bytes[] memory values); + + /// @dev Returns the latest relay block number that has a storage root stored on-chain. + /// @custom:selector aed36869 + /// @return relayBlockNumber the lastest relay block number + function latestRelayBlockNumber() + external + view + returns (uint32 relayBlockNumber); +} \ No newline at end of file diff --git a/.snippets/code/builders/pallets-precompiles/precompiles/relay-data-verifier/ethers-relay-data-verifier.js b/.snippets/code/builders/pallets-precompiles/precompiles/relay-data-verifier/ethers-relay-data-verifier.js index 33561fb6c..e585b279f 100644 --- a/.snippets/code/builders/pallets-precompiles/precompiles/relay-data-verifier/ethers-relay-data-verifier.js +++ b/.snippets/code/builders/pallets-precompiles/precompiles/relay-data-verifier/ethers-relay-data-verifier.js @@ -1,8 +1,11 @@ -import * as fs from 'fs'; // For reading local ABI file -import { ethers } from 'ethers'; // Import Ethers library, to interact with Moonbeam networks -import { ApiPromise, WsProvider } from '@polkadot/api';; // Import Polkadot library, to interact with relay chain +// For reading local ABI file +import * as fs from 'fs'; +// Import Ethers library, to interact with Moonbeam networks +import { ethers } from 'ethers'; +// Import Polkadot library, to interact with relay chain +import { ApiPromise, WsProvider } from '@polkadot/api';; -var ABI= JSON.parse(fs.readFileSync('./RelayChainDataVerifierABI.json')); +const abi = JSON.parse(fs.readFileSync('./RelayChainDataVerifierABI.json')); const privateKey = 'INSERT_PRIVATE_KEY'; const precompileAddress = '0x0000000000000000000000000000000000000819'; const moonbeamURL = 'https://rpc.api.moonbase.moonbeam.network'; @@ -12,29 +15,31 @@ const relayURL = 'wss://frag-moonbase-relay-rpc-ws.g.moonbase.moonbeam.network'; const provider = new ethers.JsonRpcProvider(moonbeamURL); const signer = new ethers.Wallet(privateKey, provider); const precompileContract = new ethers.Contract( - precompileAddress, - ABI, - signer + precompileAddress, + abi, + signer ); -// Create provider for relay chain -const wsProvider = new WsProvider(relayURL); -const api = await ApiPromise.create({ provider: wsProvider }); +async function run() { + // Create provider for relay chain + const wsProvider = new WsProvider(relayURL); + const api = await ApiPromise.create({ provider: wsProvider }); -async function run(){ // Get the storage key for a random account on relay chain - let key = await api.query.system.account.key( + const key = api.query.system.account.key( '5CBATpb3yvEM4mhX9Dw3tyuqiWKhq9YBG6ugSbodRUSbodoU' ) - // Find the latest available block number(relay chain) from moonbeam - let blockNum = await precompileContract.latestRelayBlockNumber() + // Find the latest available relay chain block number + const blockNum = await precompileContract.latestRelayBlockNumber() // Get the blockHash and storage proof from relay chain - let blockHash = await api.rpc.chain.getBlockHash(blockNum); - let proof = await api.rpc.state.getReadProof([key],blockHash); - + const blockHash = await api.rpc.chain.getBlockHash(blockNum); + const proof = await api.rpc.state.getReadProof([key], blockHash); + // This tx will be rejected if the verification failed - await precompileContract.verifyEntry(blockNum, proof, key) + let receipt = await precompileContract.verifyEntry(blockNum, proof, key) + await receipt.wait(); + console.log(receipt.hash) } await run(); \ No newline at end of file diff --git a/.snippets/code/builders/pallets-precompiles/precompiles/relay-data-verifier/web3js-relay-data-verifier.js b/.snippets/code/builders/pallets-precompiles/precompiles/relay-data-verifier/web3js-relay-data-verifier.js index d3f3b0d86..6e3394551 100644 --- a/.snippets/code/builders/pallets-precompiles/precompiles/relay-data-verifier/web3js-relay-data-verifier.js +++ b/.snippets/code/builders/pallets-precompiles/precompiles/relay-data-verifier/web3js-relay-data-verifier.js @@ -1,8 +1,12 @@ -import * as fs from 'fs'; // For reading local ABI file -import { Web3 } from 'web3'; // Import web3js library, to interact with Moonbeam networks -import { ApiPromise, WsProvider } from '@polkadot/api';; // Import Polkadot library, to interact with relay chain - -var ABI= JSON.parse(fs.readFileSync('./RelayChainDataVerifierABI.json')); +// For reading local ABI file +import * as fs from 'fs'; +// Import web3js library, to interact with Moonbeam networks +import { Web3 } from 'web3'; +// Import Polkadot library, to interact with relay chain +import { ApiPromise, WsProvider } from '@polkadot/api'; +import { constants } from 'os'; + +const abi = JSON.parse(fs.readFileSync('./RelayChainDataVerifierABI.json')); const privateKey = 'INSERT_PRIVATE_KEY'; const precompileAddress = '0x0000000000000000000000000000000000000819'; const moonbeamURL = 'https://rpc.api.moonbase.moonbeam.network'; @@ -10,17 +14,17 @@ const relayURL = 'wss://frag-moonbase-relay-rpc-ws.g.moonbase.moonbeam.network'; // Create Web3js provider and signer const web3 = new Web3(moonbeamURL); -const precompileContract = new web3.eth.Contract(ABI, precompileAddress) - -// Create provider for relay chain -const wsProvider = new WsProvider(relayURL); -const api = await ApiPromise.create({ provider: wsProvider }); +const precompileContract = new web3.eth.Contract(abi, precompileAddress) const account = web3.eth.accounts.privateKeyToAccount(privateKey); -async function run(){ +async function run() { + // Create provider for relay chain + const wsProvider = new WsProvider(relayURL); + const api = await ApiPromise.create({ provider: wsProvider }); + // Get the storage key for a random account on relay chain - const key = await api.query.system.account.key( + const key = api.query.system.account.key( '5CBATpb3yvEM4mhX9Dw3tyuqiWKhq9YBG6ugSbodRUSbodoU' ) // Find the latest available block number(relay chain) from moonbeam @@ -28,8 +32,8 @@ async function run(){ // Get the blockHash and storage proof from relay chain const blockHash = await api.rpc.chain.getBlockHash(blockNum); - const proof = await api.rpc.state.getReadProof([key],blockHash); - + const proof = await api.rpc.state.getReadProof([key], blockHash); + const callObject = { to: precompileAddress, data: precompileContract.methods.verifyEntry(blockNum, proof, key).encodeABI(), @@ -37,12 +41,11 @@ async function run(){ gasPrice: await web3.eth.getGasPrice(), nonce: await web3.eth.getTransactionCount(account.address), } - + // This tx will be rejected if the verification failed const tx = await web3.eth.accounts.signTransaction(callObject, account.privateKey); - web3.eth.sendSignedTransaction(tx.rawTransaction) - .on('receipt', console.log) - .on('error', function(error){ console.log(error) }); + const receipt = await web3.eth.sendSignedTransaction(tx.rawTransaction) + console.log(receipt.transactionHash) } diff --git a/.snippets/code/builders/pallets-precompiles/precompiles/relay-data-verifier/web3py-relay-data-verifier.py b/.snippets/code/builders/pallets-precompiles/precompiles/relay-data-verifier/web3py-relay-data-verifier.py index 47fc672dc..454c9c2d8 100644 --- a/.snippets/code/builders/pallets-precompiles/precompiles/relay-data-verifier/web3py-relay-data-verifier.py +++ b/.snippets/code/builders/pallets-precompiles/precompiles/relay-data-verifier/web3py-relay-data-verifier.py @@ -1,40 +1,43 @@ # Import packages -import json -from substrateinterface import * +from substrateinterface import SubstrateInterface from web3 import Web3 from eth_account import Account # Initialize variables -ABI = [{'inputs':[],'name':'latestRelayBlockNumber','outputs':[{'internalType':'uint32','name':'relayBlockNumber','type':'uint32'}],'stateMutability':'view','type':'function'},{'inputs':[{'internalType':'uint32','name':'relayBlockNumber','type':'uint32'},{'components':[{'internalType':'bytes32','name':'at','type':'bytes32'},{'internalType':'bytes[]','name':'proof','type':'bytes[]'}],'internalType':'structRelayDataVerifier.ReadProof','name':'readProof','type':'tuple'},{'internalType':'bytes[]','name':'keys','type':'bytes[]'}],'name':'verifyEntries','outputs':[{'internalType':'bytes[]','name':'values','type':'bytes[]'}],'stateMutability':'nonpayable','type':'function'},{'inputs':[{'internalType':'uint32','name':'relayBlockNumber','type':'uint32'},{'components':[{'internalType':'bytes32','name':'at','type':'bytes32'},{'internalType':'bytes[]','name':'proof','type':'bytes[]'}],'internalType':'structRelayDataVerifier.ReadProof','name':'readProof','type':'tuple'},{'internalType':'bytes','name':'key','type':'bytes'}],'name':'verifyEntry','outputs':[{'internalType':'bytes','name':'value','type':'bytes'}],'stateMutability':'nonpayable','type':'function'}] +abi = INSERT_ABI -privateKey = 'INSERT_PRIVATE_KEY'; -precompileAddress = '0x0000000000000000000000000000000000000819'; -moonbeamURL = 'https://rpc.api.moonbase.moonbeam.network'; -relayURL = 'wss://frag-moonbase-relay-rpc-ws.g.moonbase.moonbeam.network'; +privateKey = "INSERT_PRIVATE_KEY" +precompileAddress = "0x0000000000000000000000000000000000000819" +moonbeamURL = "https://rpc.api.moonbase.moonbeam.network" +relayURL = "wss://frag-moonbase-relay-rpc-ws.g.moonbase.moonbeam.network" # Create provider for Moonbeam network web3 = Web3(Web3.HTTPProvider(moonbeamURL)) account = Account.from_key(privateKey) -precompileContract = web3.eth.contract(address=precompileAddress,abi=ABI) +precompileContract = web3.eth.contract(address=precompileAddress, abi=abi) # Create provider for relay chain -substrate = SubstrateInterface(url= relayURL) +substrate = SubstrateInterface(url=relayURL) # Get storage key -key = substrate.generate_storage_hash(storage_module = "System",storage_function = "Account",params = ["5CBATpb3yvEM4mhX9Dw3tyuqiWKhq9YBG6ugSbodRUSbodoU"]) +key = substrate.generate_storage_hash( + storage_module="System", + storage_function="Account", + params=["5CBATpb3yvEM4mhX9Dw3tyuqiWKhq9YBG6ugSbodRUSbodoU"], +) # Find the latest available block number(relay chain) from moonbeam blockNum = precompileContract.functions.latestRelayBlockNumber().call() # Get the blockHash from relay chain -blockHash = substrate.get_block_hash(blockNum); +blockHash = substrate.get_block_hash(blockNum) # Get the storage proof from relay chain -response = substrate.rpc_request("state_getReadProof",[[key],blockHash]) +response = substrate.rpc_request("state_getReadProof", [[key], blockHash]) proof = response["result"] # Call smart contract -tx = precompileContract.functions.verifyEntry(blockNum,proof,key).build_transaction( +tx = precompileContract.functions.verifyEntry(blockNum, proof, key).build_transaction( { "from": Web3.to_checksum_address(account.address), "nonce": web3.eth.get_transaction_count( @@ -44,4 +47,4 @@ ) tx_create = web3.eth.account.sign_transaction(tx, privateKey) tx_hash = web3.eth.send_raw_transaction(tx_create.rawTransaction) -tx_receipt = web3.eth.wait_for_transaction_receipt(tx_hash) \ No newline at end of file +tx_receipt = web3.eth.wait_for_transaction_receipt(tx_hash) diff --git a/builders/pallets-precompiles/precompiles/relay-data-verifier.md b/builders/pallets-precompiles/precompiles/relay-data-verifier.md index 49eb769e0..4d1d483cc 100644 --- a/builders/pallets-precompiles/precompiles/relay-data-verifier.md +++ b/builders/pallets-precompiles/precompiles/relay-data-verifier.md @@ -1,6 +1,6 @@ --- -title: Relay Data Verifier Precompile Contract -description: Learn how to verify data availability and authenticity on relay chain via a Solidity interface with Moonbeam's Relay Data Verifier Precompile contract. +title: Relay Data Verifier Precompile Contract +description: Learn how to verify data availability and authenticity on the relay chain via a Solidity interface with Moonbeam's Relay Data Verifier Precompile contract. keywords: solidity, ethereum, verify, proof, relay chain, transaction, moonbeam, precompiled, contracts --- @@ -10,7 +10,7 @@ keywords: solidity, ethereum, verify, proof, relay chain, transaction, moonbeam, Polkadot's multi-chain architecture relies on state proofs to guarantee data integrity across its various components, especially between the relay chain and parachains. A state proof is a concise, cryptographic data structure that represents a specific subset of transactions or state data within a trie. It consists of a set of hashes that form a path from the target data to the root hash stored in the block header. -By providing a state proof, a client can independently reconstruct the root hash and compare it with each other. If the reconstructed root hash matches each other, it confirms the authenticity, validity and inclusion of the target data within the blockchain. +By providing a state proof, a client can independently reconstruct the root hash and compare it with the original stored in the block header. If the reconstructed root hash matches the original, it confirms the authenticity, validity, and inclusion of the target data within the blockchain. Moonbeam‘s [relay data verifier precompiled](https://github.com/moonbeam-foundation/moonbeam/blob/master/precompiles/relay-data-verifier/RelayDataVerifier.sol){target=\_blank} contract provide a easy way to verify Merkel proof between Moonbeam network and its relay chain. This functionality is readily available at the following contract addresses: @@ -36,37 +36,76 @@ Moonbeam‘s [relay data verifier precompiled](https://github.com/moonbeam-found ## The Relay Data Verifier Solidity Interface {: #the-relay-data-verifier-solidity-interface } -[`RelayDataVerifier.sol`](https://github.com/moonbeam-foundation/moonbeam/blob/master/precompiles/relay-data-verifier/RelayDataVerifier.sol){target=\_blank} is a Solidity interface that allows developers to interact with the precompile's methods: +[`RelayDataVerifier.sol`](https://github.com/moonbeam-foundation/moonbeam/blob/master/precompiles/relay-data-verifier/RelayDataVerifier.sol){target=\_blank} is a Solidity interface that allows developers to interact with the precompile's methods. +??? code "RelayDataVerifier.sol" -- **latestRelayBlockNumber**() — Retrieves the most recent relay chain block that has its storage root stored on the blockchain itself -- **verifyEntry**(*uint32* relayBlockNumber, *ReadProof* calldata readProof, *bytes* callData key) — Verifies a storage entry in the relay chain using a relay block number, a storage proof and the storage key. It returns the value associated with the key if the verification is successful -- **verifyEntries**(*uint32* relayBlockNumber, *ReadProof* calldata readProof, *bytes[]* callData keys) — Verifies a set of entries in the relay chain and returns the corresponding values. This function takes a relay block number, a storage proof, and an array of storage keys to verify. It returns an array of values associated with the keys, in the same order as the keys + ```solidity + --8<-- 'code/builders/pallets-precompiles/precompiles/relay-data-verifier/RelayDataVerifier.sol' + ``` + +"function **latestRelayBlockNumber**() — Retrieves the most recent relay chain block that has its storage root stored on the blockchain itself" + + === "Returns" + + - `relayBlockNumber` - the latest relay block number that has a storage root stored on-chain. + +???+ "function **verifyEntry**(_uint32_ relayBlockNumber, _ReadProof_ calldata readProof, _bytes_ callData key) — Verifies a storage entry in the relay chain using a relay block number, a storage proof, and the storage key. It returns the value associated with the key if the verification is successful" + + === "Parameters" + + - `relayBlockNumber` - the relay block number for which the data is being verified. The latest relay block number can be obtained from the `latestRelayBlockNumber()` function -Function verifyEntry() and verifyEntries() contains the following parameters: + - `readProof` - a struct defined in the precompile contract, containing the storage proof used to verify the data. The `ReadProof` struct is defined as: + ``` + struct ReadProof { + // The block hash against which the proof is generated + bytes32 at; + /// The storage proof + bytes[] proof; + } + ``` ---8<-- 'text/builders/pallets-precompiles/precompiles/relay-data-verifier/relay-data-verifier-parameters.md' + - `key` - the storage key for the generated proof + +???+ "function **verifyEntries**(_uint32_ relayBlockNumber, _ReadProof_ calldata readProof, _bytes[]_ callData keys) — Verifies a set of entries in the relay chain and returns the corresponding values. This function takes a relay block number, a storage proof, and an array of storage keys to verify. It returns an array of values associated with the keys, in the same order as the keys" + + === "Parameters" + + - `relayBlockNumber` - The relay block number for which the data is being verified. The latest relay block number can be obtained from the `latestRelayBlockNumber()` function + + - `readProof` - A struct defined in the precompile contract, containing the storage proof used to verify the data. The `ReadProof` struct is defined as: + ``` + struct ReadProof { + // The block hash against which the proof is generated + bytes32 at; + /// The storage proof + bytes[] proof; + } + ``` + + - `keys` - The storage keys for the generated proof ## Interact with the Solidity Interface {: #interact-with-the-solidity-interface } A typical workflow to verify relay chain data involves the following steps: -1. **Moonbeam RPC Call**: Call the `latestRelayBlockNumber` function to get the latest relay block number tracked by the chain in the `pallet-storage-root` +1. **Moonbeam RPC Call** - Call the `latestRelayBlockNumber` function to get the latest relay block number tracked by the chain in the `pallet-storage-root` -2. **Relay RPC Call**: Call the `chain_getBlockHash(blockNumber)` RPC method to get the relay block hash for the block number obtained in step 1. +2. **Relay RPC Call** - Call the `chain_getBlockHash(blockNumber)` RPC method to get the relay block hash for the block number obtained in step 1 -3. **Relay RPC Call**: Call the `state_getReadProof(keys, at)` RPC method, where at is the relay block hash obtained in step 2, to get the ReadProof of the entries. +3. **Relay RPC Call** - Call the `state_getReadProof(keys, at)` RPC method, where `at` is the relay block hash obtained in step 2, to get the storage proof of the entries -4. **Moonbeam RPC Call**: Submit an Ethereum transaction to call the `verifyEntry` or `verifyEntries` function to verify the data against the relay block number. The call data should contain the relay block number obtained in step 1, the read proof generated in step 3, and the key(s) to verify. +4. **Moonbeam RPC Call** - Submit an Ethereum transaction to call the `verifyEntry` or `verifyEntries` function to verify the data against the relay block number. The call data should contain the relay block number obtained in step 1, the read proof generated in step 3, and the key(s) to verify -The following sections will cover how to interact with the Identity Precompile using Ethereum libraries, such as Ethers.js, Web3.js, and Web3.py. The examples in this guide will be on Moonbase Alpha. +The following sections will cover how to interact with the Identity Precompile using Ethereum libraries, such as Ethers.js, Web3.js, and Web3.py. The examples in this guide will be on Moonbase Alpha. ### Checking Prerequisites {: #checking-prerequisites } To follow along with this tutorial, you will need to have: - Create or have an accounts on Moonbase Alpha to test out the different features in the precompile -- At least one of the accounts will need to be funded with `DEV` tokens. - --8<-- 'text/_common/faucet/faucet-list-item.md' +- The account will need to be funded with `DEV` tokens. + --8<-- 'text/\_common/faucet/faucet-list-item.md' ### Using Ethereum Libraries {: #using-ethereum-libraries } @@ -84,10 +123,10 @@ Once you have the ABI, you can interact with the precompile using the Ethereum l 2. Create a contract instance of the precompile 3. Interact with the precompile's functions -The provided code example demonstrates how to use the Ethers.js library to interact with the Moonbase Alpha network and its relay chain, verifying a data entry using the verifyEntry function. +The provided code example demonstrates how to use the Ethers.js library to interact with the Moonbase Alpha network and its relay chain, verifying a data entry using the `verifyEntry` function. !!! note - The code snippets presented in the following sections are not meant for production environments. Please make sure you adapt it for each use-case. +The code snippets presented in the following sections are not meant for production environments. Please make sure you adapt it for each use-case. === "Ethers.js" @@ -105,4 +144,4 @@ The provided code example demonstrates how to use the Ethers.js library to inter ```py --8<-- 'code/builders/pallets-precompiles/precompiles/relay-data-verifier/web3py-relay-data-verifier.py' - ``` \ No newline at end of file + ``` From 9f902926cd0d36ed7539179a12b56830d4d7cfac Mon Sep 17 00:00:00 2001 From: Wuzhong <144415646+wuzhong-papermoon@users.noreply.github.com> Date: Thu, 4 Apr 2024 18:39:45 +0800 Subject: [PATCH 11/26] Fixed formatting error --- .../precompiles/relay-data-verifier.md | 28 ++++++++++--------- 1 file changed, 15 insertions(+), 13 deletions(-) diff --git a/builders/pallets-precompiles/precompiles/relay-data-verifier.md b/builders/pallets-precompiles/precompiles/relay-data-verifier.md index 4d1d483cc..37bb0784e 100644 --- a/builders/pallets-precompiles/precompiles/relay-data-verifier.md +++ b/builders/pallets-precompiles/precompiles/relay-data-verifier.md @@ -12,7 +12,7 @@ Polkadot's multi-chain architecture relies on state proofs to guarantee data int By providing a state proof, a client can independently reconstruct the root hash and compare it with the original stored in the block header. If the reconstructed root hash matches the original, it confirms the authenticity, validity, and inclusion of the target data within the blockchain. -Moonbeam‘s [relay data verifier precompiled](https://github.com/moonbeam-foundation/moonbeam/blob/master/precompiles/relay-data-verifier/RelayDataVerifier.sol){target=\_blank} contract provide a easy way to verify Merkel proof between Moonbeam network and its relay chain. This functionality is readily available at the following contract addresses: +Moonbeam‘s [relay data verifier precompiled](https://github.com/moonbeam-foundation/moonbeam/blob/master/precompiles/relay-data-verifier/RelayDataVerifier.sol){target=\_blank} contract provides an easy way to verify Merkel proof between Moonbeam network and its relay chain. This functionality is readily available at the following contract addresses: === "Moonbeam" @@ -43,15 +43,17 @@ Moonbeam‘s [relay data verifier precompiled](https://github.com/moonbeam-found --8<-- 'code/builders/pallets-precompiles/precompiles/relay-data-verifier/RelayDataVerifier.sol' ``` -"function **latestRelayBlockNumber**() — Retrieves the most recent relay chain block that has its storage root stored on the blockchain itself" +The interface includes the following functions: - === "Returns" +???+ function "**latestRelayBlockNumber**() — Retrieves the most recent relay chain block that has its storage root stored on the blockchain itself" - - `relayBlockNumber` - the latest relay block number that has a storage root stored on-chain. + === "Returns" -???+ "function **verifyEntry**(_uint32_ relayBlockNumber, _ReadProof_ calldata readProof, _bytes_ callData key) — Verifies a storage entry in the relay chain using a relay block number, a storage proof, and the storage key. It returns the value associated with the key if the verification is successful" + `relayBlockNumber` - the latest relay block number that has a storage root stored on-chain. - === "Parameters" +???+ function "**verifyEntry**(_uint32_ relayBlockNumber, _ReadProof_ calldata readProof, _bytes_ callData key) — Verifies a storage entry in the relay chain using a relay block number, a storage proof, and the storage key. It returns the value associated with the key if the verification is successful" + + === "Parameters" - `relayBlockNumber` - the relay block number for which the data is being verified. The latest relay block number can be obtained from the `latestRelayBlockNumber()` function @@ -67,9 +69,9 @@ Moonbeam‘s [relay data verifier precompiled](https://github.com/moonbeam-found - `key` - the storage key for the generated proof -???+ "function **verifyEntries**(_uint32_ relayBlockNumber, _ReadProof_ calldata readProof, _bytes[]_ callData keys) — Verifies a set of entries in the relay chain and returns the corresponding values. This function takes a relay block number, a storage proof, and an array of storage keys to verify. It returns an array of values associated with the keys, in the same order as the keys" +???+ function "**verifyEntries**(_uint32_ relayBlockNumber, _ReadProof_ calldata readProof, _bytes[]_ callData keys) — Verifies a set of entries in the relay chain and returns the corresponding values. This function takes a relay block number, a storage proof, and an array of storage keys to verify. It returns an array of values associated with the keys, in the same order as the keys" - === "Parameters" + === "Parameters" - `relayBlockNumber` - The relay block number for which the data is being verified. The latest relay block number can be obtained from the `latestRelayBlockNumber()` function @@ -93,9 +95,9 @@ A typical workflow to verify relay chain data involves the following steps: 2. **Relay RPC Call** - Call the `chain_getBlockHash(blockNumber)` RPC method to get the relay block hash for the block number obtained in step 1 -3. **Relay RPC Call** - Call the `state_getReadProof(keys, at)` RPC method, where `at` is the relay block hash obtained in step 2, to get the storage proof of the entries +3. **Relay RPC Call** - Call the `state_getReadProof(keys, at)` RPC method to retrieve the storage proof, where `at` is the relay block hash obtained in step 2, `keys` is an Array of strings which contains the keys for target storage items. For `@polkadot/api`, it can be obtained via `api.query.module.key()` function -4. **Moonbeam RPC Call** - Submit an Ethereum transaction to call the `verifyEntry` or `verifyEntries` function to verify the data against the relay block number. The call data should contain the relay block number obtained in step 1, the read proof generated in step 3, and the key(s) to verify +4. **Moonbeam RPC Call** - Submit an Ethereum transaction to call the `verifyEntry` or `verifyEntries` function to verify the data against the relay block number. The call data should contain the relay block number obtained in Step 1, the read proof generated in Step 3, and the key(s) to verify The following sections will cover how to interact with the Identity Precompile using Ethereum libraries, such as Ethers.js, Web3.js, and Web3.py. The examples in this guide will be on Moonbase Alpha. @@ -103,7 +105,7 @@ The following sections will cover how to interact with the Identity Precompile u To follow along with this tutorial, you will need to have: -- Create or have an accounts on Moonbase Alpha to test out the different features in the precompile +- Create or have an account on Moonbase Alpha to test out the different features in the precompile - The account will need to be funded with `DEV` tokens. --8<-- 'text/\_common/faucet/faucet-list-item.md' @@ -126,7 +128,7 @@ Once you have the ABI, you can interact with the precompile using the Ethereum l The provided code example demonstrates how to use the Ethers.js library to interact with the Moonbase Alpha network and its relay chain, verifying a data entry using the `verifyEntry` function. !!! note -The code snippets presented in the following sections are not meant for production environments. Please make sure you adapt it for each use-case. + The code snippets presented in the following sections are not meant for production environments. Please make sure you adapt it for each use case. === "Ethers.js" @@ -144,4 +146,4 @@ The code snippets presented in the following sections are not meant for producti ```py --8<-- 'code/builders/pallets-precompiles/precompiles/relay-data-verifier/web3py-relay-data-verifier.py' - ``` + ``` \ No newline at end of file From 604777dd91a41bebd980592ca4a69c4cadbb313c Mon Sep 17 00:00:00 2001 From: wuzhong-papermoon <144415646+wuzhong-papermoon@users.noreply.github.com> Date: Thu, 4 Apr 2024 22:30:51 +0800 Subject: [PATCH 12/26] Update builders/pallets-precompiles/precompiles/relay-data-verifier.md --- builders/pallets-precompiles/precompiles/relay-data-verifier.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/builders/pallets-precompiles/precompiles/relay-data-verifier.md b/builders/pallets-precompiles/precompiles/relay-data-verifier.md index 37bb0784e..42cf3dae2 100644 --- a/builders/pallets-precompiles/precompiles/relay-data-verifier.md +++ b/builders/pallets-precompiles/precompiles/relay-data-verifier.md @@ -91,7 +91,7 @@ The interface includes the following functions: A typical workflow to verify relay chain data involves the following steps: -1. **Moonbeam RPC Call** - Call the `latestRelayBlockNumber` function to get the latest relay block number tracked by the chain in the `pallet-storage-root` +1. **Moonbeam RPC Call** - call the `latestRelayBlockNumber` function to get the latest relay block number tracked by the chain in the `pallet-storage-root` 2. **Relay RPC Call** - Call the `chain_getBlockHash(blockNumber)` RPC method to get the relay block hash for the block number obtained in step 1 From 145b9aa83b084d98a95c993001d6be0eec9e8088 Mon Sep 17 00:00:00 2001 From: wuzhong-papermoon <144415646+wuzhong-papermoon@users.noreply.github.com> Date: Thu, 4 Apr 2024 22:31:02 +0800 Subject: [PATCH 13/26] Update builders/pallets-precompiles/precompiles/relay-data-verifier.md --- builders/pallets-precompiles/precompiles/relay-data-verifier.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/builders/pallets-precompiles/precompiles/relay-data-verifier.md b/builders/pallets-precompiles/precompiles/relay-data-verifier.md index 42cf3dae2..861e51937 100644 --- a/builders/pallets-precompiles/precompiles/relay-data-verifier.md +++ b/builders/pallets-precompiles/precompiles/relay-data-verifier.md @@ -93,7 +93,7 @@ A typical workflow to verify relay chain data involves the following steps: 1. **Moonbeam RPC Call** - call the `latestRelayBlockNumber` function to get the latest relay block number tracked by the chain in the `pallet-storage-root` -2. **Relay RPC Call** - Call the `chain_getBlockHash(blockNumber)` RPC method to get the relay block hash for the block number obtained in step 1 +2. **Relay RPC Call** - call the `chain_getBlockHash(blockNumber)` RPC method to get the relay block hash for the block number obtained in step 1 3. **Relay RPC Call** - Call the `state_getReadProof(keys, at)` RPC method to retrieve the storage proof, where `at` is the relay block hash obtained in step 2, `keys` is an Array of strings which contains the keys for target storage items. For `@polkadot/api`, it can be obtained via `api.query.module.key()` function From 99f5e737d8756568299d5606c4963c8aa28f4910 Mon Sep 17 00:00:00 2001 From: wuzhong-papermoon <144415646+wuzhong-papermoon@users.noreply.github.com> Date: Thu, 4 Apr 2024 22:31:09 +0800 Subject: [PATCH 14/26] Update builders/pallets-precompiles/precompiles/relay-data-verifier.md --- builders/pallets-precompiles/precompiles/relay-data-verifier.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/builders/pallets-precompiles/precompiles/relay-data-verifier.md b/builders/pallets-precompiles/precompiles/relay-data-verifier.md index 861e51937..d95cf5a4c 100644 --- a/builders/pallets-precompiles/precompiles/relay-data-verifier.md +++ b/builders/pallets-precompiles/precompiles/relay-data-verifier.md @@ -95,7 +95,7 @@ A typical workflow to verify relay chain data involves the following steps: 2. **Relay RPC Call** - call the `chain_getBlockHash(blockNumber)` RPC method to get the relay block hash for the block number obtained in step 1 -3. **Relay RPC Call** - Call the `state_getReadProof(keys, at)` RPC method to retrieve the storage proof, where `at` is the relay block hash obtained in step 2, `keys` is an Array of strings which contains the keys for target storage items. For `@polkadot/api`, it can be obtained via `api.query.module.key()` function +3. **Relay RPC Call** - call the `state_getReadProof(keys, at)` RPC method to retrieve the storage proof, where `at` is the relay block hash obtained in step 2, `keys` is an Array of strings which contains the keys for target storage items. For `@polkadot/api`, it can be obtained via `api.query.module.key()` function 4. **Moonbeam RPC Call** - Submit an Ethereum transaction to call the `verifyEntry` or `verifyEntries` function to verify the data against the relay block number. The call data should contain the relay block number obtained in Step 1, the read proof generated in Step 3, and the key(s) to verify From ac76f50e36d94f28649c1b1052a931896be5f329 Mon Sep 17 00:00:00 2001 From: wuzhong-papermoon <144415646+wuzhong-papermoon@users.noreply.github.com> Date: Thu, 4 Apr 2024 22:31:15 +0800 Subject: [PATCH 15/26] Update builders/pallets-precompiles/precompiles/relay-data-verifier.md --- builders/pallets-precompiles/precompiles/relay-data-verifier.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/builders/pallets-precompiles/precompiles/relay-data-verifier.md b/builders/pallets-precompiles/precompiles/relay-data-verifier.md index d95cf5a4c..731391649 100644 --- a/builders/pallets-precompiles/precompiles/relay-data-verifier.md +++ b/builders/pallets-precompiles/precompiles/relay-data-verifier.md @@ -97,7 +97,7 @@ A typical workflow to verify relay chain data involves the following steps: 3. **Relay RPC Call** - call the `state_getReadProof(keys, at)` RPC method to retrieve the storage proof, where `at` is the relay block hash obtained in step 2, `keys` is an Array of strings which contains the keys for target storage items. For `@polkadot/api`, it can be obtained via `api.query.module.key()` function -4. **Moonbeam RPC Call** - Submit an Ethereum transaction to call the `verifyEntry` or `verifyEntries` function to verify the data against the relay block number. The call data should contain the relay block number obtained in Step 1, the read proof generated in Step 3, and the key(s) to verify +4. **Moonbeam RPC Call** - submit an Ethereum transaction to call the `verifyEntry` or `verifyEntries` function to verify the data against the relay block number. The call data should contain the relay block number obtained in Step 1, the read proof generated in Step 3, and the key(s) to verify The following sections will cover how to interact with the Identity Precompile using Ethereum libraries, such as Ethers.js, Web3.js, and Web3.py. The examples in this guide will be on Moonbase Alpha. From 877b98cf98c91a5b50f28e4a7f483463a5abfccf Mon Sep 17 00:00:00 2001 From: Erin Shaben Date: Fri, 5 Apr 2024 12:24:01 -0400 Subject: [PATCH 16/26] minor cleanup --- .../precompiles/relay-data-verifier/abi.js | 192 +++++++++--------- .../ethers-relay-data-verifier.js | 26 +-- .../web3js-relay-data-verifier.js | 69 ++++--- .../web3py-relay-data-verifier.py | 4 +- .../relay-data-verifier-parameters.md | 10 - .../precompiles/relay-data-verifier.md | 90 ++++---- 6 files changed, 200 insertions(+), 191 deletions(-) delete mode 100644 .snippets/text/builders/pallets-precompiles/precompiles/relay-data-verifier/relay-data-verifier-parameters.md diff --git a/.snippets/code/builders/pallets-precompiles/precompiles/relay-data-verifier/abi.js b/.snippets/code/builders/pallets-precompiles/precompiles/relay-data-verifier/abi.js index f1fa7cf87..1a31a1ecb 100644 --- a/.snippets/code/builders/pallets-precompiles/precompiles/relay-data-verifier/abi.js +++ b/.snippets/code/builders/pallets-precompiles/precompiles/relay-data-verifier/abi.js @@ -1,97 +1,97 @@ [ - { - "inputs": [], - "name": "latestRelayBlockNumber", - "outputs": [ - { - "internalType": "uint32", - "name": "relayBlockNumber", - "type": "uint32" - } - ], - "stateMutability": "view", - "type": "function" - }, - { - "inputs": [ - { - "internalType": "uint32", - "name": "relayBlockNumber", - "type": "uint32" - }, - { - "components": [ - { - "internalType": "bytes32", - "name": "at", - "type": "bytes32" - }, - { - "internalType": "bytes[]", - "name": "proof", - "type": "bytes[]" - } - ], - "internalType": "struct RelayDataVerifier.ReadProof", - "name": "readProof", - "type": "tuple" - }, - { - "internalType": "bytes[]", - "name": "keys", - "type": "bytes[]" - } - ], - "name": "verifyEntries", - "outputs": [ - { - "internalType": "bytes[]", - "name": "values", - "type": "bytes[]" - } - ], - "stateMutability": "nonpayable", - "type": "function" - }, - { - "inputs": [ - { - "internalType": "uint32", - "name": "relayBlockNumber", - "type": "uint32" - }, - { - "components": [ - { - "internalType": "bytes32", - "name": "at", - "type": "bytes32" - }, - { - "internalType": "bytes[]", - "name": "proof", - "type": "bytes[]" - } - ], - "internalType": "struct RelayDataVerifier.ReadProof", - "name": "readProof", - "type": "tuple" - }, - { - "internalType": "bytes", - "name": "key", - "type": "bytes" - } - ], - "name": "verifyEntry", - "outputs": [ - { - "internalType": "bytes", - "name": "value", - "type": "bytes" - } - ], - "stateMutability": "nonpayable", - "type": "function" - } -] \ No newline at end of file + { + inputs: [], + name: 'latestRelayBlockNumber', + outputs: [ + { + internalType: 'uint32', + name: 'relayBlockNumber', + type: 'uint32', + }, + ], + stateMutability: 'view', + type: 'function', + }, + { + inputs: [ + { + internalType: 'uint32', + name: 'relayBlockNumber', + type: 'uint32', + }, + { + components: [ + { + internalType: 'bytes32', + name: 'at', + type: 'bytes32', + }, + { + internalType: 'bytes[]', + name: 'proof', + type: 'bytes[]', + }, + ], + internalType: 'struct RelayDataVerifier.ReadProof', + name: 'readProof', + type: 'tuple', + }, + { + internalType: 'bytes[]', + name: 'keys', + type: 'bytes[]', + }, + ], + name: 'verifyEntries', + outputs: [ + { + internalType: 'bytes[]', + name: 'values', + type: 'bytes[]', + }, + ], + stateMutability: 'nonpayable', + type: 'function', + }, + { + inputs: [ + { + internalType: 'uint32', + name: 'relayBlockNumber', + type: 'uint32', + }, + { + components: [ + { + internalType: 'bytes32', + name: 'at', + type: 'bytes32', + }, + { + internalType: 'bytes[]', + name: 'proof', + type: 'bytes[]', + }, + ], + internalType: 'struct RelayDataVerifier.ReadProof', + name: 'readProof', + type: 'tuple', + }, + { + internalType: 'bytes', + name: 'key', + type: 'bytes', + }, + ], + name: 'verifyEntry', + outputs: [ + { + internalType: 'bytes', + name: 'value', + type: 'bytes', + }, + ], + stateMutability: 'nonpayable', + type: 'function', + }, +]; diff --git a/.snippets/code/builders/pallets-precompiles/precompiles/relay-data-verifier/ethers-relay-data-verifier.js b/.snippets/code/builders/pallets-precompiles/precompiles/relay-data-verifier/ethers-relay-data-verifier.js index e585b279f..5db18efbd 100644 --- a/.snippets/code/builders/pallets-precompiles/precompiles/relay-data-verifier/ethers-relay-data-verifier.js +++ b/.snippets/code/builders/pallets-precompiles/precompiles/relay-data-verifier/ethers-relay-data-verifier.js @@ -1,9 +1,9 @@ // For reading local ABI file -import * as fs from 'fs'; +import * as fs from 'fs'; // Import Ethers library, to interact with Moonbeam networks -import { ethers } from 'ethers'; +import { ethers } from 'ethers'; // Import Polkadot library, to interact with relay chain -import { ApiPromise, WsProvider } from '@polkadot/api';; +import { ApiPromise, WsProvider } from '@polkadot/api'; const abi = JSON.parse(fs.readFileSync('./RelayChainDataVerifierABI.json')); const privateKey = 'INSERT_PRIVATE_KEY'; @@ -14,11 +14,7 @@ const relayURL = 'wss://frag-moonbase-relay-rpc-ws.g.moonbase.moonbeam.network'; // Create Ethers provider and signer const provider = new ethers.JsonRpcProvider(moonbeamURL); const signer = new ethers.Wallet(privateKey, provider); -const precompileContract = new ethers.Contract( - precompileAddress, - abi, - signer -); +const precompileContract = new ethers.Contract(precompileAddress, abi, signer); async function run() { // Create provider for relay chain @@ -28,18 +24,18 @@ async function run() { // Get the storage key for a random account on relay chain const key = api.query.system.account.key( '5CBATpb3yvEM4mhX9Dw3tyuqiWKhq9YBG6ugSbodRUSbodoU' - ) - // Find the latest available relay chain block number - const blockNum = await precompileContract.latestRelayBlockNumber() + ); + // Find the latest available relay chain block number from Moonbeam + const blockNum = await precompileContract.latestRelayBlockNumber(); - // Get the blockHash and storage proof from relay chain + // Get the block hash and storage proof from relay chain const blockHash = await api.rpc.chain.getBlockHash(blockNum); const proof = await api.rpc.state.getReadProof([key], blockHash); // This tx will be rejected if the verification failed - let receipt = await precompileContract.verifyEntry(blockNum, proof, key) + const receipt = await precompileContract.verifyEntry(blockNum, proof, key); await receipt.wait(); - console.log(receipt.hash) + console.log(receipt.hash); } -await run(); \ No newline at end of file +await run(); diff --git a/.snippets/code/builders/pallets-precompiles/precompiles/relay-data-verifier/web3js-relay-data-verifier.js b/.snippets/code/builders/pallets-precompiles/precompiles/relay-data-verifier/web3js-relay-data-verifier.js index 6e3394551..cd33040c6 100644 --- a/.snippets/code/builders/pallets-precompiles/precompiles/relay-data-verifier/web3js-relay-data-verifier.js +++ b/.snippets/code/builders/pallets-precompiles/precompiles/relay-data-verifier/web3js-relay-data-verifier.js @@ -4,7 +4,6 @@ import * as fs from 'fs'; import { Web3 } from 'web3'; // Import Polkadot library, to interact with relay chain import { ApiPromise, WsProvider } from '@polkadot/api'; -import { constants } from 'os'; const abi = JSON.parse(fs.readFileSync('./RelayChainDataVerifierABI.json')); const privateKey = 'INSERT_PRIVATE_KEY'; @@ -14,39 +13,47 @@ const relayURL = 'wss://frag-moonbase-relay-rpc-ws.g.moonbase.moonbeam.network'; // Create Web3js provider and signer const web3 = new Web3(moonbeamURL); -const precompileContract = new web3.eth.Contract(abi, precompileAddress) +const precompileContract = new web3.eth.Contract(abi, precompileAddress); const account = web3.eth.accounts.privateKeyToAccount(privateKey); async function run() { - // Create provider for relay chain - const wsProvider = new WsProvider(relayURL); - const api = await ApiPromise.create({ provider: wsProvider }); - - // Get the storage key for a random account on relay chain - const key = api.query.system.account.key( - '5CBATpb3yvEM4mhX9Dw3tyuqiWKhq9YBG6ugSbodRUSbodoU' - ) - // Find the latest available block number(relay chain) from moonbeam - const blockNum = await precompileContract.methods.latestRelayBlockNumber().call() - - // Get the blockHash and storage proof from relay chain - const blockHash = await api.rpc.chain.getBlockHash(blockNum); - const proof = await api.rpc.state.getReadProof([key], blockHash); - - const callObject = { - to: precompileAddress, - data: precompileContract.methods.verifyEntry(blockNum, proof, key).encodeABI(), - gas: await precompileContract.methods.verifyEntry(blockNum, proof, key).estimateGas(), - gasPrice: await web3.eth.getGasPrice(), - nonce: await web3.eth.getTransactionCount(account.address), - } - - // This tx will be rejected if the verification failed - const tx = await web3.eth.accounts.signTransaction(callObject, account.privateKey); - const receipt = await web3.eth.sendSignedTransaction(tx.rawTransaction) - console.log(receipt.transactionHash) - + // Create provider for relay chain + const wsProvider = new WsProvider(relayURL); + const api = await ApiPromise.create({ provider: wsProvider }); + + // Get the storage key for a random account on relay chain + const key = api.query.system.account.key( + '5CBATpb3yvEM4mhX9Dw3tyuqiWKhq9YBG6ugSbodRUSbodoU' + ); + // Find the latest available relay chain block number from Moonbeam + const blockNum = await precompileContract.methods + .latestRelayBlockNumber() + .call(); + + // Get the block hash and storage proof from relay chain + const blockHash = await api.rpc.chain.getBlockHash(blockNum); + const proof = await api.rpc.state.getReadProof([key], blockHash); + + const callObject = { + to: precompileAddress, + data: precompileContract.methods + .verifyEntry(blockNum, proof, key) + .encodeABI(), + gas: await precompileContract.methods + .verifyEntry(blockNum, proof, key) + .estimateGas(), + gasPrice: await web3.eth.getGasPrice(), + nonce: await web3.eth.getTransactionCount(account.address), + }; + + // This tx will be rejected if the verification failed + const tx = await web3.eth.accounts.signTransaction( + callObject, + account.privateKey + ); + const receipt = await web3.eth.sendSignedTransaction(tx.rawTransaction); + console.log(receipt.transactionHash); } -await run(); \ No newline at end of file +await run(); diff --git a/.snippets/code/builders/pallets-precompiles/precompiles/relay-data-verifier/web3py-relay-data-verifier.py b/.snippets/code/builders/pallets-precompiles/precompiles/relay-data-verifier/web3py-relay-data-verifier.py index 454c9c2d8..659ff5d85 100644 --- a/.snippets/code/builders/pallets-precompiles/precompiles/relay-data-verifier/web3py-relay-data-verifier.py +++ b/.snippets/code/builders/pallets-precompiles/precompiles/relay-data-verifier/web3py-relay-data-verifier.py @@ -26,10 +26,10 @@ params=["5CBATpb3yvEM4mhX9Dw3tyuqiWKhq9YBG6ugSbodRUSbodoU"], ) -# Find the latest available block number(relay chain) from moonbeam +# Find the latest available relay chain block number from Moonbeam blockNum = precompileContract.functions.latestRelayBlockNumber().call() -# Get the blockHash from relay chain +# Get the block hash from relay chain blockHash = substrate.get_block_hash(blockNum) # Get the storage proof from relay chain diff --git a/.snippets/text/builders/pallets-precompiles/precompiles/relay-data-verifier/relay-data-verifier-parameters.md b/.snippets/text/builders/pallets-precompiles/precompiles/relay-data-verifier/relay-data-verifier-parameters.md deleted file mode 100644 index ac37581c4..000000000 --- a/.snippets/text/builders/pallets-precompiles/precompiles/relay-data-verifier/relay-data-verifier-parameters.md +++ /dev/null @@ -1,10 +0,0 @@ -- ***uint32* relayBlockNumber** - The relay block number for which the data is being verified. The latest relay block number can be obtained from the `latestRelayBlockNumber()` function -- ***ReadProof* calldata readProof** - A struct defined in the precompile contract, containing the storage proof used to verify the data. The `ReadProof` struct is defined as: - ``` - struct ReadProof { - // The block hash against which the proof is generated - bytes32 at; - /// The storage proof - bytes[] proof; - } - ``` \ No newline at end of file diff --git a/builders/pallets-precompiles/precompiles/relay-data-verifier.md b/builders/pallets-precompiles/precompiles/relay-data-verifier.md index 731391649..11a8a013e 100644 --- a/builders/pallets-precompiles/precompiles/relay-data-verifier.md +++ b/builders/pallets-precompiles/precompiles/relay-data-verifier.md @@ -8,9 +8,9 @@ keywords: solidity, ethereum, verify, proof, relay chain, transaction, moonbeam, ## Introduction {: #introduction } -Polkadot's multi-chain architecture relies on state proofs to guarantee data integrity across its various components, especially between the relay chain and parachains. A state proof is a concise, cryptographic data structure that represents a specific subset of transactions or state data within a trie. It consists of a set of hashes that form a path from the target data to the root hash stored in the block header. +Polkadot's multi-chain architecture relies on state proofs to guarantee data integrity across its various components, especially between the relay chain and parachains. A state proof is a concise, cryptographic data structure representing a specific subset of transactions or state data within a trie. It consists of a set of hashes that form a path from the target data to the root hash stored in the block header. -By providing a state proof, a client can independently reconstruct the root hash and compare it with the original stored in the block header. If the reconstructed root hash matches the original, it confirms the authenticity, validity, and inclusion of the target data within the blockchain. +A client can independently reconstruct the root hash and compare it with the original stored in the block header by providing a state proof. If the reconstructed root hash matches the original, it confirms the target data's authenticity, validity, and inclusion within the blockchain. Moonbeam‘s [relay data verifier precompiled](https://github.com/moonbeam-foundation/moonbeam/blob/master/precompiles/relay-data-verifier/RelayDataVerifier.sol){target=\_blank} contract provides an easy way to verify Merkel proof between Moonbeam network and its relay chain. This functionality is readily available at the following contract addresses: @@ -37,6 +37,7 @@ Moonbeam‘s [relay data verifier precompiled](https://github.com/moonbeam-found ## The Relay Data Verifier Solidity Interface {: #the-relay-data-verifier-solidity-interface } [`RelayDataVerifier.sol`](https://github.com/moonbeam-foundation/moonbeam/blob/master/precompiles/relay-data-verifier/RelayDataVerifier.sol){target=\_blank} is a Solidity interface that allows developers to interact with the precompile's methods. + ??? code "RelayDataVerifier.sol" ```solidity @@ -45,69 +46,84 @@ Moonbeam‘s [relay data verifier precompiled](https://github.com/moonbeam-found The interface includes the following functions: -???+ function "**latestRelayBlockNumber**() — Retrieves the most recent relay chain block that has its storage root stored on the blockchain itself" +???+ function "**latestRelayBlockNumber**() — retrieves the most recent relay chain block that has its storage root stored on the blockchain itself" + + === "Parameters" + + None === "Returns" - `relayBlockNumber` - the latest relay block number that has a storage root stored on-chain. + The latest relay block number that has a storage root stored on-chain. -???+ function "**verifyEntry**(_uint32_ relayBlockNumber, _ReadProof_ calldata readProof, _bytes_ callData key) — Verifies a storage entry in the relay chain using a relay block number, a storage proof, and the storage key. It returns the value associated with the key if the verification is successful" +??? function "**verifyEntry**(_uint32_ relayBlockNumber, _ReadProof_ calldata readProof, _bytes_ callData key) — verifies a storage entry in the relay chain using a relay block number, a storage proof, and the storage key. It returns the value associated with the key if the verification is successful" === "Parameters" - - `relayBlockNumber` - the relay block number for which the data is being verified. The latest relay block number can be obtained from the `latestRelayBlockNumber()` function - - - `readProof` - a struct defined in the precompile contract, containing the storage proof used to verify the data. The `ReadProof` struct is defined as: + - `relayBlockNumber` - the relay block number for which the data is being verified. The latest relay block number can be obtained from the `latestRelayBlockNumber()` function + - `readProof` - a struct defined in the precompile contract, containing the storage proof used to verify the data. The `ReadProof` struct is defined as: ``` struct ReadProof { - // The block hash against which the proof is generated - bytes32 at; - /// The storage proof - bytes[] proof; - } + // The block hash against which the proof is generated + bytes32 at; + /// The storage proof + bytes[] proof; + } ``` + - `key` - the storage key for the generated proof + + === "Returns" - - `key` - the storage key for the generated proof + When performing a [static call](https://docs.ethers.org/v6/api/contract/#BaseContractMethod-staticCall){target=\_blank} on the `verifyEntry` function, you can view the returned value associated with the key in hexadecimal format. -???+ function "**verifyEntries**(_uint32_ relayBlockNumber, _ReadProof_ calldata readProof, _bytes[]_ callData keys) — Verifies a set of entries in the relay chain and returns the corresponding values. This function takes a relay block number, a storage proof, and an array of storage keys to verify. It returns an array of values associated with the keys, in the same order as the keys" + ```js + + '0x01000000040000000100000000000000f88ce384dca20000000000000000000000370589030a0000000000000000000000203d88792d0000000000000000000000000000000000000000000000000080' + ``` + +??? function "**verifyEntries**(_uint32_ relayBlockNumber, _ReadProof_ calldata readProof, _bytes[]_ callData keys) — verifies a set of entries in the relay chain and returns the corresponding values. This function takes a relay block number, a storage proof, and an array of storage keys to verify. It returns an array of values associated with the keys, in the same order as the keys" === "Parameters" - - `relayBlockNumber` - The relay block number for which the data is being verified. The latest relay block number can be obtained from the `latestRelayBlockNumber()` function + - `relayBlockNumber` - the relay block number for which the data is being verified. The latest relay block number can be obtained from the `latestRelayBlockNumber()` function + - `readProof` - a struct defined in the precompile contract, containing the storage proof used to verify the data. The `ReadProof` struct is defined as: + ``` + struct ReadProof { + // The block hash against which the proof is generated + bytes32 at; + /// The storage proof + bytes[] proof; + } + ``` + - `keys` - the storage keys for the generated proof - - `readProof` - A struct defined in the precompile contract, containing the storage proof used to verify the data. The `ReadProof` struct is defined as: - ``` - struct ReadProof { - // The block hash against which the proof is generated - bytes32 at; - /// The storage proof - bytes[] proof; - } - ``` + === "Returns" + + When performing a [static call](https://docs.ethers.org/v6/api/contract/#BaseContractMethod-staticCall){target=\_blank} on the `verifyEntries` function, you can view an array containing the corresponding values mapped to their respective keys, represented in hexadecimal format. - - `keys` - The storage keys for the generated proof + ```js + + ['0x01000000040000000100000000000000f88ce384dca20000000000000000000000370589030a0000000000000000000000203d88792d0000000000000000000000000000000000000000000000000080'] + ``` ## Interact with the Solidity Interface {: #interact-with-the-solidity-interface } A typical workflow to verify relay chain data involves the following steps: -1. **Moonbeam RPC Call** - call the `latestRelayBlockNumber` function to get the latest relay block number tracked by the chain in the `pallet-storage-root` +1. **Moonbeam RPC call** - call the `latestRelayBlockNumber` function to get the latest relay block number tracked by the chain in the `pallet-storage-root` +2. **Relay RPC call** - call the `chain_getBlockHash(blockNumber)` RPC method to get the relay block hash for the block number obtained in step one +3. **Relay RPC call** - call the `state_getReadProof(keys, at)` RPC method to retrieve the storage proof, where `at` is the relay block hash obtained in step two, and `keys` is an array of strings which contains the keys for target storage items. For `@polkadot/api`, it can be obtained via `api.query.module.key()` function +4. **Moonbeam RPC call** - submit an Ethereum transaction to call the `verifyEntry` or `verifyEntries` function to verify the data against the relay block number. The call data should contain the relay block number obtained in step one, the read proof generated in step three, and the key(s) to verify -2. **Relay RPC Call** - call the `chain_getBlockHash(blockNumber)` RPC method to get the relay block hash for the block number obtained in step 1 - -3. **Relay RPC Call** - call the `state_getReadProof(keys, at)` RPC method to retrieve the storage proof, where `at` is the relay block hash obtained in step 2, `keys` is an Array of strings which contains the keys for target storage items. For `@polkadot/api`, it can be obtained via `api.query.module.key()` function - -4. **Moonbeam RPC Call** - submit an Ethereum transaction to call the `verifyEntry` or `verifyEntries` function to verify the data against the relay block number. The call data should contain the relay block number obtained in Step 1, the read proof generated in Step 3, and the key(s) to verify - -The following sections will cover how to interact with the Identity Precompile using Ethereum libraries, such as Ethers.js, Web3.js, and Web3.py. The examples in this guide will be on Moonbase Alpha. +The following sections will cover how to interact with the Relay Data Verifier Precompile using Ethereum libraries, such as Ethers.js, Web3.js, and Web3.py. The examples in this guide will be on Moonbase Alpha. ### Checking Prerequisites {: #checking-prerequisites } To follow along with this tutorial, you will need to have: - Create or have an account on Moonbase Alpha to test out the different features in the precompile -- The account will need to be funded with `DEV` tokens. - --8<-- 'text/\_common/faucet/faucet-list-item.md' +- The account will need to be funded with `DEV` tokens. + --8<-- 'text/_common/faucet/faucet-list-item.md' ### Using Ethereum Libraries {: #using-ethereum-libraries } @@ -146,4 +162,4 @@ The provided code example demonstrates how to use the Ethers.js library to inter ```py --8<-- 'code/builders/pallets-precompiles/precompiles/relay-data-verifier/web3py-relay-data-verifier.py' - ``` \ No newline at end of file + ``` From 05c06c7ceabf50421659226f0351ce362227e9cc Mon Sep 17 00:00:00 2001 From: Erin Shaben Date: Fri, 5 Apr 2024 13:52:33 -0400 Subject: [PATCH 17/26] Update builders/pallets-precompiles/precompiles/relay-data-verifier.md Co-authored-by: albertov19 <64150856+albertov19@users.noreply.github.com> --- builders/pallets-precompiles/precompiles/relay-data-verifier.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/builders/pallets-precompiles/precompiles/relay-data-verifier.md b/builders/pallets-precompiles/precompiles/relay-data-verifier.md index 11a8a013e..ec11b399a 100644 --- a/builders/pallets-precompiles/precompiles/relay-data-verifier.md +++ b/builders/pallets-precompiles/precompiles/relay-data-verifier.md @@ -12,7 +12,7 @@ Polkadot's multi-chain architecture relies on state proofs to guarantee data int A client can independently reconstruct the root hash and compare it with the original stored in the block header by providing a state proof. If the reconstructed root hash matches the original, it confirms the target data's authenticity, validity, and inclusion within the blockchain. -Moonbeam‘s [relay data verifier precompiled](https://github.com/moonbeam-foundation/moonbeam/blob/master/precompiles/relay-data-verifier/RelayDataVerifier.sol){target=\_blank} contract provides an easy way to verify Merkel proof between Moonbeam network and its relay chain. This functionality is readily available at the following contract addresses: +Moonbeam's [relay data verifier precompiled](https://github.com/moonbeam-foundation/moonbeam/blob/master/precompiles/relay-data-verifier/RelayDataVerifier.sol){target=\_blank} contract provides an easy way for smart contracts to programmatically build functions that rely on verifying relay chain state in contract calls. Consequently, no oracles are needed to feed relay chain data to Moonbeam. This functionality is readily available at the following contract addresses: === "Moonbeam" From 868ace1d1b94bf7036a2c28e9849311f33f89ae7 Mon Sep 17 00:00:00 2001 From: Erin Shaben Date: Fri, 5 Apr 2024 13:52:47 -0400 Subject: [PATCH 18/26] Update builders/pallets-precompiles/precompiles/relay-data-verifier.md Co-authored-by: albertov19 <64150856+albertov19@users.noreply.github.com> --- builders/pallets-precompiles/precompiles/relay-data-verifier.md | 2 ++ 1 file changed, 2 insertions(+) diff --git a/builders/pallets-precompiles/precompiles/relay-data-verifier.md b/builders/pallets-precompiles/precompiles/relay-data-verifier.md index ec11b399a..887a0f77c 100644 --- a/builders/pallets-precompiles/precompiles/relay-data-verifier.md +++ b/builders/pallets-precompiles/precompiles/relay-data-verifier.md @@ -12,6 +12,8 @@ Polkadot's multi-chain architecture relies on state proofs to guarantee data int A client can independently reconstruct the root hash and compare it with the original stored in the block header by providing a state proof. If the reconstructed root hash matches the original, it confirms the target data's authenticity, validity, and inclusion within the blockchain. +Polkadot's unique architecture and parachain block validation process means blockchains like Moonbeam have the relay chain storage root hash in their state. Consequently, Moonbeam can provide a mechanism to verify a relay chain state by checking the proof against the stored storage root hash. + Moonbeam's [relay data verifier precompiled](https://github.com/moonbeam-foundation/moonbeam/blob/master/precompiles/relay-data-verifier/RelayDataVerifier.sol){target=\_blank} contract provides an easy way for smart contracts to programmatically build functions that rely on verifying relay chain state in contract calls. Consequently, no oracles are needed to feed relay chain data to Moonbeam. This functionality is readily available at the following contract addresses: === "Moonbeam" From fc727f80917ec9cad100261cd7063d1f4860e0cc Mon Sep 17 00:00:00 2001 From: Erin Shaben Date: Fri, 5 Apr 2024 13:52:53 -0400 Subject: [PATCH 19/26] Update builders/pallets-precompiles/precompiles/relay-data-verifier.md Co-authored-by: albertov19 <64150856+albertov19@users.noreply.github.com> --- builders/pallets-precompiles/precompiles/relay-data-verifier.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/builders/pallets-precompiles/precompiles/relay-data-verifier.md b/builders/pallets-precompiles/precompiles/relay-data-verifier.md index 887a0f77c..0cbea7b7b 100644 --- a/builders/pallets-precompiles/precompiles/relay-data-verifier.md +++ b/builders/pallets-precompiles/precompiles/relay-data-verifier.md @@ -8,7 +8,7 @@ keywords: solidity, ethereum, verify, proof, relay chain, transaction, moonbeam, ## Introduction {: #introduction } -Polkadot's multi-chain architecture relies on state proofs to guarantee data integrity across its various components, especially between the relay chain and parachains. A state proof is a concise, cryptographic data structure representing a specific subset of transactions or state data within a trie. It consists of a set of hashes that form a path from the target data to the root hash stored in the block header. +Polkadot's relies on state proofs to guarantee data integrity at a particular time. A state proof is a concise, cryptographic data structure representing a specific subset of transactions or state data within a trie. It consists of a set of hashes that form a path from the target data to the root hash stored in the block header. A client can independently reconstruct the root hash and compare it with the original stored in the block header by providing a state proof. If the reconstructed root hash matches the original, it confirms the target data's authenticity, validity, and inclusion within the blockchain. From 285a26bc2304d81a67b6762121c2c6ce0725dd9c Mon Sep 17 00:00:00 2001 From: Erin Shaben Date: Fri, 5 Apr 2024 13:55:05 -0400 Subject: [PATCH 20/26] minor fix --- builders/pallets-precompiles/precompiles/relay-data-verifier.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/builders/pallets-precompiles/precompiles/relay-data-verifier.md b/builders/pallets-precompiles/precompiles/relay-data-verifier.md index 0cbea7b7b..5f2e8efc6 100644 --- a/builders/pallets-precompiles/precompiles/relay-data-verifier.md +++ b/builders/pallets-precompiles/precompiles/relay-data-verifier.md @@ -8,7 +8,7 @@ keywords: solidity, ethereum, verify, proof, relay chain, transaction, moonbeam, ## Introduction {: #introduction } -Polkadot's relies on state proofs to guarantee data integrity at a particular time. A state proof is a concise, cryptographic data structure representing a specific subset of transactions or state data within a trie. It consists of a set of hashes that form a path from the target data to the root hash stored in the block header. +Polkadot relies on state proofs to guarantee data integrity at a particular time. A state proof is a concise, cryptographic data structure representing a specific subset of transactions or state data within a trie. It consists of a set of hashes that form a path from the target data to the root hash stored in the block header. A client can independently reconstruct the root hash and compare it with the original stored in the block header by providing a state proof. If the reconstructed root hash matches the original, it confirms the target data's authenticity, validity, and inclusion within the blockchain. From 947c6e89ec56e4e406f1df993986700cef284aaa Mon Sep 17 00:00:00 2001 From: Erin Shaben Date: Fri, 5 Apr 2024 15:27:07 -0400 Subject: [PATCH 21/26] Apply suggestions from code review Co-authored-by: Kevin Neilson --- builders/build/eth-api/dev-env/tenderly.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/builders/build/eth-api/dev-env/tenderly.md b/builders/build/eth-api/dev-env/tenderly.md index 5c4b6fe60..fceb65e78 100644 --- a/builders/build/eth-api/dev-env/tenderly.md +++ b/builders/build/eth-api/dev-env/tenderly.md @@ -11,13 +11,13 @@ description: Learn how to use Tenderly, an Ethereum development platform, to bui The Tenderly platform provides the following features: -- **[Contract Verification](https://docs.tenderly.co/monitoring/smart-contract-verification/){target=\_blank}** - as it is essential to verify your smart contracts to take full advantage of all of Tenderly's features, Tenderly provides several methods of verification. You can verify smart contracts through [the Tenderly dashboard](https://docs.tenderly.co/monitoring/smart-contract-verification/verifying-a-smart-contract#verifying-a-smart-contract){target=\_blank}, [the Tenderly CLI](https://docs.tenderly.co/monitoring/smart-contract-verification/verifying-contracts-using-cli){target=\_blank}, or [the Tenderly Hardhat plugin](https://docs.tenderly.co/monitoring/smart-contract-verification/verifying-contracts-using-the-tenderly-hardhat-plugin){target=\_blank} +- **[Contract Verification](https://docs.tenderly.co/contract-verification){target=\_blank}** - as it is essential to verify your smart contracts to take full advantage of all of Tenderly's features, Tenderly provides several methods of verification. You can verify smart contracts through [the Tenderly dashboard](https://docs.tenderly.co/contract-verification#verifying-a-smart-contract){target=\_blank}, [the Tenderly CLI](https://docs.tenderly.co/monitoring/smart-contract-verification/verifying-contracts-using-cli){target=\_blank}, or [the Tenderly Hardhat plugin](https://docs.tenderly.co/contract-verification/hardhat){target=\_blank} - **[Debugger](https://docs.tenderly.co/debugger){target=\_blank}** - use the visual debugger to inspect transactions and get better insight into the behavior of your code. With the debugger, you can review a transaction's stack trace, view the calls made in a transaction, step through a contract, and review decoded inputs, outputs, and state variables. You can use the debugger on the Tenderly dashboard or the [Tenderly Debugger Chrome Extension](https://docs.tenderly.co/simulations-and-forks/how-to-simulate-a-transaction){target=\_blank} - **[Gas Profiler](https://docs.tenderly.co/debugger#gas-profiler){target=\_blank}** - view how much gas you're spending on a granular level, so you can optimize your smart contracts and reduce transaction gas costs -- **[Simulator](https://docs.tenderly.co/simulations-and-forks/how-to-simulate-a-transaction){target=\_blank}** - simulate transactions in a forked development environment to learn how your transactions will behave without having to send them on-chain. This way, you can know the outcome of the transaction and make sure it works as expected before sending it to the network. You can experiment with different parameters, simulate historical and current transactions, and edit the contract source code. You can access the simulator from the Tenderly dashboard or you can use the [Tenderly Simulation API](https://docs.tenderly.co/simulations-and-forks/simulation-api){target=\_blank} to take advantage of the simulator programmatically +- **[Simulator](https://docs.tenderly.co/simulator-ui){target=\_blank}** - simulate transactions in a forked development environment to learn how your transactions will behave without having to send them on-chain. This way, you can know the outcome of the transaction and make sure it works as expected before sending it to the network. You can experiment with different parameters, simulate historical and current transactions, and edit the contract source code. You can access the simulator from the Tenderly dashboard or you can use the [Tenderly Simulation API](https://docs.tenderly.co/reference/api#tag/Simulations){target=\_blank} to take advantage of the simulator programmatically - **[Forks](https://docs.tenderly.co/simulations-and-forks/forks){target=\_blank}** - this feature simulates the live Moonbeam network in an isolated environment, which enables you to interact with deployed contracts and live on-chain data. Forking also takes transaction simulations a step further by enabling you to chain multiple simulations together chronologically. This allows for the testing of complex transaction scenarios where one transaction depends upon another, with the benefit of using live on-chain data. There are some limitations to be aware of when using Tenderly's forking feature. You cannot interact with any of the [Moonbeam precompiled contracts](/builders/pallets-precompiles/precompiles/){target=\_blank} and their functions. Precompiles are a part of the Substrate implementation and therefore cannot be replicated in the simulated EVM environment. This prohibits you from interacting with cross-chain assets on Moonbeam and Substrate-based functionality such as staking and governance From 8a19004225658f14c0c2d8744c7877a5c19bd159 Mon Sep 17 00:00:00 2001 From: Erin Shaben Date: Fri, 5 Apr 2024 15:47:21 -0400 Subject: [PATCH 22/26] clean up and double-check all the tendery links --- builders/build/eth-api/dev-env/tenderly.md | 22 +++++++++++----------- tutorials/eth-api/using-tenderly.md | 12 ++++++------ 2 files changed, 17 insertions(+), 17 deletions(-) diff --git a/builders/build/eth-api/dev-env/tenderly.md b/builders/build/eth-api/dev-env/tenderly.md index fceb65e78..05023bb13 100644 --- a/builders/build/eth-api/dev-env/tenderly.md +++ b/builders/build/eth-api/dev-env/tenderly.md @@ -5,21 +5,21 @@ description: Learn how to use Tenderly, an Ethereum development platform, to bui # Using Tenderly on Moonbeam -## Introduction {: #introduction } +## Introduction {: #introduction } [Tenderly](https://tenderly.co/){target=\_blank} is a Web3 development platform that contains a suite of tools designed to help developers throughout the DApp development life cycle. With Tenderly, you can build, debug, test, optimize, monitor, set up alerts, and view analytics for your smart contracts on Moonbeam and Moonriver. The Tenderly platform provides the following features: -- **[Contract Verification](https://docs.tenderly.co/contract-verification){target=\_blank}** - as it is essential to verify your smart contracts to take full advantage of all of Tenderly's features, Tenderly provides several methods of verification. You can verify smart contracts through [the Tenderly dashboard](https://docs.tenderly.co/contract-verification#verifying-a-smart-contract){target=\_blank}, [the Tenderly CLI](https://docs.tenderly.co/monitoring/smart-contract-verification/verifying-contracts-using-cli){target=\_blank}, or [the Tenderly Hardhat plugin](https://docs.tenderly.co/contract-verification/hardhat){target=\_blank} +- **[Contract Verification](https://docs.tenderly.co/contract-verification){target=\_blank}** - as it is essential to verify your smart contracts to take full advantage of all of Tenderly's features, Tenderly provides several methods of verification. You can verify smart contracts through [the Tenderly dashboard](https://docs.tenderly.co/contract-verification/dashboard){target=\_blank}, [the Tenderly CLI and Foundry](https://docs.tenderly.co/contract-verification/foundry){target=\_blank}, or [the Tenderly Hardhat plugin](https://docs.tenderly.co/contract-verification/hardhat){target=\_blank} -- **[Debugger](https://docs.tenderly.co/debugger){target=\_blank}** - use the visual debugger to inspect transactions and get better insight into the behavior of your code. With the debugger, you can review a transaction's stack trace, view the calls made in a transaction, step through a contract, and review decoded inputs, outputs, and state variables. You can use the debugger on the Tenderly dashboard or the [Tenderly Debugger Chrome Extension](https://docs.tenderly.co/simulations-and-forks/how-to-simulate-a-transaction){target=\_blank} +- **[Debugger](https://docs.tenderly.co/debugger){target=\_blank}** - use the visual debugger to inspect transactions and get better insight into the behavior of your code. With the debugger, you can review a transaction's stack trace, view the calls made in a transaction, step through a contract, and review decoded inputs, outputs, and state variables. You can use the debugger on the Tenderly dashboard or the [Tenderly Debugger Chrome Extension](https://docs.tenderly.co/debugger/tenderly-debugger-extension){target=\_blank} - **[Gas Profiler](https://docs.tenderly.co/debugger#gas-profiler){target=\_blank}** - view how much gas you're spending on a granular level, so you can optimize your smart contracts and reduce transaction gas costs -- **[Simulator](https://docs.tenderly.co/simulator-ui){target=\_blank}** - simulate transactions in a forked development environment to learn how your transactions will behave without having to send them on-chain. This way, you can know the outcome of the transaction and make sure it works as expected before sending it to the network. You can experiment with different parameters, simulate historical and current transactions, and edit the contract source code. You can access the simulator from the Tenderly dashboard or you can use the [Tenderly Simulation API](https://docs.tenderly.co/reference/api#tag/Simulations){target=\_blank} to take advantage of the simulator programmatically +- **[Simulator](https://docs.tenderly.co/simulator-ui){target=\_blank}** - simulate transactions in a forked development environment to learn how your transactions will behave without having to send them on-chain. This way, you can know the outcome of the transaction and make sure it works as expected before sending it to the network. You can experiment with different parameters, simulate historical and current transactions, and edit the contract source code. You can access the simulator from the Tenderly dashboard or you can use the [Tenderly Simulation API](https://docs.tenderly.co/reference/api#tag/Simulations){target=\_blank} to take advantage of the simulator programmatically -- **[Forks](https://docs.tenderly.co/simulations-and-forks/forks){target=\_blank}** - this feature simulates the live Moonbeam network in an isolated environment, which enables you to interact with deployed contracts and live on-chain data. Forking also takes transaction simulations a step further by enabling you to chain multiple simulations together chronologically. This allows for the testing of complex transaction scenarios where one transaction depends upon another, with the benefit of using live on-chain data. There are some limitations to be aware of when using Tenderly's forking feature. You cannot interact with any of the [Moonbeam precompiled contracts](/builders/pallets-precompiles/precompiles/){target=\_blank} and their functions. Precompiles are a part of the Substrate implementation and therefore cannot be replicated in the simulated EVM environment. This prohibits you from interacting with cross-chain assets on Moonbeam and Substrate-based functionality such as staking and governance +- **[Forks](https://docs.tenderly.co/forks){target=\_blank}** - this feature simulates the live Moonbeam network in an isolated environment, which enables you to interact with deployed contracts and live on-chain data. Forking also takes transaction simulations a step further by enabling you to chain multiple simulations together chronologically. This allows for the testing of complex transaction scenarios where one transaction depends upon another, with the benefit of using live on-chain data. There are some limitations to be aware of when using Tenderly's forking feature. You cannot interact with any of the [Moonbeam precompiled contracts](/builders/pallets-precompiles/precompiles/){target=\_blank} and their functions. Precompiles are a part of the Substrate implementation and therefore cannot be replicated in the simulated EVM environment. This prohibits you from interacting with cross-chain assets on Moonbeam and Substrate-based functionality such as staking and governance - **[Alerting](https://docs.tenderly.co/alerts/intro-to-alerts){target=\_blank}** - configure real-time alerts to notify you whenever a specific event occurs, allowing you to stay informed about what's going on with your smart contracts @@ -30,7 +30,7 @@ The Tenderly platform provides the following features: - **[Sandbox](https://sandbox.tenderly.co/){target=\_blank}** - write, compile, execute, and debug your smart contracts directly in your browser with baked-in JavaScript and Solidity editors. Every time you run your code, Tenderly creates a temporary fork that comes with 10 pre-funded accounts, each with 100 tokens for testing purposes !!! note - Moonbeam and Moonriver is fully supported by Tenderly with the exception of the Web3 Gateway. Moonbase Alpha is not currently supported by Tenderly. For more information on supported features and networks, check out [Tenderly's documentation site](https://docs.tenderly.co/supported-networks-and-languages#footnotes){target=\_blank}. + Moonbeam and Moonriver is fully supported by Tenderly with the exception of the Web3 Gateway. Moonbase Alpha is not currently supported by Tenderly. For more information, check out Tenderly's documentation on [Supported Networks](https://docs.tenderly.co/supported-networks-and-languages#supported-networks){target=\_blank}. ## Getting Started @@ -53,13 +53,13 @@ To deploy contracts to Moonbeam with a Tenderly Sandbox, you can navigate to [sa 3. Update the JavaScript editor on the right-hand side for your contract. [Ethers.js](/builders/build/eth-api/libraries/ethersjs){target=\_blank} and [Web3.js](/builders/build/eth-api/libraries/web3js){target=\_blank} are included in the Sandbox by default and can be instantiated with `ethers` and `web3`, respectively. It's also important to note that the Sandbox includes [global variables](https://docs.tenderly.co/tenderly-sandbox#available-javascript-global-variables){target=\_blank} to ease development, so you don't need to worry about updating the RPC URL for Moonbeam 4. Click on **RUN** when you're ready to compile your contract and execute your code -If your code contained logic to deploy your contract or send a transaction, you'll see the transaction(s) appear under the **Simulated Transactions** section on the bottom left-hand side. +If your code contained logic to deploy your contract or send a transaction, you'll see the transaction(s) appear under the **Simulated Transactions** section on the bottom left-hand side. ![Tenderly Sandbox](/images/builders/build/eth-api/dev-env/tenderly/tenderly-2.webp) ### Add a Contract {: #add-a-contract } -A good place to start with the Tenderly dashboard is to add a deployed smart contract. Once you've added a contract, you'll be able to create transaction simulations and forks, use the debugger, set up monitoring and alerts, and more. +A good place to start with the Tenderly dashboard is to add a deployed smart contract. Once you've added a contract, you'll be able to create transaction simulations and forks, use the debugger, set up monitoring and alerts, and more. To add a new contract, you can click on **Contracts** on the left-side panel and click **Add Contract**. A pop-up will appear and you can take the following steps: @@ -75,7 +75,7 @@ After a contract has been added, it will appear in the list of contracts on the ![Contract in list of contracts](/images/builders/build/eth-api/dev-env/tenderly/tenderly-4.webp) -To take full advantage of the Tenderly tool set, it is recommended that you verify your smart contracts, which you can do by clicking on **Verify**. You can choose to verify your contract by uploading the contract's JSON, ABI, or source code. For more information, please refer to [Tenderly's documentation](https://docs.tenderly.co/monitoring/smart-contract-verification/verifying-a-smart-contract#verifying-a-smart-contract){target=\_blank}. +To take full advantage of the Tenderly tool set, it is recommended that you verify your smart contracts, which you can do by clicking on **Verify**. You can choose to verify your contract by uploading the contract's JSON, ABI, or source code. For more information, please refer to Tenderly's documentation on [Smart Contract Verification](https://docs.tenderly.co/monitoring/smart-contract-verification/verifying-a-smart-contract#verifying-a-smart-contract){target=\_blank}. ### Create a Fork {: #fork-moonbeam } @@ -92,13 +92,13 @@ Tenderly makes creating a fork through the dashboard quite simple. To get starte ![Fork Moonbeam](/images/builders/build/eth-api/dev-env/tenderly/tenderly-5.webp) -Once you've created your fork, you can start using it by deploying a contract to it or creating a transaction simulation using it. +Once you've created your fork, you can start using it by deploying a contract to it or creating a transaction simulation using it. To deploy a contract to your fork, you can click on the **Deploy Contract** button, upload your contract's source code, and set the compiler configurations. Once you submit the deployment, you'll see the transaction of your deployment appear under the **Simulated Transactions** tab and can click on the simulation for more information. ![Fork simulations](/images/builders/build/eth-api/dev-env/tenderly/tenderly-6.webp) -To create additional simulations, you can click the **New Simulation** button and enter in the configurations for the simulation. For more information on simulations, please refer to [Tenderly's How to Simulate a Transaction documentation](https://docs.tenderly.co/simulations-and-forks/how-to-simulate-a-transaction){target=\_blank}. +To create additional simulations, you can click the **New Simulation** button and enter in the configurations for the simulation. For more information on simulations, please refer to Tenderly's [Simulator UI Overview](https://docs.tenderly.co/simulator-ui/using-simulation-ui){target=\_blank} documentation. Now that you've learned how to get started with a few of Tenderly's features on Moonbeam, please feel free to dive in and check out the other tools available in their development platform. You can visit [Tenderly's documentation site](https://docs.tenderly.co/){target=\_blank} for more information. You can also check out Moonbeam's tutorial on [Using Tenderly to Simulate and Debug Transactions](/tutorials/eth-api/using-tenderly/){target=\_blank}. diff --git a/tutorials/eth-api/using-tenderly.md b/tutorials/eth-api/using-tenderly.md index 97e9e2217..cc4d509e7 100644 --- a/tutorials/eth-api/using-tenderly.md +++ b/tutorials/eth-api/using-tenderly.md @@ -23,7 +23,7 @@ To get started, you will need the following: ## Create a Tenderly Project {: #create-a-tenderly-project } -Although not strictly required, it's a good idea to create a Tenderly project to keep things organized and access more of Tenderly's available features. Underneath the **Select Project** dropdown, you can press **Create Project** or head to [this Create Project link](https://dashboard.tenderly.co/projects/create){target=\_blank}. +Although not strictly required, it's a good idea to create a Tenderly project to keep things organized and access more of Tenderly's available features. Underneath the **Select Project** dropdown, you can press **Create Project** or head directly to the [Create Project](https://dashboard.tenderly.co/projects/create){target=\_blank} page of the dashboard. Give your project a name, and then press **Create Project**. Although you can change your project name at a later point, the URL will remain the original one you created. @@ -60,7 +60,7 @@ Head over to the **Simulator** tab, and let's craft a transaction to simulate ag ![Simulate a transaction against Moonbeam](/images/tutorials/eth-api/using-tenderly/tenderly-3.webp) -Clearly, this simulated transaction is going to fail because we're trying to send 10,000 FRAX that we don't have. But, with the [Tenderly Simulator](https://docs.tenderly.co/simulations-and-forks/how-to-simulate-a-transaction){target=\_blank}, we can tinker with the blockchain state and run simulations that assume different conditions. For example, let's run the simulation assuming that Baltathar actually holds a balance of 10,000 FRAX. Press **Re-Simulate** in the upper right corner, then take the following steps: +Clearly, this simulated transaction is going to fail because we're trying to send 10,000 FRAX that we don't have. But, with the [Tenderly Simulator](https://docs.tenderly.co/simulator-ui){target=\_blank}, we can tinker with the blockchain state and run simulations that assume different conditions. For example, let's run the simulation assuming that Baltathar actually holds a balance of 10,000 FRAX. Press **Re-Simulate** in the upper right corner, then take the following steps: 1. Expand the **State Overrides** section 2. Press **Add State Override** @@ -78,13 +78,13 @@ If you correctly added the state override, you should now see a transaction simu ![Transaction simulation with state override success](/images/tutorials/eth-api/using-tenderly/tenderly-5.webp) -You can also access Tenderly's transaction simulator via the [Tenderly Simulation API](https://docs.tenderly.co/simulations-and-forks/simulation-api){target=\_blank}. +You can also access Tenderly's transaction simulator via the [Simulations API](https://docs.tenderly.co/reference/api#tag/Simulations){target=\_blank}. ## Fork the Chain {: #fork-the-chain } ### Create a Fork {: #create-a-fork } -Simulations are great for one-off tests, but what if you want to test a series of interdependent transactions? A fork is a better option in this case because forks are stateful. Additionally, [Tenderly forks](https://docs.tenderly.co/simulations-and-forks/forks){target=\_blank} are a terrific option when you want to interact with contracts in a private environment without redeploying existing smart contract logic on-chain. +Simulations are great for one-off tests, but what if you want to test a series of interdependent transactions? A fork is a better option in this case because forks are stateful. Additionally, [Tenderly forks](https://docs.tenderly.co/forks){target=\_blank} are a terrific option when you want to interact with contracts in a private environment without redeploying existing smart contract logic on-chain. !!! note There are some limitations to be aware of when using Tenderly's forking feature. You cannot interact with any of the [Moonbeam precompiled contracts](/builders/pallets-precompiles/precompiles/){target=\_blank} or their functions. Precompiles are a part of the Substrate implementation and therefore cannot be replicated in the simulated EVM environment. This prohibits you from interacting with cross-chain assets on Moonbeam and Substrate-based functionality such as staking and governance. @@ -156,8 +156,8 @@ Finally, you'll see a **Gas Profiler**, which will give you a visual representat ![Debugger 4](/images/tutorials/eth-api/using-tenderly/tenderly-13.webp) -For a more detailed look at how to use the Tenderly Debugger, be sure to check out [Tenderly's Debugger guide](https://docs.tenderly.co/debugger){target=\_blank}. And that's it! You're well on your way to mastering Tenderly, which is sure to save you time and simplify your development experience building dApps on Moonbeam. +For a more detailed look, be sure to check out the [How to Use Tenderly Debugger](https://docs.tenderly.co/debugger){target=\_blank} guide. And that's it! You're well on your way to mastering Tenderly, which is sure to save you time and simplify your development experience building dApps on Moonbeam. --8<-- 'text/_disclaimers/educational-tutorial.md' ---8<-- 'text/_disclaimers/third-party-content.md' \ No newline at end of file +--8<-- 'text/_disclaimers/third-party-content.md' From b9bda10a7864295af1c37f88bc2830150cd295c0 Mon Sep 17 00:00:00 2001 From: Erin Shaben Date: Sun, 7 Apr 2024 23:23:38 -0400 Subject: [PATCH 23/26] fix link --- builders/build/eth-api/dev-env/tenderly.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/builders/build/eth-api/dev-env/tenderly.md b/builders/build/eth-api/dev-env/tenderly.md index 05023bb13..7ff692d6f 100644 --- a/builders/build/eth-api/dev-env/tenderly.md +++ b/builders/build/eth-api/dev-env/tenderly.md @@ -75,7 +75,7 @@ After a contract has been added, it will appear in the list of contracts on the ![Contract in list of contracts](/images/builders/build/eth-api/dev-env/tenderly/tenderly-4.webp) -To take full advantage of the Tenderly tool set, it is recommended that you verify your smart contracts, which you can do by clicking on **Verify**. You can choose to verify your contract by uploading the contract's JSON, ABI, or source code. For more information, please refer to Tenderly's documentation on [Smart Contract Verification](https://docs.tenderly.co/monitoring/smart-contract-verification/verifying-a-smart-contract#verifying-a-smart-contract){target=\_blank}. +To take full advantage of the Tenderly tool set, it is recommended that you verify your smart contracts, which you can do by clicking on **Verify**. You can choose to verify your contract by uploading the contract's JSON, ABI, or source code. For more information, please refer to Tenderly's documentation on [Smart Contract Verification](https://docs.tenderly.co/contract-verification#verifying-a-smart-contract){target=\_blank}. ### Create a Fork {: #fork-moonbeam } From 8dbd9c9f4528aaa4f327dec7ae385042a702dd5c Mon Sep 17 00:00:00 2001 From: Erin Shaben Date: Mon, 8 Apr 2024 10:08:24 -0400 Subject: [PATCH 24/26] update moonbeam to runtime 2801 --- builders/build/runtime-upgrades.md | 4 ++-- variables.yml | 2 +- 2 files changed, 3 insertions(+), 3 deletions(-) diff --git a/builders/build/runtime-upgrades.md b/builders/build/runtime-upgrades.md index fc1d896cc..21039bc30 100644 --- a/builders/build/runtime-upgrades.md +++ b/builders/build/runtime-upgrades.md @@ -18,7 +18,7 @@ The following table contains a list of the runtime upgrades and the block at whi Not all runtime upgrades are released on each network, as sometimes after releasing the initial runtime upgrade, the need for a subsequent upgrade arises. If a runtime upgrade version has been skipped or hasn't been released yet (only applicable to the latest runtime upgrade), you'll see a `-` in that row. | Runtime | Moonbeam | Moonriver | Moonbase Alpha | -|:----------------------------------------------------------------------------------------:|:--------------------------------------------------------------------:|:---------------------------------------------------------------------:|:--------------------------------------------------------------------:| +| :--------------------------------------------------------------------------------------: | :------------------------------------------------------------------: | :-------------------------------------------------------------------: | :------------------------------------------------------------------: | | 40 | - | - | [0](https://moonbase.subscan.io/block/0){target=\_blank} | | 44 | - | - | [142863](https://moonbase.subscan.io/block/142863){target=\_blank} | | 47 | - | - | [209144](https://moonbase.subscan.io/block/209144){target=\_blank} | @@ -75,4 +75,4 @@ Not all runtime upgrades are released on each network, as sometimes after releas | [2601](https://forum.moonbeam.network/t/runtime-rt2600-schedule/1372/5){target=\_blank} | - | - | [5474345](https://moonbase.subscan.io/block/5474345){target=\_blank} | | [2602](https://forum.moonbeam.network/t/runtime-rt2600-schedule/1372/13){target=\_blank} | [4977160](https://moonbeam.subscan.io/block/4977160){target=\_blank} | [5638536](https://moonriver.subscan.io/block/5638536){target=\_blank} | [5576588](https://moonbase.subscan.io/block/5576588){target=\_blank} | | [2700](https://forum.moonbeam.network/t/runtime-rt2700-schedule/1441/3){target=\_blank} | [5504531](https://moonbeam.subscan.io/block/5504531){target=\_blank} | [6041969](https://moonriver.subscan.io/block/6041969){target=\_blank} | [5860584](https://moonbase.subscan.io/block/5860584){target=\_blank} | -| [2801](https://forum.moonbeam.network/t/runtime-rt2801-schedule/1616/4){target=\_blank} | - | [6411588](https://moonriver.subscan.io/block/6411588){target=\_blank} | [6209638](https://moonbase.subscan.io/block/6209638){target=\_blank} | +| [2801](https://forum.moonbeam.network/t/runtime-rt2801-schedule/1616/4){target=\_blank} | [5899847](https://moonbeam.subscan.io/block/5899847){target=\_blank} | [6411588](https://moonriver.subscan.io/block/6411588){target=\_blank} | [6209638](https://moonbase.subscan.io/block/6209638){target=\_blank} | diff --git a/variables.yml b/variables.yml index 0a0a902e7..d0398dcb8 100644 --- a/variables.yml +++ b/variables.yml @@ -780,7 +780,7 @@ networks: tracing_tag: moonbeamfoundation/moonbeam-tracing:v0.36.0-2801-7ae4 chain_spec: moonbeam block_explorer: https://moonscan.io - spec_version: runtime-2700 + spec_version: runtime-2801 binary_name: moonbeam min_gas_price: 125 block_time: 12 From 377b50f50f33ffc44c34e5582f68306fc643943d Mon Sep 17 00:00:00 2001 From: Erin Shaben Date: Mon, 8 Apr 2024 10:30:21 -0400 Subject: [PATCH 25/26] add xcTNKR to list of xc-20s --- builders/interoperability/xcm/xc20/overview.md | 1 + 1 file changed, 1 insertion(+) diff --git a/builders/interoperability/xcm/xc20/overview.md b/builders/interoperability/xcm/xc20/overview.md index 285296338..4ea3f7ac1 100644 --- a/builders/interoperability/xcm/xc20/overview.md +++ b/builders/interoperability/xcm/xc20/overview.md @@ -118,6 +118,7 @@ The current list of available external XC-20 assets per network is as follows: | Picasso | xcPICA | [0xFffFfFFf7dD9B9C60ac83e49D7E3E1f7A1370aD2](https://moonriver.moonscan.io/token/0xFffFfFFf7dD9B9C60ac83e49D7E3E1f7A1370aD2){target=\_blank} | | Robonomics | xcXRT | [0xFffFFffF51470Dca3dbe535bD2880a9CcDBc6Bd9](https://moonriver.moonscan.io/token/0xFffFFffF51470Dca3dbe535bD2880a9CcDBc6Bd9){target=\_blank} | | Shiden | xcSDN | [0xFFFfffFF0Ca324C842330521525E7De111F38972](https://moonriver.moonscan.io/token/0xFFFfffFF0Ca324C842330521525E7De111F38972){target=\_blank} | + | Tinkernet | xcTNKR | [0xfFFfFffF683474B842852111cc31d470bD8f5081](https://moonriver.moonscan.io/token/0xffffffff683474b842852111cc31d470bd8f5081){target=\_blank} | | Turing | xcTUR | [0xfFffffFf6448d0746f2a66342B67ef9CAf89478E](https://moonriver.moonscan.io/token/0xfFffffFf6448d0746f2a66342B67ef9CAf89478E){target=\_blank} | _*You can check each [Asset ID](https://polkadot.js.org/apps/?rpc=wss://wss.api.moonriver.moonbeam.network#/assets){target=\_blank} on Polkadot.js Apps_ From 6ed2041a3076e01a73761b16728d0377c6c812b6 Mon Sep 17 00:00:00 2001 From: Erin Shaben Date: Tue, 16 Apr 2024 11:08:55 -0400 Subject: [PATCH 26/26] update list of xc-20s to include xcDED xcPEAQ and xcUNQ --- builders/interoperability/xcm/xc20/overview.md | 9 ++++++--- 1 file changed, 6 insertions(+), 3 deletions(-) diff --git a/builders/interoperability/xcm/xc20/overview.md b/builders/interoperability/xcm/xc20/overview.md index 285296338..f26ec850d 100644 --- a/builders/interoperability/xcm/xc20/overview.md +++ b/builders/interoperability/xcm/xc20/overview.md @@ -57,7 +57,7 @@ The current list of available external XC-20 assets per network is as follows: | Acala | xcACA | [0xffffFFffa922Fef94566104a6e5A35a4fCDDAA9f](https://moonscan.io/token/0xffffFFffa922Fef94566104a6e5A35a4fCDDAA9f){target=\_blank} | | Acala | xcLDOT | [0xFFfFfFffA9cfFfa9834235Fe53f4733F1b8B28d4](https://moonscan.io/token/0xFFfFfFffA9cfFfa9834235Fe53f4733F1b8B28d4){target=\_blank} | | Astar | xcASTR | [0xFfFFFfffA893AD19e540E172C10d78D4d479B5Cf](https://moonscan.io/token/0xFfFFFfffA893AD19e540E172C10d78D4d479B5Cf){target=\_blank} | - | Bifrost | xcBNC | [0xffffffff7cc06abdf7201b350a1265c62c8601d2](https://moonscan.io/token/0xffffffff7cc06abdf7201b350a1265c62c8601d2){target=\_blank} | + | Bifrost | xcBNC | [0xFFffffFf7cC06abdF7201b350A1265c62C8601d2](https://moonscan.io/token/0xFFffffFf7cC06abdF7201b350A1265c62C8601d2){target=\_blank} | | Bifrost | xcBNCS | [0xfFfffffF6aF229AE7f0F4e0188157e189a487D59](https://moonscan.io/token/0xfFfffffF6aF229AE7f0F4e0188157e189a487D59){target=\_blank} | | Bifrost | xcFIL | [0xfFFfFFFF6C57e17D210DF507c82807149fFd70B2](https://moonscan.io/token/0xfFFfFFFF6C57e17D210DF507c82807149fFd70B2){target=\_blank} | | Bifrost | xcvASTR | [0xFffFffff55C732C47639231a4C4373245763d26E](https://moonscan.io/token/0xFffFffff55C732C47639231a4C4373245763d26E){target=\_blank} | @@ -73,6 +73,7 @@ The current list of available external XC-20 assets per network is as follows: | Composable | xcIBCTIA | [0xFFFfFfff644a12F6F01b754987D175F5A780A75B](https://moonscan.io/token/0xFFFfFfff644a12F6F01b754987D175F5A780A75B){target=\_blank} | | Composable | xcIBCATOM | [0xffFFFffF6807D5082ff2f6F86BdE409245e2D953](https://moonscan.io/token/0xffFFFffF6807D5082ff2f6F86BdE409245e2D953){target=\_blank} | | Darwinia | xcRING | [0xFfffFfff5e90e365eDcA87fB4c8306Df1E91464f](https://moonscan.io/token/0xFfffFfff5e90e365eDcA87fB4c8306Df1E91464f){target=\_blank} | + | DED | xcDED | [0xfFffFFFf5da2d7214D268375cf8fb1715705FdC6](https://moonscan.io/token/0xfFffFFFf5da2d7214D268375cf8fb1715705FdC6){target=\_blank} | | Equilibrium | xcEQ | [0xFffFFfFf8f6267e040D8a0638C576dfBa4F0F6D6](https://moonscan.io/token/0xFffFFfFf8f6267e040D8a0638C576dfBa4F0F6D6){target=\_blank} | | Equilibrium | xcEQD | [0xFFffFfFF8cdA1707bAF23834d211B08726B1E499](https://moonscan.io/token/0xFFffFfFF8cdA1707bAF23834d211B08726B1E499){target=\_blank} | | HydraDX | xcHDX | [0xFFFfFfff345Dc44DDAE98Df024Eb494321E73FcC](https://moonscan.io/token/0xFFFfFfff345Dc44DDAE98Df024Eb494321E73FcC){target=\_blank} | @@ -82,13 +83,15 @@ The current list of available external XC-20 assets per network is as follows: | Nodle | xcNODL | [0xfffffffFe896ba7Cb118b9Fa571c6dC0a99dEfF1](https://moonscan.io/token/0xfffffffFe896ba7Cb118b9Fa571c6dC0a99dEfF1){target=\_blank} | | OriginTrail Parachain | xcOTP | [0xFfffffFfB3229c8E7657eABEA704d5e75246e544](https://moonscan.io/token/0xFfffffFfB3229c8E7657eABEA704d5e75246e544){target=\_blank} | | Parallel | xcPARA | [0xFfFffFFF18898CB5Fe1E88E668152B4f4052A947](https://moonscan.io/token/0xFfFffFFF18898CB5Fe1E88E668152B4f4052A947){target=\_blank} | - | Pendulum | xcPEN | [0xffffffff2257622f345e1acde0d4f46d7d1d77d0](https://moonscan.io/token/0xffffffff2257622f345e1acde0d4f46d7d1d77d0){target=\_blank} | + | Peaq | xcPEAQ | [0xFffFFFFFEC4908b74688a01374f789B48E9a3eab](https://moonscan.io/token/0xFffFFFFFEC4908b74688a01374f789B48E9a3eab){target=\_blank} | + | Pendulum | xcPEN | [0xffFFfFFf2257622F345E1ACDe0D4f46D7d1D77D0](https://moonscan.io/token/0xffFFfFFf2257622F345E1ACDe0D4f46D7d1D77D0){target=\_blank} | | Phala | xcPHA | [0xFFFfFfFf63d24eCc8eB8a7b5D0803e900F7b6cED](https://moonscan.io/token/0xFFFfFfFf63d24eCc8eB8a7b5D0803e900F7b6cED){target=\_blank} | | Polkadex | xcPDEX | [0xfFffFFFF43e0d9b84010b1b67bA501bc81e33C7A](https://moonscan.io/token/0xfFffFFFF43e0d9b84010b1b67bA501bc81e33C7A){target=\_blank} | | Polkadot Asset Hub | xcPINK | [0xfFfFFfFf30478fAFBE935e466da114E14fB3563d](https://moonscan.io/token/0xfFfFFfFf30478fAFBE935e466da114E14fB3563d){target=\_blank} | | Polkadot Asset Hub | xcUSDC | [0xFFfffffF7D2B0B761Af01Ca8e25242976ac0aD7D](https://moonscan.io/token/0xFFfffffF7D2B0B761Af01Ca8e25242976ac0aD7D){target=\_blank} | | Polkadot Asset Hub | xcUSDT | [0xFFFFFFfFea09FB06d082fd1275CD48b191cbCD1d](https://moonscan.io/token/0xFFFFFFfFea09FB06d082fd1275CD48b191cbCD1d){target=\_blank} | - | Subsocial | xcSUB | [0xffffffff43b4560bc0c451a3386e082bff50ac90](https://moonscan.io/token/0xffffffff43b4560bc0c451a3386e082bff50ac90){target=\_blank} | + | Subsocial | xcSUB | [0xfFfFffFf43B4560Bc0C451a3386E082bff50aC90](https://moonscan.io/token/0xfFfFffFf43B4560Bc0C451a3386E082bff50aC90){target=\_blank} | + | Unique | xcUNQ | [0xFffffFFFD58f77E6693CFB99EbE273d73C678DC2](https://moonscan.io/token/0xFffffFFFD58f77E6693CFB99EbE273d73C678DC2){target=\_blank} | | Zeitgeist | xcZTG | [0xFFFFfffF71815ab6142E0E20c7259126C6B40612](https://moonscan.io/token/0xFFFFfffF71815ab6142E0E20c7259126C6B40612){target=\_blank} | _*You can check each [Asset ID](https://polkadot.js.org/apps/?rpc=wss://wss.api.moonbeam.network#/assets){target=\_blank} on Polkadot.js Apps_