From e9e79197e284199b9bb74be38015c8724d22c9f8 Mon Sep 17 00:00:00 2001 From: Ashutosh Tripathi <39340292+ashucoder9@users.noreply.github.com> Date: Wed, 25 Sep 2024 18:55:08 +0530 Subject: [PATCH] Subnet 9000 Replacement (#1885) * initial replacement * meta changes * change few other mentions * moarrrrr changes * ai changes * Update x-chain-migration.mdx Signed-off-by: Owen * some changes * PoA fix * Update api.mdx Signed-off-by: Owen * small fixes * add: linkChecker, fix: majority of broken links * add cheerio as dev depend * fix gcp terraform link * fix hamburger subnet link * fix few commands * fix couple more commands * some fixes * add assets.website-files.com to whitelist * Update content/docs/api-reference/p-chain/api.mdx Co-authored-by: Meaghan FitzGerald Signed-off-by: Ashutosh Tripathi <39340292+ashucoder9@users.noreply.github.com> --------- Signed-off-by: Owen Signed-off-by: Ashutosh Tripathi <39340292+ashucoder9@users.noreply.github.com> Co-authored-by: owenwahlgren Co-authored-by: Meaghan FitzGerald --- .github/linkChecker.ts | 135 ++++++++ .github/workflows/checklinks.yml | 30 ++ app/(home)/page.tsx | 2 +- app/layout.config.tsx | 2 +- content/docs/api-reference/admin-api.mdx | 3 +- .../avalanche-go-configs-flags.mdx | 46 +-- content/docs/api-reference/c-chain/api.mdx | 12 +- .../docs/api-reference/c-chain/configs.mdx | 4 +- .../docs/api-reference/c-chain/txn-format.mdx | 1 + content/docs/api-reference/health-api.mdx | 4 +- content/docs/api-reference/index-api.mdx | 4 +- content/docs/api-reference/info-api.mdx | 17 +- content/docs/api-reference/install-script.mdx | 4 +- content/docs/api-reference/keystore-api.mdx | 1 + content/docs/api-reference/metrics-api.mdx | 2 +- content/docs/api-reference/p-chain/api.mdx | 108 +++--- .../docs/api-reference/p-chain/configs.mdx | 16 +- .../docs/api-reference/p-chain/txn-format.mdx | 100 +++--- content/docs/api-reference/rpc-providers.mdx | 18 +- .../standards/avalanche-network-protocol.mdx | 6 +- .../standards/cryptographic-primitives.mdx | 2 +- .../standards/guides/banff-changes.mdx | 17 +- .../standards/guides/blockchain-flow.mdx | 6 +- .../standards/guides/issuing-api-calls.mdx | 18 +- .../standards/guides/txn-fees.mdx | 14 +- .../standards/guides/x-chain-migration.mdx | 4 +- .../standards/serialization-primitives.mdx | 1 + content/docs/api-reference/subnet-evm-api.mdx | 2 +- content/docs/api-reference/x-chain/api.mdx | 7 +- .../docs/api-reference/x-chain/configs.mdx | 4 +- .../docs/api-reference/x-chain/txn-format.mdx | 1 + .../add-utility/cross-chain-bridge.mdx | 8 +- .../add-utility/deploy-smart-contract.mdx | 34 +- .../add-utility/testnet-faucet.mdx | 40 +-- .../avalanche-cli-avalanche-l1s.mdx} | 317 ++++++++--------- .../avalanche-l1-nodes.mdx} | 28 +- .../build-first-avalanche-l1.mdx} | 60 ++-- .../c-chain-or-avalanche-l1.mdx} | 34 +- .../avalanche-mainnet.mdx | 120 +++---- .../custom-virtual-machine.mdx | 26 +- .../deploy-a-avalanche-l1}/fuji-testnet.mdx | 138 ++++---- .../deploy-a-avalanche-l1}/local-network.mdx | 25 +- .../deploy-a-avalanche-l1}/multisig-auth.mdx | 100 +++--- .../production-infrastructure.mdx | 169 +++++++++ .../make-avalanche-l1-permissionless.mdx | 80 +++++ .../elastic-avalanche-l1s}/parameters.mdx | 32 +- content/docs/avalanche-l1s/index.mdx | 75 ++++ .../maintain/delete-avalanche-l1.mdx | 25 ++ .../maintain/pause-resume.mdx | 6 +- .../maintain/transfer-pchain-funds.mdx | 6 +- .../maintain/view-avalanche-l1s.mdx} | 14 +- content/docs/avalanche-l1s/meta.json | 35 ++ .../troubleshooting.mdx | 6 +- .../avalanche-l1-precompile-config.mdx} | 88 ++--- .../upgrade/avalanche-l1-virtual-machine.mdx} | 22 +- .../avalanche-l1s/upgrade/considerations.mdx | 119 +++++++ .../upgrade/customize-avalanche-l1.mdx} | 45 +-- .../upgrade/durango-upgrade.mdx | 10 +- .../wagmi-avalanche-l1.mdx} | 48 +-- .../avalanche-warp-messaging/deep-dive.mdx | 68 ++-- .../evm-integration.mdx | 83 ++--- .../avalanche-warp-messaging/overview.mdx | 36 +- .../avalanche-warp-messaging/run-relayer.mdx | 326 ++---------------- content/docs/cross-chain/index.mdx | 2 +- content/docs/cross-chain/teleporter/cli.mdx | 14 +- .../docs/cross-chain/teleporter/deep-dive.mdx | 179 ++++------ .../teleporter/getting-started.mdx | 21 +- .../docs/cross-chain/teleporter/overview.mdx | 90 ++--- .../teleporter/teleporter-on-devnet.mdx | 77 +++-- .../teleporter-on-local-network.mdx | 47 +-- .../cross-chain/teleporter/upgradeability.mdx | 159 ++++++--- .../add-network-programmatically.mdx | 10 +- .../advanced-tutorials/dynamic-gas-fees.mdx | 2 +- .../exchange-integration.mdx | 10 +- .../manually-adjust-gas-price.mdx | 2 +- content/docs/dapps/block-explorers.mdx | 3 +- content/docs/dapps/chain-settings.mdx | 6 +- .../deploy-nft-collection/deploy-erc-721.mdx | 3 +- .../dapps/deploy-nft-collection/index.mdx | 2 +- .../deploy-nft-collection/prep-nft-files.mdx | 2 +- .../docs/dapps/end-to-end/fuji-workflow.mdx | 36 +- .../dapps/end-to-end/launch-ethereum-dapp.mdx | 27 +- content/docs/dapps/index.mdx | 2 +- .../deploy-with-remix-ide.mdx | 8 +- .../dapps/smart-contract-dev/erc-20-token.mdx | 2 +- .../smart-contract-dev/get-test-funds.mdx | 1 + .../interact-golang-app.mdx | 1 + content/docs/dapps/toolchains/foundry.mdx | 6 +- content/docs/dapps/toolchains/hardhat.mdx | 8 +- content/docs/dapps/toolchains/index.mdx | 2 +- content/docs/dapps/toolchains/thirdweb.mdx | 3 +- .../docs/dapps/verify-contract/hardhat.mdx | 1 + content/docs/dapps/verify-contract/index.mdx | 2 +- .../docs/dapps/verify-contract/snowtrace.mdx | 8 +- .../learn/avalanche-community-proposals.mdx | 14 +- content/docs/learn/avalanche-consensus.mdx | 8 +- content/docs/learn/avalanche-l1s.mdx | 74 ++++ content/docs/learn/avax-token.mdx | 7 +- content/docs/learn/disclaimer.mdx | 4 + content/docs/learn/index.mdx | 7 +- content/docs/learn/meta.json | 2 +- content/docs/learn/networks/fuji-testnet.mdx | 4 +- content/docs/learn/networks/mainnet.mdx | 4 +- content/docs/learn/primary-network.mdx | 8 +- content/docs/learn/rewards-formula.mdx | 1 + content/docs/learn/subnets.mdx | 71 ---- content/docs/learn/virtual-machines.mdx | 16 +- content/docs/nodes/chain-configs/c-chain.mdx | 2 +- content/docs/nodes/chain-configs/overview.mdx | 8 +- content/docs/nodes/chain-configs/p-chain.mdx | 16 +- content/docs/nodes/chain-configs/x-chain.mdx | 2 +- ...t-configs.mdx => avalanche-l1-configs.mdx} | 44 +-- .../docs/nodes/configure/configs-flags.mdx | 39 ++- content/docs/nodes/index.mdx | 1 + .../docs/nodes/maintain/backup-restore.mdx | 4 +- content/docs/nodes/maintain/bootstrapping.mdx | 24 +- .../maintain/enroll-in-avalanche-notify.mdx | 2 +- content/docs/nodes/maintain/monitoring.mdx | 14 +- content/docs/nodes/maintain/upgrade.mdx | 2 +- content/docs/nodes/meta.json | 4 +- .../aws-marketplace.mdx | 6 +- .../on-third-party-services/google-cloud.mdx | 4 +- .../microsoft-azure.mdx | 105 +++--- .../run-a-node/avalanche-l1-nodes.mdx} | 26 +- content/docs/nodes/run-a-node/manually.mdx | 6 +- .../node-config-maintenance.mdx | 2 +- .../docs/nodes/validate/node-validator.mdx | 4 +- .../production-infrastructure.mdx | 169 --------- .../make-subnet-permissionless.mdx | 80 ----- content/docs/subnets/index.mdx | 75 ---- .../docs/subnets/maintain/delete-subnet.mdx | 24 -- content/docs/subnets/meta.json | 35 -- .../docs/subnets/upgrade/considerations.mdx | 119 ------- content/docs/tooling/avalanche-cli.mdx | 224 ++++++------ .../docs/tooling/avalanche-go-installer.mdx | 2 +- content/docs/tooling/avalanche-js.mdx | 4 +- .../avalanche-network-runner/anr-commands.mdx | 36 +- .../avalanche-network-runner/introduction.mdx | 18 +- .../docs/tooling/avalanche-plugin-manager.mdx | 4 +- .../add-postman-collection.mdx | 4 +- .../avalanche-postman/data-visualization.mdx | 4 +- .../avalanche-postman/making-api-calls.mdx | 6 +- .../tooling/avalanche-postman/variables.mdx | 4 +- .../deploy-custom-vm.mdx | 36 +- .../create-avalanche-nodes/run-loadtest.mdx | 10 +- .../run-validators-aws.mdx | 6 +- .../run-validators-gcp.mdx | 6 +- .../create-avalanche-nodes/setup-devnet.mdx | 14 +- ...e-subnet.mdx => validate-avalanche-l1.mdx} | 40 +-- .../validate-primary-network.mdx | 4 +- .../create-avalanche-l1.mdx} | 60 ++-- .../deploy-locally.mdx | 26 +- .../deploy-on-fuji-testnet.mdx | 114 +++--- .../deploy-on-mainnet.mdx | 92 ++--- .../create-deploy-avalanche-l1s/index.mdx | 5 + .../view-avalanche-l1s.mdx} | 14 +- .../tooling/create-deploy-subnets/index.mdx | 5 - .../tooling/cross-chain/teleporter-devnet.mdx | 28 +- .../cross-chain/teleporter-local-network.mdx | 34 +- .../cross-chain/teleporter-token-bridge.mdx | 54 +-- content/docs/tooling/glacier-api.mdx | 3 +- ...ort-subnet.mdx => import-avalanche-l1.mdx} | 40 +-- content/docs/tooling/meta.json | 2 +- content/docs/tooling/metrics-api.mdx | 2 +- content/docs/tooling/rpc-providers.mdx | 8 +- .../docs/tooling/transfer-p-chain-funds.mdx | 4 +- .../executing-test-cases.mdx | 2 +- .../evm-customization/introduction.mdx | 2 +- .../golang-vms/complex-golang-vm.mdx | 2 +- .../virtual-machines/manage-vm-binaries.mdx | 4 +- .../simple-vm-any-language.mdx | 2 +- .../virtual-machines/timestamp-vm/blocks.mdx | 8 +- content/integrations/ash.mdx | 2 +- content/integrations/avalanche-explorer.mdx | 28 +- content/integrations/biconomy.mdx | 2 +- content/integrations/chainlink-oracles.mdx | 2 +- content/integrations/goldrush.mdx | 2 +- content/integrations/privy.mdx | 10 +- content/integrations/zeeve.mdx | 4 +- editing-guides/remote-github-content-guide.md | 12 +- next-env.d.ts | 2 +- package.json | 4 +- public/images/azure1.png | Bin 0 -> 50214 bytes public/images/azure10.png | Bin 0 -> 73748 bytes public/images/azure11.png | Bin 0 -> 17472 bytes public/images/azure12.png | Bin 0 -> 11220 bytes public/images/azure13.png | Bin 0 -> 12981 bytes public/images/azure14.png | Bin 0 -> 46461 bytes public/images/azure15.png | Bin 0 -> 98800 bytes public/images/azure16.png | Bin 0 -> 51442 bytes public/images/azure17.png | Bin 0 -> 19705 bytes public/images/azure19.png | Bin 0 -> 10141 bytes public/images/azure2.png | Bin 0 -> 45209 bytes public/images/azure20.png | Bin 0 -> 12888 bytes public/images/azure21.png | Bin 0 -> 21103 bytes public/images/azure22.png | Bin 0 -> 12094 bytes public/images/azure23.png | Bin 0 -> 50194 bytes public/images/azure24.png | Bin 0 -> 48329 bytes public/images/azure25.png | Bin 0 -> 44985 bytes public/images/azure26.png | Bin 0 -> 21487 bytes public/images/azure27.png | Bin 0 -> 34519 bytes public/images/azure28.png | Bin 0 -> 84852 bytes public/images/azure29.png | Bin 0 -> 17964 bytes public/images/azure3.png | Bin 0 -> 21545 bytes public/images/azure30.png | Bin 0 -> 31714 bytes public/images/azure31.png | Bin 0 -> 43351 bytes public/images/azure32.png | Bin 0 -> 52470 bytes public/images/azure33.png | Bin 0 -> 33929 bytes public/images/azure34.png | Bin 0 -> 73049 bytes public/images/azure35.png | Bin 0 -> 38376 bytes public/images/azure36.png | Bin 0 -> 40963 bytes public/images/azure37.png | Bin 0 -> 50780 bytes public/images/azure38.png | Bin 0 -> 38778 bytes public/images/azure39.png | Bin 0 -> 26536 bytes public/images/azure4.png | Bin 0 -> 24967 bytes public/images/azure40.png | Bin 0 -> 15589 bytes public/images/azure41.png | Bin 0 -> 19813 bytes public/images/azure42.png | Bin 0 -> 30071 bytes public/images/azure43.png | Bin 0 -> 10656 bytes public/images/azure44.png | Bin 0 -> 9808 bytes public/images/azure45.png | Bin 0 -> 42559 bytes public/images/azure46.png | Bin 0 -> 81238 bytes public/images/azure47.png | Bin 0 -> 5854 bytes public/images/azure5.png | Bin 0 -> 67752 bytes public/images/azure6.png | Bin 0 -> 27113 bytes public/images/azure7.png | Bin 0 -> 22586 bytes public/images/azure8.png | Bin 0 -> 93106 bytes public/images/azure9.png | Bin 0 -> 19828 bytes public/images/erpc.webp | Bin 0 -> 211414 bytes scripts/avalanchego-installer.sh | 2 +- utils/remote-content.mts | 6 +- 231 files changed, 2770 insertions(+), 2826 deletions(-) create mode 100644 .github/linkChecker.ts create mode 100644 .github/workflows/checklinks.yml rename content/docs/{subnets => avalanche-l1s}/add-utility/cross-chain-bridge.mdx (97%) rename content/docs/{subnets => avalanche-l1s}/add-utility/deploy-smart-contract.mdx (65%) rename content/docs/{subnets => avalanche-l1s}/add-utility/testnet-faucet.mdx (88%) rename content/docs/{subnets/avalanche-cli-subnets.mdx => avalanche-l1s/avalanche-cli-avalanche-l1s.mdx} (74%) rename content/docs/{nodes/run-a-node/subnet-nodes.mdx => avalanche-l1s/avalanche-l1-nodes.mdx} (73%) rename content/docs/{subnets/build-first-subnet.mdx => avalanche-l1s/build-first-avalanche-l1.mdx} (70%) rename content/docs/{subnets/c-chain-or-subnet.mdx => avalanche-l1s/c-chain-or-avalanche-l1.mdx} (50%) rename content/docs/{subnets/deploy-a-subnet => avalanche-l1s/deploy-a-avalanche-l1}/avalanche-mainnet.mdx (75%) rename content/docs/{subnets/deploy-a-subnet => avalanche-l1s/deploy-a-avalanche-l1}/custom-virtual-machine.mdx (86%) rename content/docs/{subnets/deploy-a-subnet => avalanche-l1s/deploy-a-avalanche-l1}/fuji-testnet.mdx (80%) rename content/docs/{subnets/deploy-a-subnet => avalanche-l1s/deploy-a-avalanche-l1}/local-network.mdx (76%) rename content/docs/{subnets/deploy-a-subnet => avalanche-l1s/deploy-a-avalanche-l1}/multisig-auth.mdx (71%) create mode 100644 content/docs/avalanche-l1s/deploy-a-avalanche-l1/production-infrastructure.mdx create mode 100644 content/docs/avalanche-l1s/elastic-avalanche-l1s/make-avalanche-l1-permissionless.mdx rename content/docs/{subnets/elastic-subnets => avalanche-l1s/elastic-avalanche-l1s}/parameters.mdx (84%) create mode 100644 content/docs/avalanche-l1s/index.mdx create mode 100644 content/docs/avalanche-l1s/maintain/delete-avalanche-l1.mdx rename content/docs/{subnets => avalanche-l1s}/maintain/pause-resume.mdx (95%) rename content/docs/{subnets => avalanche-l1s}/maintain/transfer-pchain-funds.mdx (97%) rename content/docs/{subnets/maintain/view-subnets.mdx => avalanche-l1s/maintain/view-avalanche-l1s.mdx} (92%) create mode 100644 content/docs/avalanche-l1s/meta.json rename content/docs/{subnets => avalanche-l1s}/troubleshooting.mdx (95%) rename content/docs/{subnets/upgrade/subnet-precompile-config.mdx => avalanche-l1s/upgrade/avalanche-l1-precompile-config.mdx} (78%) rename content/docs/{subnets/upgrade/subnet-virtual-machine.mdx => avalanche-l1s/upgrade/avalanche-l1-virtual-machine.mdx} (50%) create mode 100644 content/docs/avalanche-l1s/upgrade/considerations.mdx rename content/docs/{subnets/upgrade/customize-subnet.mdx => avalanche-l1s/upgrade/customize-avalanche-l1.mdx} (94%) rename content/docs/{subnets => avalanche-l1s}/upgrade/durango-upgrade.mdx (94%) rename content/docs/{subnets/wagmi-subnet.mdx => avalanche-l1s/wagmi-avalanche-l1.mdx} (72%) create mode 100644 content/docs/learn/avalanche-l1s.mdx delete mode 100644 content/docs/learn/subnets.mdx rename content/docs/nodes/configure/{subnet-configs.mdx => avalanche-l1-configs.mdx} (72%) rename content/docs/{subnets/subnet-nodes.mdx => nodes/run-a-node/avalanche-l1-nodes.mdx} (74%) delete mode 100644 content/docs/subnets/deploy-a-subnet/production-infrastructure.mdx delete mode 100644 content/docs/subnets/elastic-subnets/make-subnet-permissionless.mdx delete mode 100644 content/docs/subnets/index.mdx delete mode 100644 content/docs/subnets/maintain/delete-subnet.mdx delete mode 100644 content/docs/subnets/meta.json delete mode 100644 content/docs/subnets/upgrade/considerations.mdx rename content/docs/tooling/create-avalanche-nodes/{validate-subnet.mdx => validate-avalanche-l1.mdx} (60%) rename content/docs/tooling/{create-deploy-subnets/create-subnet.mdx => create-deploy-avalanche-l1s/create-avalanche-l1.mdx} (69%) rename content/docs/tooling/{create-deploy-subnets => create-deploy-avalanche-l1s}/deploy-locally.mdx (74%) rename content/docs/tooling/{create-deploy-subnets => create-deploy-avalanche-l1s}/deploy-on-fuji-testnet.mdx (82%) rename content/docs/tooling/{create-deploy-subnets => create-deploy-avalanche-l1s}/deploy-on-mainnet.mdx (79%) create mode 100644 content/docs/tooling/create-deploy-avalanche-l1s/index.mdx rename content/docs/tooling/{create-deploy-subnets/view-subnets.mdx => create-deploy-avalanche-l1s/view-avalanche-l1s.mdx} (95%) delete mode 100644 content/docs/tooling/create-deploy-subnets/index.mdx rename content/docs/tooling/guides/{import-subnet.mdx => import-avalanche-l1.mdx} (65%) create mode 100644 public/images/azure1.png create mode 100644 public/images/azure10.png create mode 100644 public/images/azure11.png create mode 100644 public/images/azure12.png create mode 100644 public/images/azure13.png create mode 100644 public/images/azure14.png create mode 100644 public/images/azure15.png create mode 100644 public/images/azure16.png create mode 100644 public/images/azure17.png create mode 100644 public/images/azure19.png create mode 100644 public/images/azure2.png create mode 100644 public/images/azure20.png create mode 100644 public/images/azure21.png create mode 100644 public/images/azure22.png create mode 100644 public/images/azure23.png create mode 100644 public/images/azure24.png create mode 100644 public/images/azure25.png create mode 100644 public/images/azure26.png create mode 100644 public/images/azure27.png create mode 100644 public/images/azure28.png create mode 100644 public/images/azure29.png create mode 100644 public/images/azure3.png create mode 100644 public/images/azure30.png create mode 100644 public/images/azure31.png create mode 100644 public/images/azure32.png create mode 100644 public/images/azure33.png create mode 100644 public/images/azure34.png create mode 100644 public/images/azure35.png create mode 100644 public/images/azure36.png create mode 100644 public/images/azure37.png create mode 100644 public/images/azure38.png create mode 100644 public/images/azure39.png create mode 100644 public/images/azure4.png create mode 100644 public/images/azure40.png create mode 100644 public/images/azure41.png create mode 100644 public/images/azure42.png create mode 100644 public/images/azure43.png create mode 100644 public/images/azure44.png create mode 100644 public/images/azure45.png create mode 100644 public/images/azure46.png create mode 100644 public/images/azure47.png create mode 100644 public/images/azure5.png create mode 100644 public/images/azure6.png create mode 100644 public/images/azure7.png create mode 100644 public/images/azure8.png create mode 100644 public/images/azure9.png create mode 100644 public/images/erpc.webp diff --git a/.github/linkChecker.ts b/.github/linkChecker.ts new file mode 100644 index 00000000000..a769338ad00 --- /dev/null +++ b/.github/linkChecker.ts @@ -0,0 +1,135 @@ +import get from 'axios'; +import { readFileSync } from 'fs'; +import { load } from 'cheerio'; +import { sync as globSync } from 'glob'; + +const baseUrl = 'http://localhost:3000'; // base url of the website + +const whitelist = ["crates.io", "softwaretestinghelp.com", "coinbase.com", "assets.website-files.com"] // some websites return 404 for head requests, so we need to whitelist them, (fix: pass header -H 'Accept: text/html' and parse text/html) + // see https://github.com/rust-lang/crates.io/issues/788 + +interface LinkCheckResult { + file: string; + link: string; + line: number; + isValid: boolean; +} + +function isValidURLOrPath(url: string): boolean { + try { + new URL(url) + return true + } catch { + if (url.startsWith("{") && url.endsWith("}")) { // is a a JSX component, ignore + return false; + } + else if (url.indexOf('.') > -1) { // is a url or misconfigured path + return true; + } + // where all our content lives + return url.startsWith("/"); + } +} + +async function checkLink(url: string): Promise { + try { + const response = await get(url, { + timeout: 20000, // timeout to 20 seconds + maxRedirects: 5, // handle up to 5 redirects + validateStatus: function (status) { + return status >= 200 && status < 400; // resolve only if the status code is less than 400 + }, + headers: { + 'User-Agent': 'Mozilla/5.0 (compatible; LinkChecker/1.0)', // Custom User-Agent + } + }); + return response.status === 200; + } catch { + return false; + } +} + +function extractLinksWithLineNumbers(mdxContent: string): { link: string; line: number }[] { + const lines = mdxContent.split('\n'); + const links: { link: string; line: number }[] = []; + + lines.forEach((line, index) => { + const $ = load(`
${line}
`); + $('a').each((i, elem) => { + const href = $(elem).attr('href'); + if (href && isValidURLOrPath(href)) { + links.push({ link: href, line: index + 1 }); + } + }); + + const markdownLinkRegex = /\[.*?\]\((.*?)\)/g; + let match; + while ((match = markdownLinkRegex.exec(line)) !== null) { + const link = match[1]; + if (isValidURLOrPath(link)) { + links.push({ link, line: index + 1 }); + } + } + }); + + return links; +} + +async function checkAllMdxFiles(): Promise { + const files = globSync('content/**/*.mdx'); + console.log(`Found ${files.length} MDX files.`); + + const results: LinkCheckResult[] = []; + + for (const file of files) { + console.log(`Processing file: ${file}`); + + const content = readFileSync(file, 'utf-8'); + const links = extractLinksWithLineNumbers(content); + + const cache: { [link: string]: boolean } = {}; + let isValid: boolean; + + for (const { link, line } of links) { + console.log(`Checking link: ${link} in file: ${file} (line ${line})`); + + if (cache[link]) { + isValid = cache[link]; + } else { + isValid = await checkLink(link); // check the link + if (!isValid) { + isValid = await checkLink(baseUrl + link); // if link failed check first time, try adding the base url (for internal relative links) + } + for (const wl of whitelist) { + if (link.includes(wl)) { + isValid = true; + break; + } + } + cache[link] = isValid; + } + results.push({ file, link, line, isValid }); + + if (!isValid) { + console.error(`\x1b[31mBroken link found\x1b[0m in ${file} (line ${line}): \x1b[33m${link}\x1b[0m`); + } + } + } + + + const brokenLinks = results.filter(result => !result.isValid); + if (brokenLinks.length > 0) { + console.error(`\n\x1b[31mSummary of broken links:\x1b[0m`); + brokenLinks.forEach(result => { + console.error(`File: \x1b[36m${result.file}\x1b[0m, Line: \x1b[33m${result.line}\x1b[0m, Link: \x1b[31m${result.link}\x1b[0m`); + }); + process.exit(1); + } else { + console.log(`\x1b[32mAll links are valid.\x1b[0m`); + } +} + +checkAllMdxFiles().catch(error => { + console.error('\x1b[31mError checking links:\x1b[0m', error); + process.exit(1); +}); diff --git a/.github/workflows/checklinks.yml b/.github/workflows/checklinks.yml new file mode 100644 index 00000000000..52bdb03bdc3 --- /dev/null +++ b/.github/workflows/checklinks.yml @@ -0,0 +1,30 @@ +name: Check MDX Links + +on: + pull_request: + paths: + - '**/*.mdx' + branches: [master] + +jobs: + check-links: + runs-on: ubuntu-latest + steps: + - uses: actions/checkout@v3 + - uses: actions/setup-node@v3 + with: + node-version: '19' + - name: Install dependencies + run: | + yarn install --frozen-lockfile + yarn global add tsx wait-on + - name: Start Dev Server in Background + run: | + yarn dev & + - name: Wait for Dev Server to be Ready + run: | + wait-on http://localhost:3000 + - name: Check links + run: yarn check-links + - name: Stop Dev Server + run: kill $(jobs -p) || true \ No newline at end of file diff --git a/app/(home)/page.tsx b/app/(home)/page.tsx index cccc9ef4fac..8e3ea1e04ec 100644 --- a/app/(home)/page.tsx +++ b/app/(home)/page.tsx @@ -55,7 +55,7 @@ function Highlights(): React.ReactElement { Your one stop shop to deploy smart contracts on the Avalanche C-Chain. - + Utilize the Avalanche tech stack to build your own L1 blockchain. diff --git a/app/layout.config.tsx b/app/layout.config.tsx index 2b24f064c2b..48affe900dd 100644 --- a/app/layout.config.tsx +++ b/app/layout.config.tsx @@ -52,7 +52,7 @@ export const docsOptions: DocsLayoutProps = { title: 'Avalanche L1s', description: 'Build Your L1 Blockchain', icon: , - url: '/subnets', + url: '/avalanche-l1s', }, { title: 'Virtual Machines', diff --git a/content/docs/api-reference/admin-api.mdx b/content/docs/api-reference/admin-api.mdx index 4a17f994dda..13695292bc8 100644 --- a/content/docs/api-reference/admin-api.mdx +++ b/content/docs/api-reference/admin-api.mdx @@ -74,7 +74,7 @@ Give a blockchain an alias, a different name that can be used any place the bloc Aliasing a chain can also be done via the [Node API](/nodes/configure/configs-flags#--chain-aliases-file-string). -Note that the alias is set for each chain on each node individually. In a multi-node Subnet, the same alias should be configured on each node to use an alias across a Subnet successfully. Setting an alias for a chain on one node does not register that alias with other nodes automatically. +Note that the alias is set for each chain on each node individually. In a multi-node Avalanche L1, the same alias should be configured on each node to use an alias across an Avalanche L1 successfully. Setting an alias for a chain on one node does not register that alias with other nodes automatically. **Signature**: @@ -428,3 +428,4 @@ curl -X POST --data '{ } ``` + diff --git a/content/docs/api-reference/avalanche-go-configs-flags.mdx b/content/docs/api-reference/avalanche-go-configs-flags.mdx index 63ae38255e4..fd97487e84c 100644 --- a/content/docs/api-reference/avalanche-go-configs-flags.mdx +++ b/content/docs/api-reference/avalanche-go-configs-flags.mdx @@ -153,7 +153,7 @@ The chain configs are passed in from the location `chain-config-dir`/`blockchain Full reference for all configuration options for some standard chains can be found in a separate [chain config flags](/nodes/configure/configs-flags) document. -Full reference for `subnet-evm` upgrade configuration can be found in a separate [Customize a Subnet](/subnets/upgrade/customize-subnet) document. +Full reference for `subnet-evm` upgrade configuration can be found in a separate [Customize an Avalanche L1](/avalanche-l1s/upgrade/customize-avalanche-l1) document. #### `--chain-config-content` (string)[​](#--chain-config-content-string "Direct link to heading") @@ -177,7 +177,7 @@ Path to JSON file that defines aliases for Blockchain IDs. Defaults to `~/.avala } ``` -The above example aliases the Blockchain whose ID is `"q2aTwKuyzgs8pynF7UXBZCU7DejbZbZ6EUyHr3JQzYgwNPUPi"` to `"DFK"`. Chain aliases are added after adding primary network aliases and before any changes to the aliases via the admin API. This means that the first alias included for a Blockchain on a Subnet will be treated as the `"Primary Alias"` instead of the full blockchainID. The Primary Alias is used in all metrics and logs. +The above example aliases the Blockchain whose ID is `"q2aTwKuyzgs8pynF7UXBZCU7DejbZbZ6EUyHr3JQzYgwNPUPi"` to `"DFK"`. Chain aliases are added after adding primary network aliases and before any changes to the aliases via the admin API. This means that the first alias included for a Blockchain on an Avalanche L1 will be treated as the `"Primary Alias"` instead of the full blockchainID. The Primary Alias is used in all metrics and logs. #### `--chain-aliases-file-content` (string)[​](#--chain-aliases-file-content-string "Direct link to heading") @@ -566,26 +566,26 @@ Avalanche uses two-way authenticated TLS connections to securely connect nodes. As an alternative to `--staking-tls-key-file`, it allows specifying base64 encoded content of the TLS private key used by the node. Note that full private key content, with the leading and trailing header, must be base64 encoded. -Subnets[​](#subnets "Direct link to heading") +Avalanche L1s[​](#avalanche-l1s "Direct link to heading") --------------------------------------------- -### Subnet Tracking[​](#subnet-tracking "Direct link to heading") +### Avalanche L1 Tracking[​](#avalanche-l1-tracking "Direct link to heading") -#### `--track-subnets` (string)[​](#--track-subnets-string "Direct link to heading") +#### `--track-subnets` (string)[​](#--track-avalanche-l1s-string "Direct link to heading") -Comma separated list of Subnet IDs that this node would track if added to. Defaults to empty (will only validate the Primary Network). +Comma separated list of Avalanche L1 `SubnetID`s that this node would track if added to. Defaults to empty (will only validate the Primary Network). -### Subnet Configs[​](#subnet-configs "Direct link to heading") +### Avalanche L1 Configs[​](#avalanche-l1-configs "Direct link to heading") -It is possible to provide parameters for Subnets. Parameters here apply to all chains in the specified Subnets. Parameters must be specified with a `{subnetID}.json` config file under `--subnet-config-dir`. AvalancheGo loads configs for Subnets specified in `--track-subnets` parameter. +It is possible to provide parameters for Avalanche L1s. Parameters here apply to all chains in the specified Avalanche L1s. Parameters must be specified with a `{subnetID}.json` config file under `--subnet-config-dir`. AvalancheGo loads configs for Avalanche L1s specified in `--track-subnets` parameter. -Full reference for all configuration options for a Subnet can be found in a separate [Subnet Configs](/nodes/configure/subnet-configs) document. +Full reference for all configuration options for an Avalanche L1 can be found in a separate [Avalanche L1 Configs](/nodes/configure/avalanche-l1-configs) document. -#### `--subnet-config-dir` (`string`)[​](#--subnet-config-dir-string "Direct link to heading") +#### `--subnet-config-dir` (`string`)[​](#--avalanche-l1-config-dir-string "Direct link to heading") -Specifies the directory that contains Subnet configs, as described above. Defaults to `$HOME/.avalanchego/configs/subnets`. If the flag is set explicitly, the specified folder must exist, or AvalancheGo will exit with an error. This flag is ignored if `--subnet-config-content` is specified. +Specifies the directory that contains Avalanche L1 configs, as described above. Defaults to `$HOME/.avalanchego/configs/subnets`. If the flag is set explicitly, the specified folder must exist, or AvalancheGo will exit with an error. This flag is ignored if `--subnet-config-content` is specified. -Example: Let's say we have a Subnet with ID `p4jUwqZsA2LuSftroCd3zb4ytH8W99oXKuKVZdsty7eQ3rXD6`. We can create a config file under the default `subnet-config-dir` at `$HOME/.avalanchego/configs/subnets/p4jUwqZsA2LuSftroCd3zb4ytH8W99oXKuKVZdsty7eQ3rXD6.json`. An example config file is: +Example: Let's say we have an Avalanche L1 with ID `p4jUwqZsA2LuSftroCd3zb4ytH8W99oXKuKVZdsty7eQ3rXD6`. We can create a config file under the default `subnet-config-dir` at `$HOME/.avalanchego/configs/subnets/p4jUwqZsA2LuSftroCd3zb4ytH8W99oXKuKVZdsty7eQ3rXD6.json`. An example config file is: ``` { @@ -601,9 +601,9 @@ Example: Let's say we have a Subnet with ID `p4jUwqZsA2LuSftroCd3zb4ytH8W99oXKuK } > By default, none of these directories and/or files exist. You would need to create them manually if needed. -#### `--subnet-config-content` (string)[​](#--subnet-config-content-string "Direct link to heading") +#### `--subnet-config-content` (string)[​](#--avalanche-l1-config-content-string "Direct link to heading") -As an alternative to `--subnet-config-dir`, it allows specifying base64 encoded parameters for a Subnet. +As an alternative to `--subnet-config-dir`, it allows specifying base64 encoded parameters for an Avalanche L1. Version[​](#version "Direct link to heading") --------------------------------------------- @@ -676,17 +676,17 @@ Timeout before killing an unresponsive chain. Defaults to `5s`. Transaction fee, in nAVAX, for transactions that create new assets. Defaults to `10000000` nAVAX (.01 AVAX) per transaction. This can only be changed on a local network. -#### `--create-subnet-tx-fee` (int)[​](#--create-subnet-tx-fee-int "Direct link to heading") +#### `--create-subnet-tx-fee` (int)[​](#--create-avalanche-l1-tx-fee-int "Direct link to heading") -Transaction fee, in nAVAX, for transactions that create new Subnets. Defaults to `1000000000` nAVAX (1 AVAX) per transaction. This can only be changed on a local network. +Transaction fee, in nAVAX, for transactions that create new Avalanche L1s. Defaults to `1000000000` nAVAX (1 AVAX) per transaction. This can only be changed on a local network. #### `--create-blockchain-tx-fee` (int)[​](#--create-blockchain-tx-fee-int "Direct link to heading") Transaction fee, in nAVAX, for transactions that create new blockchains. Defaults to `1000000000` nAVAX (1 AVAX) per transaction. This can only be changed on a local network. -#### `--transform-subnet-tx-fee` (int)[​](#--transform-subnet-tx-fee-int "Direct link to heading") +#### `--transform-subnet-tx-fee` (int)[​](#--transform-avalanche-l1-tx-fee-int "Direct link to heading") -Transaction fee, in nAVAX, for transactions that transform Subnets. Defaults to `1000000000` nAVAX (1 AVAX) per transaction. This can only be changed on a local network. +Transaction fee, in nAVAX, for transactions that transform Avalanche L1s. Defaults to `1000000000` nAVAX (1 AVAX) per transaction. This can only be changed on a local network. #### `--add-primary-network-validator-fee` (int)[​](#--add-primary-network-validator-fee-int "Direct link to heading") @@ -696,13 +696,13 @@ Transaction fee, in nAVAX, for transactions that add new primary network validat Transaction fee, in nAVAX, for transactions that add new primary network delegators. Defaults to 0. This can only be changed on a local network. -#### `--add-subnet-validator-fee` (int)[​](#--add-subnet-validator-fee-int "Direct link to heading") +#### `--add-subnet-validator-fee` (int)[​](#--add-avalanche-l1-validator-fee-int "Direct link to heading") -Transaction fee, in nAVAX, for transactions that add new Subnet validators. Defaults to `10000000` nAVAX (.01 AVAX). +Transaction fee, in nAVAX, for transactions that add new Avalanche L1 validators. Defaults to `10000000` nAVAX (.01 AVAX). -#### `--add-subnet-delegator-fee` (int)[​](#--add-subnet-delegator-fee-int "Direct link to heading") +#### `--add-subnet-delegator-fee` (int)[​](#--add-avalanche-l1-delegator-fee-int "Direct link to heading") -Transaction fee, in nAVAX, for transactions that add new Subnet delegators. Defaults to `10000000` nAVAX (.01 AVAX). +Transaction fee, in nAVAX, for transactions that add new Avalanche L1 delegators. Defaults to `10000000` nAVAX (.01 AVAX). #### `--min-delegator-stake` (int)[​](#--min-delegator-stake-int "Direct link to heading") @@ -1139,4 +1139,4 @@ Node reports unhealthy if the router drops more than this portion of messages. D #### `--router-health-max-outstanding-requests` (uint)[​](#--router-health-max-outstanding-requests-uint "Direct link to heading") -Node reports unhealthy if there are more than this many outstanding consensus requests (Get, PullQuery, etc.) over all chains. Defaults to `1024`. \ No newline at end of file +Node reports unhealthy if there are more than this many outstanding consensus requests (Get, PullQuery, etc.) over all chains. Defaults to `1024`. diff --git a/content/docs/api-reference/c-chain/api.mdx b/content/docs/api-reference/c-chain/api.mdx index 40d65043e17..388f3f40af1 100644 --- a/content/docs/api-reference/c-chain/api.mdx +++ b/content/docs/api-reference/c-chain/api.mdx @@ -29,7 +29,7 @@ where `blockchainID` is the ID of the blockchain running the EVM. #### WebSocket Endpoints -On the [public API node](/tooling/rpc-providers#supported-apis), it only supports C-Chain +On the [public API node](/tooling/rpc-providers), it only supports C-Chain websocket API calls for API methods that don't exist on the C-Chain's HTTP API @@ -290,7 +290,7 @@ Not recommended for use on Mainnet. See warning notice in [Keystore API](/api-re Export an asset from the C-Chain to X-Chain or P-Chain. If exporting to the X-Chain, you must call the -X-Chain's [`avm.import`](/api-reference/x-chain/api.md#avmimport). +X-Chain's [`avm.import`](/api-reference/x-chain/api#avmimport). **Signature:** @@ -348,10 +348,10 @@ curl -X POST --data '{ Not recommended for use on Mainnet. See warning notice in [Keystore API](/api-reference/keystore-api). -**DEPRECATED—instead use** [`avax.export`](/api-reference/c-chain/api.md#avaxexport). +**DEPRECATED—instead use** [`avax.export`](/api-reference/c-chain/api#avaxexport). Send AVAX from the C-Chain to X-Chain or P-Chain. If exporting to the X-Chain, you must call the -X-Chain's [`avm.import`](/api-reference/x-chain/api.md#avmimport) with assetID `AVAX` +X-Chain's [`avm.import`](/api-reference/x-chain/api#avmimport) with assetID `AVAX` on the X-Chain to complete the transfer. **Signature:** @@ -727,7 +727,7 @@ curl -X POST --data '{ Not recommended for use on Mainnet. See warning notice in [Keystore API](/api-reference/keystore-api). -**DEPRECATED—instead use** [`avax.import`](/api-reference/c-chain/api.md#avaximport) +**DEPRECATED—instead use** [`avax.import`](/api-reference/c-chain/api#avaximport) Finalize a transfer of AVAX from the X-Chain or P-Chain to the C-Chain. @@ -1049,4 +1049,4 @@ curl -X POST --data '{ "id": 1, "result": {} } -``` \ No newline at end of file +``` diff --git a/content/docs/api-reference/c-chain/configs.mdx b/content/docs/api-reference/c-chain/configs.mdx index d41d070485f..b5b1bd0ca62 100644 --- a/content/docs/api-reference/c-chain/configs.mdx +++ b/content/docs/api-reference/c-chain/configs.mdx @@ -772,7 +772,7 @@ by deleting old trie nodes. **While performing offline pruning, your node will not be able to process blocks and will be considered offline.** While ongoing, the pruning process consumes a small amount of additional disk space (for deletion markers and the bloom filter). For more information see -[here.](/nodes/maintain/run-offline-pruning.md#disk-space-considerations) +[here.](/nodes/maintain/reduce-disk-usage#running-offline-pruning) Since offline pruning deletes old state data, this should not be run on nodes that need to support archival API requests. @@ -850,4 +850,4 @@ _Boolean_ If set to `true`, the chain will skip verifying that all expected network upgrades have taken place before the last accepted block on startup. This allows node operators to recover if their node has accepted blocks after a network -upgrade with a version of the code prior to the upgrade. Defaults to `false`. \ No newline at end of file +upgrade with a version of the code prior to the upgrade. Defaults to `false`. diff --git a/content/docs/api-reference/c-chain/txn-format.mdx b/content/docs/api-reference/c-chain/txn-format.mdx index 1ee59ad3aed..815eb35c53e 100644 --- a/content/docs/api-reference/c-chain/txn-format.mdx +++ b/content/docs/api-reference/c-chain/txn-format.mdx @@ -966,3 +966,4 @@ Let's make a UTXO from the signed transaction created above: 0x24, 0x25, 0x26, 0x27, ] ``` + diff --git a/content/docs/api-reference/health-api.mdx b/content/docs/api-reference/health-api.mdx index 4f2be558a5c..e6aefb42977 100644 --- a/content/docs/api-reference/health-api.mdx +++ b/content/docs/api-reference/health-api.mdx @@ -37,7 +37,7 @@ curl 'http://localhost:9650/ext/health?tag=29uVeLPJB1eQJkzRemU8g8wZDw5uJRqpab5U2 In this example returned results will contain global health checks and health checks that are related to subnetID `29uVeLPJB1eQJkzRemU8g8wZDw5uJRqpab5U2mX9euieVwiEbL`. -**Note**: This filtering can show healthy results even if the node is unhealthy in other Chains/Subnets. +**Note**: This filtering can show healthy results even if the node is unhealthy in other Chains/Avalanche L1s. In order to filter results by multiple tags, use multiple `tag` query parameters. For example, to filter health results by subnetID `29uVeLPJB1eQJkzRemU8g8wZDw5uJRqpab5U2mX9euieVwiEbL` and `28nrH5T2BMvNrWecFcV3mfccjs6axM1TVyqe79MCv2Mhs8kxiY` use the following query: @@ -280,4 +280,4 @@ In this example response, the node was able to handle the request and mark the s **Response Explanation**: - `checks` is an empty list. -- `healthy` is true. \ No newline at end of file +- `healthy` is true. diff --git a/content/docs/api-reference/index-api.mdx b/content/docs/api-reference/index-api.mdx index 787c38c28b7..6f47112ff38 100644 --- a/content/docs/api-reference/index-api.mdx +++ b/content/docs/api-reference/index-api.mdx @@ -437,9 +437,6 @@ Example: Iterating Through X-Chain Transaction[​](#example-iterating-through-x Here is an example of how to iterate through all transactions on the X-Chain. - -To help users to try out this example and other index APIs, we have set up a testing indexer node located at [https://indexer-demo.avax.network](https://indexer-demo.avax.network/). This indexer node is not for production use. We may change or shut it down at any time without notice. - You can use the Index API to get the ID of every transaction that has been accepted on the X-Chain, and use the X-Chain API method `avm.getTx` to get a human-readable representation of the transaction. To get an X-Chain transaction by its index (the order it was accepted in), use Index API method [index.getlastaccepted](#indexgetlastaccepted). @@ -557,3 +554,4 @@ Response: } ``` + diff --git a/content/docs/api-reference/info-api.mdx b/content/docs/api-reference/info-api.mdx index 6a0297fd109..2f51e77b2ec 100644 --- a/content/docs/api-reference/info-api.mdx +++ b/content/docs/api-reference/info-api.mdx @@ -413,13 +413,13 @@ info.getTxFee() -> - `txFee` is the default fee for making transactions. - `createAssetTxFee` is the fee for creating a new asset. -- `createSubnetTxFee` is the fee for creating a new Subnet. -- `transformSubnetTxFee` is the fee for converting a PoA Subnet into a PoS Subnet. +- `createSubnetTxFee` is the fee for creating a new Avalanche L1. +- `transformSubnetTxFee` is the fee for converting a PoA Avalanche L1 into a PoS Avalanche L1. - `createBlockchainTxFee` is the fee for creating a new blockchain. - `addPrimaryNetworkValidatorFee` is the fee for adding a new primary network validator. - `addPrimaryNetworkDelegatorFee` is the fee for adding a new primary network delegator. -- `addSubnetValidatorFee` is the fee for adding a new Subnet validator. -- `addSubnetDelegatorFee` is the fee for adding a new Subnet delegator. +- `addSubnetValidatorFee` is the fee for adding a new Avalanche L1 validator. +- `addSubnetDelegatorFee` is the fee for adding a new Avalanche L1 delegator. All fees are denominated in nAVAX. @@ -534,7 +534,7 @@ info.peers({ - `lastReceived` is the timestamp of last message received from the peer. - `benched` shows chain IDs that the peer is being benched. - `observedUptime` is this node's primary network uptime, observed by the peer. -- `observedSubnetUptime` is a map of Subnet IDs to this node's Subnet uptimes, observed by the peer. +- `observedSubnetUptime` is a map of Avalanche L1 IDs (SubnetIDs) to this node's Avalanche L1 uptimes, observed by the peer. **Example Call**: @@ -622,7 +622,7 @@ info.uptime({ } ``` -- `subnetID` is the Subnet to get the uptime of. If not provided, returns the uptime of the node on the primary network. +- `subnetID` is the Avalanche L1 to get the uptime of. If not provided, returns the uptime of the node on the primary network. - `rewardingStakePercentage` is the percent of stake which thinks this node is above the uptime requirement. - `weightedAveragePercentage` is the stake-weighted average of all observed uptimes for this node. @@ -649,7 +649,7 @@ curl -X POST --data '{ } ``` -#### Example Subnet Call +#### Example Avalanche L1 Call ``` curl -X POST --data '{ @@ -662,7 +662,7 @@ curl -X POST --data '{ }' -H 'content-type:application/json;' 127.0.0.1:9650/ext/info ``` -#### Example Subnet Response +#### Example Avalanche L1 Response ``` { @@ -674,3 +674,4 @@ curl -X POST --data '{ } } ``` + diff --git a/content/docs/api-reference/install-script.mdx b/content/docs/api-reference/install-script.mdx index 2817fb69064..6628dc20308 100644 --- a/content/docs/api-reference/install-script.mdx +++ b/content/docs/api-reference/install-script.mdx @@ -2,10 +2,10 @@ title: AvalancheGo Install Script --- -AvalancheGo Installer is a shell (bash) script that installs AvalancheGo on any Linux computer. This script sets up full, running node in a matter of minutes with minimal user input required. This is convenient if you want to run the node as a service on a standalone Linux installation, for example to set up a (Subnet) validator, use the node as a private RPC server and similar uses. It also makes upgrading or reinstalling the nodes easy. +AvalancheGo Installer is a shell (bash) script that installs AvalancheGo on any Linux computer. This script sets up full, running node in a matter of minutes with minimal user input required. This is convenient if you want to run the node as a service on a standalone Linux installation, for example to set up a (Avalanche L1) validator, use the node as a private RPC server and similar uses. It also makes upgrading or reinstalling the nodes easy. GitHub: [https://github.com/ava-labs/avalanche-docs/blob/master/scripts/avalanchego-installer.sh](https://github.com/ava-labs/avalanche-docs/blob/master/scripts/avalanchego-installer.sh) How-to: [Run an Avalanche Node Using the Install Script](/nodes/using-install-script/installing-avalanche-go) -If you want to run a node in a more complex environment, like in a docker or Kubernetes container, or as a part of an installation orchestrated using a tool like Terraform, this installer probably won't fit your purposes. See here for how to run AvalancheGo in a [Docker container](/tooling/guides/run-with-docker). \ No newline at end of file +If you want to run a node in a more complex environment, like in a docker or Kubernetes container, or as a part of an installation orchestrated using a tool like Terraform, this installer probably won't fit your purposes. See here for how to run AvalancheGo in a [Docker container](/tooling/guides/run-with-docker). diff --git a/content/docs/api-reference/keystore-api.mdx b/content/docs/api-reference/keystore-api.mdx index 105061e3e2f..580aa38b750 100644 --- a/content/docs/api-reference/keystore-api.mdx +++ b/content/docs/api-reference/keystore-api.mdx @@ -251,3 +251,4 @@ curl -X POST --data '{ } } ``` + diff --git a/content/docs/api-reference/metrics-api.mdx b/content/docs/api-reference/metrics-api.mdx index 044531156b0..64986673c62 100644 --- a/content/docs/api-reference/metrics-api.mdx +++ b/content/docs/api-reference/metrics-api.mdx @@ -33,4 +33,4 @@ Format[​](#format "Direct link to heading") This API produces Prometheus compatible metrics. See [here](https://github.com/prometheus/docs/blob/master/content/docs/instrumenting/exposition_formats.md) for information on Prometheus' formatting. -[Here](/nodes/maintain/monitoring) is a tutorial that shows how to set up Prometheus and Grafana to monitor AvalancheGo node using the Metrics API. \ No newline at end of file +[Here](/nodes/maintain/monitoring) is a tutorial that shows how to set up Prometheus and Grafana to monitor AvalancheGo node using the Metrics API. diff --git a/content/docs/api-reference/p-chain/api.mdx b/content/docs/api-reference/p-chain/api.mdx index 7ddd0e1988a..156f196e75a 100644 --- a/content/docs/api-reference/p-chain/api.mdx +++ b/content/docs/api-reference/p-chain/api.mdx @@ -455,7 +455,7 @@ platform.getBlockchains() -> - `blockchains` is all of the blockchains that exists on the Avalanche network. - `name` is the human-readable name of this blockchain. - `id` is the blockchain's ID. -- `subnetID` is the ID of the Subnet that validates this blockchain. +- `subnetID` is the ID of the Avalanche L1 that validates this blockchain. - `vmID` is the ID of the Virtual Machine the blockchain runs. **Example Call:** @@ -575,7 +575,7 @@ curl -X POST --data '{ ### `platform.getCurrentSupply` -Returns an upper bound on amount of tokens that exist that can stake the requested Subnet. This is +Returns an upper bound on amount of tokens that exist that can stake the requested Avalanche L1. This is an upper bound because it does not account for burnt tokens, including transaction fees. **Signature:** @@ -617,7 +617,7 @@ The response in this example indicates that AVAX's supply is at most 365.865 mil ### `platform.getCurrentValidators` -List the current validators of the given Subnet. +List the current validators of the given Avalanche L1. **Signature:** @@ -670,41 +670,41 @@ platform.getCurrentValidators({ } ``` -- `subnetID` is the Subnet whose current validators are returned. If omitted, returns the current +- `subnetID` is the Avalanche L1 whose current validators are returned. If omitted, returns the current validators of the Primary Network. - `nodeIDs` is a list of the NodeIDs of current validators to request. If omitted, all current validators are returned. If a specified NodeID is not in the set of current validators, it will not be included in the response. - `validators`: - `txID` is the validator transaction. - - `startTime` is the Unix time when the validator starts validating the Subnet. - - `endTime` is the Unix time when the validator stops validating the Subnet. + - `startTime` is the Unix time when the validator starts validating the Avalanche L1. + - `endTime` is the Unix time when the validator stops validating the Avalanche L1. - `stakeAmount` is the amount of tokens this validator staked. Omitted if `subnetID` is not a PoS - Subnet. + Avalanche L1. - `nodeID` is the validator's node ID. - `weight` is the validator's weight when sampling validators. Omitted if `subnetID` is a PoS - Subnet. + Avalanche L1. - `validationRewardOwner` is an `OutputOwners` output which includes `locktime`, `threshold` and array of `addresses`. Specifies the owner of the potential reward earned from staking. Omitted - if `subnetID` is not a PoS Subnet. + if `subnetID` is not a PoS Avalanche L1. - `delegationRewardOwner` is an `OutputOwners` output which includes `locktime`, `threshold` and array of `addresses`. Specifies the owner of the potential reward earned from delegations. - Omitted if `subnetID` is not a PoS Subnet. + Omitted if `subnetID` is not a PoS Avalanche L1. - `potentialReward` is the potential reward earned from staking. Omitted if `subnetID` is not a - PoS Subnet. + PoS Avalanche L1. - `delegationFeeRate` is the percent fee this validator charges when others delegate stake to - them. Omitted if `subnetID` is not a PoS Subnet. + them. Omitted if `subnetID` is not a PoS Avalanche L1. - `uptime` is the % of time the queried node has reported the peer as online and validating the - Subnet. Omitted if `subnetID` is not a PoS Subnet. - - `connected` is if the node is connected and tracks the Subnet. + Avalanche L1. Omitted if `subnetID` is not a PoS Avalanche L1. + - `connected` is if the node is connected and tracks the Avalanche L1. - `signer` is the node's BLS public key and proof of possession. Omitted if the validator doesn't have a BLS public key. - `delegatorCount` is the number of delegators on this validator. - Omitted if `subnetID` is not a PoS Subnet. + Omitted if `subnetID` is not a PoS Avalanche L1. - `delegatorWeight` is total weight of delegators on this validator. - Omitted if `subnetID` is not a PoS Subnet. + Omitted if `subnetID` is not a PoS Avalanche L1. - `delegators` is the list of delegators to this validator. - Omitted if `subnetID` is not a PoS Subnet. + Omitted if `subnetID` is not a PoS Avalanche L1. Omitted unless `nodeIDs` specifies a single NodeID. - `txID` is the delegator transaction. - `startTime` is the Unix time when the delegator started. @@ -841,7 +841,7 @@ platform.getMaxStakeAmount( } ``` -- `subnetID` is a Buffer or cb58 string representing Subnet +- `subnetID` is a Buffer or cb58 string representing Avalanche L1 - `nodeID` is a string representing ID of the node whose stake amount is required during the given duration - `startTime` is a big number denoting start time of the duration during which stake amount of the @@ -879,7 +879,7 @@ curl -X POST --data '{ ### `platform.getMinStake` -Get the minimum amount of tokens required to validate the requested Subnet and the minimum amount of +Get the minimum amount of tokens required to validate the requested Avalanche L1 and the minimum amount of tokens that can be delegated. **Signature:** @@ -922,8 +922,8 @@ curl -X POST --data '{ ### `platform.getPendingValidators` -List the validators in the pending validator set of the specified Subnet. Each validator is not -currently validating the Subnet but will in the future. +List the validators in the pending validator set of the specified Avalanche L1. Each validator is not +currently validating the Avalanche L1 but will in the future. **Signature:** @@ -956,23 +956,23 @@ platform.getPendingValidators({ } ``` -- `subnetID` is the Subnet whose current validators are returned. If omitted, returns the current +- `subnetID` is the Avalanche L1 whose current validators are returned. If omitted, returns the current validators of the Primary Network. - `nodeIDs` is a list of the NodeIDs of pending validators to request. If omitted, all pending validators are returned. If a specified NodeID is not in the set of pending validators, it will not be included in the response. - `validators`: - `txID` is the validator transaction. - - `startTime` is the Unix time when the validator starts validating the Subnet. - - `endTime` is the Unix time when the validator stops validating the Subnet. + - `startTime` is the Unix time when the validator starts validating the Avalanche L1. + - `endTime` is the Unix time when the validator stops validating the Avalanche L1. - `stakeAmount` is the amount of tokens this validator staked. Omitted if `subnetID` is not a PoS - Subnet. + Avalanche L1. - `nodeID` is the validator's node ID. - - `connected` if the node is connected and tracks the Subnet. + - `connected` if the node is connected and tracks the Avalanche L1. - `signer` is the node's BLS public key and proof of possession. Omitted if the validator doesn't have a BLS public key. - `weight` is the validator's weight when sampling validators. Omitted if `subnetID` is a PoS - Subnet. + Avalanche L1. - `delegators`: - `txID` is the delegator transaction. - `startTime` is the Unix time when the delegator starts. @@ -1151,7 +1151,7 @@ curl -X POST --data '{ ### `platform.getStakingAssetID` -Retrieve an assetID for a Subnet's staking asset. +Retrieve an assetID for an Avalanche L1's staking asset. **Signature:** @@ -1163,8 +1163,8 @@ platform.getStakingAssetID({ } ``` -- `subnetID` is the Subnet whose assetID is requested. -- `assetID` is the assetID for a Subnet's staking asset. +- `subnetID` is the Avalanche L1 whose assetID is requested. +- `assetID` is the assetID for an Avalanche L1's staking asset. **Example Call:** @@ -1203,7 +1203,7 @@ Testnet: U8iRqJoiJm8xZHAacmvYyZVwqQx6uDNtQeP3CQ6fcgQk3JqnK ### `platform.getSubnet` -Get owners and elastic info about the Subnet. +Get owners and elastic info about the Avalanche L1. **Signature:** @@ -1220,12 +1220,12 @@ platform.getSubnet({ } ``` -- `subnetID` is the ID of the Subnet to get information about. If omitted, fails. +- `subnetID` is the ID of the Avalanche L1 to get information about. If omitted, fails. - `threshold` signatures from addresses in `controlKeys` are needed to make changes to - a permissioned subnet. If the Subnet is a PoS Subnet, then `threshold` will be `0` and `controlKeys` + a permissioned avalanche-l1. If the Avalanche L1 is a PoS Avalanche L1, then `threshold` will be `0` and `controlKeys` will be empty. -- changes can not be made into the subnet until `locktime` is in the past. -- `subnetTransformationTxID` is the ID of the transaction that changed the subnet into a elastic one, +- changes can not be made into the avalanche-l1 until `locktime` is in the past. +- `subnetTransformationTxID` is the ID of the transaction that changed the Avalanche L1 into an elastic one, for when this change was performed. **Example Call:** @@ -1263,7 +1263,7 @@ Deprecated as of [**v1.9.12**](https://github.com/ava-labs/avalanchego/releases/ -Get info about the Subnets. +Get info about the Avalanche L1s. **Signature:** @@ -1272,7 +1272,7 @@ platform.getSubnets({ ids: []string }) -> { - subnets: []{ + subnets: [] id: string, controlKeys: []string, threshold: string @@ -1280,15 +1280,15 @@ platform.getSubnets({ } ``` -- `ids` are the IDs of the Subnets to get information about. If omitted, gets information about all - Subnets. -- `id` is the Subnet's ID. +- `ids` are the IDs of the Avalanche L1s to get information about. If omitted, gets information about all + Avalanche L1s. +- `id` is the Avalanche L1's ID. - `threshold` signatures from addresses in `controlKeys` are needed to add a validator to the - Subnet. If the Subnet is a PoS Subnet, then `threshold` will be `0` and `controlKeys` will be + Avalanche L1. If the Avalanche L1 is a PoS Avalanche L1, then `threshold` will be `0` and `controlKeys` will be empty. See [here](/nodes/validate/node-validator) for information on adding a validator to a -Subnet. +Avalanche L1. **Example Call:** @@ -1358,7 +1358,7 @@ curl -X POST --data '{ ### `platform.getTotalStake` -Get the total amount of tokens staked on the requested Subnet. +Get the total amount of tokens staked on the requested Avalanche L1. **Signature:** @@ -1400,7 +1400,7 @@ curl -X POST --data '{ } ``` -#### Subnet Example +#### Avalanche L1 Example **Example Call:** @@ -1755,7 +1755,7 @@ This gives response: ### `platform.getValidatorsAt` -Get the validators and their weights of a Subnet or the Primary Network at a given P-Chain height. +Get the validators and their weights of an Avalanche L1 or the Primary Network at a given P-Chain height. **Signature:** @@ -1769,7 +1769,7 @@ platform.getValidatorsAt( ``` - `height` is the P-Chain height to get the validator set at. -- `subnetID` is the Subnet ID to get the validator set of. If not given, gets validator set of the +- `subnetID` is the Avalanche L1 ID (SubnetID) to get the validator set of. If not given, gets validator set of the Primary Network. **Example Call:** @@ -1900,7 +1900,7 @@ curl -X POST --data '{ ### `platform.sampleValidators` -Sample validators from the specified Subnet. +Sample validators from the specified Avalanche L1. **Signature:** @@ -1917,7 +1917,7 @@ platform.sampleValidators( ``` - `size` is the number of validators to sample. -- `subnetID` is the Subnet to sampled from. If omitted, defaults to the Primary Network. +- `subnetID` is the Avalanche L1 to sampled from. If omitted, defaults to the Primary Network. - Each element of `validators` is the ID of a validator. **Example Call:** @@ -1950,7 +1950,7 @@ curl -X POST --data '{ ### `platform.validatedBy` -Get the Subnet that validates a given blockchain. +Get the `SubnetID` of the Avalanche L1 that validates a given blockchain. **Signature:** @@ -1963,7 +1963,7 @@ platform.validatedBy( ``` - `blockchainID` is the blockchain's ID. -- `subnetID` is the ID of the Subnet that validates the blockchain. +- `subnetID` is the ID of the Avalanche L1 that validates the blockchain. **Example Call:** @@ -1992,7 +1992,7 @@ curl -X POST --data '{ ### `platform.validates` -Get the IDs of the blockchains a Subnet validates. +Get the IDs of the blockchains an Avalanche L1 validates. **Signature:** @@ -2004,8 +2004,8 @@ platform.validates( ) -> {blockchainIDs: []string} ``` -- `subnetID` is the Subnet's ID. -- Each element of `blockchainIDs` is the ID of a blockchain the Subnet validates. +- `subnetID` is the Avalanche L1's ID. +- Each element of `blockchainIDs` is the ID of a blockchain the Avalanche L1 validates. **Example Call:** @@ -2033,4 +2033,4 @@ curl -X POST --data '{ }, "id": 1 } -``` \ No newline at end of file +``` diff --git a/content/docs/api-reference/p-chain/configs.mdx b/content/docs/api-reference/p-chain/configs.mdx index 89b190dea80..e44da6365ad 100644 --- a/content/docs/api-reference/p-chain/configs.mdx +++ b/content/docs/api-reference/p-chain/configs.mdx @@ -17,7 +17,7 @@ In order to specify a configuration for the PlatformVM, you need to define a `Co "UptimeLockedCalculator": null, "SybilProtectionEnabled": false, "PartialSyncPrimaryNetwork": false, - "TrackedSubnets": [], +"TrackedSubnets": [], "TxFee": 0, "CreateAssetTxFee": 0, "CreateSubnetTxFee": 0, @@ -57,7 +57,7 @@ The node's chain manager ### `Validators` -Node's validator set maps SubnetID to validators of the Subnet +Node's validator set maps SubnetID to validators of the Avalanche L1 - The primary network's validator set should have been added to the manager before calling VM.Initialize. - The primary network's validator set should be empty before calling VM.Initialize. @@ -80,7 +80,7 @@ If true, only the P-chain will be instantiated on the primary network. ### `TrackedSubnets` -Set of Subnets that this node is validating +Set of Avalanche L1s that this node is validating ### `TxFee` @@ -98,13 +98,13 @@ Fee that must be burned by every state creating transaction before AP3 _Uint64_ -Fee that must be burned by every Subnet creating transaction after AP3 +Fee that must be burned by every Avalanche L1 creating transaction after AP3 ### `TransformSubnetTxFee` _Uint64_ -Fee that must be burned by every transform Subnet transaction +Fee that must be burned by every transform Avalanche L1 transaction ### `CreateBlockchainTxFee` @@ -128,13 +128,13 @@ Transaction fee for adding a primary network delegator _Uint64_ -Transaction fee for adding a Subnet validator +Transaction fee for adding an Avalanche L1 validator ### `AddSubnetDelegatorFee` _Uint64_ -Transaction fee for adding a Subnet delegator +Transaction fee for adding an Avalanche L1 delegator ### `MinValidatorStake` @@ -222,4 +222,4 @@ Time of the E network upgrade _Boolean_ -UseCurrentHeight forces `GetMinimumHeight` to return the current height of the P-Chain instead of the oldest block in the `recentlyAccepted` window. This config is particularly useful for triggering proposervm activation on recently created Subnets (without this, users need to wait for `recentlyAcceptedWindowTTL` to pass for activation to occur). \ No newline at end of file +UseCurrentHeight forces `GetMinimumHeight` to return the current height of the P-Chain instead of the oldest block in the `recentlyAccepted` window. This config is particularly useful for triggering proposervm activation on recently created Avalanche L1s (without this, users need to wait for `recentlyAcceptedWindowTTL` to pass for activation to occur). diff --git a/content/docs/api-reference/p-chain/txn-format.mdx b/content/docs/api-reference/p-chain/txn-format.mdx index 4ee72c8e610..c2c262393e7 100644 --- a/content/docs/api-reference/p-chain/txn-format.mdx +++ b/content/docs/api-reference/p-chain/txn-format.mdx @@ -733,22 +733,22 @@ Let's make an unsigned add validator TX that uses the inputs and outputs from th ] ``` -## Unsigned Remove Subnet Validator TX +## Unsigned Remove Avalanche L1 Validator TX -### What Unsigned Remove Subnet Validator TX Contains +### What Unsigned Remove Avalanche L1 Validator TX Contains -An unsigned remove Subnet validator TX contains a `BaseTx`, `NodeID`, +An unsigned remove Avalanche L1 validator TX contains a `BaseTx`, `NodeID`, `SubnetID`, and `SubnetAuth`. The `TypeID` for this type is 23 or `0x00000017`. - **`BaseTx`** - **`NodeID`** is the 20 byte node ID of the validator. -- **`SubnetID`** is the 32 byte Subnet ID that the validator is being removed from. +- **`SubnetID`** is the 32 byte Avalanche L1 ID (SubnetID) that the validator is being removed from. - **`SubnetAuth`** contains `SigIndices` and has a type id of `0x0000000a`. `SigIndices` is a list of unique ints that define the addresses signing the control signature which proves that the issuer has the right to remove the - node from the Subnet. The array must be sorted low to high. + node from the Avalanche L1. The array must be sorted low to high. -### Gantt Unsigned Remove Subnet Validator TX Specification +### Gantt Unsigned Remove Avalanche L1 Validator TX Specification ```text +---------------+----------------------+------------------------------------------------+ @@ -764,7 +764,7 @@ An unsigned remove Subnet validator TX contains a `BaseTx`, `NodeID`, +---------------------------------------------------------------------------------------+ ``` -### Proto Unsigned Remove Subnet Validator TX Specification +### Proto Unsigned Remove Avalanche L1 Validator TX Specification ```text message RemoveSubnetValidatorTx { @@ -775,9 +775,9 @@ message RemoveSubnetValidatorTx { } ``` -### Unsigned Remove Subnet Validator TX Example +### Unsigned Remove Avalanche L1 Validator TX Example -Let's make an unsigned remove Subnet validator TX that uses the inputs and +Let's make an unsigned remove Avalanche L1 validator TX that uses the inputs and outputs from the previous examples: - **`BaseTx`**: `"Example BaseTx as defined above with ID set to 17"` @@ -836,7 +836,7 @@ An unsigned add permissionless validator TX contains a `BaseTx`, `Validator`, - **`StartTime`** is a long which is the Unix time when the validator starts validating. - **`EndTime`** is a long which is the Unix time when the validator stops validating. - **`Weight`** is a long which is the amount the validator stakes -- **`SubnetID`** is the 32 byte Subnet ID of the Subnet this validator will validate. +- **`SubnetID`** is the 32 byte Avalanche L1 ID (SubnetID) of the Avalanche L1 this validator will validate. - **`Signer`** If the [SubnetID] is the primary network, [Signer] is the type ID 28 (`0x1C`) followed by a [Proof of Possession](#proof-of-possession). If the [SubnetID] is not the primary network, this value is the empty signer, whose @@ -1041,7 +1041,7 @@ is 26 or `0x0000001a`. - **`StartTime`** is a long which is the Unix time when the validator starts validating. - **`EndTime`** is a long which is the Unix time when the validator stops validating. - **`Weight`** is a long which is the amount the validator stakes -- **`SubnetID`** is the 32 byte Subnet ID of the Subnet this delegation is on. +- **`SubnetID`** is the 32 byte Avalanche L1 ID (SubnetID) of the Avalanche L1 this delegation is on. - **`StakeOuts`** An array of Transferable Outputs. Where to send staked tokens when done validating. - **`DelegatorRewardsOwner`** Where to send staking rewards when done validating. @@ -1165,13 +1165,13 @@ outputs from the previous examples: ] ``` -## Unsigned Transform Subnet TX +## Unsigned Transform Avalanche L1 TX -Transforms a permissioned Subnet into a permissionless Subnet. Must be signed by the Subnet owner. +Transforms a permissioned Avalanche L1 into a permissionless Avalanche L1. Must be signed by the Avalanche L1 owner. -### What Unsigned Transform Subnet TX Contains +### What Unsigned Transform Avalanche L1 TX Contains -An unsigned transform Subnet TX contains a `BaseTx`, `SubnetID`, `AssetID`, +An unsigned transform Avalanche L1 TX contains a `BaseTx`, `SubnetID`, `AssetID`, `InitialSupply`, `MaximumSupply`, `MinConsumptionRate`, `MaxConsumptionRate`, `MinValidatorStake`, `MaxValidatorStake`, `MinStakeDuration`, `MaxStakeDuration`, `MinDelegationFee`, `MinDelegatorStake`, @@ -1179,8 +1179,8 @@ An unsigned transform Subnet TX contains a `BaseTx`, `SubnetID`, `AssetID`, for this type is 24 or `0x00000018`. - **`BaseTx`** -- **`SubnetID`** a 32-byte Subnet ID of the Subnet to transform. -- **`AssetID`** is a 32-byte array that defines which asset to use when staking on the Subnet. +- **`SubnetID`** a 32-byte Avalanche L1 ID of the Avalanche L1 to transform. +- **`AssetID`** is a 32-byte array that defines which asset to use when staking on the Avalanche L1. - Restrictions - Must not be the Empty ID - Must not be the AVAX ID @@ -1234,7 +1234,7 @@ for this type is 24 or `0x00000018`. control signature to authorizes this transformation. The array must be sorted low to high. -### Gantt Unsigned Transform Subnet TX Specification +### Gantt Unsigned Transform Avalanche L1 TX Specification ```text +----------------------+------------------+----------------------------------+ @@ -1274,7 +1274,7 @@ for this type is 24 or `0x00000018`. +----------------------------------------------------------------------------+ ``` -### Proto Unsigned Transform Subnet TX Specification +### Proto Unsigned Transform Avalanche L1 TX Specification ```text message TransformSubnetTx { @@ -1297,9 +1297,9 @@ message TransformSubnetTx { } ``` -### Unsigned Transform Subnet TX Example +### Unsigned Transform Avalanche L1 TX Example -Let's make an unsigned transform Subnet TX that uses the inputs and outputs from the previous examples: +Let's make an unsigned transform Avalanche L1 TX that uses the inputs and outputs from the previous examples: - **`BaseTx`**: `"Example BaseTx as defined above with ID set to 18"` - **`SubnetID`**: `0x5fa29ed4356903dac2364713c60f57d8472c7dda4a5e08d88a88ad8ea71aed60` @@ -1413,7 +1413,9 @@ Let's make an unsigned transform Subnet TX that uses the inputs and outputs from 0x05, // UptimeRequirement 0x00, 0x0c, 0x35, 0x00, - // SubnetAuth +``` +// SubnetAuth +``` // SubnetAuth TypeID 0x00, 0x00, 0x00, 0x0a, // SigIndices length @@ -1423,11 +1425,11 @@ Let's make an unsigned transform Subnet TX that uses the inputs and outputs from ] ``` -## Unsigned Add Subnet Validator TX +## Unsigned Add Avalanche L1 Validator TX -### What Unsigned Add Subnet Validator TX Contains +### What Unsigned Add Avalanche L1 Validator TX Contains -An unsigned add Subnet validator TX contains a `BaseTx`, `Validator`, +An unsigned add Avalanche L1 validator TX contains a `BaseTx`, `Validator`, `SubnetID`, and `SubnetAuth`. The `TypeID` for this type is `0x0000000d`. - **`BaseTx`** @@ -1436,13 +1438,13 @@ An unsigned add Subnet validator TX contains a `BaseTx`, `Validator`, - **`StartTime`** is a long which is the Unix time when the validator starts validating. - **`EndTime`** is a long which is the Unix time when the validator stops validating. - **`Weight`** is a long which is the amount the validator stakes -- **`SubnetID`** is the 32 byte Subnet ID to add the validator to. +- **`SubnetID`** is the 32 byte Avalanche L1 ID to add the validator to. - **`SubnetAuth`** contains `SigIndices` and has a type id of `0x0000000a`. `SigIndices` is a list of unique ints that define the addresses signing the - control signature to add a validator to a Subnet. The array must be sorted low + control signature to add a validator to an Avalanche L1. The array must be sorted low to high. -### Gantt Unsigned Add Subnet Validator TX Specification +### Gantt Unsigned Add Avalanche L1 Validator TX Specification ```text +---------------+----------------------+-----------------------------------------+ @@ -1458,7 +1460,7 @@ An unsigned add Subnet validator TX contains a `BaseTx`, `Validator`, +---------------------------------------------+ ``` -### Proto Unsigned Add Subnet Validator TX Specification +### Proto Unsigned Add Avalanche L1 Validator TX Specification ```text message AddSubnetValidatorTx { @@ -1469,9 +1471,9 @@ message AddSubnetValidatorTx { } ``` -### Unsigned Add Subnet Validator TX Example +### Unsigned Add Avalanche L1 Validator TX Example -Let's make an unsigned add Subnet validator TX that uses the inputs and outputs from the previous examples: +Let's make an unsigned add Avalanche L1 validator TX that uses the inputs and outputs from the previous examples: - **`BaseTx`**: `"Example BaseTx as defined above with ID set to 0d"` - **`NodeID`**: `0xe9094f73698002fd52c90819b457b9fbc866ab80` @@ -1695,12 +1697,12 @@ An unsigned create chain TX contains a `BaseTx`, `SubnetID`, `ChainName`, `0x0000000f`. - **`BaseTx`** -- **`SubnetID`** ID of the Subnet that validates this blockchain +- **`SubnetID`** ID of the Avalanche L1 that validates this blockchain - **`ChainName`** A human readable name for the chain; need not be unique - **`VMID`** ID of the VM running on the new chain - **`FxIDs`** IDs of the feature extensions running on the new chain - **`GenesisData`** Byte representation of genesis state of the new chain -- **`SubnetAuth`** Authorizes this blockchain to be added to this Subnet +- **`SubnetAuth`** Authorizes this blockchain to be added to this Avalanche L1 ### Gantt Unsigned Create Chain TX Specification @@ -1845,16 +1847,16 @@ Let's make an unsigned create chain TX that uses the inputs and outputs from the ] ``` -## Unsigned Create Subnet TX +## Unsigned Create Avalanche L1 TX -### What Unsigned Create Subnet TX Contains +### What Unsigned Create Avalanche L1 TX Contains -An unsigned create Subnet TX contains a `BaseTx`, and `RewardsOwner`. The `TypeID` for this type is `0x00000010`. +An unsigned create Avalanche L1 TX contains a `BaseTx`, and `RewardsOwner`. The `TypeID` for this type is `0x00000010`. - **`BaseTx`** - **`RewardsOwner`** A `SECP256K1OutputOwners` -### Gantt Unsigned Create Subnet TX Specification +### Gantt Unsigned Create Avalanche L1 TX Specification ```text +-----------------+-----------------------|---------------------------------+ @@ -1866,7 +1868,7 @@ An unsigned create Subnet TX contains a `BaseTx`, and `RewardsOwner`. The `TypeI +-------------------------------------------+ ``` -### Proto Unsigned Create Subnet TX Specification +### Proto Unsigned Create Avalanche L1 TX Specification ```text message CreateSubnetTx { @@ -1875,9 +1877,9 @@ message CreateSubnetTx { } ``` -### Unsigned Create Subnet TX Example +### Unsigned Create Avalanche L1 TX Example -Let's make an unsigned create Subnet TX that uses the inputs from the previous examples: +Let's make an unsigned create Avalanche L1 TX that uses the inputs from the previous examples: - **`BaseTx`**: "Example BaseTx as defined above but with TypeID set to 16" - **`RewardsOwner`**: @@ -2575,20 +2577,20 @@ Let's make a stakeablelockout with: ] ``` -## Subnet Auth +## Avalanche L1 Auth -### What Subnet Auth Contains +### What Avalanche L1 Auth Contains Specifies the addresses whose signatures will be provided to demonstrate that -the owners of a Subnet approve something. +the owners of an Avalanche L1 approve something. - **`TypeID`** is the ID for this type. It is `0x0000000a`. - **`AddressIndices`** defines which addresses' signatures will be attached to - this transaction. AddressIndices[i] is the index in a Subnet owner list that + this transaction. AddressIndices[i] is the index in an Avalanche L1 owner list that corresponds to the signature at index i in the signature list. Must be sorted low to high and not have duplicates. -### Gantt Subnet Auth Specification +### Gantt Avalanche L1 Auth Specification ```text +-----------------+------------------+-------------------------------------+ @@ -2600,7 +2602,7 @@ the owners of a Subnet approve something. +-----------------+--------------------------------------------------------+ ``` -### Proto Subnet Auth Specification +### Proto Avalanche L1 Auth Specification ```text message SubnetAuth { @@ -2609,9 +2611,9 @@ message SubnetAuth { } ``` -### Subnet Auth Example +### Avalanche L1 Auth Example -Let's make a Subnet auth: +Let's make an Avalanche L1 auth: - **`TypeID`**: `10` - **`AddressIndices`**: [`0`] @@ -2795,4 +2797,4 @@ Let's make a rewards owner: 0xde, 0x35, 0x23, 0xa2, 0x4a, 0x46, 0x1c, 0x89, 0x43, 0xab, 0x08, 0x59, ] -``` \ No newline at end of file +``` diff --git a/content/docs/api-reference/rpc-providers.mdx b/content/docs/api-reference/rpc-providers.mdx index bf3389f294c..690df0e2b81 100644 --- a/content/docs/api-reference/rpc-providers.mdx +++ b/content/docs/api-reference/rpc-providers.mdx @@ -31,7 +31,7 @@ Note: on Fuji Testnet, the URL is `wss://api.avax-test.network/ext/bc/C/ws`. The public API server supports all the API endpoints that make sense to be available on a public-facing service, including APIs for the [X-Chain](/api-reference/x-chain/api), [P-Chain](/api-reference/p-chain/api), [C-Chain](/api-reference/c-chain/api), and full archival for the Primary Network. However, it doesn't support [Index APIs](/api-reference/index-api), which includes the X-Chain API's `getAddressTxs` method. -For a full list of available APIs see [here](/api-reference/quicklinks). +For a full list of available APIs see [here](/api-reference/p-chain/api). #### Limitations[​](#limitations "Direct link to heading") @@ -39,7 +39,7 @@ The public API only supports C-Chain WebSocket API calls for API methods that do For batched C-Chain requests on the public API node, the maximum number of items is 40. We're working on to support a larger batch size. -The maximum number of blocks to serve per `getLogs` request is 2048, which is set by [`api-max-blocks-per-request`](/nodes/configure/chain-configs/c-chain#api-max-blocks-per-request). +The maximum number of blocks to serve per `getLogs` request is 2048, which is set by [`api-max-blocks-per-request`](/nodes/chain-configs/c-chain#api-max-blocks-per-request). #### Sticky Sessions[​](#sticky-sessions "Direct link to heading") @@ -116,10 +116,6 @@ Note: soft limited to 1 million daily requests per IP or referring domain. Batch - For C-Chain WSS Endpoint, the URL is `wss://ava-testnet.public.blastapi.io/ext/bc/C/ws` -### BlockSpaces[​](#blockspaces "Direct link to heading") - -[BlockSpaces](https://www.blockspaces.com/web3-infrastructure) supports the C-Chain. - #### HTTP[​](#http-3 "Direct link to heading") - For C-Chain RPC Endpoint AVAX, the URL is `https://web3endpoints.com/avax-mainnet` @@ -198,7 +194,7 @@ Note: on Fuji Testnet, the URL is `wss://avax.getblock.io/api_key/testnet/ext/bc ### Infura[​](#infura "Direct link to heading") -[Infura](https://docs.infura.io/infura/networks/avalanche-c-chain/how-to/choose-a-network) currently only supports the C-Chain. +[Infura](https://docs.infura.io/api/networks/avalanche-c-chain) currently only supports the C-Chain. #### HTTP[​](#http-7 "Direct link to heading") @@ -225,7 +221,7 @@ Features: ### Nodies[​](#nodies "Direct link to heading") -[Nodies](https://nodies.app/) supports the C, X, P, and DFK Subnet chains. +[Nodies](https://nodies.app/) supports the C, X, P, and DFK Avalanche L1 chains. Features: @@ -238,7 +234,7 @@ Features: - For `C-Chain`, the URL is `https://lb.nodies.app/v1/105f8099e80f4123976b59df1ebfb433/ext/bc/C/rpc` - For `X-Chain`, the URL is `https://lb.nodies.app/v1/105f8099e80f4123976b59df1ebfb433/ext/bc/X` - For `P-Chain`, the URL is `https://lb.nodies.app/v1/105f8099e80f4123976b59df1ebfb433/ext/bc/P` -- For `DFK-Subnet`, the URL is `https://lb.nodies.app/v1/105f8099e80f4123976b59df1ebfb433/ext/bc/q2aTwKuyzgs8pynF7UXBZCU7DejbZbZ6EUyHr3JQzYgwNPUPi/rpc` +- For `DFK-L1`, the URL is `https://lb.nodies.app/v1/105f8099e80f4123976b59df1ebfb433/ext/bc/q2aTwKuyzgs8pynF7UXBZCU7DejbZbZ6EUyHr3JQzYgwNPUPi/rpc` ### QuickNode[​](#quicknode "Direct link to heading") @@ -326,7 +322,7 @@ Features: - For X-Chain RPC Endpoint, the URL is `https://1rpc.io/avax/x` - For P-Chain RPC Endpoint, the URL is `https://1rpc.io/avax/p` -Subnets RPC - Public API Servers[​](#subnets-rpc---public-api-servers "Direct link to heading") +Avalanche L1s RPC - Public API Servers[​](#avalanche-l1s-rpc---public-api-servers "Direct link to heading") ----------------------------------------------------------------------------------------------- ### Beam[​](#beam "Direct link to heading") @@ -369,4 +365,4 @@ Note: on Fuji Testnet, the URL is `https://subnets.avax.network/dexalot/testnet/ - The URL is `wss://subnets.avax.network/dexalot/mainnet/ws`. -Note: on Fuji Testnet, the URL is `wss://subnets.avax.network/dexalot/testnet/ws`. \ No newline at end of file +Note: on Fuji Testnet, the URL is `wss://subnets.avax.network/dexalot/testnet/ws`. diff --git a/content/docs/api-reference/standards/avalanche-network-protocol.mdx b/content/docs/api-reference/standards/avalanche-network-protocol.mdx index b6da320a29e..3f54feab486 100644 --- a/content/docs/api-reference/standards/avalanche-network-protocol.mdx +++ b/content/docs/api-reference/standards/avalanche-network-protocol.mdx @@ -50,7 +50,7 @@ message Ping { ``` - `uptime`: Uptime percentage on the primary network \[0, 100\]. -- `subnet_uptimes`: Uptime percentages on Subnets. +- `subnet_uptimes`: Uptime percentages on Avalanche L1s. ### Pong[​](#pong "Direct link to heading") @@ -87,7 +87,7 @@ message Version { - `my_version`: Avalanche client version. - `my_version_time`: Timestamp of the IP. - `sig`: Signature of the peer IP port pair at a provided timestamp. -- `tracked_subnets`: Subnets the peer is tracking. +- `tracked_subnets`: Avalanche L1s the peer is tracking. ### PeerList[​](#peerlist "Direct link to heading") @@ -452,4 +452,4 @@ message AppGossip { ``` - `chain_id`: Chain the message is for. -- `app_bytes`: Message body. \ No newline at end of file +- `app_bytes`: Message body. diff --git a/content/docs/api-reference/standards/cryptographic-primitives.mdx b/content/docs/api-reference/standards/cryptographic-primitives.mdx index 5e16485da5d..fc82422006f 100644 --- a/content/docs/api-reference/standards/cryptographic-primitives.mdx +++ b/content/docs/api-reference/standards/cryptographic-primitives.mdx @@ -169,4 +169,4 @@ Avalanche nodes support the full Ethereum Virtual Machine (EVM) and precisely du ## Cryptography in Other Virtual Machines -Since Avalanche is an extensible platform, we expect that people will add additional cryptographic primitives to the system over time. \ No newline at end of file +Since Avalanche is an extensible platform, we expect that people will add additional cryptographic primitives to the system over time. diff --git a/content/docs/api-reference/standards/guides/banff-changes.mdx b/content/docs/api-reference/standards/guides/banff-changes.mdx index 2d44b63b8b6..47f94bd804b 100644 --- a/content/docs/api-reference/standards/guides/banff-changes.mdx +++ b/content/docs/api-reference/standards/guides/banff-changes.mdx @@ -69,12 +69,12 @@ So the two main differences with respect to Apricot are: ``` type RemoveSubnetValidatorTx struct { BaseTx `serialize:"true"` - // The node to remove from the subnet. + // The node to remove from the Avalanche L1. NodeID ids.NodeID `serialize:"true" json:"nodeID"` - // The subnet to remove the node from. + // The Avalanche L1 to remove the node from. Subnet ids.ID `serialize:"true" json:"subnet"` - // Proves that the issuer has the right to remove the node from the subnet. - SubnetAuth verify.Verifiable `serialize:"true" json:"subnetAuthorization"` + // Proves that the issuer has the right to remove the node from the Avalanche L1. +SubnetAuth verify.Verifiable `serialize:"true" json:"subnetAuthorization"` } ``` @@ -88,7 +88,7 @@ type TransformSubnetTx struct { // Restrictions: // - Must not be the Primary Network ID Subnet ids.ID `serialize:"true" json:"subnetID"` - // Asset to use when staking on the Subnet + // Asset to use when staking on the Avalanche L1 // Restrictions: // - Must not be the Empty ID // - Must not be the AVAX ID @@ -153,7 +153,7 @@ type TransformSubnetTx struct { // - Must be <= [reward.PercentDenominator] UptimeRequirement uint32 `serialize:"true" json:"uptimeRequirement"` // Authorizes this transformation - SubnetAuth verify.Verifiable `serialize:"true" json:"subnetAuthorization"` +SubnetAuth verify.Verifiable `serialize:"true" json:"subnetAuthorization"` } ``` @@ -165,7 +165,7 @@ type AddPermissionlessValidatorTx struct { BaseTx `serialize:"true"` // Describes the validator Validator validator.Validator `serialize:"true" json:"validator"` - // ID of the subnet this validator is validating + // ID of the Avalanche L1 this validator is validating Subnet ids.ID `serialize:"true" json:"subnet"` // Where to send staked tokens when done validating StakeOuts []*avax.TransferableOutput `serialize:"true" json:"stake"` @@ -188,7 +188,7 @@ type AddPermissionlessDelegatorTx struct { BaseTx `serialize:"true"` // Describes the validator Validator validator.Validator `serialize:"true" json:"validator"` - // ID of the subnet this validator is validating + // ID of the Avalanche L1 this validator is validating Subnet ids.ID `serialize:"true" json:"subnet"` // Where to send staked tokens when done validating Stake []*avax.TransferableOutput `serialize:"true" json:"stake"` @@ -241,3 +241,4 @@ BanffCommitBlock = 31 BanffStandardBlock = 32 ``` + diff --git a/content/docs/api-reference/standards/guides/blockchain-flow.mdx b/content/docs/api-reference/standards/guides/blockchain-flow.mdx index a24c557119d..1a09e3c36fc 100644 --- a/content/docs/api-reference/standards/guides/blockchain-flow.mdx +++ b/content/docs/api-reference/standards/guides/blockchain-flow.mdx @@ -6,7 +6,7 @@ title: Flow of a Single Blockchain Intro[​](#intro "Direct link to heading") ----------------------------------------- -The Avalanche network consists of 3 built-in blockchains: X-Chain, C-Chain, and P-Chain. The X-Chain is used to manage assets and uses the Avalanche consensus protocol. The C-Chain is used to create and interact with smart contracts and uses the Snowman consensus protocol. The P-Chain is used to coordinate validators and stake and also uses the Snowman consensus protocol. At the time of writing, the Avalanche network has ~1200 validators. A set of validators makes up a Subnet. Subnets can validate 1 or more chains. It is a common misconception that 1 Subnet = 1 chain and this is shown by the primary Subnet of Avalanche which is made up of the X-Chain, C-Chain, and P-Chain. +The Avalanche network consists of 3 built-in blockchains: X-Chain, C-Chain, and P-Chain. The X-Chain is used to manage assets and uses the Avalanche consensus protocol. The C-Chain is used to create and interact with smart contracts and uses the Snowman consensus protocol. The P-Chain is used to coordinate validators and stake and also uses the Snowman consensus protocol. At the time of writing, the Avalanche network has ~1200 validators. A set of validators makes up an Avalanche L1. Avalanche L1s can validate 1 or more chains. It is a common misconception that 1 Avalanche L1 = 1 chain and this is shown by the primary Avalanche L1 of Avalanche which is made up of the X-Chain, C-Chain, and P-Chain. A node in the Avalanche network can either be a validator or a non-validator. A validator stakes AVAX tokens and participates in consensus to earn rewards. A non-validator does not participate in consensus or have any AVAX staked but can be used as an API server. Both validators and non-validators need to have their own copy of the chain and need to know the current state of the network. At the time of writing, there are ~1200 validators and ~1800 non-validators. @@ -36,7 +36,7 @@ Currently, AvalancheGo implements its own message serialization to communicate. ### Network[​](#network "Direct link to heading") -[The networking interface](https://github.com/ava-labs/avalanchego/blob/master/network/network.go) is shared across all chains. It implements functions from the `ExternalSender` interface. The two functions it implements are `Send` and `Gossip`. `Send` sends a message of type `OutboundMessage` to a specific set of nodes (specified by an array of `NodeIDs`). `Gossip` sends a message of type `OutboundMessage` to a random group of nodes in a Subnet (can be a validator or a non-validator). Gossiping is used to push transactions across the network. The networking protocol uses TLS to pass messages between peers. +[The networking interface](https://github.com/ava-labs/avalanchego/blob/master/network/network.go) is shared across all chains. It implements functions from the `ExternalSender` interface. The two functions it implements are `Send` and `Gossip`. `Send` sends a message of type `OutboundMessage` to a specific set of nodes (specified by an array of `NodeIDs`). `Gossip` sends a message of type `OutboundMessage` to a random group of nodes in an Avalanche L1 (can be a validator or a non-validator). Gossiping is used to push transactions across the network. The networking protocol uses TLS to pass messages between peers. Along with sending and gossiping, the networking library is also responsible for making connections and maintaining connections. Any node, either a validator or non-validator, will attempt to connect to the primary network. @@ -68,4 +68,4 @@ Consensus is defined as getting a group of distributed systems to agree on an ou Blockchain Creation[​](#blockchain-creation "Direct link to heading") --------------------------------------------------------------------- -[The `Manager`](https://github.com/ava-labs/avalanchego/blob/master/chains/manager.go) is what kick-starts everything in regards to blockchain creation, starting with the P-Chain. Once the P-Chain finishes bootstrapping, it will kickstart C-Chain and X-Chain and any other chains. The `Manager`'s job is not done yet, if a create-chain transaction is seen by a validator, a whole new process to create a chain will be started by the `Manager`. This can happen dynamically, long after the 3 chains in the Primary Network have been created and bootstrapped. \ No newline at end of file +[The `Manager`](https://github.com/ava-labs/avalanchego/blob/master/chains/manager.go) is what kick-starts everything in regards to blockchain creation, starting with the P-Chain. Once the P-Chain finishes bootstrapping, it will kickstart C-Chain and X-Chain and any other chains. The `Manager`'s job is not done yet, if a create-chain transaction is seen by a validator, a whole new process to create a chain will be started by the `Manager`. This can happen dynamically, long after the 3 chains in the Primary Network have been created and bootstrapped. diff --git a/content/docs/api-reference/standards/guides/issuing-api-calls.mdx b/content/docs/api-reference/standards/guides/issuing-api-calls.mdx index f5ce90806b3..c5688fd0147 100644 --- a/content/docs/api-reference/standards/guides/issuing-api-calls.mdx +++ b/content/docs/api-reference/standards/guides/issuing-api-calls.mdx @@ -33,7 +33,7 @@ Each API's documentation specifies what endpoint path a user should make calls t In general, they are formatted like: -So for the Admin API, the endpoint path is `/ext/admin`, for the Info API it is `/ext/info` and so on. Note that some APIs have additional path components, most notably the chain RPC endpoints which includes the Subnet chain RPCs. We'll go over those in detail in the next section. +So for the Admin API, the endpoint path is `/ext/admin`, for the Info API it is `/ext/info` and so on. Note that some APIs have additional path components, most notably the chain RPC endpoints which includes the Avalanche L1 chain RPCs. We'll go over those in detail in the next section. So, in combining the base URL and the endpoint path we get the complete URL for making RPC calls. For example, to make a local RPC call on the Info API, the full URL would be: @@ -41,10 +41,10 @@ So, in combining the base URL and the endpoint path we get the complete URL for http://127.0.0.1:9650/ext/info ``` -Primary Network and Subnet RPC calls[​](#primary-network-and-subnet-rpc-calls "Direct link to heading") +Primary Network and Avalanche L1 RPC calls[​](#primary-network-and-avalanche-l1-rpc-calls "Direct link to heading") ------------------------------------------------------------------------------------------------------- -Besides the APIs that are local to the node, like Admin or Metrics APIs, nodes also expose endpoints for talking to particular chains that are either part of the Primary Network (the X, P and C chains), or part of any Subnets the node might be syncing or validating. +Besides the APIs that are local to the node, like Admin or Metrics APIs, nodes also expose endpoints for talking to particular chains that are either part of the Primary Network (the X, P and C chains), or part of any Avalanche L1s the node might be syncing or validating. In general, chain endpoints are formatted as: @@ -54,25 +54,25 @@ The Primary Network consists of three chains: X, P and C chain. As those chains ### C-Chain and Subnet-EVM Endpoints[​](#c-chain-and-subnet-evm-endpoints "Direct link to heading") -C-Chain and many Subnets run a version of the EthereumVM (EVM). EVM exposes its own endpoints, which are also accessible on the node: JSON-RPC, and Websocket. +C-Chain and many Avalanche L1s run a version of the EthereumVM (EVM). EVM exposes its own endpoints, which are also accessible on the node: JSON-RPC, and Websocket. #### JSON-RPC EVM Endpoints[​](#json-rpc-evm-endpoints "Direct link to heading") To interact with C-Chain EVM via the JSON-RPC use the endpoint: -To interact with Subnet instances of the EVM via the JSON-RPC endpoint: +To interact with Avalanche L1 instances of the EVM via the JSON-RPC endpoint: ``` /ext/bc/[blockchainID]/rpc ``` -where `blockchainID` is the ID of the blockchain running the EVM. So for example, the RPC URL for the DFK Network (a Subnet that runs the DeFi Kingdoms:Crystalvale game) running on a local node would be: +where `blockchainID` is the ID of the blockchain running the EVM. So for example, the RPC URL for the DFK Network (an Avalanche L1 that runs the DeFi Kingdoms:Crystalvale game) running on a local node would be: ``` http://127.0.0.1/ext/bc/q2aTwKuyzgs8pynF7UXBZCU7DejbZbZ6EUyHr3JQzYgwNPUPi/rpc ``` -Or for the WAGMI Subnet on the Fuji testnet: +Or for the WAGMI Avalanche L1 on the Fuji testnet: ``` http://127.0.0.1/ext/bc/2ebCneCbwthjQ1rYT41nhd7M76Hc6YmosMAQrTFhBq8qeqh6tt/rpc @@ -94,7 +94,7 @@ ws://127.0.0.1:9650/ext/bc/C/ws When using the [Public API](/tooling/rpc-providers) or another host that supports HTTPS, use `https://` or `wss://` instead of `http://` or `ws://`. -Also, note that the [public API](/tooling/rpc-providers#supported-apis) only supports C-Chain websocket API calls for API methods that don't exist on the C-Chain's HTTP API. +Also, note that the [public API](/tooling/rpc-providers#using-the-public-api-nodes) only supports C-Chain websocket API calls for API methods that don't exist on the C-Chain's HTTP API. @@ -181,4 +181,4 @@ Some APIs may use a standard other than JSON RPC 2.0 to format their requests an Sending and Receiving Bytes[​](#sending-and-receiving-bytes "Direct link to heading") ------------------------------------------------------------------------------------- -Unless otherwise noted, when bytes are sent in an API call/response, they are in hex representation. However, Transaction IDs (TXIDs), ChainIDs, and subnetIDs are in [CB58](https://support.avalabs.org/en/articles/4587395-what-is-cb58) representation, a base-58 encoding with a checksum. \ No newline at end of file +Unless otherwise noted, when bytes are sent in an API call/response, they are in hex representation. However, Transaction IDs (TXIDs), ChainIDs, and subnetIDs are in [CB58](https://support.avalabs.org/en/articles/4587395-what-is-cb58) representation, a base-58 encoding with a checksum. diff --git a/content/docs/api-reference/standards/guides/txn-fees.mdx b/content/docs/api-reference/standards/guides/txn-fees.mdx index 9c6d2c5d51d..c994dc01efb 100644 --- a/content/docs/api-reference/standards/guides/txn-fees.mdx +++ b/content/docs/api-reference/standards/guides/txn-fees.mdx @@ -15,23 +15,23 @@ Different types of transactions require payment of a different transaction fee. +----------+---------------------------+--------------------------------+ | Chain | Transaction Type | Mainnet Transaction Fee (AVAX) | +----------+---------------------------+--------------------------------+ -| P | Create Subnet | 1 | +| P | Create Layer 1 | 1 | +----------+---------------------------+--------------------------------+ | P | Create Blockchain | 1 | +----------+---------------------------+--------------------------------+ | P | Add Validator | 0 | +----------+---------------------------+--------------------------------+ -| P | Add Subnet Validator | 0.001 | +| P | Add Avalanche L1 Validator | 0.001 | +----------+---------------------------+--------------------------------+ | P | Add Permissionless | Primary Network: 0 | -| | Validator | Subnet: 0.001 | +| | Validator | Avalanche L1: 0.001 | +----------+---------------------------+--------------------------------+ | P | Add Delegator | 0 | +----------+---------------------------+--------------------------------+ -| P | Add Subnet Delegator | 0.001 | +| P | Add Avalanche L1 Delegator | 0.001 | +----------+---------------------------+--------------------------------+ | P | Add Permissionless | Primary Network: 0 | -| | Delegator | Subnet: 0.001 | +| | Delegator | Avalanche L1: 0.001 | +----------+---------------------------+--------------------------------+ | P | Import AVAX | 0.001 | +----------+---------------------------+--------------------------------+ @@ -56,7 +56,7 @@ Different types of transactions require payment of a different transaction fee. On Fuji Testnet, all fees are the same as those on Mainnet, except the following ones: -- Create Subnet: 0.1 AVAX +- Create Avalanche L1: 0.1 AVAX - Create Blockchain: 0.1 AVAX C-Chain Fees[​](#c-chain-fees "Direct link to heading") @@ -107,4 +107,4 @@ Gas Used: Therefore, the gas used by an atomic transaction is `1 * len(unsignedTxBytes) + 1,000 * numSignatures + 10,000` -The TX fee additionally takes the base fee into account. Due to the fact that atomic transactions use units denominated in 9 decimal places, the base fee must be converted to 9 decimal places before calculating the actual fee paid by the transaction. Therefore, the actual fee is: `gasUsed * baseFee (converted to 9 decimals)`. \ No newline at end of file +The TX fee additionally takes the base fee into account. Due to the fact that atomic transactions use units denominated in 9 decimal places, the base fee must be converted to 9 decimal places before calculating the actual fee paid by the transaction. Therefore, the actual fee is: `gasUsed * baseFee (converted to 9 decimals)`. diff --git a/content/docs/api-reference/standards/guides/x-chain-migration.mdx b/content/docs/api-reference/standards/guides/x-chain-migration.mdx index c8a40312a08..6ea061b1cf4 100644 --- a/content/docs/api-reference/standards/guides/x-chain-migration.mdx +++ b/content/docs/api-reference/standards/guides/x-chain-migration.mdx @@ -83,7 +83,7 @@ After Cortina activation, it will also be possible to fetch X-Chain blocks direc Deprecated API Calls[​](#deprecated-api-calls "Direct link to heading") ----------------------------------------------------------------------- -This long-term deprecation effort will better align usage of AvalancheGo with its purpose, to be a minimal and efficient runtime that supports only what is required to validate the Primary Network and Subnets. Integrators should make plans to migrate to tools and services that are better optimized for serving queries over Avalanche Network state and avoid keeping any keys on the node itself. +This long-term deprecation effort will better align usage of AvalancheGo with its purpose, to be a minimal and efficient runtime that supports only what is required to validate the Primary Network and Avalanche L1s. Integrators should make plans to migrate to tools and services that are better optimized for serving queries over Avalanche Network state and avoid keeping any keys on the node itself. @@ -159,4 +159,4 @@ No. As a reminder, you can check your validator's estimated uptime using the [`i ### I Think Something Is Wrong. What Should I Do?[​](#i-think-something-is-wrong-what-should-i-do "Direct link to heading") -First, make sure that you've read the documentation thoroughly and checked the [FAQs](https://support.avax.network/en/). If you don't see an answer to your question, go to our [Discord](https://discord.com/invite/RwXY7P6) server and search for your question. If it has not already been asked, please post it in the appropriate channel. \ No newline at end of file +First, make sure that you've read the documentation thoroughly and checked the [FAQs](https://support.avax.network/en/). If you don't see an answer to your question, go to our [Discord](https://discord.com/invite/RwXY7P6) server and search for your question. If it has not already been asked, please post it in the appropriate channel. diff --git a/content/docs/api-reference/standards/serialization-primitives.mdx b/content/docs/api-reference/standards/serialization-primitives.mdx index 850ec1b9c80..21eacdffb70 100644 --- a/content/docs/api-reference/standards/serialization-primitives.mdx +++ b/content/docs/api-reference/standards/serialization-primitives.mdx @@ -151,3 +151,4 @@ Results in: [0x00, 0x04, 0x41, 0x76, 0x61, 0x78] ``` + diff --git a/content/docs/api-reference/subnet-evm-api.mdx b/content/docs/api-reference/subnet-evm-api.mdx index 7cbdadf37a1..b47d63178a6 100644 --- a/content/docs/api-reference/subnet-evm-api.mdx +++ b/content/docs/api-reference/subnet-evm-api.mdx @@ -255,4 +255,4 @@ curl -X POST --data '{ } } } -``` \ No newline at end of file +``` diff --git a/content/docs/api-reference/x-chain/api.mdx b/content/docs/api-reference/x-chain/api.mdx index 4533ca0bd43..2ebf9bb8dcd 100644 --- a/content/docs/api-reference/x-chain/api.mdx +++ b/content/docs/api-reference/x-chain/api.mdx @@ -604,7 +604,7 @@ Not recommended for use on Mainnet. See warning notice in [Keystore API](/api-re Get the private key that controls a given address. The returned private key can be added to a user -with [`avm.importKey`](/api-reference/x-chain/api.md#avmimportkey). +with [`avm.importKey`](/api-reference/x-chain/api#avmimportkey). **Signature:** @@ -1599,7 +1599,7 @@ Not recommended for use on Mainnet. See warning notice in [Keystore API](/api-re Mint units of a variable-cap asset created with -[`avm.createVariableCapAsset`](/api-reference/x-chain/api.md#avmcreatevariablecapasset). +[`avm.createVariableCapAsset`](/api-reference/x-chain/api#avmcreatevariablecapasset). **Signature:** @@ -1675,7 +1675,7 @@ Not recommended for use on Mainnet. See warning notice in [Keystore API](/api-re Mint non-fungible tokens which were created with -[`avm.createNFTAsset`](/api-reference/x-chain/api.md#avmcreatenftasset). +[`avm.createNFTAsset`](/api-reference/x-chain/api#avmcreatenftasset). **Signature:** @@ -2304,3 +2304,4 @@ Calling **NewSet** or **NewBloom** resets the filter, and must be followed with ```json 2021/05/11 15:59:35 {"txID":"22HWKHrREyXyAiDnVmGp3TQQ79tHSSVxA9h26VfDEzoxvwveyk"} ``` + diff --git a/content/docs/api-reference/x-chain/configs.mdx b/content/docs/api-reference/x-chain/configs.mdx index 73283d08aa7..02f8eb8ec6c 100644 --- a/content/docs/api-reference/x-chain/configs.mdx +++ b/content/docs/api-reference/x-chain/configs.mdx @@ -33,7 +33,7 @@ _Boolean_ Enables AVM transaction indexing if set to `true`. When set to `true`, AVM transactions are indexed against the `address` and `assetID` involved. This data is available via `avm.getAddressTxs` -[API](/api-reference/x-chain/api.md#avmgetaddresstxs). +[API](/api-reference/x-chain/api#avmgetaddresstxs). If `index-transactions` is set to true, it must always be set to true @@ -53,4 +53,4 @@ Allows incomplete indices. This config value is ignored if there is no X-Chain i _Boolean_ -Enables checksums if set to `true`. \ No newline at end of file +Enables checksums if set to `true`. diff --git a/content/docs/api-reference/x-chain/txn-format.mdx b/content/docs/api-reference/x-chain/txn-format.mdx index 0af652a279c..40dab42f3f5 100644 --- a/content/docs/api-reference/x-chain/txn-format.mdx +++ b/content/docs/api-reference/x-chain/txn-format.mdx @@ -2336,3 +2336,4 @@ Let's make a GenesisAsset: 0x43, 0xab, 0x08, 0x59, ] ``` + diff --git a/content/docs/subnets/add-utility/cross-chain-bridge.mdx b/content/docs/avalanche-l1s/add-utility/cross-chain-bridge.mdx similarity index 97% rename from content/docs/subnets/add-utility/cross-chain-bridge.mdx rename to content/docs/avalanche-l1s/add-utility/cross-chain-bridge.mdx index ca81abb8494..892763eb020 100644 --- a/content/docs/subnets/add-utility/cross-chain-bridge.mdx +++ b/content/docs/avalanche-l1s/add-utility/cross-chain-bridge.mdx @@ -10,11 +10,11 @@ This tutorial is for demo purpose on how to build a cross-chain bridge. It is no Introduction[​](#introduction "Direct link to heading") ------------------------------------------------------- -In this tutorial, we will be building a bridge between **[WAGMI](/subnets/wagmi-case-study)** and **[Fuji](/learn/networks/fuji-testnet)**. This bridge will help us to transfer native **WGM** coin wrapped into **wWGM** back and forth from the WAGMI chain to the Fuji chain. Using this guide, you can deploy a bridge between any EVM-based chains for any ERC20 tokens. +In this tutorial, we will be building a bridge between **[WAGMI](/avalanche-l1s/wagmi-avalanche-l1)** and **[Fuji](/learn/networks/fuji-testnet)**. This bridge will help us to transfer native **WGM** coin wrapped into **wWGM** back and forth from the WAGMI chain to the Fuji chain. Using this guide, you can deploy a bridge between any EVM-based chains for any ERC20 tokens. The wrapped version of a native coin is its pegged ERC20 representation. Wrapping it with the ERC20 standard makes certain processes like delegated transactions much easier. You can easily get wrapped tokens by sending the native coin to the wrapped token contract address. -> WAGMI is an independent EVM-based test chain deployed on a custom Subnet on the Avalanche network. +> WAGMI is an independent EVM-based test chain deployed on a custom Avalanche L1 on the Avalanche network. We will be using **ChainSafe**\'s bridge repository, to easily set up a robust and secure bridge. @@ -43,7 +43,7 @@ Requirements[​](#requirements "Direct link to heading") These are the requirement to follow this tutorial: -- Set up [WAGMI](/subnets/wagmi-case-study#adding-wagmi-to-core) and [Fuji](/dapps/end-to-end/fuji-workflow#set-up-fuji-network-on-core-optional) on Core +- Set up [WAGMI](/avalanche-l1s/wagmi-avalanche-l1) and [Fuji](/dapps/end-to-end/fuji-workflow#set-up-fuji-network-on-core-optional) on Core - Import `wWGM` token (asset) on the WAGMI network (Core). Here is the address - `0x3Ee7094DADda15810F191DD6AcF7E4FFa37571e4` - `WGM` coins on the WAGMI chain. Drip `1 WGM` from the [WAGMI Faucet](https://faucet.trywagmi.xyz/). - `AVAX` coins on the Fuji chain. Drip `10 AVAX` from the [Fuji Faucet](https://core.app/tools/testnet-faucet//). If you already have an AVAX balance greater than zero on Mainnet, paste your C-Chain address there, and request test tokens. Otherwise, please request a faucet coupon on [Guild](https://guild.xyz/avalanche). Admins and mods on the official [Discord](https://discord.com/invite/RwXY7P6) can provide testnet AVAX if developers are unable to obtain it from the other two options. @@ -340,4 +340,4 @@ Conclusion[​](#conclusion "Direct link to heading") Similar to the above process, you can deploy a bridge between any 2 EVM-based chains. We have used the command-line tool to make approvals and deposits. This can be further extended to build a frontend integrated with the bridge. Currently, it depends on a single relayer, which is not secure. We need a large set of relayers and a high threshold to avoid any kind of centralization. -You can learn more about these contracts and implementations by reading ChainSafe's [ChainBridge](https://chainbridge.chainsafe.io/) documentation. \ No newline at end of file +You can learn more about these contracts and implementations by reading ChainSafe's [ChainBridge](https://chainbridge.chainsafe.io/) documentation. diff --git a/content/docs/subnets/add-utility/deploy-smart-contract.mdx b/content/docs/avalanche-l1s/add-utility/deploy-smart-contract.mdx similarity index 65% rename from content/docs/subnets/add-utility/deploy-smart-contract.mdx rename to content/docs/avalanche-l1s/add-utility/deploy-smart-contract.mdx index 382bc8f13be..4c4a910019e 100644 --- a/content/docs/subnets/add-utility/deploy-smart-contract.mdx +++ b/content/docs/avalanche-l1s/add-utility/deploy-smart-contract.mdx @@ -1,18 +1,18 @@ --- title: Deploy a Smart Contract -description: Deploy a smart contract on your Subnet. +description: Deploy a smart contract on your Avalanche L1. --- This tutorial assumes that: -- [A Subnet and EVM blockchain](/subnets/deploy-a-subnet/fuji-testnet) has been created -- Your Node is currently validating your target Subnet -- Your wallet has a balance of the Subnet Native Token(Specified under _alloc_ in your [Genesis File](/subnets/upgrade/customize-subnet#genesis)). +- [an Avalanche L1 and EVM blockchain](/avalanche-l1s/deploy-a-avalanche-l1/fuji-testnet) has been created +- Your Node is currently validating your target Avalanche L1 +- Your wallet has a balance of the Avalanche L1 Native Token(Specified under _alloc_ in your [Genesis File](/avalanche-l1s/upgrade/customize-avalanche-l1#genesis)). Step 1: Setting up Core[​](#step-1-setting-up-core "Direct link to heading") ---------------------------------------------------------------------------- -### **EVM Subnet Settings**: [(EVM Core Tutorial)](/subnets/deploy-a-subnet/fuji-testnet#connect-with-core)[​](#evm-subnet-settings-evm-core-tutorial "Direct link to heading") +### **EVM Avalanche L1 Settings**: [(EVM Core Tutorial)](/avalanche-l1s/deploy-a-avalanche-l1/fuji-testnet#connect-with-core)[​](#evm-avalanche-l1-settings-evm-core-tutorial "Direct link to heading") - **`Network Name`**: Custom Subnet-EVM - **`New RPC URL`**: http://NodeIPAddress:9650/ext/bc/BlockchainID/rpc (Note: the port number should match your local setting which can be different from 9650.) @@ -20,7 +20,7 @@ Step 1: Setting up Core[​](#step-1-setting-up-core "Direct link to heading") - **`Symbol`**: Subnet-EVM Token Symbol - **`Explorer`**: N/A -You should see a balance of your Subnet's Native Token in Core. +You should see a balance of your Avalanche L1's Native Token in Core. ![balance](/images/smart-contract1.png) @@ -31,7 +31,7 @@ Step 2: Connect Core and Deploy a Smart Contract[​](#step-2-connect-core-and-d Open [Remix](https://remix.ethereum.org/) -> Select Solidity. -![remix Subnet evm sc home](/images/smart-contract2.png) +![remix Avalanche L1 evm sc home](/images/smart-contract2.png) Create the smart contracts that we want to compile and deploy using Remix file explorer @@ -39,27 +39,27 @@ Create the smart contracts that we want to compile and deploy using Remix file e In Remix Home _Click_ the GitHub button. -![remix Subnet evm sc load panel](/images/smart-contract3.png) +![remix Avalanche L1 evm sc load panel](/images/smart-contract3.png) Paste the [link to the Smart Contract](https://github.com/ava-labs/avalanche-smart-contract-quickstart/blob/main/contracts/NFT.sol) into the popup and _Click_ import. -![remix Subnet evm sc import](/images/smart-contract4.png) +![remix Avalanche L1 evm sc import](/images/smart-contract4.png) For this example, we will deploy an ERC721 contract from the [Avalanche Smart Contract Quickstart Repository](https://github.com/ava-labs/avalanche-smart-contract-quickstart). -![remix Subnet evm sc file explorer](/images/smart-contract5.png) +![remix Avalanche L1 evm sc file explorer](/images/smart-contract5.png) Navigate to Deploy Tab -> Open the "ENVIRONMENT" drop-down and select Injected Web3 (make sure Core is loaded). -![remix Subnet evm sc web3](/images/smart-contract6.png) +![remix Avalanche L1 evm sc web3](/images/smart-contract6.png) Once we injected the web3-> Go back to the compiler, and compile the selected contract -> Navigate to Deploy Tab. -![remix Subnet evm sc compile](/images/smart-contract7.png) +![remix Avalanche L1 evm sc compile](/images/smart-contract7.png) Now, the smart contract is compiled, Core is injected, and we are ready to deploy our ERC721. Click "Deploy." -![remix Subnet evm sc deploy](/images/smart-contract8.png) +![remix Avalanche L1 evm sc deploy](/images/smart-contract8.png) Confirm the transaction on the Core pop up. @@ -67,16 +67,16 @@ Confirm the transaction on the Core pop up. Our contract is successfully deployed! -![remix Subnet evm sc deployed](/images/smart-contract10.png) +![remix Avalanche L1 evm sc deployed](/images/smart-contract10.png) Now, we can expand it by selecting it from the "Deployed Contracts" tab and test it out. -![remix Subnet evm sc end](/images/smart-contract11.png) +![remix Avalanche L1 evm sc end](/images/smart-contract11.png) The contract ABI and Bytecode are available on the compiler tab. -![remix Subnet evm sc ABI](/images/smart-contract12.png) +![remix Avalanche L1 evm sc ABI](/images/smart-contract12.png) If you had any difficulties following this tutorial or simply want to discuss Avalanche with us, you can join our community at [Discord](https://chat.avalabs.org/)! -You can use Subnet-EVM just like you use C-Chain and EVM tools. Only differences are `chainID` and RPC URL. For example you can deploy your contracts with [hardhat quick start guide](/dapps/toolchains/hardhat) by changing `url` and `chainId` in the `hardhat.config.ts`. \ No newline at end of file +You can use Subnet-EVM just like you use C-Chain and EVM tools. Only differences are `chainID` and RPC URL. For example you can deploy your contracts with [hardhat quick start guide](/dapps/toolchains/hardhat) by changing `url` and `chainId` in the `hardhat.config.ts`. diff --git a/content/docs/subnets/add-utility/testnet-faucet.mdx b/content/docs/avalanche-l1s/add-utility/testnet-faucet.mdx similarity index 88% rename from content/docs/subnets/add-utility/testnet-faucet.mdx rename to content/docs/avalanche-l1s/add-utility/testnet-faucet.mdx index 6a9c8dda46b..ce74ae5421d 100644 --- a/content/docs/subnets/add-utility/testnet-faucet.mdx +++ b/content/docs/avalanche-l1s/add-utility/testnet-faucet.mdx @@ -1,34 +1,34 @@ --- title: Add a Testnet Faucet -description: This guide will help you add a testnet faucet to your Subnet. +description: This guide will help you add a testnet faucet to your Avalanche L1. --- There are thousands of networks and chains in the blockchain space, each with its capabilities and use-cases. Each network requires native coins to do any transaction on them, which can have a monetary value as well. These coins can be collected through centralized exchanges, token sales, etc in exchange for some monetary assets like USD. But we cannot risk our funds on the network or on any applications hosted on that network, without testing them first. So, these networks often have test networks or testnets, where the native coins do not have any monetary value, and thus can be obtained freely through faucets. -These testnets are often the testbeds for any new native feature of the network itself, or any dapp or [Subnet](/learn/subnets) that is going live on the main network (Mainnet). For example, [Fuji](/learn/networks/fuji-testnet) network is the Testnet for Avalanche's Mainnet. +These testnets are often the testbeds for any new native feature of the network itself, or any dapp or [Avalanche L1](/learn/avalanche-l1s) that is going live on the main network (Mainnet). For example, [Fuji](/learn/networks/fuji-testnet) network is the Testnet for Avalanche's Mainnet. -Besides Fuji Testnet, the [Avalanche Faucet](https://core.app/tools/testnet-faucet/?subnet=c&token=c) can be used to get free test tokens on testnet Subnets like: +Besides Fuji Testnet, the [Avalanche Faucet](https://core.app/tools/testnet-faucet/?avalanche-l1=c&token=c) can be used to get free test tokens on testnet Avalanche L1s like: -- [WAGMI Testnet](https://core.app/tools/testnet-faucet/?subnet=wagmi) -- [DeFI Kingdoms Testnet](https://core.app/tools/testnet-faucet/?subnet=dfk) -- [Beam Testnet](https://core.app/tools/testnet-faucet/?subnet=beam&token=beam) and many more. +- [WAGMI Testnet](https://core.app/tools/testnet-faucet/?avalanche-l1=wagmi) +- [DeFI Kingdoms Testnet](https://core.app/tools/testnet-faucet/?avalanche-l1=dfk) +- [Beam Testnet](https://core.app/tools/testnet-faucet/?avalanche-l1=beam&token=beam) and many more. -You can use this [repository](https://github.com/ava-labs/avalanche-faucet) to deploy your faucet or just make a PR with the [configurations](https://github.com/ava-labs/avalanche-faucet/blob/main/config.json) of the Subnet. This faucet comes with many features like multiple chain support, custom rate-limiting per Subnet, CAPTCHA verification, and concurrent transaction handling. +You can use this [repository](https://github.com/ava-labs/avalanche-faucet) to deploy your faucet or just make a PR with the [configurations](https://github.com/ava-labs/avalanche-faucet/blob/main/config.json) of the Avalanche L1. This faucet comes with many features like multiple chain support, custom rate-limiting per Avalanche L1, CAPTCHA verification, and concurrent transaction handling. Summary[​](#summary "Direct link to heading") --------------------------------------------- -A [Faucet](https://core.app/tools/testnet-faucet/) powered by Avalanche for Fuji Network and other Subnets. You can - +A [Faucet](https://core.app/tools/testnet-faucet/) powered by Avalanche for Fuji Network and other Avalanche L1s. You can - -- Request test coins for the supported Subnets -- Integrate your EVM Subnet with the faucet by making a PR with the [chain configurations](https://github.com/ava-labs/avalanche-faucet/blob/main/config.json) +- Request test coins for the supported Avalanche L1s +- Integrate your EVM Avalanche L1 with the faucet by making a PR with the [chain configurations](https://github.com/ava-labs/avalanche-faucet/blob/main/config.json) - Fork the [repository](https://github.com/ava-labs/avalanche-faucet) to deploy your faucet for any EVM chain -Adding a New Subnet[​](#adding-a-new-subnet "Direct link to heading") +Adding a New Avalanche L1[​](#adding-a-new-avalanche-l1 "Direct link to heading") --------------------------------------------------------------------- -You can also integrate a new Subnet on the live [faucet](https://core.app/tools/testnet-faucet/) with just a few lines of configuration parameters. All you have to do is make a PR on the [Avalanche Faucet](https://github.com/ava-labs/avalanche-faucet) git repository with the Subnet's information. The following parameters are required. +You can also integrate a new Avalanche L1 on the live [faucet](https://core.app/tools/testnet-faucet/) with just a few lines of configuration parameters. All you have to do is make a PR on the [Avalanche Faucet](https://github.com/ava-labs/avalanche-faucet) git repository with the Avalanche L1's information. The following parameters are required. ```json { @@ -49,8 +49,8 @@ You can also integrate a new Subnet on the live [faucet](https://core.app/tools/ } ``` -- `ID` - Each Subnet chain should have a unique and relatable ID. -- `NAME` - Name of the Subnet chain that will appear on the site. +- `ID` - Each Avalanche L1 chain should have a unique and relatable ID. +- `NAME` - Name of the Avalanche L1 chain that will appear on the site. - `RPC` - A valid RPC URL for accessing the chain. - `CHAINID` - ChainID of the chain - `EXPLORER` - Base URL of standard explorer's site. @@ -85,7 +85,7 @@ git clone https://github.com/ava-labs/avalanche-faucet The repository cloning method used is HTTPS, but SSH can be used too: -`git clone [[email protected]](https://docs.avax.network/cdn-cgi/l/email-protection):ava-labs/avalanche-faucet.git` +`git clone git@github.com:ava-labs/avalanche-faucet.git` You can find more about SSH and how to use it [here](https://docs.github.com/en/authentication/connecting-to-github-with-ssh/about-ssh). @@ -391,13 +391,13 @@ You can use the dropdown to select the network of your choice and get some free If you already have an AVAX balance greater than zero on Mainnet, paste your C-Chain address there, and request test tokens. Otherwise, please request a faucet coupon on [Guild](https://guild.xyz/avalanche). Admins and mods on the official [Discord](https://discord.com/invite/RwXY7P6) can provide testnet AVAX if developers are unable to obtain it from the other two options. -Within a second, you will get a **transaction hash** for the processed transaction. The hash would be a hyperlink to Subnet's explorer. You can see the transaction status, by clicking on that hyperlink. +Within a second, you will get a **transaction hash** for the processed transaction. The hash would be a hyperlink to Avalanche L1's explorer. You can see the transaction status, by clicking on that hyperlink. ![faucet 3](/images/faucet6.png) ### More Interactions[​](#more-interactions "Direct link to heading") -This is not just it. Using the buttons shown below, you can go to the Subnet explorer or add the Subnet to your browser wallet extensions like Core or MetaMask with a single click. +This is not just it. Using the buttons shown below, you can go to the Avalanche L1 explorer or add the Avalanche L1 to your browser wallet extensions like Core or MetaMask with a single click. ![faucet 4](/images/faucet7.png) @@ -405,8 +405,8 @@ This is not just it. Using the buttons shown below, you can go to the Subnet exp Errors are not expected, but if you are facing some of the errors shown, then you could try troubleshooting as shown below. If none of the troubleshooting works, reach us through [Discord](https://discord.com/channels/578992315641626624/). -1. **Too many requests. Please try again after X minutes**: This is a rate-limiting message. Every Subnet can set its drop limits. The above message suggests that you have reached your drop limit, that is the number of times you could request coins within the window of X minutes. You should try requesting after X minutes. If you are facing this problem, even when you are requesting for the first time in the window, you may be behind some proxy, Wi-Fi, or VPN service that is also being used by some other user. +1. **Too many requests. Please try again after X minutes**: This is a rate-limiting message. Every Avalanche L1 can set its drop limits. The above message suggests that you have reached your drop limit, that is the number of times you could request coins within the window of X minutes. You should try requesting after X minutes. If you are facing this problem, even when you are requesting for the first time in the window, you may be behind some proxy, Wi-Fi, or VPN service that is also being used by some other user. 2. **CAPTCHA verification failed! Try refreshing**: We are using v3 of [Google's reCAPTCHA](https://developers.google.com/recaptcha/docs/v3). This version uses scores between 0 and 1 to rate the interaction of humans with the site, with 0 being the most suspicious one. You do not have to solve any puzzle or mark the **I am not a Robot** checkbox. The score will be automatically calculated. We want our users to score at least 0.3 to use the faucet. This is configurable, and we will update the threshold after having broader data. But if you are facing this issue, then you can try refreshing your page, disabling ad-blockers, or switching off any VPN. You can follow this [guide](https://2captcha.com/blog/google-doesnt-accept-recaptcha-answers) to get rid of this issue. -3. **Internal RPC error! Please try after sometime**: This is an internal error in the Subnet's node, on which we are making an RPC for sending transactions. A regular check will update the RPC's health status every 30 seconds (default) or whatever is set in the configuration. This may happen only in rare scenarios and you cannot do much about it, rather than waiting. +3. **Internal RPC error! Please try after sometime**: This is an internal error in the Avalanche L1's node, on which we are making an RPC for sending transactions. A regular check will update the RPC's health status every 30 seconds (default) or whatever is set in the configuration. This may happen only in rare scenarios and you cannot do much about it, rather than waiting. 4. **Timeout of 10000ms exceeded**: There could be many reasons for this message. It could be an internal server error, or the request didn't receive by the server, slow internet, etc. You could try again after some time, and if the problem persists, then you should raise this issue on our [Discord](https://discord.com/channels/578992315641626624/) server. -5. **Couldn't see any transaction status on explorer**: The transaction hash that you get for each drop is pre-computed using the expected nonce, amount, and receiver's address. Though transactions on Avalanche are near-instant, the explorer may take time to index those transactions. You should wait for a few more seconds, before raising any issue or reaching out to us. \ No newline at end of file +5. **Couldn't see any transaction status on explorer**: The transaction hash that you get for each drop is pre-computed using the expected nonce, amount, and receiver's address. Though transactions on Avalanche are near-instant, the explorer may take time to index those transactions. You should wait for a few more seconds, before raising any issue or reaching out to us. diff --git a/content/docs/subnets/avalanche-cli-subnets.mdx b/content/docs/avalanche-l1s/avalanche-cli-avalanche-l1s.mdx similarity index 74% rename from content/docs/subnets/avalanche-cli-subnets.mdx rename to content/docs/avalanche-l1s/avalanche-cli-avalanche-l1s.mdx index 48216648a9b..c2f79ffcb1b 100644 --- a/content/docs/subnets/avalanche-cli-subnets.mdx +++ b/content/docs/avalanche-l1s/avalanche-cli-avalanche-l1s.mdx @@ -1,11 +1,11 @@ --- title: Avalanche-CLI -description: Learn about Avalanche CLI and its different commands for Subnets. +description: Learn about Avalanche CLI and its different commands for Avalanche L1s. --- -Avalanche-CLI is a command-line tool that gives developers access to everything Avalanche. This release specializes in helping developers build and test Subnets. +Avalanche-CLI is a command-line tool that gives developers access to everything Avalanche. This release specializes in helping developers build and test Avalanche L1s. -To get started, look at the documentation for the subcommands or jump right in with `avalanche blockchain create myNewSubnet`. +To get started, look at the documentation for the subcommands or jump right in with `avalanche blockchain create myblockchain`. [Install Avalanche CLI](/tooling/guides/get-avalanche-cli) @@ -46,58 +46,58 @@ avalanche primary addValidator [flags] --delegation-fee uint set the delegation fee (20 000 is equivalent to 2%) ``` -Subnet[​](#subnet "Direct link to heading") +Avalanche L1[​](#avalanche-l1 "Direct link to heading") ------------------------------------------- -The `subnet` command suite provides a collection of tools for developing and deploying Subnets. +The `blockchain` command suite provides a collection of tools for developing and deploying Avalanche L1s. -To get started, use the `blockchain create` command wizard to walk through the configuration of your very first Subnet. Then, go ahead and deploy it with the `blockchain deploy` command. You can use the rest of the commands to manage your Subnet configurations and live deployments. +To get started, use the `blockchain create` command wizard to walk through the configuration of your very first Avalanche L1. Then, go ahead and deploy it with the `blockchain deploy` command. You can use the rest of the commands to manage your Avalanche L1 configurations and live deployments. -### Subnet AddValidator[​](#subnet-addvalidator "Direct link to heading") +### Avalanche L1 AddValidator[​](#avalanche-l1-addvalidator "Direct link to heading") -The `blockchain addValidator` command whitelists a primary network validator to validate the provided deployed Subnet. +The `blockchain addValidator` command whitelists a primary network validator to validate the provided deployed Avalanche L1. -To add the validator to the Subnet's allow list, you first need to provide the subnetName and the validator's unique NodeID. The command then prompts for the validation start time, duration, and stake weight. You can bypass these prompts by providing the values with flags. +To add the validator to the Avalanche L1's allow list, you first need to provide the blockchainName and the validator's unique NodeID. The command then prompts for the validation start time, duration, and stake weight. You can bypass these prompts by providing the values with flags. -This command currently only works on Subnets deployed to either the Fuji Testnet or Mainnet. +This command currently only works on Avalanche L1s deployed to either the Fuji Testnet or Mainnet. **Usage**: ```bash -avalanche blockchain addValidator [subnetName] [flags] +avalanche blockchain addValidator [blockchainName] [flags] ``` **Flags**: ```bash - --default-validator-params use default weight/start/duration params for subnet validator - --devnet devnet add subnet validator on devnet + --default-validator-params use default weight/start/duration params for Avalanche L1 validator + --devnet devnet add Avalanche L1 validator on devnet --endpoint string use the given endpoint for network operations -e, --ewoq use ewoq key [fuji/devnet only] - --fuji fuji add subnet validator on fuji (alias for `testnet`) + --fuji fuji add Avalanche L1 validator on fuji (alias for `testnet`) -h, --help help for addValidator -k, --key string select the key to use [fuji/devnet only] -g, --ledger use ledger instead of key (always true on mainnet, defaults to false on fuji/devnet) --ledger-addrs strings use the given ledger addresses - --local local add subnet validator on local - --mainnet mainnet add subnet validator on mainnet + --local local add Avalanche L1 validator on local + --mainnet mainnet add Avalanche L1 validator on mainnet --nodeID string set the NodeID of the validator to add --output-tx-path string file path of the add validator tx --staking-period duration how long this validator will be staking --start-time string UTC start time when this validator starts validating, in 'YYYY-MM-DD HH:MM:SS' format --subnet-auth-keys strings control keys that will be used to authenticate add validator tx - --testnet testnet add subnet validator on testnet (alias for `fuji`) + --testnet testnet add Avalanche L1 validator on testnet (alias for `fuji`) --weight uint set the staking weight of the validator to add ``` -### Remove Validator in a Subnet[​](#remove-validator-in-a-subnet "Direct link to heading") +### Remove Validator in an Avalanche L1[​](#remove-validator-in-a-avalanche-l1 "Direct link to heading") -This command removes a node as a validator in a Subnet. +This command removes a node as a validator in an Avalanche L1. **Usage**: ```bash -avalanche blockchain removeValidator [subnetName] [flags] +avalanche blockchain removeValidator [blockchainName] [flags] ``` **Flags**: @@ -109,51 +109,51 @@ avalanche blockchain removeValidator [subnetName] [flags] --ledger-addrs strings use the given ledger addresses --local remove validator in existing local deployment --mainnet remove validator in existing mainnet deployment - --nodeID string node id of node to be added as validator in elastic subnet + --nodeID string node id of node to be added as validator in elastic Avalanche L1 --output-tx-path string file path of the removeValidator tx --subnet-auth-keys strings control keys that will be used to authenticate removeValidator tx --testnet remove validator in existing testnet deployment (alias for `fuji`) ``` -### Subnet Change Owner[​](#subnet-change-owner "Direct link to heading") +### Avalanche L1 Change Owner[​](#avalanche-l1-change-owner "Direct link to heading") -The `blockchain changeOwner` changes the owner of the deployed Subnet. This command currently only works on Subnets deployed to Devnet, Fuji or Mainnet. +The `blockchain changeOwner` changes the owner of the deployed Avalanche L1. This command currently only works on Avalanche L1s deployed to Devnet, Fuji or Mainnet. **Usage**: ```bash -avalanche blockchain changeOwner [subnetName] [flags] +avalanche blockchain changeOwner [blockchainName] [flags] ``` **Flags**: ```bash - --control-keys strings addresses that may make subnet changes - --devnet devnet change subnet owner on devnet + --control-keys strings addresses that may make Avalanche L1 changes + --devnet devnet change Avalanche L1 owner on devnet --endpoint string use the given endpoint for network operations -e, --ewoq use ewoq key [fuji/devnet] - --fuji fuji change subnet owner on fuji (alias for `testnet`) + --fuji fuji change Avalanche L1 owner on fuji (alias for `testnet`) -h, --help help for changeOwner -k, --key string select the key to use [fuji/devnet] -g, --ledger use ledger instead of key (always true on mainnet, defaults to false on fuji/devnet) --ledger-addrs strings use the given ledger addresses - --local local change subnet owner on local - --mainnet mainnet change subnet owner on mainnet - --output-tx-path string file path of the transfer subnet ownership tx + --local local change Avalanche L1 owner on local + --mainnet mainnet change Avalanche L1 owner on mainnet + --output-tx-path string file path of the transfer Avalanche L1 ownership tx -s, --same-control-key use the fee-paying key as control key - --subnet-auth-keys strings control keys that will be used to authenticate transfer subnet ownership tx - --testnet testnet change subnet owner on testnet (alias for `fuji`) - --threshold uint32 required number of control key signatures to make subnet changes + --subnet-auth-keys strings control keys that will be used to authenticate transfer Avalanche L1 ownership tx + --testnet testnet change Avalanche L1 owner on testnet (alias for `fuji`) + --threshold uint32 required number of control key signatures to make Avalanche L1 changes ``` -### Subnet Configure[​](#subnet-configure "Direct link to heading") +### Avalanche L1 Configure[​](#avalanche-l1-configure "Direct link to heading") -AvalancheGo nodes support several different configuration files. Subnets have their own Subnet config which applies to all chains/VMs in the Subnet. Each chain within the Subnet can have its own chain config. This command allows you to set both config files. +AvalancheGo nodes support several different configuration files. Avalanche L1s have their own Avalanche L1 config which applies to all chains/VMs in the Avalanche L1. Each chain within the Avalanche L1 can have its own chain config. This command allows you to set both config files. **Usage**: ```bash -avalanche blockchain configure [subnetName] [flags] +avalanche blockchain configure [blockchainName] [flags] ``` **Flags**: @@ -162,21 +162,21 @@ avalanche blockchain configure [subnetName] [flags] --chain-config string path to the chain configuration -h, --help help for configure --per-node-chain-config string path to per node chain configuration for local network - --subnet-config string path to the subnet configuration + --subnet-config string path to the Avalanche L1 configuration ``` -### Subnet Create[​](#subnet-create "Direct link to heading") +### Avalanche L1 Create[​](#avalanche-l1-create "Direct link to heading") -The `blockchain create` command builds a new genesis file to configure your Subnet. By default, the command runs an interactive wizard. It walks you through all the steps you need to create your first Subnet. +The `blockchain create` command builds a new genesis file to configure your Avalanche L1. By default, the command runs an interactive wizard. It walks you through all the steps you need to create your first Avalanche L1. The tool supports deploying Subnet-EVM and custom VMs. You can create a custom, user-generated genesis with a custom VM by providing the path to your genesis and VM binaries with the `--genesis` and `--vm` flags. -By default, running the command with a `subnetName` that already exists causes the command to fail. If you'd like to overwrite an existing configuration, pass the `-f` flag. +By default, running the command with a `blockchainName` that already exists causes the command to fail. If you'd like to overwrite an existing configuration, pass the `-f` flag. **Usage**: ```bash -avalanche blockchain create [subnetName] [flags] +avalanche blockchain create [blockchainName] [flags] ``` **Flags**: @@ -202,9 +202,9 @@ avalanche blockchain create [subnetName] [flags] --vm-version string version of Subnet-EVM template to use ``` -### Subnet Delete[​](#subnet-delete "Direct link to heading") +### Avalanche L1 Delete[​](#avalanche-l1-delete "Direct link to heading") -The `blockchain delete` command deletes an existing Subnet configuration. +The `blockchain delete` command deletes an existing Avalanche L1 configuration. **Usage**: @@ -218,18 +218,18 @@ avalanche blockchain delete [flags] -h, --help help for delete ``` -### Subnet Deploy[​](#subnet-deploy "Direct link to heading") +### Avalanche L1 Deploy[​](#avalanche-l1-deploy "Direct link to heading") -The `blockchain deploy` command deploys your Subnet configuration locally, to Fuji Testnet, or to Mainnet. +The `blockchain deploy` command deploys your Avalanche L1 configuration locally, to Fuji Testnet, or to Mainnet. -At the end of the call, the command prints the RPC URL you can use to interact with the Subnet. +At the end of the call, the command prints the RPC URL you can use to interact with the Avalanche L1. -Avalanche-CLI only supports deploying an individual Subnet once per network. Subsequent attempts to deploy the same Subnet to the same network (local, Fuji, Mainnet) aren't allowed. If you'd like to redeploy a Subnet locally for testing, you must first call [avalanche network clean](#network-clean) to reset all deployed chain state. Subsequent local deploys redeploy the chain with fresh state. You can deploy the same Subnet to multiple networks, so you can take your locally tested Subnet and deploy it on Fuji or Mainnet. +Avalanche-CLI only supports deploying an individual Avalanche L1 once per network. Subsequent attempts to deploy the same Avalanche L1 to the same network (local, Fuji, Mainnet) aren't allowed. If you'd like to redeploy an Avalanche L1 locally for testing, you must first call [avalanche network clean](#network-clean) to reset all deployed chain state. Subsequent local deploys redeploy the chain with fresh state. You can deploy the same Avalanche L1 to multiple networks, so you can take your locally tested Avalanche L1 and deploy it on Fuji or Mainnet. **Usage**: ```bash -avalanche blockchain deploy [subnetName] [flags] +avalanche blockchain deploy [blockchainName] [flags] ``` **Flags**: @@ -237,7 +237,7 @@ avalanche blockchain deploy [subnetName] [flags] ```bash --avalanchego-path string use this avalanchego binary path --avalanchego-version string use this version of avalanchego (ex: v1.17.12) (default "latest") - --control-keys strings addresses that may make subnet changes + --control-keys strings addresses that may make Avalanche L1 changes --devnet deploy to a devnet network --endpoint string use the given endpoint for network operations -e, --ewoq use ewoq key [fuji/devnet deploy only] @@ -254,17 +254,17 @@ avalanche blockchain deploy [subnetName] [flags] --subnet-auth-keys strings control keys that will be used to authenticate chain creation -u, --subnet-id string deploy into given subnet id -t, --testnet fuji deploy to testnet (alias to fuji) - --threshold uint32 required number of control key signatures to make subnet changes + --threshold uint32 required number of control key signatures to make Avalanche L1 changes ``` -### Subnet Describe[​](#subnet-describe "Direct link to heading") +### Avalanche L1 Describe[​](#avalanche-l1-describe "Direct link to heading") -The `blockchain describe` command prints the details of a Subnet configuration to the console. By default, the command prints a summary of the configuration. By providing the `--genesis` flag, the command instead prints out the raw genesis file. +The `blockchain describe` command prints the details of an Avalanche L1 configuration to the console. By default, the command prints a summary of the configuration. By providing the `--genesis` flag, the command instead prints out the raw genesis file. **Usage**: ```bash -avalanche blockchain describe [subnetName] [flags] +avalanche blockchain describe [blockchainName] [flags] ``` **Flags**: @@ -274,14 +274,14 @@ avalanche blockchain describe [subnetName] [flags] -h, --help help for describe ``` -### Subnet Export[​](#subnet-export "Direct link to heading") +### Avalanche L1 Export[​](#avalanche-l1-export "Direct link to heading") -The `blockchain export` command write the details of an existing Subnet deploy to a file. The command prompts for an output path. You can also provide one with the `--output` flag. +The `blockchain export` command write the details of an existing Avalanche L1 deploy to a file. The command prompts for an output path. You can also provide one with the `--output` flag. **Usage**: ```bash -avalanche blockchain export [subnetName] [flags] +avalanche blockchain export [blockchainName] [flags] ``` **Flags**: @@ -291,20 +291,20 @@ avalanche blockchain export [subnetName] [flags] -o, --output string write the export data to the provided file path ``` -### Subnet Import[​](#subnet-import "Direct link to heading") +### Avalanche L1 Import[​](#avalanche-l1-import "Direct link to heading") The `blockchain import` command imports configurations into Avalanche-CLI. -This command supports importing from a file created on another computer, or importing from Subnets running public networks (for example, created manually or with the deprecated Subnet-CLI) +This command supports importing from a file created on another computer, or importing from Avalanche L1s running public networks (for example, created manually or with the deprecated Avalanche L1-CLI) #### Import from a File[​](#import-from-a-file "Direct link to heading") -To import from a file, you can optionally provide the path as a command-line argument. Alternatively, running the command without any arguments triggers an interactive wizard. To import from a repository, go through the wizard. By default, an imported Subnet doesn't overwrite an existing Subnet with the same name. To allow overwrites, provide the `--force` flag. +To import from a file, you can optionally provide the path as a command-line argument. Alternatively, running the command without any arguments triggers an interactive wizard. To import from a repository, go through the wizard. By default, an imported Avalanche L1 doesn't overwrite an existing Avalanche L1 with the same name. To allow overwrites, provide the `--force` flag. **Usage**: ```bash -avalanche blockchain import file [subnetPath] [flags] +avalanche blockchain import file [blockchainPath] [flags] ``` **Flags**: @@ -314,19 +314,19 @@ avalanche blockchain import file [subnetPath] [flags] -f, --force overwrite the existing configuration if one exists -h, --help help for import --repo string the repo to import (ex: ava-labs/avalanche-plugins-core) or url to download the repo from - --subnet string the subnet configuration to import from the provided repo + --subnet string the Avalanche L1 configuration to import from the provided repo ``` #### Import from a Public Network[​](#import-from-a-public-network "Direct link to heading") -The `blockchain import public` command imports a Subnet configuration from a running network. +The `blockchain import public` command imports an Avalanche L1 configuration from a running network. -The genesis file should be available from the disk for this to work. By default, an imported Subnet doesn't overwrite an existing Subnet with the same name. To allow overwrites, provide the `--force` flag. +The genesis file should be available from the disk for this to work. By default, an imported Avalanche L1 doesn't overwrite an existing Avalanche L1 with the same name. To allow overwrites, provide the `--force` flag. **Usage**: ```bash -avalanche blockchain import public [subnetPath] [flags] +avalanche blockchain import public [blockchainPath] [flags] ``` **Flags**: @@ -339,26 +339,26 @@ avalanche blockchain import public [subnetPath] [flags] --genesis-file-path string path to the genesis file -h, --help help for public --mainnet mainnet import from mainnet - --node-url string [optional] URL of an already running subnet validator + --node-url string [optional] URL of an already running Avalanche L1 validator --subnet-id string the subnet ID --testnet testnet import from testnet (alias for `fuji`) ``` -### Subnet Join[​](#subnet-join "Direct link to heading") +### Avalanche L1 Join[​](#avalanche-l1-join "Direct link to heading") -The `blockchain join` command configures your validator node to begin validating a new Subnet. +The `blockchain join` command configures your validator node to begin validating a new Avalanche L1. -To complete this process, you must have access to the machine running your validator. If the CLI is running on the same machine as your validator, it can generate or update your node's config file automatically. Alternatively, the command can print the necessary instructions to update your node manually. To complete the validation process, the Subnet's admins must add the NodeID of your validator to the Subnet's allow list by calling `addValidator` with your NodeID. +To complete this process, you must have access to the machine running your validator. If the CLI is running on the same machine as your validator, it can generate or update your node's config file automatically. Alternatively, the command can print the necessary instructions to update your node manually. To complete the validation process, the Avalanche L1's admins must add the NodeID of your validator to the Avalanche L1's allow list by calling `addValidator` with your NodeID. After you update your validator's config, you need to restart your validator manually. If you provide the `--avalanchego-config` flag, this command attempts to edit the config file at that path. -This command currently only supports Subnets deployed on the Fuji Testnet and Mainnet. +This command currently only supports Avalanche L1s deployed on the Fuji Testnet and Mainnet. **Usage**: ```bash -avalanche blockchain join [subnetName] [flags] +avalanche blockchain join [blockchainName] [flags] ``` **Flags**: @@ -378,9 +378,9 @@ avalanche blockchain join [subnetName] [flags] --testnet testnet join on testnet (alias for `fuji`) ``` -### Subnet List[​](#subnet-list "Direct link to heading") +### Avalanche L1 List[​](#avalanche-l1-list "Direct link to heading") -The `blockchain list` command prints the names of all created Subnet configurations. Without any flags, it prints some general, static information about the Subnet. With the `--deployed` flag, the command shows additional information including the VMID, BlockchainID and SubnetID. +The `blockchain list` command prints the names of all created Avalanche L1 configurations. Without any flags, it prints some general, static information about the Avalanche L1. With the `--deployed` flag, the command shows additional information including the VMID, BlockchainID and SubnetID. **Usage**: @@ -395,21 +395,21 @@ avalanche blockchain list [flags] -h, --help help for list ``` -### Subnet Publish[​](#subnet-publish "Direct link to heading") +### Avalanche L1 Publish[​](#avalanche-l1-publish "Direct link to heading") -The `blockchain publish` command publishes the Subnet's VM to a repository. +The `blockchain publish` command publishes the Avalanche L1's VM to a repository. **Usage**: ```bash -avalanche blockchain publish [subnetName] [flags] +avalanche blockchain publish [blockchainName] [flags] ``` **Flags**: ```bash --alias string We publish to a remote repo, but identify the repo locally under a user-provided alias (e.g. myrepo). - --force If true, ignores if the subnet has been published in the past, and attempts a forced publish. + --force If true, ignores if the Avalanche L1 has been published in the past, and attempts a forced publish. -h, --help help for publish --no-repo-path string Do not let the tool manage file publishing, but have it only generate the files and put them in the location given by this flag. --repo-url string The URL of the repo where we are publishing @@ -417,14 +417,14 @@ avalanche blockchain publish [subnetName] [flags] --vm-file-path string Path to the VM description file. If not given, a prompting sequence will be initiated. ``` -### Subnet Stats[​](#subnet-stats "Direct link to heading") +### Avalanche L1 Stats[​](#avalanche-l1-stats "Direct link to heading") -The `blockchain stats` command prints validator statistics for the given Subnet. +The `blockchain stats` command prints validator statistics for the given Avalanche L1. **Usage**: ```bash -avalanche blockchain stats [subnetName] [flags] +avalanche blockchain stats [blockchainName] [flags] ``` **Flags**: @@ -436,60 +436,60 @@ avalanche blockchain stats [subnetName] [flags] --testnet testnet print stats on testnet (alias for `fuji`) ``` -### Subnet VMID[​](#subnet-vmid "Direct link to heading") +### Avalanche L1 VMID[​](#avalanche-l1-vmid "Direct link to heading") -The `blockchain vmid` command prints the virtual machine ID (VMID) for the given Subnet. +The `blockchain vmid` command prints the virtual machine ID (VMID) for the given Avalanche L1. **Usage**: ```bash -avalanche blockchain vmid [subnetName] +avalanche blockchain vmid [blockchainName] ``` -Elastic Subnet[​](#elastic-subnet "Direct link to heading") +Elastic Avalanche L1[​](#elastic-avalanche-l1 "Direct link to heading") ----------------------------------------------------------- -### Transforms permissioned Subnet into Elastic Subnet[​](#transforms-permissioned-subnet-into-elastic-subnet "Direct link to heading") +### Transforms permissioned Avalanche L1 into Elastic Avalanche L1[​](#transforms-permissioned-avalanche-l1-into-elastic-avalanche-l1 "Direct link to heading") -This command transforms your permissioned Subnet into an Elastic Subnet (NOTE: this action is irreversible). +This command transforms your permissioned Avalanche L1 into an Elastic Avalanche L1 (NOTE: this action is irreversible). **Usage**: ```bash -avalanche blockchain elastic [subnetName] [flags] +avalanche blockchain elastic [blockchainName] [flags] ``` **Flags**: ```bash - --default If true, use default elastic subnet config values + --default If true, use default elastic Avalanche L1 config values --denonimation int specify the token denomination (for Fuji and Mainnet only) - --force If true, override transform into elastic subnet warning - --fuji elastic subnet transform existing fuji deployment (alias for `testnet`) + --force If true, override transform into elastic Avalanche L1 warning + --fuji elastic Avalanche L1 transform existing fuji deployment (alias for `testnet`) -k, --key string select the key to use [fuji only] -g, --ledger use ledger instead of key (always true on mainnet, defaults to false on fuji) --ledger-addrs strings use the given ledger addresses - --local elastic subnet transform existing local deployment - --mainnet elastic subnet transform existing mainnet deployment + --local elastic Avalanche L1 transform existing local deployment + --mainnet elastic Avalanche L1 transform existing mainnet deployment --output-tx-path string file path of the transformSubnet tx --stake-amount int amount of tokens to stake on validator --staking-period string how long validator validates for after start time --start-time string when validator starts validating (format as "2006-01-02 15:00:00") --subnet-auth-keys strings control keys that will be used to authenticate transformSubnet tx - --testnet elastic subnet transform existing testnet deployment (alias for `fuji`) + --testnet elastic Avalanche L1 transform existing testnet deployment (alias for `fuji`) --tokenName string specify the token name --tokenSymbol string specify the token symbol --transform-validators If true, transform validators to permissionless validators after elastic transform ``` -### Add Permissionless Validator in an Elastic Subnet[​](#add-permissionless-validator-in-an-elastic-subnet "Direct link to heading") +### Add Permissionless Validator in an Elastic Avalanche L1[​](#add-permissionless-validator-in-an-elastic-avalanche-l1 "Direct link to heading") -This command adds a node as a permissionless validator in an Elastic Subnet. +This command adds a node as a permissionless validator in an Elastic Avalanche L1. **Usage**: ```bash -avalanche blockchain join [subnetName] --elastic [flags] +avalanche blockchain join [blockchainName] --elastic [flags] ``` **Flags**: @@ -501,21 +501,21 @@ avalanche blockchain join [subnetName] --elastic [flags] --ledger-addrs strings use the given ledger addresses --local add permissionless validator in existing local deployment --mainnet add permissionless validator in existing mainnet deployment - --nodeID string node id of node to be added as validator in elastic subnet + --nodeID string node id of node to be added as validator in elastic Avalanche L1 --stake-amount int amount of tokens to stake on validator --staking-period string how long validator validates for after start time --start-time string when validator starts validating (format as "2006-01-02 15:00:00") --testnet add permissionless validator in existing testnet deployment (alias for `fuji`) ``` -### Add Permissionless Delegator in an Elastic Subnet[​](#add-permissionless-delegator-in-an-elastic-subnet "Direct link to heading") +### Add Permissionless Delegator in an Elastic Avalanche L1[​](#add-permissionless-delegator-in-an-elastic-avalanche-l1 "Direct link to heading") -This command delegates stake to a permissionless validator in an Elastic Subnet. +This command delegates stake to a permissionless validator in an Elastic Avalanche L1. **Usage**: ```bash -avalanche blockchain addPermissionlessDelegator [subnetName] [flags] +avalanche blockchain addPermissionlessDelegator [blockchainName] [flags] ``` **Flags**: @@ -527,37 +527,37 @@ avalanche blockchain addPermissionlessDelegator [subnetName] [flags] --ledger-addrs strings use the given ledger addresses --local add permissionless delegator in existing local deployment --mainnet add permissionless delegator in existing mainnet deployment - --nodeID string node id of node to be added as validator in elastic subnet + --nodeID string node id of node to be added as validator in elastic Avalanche L1 --stake-amount int amount of tokens to delegate to validator --staking-period string how long to delegate for after start time --start-time string when to starts delegating (format as "2006-01-02 15:00:00") --testnet add permissionless delegator in existing testnet deployment (alias for `fuji`) ``` -Subnet Upgrade[​](#subnet-upgrade "Direct link to heading") +Avalanche L1 Upgrade[​](#avalanche-l1-upgrade "Direct link to heading") ----------------------------------------------------------- -The `blockchain upgrade` command suite provides a collection of tools for updating your developmental and deployed Subnets. +The `blockchain upgrade` command suite provides a collection of tools for updating your developmental and deployed Avalanche L1s. -### Subnet Upgrade Apply[​](#subnet-upgrade-apply "Direct link to heading") +### Avalanche L1 Upgrade Apply[​](#avalanche-l1-upgrade-apply "Direct link to heading") -Apply generated upgrade bytes to running Subnet nodes to trigger a network upgrade. +Apply generated upgrade bytes to running Avalanche L1 nodes to trigger a network upgrade. For public networks (Fuji Testnet or Mainnet), to complete this process, you must have access to the machine running your validator. If the CLI is running on the same machine as your validator, it can manipulate your node's configuration automatically. Alternatively, the command can print the necessary instructions to upgrade your node manually. -After you update your validator's configuration, you need to restart your validator manually. If you provide the `--avalanchego-chain-config-dir` flag, this command attempts to write the upgrade file at that path. Refer to [this doc](/nodes/configure/configs-flags#subnet-chain-configs) for related documentation. +After you update your validator's configuration, you need to restart your validator manually. If you provide the `--avalanchego-chain-config-dir` flag, this command attempts to write the upgrade file at that path. Refer to [this doc](/nodes/configure/configs-flags#avalanche-l1-chain-configs) for related documentation. **Usage**: ```bash -avalanche blockchain upgrade apply [subnetName] [flags] +avalanche blockchain upgrade apply [blockchainName] [flags] ``` **Flags**: ```bash --avalanchego-chain-config-dir string avalanchego's chain config file directory (default "/Users/connor/.avalanchego/chains") - --config create upgrade config for future subnet deployments (same as generate) + --config create upgrade config for future Avalanche L1 deployments (same as generate) --force If true, don't prompt for confirmation of timestamps in the past --fuji fuji apply upgrade existing fuji deployment (alias for `testnet`) -h, --help help for apply @@ -567,14 +567,14 @@ avalanche blockchain upgrade apply [subnetName] [flags] --testnet testnet apply upgrade existing testnet deployment (alias for `fuji`) ``` -### Subnet Upgrade Export[​](#subnet-upgrade-export "Direct link to heading") +### Avalanche L1 Upgrade Export[​](#avalanche-l1-upgrade-export "Direct link to heading") Export the upgrade bytes file to a location of choice on disk. **Usage**: ```bash -avalanche blockchain upgrade export [subnetName] [flags] +avalanche blockchain upgrade export [blockchainName] [flags] ``` **Flags**: @@ -585,14 +585,14 @@ avalanche blockchain upgrade export [subnetName] [flags] --upgrade-filepath string Export upgrade bytes file to location of choice on disk ``` -### Subnet Upgrade Generate[​](#subnet-upgrade-generate "Direct link to heading") +### Avalanche L1 Upgrade Generate[​](#avalanche-l1-upgrade-generate "Direct link to heading") -The `blockchain upgrade generate` command builds a new upgrade.json file to customize your Subnet. It guides the user through the process using an interactive wizard. +The `blockchain upgrade generate` command builds a new upgrade.json file to customize your Avalanche L1. It guides the user through the process using an interactive wizard. **Usage**: ```bash -avalanche blockchain upgrade generate [subnetName] [flags] +avalanche blockchain upgrade generate [blockchainName] [flags] ``` **Flags**: @@ -601,14 +601,14 @@ avalanche blockchain upgrade generate [subnetName] [flags] -h, --help help for generate ``` -### Subnet Upgrade Import[​](#subnet-upgrade-import "Direct link to heading") +### Avalanche L1 Upgrade Import[​](#avalanche-l1-upgrade-import "Direct link to heading") Import the upgrade bytes file into the local environment. **Usage**: ```bash -avalanche blockchain upgrade import [subnetName] [flags] +avalanche blockchain upgrade import [blockchainName] [flags] ``` **Flags**: @@ -618,14 +618,14 @@ avalanche blockchain upgrade import [subnetName] [flags] --upgrade-filepath string Import upgrade bytes file into local environment ``` -### Subnet Upgrade Print[​](#subnet-upgrade-print "Direct link to heading") +### Avalanche L1 Upgrade Print[​](#avalanche-l1-upgrade-print "Direct link to heading") Print the upgrade.json file content. **Usage**: ```bash -avalanche blockchain upgrade print [subnetName] [flags] +avalanche blockchain upgrade print [blockchainName] [flags] ``` **Flags**: @@ -634,16 +634,16 @@ avalanche blockchain upgrade print [subnetName] [flags] -h, --help help for list ``` -### Subnet Upgrade VM[​](#subnet-upgrade-vm "Direct link to heading") +### Avalanche L1 Upgrade VM[​](#avalanche-l1-upgrade-vm "Direct link to heading") -The `blockchain upgrade vm` command enables the user to upgrade their Subnet's VM binary. The command can upgrade both local Subnets and publicly deployed Subnets on Fuji and Mainnet. +The `blockchain upgrade vm` command enables the user to upgrade their Avalanche L1's VM binary. The command can upgrade both local Avalanche L1s and publicly deployed Avalanche L1s on Fuji and Mainnet. The command walks the user through an interactive wizard. The user can skip the wizard by providing command line flags. **Usage**: ```bash -avalanche blockchain upgrade export [subnetName] [flags] +avalanche blockchain upgrade export [blockchainName] [flags] ``` **Flags**: @@ -658,7 +658,7 @@ Node[​](#node "Direct link to heading") The `node` command suite provides a collection of tools for creating and maintaining validators on the Avalanche Network. -To get started, use the node create command wizard to walk through the configuration to make your node a primary validator on Avalanche public network. You can use the rest of the commands to maintain your node and make your node a Subnet Validator. +To get started, use the node create command wizard to walk through the configuration to make your node a primary validator on Avalanche public network. You can use the rest of the commands to maintain your node and make your node an Avalanche L1 Validator. ### Node Create[​](#node-create "Direct link to heading") @@ -666,7 +666,7 @@ To get started, use the node create command wizard to walk through the configura (ALPHA Warning) This command is currently in experimental mode. -The `node create` command sets up a validator on a cloud server of your choice. The validator will be validating the Avalanche Primary Network and Subnet of your choice. By default, the command runs an interactive wizard. It walks you through all the steps you need to set up a validator. Validators can be deployed in multiple regions/zones simultaneously. Once this command is run, you will have to wait for the validator to finish bootstrapping on the primary network before running further commands on it, for example validating a Subnet. You can check the bootstrapping status by running `avalanche node status`. +The `node create` command sets up a validator on a cloud server of your choice. The validator will be validating the Avalanche Primary Network and Avalanche L1 of your choice. By default, the command runs an interactive wizard. It walks you through all the steps you need to set up a validator. Validators can be deployed in multiple regions/zones simultaneously. Once this command is run, you will have to wait for the validator to finish bootstrapping on the primary network before running further commands on it, for example validating an Avalanche L1. You can check the bootstrapping status by running `avalanche node status`. The created node will be part of group of validators called `` and users can call node commands with `` so that the command will apply to all nodes in the cluster. @@ -681,7 +681,7 @@ avalanche node create [clusterName] [flags] ```bash --alternative-key-pair-name string key pair name to use if default one generates conflicts --authorize-access authorize CLI to create cloud resources - --avalanchego-version-from-subnet string install latest avalanchego version, that is compatible with the given subnet, on node/s + --avalanchego-version-from-subnet string install latest avalanchego version, that is compatible with the given Avalanche L1, on node/s --aws create node/s in AWS cloud --aws-profile string aws profile to use (default "default") --custom-avalanchego-version string install given avalanchego version on node/s @@ -715,12 +715,12 @@ The `node devnet` command suite provides a collection of commands related to dev ### Node Devnet Deploy[​](#node-devnet-deploy "Direct link to heading") -The `node devnet deploy` command deploys a Subnet into a devnet cluster, creating Subnet and blockchain TXs for it. It saves the deploy info both locally and remotely. +The `node devnet deploy` command deploys an Avalanche L1 into a devnet cluster, creating Avalanche L1 and blockchain TXs for it. It saves the deploy info both locally and remotely. **Usage**: ```bash -avalanche node devnet deploy [clusterName] [subnetName] [flags] +avalanche node devnet deploy [clusterName] [Avalanche L1 Name] [flags] ``` **Flags**: @@ -731,12 +731,12 @@ avalanche node devnet deploy [clusterName] [subnetName] [flags] ### Node Devnet Wiz[​](#node-devnet-wiz "Direct link to heading") -The `node devnet wiz` command creates a devnet and deploys, sync and validate a Subnet into it. It creates the Subnet if so needed. +The `node devnet wiz` command creates a devnet and deploys, sync and validate an Avalanche L1 into it. It creates the Avalanche L1 if so needed. **Usage**: ```bash -avalanche node devnet wiz [clusterName] [subnetName] [flags] +avalanche node devnet wiz [clusterName] [blockchainName] [flags] ``` **Flags**: @@ -747,19 +747,19 @@ avalanche node devnet wiz [clusterName] [subnetName] [flags] --avalanchego-version string install given avalanchego version on node/s --aws create node/s in AWS cloud --aws-profile string aws profile to use (default "default") - --chain-config string path to the chain configuration for subnet - --custom-subnet use a custom VM as the subnet virtual machine + --chain-config string path to the chain configuration for Avalanche L1 + --custom-subnet use a custom VM as the Avalanche L1 virtual machine --custom-vm-branch string custom vm branch --custom-vm-build-script string custom vm build-script --custom-vm-repo-url string custom vm repository url - --default-validator-params use default weight/start/duration params for subnet validator + --default-validator-params use default weight/start/duration params for Avalanche L1 validator --devnet-api-nodes int number of API nodes(nodes without stake) to create in the new Devnet --evm-chain-id uint chain ID to use with Subnet-EVM --evm-defaults use default settings for fees/airdrop/precompiles with Subnet-EVM - --evm-subnet use Subnet-EVM as the subnet virtual machine + --evm-subnet use Subnet-EVM as the Avalanche L1 virtual machine --evm-token string token name to use with Subnet-EVM --evm-version string version of Subnet-EVM to use - --force-subnet-create overwrite the existing subnet configuration if one exists + --force-subnet-create overwrite the existing Avalanche L1 configuration if one exists --gcp create node/s in GCP cloud --gcp-credentials string use given GCP credentials --gcp-project string use given GCP project @@ -768,7 +768,7 @@ avalanche node devnet wiz [clusterName] [subnetName] [flags] --latest-avalanchego-version install latest avalanchego release version on node/s --latest-evm-version use latest Subnet-EVM released version --latest-pre-released-evm-version use latest Subnet-EVM pre-released version - --node-config string path to avalanchego node configuration for subnet + --node-config string path to avalanchego node configuration for Avalanche L1 --node-type string cloud instance type. Use 'default' to use recommended default instance type --num-nodes ints number of nodes to create per region(s). Use comma to separate multiple numbers for each region in the same order as --region flag --region strings create node/s in given region(s). Use comma to separate multiple regions @@ -776,11 +776,11 @@ avalanche node devnet wiz [clusterName] [subnetName] [flags] --separate-monitoring-instance host monitoring for all cloud servers on a separate instance --skip-monitoring don't set up monitoring in created nodes --ssh-agent-identity string use given ssh identity(only for ssh agent). If not set, default will be used. - --subnet-config string path to the subnet configuration for subnet + --subnet-config string path to the subnet configuration for Avalanche L1 --subnet-genesis string file path of the subnet genesis --use-ssh-agent use ssh agent for ssh --use-static-ip attach static Public IP on cloud servers (default true) - --validators strings deploy subnet into given comma separated list of validators. defaults to all cluster nodes + --validators strings deploy blockchain into given comma separated list of validators. defaults to all cluster nodes ``` ### Node List[​](#node-list "Direct link to heading") @@ -831,7 +831,7 @@ avalanche node ssh [clusterName] [flags] The `node status` command gets the bootstrap status of all nodes in a cluster with the Primary Network. If no cluster is given, defaults to node list behaviour. -To get the bootstrap status of a node with a Subnet, use the `--subnet` flag. +To get the bootstrap status of a node with an Avalanche L1, use the `--subnet` flag. **Usage**: @@ -843,7 +843,7 @@ avalanche node status [clusterName] [flags] ```bash -h, --help help for status - --subnet string specify the subnet the node is syncing with + --subnet string specify the Avalanche L1 the node is syncing with ``` ### Node Stop[​](#node-stop "Direct link to heading") @@ -874,12 +874,12 @@ avalanche node stop [clusterName] [flags] (ALPHA Warning) This command is currently in experimental mode. -The `node sync` command enables all nodes in a cluster to be bootstrapped to a Subnet. You can check the Subnet bootstrap status by calling avalanche `node status --subnet ` +The `node sync` command enables all nodes in a cluster to be bootstrapped to an Avalanche L1. You can check the Avalanche L1 bootstrap status by calling avalanche `node status --subnet ` **Usage**: ```bash -avalanche node sync [clusterName] [subnetName] [flags] +avalanche node sync [clusterName] [blockchainName] [flags] ``` **Flags**: @@ -896,24 +896,24 @@ avalanche node sync [clusterName] [subnetName] [flags] The `node update` command suite provides a collection of commands for nodes to update their AvalancheGo version or VM version/config. You can check the status after update by calling `avalanche node status` -#### Node Update Subnet[​](#node-update-subnet "Direct link to heading") +#### Node Update Avalanche L1[​](#node-update-avalanche-l1 "Direct link to heading") (ALPHA Warning) This command is currently in experimental mode. -The `node update subnet` command updates all nodes in a cluster with latest Subnet configuration and You can check the updated Subnet bootstrap status by calling avalanche `node status --subnet ` +The `node update subnet` command updates all nodes in a cluster with latest Avalanche L1 configuration and You can check the updated Avalanche L1 bootstrap status by calling avalanche `node status --subnet ` **Usage**: ```bash -avalanche node update subnet [clusterName] [subnetName] [flags] +avalanche node update Avalanche L1 [clusterName] [blockchainName] [flags] ``` **Flags**: ```bash --h, --help help for subnet +-h, --help help for Avalanche L1 ``` ### Node Validate[​](#node-validate "Direct link to heading") @@ -922,7 +922,7 @@ avalanche node update subnet [clusterName] [subnetName] [flags] (ALPHA Warning) This command is currently in experimental mode. -The `node validate` command suite provides a collection of commands for nodes to join the Primary Network and Subnets as validators. If any of the commands is run before the nodes are bootstrapped on the Primary Network, the command will fail. You can check the bootstrap status by calling `avalanche node status `. +The `node validate` command suite provides a collection of commands for nodes to join the Primary Network and Avalanche L1s as validators. If any of the commands is run before the nodes are bootstrapped on the Primary Network, the command will fail. You can check the bootstrap status by calling `avalanche node status `. #### Node Validate Primary[​](#node-validate-primary "Direct link to heading") @@ -952,29 +952,29 @@ avalanche node validate primary [clusterName] [flags] -t, --testnet fuji set up validator in testnet (alias to fuji) ``` -#### Node Validate Subnet[​](#node-validate-subnet "Direct link to heading") +#### Node Validate Avalanche L1[​](#node-validate-avalanche-l1 "Direct link to heading") (ALPHA Warning) This command is currently in experimental mode. -The `node validate subnet` command enables all nodes in a cluster to be validators of a Subnet. If the command is run before the nodes are Primary Network validators, the command will first make the nodes Primary Network validators before making them Subnet validators. If The command is run before the nodes are bootstrapped on the Primary Network, the command will fail. You can check the bootstrap status by calling `avalanche node status `. If The command is run before the nodes are synced to the Subnet, the command will fail. You can check the Subnet sync status by calling `avalanche node status --subnet `. +The `node validate subnet` command enables all nodes in a cluster to be validators of an Avalanche L1. If the command is run before the nodes are Primary Network validators, the command will first make the nodes Primary Network validators before making them Avalanche L1 validators. If the command is run before the nodes are bootstrapped on the Primary Network, the command will fail. You can check the bootstrap status by calling `avalanche node status `. If the command is run before the nodes are synced to the Avalanche L1, the command will fail. You can check the Avalanche L1 sync status by calling `avalanche node status --subnet `. **Usage**: ```bash -avalanche node validate subnet [clusterName] [subnetName] [flags] +avalanche node validate Avalanche L1 [clusterName] [blockchainName] [flags] ``` **Flags**: ```bash - --default-validator-params use default weight/start/duration params for subnet validator + --default-validator-params use default weight/start/duration params for Avalanche L1 validator -d, --devnet set up validator in devnet --endpoint string use the given endpoint for network operations -e, --ewoq use ewoq key [fuji/devnet only] -f, --fuji testnet set up validator in fuji (alias to testnet --h, --help help for subnet +-h, --help help for Avalanche L1 -k, --key string select the key to use [fuji/devnet only] -g, --ledger use ledger instead of key (always true on mainnet, defaults to false on fuji/devnet) --ledger-addrs strings use the given ledger addresses @@ -1082,15 +1082,15 @@ avalanche node resize [clusterName] [flags] Network[​](#network "Direct link to heading") --------------------------------------------- -The `network` command suite provides a collection of tools for managing local Subnet deployments. +The `network` command suite provides a collection of tools for managing local Avalanche L1 deployments. -When you deploy a Subnet locally, it runs on a local, multi-node Avalanche network. The `blockchain deploy` command starts this network in the background. This command suite allows you to shutdown, restart, and clear that network. +When you deploy an Avalanche L1 locally, it runs on a local, multi-node Avalanche network. The `blockchain deploy` command starts this network in the background. This command suite allows you to shutdown, restart, and clear that network. -This network currently supports multiple, concurrently deployed Subnets. +This network currently supports multiple, concurrently deployed Avalanche L1s. ### Network Clean[​](#network-clean "Direct link to heading") -The `network clean` command shuts down your local, multi-node network. All deployed Subnets shutdown and delete their state. You can restart the network by deploying a new Subnet configuration. +The `network clean` command shuts down your local, multi-node network. All deployed Avalanche L1s shutdown and delete their state. You can restart the network by deploying a new Avalanche L1 configuration. **Usage**: @@ -1146,7 +1146,7 @@ avalanche network status [flags] The `network stop` command shuts down your local, multi-node network. -All deployed Subnets shutdown gracefully and save their state. If you provide the `--snapshot-name` flag, the network saves its state under this named snapshot. You can reload this snapshot with `network start --snapshot-name `. Otherwise, the network saves to the default snapshot, overwriting any existing state. You can reload the default snapshot with `network start`. +All deployed Avalanche L1s shutdown gracefully and save their state. If you provide the `--snapshot-name` flag, the network saves its state under this named snapshot. You can reload this snapshot with `network start --snapshot-name `. Otherwise, the network saves to the default snapshot, overwriting any existing state. You can reload the default snapshot with `network start`. **Usage**: @@ -1173,7 +1173,7 @@ The `transaction commit` command commits a transaction by submitting it to the P **Usage**: ```bash -avalanche transaction commit [subnetName] [flags] +avalanche transaction commit [blockchainName] [flags] ``` **Flags**: @@ -1190,7 +1190,7 @@ The `transaction sign` command signs a multisig transaction. **Usage**: ```bash -avalanche transaction sign [subnetName] [flags] +avalanche transaction sign [blockchainName] [flags] ``` **Flags**: @@ -1206,13 +1206,13 @@ avalanche transaction sign [subnetName] [flags] Key[​](#key "Direct link to heading") ------------------------------------- -The `key` command suite provides a collection of tools for creating and managing signing keys. You can use these keys to deploy Subnets to the Fuji Testnet, but these keys are NOT suitable to use in production environments. DO NOT use these keys on Mainnet. +The `key` command suite provides a collection of tools for creating and managing signing keys. You can use these keys to deploy Avalanche L1s to the Fuji Testnet, but these keys are NOT suitable to use in production environments. DO NOT use these keys on Mainnet. To get started, use the `key create` command. ### Key Create[​](#key-create "Direct link to heading") -The `key create` command generates a new private key to use for creating and controlling test Subnets. Keys generated by this command are NOT cryptographically secure enough to use in production environments. DO NOT use these keys on Mainnet. +The `key create` command generates a new private key to use for creating and controlling test Avalanche L1s. Keys generated by this command are NOT cryptographically secure enough to use in production environments. DO NOT use these keys on Mainnet. The command works by generating a secp256 key and storing it with the provided `keyName`. You can use this key in other commands by providing this `keyName`. @@ -1291,7 +1291,7 @@ avalanche key list [flags] -l, --local list local network addresses -m, --mainnet list mainnet network addresses --pchain list P-Chain addresses (default true) - --subnet string provide balance information for the given subnet (Subnet-Evm based only) + --subnet string provide balance information for the given Avalanche L1 (Subnet-Evm based only) -t, --testnet list testnet (fuji) network addresses -n, --use-nano-avax use nano Avax for balances --xchain list X-Chain addresses (default true) @@ -1326,3 +1326,4 @@ avalanche key transfer [options] [flags] -a, --target-addr string receiver address -t, --testnet transfer between testnet (fuji) addresses ``` + diff --git a/content/docs/nodes/run-a-node/subnet-nodes.mdx b/content/docs/avalanche-l1s/avalanche-l1-nodes.mdx similarity index 73% rename from content/docs/nodes/run-a-node/subnet-nodes.mdx rename to content/docs/avalanche-l1s/avalanche-l1-nodes.mdx index dbaa548f204..dc4cd42b2fc 100644 --- a/content/docs/nodes/run-a-node/subnet-nodes.mdx +++ b/content/docs/avalanche-l1s/avalanche-l1-nodes.mdx @@ -1,11 +1,11 @@ --- -title: Subnet Nodes -description: Learn how to run an Avalanche node that tracks a Subnet. +title: Avalanche L1 Nodes +description: Learn how to run an Avalanche node that tracks an Avalanche L1. --- -This article describes how to run a node that tracks a Subnet. It requires building AvalancheGo, adding Virtual Machine binaries as plugins to your local data directory, and running AvalancheGo to track these binaries. +This article describes how to run a node that tracks an Avalanche L1. It requires building AvalancheGo, adding Virtual Machine binaries as plugins to your local data directory, and running AvalancheGo to track these binaries. -This tutorial specifically covers tracking a Subnet built with Avalanche's [Subnet-EVM](https://github.com/ava-labs/subnet-evm), the default [Virtual Machine](/learn/virtual-machines) run by Subnets on Avalanche. +This tutorial specifically covers tracking an Avalanche L1 built with Avalanche's [Subnet-EVM](https://github.com/ava-labs/subnet-evm), the default [Virtual Machine](/learn/virtual-machines) run by Avalanche L1s on Avalanche. Build AvalancheGo[​](#build-avalanchego "Direct link to heading") ----------------------------------------------------------------- @@ -51,7 +51,7 @@ Note that as network usage increases, hardware requirements may change. -## Manage the Subnet Binaries +## Manage the Avalanche L1 Binaries After building AvalancheGo successfully, @@ -64,7 +64,7 @@ git clone https://github.com/ava-labs/subnet-evm.git ### 2. Build the Binary and Save as a Plugin -In the Subnet-EVM directory, run the build script, and save it in the “plugins” folder of your `.avalanchego` data directory. Name the plugin after the `VMID` of the Subnet you wish to track. The `VMID` of the WAGMI Subnet is the value beginning with “srEX...”. +In the Subnet-EVM directory, run the build script, and save it in the “plugins” folder of your `.avalanchego` data directory. Name the plugin after the `VMID` of the Avalanche L1 you wish to track. The `VMID` of the WAGMI Avalanche L1 is the value beginning with “srEX...”. ```bash cd $GOPATH/src/github.com/ava-labs/subnet-evm @@ -72,8 +72,8 @@ cd $GOPATH/src/github.com/ava-labs/subnet-evm ``` - -VMID, Subnet ID, ChainID, and all other parameters can be found in the "Chain Info" section of the Subnet Explorer. + +VMID, Avalanche L1 ID (SubnetID), ChainID, and all other parameters can be found in the "Chain Info" section of the Avalanche L1 Explorer. - [Avalanche Mainnet](https://subnets.avax.network/c-chain) - [Fuji Testnet](https://subnets-test.avax.network/wagmi) @@ -82,7 +82,7 @@ VMID, Subnet ID, ChainID, and all other parameters can be found in the "Chain In ### 3. Specify the Plugin with a Config.JSON -Create a file named `config.json` and add a `track-subnets` field that is populated with the `SubnetID` you wish to track. The `SubnetID` of the WAGMI Subnet is the value beginning with “28nr...”. +Create a file named `config.json` and add a `track-subnets` field that is populated with the `SubnetID` you wish to track. The `SubnetID` of the WAGMI Avalanche L1 is the value beginning with “28nr...”. ```bash cd ~/.avalanchego @@ -91,18 +91,18 @@ echo '{"track-subnets": "28nrH5T2BMvNrWecFcV3mfccjs6axM1TVyqe79MCv2Mhs8kxiY"}' > ## Run the Node -Run AvalancheGo with the `—config-file` flag to start your node and ensure it tracks the Subnets included in the configuration file. +Run AvalancheGo with the `—config-file` flag to start your node and ensure it tracks the Avalanche L1s included in the configuration file. ```bash cd $GOPATH/src/github.com/ava-labs/avalanchego ./build/avalanchego --config-file ~/.avalanchego/config.json --network-id=fuji ``` -Note: The above command includes the `--network-id=fuji` command because the WAGMI Subnet is deployed on Fuji Testnet. +Note: The above command includes the `--network-id=fuji` command because the WAGMI Avalanche L1 is deployed on Fuji Testnet. -If you would prefer to track Subnets using a command line flag, you can instead use the `--track-subnets` flag. +If you would prefer to track Avalanche L1s using a command line flag, you can instead use the `--track-subnets` flag. For example: @@ -116,7 +116,7 @@ You should now see terminal filled with logs and information to suggest the node ## Bootstrapping and RPC Details -It may take a few hours for the node to fully [bootstrap](/nodes/run-a-node/manually#bootstrapping) to the Avalanche Primary Network and tracked Subnets. +It may take a few hours for the node to fully [bootstrap](/nodes/run-a-node/manually#bootstrapping) to the Avalanche Primary Network and tracked Avalanche L1s. When finished bootstrapping, the endpoint will be: @@ -134,4 +134,4 @@ if run on a cloud provider. The “X”s should be replaced with the public IP o For more information on the requests available at these endpoints, please see the [Subnet-EVM API Reference](/api-reference/subnet-evm-api) documentation. -Because each node is also tracking the Primary Network, those [RPC endpoints](/nodes/run-a-node/manually#rpc) are available as well. \ No newline at end of file +Because each node is also tracking the Primary Network, those [RPC endpoints](/nodes/run-a-node/manually#rpc) are available as well. diff --git a/content/docs/subnets/build-first-subnet.mdx b/content/docs/avalanche-l1s/build-first-avalanche-l1.mdx similarity index 70% rename from content/docs/subnets/build-first-subnet.mdx rename to content/docs/avalanche-l1s/build-first-avalanche-l1.mdx index dc711b4c2d7..637a7be44b1 100644 --- a/content/docs/subnets/build-first-subnet.mdx +++ b/content/docs/avalanche-l1s/build-first-avalanche-l1.mdx @@ -1,9 +1,9 @@ --- -title: Build Your First Subnet -description: This tutorial walks you through the process of using Avalanche-CLI to create a Subnet, deploy it on a local network, and add to Core wallet. +title: Build Your First Avalanche L1 +description: This tutorial walks you through the process of using Avalanche-CLI to create an Avalanche L1, deploy it on a local network, and add to Core wallet. --- -The first step of learning Subnet development is learning to use [Avalanche-CLI](https://github.com/ava-labs/avalanche-cli). +The first step of learning Avalanche L1 development is learning to use [Avalanche-CLI](https://github.com/ava-labs/avalanche-cli). Installation[​](#installation "Direct link to heading") ------------------------------------------------------- @@ -28,14 +28,14 @@ If you add it to your path, you should be able to call the program anywhere with For more detailed installation instructions, see [Avalanche-CLI Installation](/tooling/guides/get-avalanche-cli). -Create Your Subnet Configuration[​](#create-your-subnet-configuration "Direct link to heading") +Create Your Avalanche L1 Configuration[​](#create-your-avalanche-l1-configuration "Direct link to heading") ----------------------------------------------------------------------------------------------- -This tutorials teaches you how to create an Ethereum Virtual Machine (EVM) based Subnet. To do so, you use Subnet-EVM, Avalanche's Subnet fork of the EVM. It supports airdrops, custom fee tokens, configurable gas parameters, and multiple stateful precompiles. To learn more, take a look at [Subnet-EVM](https://github.com/ava-labs/subnet-evm). The goal of your first command is to create a Subnet-EVM configuration. +This tutorials teaches you how to create an Ethereum Virtual Machine (EVM) based Avalanche L1. To do so, you use Subnet-EVM, Avalanche's Avalanche L1 fork of the EVM. It supports airdrops, custom fee tokens, configurable gas parameters, and multiple stateful precompiles. To learn more, take a look at [Subnet-EVM](https://github.com/ava-labs/subnet-evm). The goal of your first command is to create a Subnet-EVM configuration. -The Subnet command suite provides a collection of tools for developing and deploying Subnets. +The Avalanche L1 command suite provides a collection of tools for developing and deploying Avalanche L1s. -The Subnet Creation Wizard walks you through the process of creating your Subnet. To get started, first pick a name for your Subnet. This tutorial uses `myblockchain`, but feel free to substitute that with any name you like. Once you've picked your name, run: +The Avalanche L1 Creation Wizard walks you through the process of creating your Avalanche L1. To get started, first pick a name for your Avalanche L1. This tutorial uses `myblockchain`, but feel free to substitute that with any name you like. Once you've picked your name, run: ```bash avalanche blockchain create myblockchain @@ -47,15 +47,15 @@ The following sections walk through each question in the wizard. Select `SubnetEVM`. -### Enter Your Subnet's ChainID[​](#enter-your-subnets-chainid "Direct link to heading") +### Enter Your Avalanche L1's ChainID[​](#enter-your-avalanche-l1s-chainid "Direct link to heading") Choose a positive integer for your EVM-style ChainID. -In production environments, this ChainID needs to be unique and not shared with any other chain. You can visit [chainlist](https://chainlist.org/) to verify that your selection is unique. Because this is a development Subnet, feel free to pick any number. Stay away from well-known ChainIDs such as 1 (Ethereum) or 43114 (Avalanche C-Chain) as those may cause issues with other tools. +In production environments, this ChainID needs to be unique and not shared with any other chain. You can visit [chainlist](https://chainlist.org/) to verify that your selection is unique. Because this is a development Avalanche L1, feel free to pick any number. Stay away from well-known ChainIDs such as 1 (Ethereum) or 43114 (Avalanche C-Chain) as those may cause issues with other tools. ### Token Symbol[​](#token-symbol "Direct link to heading") -Enter a string to name your Subnet's native token. The token symbol doesn't necessarily need to be unique. Example token symbols are AVAX, JOE, and BTC. +Enter a string to name your Avalanche L1's native token. The token symbol doesn't necessarily need to be unique. Example token symbols are AVAX, JOE, and BTC. ### Subnet-EVM Version[​](#subnet-evm-version "Direct link to heading") @@ -63,7 +63,7 @@ Select `Use latest version`. ### Gas Fee Configuration[​](#gas-fee-configuration "Direct link to heading") -This question determines how to set gas fees on your Subnet. +This question determines how to set gas fees on your Avalanche L1. Select `Low disk use / Low Throughput 1.5 mil gas/s (C-Chain's setting)`. @@ -77,30 +77,30 @@ When you are ready to start more mature testing, select `Customize your airdrop` ### Precompiles[​](#precompiles "Direct link to heading") -Precompiles are Avalanche's way of customizing the behavior of your Subnet. They're strictly an advanced feature, so you can safely select `No` for now. +Precompiles are Avalanche's way of customizing the behavior of your Avalanche L1. They're strictly an advanced feature, so you can safely select `No` for now. ### Wrapping Up[​](#wrapping-up "Direct link to heading") -If all worked successfully, the command prints `Successfully created subnet configuration`. +If all worked successfully, the command prints `Successfully created blockchain configuration`. -You've successfully created your first Subnet configuration. Now it's time to deploy it. +You've successfully created your first Avalanche L1 configuration. Now it's time to deploy it. -Deploying Subnets Locally[​](#deploying-subnets-locally "Direct link to heading") +Deploying Avalanche L1s Locally[​](#deploying-avalanche-l1s-locally "Direct link to heading") --------------------------------------------------------------------------------- -To deploy your Subnet, run: +To deploy your Avalanche L1, run: ```bash avalanche blockchain deploy myblockchain ``` -Make sure to substitute the name of your Subnet if you used a different one than `myblockchain`. +Make sure to substitute the name of your Avalanche L1 if you used a different one than `myblockchain`. Next, select `Local Network`. This command boots a five node Avalanche network on your machine. It needs to download the latest versions of AvalancheGo and Subnet-EVM. The command may take a couple minutes to run. -Note: If you run `bash` on your shell and are running Avalanche-CLI on ARM64 on Mac, you will require Rosetta 2 to be able to deploy Subnets locally. You can download Rosetta 2 using `softwareupdate --install-rosetta` . +Note: If you run `bash` on your shell and are running Avalanche-CLI on ARM64 on Mac, you will require Rosetta 2 to be able to deploy Avalanche L1s locally. You can download Rosetta 2 using `softwareupdate --install-rosetta` . If all works as expected, the command output should look something like this: @@ -143,12 +143,12 @@ Chain ID: 54325 Currency Symbol: TUTORIAL ``` -You can use the deployment details to connect to and interact with your Subnet. Now it's time to interact with it. +You can use the deployment details to connect to and interact with your Avalanche L1. Now it's time to interact with it. -Interacting with Your Subnet[​](#interacting-with-your-subnet "Direct link to heading") +Interacting with Your Avalanche L1[​](#interacting-with-your-avalanche-l1 "Direct link to heading") --------------------------------------------------------------------------------------- -You can use the value provided by `Browser Extension connection details` to connect to your Subnet with Core, MetaMask, or any other wallet. +You can use the value provided by `Browser Extension connection details` to connect to your Avalanche L1 with Core, MetaMask, or any other wallet. To allow API calls from other machines, use `--http-host=0.0.0.0` in the config. @@ -187,32 +187,32 @@ Next, rename the Core account to prevent confusion. On the `Imported` tab, click ![Rename Account](/images/deploy-subnet4.png) -### Connect to the Subnet[​](#connect-to-the-subnet "Direct link to heading") +### Connect to the Avalanche L1[​](#connect-to-the-avalanche-l1 "Direct link to heading") -Next, you need to add your Subnet to Core's networks. +Next, you need to add your Avalanche L1 to Core's networks. In the Core Extension click, `See All Networks` and then select the `+` icon in the top right. ![Add network](/images/deploy-subnet5.png) -Enter your Subnet's details, found in the output of your `avalanche blockchain deploy` [command](#deploying-subnets-locally), into the form and click `Save`. +Enter your Avalanche L1's details, found in the output of your `avalanche blockchain deploy` [command](#deploying-avalanche-l1s-locally), into the form and click `Save`. ![Add network 2](/images/deploy-subnet6.png) -If all worked as expected, your balance should read 1 million tokens. Your Subnet is ready for action. You might want to try to [Deploy a Smart Contract on Your Subnet-EVM Using Remix and Core](/subnets/add-utility/deploy-smart-contract). +If all worked as expected, your balance should read 1 million tokens. Your Avalanche L1 is ready for action. You might want to try to [Deploy a Smart Contract on Your Subnet-EVM Using Remix and Core](/avalanche-l1s/add-utility/deploy-smart-contract). -![Subnet in Core](/images/deploy-subnet7.png) +![Avalanche L1 in Core](/images/deploy-subnet7.png) Next Steps[​](#next-steps "Direct link to heading") --------------------------------------------------- -After you feel comfortable with this deployment flow, try deploying smart contracts on your chain with [Remix](https://remix.ethereum.org/), [Hardhat](https://hardhat.org/), or [Foundry](https://github.com/foundry-rs/foundry). You can also experiment with customizing your Subnet by addingprecompiles or adjusting the airdrop. +After you feel comfortable with this deployment flow, try deploying smart contracts on your chain with [Remix](https://remix.ethereum.org/), [Hardhat](https://hardhat.org/), or [Foundry](https://github.com/foundry-rs/foundry). You can also experiment with customizing your Avalanche L1 by addingprecompiles or adjusting the airdrop. -Once you've developed a stable Subnet you like, see [Create an EVM Subnet on Fuji Testnet](/subnets/deploy-a-subnet/fuji-testnet) to take your Subnet one step closer to production. +Once you've developed a stable Avalanche L1 you like, see [Create an EVM Avalanche L1 on Fuji Testnet](/avalanche-l1s/deploy-a-avalanche-l1/fuji-testnet) to take your Avalanche L1 one step closer to production. FAQ[​](#faq "Direct link to heading") ------------------------------------- -**How is the Subnet ID determined upon creation?** +**How is the Avalanche L1 ID (SubnetID) determined upon creation?** -The Subnet ID is the hash of the transaction that created the Subnet. \ No newline at end of file +The Avalanche L1 ID (SubnetID) is the hash of the transaction that created the Avalanche L1. diff --git a/content/docs/subnets/c-chain-or-subnet.mdx b/content/docs/avalanche-l1s/c-chain-or-avalanche-l1.mdx similarity index 50% rename from content/docs/subnets/c-chain-or-subnet.mdx rename to content/docs/avalanche-l1s/c-chain-or-avalanche-l1.mdx index 3da8b6e765e..00028efd3cc 100644 --- a/content/docs/subnets/c-chain-or-subnet.mdx +++ b/content/docs/avalanche-l1s/c-chain-or-avalanche-l1.mdx @@ -1,26 +1,26 @@ --- -title: C-Chain or Subnet? -description: Learn key concepts to decide when to build on a Subnet vs. C-Chain. +title: C-Chain or Avalanche L1? +description: Learn key concepts to decide when to build on an Avalanche L1 vs. C-Chain. --- -In this article, we discuss often-overlooked differentiating characteristics of Subnets, with a primary focus on EVM-based applications. The goal is to identify the pros and cons of building an app on [C-Chain](/learn/primary-network#c-chain) versus [Subnet-EVM](https://github.com/ava-labs/subnet-evm), and help developers make more informed decisions. +In this article, we discuss often-overlooked differentiating characteristics of Avalanche L1s, with a primary focus on EVM-based applications. The goal is to identify the pros and cons of building an app on [C-Chain](/learn/primary-network#c-chain) versus [Subnet-EVM](https://github.com/ava-labs/subnet-evm), and help developers make more informed decisions. -When to Use a Subnet[​](#when-to-use-a-subnet "Direct link to heading") +When to Use an Avalanche L1[​](#when-to-use-a-avalanche-l1 "Direct link to heading") ----------------------------------------------------------------------- -There are many advantages to running your own Subnet. If you find one or more of these a good match for your project then a Subnet might be a good solution for you. But make sure to check the reasons to use the C-Chain instead, as some trade-offs involved might make that a preferred solution. +There are many advantages to running your own Avalanche L1. If you find one or more of these a good match for your project then an Avalanche L1 might be a good solution for you. But make sure to check the reasons to use the C-Chain instead, as some trade-offs involved might make that a preferred solution. ### We Want Our Own Gas Token[​](#we-want-our-own-gas-token "Direct link to heading") C-Chain is an Ethereum Virtual Machine (EVM) chain; it requires the gas fees to be paid in its native token. That is, the application may create its own utility tokens (ERC-20) on the C-Chain, but the gas must be paid in AVAX. In the meantime, [Subnet-EVM](https://github.com/ava-labs/subnet-evm) effectively creates an application-specific EVM-chain with full control over native(gas) coins. The operator can pre-allocate the native tokens in the chain genesis, and mint more using the [Subnet-EVM](https://github.com/ava-labs/subnet-evm) precompile contract. And these fees can be either burned (as AVAX burns in C-Chain) or configured to be sent to an address which can be a smart contract. -Note that the Subnet gas token is specific to the application in the chain, thus unknown to the external parties. Moving assets to other chains requires trusted bridge contracts (or upcoming cross Subnet communication feature). +Note that the Avalanche L1 gas token is specific to the application in the chain, thus unknown to the external parties. Moving assets to other chains requires trusted bridge contracts (or upcoming cross Avalanche L1 communication feature). ### We Want Higher Throughput[​](#we-want-higher-throughput "Direct link to heading") -The primary goal of the gas limit on C-Chain is to restrict the block size and therefore prevent network saturation. If a block can be arbitrarily large, it takes longer to propagate, potentially degrading the network performance. The C-Chain gas limit acts as a deterrent against any system abuse but can be quite limiting for high throughput applications. Unlike C-Chain, Subnet can be single-tenant, dedicated to the specific application, and thus host its own set of validators with higher bandwidth requirements, which allows for a higher gas limit thus higher transaction throughput. Plus, [Subnet-EVM](https://github.com/ava-labs/subnet-evm) supports fee configuration upgrades that can be adaptive to the surge in application traffic. +The primary goal of the gas limit on C-Chain is to restrict the block size and therefore prevent network saturation. If a block can be arbitrarily large, it takes longer to propagate, potentially degrading the network performance. The C-Chain gas limit acts as a deterrent against any system abuse but can be quite limiting for high throughput applications. Unlike C-Chain, Avalanche L1 can be single-tenant, dedicated to the specific application, and thus host its own set of validators with higher bandwidth requirements, which allows for a higher gas limit thus higher transaction throughput. Plus, [Subnet-EVM](https://github.com/ava-labs/subnet-evm) supports fee configuration upgrades that can be adaptive to the surge in application traffic. -Subnet workloads are isolated from the Primary Network; which means, the noisy neighbor effect of one workload (for example NFT mint on C-Chain) cannot destabilize the Subnet or surge its gas price. This failure isolation model in the Subnet can provide higher application reliability. +Avalanche L1 workloads are isolated from the Primary Network; which means, the noisy neighbor effect of one workload (for example NFT mint on C-Chain) cannot destabilize the Avalanche L1 or surge its gas price. This failure isolation model in the Avalanche L1 can provide higher application reliability. ### We Want Strict Access Control[​](#we-want-strict-access-control "Direct link to heading") @@ -28,36 +28,36 @@ The C-Chain is open and permissionless where anyone can deploy and interact with ### We Need EVM Customization[​](#we-need-evm-customization "Direct link to heading") -If your project is deployed on the C-Chain then your execution environment is dictated by the setup of the C-Chain. Changing any of the execution parameters means that the configuration of the C-Chain would need to change, and that is expensive, complex and difficult to change. So if your project needs some other capabilities, different execution parameters or precompiles that C-Chain does not provide, then Subnets are a solution you need. You can configure the EVM in a Subnet to run however you want, adding precompiles, and setting runtime parameters to whatever your project needs. +If your project is deployed on the C-Chain then your execution environment is dictated by the setup of the C-Chain. Changing any of the execution parameters means that the configuration of the C-Chain would need to change, and that is expensive, complex and difficult to change. So if your project needs some other capabilities, different execution parameters or precompiles that C-Chain does not provide, then Avalanche L1s are a solution you need. You can configure the EVM in an Avalanche L1 to run however you want, adding precompiles, and setting runtime parameters to whatever your project needs. When to Use the C-Chain[​](#when-to-use-the-c-chain "Direct link to heading") ----------------------------------------------------------------------------- -All the reasons for using a Subnet outlined above are very attractive to developers and might make it seem that every new project should look into launching a Subnet instead of using the C-Chain. Of course, things are rarely that simple and without trade-offs. Here are some advantages of the C-Chain that you should take into account. +All the reasons for using an Avalanche L1 outlined above are very attractive to developers and might make it seem that every new project should look into launching an Avalanche L1 instead of using the C-Chain. Of course, things are rarely that simple and without trade-offs. Here are some advantages of the C-Chain that you should take into account. ### We Want High Composability with C-Chain Assets[​](#we-want-high-composability-with-c-chain-assets "Direct link to heading") -C-Chain is a better option for seamless integration with existing C-Chain assets and contracts. It is easier to build a DeFi application on C-Chain, as it provides larger liquidity pools and thus allows for efficient exchange between popular assets. A DeFi Subnet can still support composability of contracts on C-Chain assets but requires some sort of off-chain system via the bridge contract. In other words, a Subnet can be a better choice if the application does not need high composability with the existing C-Chain assets. Plus, the upcoming support for cross Subnet communication will greatly simplify the bridging process. +C-Chain is a better option for seamless integration with existing C-Chain assets and contracts. It is easier to build a DeFi application on C-Chain, as it provides larger liquidity pools and thus allows for efficient exchange between popular assets. A DeFi Avalanche L1 can still support composability of contracts on C-Chain assets but requires some sort of off-chain system via the bridge contract. In other words, an Avalanche L1 can be a better choice if the application does not need high composability with the existing C-Chain assets. Plus, the upcoming support for cross Avalanche L1 communication will greatly simplify the bridging process. ### We Want High Security[​](#we-want-high-security "Direct link to heading") The security of Avalanche Primary Network is a function of the security of the underlying validators and stake delegators. Some choose C-Chain in order to achieve maximum security by utilizing thousands of Avalanche Primary Network validators. Some may choose to not rely on the entire security of the base chain. -The better approach is to scale up the security as the application accrues more values and adoption from its users. And Subnet can provide elastic, on-demand security to take such organic growth into account. +The better approach is to scale up the security as the application accrues more values and adoption from its users. And Avalanche L1 can provide elastic, on-demand security to take such organic growth into account. ### We Want Low Initial Cost[​](#we-want-low-initial-cost "Direct link to heading") -C-Chain has economic advantages of low-cost deployment, whereas each Subnet validator is required to validate the Primary Network by staking AVAX (minimum 2,000 AVAX for Mainnet). For fault tolerance, we recommend at least five validators for a Subnet, even though there is no requirement that the Subnet owner should own all these 5 validators, it still further increases the upfront costs. +C-Chain has economic advantages of low-cost deployment, whereas each Avalanche L1 validator is required to validate the Primary Network by staking AVAX (minimum 2,000 AVAX for Mainnet). For fault tolerance, we recommend at least five validators for an Avalanche L1, even though there is no requirement that the Avalanche L1 owner should own all these 5 validators, it still further increases the upfront costs. ### We Want Low Operational Costs[​](#we-want-low-operational-costs "Direct link to heading") -C-Chain is run and operated by thousands of nodes, it is highly decentralized and reliable, and all the infrastructure (explorers, indexers, exchanges, bridges) has already been built out by dedicated teams that maintain them for you at no extra charge. Project deployed on the C-Chain can leverage all of that basically for free. On the other hand, if you run your own Subnet you are basically in charge of running your own L1 network. You (or someone who you partner with or pay to) will need to do all those things and you will ultimately be responsible for them. If you don't have a desire, resources or partnerships to operate a high-availability 24/7 platform, you're probably better off deploying on the C-Chain. +C-Chain is run and operated by thousands of nodes, it is highly decentralized and reliable, and all the infrastructure (explorers, indexers, exchanges, bridges) has already been built out by dedicated teams that maintain them for you at no extra charge. Project deployed on the C-Chain can leverage all of that basically for free. On the other hand, if you run your own Avalanche L1 you are basically in charge of running your own L1 network. You (or someone who you partner with or pay to) will need to do all those things and you will ultimately be responsible for them. If you don't have a desire, resources or partnerships to operate a high-availability 24/7 platform, you're probably better off deploying on the C-Chain. Conclusion[​](#conclusion "Direct link to heading") --------------------------------------------------- -Here we presented some considerations both in favor of running your own Subnet and in favor of deploying on the C-Chain. You should carefully weigh and consider what makes the most sense for your and your project: deploying on a Subnet or deploying on the C-Chain. +Here we presented some considerations both in favor of running your own Avalanche L1 and in favor of deploying on the C-Chain. You should carefully weigh and consider what makes the most sense for your and your project: deploying on an Avalanche L1 or deploying on the C-Chain. -But, there is also a third way: deploy on C-Chain now, then move to your own Subnet later. If an application has relatively low transaction rate and no special circumstances that would make the C-Chain a non-starter, you can begin with C-Chain deployment to leverage existing technical infrastructure, and later expand to a Subnet. That way you can focus on working on the core of your project and once you have a solid product/market fit and have gained enough traction that the C-Chain is constricting you, plan a move to your own Subnet. +But, there is also a third way: deploy on C-Chain now, then move to your own Avalanche L1 later. If an application has relatively low transaction rate and no special circumstances that would make the C-Chain a non-starter, you can begin with C-Chain deployment to leverage existing technical infrastructure, and later expand to an Avalanche L1. That way you can focus on working on the core of your project and once you have a solid product/market fit and have gained enough traction that the C-Chain is constricting you, plan a move to your own Avalanche L1. -Of course, we're happy to talk to you about your architecture and help you choose the best path forward. Feel free to reach out to us on [Discord](https://chat.avalabs.org/) or other [community channels](https://www.avax.network/community) we run. \ No newline at end of file +Of course, we're happy to talk to you about your architecture and help you choose the best path forward. Feel free to reach out to us on [Discord](https://chat.avalabs.org/) or other [community channels](https://www.avax.network/community) we run. diff --git a/content/docs/subnets/deploy-a-subnet/avalanche-mainnet.mdx b/content/docs/avalanche-l1s/deploy-a-avalanche-l1/avalanche-mainnet.mdx similarity index 75% rename from content/docs/subnets/deploy-a-subnet/avalanche-mainnet.mdx rename to content/docs/avalanche-l1s/deploy-a-avalanche-l1/avalanche-mainnet.mdx index 0f8cfd3ba07..21d2644b6d2 100644 --- a/content/docs/subnets/deploy-a-subnet/avalanche-mainnet.mdx +++ b/content/docs/avalanche-l1s/deploy-a-avalanche-l1/avalanche-mainnet.mdx @@ -1,21 +1,21 @@ --- title: On Avalanche Mainnet -description: Deploy a Subnet to Avalanche Mainnet +description: Deploy an Avalanche L1 to Avalanche Mainnet --- -Deploying a Subnet to Mainnet has many risks. Doing so safely requires a laser focus on security. This tutorial does its best to point out common pitfalls, but there may be other risks not discussed here. +Deploying an Avalanche L1 to Mainnet has many risks. Doing so safely requires a laser focus on security. This tutorial does its best to point out common pitfalls, but there may be other risks not discussed here. This tutorial is an educational resource and provides no guarantees that following it results in a secure deployment. Additionally, this tutorial takes some shortcuts that aid the understanding of the deployment process at the expense of security. The text highlights these shortcuts and they shouldn't be used for a production deployment. -After managing a successful Subnet deployment on the `Fuji Testnet`, you're ready to deploy your Subnet on Mainnet. If you haven't done so, first [Deploy a Subnet on Testnet](/subnets/deploy-a-subnet/fuji-testnet). +After managing a successful Avalanche L1 deployment on the `Fuji Testnet`, you're ready to deploy your Avalanche L1 on Mainnet. If you haven't done so, first [Deploy an Avalanche L1 on Testnet](/avalanche-l1s/deploy-a-avalanche-l1/fuji-testnet). This tutorial shows how to do the following on `Mainnet`. -- Create a Subnet. +- Create an Avalanche L1. - Deploy a virtual machine based on Subnet-EVM. -- Join a node to the newly created Subnet. -- Add a node as a validator to the Subnet. +- Join a node to the newly created Avalanche L1. +- Add a node as a validator to the Avalanche L1. All IDs in this article are for illustration purposes only. They are guaranteed to be different in your own run-through of this tutorial. @@ -23,13 +23,13 @@ All IDs in this article are for illustration purposes only. They are guaranteed ## Prerequisites -- 5+ nodes running and [fully bootstrapped](/nodes/quick-links) on `Mainnet` +- 5+ nodes running and [fully bootstrapped](/nodes) on `Mainnet` - [Avalanche-CLI is installed](/tooling/guides/get-avalanche-cli) on each validator node's box - A [Ledger](https://www.ledger.com/) device -- You've [created a Subnet configuration](/subnets/build-first-subnet#create-your-subnet-configuration) and fully tested a [Fuji Testnet Subnet deployment](/subnets/deploy-a-subnet/fuji-testnet) +- You've [created an Avalanche L1 configuration](/avalanche-l1s/build-first-avalanche-l1#create-your-avalanche-l1-configuration) and fully tested a [Fuji Testnet Avalanche L1 deployment](/avalanche-l1s/deploy-a-avalanche-l1/fuji-testnet) -Although only one validator is strictly required to run a Subnet, running with less than five validators is extremely dangerous and guarantees network downtime. Plan to support at least five validators in your production network. +Although only one validator is strictly required to run an Avalanche L1, running with less than five validators is extremely dangerous and guarantees network downtime. Plan to support at least five validators in your production network. ### Getting Your Mainnet NodeIDs[​](#getting-your-mainnet-nodeids "Direct link to heading") @@ -68,7 +68,7 @@ Avalanche-CLI supports the Ledger `Nano X`, `Nano S`, and `Nano S Plus`. Ledger devices support TX signing for any address inside a sequence automatically generated by the device. -By default, Avalanche-CLI uses the first address of the derivation, and that address needs funds to issue the TXs to create the Subnet and add validators. +By default, Avalanche-CLI uses the first address of the derivation, and that address needs funds to issue the TXs to create the Avalanche L1 and add validators. To get the first `Mainnet` address of your Ledger device, first make sure it is connected, unblocked, and running the Avalanche app. Then execute the `key list` command: @@ -84,7 +84,7 @@ avalanche key list --ledger 0 --mainnet +--------+---------+-------------------------+-----------------------------------------------+---------+---------+ ``` -The command prints the P-Chain address for `Mainnet`, `P-avax1ucykh6ls8thqpuwhg3vp8vvu6spg5e8tp8a25j`, and its balance. You should fund this address with at least 2.5 AVAX to cover TX fees. the TX fee for creating your Subnet costs 2 AVAX. Adding validators costs 0.001 AVAX each. For more details, see [Fees](/api-reference/standards/guides/txn-fees) +The command prints the P-Chain address for `Mainnet`, `P-avax1ucykh6ls8thqpuwhg3vp8vvu6spg5e8tp8a25j`, and its balance. You should fund this address with at least 2.5 AVAX to cover TX fees. the TX fee for creating your Avalanche L1 costs 2 AVAX. Adding validators costs 0.001 AVAX each. For more details, see [Fees](/api-reference/standards/guides/txn-fees) You can use the `key list` command to get any Ledger address in the derivation sequence by changing the index parameter from `0` to the one desired, or to a list of them (for example: `2`, or `0,4,7`). Also, you can ask for addresses on `Fuji` with the `--fuji` parameter, and local networks with the `--local` parameter. @@ -98,13 +98,13 @@ You can load the Ledger's C-Chain address in Core extension, or load in a differ You can move test funds from the C-Chain to the P-Chain by clicking Stake on Core web , then Cross-Chain Transfer (find more details on [this tutorial](https://support.avax.network/en/articles/8133713-core-web-how-do-i-make-cross-chain-transfers-in-core-stake)). -Deploy the Subnet[​](#deploy-the-subnet "Direct link to heading") +Deploy the Avalanche L1[​](#deploy-the-avalanche-l1 "Direct link to heading") ----------------------------------------------------------------- With your Ledger unlocked and running the Avalanche app, run ```bash -avalanche blockchain deploy testsubnet +avalanche blockchain deploy testblockchain ``` This is going to start a new prompt series. @@ -121,7 +121,7 @@ This tutorial is about deploying to `Mainnet`, so navigate with the arrow keys t ```bash ✔ Mainnet -Deploying [testsubnet] to Mainnet +Deploying [testblockchain] to Mainnet ``` After that, CLI shows the `Mainnet` Ledger address used to fund the deployment: @@ -132,35 +132,35 @@ Ledger address: P-avax1ucykh6ls8thqpuwhg3vp8vvu6spg5e8tp8a25j The deployment requires running a `createSubnet` transaction and a `createBlockchain` transaction, and so this first Ledger address must have the funds to issue both operations. -This tutorial creates a permissioned Subnet. As such, you must specify which P-Chain addresses can control the Subnet. These addresses are known as `Control Keys`. The CLI can automatically set your Ledger's address as the sole control key or the user may specify a custom list. +This tutorial creates a permissioned Avalanche L1. As such, you must specify which P-Chain addresses can control the Avalanche L1. These addresses are known as `Control Keys`. The CLI can automatically set your Ledger's address as the sole control key or the user may specify a custom list. -In production Subnets, you should always use multiple control keys running in a multisig configuration. This tutorial uses a single control key for illustrative purposes only. +In production Avalanche L1s, you should always use multiple control keys running in a multisig configuration. This tutorial uses a single control key for illustrative purposes only. -For instructions on controlling your Subnet with a multisig, see the [Multisig Deployment Tutorial](/subnets/deploy-a-subnet/multisig-auth). +For instructions on controlling your Avalanche L1 with a multisig, see the [Multisig Deployment Tutorial](/avalanche-l1s/deploy-a-avalanche-l1/multisig-auth). ```bash -Configure which addresses may make changes to the subnet. +Configure which addresses may make changes to the Avalanche L1. These addresses are known as your control keys. You are going to also -set how many control keys are required to make a subnet change (the threshold). +set how many control keys are required to make an Avalanche L1 change (the threshold). Use the arrow keys to navigate: ↓ ↑ → ← ? How would you like to set your control keys?: ▸ Use ledger address Custom list ``` -For this tutorial, opt to use the first Ledger address, so enter at `Use ledger address`. Only this address is going to be able to add or remove validators, or create blockchains on the Subnet. +For this tutorial, opt to use the first Ledger address, so enter at `Use ledger address`. Only this address is going to be able to add or remove validators, or create blockchains on the Avalanche L1. ```bash -Your Subnet's control keys: [P-avax1ucykh6ls8thqpuwhg3vp8vvu6spg5e8tp8a25j] -Your subnet auth keys for chain creation: [P-avax1ucykh6ls8thqpuwhg3vp8vvu6spg5e8tp8a25j] +Your Avalanche L1's control keys: [P-avax1ucykh6ls8thqpuwhg3vp8vvu6spg5e8tp8a25j] +Your Avalanche L1 auth keys for chain creation: [P-avax1ucykh6ls8thqpuwhg3vp8vvu6spg5e8tp8a25j] ``` Next, the CLI generates a TX for creating the SubnetID and asks the user to sign it by using the Ledger. ```bash -*** Please sign subnet creation hash on the ledger device *** +*** Please sign Avalanche L1 creation hash on the ledger device *** ``` This activates a `Please review` window on the Ledger. Navigate to the Ledger's `APPROVE` window by using the Ledger's right button, and then authorize the request by pressing both left and right buttons. @@ -168,26 +168,26 @@ This activates a `Please review` window on the Ledger. Navigate to the Ledger's If the Ledger doesn't have enough funds, the user may see an error message: ```bash -*** Please sign subnet creation hash on the ledger device *** +*** Please sign Avalanche L1 creation hash on the ledger device *** Error: insufficient funds: provided UTXOs need 1000000000 more units of asset "U8iRqJoiJm8xZHAacmvYyZVwqQx6uDNtQeP3CQ6fcgQk3JqnK" ``` If successful, the CLI next asks you to sign a chain creation TX. ```bash -Subnet has been created with ID: 2UUCLbdGqawRDND7kHjwq3zXXMPdiycG2bkyuRzYMnuTSDr6db. Now creating blockchain... +Avalanche L1 has been created with ID: 2UUCLbdGqawRDND7kHjwq3zXXMPdiycG2bkyuRzYMnuTSDr6db. Now creating blockchain... *** Please sign blockchain creation hash on the ledger device *** ``` This activates a `Please review` window on the Ledger. Navigate to the Ledger's `APPROVE` window by using the Ledger's right button, and then authorize the request by pressing both left and right buttons. -After that, CLI creates the blockchain within the Subnet, and a summary window for the deployment appears: +After that, CLI creates the blockchain within the Avalanche L1, and a summary window for the deployment appears: ```bash +--------------------+------------------------------------------------------------------------------------+ | DEPLOYMENT RESULTS | | +--------------------+------------------------------------------------------------------------------------+ -| Chain Name | testsubnet | +| Chain Name | testblockchain | +--------------------+------------------------------------------------------------------------------------+ | Subnet ID | 2UUCLbdGqawRDND7kHjwq3zXXMPdiycG2bkyuRzYMnuTSDr6db | +--------------------+------------------------------------------------------------------------------------+ @@ -201,26 +201,26 @@ After that, CLI creates the blockchain within the Subnet, and a summary window f +--------------------+------------------------------------------------------------------------------------+ ``` -Well done. You have just created your own Subnet running on `Mainnet`. Now it's time to add your validators. +Well done. You have just created your own Avalanche L1 running on `Mainnet`. Now it's time to add your validators. -Request to Join a Subnet as a Validator[​](#request-to-join-a-subnet-as-a-validator "Direct link to heading") +Request to Join an Avalanche L1 as a Validator[​](#request-to-join-a-avalanche-l1-as-a-validator "Direct link to heading") ------------------------------------------------------------------------------------------------------------- -The new Subnet created in the previous steps doesn't have any dedicated validators yet. To request permission to validate a Subnet, the following steps are required: +The new Avalanche L1 created in the previous steps doesn't have any dedicated validators yet. To request permission to validate an Avalanche L1, the following steps are required: -Adding a validator on a Subnet requires that the node is already a validator on the primary network, which means that your node has **fully bootstrapped**. +Adding a validator on an Avalanche L1 requires that the node is already a validator on the primary network, which means that your node has **fully bootstrapped**. See [here](/nodes/validate/node-validator#add-a-validator-with-core-extension) on how to become a validator. -First, request permission to validate by running the `join` command along with the Subnet name: +First, request permission to validate by running the `join` command along with the Avalanche L1 name: ```bash -avalanche blockchain join testsubnet +avalanche blockchain join testblockchain ``` -Note: Running `join` does not guarantee that your node is a validator of the Subnet! The owner of the Subnet must approve your node to be a validator afterwards by calling `addValidator` as described in the next section. +Note: Running `join` does not guarantee that your node is a validator of the Avalanche L1! The owner of the Avalanche L1 must approve your node to be a validator afterwards by calling `addValidator` as described in the next section. ### Select Mainnet[​](#select-mainnet "Direct link to heading") @@ -287,7 +287,7 @@ It's **required to restart the node**. ### Setup Node Manually[​](#setup-node-manually "Direct link to heading") -By choosing "Manual" instead, the tool prints _instructions_. The user is going to have to follow these instructions and apply them to the node. Note that the IDs for the VM and Subnet are different for each Subnet deployment and you shouldn't copy them from this tutorial. +By choosing "Manual" instead, the tool prints _instructions_. The user is going to have to follow these instructions and apply them to the node. Note that the IDs for the VM and Avalanche L1 are different for each Avalanche L1 deployment and you shouldn't copy them from this tutorial. ```bash ✔ Manual @@ -295,7 +295,7 @@ By choosing "Manual" instead, the tool prints _instructions_. The user is going To setup your node, you must do two things: 1. Add your VM binary to your node's plugin directory -2. Update your node config to start validating the subnet +2. Update your node config to start validating the Avalanche L1 To add the VM to your plugin directory, copy or scp from /tmp/tGBrMADESojmu5Et9CpbGCrmVf9fiAJtZM5ZJ3YVDj5JTu2qw @@ -326,24 +326,24 @@ Add a Validator[​](#add-a-validator "Direct link to heading") ------------------------------------------------------------- -If the `join` command isn't successfully completed before `addValidator` is completed, the Subnet could experience degraded performance or even halt. +If the `join` command isn't successfully completed before `addValidator` is completed, the Avalanche L1 could experience degraded performance or even halt. -Now that the node has joined the Subnet, a Subnet control key holder must call `addValidator` to grant the node permission to be a validator in your Subnet. +Now that the node has joined the Avalanche L1, an Avalanche L1 control key holder must call `addValidator` to grant the node permission to be a validator in your Avalanche L1. -To whitelist a node as a recognized validator on the Subnet, run: +To whitelist a node as a recognized validator on the Avalanche L1, run: ```bash -avalanche blockchain addValidator testsubnet +avalanche blockchain addValidator testblockchain ``` You need to repeat this process for every validator you add to the network. -You can run the `addValidator` transactions from the same box that deployed the Subnet. +You can run the `addValidator` transactions from the same box that deployed the Avalanche L1. ### Submit addValidator TX to Mainnet[​](#submit-addvalidator-tx-to-mainnet "Direct link to heading") -First choose `Mainnet` as the network to add the Subnet validator to. +First choose `Mainnet` as the network to add the Avalanche L1 validator to. ```bash Use the arrow keys to navigate: ↓ ↑ → ← @@ -352,10 +352,10 @@ Use the arrow keys to navigate: ↓ ↑ → ← ▸ Mainnet ``` -Because this operation issues a new transaction, the CLI needs the control keys to sign the operation. Because this tutorial only uses one control key in the Subnet, the process looks slightly different if you use multiple controls keys. The address needs to pay a TX fee of 0.001 AVAX. +Because this operation issues a new transaction, the CLI needs the control keys to sign the operation. Because this tutorial only uses one control key in the Avalanche L1, the process looks slightly different if you use multiple controls keys. The address needs to pay a TX fee of 0.001 AVAX. ```bash -Your subnet auth keys for add validator tx creation: [P-avax1ucykh6ls8thqpuwhg3vp8vvu6spg5e8tp8a25j] +Your Avalanche L1 auth keys for add validator tx creation: [P-avax1ucykh6ls8thqpuwhg3vp8vvu6spg5e8tp8a25j] ``` ### Set NodeID[​](#set-nodeid "Direct link to heading") @@ -450,17 +450,17 @@ The CLI shows the Ledger address: Ledger address: P-avax1ucykh6ls8thqpuwhg3vp8vvu6spg5e8tp8a25j ``` -At this point, if the Ledger address isn't the control key for the Subnet, the user receives an error: +At this point, if the Ledger address isn't the control key for the Avalanche L1, the user receives an error: ```bash -Error: wallet doesn't contain subnet auth keys +Error: wallet doesn't contain Avalanche L1 auth keys exit status 1 ``` If the Ledger doesn't have enough funds, the following error message appears: ```bash -*** Please sign subnet creation hash on the ledger device *** +*** Please sign Avalanche L1 creation hash on the ledger device *** Error: insufficient funds: provided UTXOs need 1000000 more units of asset "U8iRqJoiJm8xZHAacmvYyZVwqQx6uDNtQeP3CQ6fcgQk3JqnK" ``` @@ -478,46 +478,46 @@ This might take a couple of seconds. After, it prints: Transaction successful, transaction ID: r3tJ4Wr2CWA8AaticmFrKdKgAs5AhW2wwWTaQHRBZKwJhsXzb ``` -This means the node is now a validator on the given Subnet on `Mainnet`! However, your work isn't complete. You **must** finish the [Request to Join a Subnet as a Validator](#request-to-join-a-subnet-as-a-validator) section otherwise your Subnet risks downtime. +This means the node is now a validator on the given Avalanche L1 on `Mainnet`! However, your work isn't complete. You **must** finish the [Request to Join an Avalanche L1 as a Validator](#request-to-join-a-avalanche-l1-as-a-validator) section otherwise your Avalanche L1 risks downtime. You can get the P-Chain TX id information on [Avalanche Explorer](https://subnets.avax.network/) -Subnet Export[​](#subnet-export "Direct link to heading") +Avalanche L1 Export[​](#avalanche-l1-export "Direct link to heading") --------------------------------------------------------- -Because you need to setup multiple validators on multiple different machines, you need to export your Subnet's configuration and import it on each validator. +Because you need to setup multiple validators on multiple different machines, you need to export your Avalanche L1's configuration and import it on each validator. ```bash -avalanche blockchain export testsubnet -✔ Enter file path to write export data to: /tmp/testsubnet-export.dat +avalanche blockchain export testblockchain +✔ Enter file path to write export data to: /tmp/testblockchain-export.dat ``` The file is in text format and you shouldn't change it. You can use it to import the configuration on a different machine. -Subnet Import[​](#subnet-import "Direct link to heading") +Avalanche L1 Import[​](#avalanche-l1-import "Direct link to heading") --------------------------------------------------------- To import a VM configuration, move the file you exported in the previous section to your desired machine and issue the `import` command with the path to the file. ```bash -avalanche blockchain import /tmp/testsubnet-export.dat -Subnet imported successfully +avalanche blockchain import /tmp/testblockchain-export.dat +Avalanche L1 imported successfully ``` -After this the whole Subnet configuration should be available on the target machine: +After this the whole Avalanche L1 configuration should be available on the target machine: ```bash avalanche blockchain list +---------------+---------------+----------+-----------+----------+ -| SUBNET | CHAIN | CHAIN ID | TYPE | DEPLOYED | +| Avalanche L1 | CHAIN | CHAIN ID | TYPE | DEPLOYED | +---------------+---------------+----------+-----------+----------+ -| testsubnet | testsubnet | 3333 | SubnetEVM | No | +| testblockchain | testblockchain | 3333 | SubnetEVM | No | +---------------+---------------+----------+-----------+----------+ ``` Going Live[​](#going-live "Direct link to heading") --------------------------------------------------- -Once all of your validators have joined the network, you are ready to issue transactions to your Subnet. +Once all of your validators have joined the network, you are ready to issue transactions to your Avalanche L1. -For the safety of your validators, you should setup dedicated API nodes to process transactions, but for test purposes, you can issue transactions directly to one of your validator's RPC interface. \ No newline at end of file +For the safety of your validators, you should setup dedicated API nodes to process transactions, but for test purposes, you can issue transactions directly to one of your validator's RPC interface. diff --git a/content/docs/subnets/deploy-a-subnet/custom-virtual-machine.mdx b/content/docs/avalanche-l1s/deploy-a-avalanche-l1/custom-virtual-machine.mdx similarity index 86% rename from content/docs/subnets/deploy-a-subnet/custom-virtual-machine.mdx rename to content/docs/avalanche-l1s/deploy-a-avalanche-l1/custom-virtual-machine.mdx index 2bc7f6e4f7f..516f0934bf3 100644 --- a/content/docs/subnets/deploy-a-subnet/custom-virtual-machine.mdx +++ b/content/docs/avalanche-l1s/deploy-a-avalanche-l1/custom-virtual-machine.mdx @@ -1,9 +1,9 @@ --- title: With Custom Virtual Machine -description: Learn how to create a Subnet with a custom virtual machine and deploy it locally. +description: Learn how to create an Avalanche L1 with a custom virtual machine and deploy it locally. --- -This tutorial walks through the process of creating a Subnet with a custom virtual machine and deploying it locally. Although the tutorial uses a fork of Subnet-EVM as an example, you can extend its lessons to support any custom VM binary. +This tutorial walks through the process of creating an Avalanche L1 with a custom virtual machine and deploying it locally. Although the tutorial uses a fork of Subnet-EVM as an example, you can extend its lessons to support any custom VM binary. Fork Subnet-EVM[​](#fork-subnet-evm "Direct link to heading") ------------------------------------------------------------- @@ -21,7 +21,7 @@ git clone https://github.com/ava-labs/subnet-evm.git The repository cloning method used is HTTPS, but SSH can be used too: -`git clone [[email protected]](https://docs.avax.network/cdn-cgi/l/email-protection):ava-labs/subnet-evm.git` +`git clone git@github.com:ava-labs/subnet-evm.git` You can find more about SSH and how to use it [here](https://docs.github.com/en/authentication/connecting-to-github-with-ssh/about-ssh). @@ -93,7 +93,7 @@ To start a VM, you need to provide a genesis file. Here is a basic Subnet-EVM ge } ``` -Open a text editor and copy the preceding text into a file called `custom_genesis.json`. For full breakdown of the genesis file, see the [Genesis File](subnets/upgrade/customize-subnet.mdx#genesis). +Open a text editor and copy the preceding text into a file called `custom_genesis.json`. For full breakdown of the genesis file, see the [Genesis File](/avalanche-l1s/upgrade/customize-avalanche-l1#genesis). The `timestamp` field is the Unix timestamp of the genesis block. `0x66321C34` represents @@ -101,10 +101,10 @@ the timestamp 1714560052 which is the time this tutorial was written. You should timestamp when you create your genesis file. -Create the Subnet Configuration[​](#create-the-subnet-configuration "Direct link to heading") +Create the Avalanche L1 Configuration[​](#create-the-avalanche-l1-configuration "Direct link to heading") --------------------------------------------------------------------------------------------- -Now that you have your binary, it's time to create the Subnet configuration. This tutorial uses `myblockchain` as it Subnet name. Invoke the Subnet Creation Wizard with this command: +Now that you have your binary, it's time to create the Avalanche L1 configuration. This tutorial uses `myblockchain` as it Avalanche L1 name. Invoke the Avalanche L1 Creation Wizard with this command: ```bash avalanche blockchain create myblockchain @@ -143,13 +143,13 @@ If all worked successfully, the command prints `Successfully created Subnet conf Now it's time to deploy it. -Deploy the Subnet Locally[​](#deploy-the-subnet-locally "Direct link to heading") +Deploy the Avalanche L1 Locally[​](#deploy-the-avalanche-l1-locally "Direct link to heading") --------------------------------------------------------------------------------- -To deploy your Subnet, run: `avalanche blockchain deploy myblockchain` +To deploy your Avalanche L1, run: `avalanche blockchain deploy myblockchain` -Make sure to substitute the name of your Subnet if you used a different one than `myblockchain`. +Make sure to substitute the name of your Avalanche L1 if you used a different one than `myblockchain`. Next, select `Local Network`: @@ -198,14 +198,14 @@ Browser Extension connection details (any node URL from above works): RPC URL: http://127.0.0.1:9650/ext/bc/z9a7L6XmFYskbaHuuLFCxThByKg4xqsYYbaqT5ke6xVutDQTp/rpc ``` -You can use the `RPC URL` to connect to and interact with your Subnet. +You can use the `RPC URL` to connect to and interact with your Avalanche L1. -Interact with Your Subnet[​](#interact-with-your-subnet "Direct link to heading") +Interact with Your Avalanche L1[​](#interact-with-your-avalanche-l1 "Direct link to heading") --------------------------------------------------------------------------------- ### Check the Version[​](#check-the-version "Direct link to heading") -You can verify that your Subnet has deployed correctly by querying the local node to see what Subnets it's running. You need to use the [`getNodeVersion`](/api-reference/info-api#infogetnodeversion) endpoint. Try running this curl command: +You can verify that your Avalanche L1 has deployed correctly by querying the local node to see what Avalanche L1s it's running. You need to use the [`getNodeVersion`](/api-reference/info-api#infogetnodeversion) endpoint. Try running this curl command: ```bash curl --location --request POST 'http://127.0.0.1:9650/ext/info' \ @@ -277,4 +277,4 @@ Note, this command doesn't work on all custom VMs, only VMs that implement the E Next Steps[​](#next-steps "Direct link to heading") --------------------------------------------------- -You've now unlocked the ability to deploy custom VMs. Go build something cool! \ No newline at end of file +You've now unlocked the ability to deploy custom VMs. Go build something cool! diff --git a/content/docs/subnets/deploy-a-subnet/fuji-testnet.mdx b/content/docs/avalanche-l1s/deploy-a-avalanche-l1/fuji-testnet.mdx similarity index 80% rename from content/docs/subnets/deploy-a-subnet/fuji-testnet.mdx rename to content/docs/avalanche-l1s/deploy-a-avalanche-l1/fuji-testnet.mdx index b49a90466e4..1bbfe9245be 100644 --- a/content/docs/subnets/deploy-a-subnet/fuji-testnet.mdx +++ b/content/docs/avalanche-l1s/deploy-a-avalanche-l1/fuji-testnet.mdx @@ -1,26 +1,26 @@ --- title: On Fuji Testnet -description: Learn how to deploy a Subnet on the Fuji Testnet. +description: Learn how to deploy an Avalanche L1 on the Fuji Testnet. --- -This document describes how to use the new Avalanche-CLI to deploy a Subnet on `Fuji`. +This document describes how to use the new Avalanche-CLI to deploy an Avalanche L1 on `Fuji`. -After trying out a Subnet on a local box by following [this tutorial](/subnets/deploy-a-subnet/local-network), next step is to try it out on `Fuji` Testnet. +After trying out an Avalanche L1 on a local box by following [this tutorial](/avalanche-l1s/deploy-a-avalanche-l1/local-network), next step is to try it out on `Fuji` Testnet. In this article, it's shown how to do the following on `Fuji` Testnet. -- Create a Subnet. +- Create an Avalanche L1. - Deploy a virtual machine based on Subnet-EVM. -- Join a node to the newly created Subnet. -- Add a node as a validator to the Subnet. +- Join a node to the newly created Avalanche L1. +- Add a node as a validator to the Avalanche L1. All IDs in this article are for illustration purposes. They can be different in your own run-through of this tutorial. ## Prerequisites -- 1+ nodes running and fully bootstrapped on `Fuji` Testnet. Check out the section [Nodes](/nodes/quick-links) on how to run a node and become a validator. +- 1+ nodes running and fully bootstrapped on `Fuji` Testnet. Check out the section [Nodes](/nodes) on how to run a node and become a validator. - [`Avalanche-CLI`](https://github.com/ava-labs/avalanche-cli) installed Virtual Machine[​](#virtual-machine "Direct link to heading") @@ -28,7 +28,7 @@ Virtual Machine[​](#virtual-machine "Direct link to heading") Avalanche can run multiple blockchains. Each blockchain is an instance of a [Virtual Machine](/learn/virtual-machines), much like an object in an object-oriented language is an instance of a class. That's, the VM defines the behavior of the blockchain. -[Subnet-EVM](https://github.com/ava-labs/subnet-evm) is the VM that defines the Subnet Contract Chains. Subnet-EVM is a simplified version of [Avalanche C-Chain](https://github.com/ava-labs/coreth). +[Subnet-EVM](https://github.com/ava-labs/subnet-evm) is the VM that defines the Avalanche L1 Contract Chains. Subnet-EVM is a simplified version of [Avalanche C-Chain](https://github.com/ava-labs/coreth). This chain implements the Ethereum Virtual Machine and supports Solidity smart contracts as well as most other Ethereum client features. @@ -66,7 +66,7 @@ The response should look something like: That portion that says, `NodeID-5mb46qkSBj81k9g9e4VFjGGSbaaSLFRzD` is the NodeID, the entire thing. The user is going to need this ID in the later section when calling [addValidator](#add-a-validator). -With more data on `Fuji`, it may take a while to bootstrap `Fuji` Testnet from scratch. You can use [State-Sync](/nodes/configure/chain-configs/c-chain#state-sync-enabled) to shorten the time for bootstrapping. +With more data on `Fuji`, it may take a while to bootstrap `Fuji` Testnet from scratch. You can use [State-Sync](/nodes/chain-configs/c-chain#state-sync-enabled) to shorten the time for bootstrapping. Avalanche-CLI[​](#avalanche-cli "Direct link to heading") @@ -88,7 +88,7 @@ This tutorial focuses on stored key usage and leave ledger operation details for - list -You should only use the private key created for this tutorial for testing operations on `Fuji` or other testnets. Don't use this key on `Mainnet`. CLI is going to store the key on your file system. Whoever gets access to that key is going to have access to all funds secured by that private key. To deploy to `Mainnet`, follow [this tutorial](/subnets/deploy-a-subnet/avalanche-mainnet). +You should only use the private key created for this tutorial for testing operations on `Fuji` or other testnets. Don't use this key on `Mainnet`. CLI is going to store the key on your file system. Whoever gets access to that key is going to have access to all funds secured by that private key. To deploy to `Mainnet`, follow [this tutorial](/avalanche-l1s/deploy-a-avalanche-l1/avalanche-mainnet). Run `create` if you don't have any private key available yet. You can create multiple named keys. Each command requiring a key is going to therefore require the appropriate key name you want to use. @@ -173,18 +173,18 @@ Do these steps only to follow this tutorial for `Fuji` addresses. To access the After following these 3 steps, your test key should now have a balance on the P-Chain on `Fuji` Testnet. -Create an EVM Subnet[​](#create-an-evm-subnet "Direct link to heading") +Create an EVM Avalanche L1[​](#create-an-evm-avalanche-l1 "Direct link to heading") ----------------------------------------------------------------------- -Creating a Subnet with `Avalanche-CLI` for `Fuji` works the same way as with a local network. In fact, the `create` commands only creates a specification of your Subnet on the local file system. Afterwards the Subnet needs to be _deployed_. This allows to reuse configs, by creating the config with the `create` command, then first deploying to a local network and successively to `Fuji` - and eventually to `Mainnet`. +Creating an Avalanche L1 with `Avalanche-CLI` for `Fuji` works the same way as with a local network. In fact, the `create` commands only creates a specification of your Avalanche L1 on the local file system. Afterwards the Avalanche L1 needs to be _deployed_. This allows to reuse configs, by creating the config with the `create` command, then first deploying to a local network and successively to `Fuji` - and eventually to `Mainnet`. -To create an EVM Subnet, run the `blockchain create` command with a name of your choice: +To create an EVM Avalanche L1, run the `blockchain create` command with a name of your choice: ```bash -avalanche blockchain create testsubnet +avalanche blockchain create testblockchain ``` -This is going to start a series of prompts to customize your EVM Subnet to your needs. Most prompts have some validation to reduce issues due to invalid input. The first prompt asks for the type of the virtual machine (see [Virtual Machine](#virtual-machine)). +This is going to start a series of prompts to customize your EVM Avalanche L1 to your needs. Most prompts have some validation to reduce issues due to invalid input. The first prompt asks for the type of the virtual machine (see [Virtual Machine](#virtual-machine)). ```bash Use the arrow keys to navigate: ↓ ↑ → ← @@ -193,23 +193,23 @@ Use the arrow keys to navigate: ↓ ↑ → ← Custom ``` -As you want to create an EVM Subnet, just accept the default `Subnet-EVM`. Next, CLI asks for the ChainID. You should provide your own ID. Check [chainlist.org](https://chainlist.org/) to see if the value you'd like is already in use. +As you want to create an EVM Avalanche L1, just accept the default `Subnet-EVM`. Next, CLI asks for the ChainID. You should provide your own ID. Check [chainlist.org](https://chainlist.org/) to see if the value you'd like is already in use. ```bash ✔ Subnet-EVM -creating subnet testsubnet -Enter your subnet's ChainId. It can be any positive integer. +creating Avalanche L1 test blockchain +Enter your Avalanche L1's ChainId. It can be any positive integer. ChainId: 3333 ``` Now, provide a symbol of your choice for the token of this EVM: ```bash -Select a symbol for your subnet's native token +Select a symbol for your Avalanche L1's native token Token symbol: TST ``` -At this point, CLI prompts the user for the fee structure of the Subnet, so that he can tune the fees to the needs: +At this point, CLI prompts the user for the fee structure of the Avalanche L1, so that he can tune the fees to the needs: ```bash Use the arrow keys to navigate: ↓ ↑ → ← @@ -236,7 +236,7 @@ Use the arrow keys to navigate: ↓ ↑ → ← You can accept the default -again, NOT for production-, or customize your airdrop. In the latter case the wizard would continue. Assume the default here. -The final question is asking for precompiles. Precompiles are powerful customizations of your EVM. Read about them at [precompiles](/subnets/upgrade/customize-subnet#precompiles). +The final question is asking for precompiles. Precompiles are powerful customizations of your EVM. Read about them at [precompiles](/avalanche-l1s/upgrade/customize-avalanche-l1#precompiles). ```bash ✔ Airdrop 1 million tokens to the default address (do not use in production) @@ -256,12 +256,12 @@ Successfully created genesis It's possible to end the process with Ctrl-C at any time. -At this point, CLI creates the specification of the new Subnet on disk, but isn't deployed yet. +At this point, CLI creates the specification of the new Avalanche L1 on disk, but isn't deployed yet. Print the specification to disk by running the `describe` command: ```bash -avalanche blockchain describe testsubnet +avalanche blockchain describe testblockchain _____ _ _ _ | __ \ | | (_) | | | | | ___| |_ __ _ _| |___ @@ -271,7 +271,7 @@ avalanche blockchain describe testsubnet +----------------------------+----------------------------------------------------+ | PARAMETER | VALUE | +----------------------------+----------------------------------------------------+ -| Subnet Name | testsubnet | +| Blockchain Name | testblockchain | +----------------------------+----------------------------------------------------+ | ChainID | 3333 | +----------------------------+----------------------------------------------------+ @@ -342,15 +342,15 @@ avalanche blockchain describe testsubnet No precompiles set ``` -Also you can list the available Subnets: +Also you can list the available Avalanche L1s: ```bash avalanche blockchain list go run main.go subnet list +-------------+-------------+----------+---------------------------------------------------+------------+-----------+ -| SUBNET | CHAIN | CHAIN ID | VM ID | TYPE | FROM REPO | +| Avalanche L1 | CHAIN | CHAIN ID | VM ID | TYPE | FROM REPO | +-------------+-------------+----------+---------------------------------------------------+------------+-----------+ -| testsubnet | testsubnet | 3333 | tGBrM2SXkAdNsqzb3SaFZZWMNdzjjFEUKteheTa4dhUwnfQyu | Subnet-EVM | false | +| testblockchain | testblockchain | 3333 | tGBrM2SXkAdNsqzb3SaFZZWMNdzjjFEUKteheTa4dhUwnfQyu | Subnet-EVM | false | +-------------+-------------+----------+---------------------------------------------------+------------+-----------+ ``` @@ -360,26 +360,26 @@ List deployed information: avalanche blockchain list --deployed go run main.go subnet list --deployed +-------------+-------------+---------------------------------------------------+---------------+-----------------------------------------------------------------+---------+ -| SUBNET | CHAIN | VM ID | LOCAL NETWORK | FUJI (TESTNET) | MAINNET | +| Avalanche L1 | CHAIN | VM ID | LOCAL NETWORK | FUJI (TESTNET) | MAINNET | +-------------+-------------+---------------------------------------------------+---------------+-----------------------------------------------------------------+---------+ -| testsubnet | testsubnet | tGBrM2SXkAdNsqzb3SaFZZWMNdzjjFEUKteheTa4dhUwnfQyu | Yes | SubnetID: XTK7AM2Pw5A4cCtQ3rTugqbeLCU9mVixML3YwwLYUJ4WXN2Kt | No | +| testblockchain | testblockchain | tGBrM2SXkAdNsqzb3SaFZZWMNdzjjFEUKteheTa4dhUwnfQyu | Yes | SubnetID: XTK7AM2Pw5A4cCtQ3rTugqbeLCU9mVixML3YwwLYUJ4WXN2Kt | No | + + + + +-----------------------------------------------------------------+---------+ | | | | | BlockchainID: 5ce2WhnyeMELzg9UtfpCDGNwRa2AzMzRhBWfTqmFuiXPWE4TR | No | +-------------+-------------+---------------------------------------------------+---------------+-----------------------------------------------------------------+---------+ ``` -Deploy the Subnet[​](#deploy-the-subnet "Direct link to heading") +Deploy the Avalanche L1[​](#deploy-the-avalanche-l1 "Direct link to heading") ----------------------------------------------------------------- -To deploy the Subnet, you will need some testnet AVAX on the P-chain. +To deploy the Avalanche L1, you will need some testnet AVAX on the P-chain. -To deploy the new Subnet, run: +To deploy the new Avalanche L1, run: ```bash -avalanche blockchain deploy testsubnet +avalanche blockchain deploy testblockchain ``` This is going to start a new prompt series. @@ -398,17 +398,17 @@ Also, this tutorial assumes that a node is up running, fully bootstrapped on `Fu ```bash ✔ Fuji -Deploying [testsubnet] to Fuji +Deploying [testblockchain] to Fuji Use the arrow keys to navigate: ↓ ↑ → ← ? Which private key should be used to issue the transaction?: test ▸ mytestkey ``` -Subnets are currently permissioned only. Therefore, the process now requires the user to provide _which keys can control the Subnet_. CLI prompts the user to provide one or more **P-Chain addresses**. Only the keys corresponding to these addresses are going to be able to add or remove validators. Make sure to provide **Fuji P-Chain** addresses -`P-Fuji....`\-. +Avalanche L1s are currently permissioned only. Therefore, the process now requires the user to provide _which keys can control the Avalanche L1_. CLI prompts the user to provide one or more **P-Chain addresses**. Only the keys corresponding to these addresses are going to be able to add or remove validators. Make sure to provide **Fuji P-Chain** addresses -`P-Fuji....`\-. ```bash -Configure which addresses may add new validators to the subnet. +Configure which addresses may add new validators to the Avalanche L1. These addresses are known as your control keys. You are going to also set how many control keys are required to add a validator. Use the arrow keys to navigate: ↓ ↑ → ← @@ -444,44 +444,44 @@ If the private key isn't funded or doesn't have enough funds, the error message Error: insufficient funds: provided UTXOs need 100000000 more units of asset "U8iRqJoiJm8xZHAacmvYyZVwqQx6uDNtQeP3CQ6fcgQk3JqnK" ``` -If the private key has funds, but the **control key** is incorrect (not controlled by the private key), the CLI is going to create the Subnet, but _not the blockchain_: +If the private key has funds, but the **control key** is incorrect (not controlled by the private key), the CLI is going to create the Avalanche L1, but _not the blockchain_: ```bash -Subnet has been created with ID: 2EkPnvnDiLgudnf8NjtxaNcVFtdAAnUPvaoNBrc9WG5tNmmfaK. Now creating blockchain... +Avalanche L1 has been created with ID: 2EkPnvnDiLgudnf8NjtxaNcVFtdAAnUPvaoNBrc9WG5tNmmfaK. Now creating blockchain... Error: insufficient authorization ``` Therefore the user needs to provide a control key which he has indeed control of, and then it succeeds. The output (assuming the node is running on `localhost` and the API port set to standard `9650`) is going to look something like this: ```bash -Subnet has been created with ID: 2b175hLJhGdj3CzgXENso9CmwMgejaCQXhMFzBsm8hXbH2MF7H. Now creating blockchain... +Avalanche L1 has been created with ID: 2b175hLJhGdj3CzgXENso9CmwMgejaCQXhMFzBsm8hXbH2MF7H. Now creating blockchain... Endpoint for blockchain "2XDnKyAEr1RhhWpTpMXqrjeejN23vETmDykVzkb4PrU1fQjewh" with VM ID "tGBrMADESojmu5Et9CpbGCrmVf9fiAJtZM5ZJ3YVDj5JTu2qw": http://127.0.0.1:9650/ext/bc/2XDnKyAEr1RhhWpTpMXqrjeejN23vETmDykVzkb4PrU1fQjewh/rpc ``` -Well done. You have just created your own Subnet with your own Subnet-EVM running on `Fuji`. +Well done. You have just created your own Avalanche L1 with your own Subnet-EVM running on `Fuji`. -To get your new Subnet information, visit the [Avalanche Subnet Explorer](https://subnets-test.avax.network/). The search best works by blockchain ID, so in this example, enter `2XDnKyAEr1RhhWpTpMXqrjeejN23vETmDykVzkb4PrU1fQjewh` into the search box and you should see your shiny new blockchain information. +To get your new Avalanche L1 information, visit the [Avalanche L1 Explorer](https://subnets-test.avax.network/). The search best works by blockchain ID, so in this example, enter `2XDnKyAEr1RhhWpTpMXqrjeejN23vETmDykVzkb4PrU1fQjewh` into the search box and you should see your shiny new blockchain information. -Request to Join a Subnet as a Validator[​](#request-to-join-a-subnet-as-a-validator "Direct link to heading") +Request to Join an Avalanche L1 as a Validator[​](#request-to-join-a-avalanche-l1-as-a-validator "Direct link to heading") ------------------------------------------------------------------------------------------------------------- -The new Subnet created in the previous steps doesn't have any dedicated validators yet. To request permission to validate a Subnet, the following steps are required: +The new Avalanche L1 created in the previous steps doesn't have any dedicated validators yet. To request permission to validate an Avalanche L1, the following steps are required: -Before a node can be a validator on a Subnet, the node is required to already be a validator on the primary network, which means that your node has **fully bootstrapped**. +Before a node can be a validator on an Avalanche L1, the node is required to already be a validator on the primary network, which means that your node has **fully bootstrapped**. -If the validator is within 24 hours of expiring on the primary network, it can't be added to the Subnet. +If the validator is within 24 hours of expiring on the primary network, it can't be added to the Avalanche L1. See [here](/nodes/validate/node-validator#add-a-validator-with-core-extension) on how to become a validator. -First, request permission to validate by running the `join` command along with the Subnet name: +First, request permission to validate by running the `join` command along with the Avalanche L1 name: ```bash -avalanche blockchain join testsubnet +avalanche blockchain join testblockchain ``` -Note: Running `join` does not guarantee that your node is a validator of the Subnet! The owner of the Subnet must approve your node to be a validator afterwards by calling `addValidator` as described in the next section. +Note: Running `join` does not guarantee that your node is a validator of the Avalanche L1! The owner of the Avalanche L1 must approve your node to be a validator afterwards by calling `addValidator` as described in the next section. When you call the `join` command, you are first prompted with the network selection: @@ -533,7 +533,7 @@ The config file has been edited. To use it, make sure to start the node with the It's **required to restart the node**. -If choosing "Manual" instead, the tool is going to just print _instructions_. The user is going to have to follow these instructions and apply them to the node. Note that the IDs for the VM and Subnets is going to be different in your case. +If choosing "Manual" instead, the tool is going to just print _instructions_. The user is going to have to follow these instructions and apply them to the node. Note that the IDs for the VM and Avalanche L1s is going to be different in your case. ```bash ✔ Manual @@ -541,7 +541,7 @@ If choosing "Manual" instead, the tool is going to just print _instructions_. Th To setup your node, you must do two things: 1. Add your VM binary to your node's plugin directory -2. Update your node config to start validating the subnet +2. Update your node config to start validating the Avalanche L1 To add the VM to your plugin directory, copy or scp from /tmp/tGBrMADESojmu5Et9CpbGCrmVf9fiAJtZM5ZJ3YVDj5JTu2qw @@ -572,15 +572,15 @@ Add a Validator[​](#add-a-validator "Direct link to heading") ------------------------------------------------------------- -If the `join` command isn't successfully completed before `addValidator` is completed, the Subnet could experience degraded performance or even halt. +If the `join` command isn't successfully completed before `addValidator` is completed, the Avalanche L1 could experience degraded performance or even halt. -Now that the node has joined the Subnet, a Subnet control key holder must call `addValidator` to grant the node permission to be a validator in your Subnet. +Now that the node has joined the Avalanche L1, an Avalanche L1 control key holder must call `addValidator` to grant the node permission to be a validator in your Avalanche L1. -To whitelist a node as a recognized validator on the Subnet, run: +To whitelist a node as a recognized validator on the Avalanche L1, run: ```bash -avalanche blockchain addValidator testsubnet +avalanche blockchain addValidator testblockchain ``` As this operation involves a new transaction, you will need to specify which private key to use: @@ -607,7 +607,7 @@ Now use the **NodeID** of the new validator defined at the beginning of this tut What is the NodeID of the validator you'd like to whitelist?: NodeID-BFa1paAAAAAAAAAAAAAAAAAAAAQGjPhUy ``` -This ID is intentionally modified. The next question requires a bit of thinking. A validator has a weight, which defines how often consensus selects it for decision making. You should think ahead of how many validators you want initially to identify a good value here. The range is 1 to 100, but the minimum for a Subnet without any validators yet is 20. +This ID is intentionally modified. The next question requires a bit of thinking. A validator has a weight, which defines how often consensus selects it for decision making. You should think ahead of how many validators you want initially to identify a good value here. The range is 1 to 100, but the minimum for an Avalanche L1 without any validators yet is 20. Just select 30 for this one: @@ -672,38 +672,38 @@ This might take a couple of seconds, and if successful, it's going to print: Transaction successful, transaction ID :EhZh8PvQyqA9xggxn6EsdemXMnWKyy839NzEJ5DHExTBiXbjV ``` -This means the node is now a validator on the given Subnet on `Fuji`! +This means the node is now a validator on the given Avalanche L1 on `Fuji`! -Subnet Export[​](#subnet-export "Direct link to heading") +Avalanche L1 Export[​](#avalanche-l1-export "Direct link to heading") --------------------------------------------------------- This tool is most useful on the machine where a validator is or is going to be running. In order to allow a VM to run on a different machine, you can export the configuration. Just need to provide a path to where to export the data: ```bash -avalanche blockchain export testsubnet -✔ Enter file path to write export data to: /tmp/testsubnet-export.dat +avalanche blockchain export testblockchain +✔ Enter file path to write export data to: /tmp/testblockchain-export.dat ``` The file is in text format and you shouldn't change it. You can then use it to import the configuration on a different machine. -Subnet Import[​](#subnet-import "Direct link to heading") +Avalanche L1 Import[​](#avalanche-l1-import "Direct link to heading") --------------------------------------------------------- To import a VM specification exported in the previous section, just issue the `import` command with the path to the file after having copied the file over: ```bash -avalanche blockchain import /tmp/testsubnet-export.dat -Subnet imported successfully +avalanche blockchain import /tmp/testblockchain-export.dat +Avalanche L1 imported successfully ``` -After this the whole Subnet configuration should be available on the target machine: +After this the whole Avalanche L1 configuration should be available on the target machine: ```bash avalanche blockchain list +---------------+---------------+----------+-----------+----------+ -| SUBNET | CHAIN | CHAIN ID | TYPE | DEPLOYED | +| Avalanche L1 | CHAIN | CHAIN ID | TYPE | DEPLOYED | +---------------+---------------+----------+-----------+----------+ -| testsubnet | testsubnet | 3333 | SubnetEVM | No | +| testblockchain | testblockchain | 3333 | SubnetEVM | No | +---------------+---------------+----------+-----------+----------+ ``` @@ -712,17 +712,17 @@ Appendix[​](#appendix "Direct link to heading") ### Connect with Core[​](#connect-with-core "Direct link to heading") -To connect Core (or MetaMask) with your blockchain on the new Subnet running on your local computer, you can add a new network on your Core wallet with the following values: +To connect Core (or MetaMask) with your blockchain on the new Avalanche L1 running on your local computer, you can add a new network on your Core wallet with the following values: ```bash -- Network Name: testsubnet +- Network Name: testblockchain - RPC URL: [http://127.0.0.1:9650/ext/bc/2XDnKyAEr1RhhWpTpMXqrjeejN23vETmDykVzkb4PrU1fQjewh/rpc] - Chain ID: 3333 - Symbol: TST ``` -Unless you deploy your Subnet on other nodes, you aren't going to be able to use other nodes, including the public API server `https://api.avax-test.network/`, to connect to Core. +Unless you deploy your Avalanche L1 on other nodes, you aren't going to be able to use other nodes, including the public API server `https://api.avax-test.network/`, to connect to Core. -If you want to open up this node for others to access your Subnet, you should set it up properly with `https//node-ip-address` instead of `http://127.0.0.1:9650`, however, it's out of scope for this tutorial on how to do that. \ No newline at end of file +If you want to open up this node for others to access your Avalanche L1, you should set it up properly with `https//node-ip-address` instead of `http://127.0.0.1:9650`, however, it's out of scope for this tutorial on how to do that. diff --git a/content/docs/subnets/deploy-a-subnet/local-network.mdx b/content/docs/avalanche-l1s/deploy-a-avalanche-l1/local-network.mdx similarity index 76% rename from content/docs/subnets/deploy-a-subnet/local-network.mdx rename to content/docs/avalanche-l1s/deploy-a-avalanche-l1/local-network.mdx index f93fc9866ac..adb9dfcae40 100644 --- a/content/docs/subnets/deploy-a-subnet/local-network.mdx +++ b/content/docs/avalanche-l1s/deploy-a-avalanche-l1/local-network.mdx @@ -1,18 +1,18 @@ --- title: On a Local Network -description: This guide focuses on taking an already created Subnet configuration and deploying it on a local Avalanche network. +description: This guide focuses on taking an already created Avalanche L1 configuration and deploying it on a local Avalanche network. --- ## Prerequisites * [Avalanche-CLI installed](/tooling/guides/get-avalanche-cli) -* You have [created a Subnet configuration](/subnets/build-first-subnet#create-your-subnet-configuration) +* You have [created an Avalanche L1 configuration](/avalanche-l1s/build-first-avalanche-l1#create-your-avalanche-l1-configuration) -## Deploying Subnets Locally +## Deploying Avalanche L1s Locally -In the following commands, make sure to substitute the name of your Subnet configuration for ``. +In the following commands, make sure to substitute the name of your Avalanche L1 configuration for ``. -To deploy your Subnet, run +To deploy your Avalanche L1, run ```bash avalanche blockchain deploy @@ -27,7 +27,7 @@ avalanche blockchain deploy --local The command may take a couple minutes to run. -If you run `bash` on your shell and are running Avalanche-CLI on ARM64 on Mac, you will require Rosetta 2 to be able to deploy Subnets locally. You can download Rosetta 2 using `softwareupdate --install-rosetta` . +If you run `bash` on your shell and are running Avalanche-CLI on ARM64 on Mac, you will require Rosetta 2 to be able to deploy Avalanche L1s locally. You can download Rosetta 2 using `softwareupdate --install-rosetta` . ### Results @@ -72,20 +72,21 @@ Chain ID: 54325 Currency Symbol: TUTORIAL ``` -You can use the deployment details to connect to and interact with your Subnet. +You can use the deployment details to connect to and interact with your Avalanche L1. To manage the newly deployed local Avalanche network, see [the `avalanche network` command tree](/tooling/avalanche-cli#network). -### Deploying Multiple Subnets +### Deploying Multiple Avalanche L1s -You may deploy multiple Subnets concurrently, but you can't deploy the same Subnet multiple times without resetting all deployed Subnet state. +You may deploy multiple Avalanche L1s concurrently, but you can't deploy the same Avalanche L1 multiple times without resetting all deployed Avalanche L1 state. -### Redeploying the Subnet +### Redeploying the Avalanche L1 -To redeploy the Subnet, you first need to wipe the Subnet state. This permanently deletes all data from all locally deployed Subnets. To do so, run: ```avalanche network clean``` +To redeploy the Avalanche L1, you first need to wipe the Avalanche L1 state. This permanently deletes all data from all locally deployed Avalanche L1s. To do so, run: ```avalanche network clean``` -You are now free to redeploy your Subnet with: +You are now free to redeploy your Avalanche L1 with: ```bash avalanche blockchain deploy --local ``` + diff --git a/content/docs/subnets/deploy-a-subnet/multisig-auth.mdx b/content/docs/avalanche-l1s/deploy-a-avalanche-l1/multisig-auth.mdx similarity index 71% rename from content/docs/subnets/deploy-a-subnet/multisig-auth.mdx rename to content/docs/avalanche-l1s/deploy-a-avalanche-l1/multisig-auth.mdx index d5192171a54..f5acc85d721 100644 --- a/content/docs/subnets/deploy-a-subnet/multisig-auth.mdx +++ b/content/docs/avalanche-l1s/deploy-a-avalanche-l1/multisig-auth.mdx @@ -1,9 +1,9 @@ --- title: With Multisig Authorization -description: Learn how to create a Subnet with a multisig authorization. +description: Learn how to create an Avalanche L1 with a multisig authorization. --- -Subnet creators can control critical Subnet operations with a N of M multisig. This multisig must be setup at deployment time and can't be edited afterward. Multisigs can are available on both the Fuji Testnet and Mainnet. +Avalanche L1 creators can control critical Avalanche L1 operations with a N of M multisig. This multisig must be setup at deployment time and can't be edited afterward. Multisigs can are available on both the Fuji Testnet and Mainnet. To setup your multisig, you need to know the P-Chain address of each key holder and what you want your signing threshold to be. @@ -14,21 +14,21 @@ Avalanche-CLI requires Ledgers for Mainnet deployments. This how-to guide assume ## Prerequisites - [`Avalanche-CLI`](https://github.com/ava-labs/avalanche-cli) installed -- Familiarity with process of [Deploying a Subnet on Testnet](/subnets/deploy-a-subnet/fuji-testnet) and [Deploying a Permissioned Subnet on Mainnet](/subnets/deploy-a-subnet/avalanche-mainnet) -- Multiple Ledger devices [configured for Avalanche](/subnets/deploy-a-subnet/avalanche-mainnet#setting-up-your-ledger) -- A Subnet configuration ready to deploy to either Fuji Testnet or Mainnet +- Familiarity with process of [Deploying an Avalanche L1 on Testnet](/avalanche-l1s/deploy-a-avalanche-l1/fuji-testnet) and [Deploying a Permissioned Avalanche L1 on Mainnet](/avalanche-l1s/deploy-a-avalanche-l1/avalanche-mainnet) +- Multiple Ledger devices [configured for Avalanche](/avalanche-l1s/deploy-a-avalanche-l1/avalanche-mainnet#setting-up-your-ledger) +- an Avalanche L1 configuration ready to deploy to either Fuji Testnet or Mainnet Getting Started[​](#getting-started "Direct link to heading") ------------------------------------------------------------- -When issuing the transactions to create the Subnet, you need to sign the TXs with multiple keys from the multisig. +When issuing the transactions to create the Avalanche L1, you need to sign the TXs with multiple keys from the multisig. ### Specify Network[​](#specify-network "Direct link to heading") -Start the Subnet deployment with +Start the Avalanche L1 deployment with ```bash -avalanche blockchain deploy testsubnet +avalanche blockchain deploy testAvalanche L1 ``` First step is to specify `Fuji` or `Mainnet` as the network: @@ -42,7 +42,7 @@ Use the arrow keys to navigate: ↓ ↑ → ← ``` ```bash -Deploying [testsubnet] to Mainnet +Deploying [testblockchain] to Mainnet ``` Ledger is automatically recognized as the signature mechanism on `Mainnet`. @@ -58,9 +58,9 @@ Ledger address: P-avax1kdzq569g2c9urm9887cmldlsa3w3jhxe0knfy5 Next the CLI asks the user to specify the control keys. This is where you setup your multisig. ```bash -Configure which addresses may make changes to the subnet. +Configure which addresses may make changes to the Avalanche L1. These addresses are known as your control keys. You are going to also -set how many control keys are required to make a subnet change (the threshold). +set how many control keys are required to make an Avalanche L1 change (the threshold). Use the arrow keys to navigate: ↓ ↑ → ← ? How would you like to set your control keys?: ▸ Use ledger address @@ -96,14 +96,14 @@ Enter P-Chain address (Example: P-...): P-avax1g7nkguzg8yju8cq3ndzc9lql2yg69s9ej ✔ Add Enter P-Chain address (Example: P-...): P-avax1g4eryh40dtcsltmxn9zk925ny07gdq2xyjtf4g ✔ Done -Your Subnet's control keys: [P-avax1wryu62weky9qjlp40cpmnqf6ml2hytnagj5q28 P-avax1kdzq569g2c9urm9887cmldlsa3w3jhxe0knfy5 P-avax12gcy0xl0al6gcjrt0395xqlcuq078ml93wl5h8 P-avax1g7nkguzg8yju8cq3ndzc9lql2yg69s9ejqa2af P-avax1g4eryh40dtcsltmxn9zk925ny07gdq2xyjtf4g] +Your Avalanche L1's control keys: [P-avax1wryu62weky9qjlp40cpmnqf6ml2hytnagj5q28 P-avax1kdzq569g2c9urm9887cmldlsa3w3jhxe0knfy5 P-avax12gcy0xl0al6gcjrt0395xqlcuq078ml93wl5h8 P-avax1g7nkguzg8yju8cq3ndzc9lql2yg69s9ejqa2af P-avax1g4eryh40dtcsltmxn9zk925ny07gdq2xyjtf4g] ``` -When deploying a Subnet with Ledger, you must include the Ledger's default address determined in [Specify Network](#specify-network) for the deployment to succeed. You may see an error like +When deploying an Avalanche L1 with Ledger, you must include the Ledger's default address determined in [Specify Network](#specify-network) for the deployment to succeed. You may see an error like ``` -Error: wallet does not contain subnet auth keys +Error: wallet does not contain Avalanche L1 auth keys exit status 1 ``` @@ -114,7 +114,7 @@ Next, specify the threshold. In your N of M multisig, your threshold is N, and M ```bash Use the arrow keys to navigate: ↓ ↑ → ← -? Select required number of control key signatures to make a subnet change: +? Select required number of control key signatures to make an Avalanche L1 change: ▸ 1 2 3 @@ -124,10 +124,10 @@ Use the arrow keys to navigate: ↓ ↑ → ← ### Specify Control Keys to Sign the Chain Creation TX[​](#specify-control-keys-to-sign-the-chain-creation-tx "Direct link to heading") -You now need N of your key holders to sign the Subnet deployment transaction. You must select which addresses you want to sign the TX. +You now need N of your key holders to sign the Avalanche L1 deployment transaction. You must select which addresses you want to sign the TX. ```bash -? Choose a subnet auth key: +? Choose an Avalanche L1 auth key: ▸ P-avax1wryu62weky9qjlp40cpmnqf6ml2hytnagj5q28 P-avax1kdzq569g2c9urm9887cmldlsa3w3jhxe0knfy5 P-avax12gcy0xl0al6gcjrt0395xqlcuq078ml93wl5h8 @@ -142,7 +142,7 @@ A successful control key selection looks like: ✔ P-avax1kdzq569g2c9urm9887cmldlsa3w3jhxe0knfy5 ✔ P-avax1g7nkguzg8yju8cq3ndzc9lql2yg69s9ejqa2af Your subnet auth keys for chain creation: [P-avax1kdzq569g2c9urm9887cmldlsa3w3jhxe0knfy5 P-avax1g7nkguzg8yju8cq3ndzc9lql2yg69s9ejqa2af] -*** Please sign subnet creation hash on the ledger device *** +*** Please sign Avalanche L1 creation hash on the ledger device *** ``` #### Potential Errors[​](#potential-errors "Direct link to heading") @@ -153,8 +153,8 @@ If the currently connected Ledger address isn't included in your TX signing grou ✔ 2 ✔ P-avax1g7nkguzg8yju8cq3ndzc9lql2yg69s9ejqa2af ✔ P-avax1g4eryh40dtcsltmxn9zk925ny07gdq2xyjtf4g -Your subnet auth keys for chain creation: [P-avax1g7nkguzg8yju8cq3ndzc9lql2yg69s9ejqa2af P-avax1g4eryh40dtcsltmxn9zk925ny07gdq2xyjtf4g] -Error: wallet does not contain subnet auth keys +Your Avalanche L1 auth keys for chain creation: [P-avax1g7nkguzg8yju8cq3ndzc9lql2yg69s9ejqa2af P-avax1g4eryh40dtcsltmxn9zk925ny07gdq2xyjtf4g] +Error: wallet does not contain Avalanche L1 auth keys exit status 1 ``` @@ -166,38 +166,38 @@ If the user has the correct address but doesn't have sufficient balance to pay f ✔ 2 ✔ P-avax1g7nkguzg8yju8cq3ndzc9lql2yg69s9ejqa2af ✔ P-avax1g4eryh40dtcsltmxn9zk925ny07gdq2xyjtf4g -Your subnet auth keys for chain creation: [P-avax1g7nkguzg8yju8cq3ndzc9lql2yg69s9ejqa2af P-avax1g4eryh40dtcsltmxn9zk925ny07gdq2xyjtf4g] -*** Please sign subnet creation hash on the ledger device *** +Your Avalanche L1 auth keys for chain creation: [P-avax1g7nkguzg8yju8cq3ndzc9lql2yg69s9ejqa2af P-avax1g4eryh40dtcsltmxn9zk925ny07gdq2xyjtf4g] +*** Please sign Avalanche L1 creation hash on the ledger device *** Error: insufficient funds: provided UTXOs need 1000000000 more units of asset "rgNLkDPpANwqg3pHC4o9aGJmf2YU4GgTVUMRKAdnKodihkqgr" exit status 1 ``` -### Sign Subnet Deployment TX with the First Address[​](#sign-subnet-deployment-tx-with-the-first-address "Direct link to heading") +### Sign Avalanche L1 Deployment TX with the First Address[​](#sign-avalanche-l1-deployment-tx-with-the-first-address "Direct link to heading") -The Subnet Deployment TX is ready for signing. +The Avalanche L1 Deployment TX is ready for signing. ```bash -*** Please sign subnet creation hash on the ledger device *** +*** Please sign Avalanche L1 creation hash on the ledger device *** ``` This activates a `Please review` window on the Ledger. Navigate to the Ledger's `APPROVE` window by using the Ledger's right button, and then authorize the request by pressing both left and right buttons. ```bash -Subnet has been created with ID: 2qUKjvPx68Fgc1NMi8w4mtaBt5hStgBzPhsQrS1m7vSub2q9ew. Now creating blockchain... +Avalanche L1 has been created with ID: 2qUKjvPx68Fgc1NMi8w4mtaBt5hStgBzPhsQrS1m7vSub2q9ew. Now creating blockchain... *** Please sign blockchain creation hash on the ledger device *** ``` -After successful Subnet creation, the CLI asks the user to sign the blockchain creation TX. +After successful Avalanche L1 creation, the CLI asks the user to sign the blockchain creation TX. This activates a `Please review` window on the Ledger. Navigate to the Ledger's `APPROVE` window by using the Ledger's right button, and then authorize the request by pressing both left and right buttons. -On success, the CLI provides Subnet deploy details. As only one address signed the chain creation TX, the CLI writes a file to disk to save the TX to continue the signing process with another command. +On success, the CLI provides Avalanche L1 deploy details. As only one address signed the chain creation TX, the CLI writes a file to disk to save the TX to continue the signing process with another command. ```bash +--------------------+----------------------------------------------------+ | DEPLOYMENT RESULTS | | +--------------------+----------------------------------------------------+ -| Chain Name | testsubnet | +| Chain Name | testblockchain | +--------------------+----------------------------------------------------+ | Subnet ID | 2qUKjvPx68Fgc1NMi8w4mtaBt5hStgBzPhsQrS1m7vSub2q9ew | +--------------------+----------------------------------------------------+ @@ -218,13 +218,13 @@ Addresses remaining to sign the tx: P-avax1g7nkguzg8yju8cq3ndzc9lql2yg69s9ejqa2a Connect a ledger with one of the remaining addresses or choose a stored key and run the signing command, or send "partiallySigned.txt" to another user for signing. -Signing command: avalanche transaction sign testsubnet --input-tx-filepath partiallySigned.txt +Signing command: avalanche transaction sign testblockchain --input-tx-filepath partiallySigned.txt ``` -Gather Remaining Signatures and Issue the Subnet Deployment TX[​](#gather-remaining-signatures-and-issue-the-subnet-deployment-tx "Direct link to heading") +Gather Remaining Signatures and Issue the Avalanche L1 Deployment TX[​](#gather-remaining-signatures-and-issue-the-avalanche-l1-deployment-tx "Direct link to heading") ----------------------------------------------------------------------------------------------------------------------------------------------------------- -So far, one address has signed the Subnet deployment TX, but you need N signatures. Your Subnet has not been fully deployed yet. To get the remaining signatures, you may connect a different Ledger to the same computer you've been working on. Alternatively, you may send the `partiallySigned.txt` file to other users to sign themselves. +So far, one address has signed the Avalanche L1 deployment TX, but you need N signatures. Your Avalanche L1 has not been fully deployed yet. To get the remaining signatures, you may connect a different Ledger to the same computer you've been working on. Alternatively, you may send the `partiallySigned.txt` file to other users to sign themselves. The remainder of this section assumes that you are working on a machine with access to both the remaining keys and the `partiallySigned.txt` file. @@ -235,7 +235,7 @@ Avalanche-CLI can detect the deployment network automatically. For `Mainnet` TXs You can start the signing process with the `transaction sign` command: ```bash -avalanche transaction sign testsubnet --input-tx-filepath partiallySigned.txt +avalanche transaction sign testblockchain --input-tx-filepath partiallySigned.txt ``` ```bash @@ -243,11 +243,11 @@ Ledger address: P-avax1g7nkguzg8yju8cq3ndzc9lql2yg69s9ejqa2af *** Please sign TX hash on the ledger device *** ``` -Next, the CLI starts a new signing process for the Subnet deployment TX. If the Ledger isn't the correct one, the following error should appear instead: +Next, the CLI starts a new signing process for the Avalanche L1 deployment TX. If the Ledger isn't the correct one, the following error should appear instead: ```bash Ledger address: P-avax1kdzq569g2c9urm9887cmldlsa3w3jhxe0knfy5 -Error: wallet does not contain subnet auth keys +Error: wallet does not contain Avalanche L1 auth keys exit status 1 ``` @@ -262,17 +262,17 @@ Overwriting partiallySigned.txt Tx is fully signed, and ready to be committed -Commit command: avalanche transaction commit testsubnet --input-tx-filepath partiallySigned.txt +Commit command: avalanche transaction commit testblockchain --input-tx-filepath partiallySigned.txt ``` Now, `partiallySigned.txt` contains a fully signed TX. -### Commit the Subnet Deployment TX[​](#commit-the-subnet-deployment-tx "Direct link to heading") +### Commit the Avalanche L1 Deployment TX[​](#commit-the-avalanche-l1-deployment-tx "Direct link to heading") To run submit the fully signed TX, run: ```bash -avalanche transaction commit testsubnet --input-tx-filepath partiallySigned.txt +avalanche transaction commit testblockchain --input-tx-filepath partiallySigned.txt ``` The CLI recognizes the deployment network automatically and submits the TX appropriately. @@ -281,7 +281,7 @@ The CLI recognizes the deployment network automatically and submits the TX appro +--------------------+-------------------------------------------------------------------------------------+ | DEPLOYMENT RESULTS | | +--------------------+-------------------------------------------------------------------------------------+ -| Chain Name | testsubnet | +| Chain Name | testblockchain | +--------------------+-------------------------------------------------------------------------------------+ | Subnet ID | 2qUKjvPx68Fgc1NMi8w4mtaBt5hStgBzPhsQrS1m7vSub2q9ew | +--------------------+-------------------------------------------------------------------------------------+ @@ -295,7 +295,7 @@ The CLI recognizes the deployment network automatically and submits the TX appro +--------------------+-------------------------------------------------------------------------------------+ ``` -Your Subnet successfully deployed with a multisig. +Your Avalanche L1 successfully deployed with a multisig. Add Validators Using the Multisig[​](#add-validators-using-the-multisig "Direct link to heading") ------------------------------------------------------------------------------------------------- @@ -303,7 +303,7 @@ Add Validators Using the Multisig[​](#add-validators-using-the-multisig "Direc The `addValidator` command also requires use of the multisig. Before starting, make sure to connect, unlock, and run the Avalanche Ledger app. ```bash -avalanche blockchain addValidator testsubnet +avalanche blockchain addValidator testblockchain ``` ### Select Network[​](#select-network "Direct link to heading") @@ -324,7 +324,7 @@ Then, similar to the `deploy` command, the command asks the user to select the N ```bash ✔ Mainnet Use the arrow keys to navigate: ↓ ↑ → ← -? Choose a subnet auth key: +? Choose an Avalanche L1 auth key: ▸ P-avax1wryu62weky9qjlp40cpmnqf6ml2hytnagj5q28 P-avax1kdzq569g2c9urm9887cmldlsa3w3jhxe0knfy5 P-avax12gcy0xl0al6gcjrt0395xqlcuq078ml93wl5h8 @@ -341,7 +341,7 @@ Your subnet auth keys for add validator TX creation: [P-avax1kdzq569g2c9urm9887c ### Finish Assembling the TX[​](#finish-assembling-the-tx "Direct link to heading") -Take a look at [Add a Validator](/subnets/deploy-a-subnet/avalanche-mainnet#add-a-validator) for additional help issuing this transaction. +Take a look at [Add a Validator](/avalanche-l1s/deploy-a-avalanche-l1/avalanche-mainnet#add-a-validator) for additional help issuing this transaction. If setting up a multisig, don't select your validator start time to be in one minute. Finishing the signing process takes significantly longer when using a multisig. @@ -355,7 +355,7 @@ Check https://docs.avax.network/apis/avalanchego/apis/info#infogetnodeid for ins What is the NodeID of the validator you'd like to whitelist?: NodeID-7Xhw2mDxuDS44j42TCB6U5579esbSt3Lg ✔ Default (20) When should your validator start validating? -If you validator is not ready by this time, subnet downtime can occur. +If your validator is not ready by this time, Avalanche L1 downtime can occur. ✔ Custom When should the validator start validating? Enter a UTC datetime in 'YYYY-MM-DD HH:MM:SS' format: 2022-11-22 23:00:00 ✔ Until primary network validator expires @@ -391,13 +391,13 @@ Addresses remaining to sign the tx: P-avax1g7nkguzg8yju8cq3ndzc9lql2yg69s9ejqa2a Connect a Ledger with one of the remaining addresses or choose a stored key and run the signing command, or send "partialAddValidatorTx.txt" to another user for signing. -Signing command: avalanche transaction sign testsubnet --input-tx-filepath partialAddValidatorTx.txt +Signing command: avalanche transaction sign testblockchain --input-tx-filepath partialAddValidatorTx.txt ``` Sign and Commit the Add Validator TX[​](#sign-and-commit-the-add-validator-tx "Direct link to heading") ------------------------------------------------------------------------------------------------------- -The process is very similar to signing of Subnet Deployment TX. So far, one address has signed the TX, but you need N signatures. To get the remaining signatures, you may connect a different Ledger to the same computer you've been working on. Alternatively, you may send the `partialAddValidatorTx.txt` file to other users to sign themselves. +The process is very similar to signing of Avalanche L1 Deployment TX. So far, one address has signed the TX, but you need N signatures. To get the remaining signatures, you may connect a different Ledger to the same computer you've been working on. Alternatively, you may send the `partialAddValidatorTx.txt` file to other users to sign themselves. The remainder of this section assumes that you are working on a machine with access to both the remaining keys and the `partialAddValidatorTx.txt` file. @@ -406,7 +406,7 @@ The remainder of this section assumes that you are working on a machine with acc Avalanche-CLI can detect the deployment network automatically. For `Mainnet` TXs, it uses your Ledger automatically. For `Fuji Testnet`, the CLI prompts the user to choose the signing mechanism. ```bash -avalanche transaction sign testsubnet --input-tx-filepath partialAddValidatorTx.txt +avalanche transaction sign testblockchain --input-tx-filepath partialAddValidatorTx.txt ``` ```bash @@ -427,7 +427,7 @@ Overwriting partialAddValidatorTx.txt Tx is fully signed, and ready to be committed -Commit command: avalanche transaction commit testsubnet --input-tx-filepath partialAddValidatorTx.txt +Commit command: avalanche transaction commit testblockchain --input-tx-filepath partialAddValidatorTx.txt ``` Now, `partialAddValidatorTx.txt` contains a fully signed TX. @@ -437,7 +437,7 @@ Now, `partialAddValidatorTx.txt` contains a fully signed TX. To run submit the fully signed TX, run: ```bash -avalanche transaction commit testsubnet --input-tx-filepath partialAddValidatorTx.txt +avalanche transaction commit testblockchain --input-tx-filepath partialAddValidatorTx.txt ``` The CLI recognizes the deployment network automatically and submits the TX appropriately. @@ -446,4 +446,4 @@ The CLI recognizes the deployment network automatically and submits the TX appro Transaction successful, transaction ID: K7XNSwcmgjYX7BEdtFB3hEwQc6YFKRq9g7hAUPhW4J5bjhEJG ``` -You've successfully added the validator to the Subnet. \ No newline at end of file +You've successfully added the validator to the Avalanche L1. diff --git a/content/docs/avalanche-l1s/deploy-a-avalanche-l1/production-infrastructure.mdx b/content/docs/avalanche-l1s/deploy-a-avalanche-l1/production-infrastructure.mdx new file mode 100644 index 00000000000..48e456f7418 --- /dev/null +++ b/content/docs/avalanche-l1s/deploy-a-avalanche-l1/production-infrastructure.mdx @@ -0,0 +1,169 @@ +--- +title: On Production Infrastructure +descdescription: Learn how to deploy an Avalanche L1 on production infrastructure. +--- + +After architecting your Avalanche L1 environment on the [local machine](/avalanche-l1s/deploy-a-avalanche-l1/local-network), proving the design and testing it out on [the Fuji Testnet](/avalanche-l1s/deploy-a-avalanche-l1/fuji-testnet), eventually you will need to deploy your Avalanche L1 to production environment. + +Running an Avalanche L1 in production is much more involved than local and Testnet deploys, as your Avalanche L1 will have to take care of real world usage, maintaining uptime, upgrades and all of that in a potentially adversarial environment. The purpose of this document is to point out a set of general considerations and propose potential solutions to them. + +The architecture of the environment your particular Avalanche L1 will use will be greatly influenced by the type of load and activity your Avalanche L1 is designed to support so your solution will most likely differ from what we propose here. Still, it might be useful to follow along, to build up the intuition for the type of questions you will need to consider. + +Node Setup[​](#node-setup "Direct link to heading") +--------------------------------------------------- + +Avalanche nodes are essential elements for running your Avalanche L1 in production. At a minimum, your Avalanche L1 will need validator nodes, potentially also nodes that act as RPC servers, indexers or explorers. Running a node is basically running an instance of [AvalancheGo](/nodes) on a server. + +### Server OS[​](#server-os "Direct link to heading") + +Although AvalancheGo can run on a MacOS or a Windows computer, we strongly recommend running nodes on computers running Linux as they are designed specifically for server loads and all the tools and utilities needed for administering a server are native to Linux. + +### Hardware Specification[​](#hardware-specification "Direct link to heading") + +For running AvalancheGo as a validator on the Primary Network the recommended configuration is as follows: + +- CPU: Equivalent of 8 AWS vCPU +- RAM: 16 GiB +- Storage: 1 TiB with at least 3000 IOPS +- OS: Ubuntu 20.04 +- Network: Reliable IPv4 or IPv6 network connection, with an open public port + +That is the configuration sufficient for running a Primary Network node. Any resource requirements for your Avalanche L1 come on top of this, so you should not go below this configuration, but may need to step up the specification if you expect your Avalanche L1 to handle a significant amount of transactions. + +Be sure to set up monitoring of resource consumption for your nodes because resource exhaustion may cause your node to slow down or even halt, which may severely impact your Avalanche L1 negatively. + +### Server Location[​](#server-location "Direct link to heading") + +You can run a node on a physical computer that you own and run, or on a cloud instance. Although running on your own HW may seem like a good idea, unless you have a sizeable DevOps 24/7 staff we recommend using cloud service providers as they generally provide reliable computing resources that you can count on to be properly maintained and monitored. + +#### Local Servers[​](#local-servers "Direct link to heading") + +If you plan on running nodes on your own hardware, make sure they satisfy the minimum HW specification as outlined earlier. Pay close attention to proper networking setup, making sure the p2p port (9651) is accessible and public IP properly configured on the node. Make sure the node is connected to the network physically (not over Wi-Fi), and that the router is powerful enough to handle a couple of thousands of persistent TCP connections and that network bandwidth can accommodate at least 5Mbps of steady upstream and downstream network traffic. + +When installing the AvalancheGo node on the machines, unless you have a dedicated DevOps staff that will take care of node setup and configuration, we recommend using the [installer script](/nodes/using-install-script/installing-avalanche-go) to set up the nodes. It will abstract most of the setup process for you, set up the node as a system service and will enable easy node upgrades. + +#### Cloud Providers[​](#cloud-providers "Direct link to heading") + +There are a number of different cloud providers. We have documents that show how to set up a node on the most popular ones: + +- [Amazon Web Services](/nodes/on-third-party-services/amazon-web-services) +- [Azure](/nodes/on-third-party-services/microsoft-azure) +- [Google Cloud Platform](/nodes/on-third-party-services/google-cloud) + +There is a whole range of other cloud providers that may offer lower prices or better deals for your particular needs, so it makes sense to shop around. + +Once you decide on a provider (or providers), if they offer instances in multiple data centers, it makes sense to spread the nodes geographically since that provides a better resilience and stability against outages. + +### Number of Validators[​](#number-of-validators "Direct link to heading") + +Number of validators on an Avalanche L1 is a crucial decision you need to make. For stability and decentralization, you should strive to have as many validators as possible. + +For stability reasons our recommendation is to have **at least** 5 full validators on your Avalanche L1. If you have less than 5 validators your Avalanche L1 liveness will be at risk whenever a single validator goes offline, and if you have less than 4 even one offline node will halt your Avalanche L1. + +You should be aware that 5 is the minimum we recommend. But, from a decentralization standpoint having more validators is always better as it increases the stability of your Avalanche L1 and makes it more resilient to both technical failures and adversarial action. In a nutshell: run as many Avalanche L1 validators as you can. + +Considering that at times you will have to take nodes offline, for routine maintenance (at least for node upgrades which happen with some regularity) or unscheduled outages and failures you need to be able to routinely handle at least one node being offline without your Avalanche L1 performance degrading. + +### Node Bootstrap[​](#node-bootstrap "Direct link to heading") + +Once you set up the server and install AvalancheGo on them, nodes will need to bootstrap (sync with the network). This is a lengthy process, as the nodes need to catch up and replay all the network activity since the genesis up to the present moment. Full bootstrap on a node can take more than a week, but there are ways to shorten that process, depending on your circumstances. + +#### State Sync[​](#state-sync "Direct link to heading") + +If the nodes you will be running as validators don't need to have the full transaction history, then you can use [state sync](/nodes/chain-configs/c-chain#state-sync-enabled). With this flag enabled, instead of replaying the whole history to get to the current state, nodes simply download only the current state from other network peers, shortening the bootstrap process from multiple days to a couple of hours. If the nodes will be used for Avalanche L1 validation exclusively, you can use the state sync without any issues. Currently, state sync is only available for the C-Chain, but since the bulk of the transactions on the platform happen there it still has a significant impact on the speed of bootstrapping. + +#### Database Copy[​](#database-copy "Direct link to heading") + +Good way to cut down on bootstrap times on multiple nodes is database copy. Database is identical across nodes, and as such can safely be copied from one node to another. Just make sure to that the node is not running during the copy process, as that can result in a corrupted database. Database copy procedure is explained in detail [here](/nodes/maintain/backup-restore#database). + +Please make sure you don't reuse any node's NodeID by accident, especially don't restore another node's ID, see [here](/nodes/maintain/backup-restore#nodeid) for details. Each node must has its own unique NodeID, otherwise, the nodes sharing the same ID will not behave correctly, which will impact your validator's uptime, thus staking rewards, and the stability of your Avalanche L1. + +Avalanche L1 Deploy[​](#avalanche-l1-deploy "Direct link to heading") +--------------------------------------------------------- + +Once you have the nodes set up you are ready to deploy the actual Avalanche L1. Right now, the recommended tool to do that is [Avalanche-CLI](https://github.com/ava-labs/avalanche-cli). + +Instructions for deployment by Avalanche-CLI can be found [here](/avalanche-l1s/deploy-a-avalanche-l1/avalanche-mainnet). + +### Ledger Hardware Wallet[​](#ledger-hw-wallet "Direct link to heading") + +When creating the Avalanche L1, you will be required to have a private key that will control the administrative functions of the Avalanche L1 (adding validators, managing the configuration). Needless to say, whoever has this private key has complete control over the Avalanche L1 and the way it runs. Therefore, protecting that key is of the utmost operational importance. Which is why we strongly recommend using a hardware wallet such as a [Ledger HW Wallet](https://www.ledger.com/) to store and access that private key. + +General instruction on how to use a Ledger device with Avalanche can be found [here](https://support.avax.network/en/articles/6150237-how-to-use-a-ledger-nano-s-or-nano-x-with-avalanche). + +### Genesis File[​](#genesis-file "Direct link to heading") + +The structure that defines the most important parameters in an Avalanche L1 is found in the genesis file, which is a `json` formatted, human-readable file. Describing the contents and the options available in the genesis file is beyond the scope of this document, and if you're ready to deploy your Avalanche L1 to production you probably have it mapped out already. + +If you want to review, we have a description of the genesis file in our document on [customizing EVM Avalanche L1s](/avalanche-l1s/upgrade/customize-avalanche-l1). + +Validator Configuration[​](#validator-configuration "Direct link to heading") +----------------------------------------------------------------------------- + +Running nodes as Avalanche L1 validators warrants some additional considerations, above those when running a regular node or a Primary Network-only validator. + +### Joining an Avalanche L1[​](#joining-a-avalanche-l1 "Direct link to heading") + +For a node to join an Avalanche L1, there are two prerequisites: + +- Primary Network validation +- Avalanche L1 tracking + +Primary Network validation means that a node cannot join an Avalanche L1 as a validator before becoming a validator on the Primary Network itself. So, after you add the node to the validator set on the Primary Network, node can join an Avalanche L1. Of course, this is valid only for Avalanche L1 validators, if you need a non-validating Avalanche L1 node, then the node doesn't need to be a validator at all. + +To have a node start syncing the Avalanche L1, you need to add the `--track-subnets` command line option, or `track-subnets` key to the node config file (found at `.avalanchego/configs/node.json` for installer-script created nodes). A single node can sync multiple Layer 1s, so you can add them as a comma-separated list of Avalanche L1 IDs (SubnetID). + +An example of a node config syncing two Avalanche L1s: + +```json +{ + "public-ip-resolution-service": "opendns", + "http-host": "", + "track-subnets": "28nrH5T2BMvNrWecFcV3mfccjs6axM1TVyqe79MCv2Mhs8kxiY,Ai42MkKqk8yjXFCpoHXw7rdTWSHiKEMqh5h8gbxwjgkCUfkrk" +} +``` + +But that is not all. Besides tracking the SubnetID, the node also needs to have the plugin that contains the VM instance the blockchain in the Avalanche L1 will run. You should have already been through that on Testnet and Fuji, but for a refresher, you can refer to [this tutorial](/avalanche-l1s/deploy-a-avalanche-l1/fuji-testnet). + +So, name the VM plugin binary as the `VMID` of the Avalanche L1 chain and place it in the `plugins` directory where the node binary is (for installer-script created nodes that would be `~/avalanche-node/plugins/`). + +### Avalanche L1 Bootstrapping[​](#avalanche-l1-bootstrapping "Direct link to heading") + +After you have tracked the Avalanche L1 and placed the VM binary in the correct directory, your node is ready to start syncing with the Avalanche L1. Restart the node and monitor the log output. You should notice something similar to: + +```bash +Jul 30 18:26:31 node-fuji avalanchego[1728308]: [07-30|18:26:31.422] INFO chains/manager.go:262 creating chain: +Jul 30 18:26:31 node-fuji avalanchego[1728308]: ID: 2ebCneCbwthjQ1rYT41nhd7M76Hc6YmosMAQrTFhBq8qeqh6tt +Jul 30 18:26:31 node-fuji avalanchego[1728308]: VMID:srEXiWaHuhNyGwPUi444Tu47ZEDwxTWrbQiuD7FmgSAQ6X7Dy +``` + +That means the node has detected the Avalanche L1, and is attempting to initialize it and start bootstrapping the Avalanche L1. It might take some time (if there are already transactions on the Avalanche L1), and eventually it will finish the bootstrap with a message like: + +```bash +Jul 30 18:27:21 node-fuji avalanchego[1728308]: [07-30|18:27:21.055] INFO <2ebCneCbwthjQ1rYT41nhd7M76Hc6YmosMAQrTFhBq8qeqh6tt Chain> snowman/transitive.go:333 consensus starting with J5wjmotMCrM2DKxeBTBPfwgCPpvsjtuqWNozLog2TomTjSuGK as the last accepted block +``` + +That means the node has successfully bootstrapped the Avalanche L1 and is now in sync. If the node is one of the validators, it will start validating any transactions that get posted to the Avalanche L1. + +### Monitoring[​](#monitoring "Direct link to heading") + +If you want to inspect the process of Avalanche L1 syncing, you can use the RPC call to check for the [blockchain status](/api-reference/p-chain/api#platformgetblockchainstatus). + +For a more in-depth look into Avalanche L1 operation, check out the blockchain log. By default, the log can be found in `~/.avalanchego/logs/ChainID.log` where you replace the `ChainID` with the actual ID of the blockchain in your Avalanche L1. + +For an even more thorough (and pretty!) insight into how the node and the Avalanche L1 is behaving, you can install the Prometheus+Grafana monitoring system with the custom dashboards for the regular node operation, as well as a dedicated dashboard for Avalanche L1 data. Check out the [tutorial](/nodes/maintain/monitoring) for information on how to set it up. + +### Managing Validation[​](#managing-validation "Direct link to heading") + +On Avalanche all validations are limited in time and can range from two weeks up to one year. Furthermore, Avalanche L1 validations are always a subset of the Primary Network validation period (must be shorter or the same). That means that periodically your validators will expire and you will need to submit a new validation transaction for both the Primary Network and your Avalanche L1. + +Unless managed properly and in a timely manner, that can be disruptive for your Avalanche L1 (if all validators expire at the same time your Avalanche L1 will halt). To avoid that, keep notes on when a particular validation is set to expire and be ready to renew it as soon as possible. Also, when initially setting up the nodes, make sure to stagger the validator expiry so they don't all expire on the same date. Setting end dates at least a day apart is a good practice, as well as setting reminders for each expiry. + +Conclusion[​](#conclusion "Direct link to heading") +--------------------------------------------------- + +Hopefully, by reading this document you have a better picture of the requirements and considerations you need to make when deploying your Avalanche L1 to production and you are now better prepared to launch your Avalanche L1 successfully. + +Keep in mind, running an Avalanche L1 in production is not a one-and-done kind of situation, it is in fact running a fleet of servers 24/7. And as with any real time service, you should have a robust logging, monitoring and alerting systems to constantly check the nodes and Avalanche L1 health and alert you if anything out of the ordinary happens. + +If you have any questions, doubts or would like to chat, please check out our [Discord server](https://chat.avax.network/), where we host a dedicated `#subnet-chat` channel dedicated to talking about all things Avalanche L1. diff --git a/content/docs/avalanche-l1s/elastic-avalanche-l1s/make-avalanche-l1-permissionless.mdx b/content/docs/avalanche-l1s/elastic-avalanche-l1s/make-avalanche-l1-permissionless.mdx new file mode 100644 index 00000000000..ca134793fc9 --- /dev/null +++ b/content/docs/avalanche-l1s/elastic-avalanche-l1s/make-avalanche-l1-permissionless.mdx @@ -0,0 +1,80 @@ +--- +title: Make Avalanche L1 Permissionless +description: Learn how to transform a Permissioned Avalanche L1 into an Elastic Avalanche L1. +--- + +Elastic Avalanche L1s are permissionless Avalanche L1s. More information can be found [here](/avalanche-l1s/elastic-avalanche-l1s/parameters). + +This how-to guide focuses on taking an already created permissioned Avalanche L1 and transforming it to an elastic (or permissionless) Avalanche L1. + +## Prerequisites + +- [Avalanche-CLI installed](/tooling/guides/get-avalanche-cli) +- You have deployed a permissioned Avalanche L1 on [local](/avalanche-l1s/deploy-a-avalanche-l1/local-network), on [Fuji](/avalanche-l1s/deploy-a-avalanche-l1/fuji-testnet) or on [Mainnet](/avalanche-l1s/deploy-a-avalanche-l1/avalanche-mainnet) + +Getting Started[​](#getting-started "Direct link to heading") +------------------------------------------------------------- + +In the following commands, make sure to substitute the name of your Avalanche L1 configuration for ``. + +To transform your permissioned Avalanche L1 into an Elastic Avalanche L1 (NOTE: this action is irreversible), run: + +```bash +avalanche blockchain elastic +``` + +and, select the network that you want to transform the Avalanche L1 on. Alternatively, you can bypass this prompt by providing the `--local`, `--fuji`, or `--mainnet` flag. + +Provide the name and the symbol for the permissionless Avalanche L1's native token. You can also bypass this prompt by providing the `--tokenName` and `--tokenSymbol` flags. + +Next, select the Elastic Avalanche L1 config. You can choose to use the default values detailed [here](/avalanche-l1s/elastic-avalanche-l1s/parameters#primary-network-parameters-on-mainnet) or customize the Elastic Avalanche L1 config. To bypass the prompt, you can use `--default` flag to use the default Elastic Avalanche L1 config. + +The command may take a couple minutes to run. + +### Elastic Avalanche L1 Transformation on Fuji and Mainnet[​](#elastic-avalanche-l1-transformation-on-fuji-and-mainnet "Direct link to heading") + +Elastic Avalanche L1 transformation on public network requires private key loaded into the tool, or a connected ledger device. + +Both stored key usage and ledger usage are enabled on Fuji (see more on creating keys [here](/avalanche-l1s/deploy-a-avalanche-l1/fuji-testnet#private-key)) while only ledger usage is enabled on Mainnet (see more on setting up your ledger [here](/avalanche-l1s/deploy-a-avalanche-l1/avalanche-mainnet#setting-up-your-ledger)). + +To transform a permissioned Avalanche L1 into Elastic Avalanche L1 on public networks, users are required to provide the keys that control the Avalanche L1 defined during the Avalanche L1 deployment process (more info on keys in Fuji can be found [here](/avalanche-l1s/deploy-a-avalanche-l1/fuji-testnet#deploy-the-avalanche-l1), while more info on ledger signing in Mainnet can be found [here](/avalanche-l1s/deploy-a-avalanche-l1/avalanche-mainnet#deploy-the-avalanche-l1)). + +### Results[​](#results "Direct link to heading") + +If all works as expected, you then have the option to automatically transform all existing permissioned validators to permissionless validators. + +You can also to skip automatic transformation at this point and choose to manually add permissionless validators later. + +You can use the output details such as the Asset ID and Elastic Avalanche L1 ID (SubnetID) to connect to and interact with your Elastic Avalanche L1. + +Adding Permissionless Validators to Elastic Avalanche L1[​](#adding-permissionless-validators-to-elastic-avalanche-l1 "Direct link to heading") +----------------------------------------------------------------------------------------------------------------------------------- + +If you are running this command on local network, you will need to first remove permissioned validators (by running `avalanche subnet removeValidator `) so that you can have a list of local nodes to choose from to be added as a permissionless validator in the Elastic Avalanche L1. + +To add permissionless validators to an Elastic Avalanche L1, run: + +```bash +avalanche blockchain join --elastic +``` + +You will be prompted with which node you would like to add as a permissionless validator. You can skip this prompt by using `--nodeID` flag. + +You will then be prompted with the amount of the Avalanche L1 native token that you like to stake in the validator. Alternatively, you can bypass this prompt by providing the `--stake-amount` flag. Note that choosing to add the maximum validator stake amount (defined during Elastic Avalanche L1 transformation step above) means that you effectively disable delegation in your validator. + +Next, select when the validator will start validating and how long it will be validating for. You can also bypass these prompts by using `--start-time` and `--staking-period` flags. + +Adding Permissionless Delegator to a Permissionless Validator in Elastic Avalanche L1[​](#adding-permissionless-delegator-to-a-permissionless-validator-in-elastic-avalanche-l1 "Direct link to heading") +--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- + +To add permissionless delegators, run: + +```bash +avalanche blockchain addPermissionlessDelegator +``` + +You will be prompted with which Avalanche L1 validator you would like to delegate to. You can skip this prompt by using `--nodeID` flag. + +You will then be prompted with the amount of the Avalanche L1 native token that you like to stake in the validator. Alternatively, you can bypass this prompt by providing the `--stake-amount` flag. The amount that can be delegated to a validator is detailed [here](/avalanche-l1s/elastic-avalanche-l1s/parameters#delegators-weight-checks). + +Next, select when you want to start delegating and how long you want to delegate for. You can also bypass these prompts by using `--start-time` and `--staking-period` flags. diff --git a/content/docs/subnets/elastic-subnets/parameters.mdx b/content/docs/avalanche-l1s/elastic-avalanche-l1s/parameters.mdx similarity index 84% rename from content/docs/subnets/elastic-subnets/parameters.mdx rename to content/docs/avalanche-l1s/elastic-avalanche-l1s/parameters.mdx index 280ffc386df..44e4df0b5a5 100644 --- a/content/docs/subnets/elastic-subnets/parameters.mdx +++ b/content/docs/avalanche-l1s/elastic-avalanche-l1s/parameters.mdx @@ -1,40 +1,40 @@ --- title: Parameters -description: Learn about the different parameters of Elastic Subnets. +description: Learn about the different parameters of Elastic Avalanche L1s. --- -Avalanche Permissioned Subnets can be turned into Elastic Subnets via the `TransformSubnetTx` transaction. `TransformSubnetTx` specifies a set of structural parameters for the Elastic Subnet. +Avalanche Permissioned Avalanche L1s can be turned into Elastic Avalanche L1s via the `TransformSubnetTx` transaction. `TransformSubnetTx` specifies a set of structural parameters for the Elastic Avalanche L1. This reference document describes these structural parameters and illustrates the constraints they must satisfy. -## Elastic Subnet Parameters +## Elastic Avalanche L1 Parameters ### `Subnet` -`Subnet` has type `ids.ID` and it's the Subnet ID. `Subnet` is the ID of the `CreateSubnetTx` transaction that created the Subnet in the first place. The following constraints apply: +`Subnet` has type `ids.ID` and it's the Avalanche L1 ID (SubnetID). `Subnet` is the ID of the `CreateSubnetTx` transaction that created the Avalanche L1 in the first place. The following constraints apply: - `Subnet` must be different from `PrimaryNetworkID`. ### `AssetID` -`AssetID` has type `ids.ID` and it's the ID of the asset to use when staking on the Subnet. The following constraints apply: +`AssetID` has type `ids.ID` and it's the ID of the asset to use when staking on the Avalanche L1. The following constraints apply: - `AssetID` must not be the `Empty ID`. - `AssetID` must not be `AVAX ID`, the Primary Network asset. ### `InitialSupply` -`InitialSupply` has type `uint64` and it's the initial amount of `AssetID` transferred in the Elastic Subnet upon its transformation. Such amount is available for distributing staking rewards. The following constraints apply: +`InitialSupply` has type `uint64` and it's the initial amount of `AssetID` transferred in the Elastic Avalanche L1 upon its transformation. Such amount is available for distributing staking rewards. The following constraints apply: - `InitialSupply` must be larger than zero. ### `MaximumSupply` -`MaximumSupply` has type `uint64` and it's the maximum amount of `AssetID` that Subnet has available for staking and rewards at any time. The following constraints apply: +`MaximumSupply` has type `uint64` and it's the maximum amount of `AssetID` that Avalanche L1 has available for staking and rewards at any time. The following constraints apply: - `MaximumSupply` must be larger or equal to `InitialSupply`. -A Subnet supply can vary in time but it should be no larger than the configured maximum at any point in time, including at Subnet creation. +an Avalanche L1 supply can vary in time but it should be no larger than the configured maximum at any point in time, including at Avalanche L1 creation. ### `MinConsumptionRate` @@ -84,7 +84,7 @@ See [Notes on Percentages](#notes-on-percentages) section to understand `Percent - `MaxStakeDuration` must be larger or equal to `MinStakeDuration`. - `MaxStakeDuration` must be smaller or equal to `GlobalMaxStakeDuration`. -`GlobalMaxStakeDuration` is defined in genesis and applies to both the Primary Network and all Subnets. +`GlobalMaxStakeDuration` is defined in genesis and applies to both the Primary Network and all Avalanche L1s. Its Mainnet value is $365 \times 24 \times time.Hour$. @@ -118,11 +118,11 @@ See [Notes on Percentages](#notes-on-percentages) section to understand `Percent ## Reward Formula -Consider an Elastic Subnet validator which stakes a $Stake$ amount `AssetID` for $StakingPeriod$ seconds. +Consider an Elastic Avalanche L1 validator which stakes a $Stake$ amount `AssetID` for $StakingPeriod$ seconds. -Assume that at the start of the staking period there is a $Supply$ amount of `AssetID` in the Subnet. The maximum amount of Subnet asset is $MaximumSupply$ `AssetID`. +Assume that at the start of the staking period there is a $Supply$ amount of `AssetID` in the Avalanche L1. The maximum amount of Avalanche L1 asset is $MaximumSupply$ `AssetID`. -Then at the end of its staking period, a responsive Elastic Subnet validator receives a reward calculated as follows: +Then at the end of its staking period, a responsive Elastic Avalanche L1 validator receives a reward calculated as follows: $$ Reward = \left(MaximumSupply - Supply \right) \times \frac{Stake}{Supply} \times \frac{Staking Period}{Minting Period} \times EffectiveConsumptionRate @@ -131,7 +131,7 @@ $$ where, $$ -MaximumSupply - Supply = \text{the number of tokens left to emit in the subnet} +MaximumSupply - Supply = \text{the number of tokens left to emit in the avalanche-l1} $$ $$ @@ -186,7 +186,7 @@ $$ MaxWeight = \min(Validator.Weight \times MaxValidatorWeightFactor, MaxValidatorStake) $$ -where $MaxValidatorWeightFactor$ and $MaxValidatorStake$ are the Elastic Subnet Parameters described above. +where $MaxValidatorWeightFactor$ and $MaxValidatorStake$ are the Elastic Avalanche L1 Parameters described above. A delegator won't be added to a validator if the combination of their weights and all other validator's delegators' weight is larger than $MaxWeight$. Note that this must be true at any point in time. @@ -205,7 +205,7 @@ It allows you to specify percentages up to 4 digital positions. To denominate yo ## Primary Network Parameters on Mainnet -An Elastic Subnet is free to pick any parameters affecting rewards, within the constraints specified above. For reference we list below Primary Network parameters on Mainnet: +An Elastic Avalanche L1 is free to pick any parameters affecting rewards, within the constraints specified above. For reference we list below Primary Network parameters on Mainnet: - `AssetID = Avax` - `InitialSupply = 240_000_000 Avax` @@ -235,4 +235,4 @@ Graph variables correspond to those defined above: - `l` (low) = $MinConsumptionRate$ - `s` = $\frac{Stake}{Supply}$ - \ No newline at end of file + diff --git a/content/docs/avalanche-l1s/index.mdx b/content/docs/avalanche-l1s/index.mdx new file mode 100644 index 00000000000..0aa71a5f9d5 --- /dev/null +++ b/content/docs/avalanche-l1s/index.mdx @@ -0,0 +1,75 @@ +--- +title: Getting Started +description: As you begin your Avalanche L1 journey, it's useful to look at the lifecycle of taking an Avalanche L1 from idea to production. +--- + +Figure Out Your Needs[​](#figure-out-your-needs "Direct link to heading") +------------------------------------------------------------------------- + +The first step of planning your Avalanche L1 is determining your application's needs. What features do you need that the Avalanche C-Chain doesn't provide? Perhaps you want your own gas token or only want to allow access to KYCed customers. [When to Build on an Avalanche L1 vs. on the C-Chain](/avalanche-l1s/c-chain-or-avalanche-l1) can help you make the decision. + +### Decide What Type of Avalanche L1 You Want[​](#decide-what-type-of-avalanche-l1-you-want "Direct link to heading") + +Once you've decided to use an Avalanche L1, you need to decide what type of Avalanche L1 to build. This means choosing a virtual machine (VM) to create your Avalanche L1 with. Broadly speaking, there are three types of VMs to choose from: + +#### EVM-Based Avalanche L1s[​](#evm-based-avalanche-l1s "Direct link to heading") + +EVM-based Avalanche L1s are forks of the Avalanche C-Chain. They support Solidity smart contracts and standard [Ethereum APIs](/api-reference/c-chain/api#ethereum-apis). [Subnet-EVM](https://github.com/ava-labs/subnet-evm) is Ava Labs' implementation of an EVM-Based Avalanche L1. + +Subnet-EVM is far and away the safest and most popular choice to build your blockchain with. It has the most mature developer tooling and receives regular updates by the Ava Labs team. + +#### Experimental Avalanche L1s[​](#experimental-avalanche-l1s "Direct link to heading") + +Experimental Avalanche L1s are proof-of-concept VMs developed by Ava Labs. They include the [TimestampVM Go](/virtual-machines/golang-vms/simple-golang-vm), [TimestampVMRust](/virtual-machines/timestamp-vm/introduction), and others. These VMs are demo software and aren't ready for production environments. Although they do receive periodic updates, the Ava Labs team hasn't audited their performance and security, internally or externally. However, these open source projects are intended to inspire the community, and provide novel capabilities not available inside the EVM. + +If you're looking to push the boundaries of what's possible with Avalanche L1s, this is a great place to get started. + +#### Custom Avalanche L1s[​](#custom-avalanche-l1s "Direct link to heading") + +Custom Avalanche L1s are an open-ended interface that allow developers to build any VM they can dream. These VMs may be a fork of an existing VM such as Subnet-EVM, or even a non-Avalanche-native VM such as Solana's virtual machine. Alternatively, you can build your VM entirely from scratch using almost any programming language. See [Introduction to VMs](/virtual-machines) for advice on getting started. + +### Determine Tokenomics[​](#determine-tokenomics "Direct link to heading") + +Avalanche L1s are powered by gas tokens. When you build an Avalanche L1, you have the option to decide what token you use and optionally, how you distribute it. You may use AVAX, an existing C-Chain token, or a brand new token. You'll need to decide how much of the supply you want to use to reward validators, what kind of emitting schedule you want, and how much to airdrop. Blocks may burn transaction fees or give them to validators as a block reward. + +### Decide how to Customize Your Avalanche L1[​](#decide-how-to-customize-your-avalanche-l1 "Direct link to heading") + +After you've selected your VM, you may want to customize it. This may mean airdropping tokens to your team in the genesis, setting how gas fees rates on your network, or changing the behavior of your VM via precompiles. These customizations are hard to get right on paper and usually require some trial and error to determine correctly. See [Customize Your EVM-Powered Avalanche L1](/avalanche-l1s/upgrade/customize-avalanche-l1) for instructions on configuring Subnet-EVM. + +Learn Avalanche-CLI[​](#learn-avalanche-cli "Direct link to heading") +--------------------------------------------------------------------- + +Now that you've specified your Avalanche L1 requirements, the next step is learning Avalanche-CLI. + +Avalanche-CLI is the best tool for rapidly prototyping Avalanche L1s and deploying them to production. You can use it throughout the entire Avalanche L1 development lifecycle. To get started, take a look at [Build Your First Avalanche L1](/avalanche-l1s/build-first-avalanche-l1). + +### Deploy Your Avalanche L1 Locally[​](#deploy-your-avalanche-l1-locally "Direct link to heading") + +The first stage of Avalanche L1 development involves testing your Avalanche L1 on your local machine or on a private cloud server such as Amazon EC2. The goal of this phase is to lock-in your Avalanche L1 customizations and create your full-stack dapp without the constraints of deploying on a public network. + +Development is extremely quick and updates take seconds to minutes to apply. In this phase, you should restrict dapp access to trusted parties. Because you're interacting with a local copy of the Avalanche network, you can't access production state or other production Avalanche L1s. + +### Deploy Your Avalanche L1 to Fuji[​](#deploy-your-avalanche-l1-to-fuji "Direct link to heading") + +The second stage of Avalanche L1 development involves deploying your Avalanche L1 and your dapp to the Fuji Testnet. This phase tests your ability to run validator nodes, coordinate all parties involved in the Avalanche L1, and monitor network health. You can also practice using Ledgers to manage Avalanche L1 transactions. + +The Avalanche L1 is publicly visible and you may want to allow external users to test your dapp. Development on Fuji is significantly slower than with local development. Updates may now take hours to days to apply. It's important to do as much local testing as possible before moving to Fuji. + +### Deploy Your Avalanche L1 to Mainnet[​](#deploy-your-avalanche-l1-to-mainnet "Direct link to heading") + +The final stage of Avalanche L1 development is creating your Avalanche L1 on Mainnet and deploying your dapp. It's time to let your real users in. + +Once your Avalanche L1 is in production, you have little flexibility to change it. Some alterations are possible, but they require days to weeks to implement and roll out. + +Your focus should shift to preserving network stability and upgrading your nodes as needed. + +Start Developing Custom VMs[​](#start-developing-custom-vms "Direct link to heading") +------------------------------------------------------------------------------------- + +If you've mastered Subnet-EVM and are looking for an additional challenge, consider building a custom VM. The Avalanche network supports far more than just the EVM. Current VMs only scratch the surface of what's possible. + +Some ideas: + +- Port an existing blockchain project to Avalanche. For example: Use Bitcoin's VM or Solana's VM. +- Create an app-specific VM instead of a general purpose VM. For example, create a DEX or a CLOB VM instead of something like the EVM. +- Create a more efficient implementation of the EVM. diff --git a/content/docs/avalanche-l1s/maintain/delete-avalanche-l1.mdx b/content/docs/avalanche-l1s/maintain/delete-avalanche-l1.mdx new file mode 100644 index 00000000000..6fd6b3bdbdd --- /dev/null +++ b/content/docs/avalanche-l1s/maintain/delete-avalanche-l1.mdx @@ -0,0 +1,25 @@ +--- +title: Delete an Avalanche L1 +description: Learn how to delete an Avalanche L1. +--- + +Deleting an Avalanche L1 Configuration[​](#deleting-a-avalanche-l1-configuration "Direct link to heading") +--------------------------------------------------------------------------------------------- + +To delete a created Avalanche L1 configuration, run: + +```bash +avalanche blockchain delete +``` + +Deleting a Deployed Avalanche L1[​](#deleting-a-deployed-avalanche-l1 "Direct link to heading") +----------------------------------------------------------------------------------- + +You can't delete Avalanche L1s deployed to Mainnet or the Fuji Testnet. + +However, you may delete Avalanche L1s deployed to a local network by cleaning the network state with below command: + +```bash +avalanche network clean +``` + diff --git a/content/docs/subnets/maintain/pause-resume.mdx b/content/docs/avalanche-l1s/maintain/pause-resume.mdx similarity index 95% rename from content/docs/subnets/maintain/pause-resume.mdx rename to content/docs/avalanche-l1s/maintain/pause-resume.mdx index 98a1abeb21b..733e6614926 100644 --- a/content/docs/subnets/maintain/pause-resume.mdx +++ b/content/docs/avalanche-l1s/maintain/pause-resume.mdx @@ -1,6 +1,6 @@ --- title: Pause and Resume -description: If you've deployed a Subnet locally, you can preserve and restore the state of your deployed Subnets. +description: If you've deployed an Avalanche L1 locally, you can preserve and restore the state of your deployed Avalanche L1s. --- Stopping the Local Network[​](#stopping-the-local-network "Direct link to heading") @@ -15,7 +15,7 @@ avalanche network stop Network stopped successfully. ``` -When restarted, all of your deployed Subnets resume where they left off. +When restarted, all of your deployed Avalanche L1s resume where they left off. ### Resuming the Local Network[​](#resuming-the-local-network "Direct link to heading") @@ -93,4 +93,4 @@ or ```bash Requesting network status... Error: timed out trying to contact backend controller, it is most probably not running -``` \ No newline at end of file +``` diff --git a/content/docs/subnets/maintain/transfer-pchain-funds.mdx b/content/docs/avalanche-l1s/maintain/transfer-pchain-funds.mdx similarity index 97% rename from content/docs/subnets/maintain/transfer-pchain-funds.mdx rename to content/docs/avalanche-l1s/maintain/transfer-pchain-funds.mdx index 095fd410a9b..9dc5bc6966e 100644 --- a/content/docs/subnets/maintain/transfer-pchain-funds.mdx +++ b/content/docs/avalanche-l1s/maintain/transfer-pchain-funds.mdx @@ -5,7 +5,7 @@ desscription: Learn how to transfer P-Chain funds using Avalanche CLI. Transferring funds between P-Chain wallets becomes necessary in certain situations: -1. Funds need to be sent to the Subnet control key, which might have a zero balance due to fee payments. The Subnet control key requires funding to ensure proper support for Subnet operations. +1. Funds need to be sent to the Avalanche L1 control key, which might have a zero balance due to fee payments. The Avalanche L1 control key requires funding to ensure proper support for Avalanche L1 operations. 2. Funds need to be moved from one Ledger address index to another. A Ledger manages an infinite sequence of addresses all derived from a master private key and can sign for any of those addresses. Each one is referred to by an index, or the associated address. Avalanche-CLI usually expects to use index 0, but sometimes, the funds are in a different index. Occasionally, a transfer made to a ledger can be made to an address different from the default one used by the CLI. To enable direct transfers between P-Chain addresses, use the command `avalanche key transfer`. This operation involves a series of import/export actions with the P-Chain and X-Chain. The fee for this operation is four times the typical import operation fee, which comes out to 0.004 AVAX. You can find more information about fees [here](/api-reference/standards/guides/txn-fees). @@ -19,7 +19,7 @@ This how-to guide focuses on transferring funds between ledger accounts. ## Prerequisites - [`Avalanche-CLI`](/tooling/guides/get-avalanche-cli) installed -- Multiple Ledger devices [configured for Avalanche](/subnets/deploy-a-subnet/avalanche-mainnet#setting-up-your-ledger) +- Multiple Ledger devices [configured for Avalanche](/avalanche-l1s/deploy-a-avalanche-l1/avalanche-mainnet#setting-up-your-ledger) Sending All Funds From One Ledger to Another[​](#example-sending-all-funds-from-one-ledger-to-another "Direct link to heading") ---------------------------------------------------------------------------------------------------------------------------------------- @@ -301,4 +301,4 @@ If this happen, the receiving operation should be started the same way, choosing avalanche key transfer --receive-recovery-step 1 ``` -Then, the CLI is going to resume where it left off. \ No newline at end of file +Then, the CLI is going to resume where it left off. diff --git a/content/docs/subnets/maintain/view-subnets.mdx b/content/docs/avalanche-l1s/maintain/view-avalanche-l1s.mdx similarity index 92% rename from content/docs/subnets/maintain/view-subnets.mdx rename to content/docs/avalanche-l1s/maintain/view-avalanche-l1s.mdx index 3a95b206f99..2529a808e1c 100644 --- a/content/docs/subnets/maintain/view-subnets.mdx +++ b/content/docs/avalanche-l1s/maintain/view-avalanche-l1s.mdx @@ -1,6 +1,6 @@ --- -title: View Subnets -description: Learn how to view Subnets deployed using Avalanche-CLI. +title: View Avalanche L1s +description: Learn how to view Avalanche L1s deployed using Avalanche-CLI. --- ```bash @@ -8,20 +8,20 @@ avalanche blockchain list # output +-------------+-------------+----------+---------------------------------------------------+------------+-----------+ -| SUBNET | CHAIN | CHAIN ID | VM ID | TYPE | FROM REPO | +| Avalanche L1 | CHAIN | CHAIN ID | VM ID | TYPE | FROM REPO | +-------------+-------------+----------+---------------------------------------------------+------------+-----------+ | test | test | 5234 | tGBrM2SXkAdNsqzb3SaFZZWMNdzjjFEUKteheTa4dhUwnfQyu | Subnet-EVM | false | +-------------+-------------+----------+---------------------------------------------------+------------+-----------+ ``` -To see detailed information about your deployed Subnets, add the `--deployed` flag: +To see detailed information about your deployed Avalanche L1s, add the `--deployed` flag: ```bash avalanche blockchain list --deployed # output +-------------+-------------+---------------------------------------------------+---------------+-----------------------------------------------------------------+---------+ -| SUBNET | CHAIN | VM ID | LOCAL NETWORK | FUJI (TESTNET) | MAINNET | +| Avalanche L1 | CHAIN | VM ID | LOCAL NETWORK | FUJI (TESTNET) | MAINNET | +-------------+-------------+---------------------------------------------------+---------------+-----------------------------------------------------------------+---------+ | test | test | tGBrM2SXkAdNsqzb3SaFZZWMNdzjjFEUKteheTa4dhUwnfQyu | Yes | SubnetID: XTK7AM2Pw5A4cCtQ3rTugqbeLCU9mVixML3YwwLYUJ4WXN2Kt | No | + + + + +-----------------------------------------------------------------+---------+ @@ -42,7 +42,7 @@ avalanche blockchain describe myblockchain +----------------------------+----------------------------------------------------+ | PARAMETER | VALUE | +----------------------------+----------------------------------------------------+ -| Subnet Name | myblockchain | +| Blockchain Name | myblockchain | +----------------------------+----------------------------------------------------+ | ChainID | 12345 | +----------------------------+----------------------------------------------------+ @@ -175,4 +175,4 @@ avalanche blockchain describe myblockchain --genesis "parentHash": "0x0000000000000000000000000000000000000000000000000000000000000000", "baseFeePerGas": null } -``` \ No newline at end of file +``` diff --git a/content/docs/avalanche-l1s/meta.json b/content/docs/avalanche-l1s/meta.json new file mode 100644 index 00000000000..6d4497efa87 --- /dev/null +++ b/content/docs/avalanche-l1s/meta.json @@ -0,0 +1,35 @@ +{ + "title": "Avalanche L1s", + "root": true, + "pages": [ + "---Avalanche L1s---", + "index", + "c-chain-or-avalanche-l1", + "build-first-avalanche-l1", + "avalanche-l1-nodes", + "---Deploy an Avalanche L1---", + "deploy-a-avalanche-l1/local-network", + "deploy-a-avalanche-l1/fuji-testnet", + "deploy-a-avalanche-l1/avalanche-mainnet", + "deploy-a-avalanche-l1/production-infrastructure", + "deploy-a-avalanche-l1/multisig-auth", + "deploy-a-avalanche-l1/custom-virtual-machine", + "---Elastic Avalanche L1s---", + "elastic-avalanche-l1s/make-avalanche-l1-permissionless", + "elastic-avalanche-l1s/parameters", + "---Maintain an Avalanche L1---", + "maintain/view-avalanche-l1s", + "maintain/pause-resume", + "maintain/delete-avalanche-l1", + "maintain/transfer-pchain-funds", + "---Add Utility on an Avalanche L1---", + "add-utility/deploy-smart-contract", + "add-utility/testnet-faucet", + "add-utility/cross-chain-bridge", + "---Upgrade an Avalanche L1---", + "...upgrade", + "---Miscellaneous---", + "wagmi-avalanche-l1", + "troubleshooting" + ] +} \ No newline at end of file diff --git a/content/docs/subnets/troubleshooting.mdx b/content/docs/avalanche-l1s/troubleshooting.mdx similarity index 95% rename from content/docs/subnets/troubleshooting.mdx rename to content/docs/avalanche-l1s/troubleshooting.mdx index 1210bddd08f..cf37cb19d87 100644 --- a/content/docs/subnets/troubleshooting.mdx +++ b/content/docs/avalanche-l1s/troubleshooting.mdx @@ -1,6 +1,6 @@ --- title: Troubleshooting -description: If you run into trouble deploying your Subnet, use this document for tips to resolve common issues. +description: If you run into trouble deploying your Avalanche L1, use this document for tips to resolve common issues. --- Deployment Times Out[​](#deployment-times-out "Direct link to heading") @@ -84,7 +84,7 @@ This error occurs when the RPCChainVM protocol version used by VMs like Subnet-E If your VM has an RPC version mismatch, you have two options: 1. Update the version of AvalancheGo you use in your VM. This is the correct long-term approach. -2. Use Avalanche-CLI to deploy an older version of AvalancheGo by using the `--avalanchego-version` flag. Both the [`blockchain deploy`](/tooling/avalanche-cli#subnet-deploy) and [`network start`](/tooling/avalanche-cli#network-start) commands support setting the AvalancheGo version explicitly. +2. Use Avalanche-CLI to deploy an older version of AvalancheGo by using the `--avalanchego-version` flag. Both the [`blockchain deploy`](/tooling/avalanche-cli#avalanche-l1-deploy) and [`network start`](/tooling/avalanche-cli#network-start) commands support setting the AvalancheGo version explicitly. Although it's very important to keep your version of AvalancheGo up-to-date, this workaround helps you avoid broken builds in the short term. @@ -136,4 +136,4 @@ This is because some Macs lack support for x86 binaries. Running the following c ```bash /usr/sbin/softwareupdate --install-rosetta -``` \ No newline at end of file +``` diff --git a/content/docs/subnets/upgrade/subnet-precompile-config.mdx b/content/docs/avalanche-l1s/upgrade/avalanche-l1-precompile-config.mdx similarity index 78% rename from content/docs/subnets/upgrade/subnet-precompile-config.mdx rename to content/docs/avalanche-l1s/upgrade/avalanche-l1-precompile-config.mdx index 20c4fd3085b..3119aa70d47 100644 --- a/content/docs/subnets/upgrade/subnet-precompile-config.mdx +++ b/content/docs/avalanche-l1s/upgrade/avalanche-l1-precompile-config.mdx @@ -1,44 +1,44 @@ --- -title: Subnet Precompile Config +title: Avalanche L1 Precompile Config description: Learn how to upgrade your Subnet-EVM precompile configuration. --- -You can customize Subnet-EVM based Subnets after deployment by enabling and disabling precompiles. To do this, create a `upgrade.json` file and place it in the appropriate directory. +You can customize Subnet-EVM based Avalanche L1s after deployment by enabling and disabling precompiles. To do this, create a `upgrade.json` file and place it in the appropriate directory. This document describes how to perform such network upgrades. It's specific for Subnet-EVM upgrades. -The document [Upgrade a Subnet](/subnets/upgrade/considerations) describes all the background information required regarding Subnet upgrades. +The document [Upgrade an Avalanche L1](/avalanche-l1s/upgrade/considerations) describes all the background information required regarding Avalanche L1 upgrades. It's very important that you have read and understood the previously linked document. Failing to do so can potentially grind your network to a halt. -This tutorial assumes that you have already [installed](/tooling/guides/get-avalanche-cli) Avalanche-CLI. It assumes you have already created and deployed a Subnet called `testSubnet`. +This tutorial assumes that you have already [installed](/tooling/guides/get-avalanche-cli) Avalanche-CLI. It assumes you have already created and deployed an Avalanche L1 called `testblockchain`. Generate the Upgrade File[​](#generate-the-upgrade-file "Direct link to heading") --------------------------------------------------------------------------------- -The [Precompiles](/subnets/upgrade/customize-subnet#network-upgrades-enabledisable-precompiles) documentation describes what files the network upgrade requires, and where to place them. +The [Precompiles](/avalanche-l1s/upgrade/customize-avalanche-l1#network-upgrades-enabledisable-precompiles) documentation describes what files the network upgrade requires, and where to place them. To generate a valid `upgrade.json` file, run: ```bash -avalanche blockchain upgrade generate testSubnet +avalanche blockchain upgrade generate testblockchain ``` -If you didn't create `testSubnet` yet, you would see this result: +If you didn't create `testblockchain` yet, you would see this result: ```bash -avalanche blockchain upgrade generate testSubnet -The provided subnet name "testSubnet" does not exist +avalanche blockchain upgrade generate testblockchain +The provided Avalanche L1 name "testblockchain" does not exist ``` -Again, it makes no sense to try the upgrade command if the Subnet doesn't exist. If that's the case, please go ahead and [create](/subnets/build-first-subnet) the Subnet first. +Again, it makes no sense to try the upgrade command if the Avalanche L1 doesn't exist. If that's the case, please go ahead and [create](/avalanche-l1s/build-first-avalanche-l1) the Avalanche L1 first. -If the Subnet definition exists, the tool launches a wizard. It may feel a bit redundant, but you first see some warnings, to draw focus to the dangers involved: +If the Avalanche L1 definition exists, the tool launches a wizard. It may feel a bit redundant, but you first see some warnings, to draw focus to the dangers involved: ```bash -avalanche blockchain upgrade generate testSubnet +avalanche blockchain upgrade generate testblockchain Performing a network upgrade requires coordinating the upgrade network-wide. A network upgrade changes the rule set used to process and verify blocks, such that any node that upgrades incorrectly or fails to upgrade by the time that upgrade goes into effect may become @@ -71,11 +71,11 @@ Use the arrow keys to navigate: ↓ ↑ → ← Transaction Allow List ``` -Refer to [Precompiles](/subnets/upgrade/customize-subnet#precompiles) for a description of available precompiles and how to configure them. +Refer to [Precompiles](/avalanche-l1s/upgrade/customize-avalanche-l1#precompiles) for a description of available precompiles and how to configure them. Make sure you understand precompiles thoroughly and how to configure them before attempting to continue. -For every precompile in the list, the wizard guides you to provide correct information by prompting relevant questions. For the sake of this tutorial, select `Transaction Allow List`. The document [Restricting Who Can Submit Transactions](/subnets/upgrade/customize-subnet#restricting-who-can-submit-transactions) describes what this precompile is about. +For every precompile in the list, the wizard guides you to provide correct information by prompting relevant questions. For the sake of this tutorial, select `Transaction Allow List`. The document [Restricting Who Can Submit Transactions](/avalanche-l1s/upgrade/customize-avalanche-l1#restricting-who-can-submit-transactions) describes what this precompile is about. ```bash ✔ Transaction Allow List @@ -117,7 +117,7 @@ Use the arrow keys to navigate: ↓ ↑ → ← This will enable the addresses added in this section to add other admins and/or add enabled addresses for transaction issuance. The addresses provided in this tutorial are fake. -However, make sure you or someone you trust have full control over the addresses. Otherwise, you might bring your Subnet to a halt. +However, make sure you or someone you trust have full control over the addresses. Otherwise, you might bring your Avalanche L1 to a halt. ```bash @@ -219,8 +219,8 @@ How To Upgrade a Local Network[​](#how-to-upgrade-a-local-network "Direct link The normal use case for this operation is that: -- You already created a Subnet -- You already deployed the Subnet locally +- You already created an Avalanche L1 +- You already deployed the Avalanche L1 locally - You already generated the upgrade file with the preceding command or imported into the tool - This tool already started the network @@ -229,20 +229,20 @@ If the preceding requirements aren't met, the network upgrade command fails. Therefore, to apply your generated or imported upgrade configuration: ```bash -avalanche blockchain upgrade apply testSubnet +avalanche blockchain upgrade apply testblockchain ``` -A number of checks run. For example, if you created the Subnet but didn't deploy it locally: +A number of checks run. For example, if you created the Avalanche L1 but didn't deploy it locally: ```bash -avalanche blockchain upgrade apply testSubnet +avalanche blockchain upgrade apply testblockchain Error: no deployment target available Usage: - avalanche blockchain upgrade apply [subnetName] [flags] + avalanche blockchain upgrade apply [blockchainName] [flags] Flags: --avalanchego-chain-config-dir string avalanchego's chain config file directory (default "/home/fabio/.avalanchego/chains") - --config create upgrade config for future subnet deployments (same as generate) + --config create upgrade config for future Avalanche L1 deployments (same as generate) --fuji fuji apply upgrade existing fuji deployment (alias for `testnet`) -h, --help help for apply --local local apply upgrade existing local deployment @@ -254,12 +254,12 @@ Global Flags: --log-level string log level for the application (default "ERROR") ``` -Go ahead and [deploy](/subnets/deploy-a-subnet/local-network) first your Subnet if that's your case. +Go ahead and [deploy](/avalanche-l1s/deploy-a-avalanche-l1/local-network) first your Avalanche L1 if that's your case. -If you already had deployed the Subnet instead, you see something like this: +If you already had deployed the Avalanche L1 instead, you see something like this: ```bash -avalanche blockchain upgrade apply testSubnet +avalanche blockchain upgrade apply testblockchain Use the arrow keys to navigate: ↓ ↑ → ← ? What deployment would you like to upgrade: ▸ Existing local deployment @@ -277,15 +277,15 @@ The next upgrade will go into effect 2023-03-31 09:00:00 +-------+------------+-----------------------------------------------------------------------------------+ | NODE | VM | URL | +-------+------------+-----------------------------------------------------------------------------------+ -| node1 | testSubnet | http://0.0.0.0:9650/ext/bc/2YTRV2roEhgvwJz7D7vr33hUZscpaZgcYgUTjeMK9KH99NFnsH/rpc | +| node1 | testblockchain | http://0.0.0.0:9650/ext/bc/2YTRV2roEhgvwJz7D7vr33hUZscpaZgcYgUTjeMK9KH99NFnsH/rpc | +-------+------------+-----------------------------------------------------------------------------------+ -| node2 | testSubnet | http://0.0.0.0:9652/ext/bc/2YTRV2roEhgvwJz7D7vr33hUZscpaZgcYgUTjeMK9KH99NFnsH/rpc | +| node2 | testblockchain | http://0.0.0.0:9652/ext/bc/2YTRV2roEhgvwJz7D7vr33hUZscpaZgcYgUTjeMK9KH99NFnsH/rpc | +-------+------------+-----------------------------------------------------------------------------------+ -| node3 | testSubnet | http://0.0.0.0:9654/ext/bc/2YTRV2roEhgvwJz7D7vr33hUZscpaZgcYgUTjeMK9KH99NFnsH/rpc | +| node3 | testblockchain | http://0.0.0.0:9654/ext/bc/2YTRV2roEhgvwJz7D7vr33hUZscpaZgcYgUTjeMK9KH99NFnsH/rpc | +-------+------------+-----------------------------------------------------------------------------------+ -| node4 | testSubnet | http://0.0.0.0:9656/ext/bc/2YTRV2roEhgvwJz7D7vr33hUZscpaZgcYgUTjeMK9KH99NFnsH/rpc | +| node4 | testblockchain | http://0.0.0.0:9656/ext/bc/2YTRV2roEhgvwJz7D7vr33hUZscpaZgcYgUTjeMK9KH99NFnsH/rpc | +-------+------------+-----------------------------------------------------------------------------------+ -| node5 | testSubnet | http://0.0.0.0:9658/ext/bc/2YTRV2roEhgvwJz7D7vr33hUZscpaZgcYgUTjeMK9KH99NFnsH/rpc | +| node5 | testblockchain | http://0.0.0.0:9658/ext/bc/2YTRV2roEhgvwJz7D7vr33hUZscpaZgcYgUTjeMK9KH99NFnsH/rpc | +-------+------------+-----------------------------------------------------------------------------------+ ``` @@ -294,12 +294,12 @@ There is only so much the tool can do here for you. It installed the upgrade byt Apply the Upgrade to a Public Node (Fuji or Mainnet)[​](#apply-the-upgrade-to-a-public-node-fuji-or-mainnet "Direct link to heading") ------------------------------------------------------------------------------------------------------------------------------------- -For this scenario to work, you should also have deployed the Subnet to the public network (Fuji or Mainnet) with this tool. Otherwise, the tool won't know the details of the Subnet, and won't be able to guide you. +For this scenario to work, you should also have deployed the Avalanche L1 to the public network (Fuji or Mainnet) with this tool. Otherwise, the tool won't know the details of the Avalanche L1, and won't be able to guide you. -Assuming the Subnet has been already deployed to Fuji, when running the `apply` command, the tool notices the deployment: +Assuming the Avalanche L1 has been already deployed to Fuji, when running the `apply` command, the tool notices the deployment: ```bash -avalanche blockchain upgrade apply testSubnet +avalanche blockchain upgrade apply testblockchain Use the arrow keys to navigate: ↓ ↑ → ← ? What deployment would you like to upgrade: Existing local deployment @@ -317,7 +317,7 @@ If this is the case, the tool tries to install the upgrade file at the expected If you are _not_ using default paths, you can configure the path by providing the flag `--avalanchego-chain-config-dir` to the tool. For example: ```bash -avalanche blockchain upgrade apply testSubnet --avalanchego-chain-config-dir /path/to/your/chains +avalanche blockchain upgrade apply testblockchain --avalanchego-chain-config-dir /path/to/your/chains ``` Make sure to identify correctly where your chain config dir is, or the node might fail to find it. @@ -325,7 +325,7 @@ Make sure to identify correctly where your chain config dir is, or the node migh If all is correct, the file gets installed: ```bash -avalanche blockchain upgrade apply testSubnet +avalanche blockchain upgrade apply testblockchain ✔ Fuji The chain config dir avalanchego uses is set at /home/fabio/.avalanchego/chains Trying to install the upgrade files at the provided /home/fabio/.avalanchego/chains path @@ -337,7 +337,7 @@ If however the node is _not_ running on this same machine where you are executin To see the instructions about how to go about this, add the `--print` flag: ```bash -avalanche blockchain upgrade apply testSubnet --print +avalanche blockchain upgrade apply testblockchain --print ✔ Fuji To install the upgrade file on your validator: @@ -377,16 +377,16 @@ Export the Upgrade File[​](#export-the-upgrade-file "Direct link to heading") If you have generated the upgrade file, you can export it: ```bash -avalanche blockchain upgrade export testSubnet -✔ Provide a path where we should export the file to: /tmp/testSubnet-upgrade.json +avalanche blockchain upgrade export testblockchain +✔ Provide a path where we should export the file to: /tmp/testblockchain-upgrade.json ``` Just provide a valid path to the prompt, and the tool exports the file there. ```bash -avalanche blockchain upgrade export testSubnet -Provide a path where we should export the file to: /tmp/testSubnet-upgrade.json -Writing the upgrade bytes file to "/tmp/testSubnet-upgrade.json"... +avalanche blockchain upgrade export testblockchain +Provide a path where we should export the file to: /tmp/testblockchain-upgrade.json +Writing the upgrade bytes file to "/tmp/testblockchain-upgrade.json"... File written successfully. ``` @@ -400,10 +400,10 @@ You or someone else might have generated the file elsewhere, or on another machi You can import the file: ```bash -avalanche blockchain upgrade import testSubnet -Provide the path to the upgrade file to import: /tmp/testSubnet-upgrade.json +avalanche blockchain upgrade import testblockchain +Provide the path to the upgrade file to import: /tmp/testblockchain-upgrade.json ``` An existing file with the same path and filename would be overwritten. -After you have imported the file, you can `apply` it either to a local network or to a locally running validator. Follow the instructions for the appropriate use case. \ No newline at end of file +After you have imported the file, you can `apply` it either to a local network or to a locally running validator. Follow the instructions for the appropriate use case. diff --git a/content/docs/subnets/upgrade/subnet-virtual-machine.mdx b/content/docs/avalanche-l1s/upgrade/avalanche-l1-virtual-machine.mdx similarity index 50% rename from content/docs/subnets/upgrade/subnet-virtual-machine.mdx rename to content/docs/avalanche-l1s/upgrade/avalanche-l1-virtual-machine.mdx index 58f1066cb0d..27c2fa283e2 100644 --- a/content/docs/subnets/upgrade/subnet-virtual-machine.mdx +++ b/content/docs/avalanche-l1s/upgrade/avalanche-l1-virtual-machine.mdx @@ -1,18 +1,18 @@ --- -title: Subnet Virtual Machine -description: This how-to guide explains how to upgrade an already-deployed Subnet. +title: Avalanche L1 Virtual Machine +description: This how-to guide explains how to upgrade an already-deployed Avalanche L1. --- Upgrading a Local VM[​](#upgrading-a-local-vm "Direct link to heading") ----------------------------------------------------------------------- -To upgrade a local Subnet, you first need to pause the local network. To do so, run: +To upgrade a local Avalanche L1, you first need to pause the local network. To do so, run: ```bash avalanche network stop ``` -Next, you need to select the new VM to run your Subnet on. If you're running a Subnet-EVM Subnet, you likely want to bump to the latest released version. If you're running a Custom VM, you'll want to choose another custom binary. +Next, you need to select the new VM to run your Avalanche L1 on. If you're running a Subnet-EVM Avalanche L1, you likely want to bump to the latest released version. If you're running a Custom VM, you'll want to choose another custom binary. Start the upgrade wizard with: @@ -20,11 +20,11 @@ Start the upgrade wizard with: avalanche blockchain upgrade vm ``` -where you replace `` with the name of the Subnet you would like to upgrade. +where you replace `` with the name of the Avalanche L1 you would like to upgrade. ### Selecting a VM Deployment to Upgrade[​](#selecting-a-vm-deployment-to-upgrade "Direct link to heading") -After starting the Subnet Upgrade Wizard, you should see something like this: +After starting the Avalanche L1 Upgrade Wizard, you should see something like this: ```bash ? What deployment would you like to upgrade: @@ -32,7 +32,7 @@ After starting the Subnet Upgrade Wizard, you should see something like this: Existing local deployment ``` -If you select the first option, Avalanche-CLI updates your Subnet's config and any future calls to `avalanche blockchain deploy` use the new version you select. However, any existing local deployments continue to use the old version. +If you select the first option, Avalanche-CLI updates your Avalanche L1's config and any future calls to `avalanche blockchain deploy` use the new version you select. However, any existing local deployments continue to use the old version. If you select the second option, the opposite occurs. The existing local deployment switches to the new VM but subsequent deploys use the original. @@ -41,13 +41,13 @@ If you select the second option, the opposite occurs. The existing local deploym The next option asks you to select your new virtual machine. ```bash -? How would you like to update your subnet's virtual machine: +? How would you like to update your Avalanche L1's virtual machine: ▸ Update to latest version Update to a specific version Update to a custom binary ``` -If you're using the Subnet-EVM, you'll have the option to upgrade to the latest released version. You can also select a specific version or supply a custom binary. If your Subnet already uses a custom VM, you need to select another custom binary. +If you're using the Subnet-EVM, you'll have the option to upgrade to the latest released version. You can also select a specific version or supply a custom binary. If your Avalanche L1 already uses a custom VM, you need to select another custom binary. Once you select your VM, you should see something like: @@ -58,7 +58,7 @@ Upgrade complete. Ready to restart the network. ### Restart the Network[​](#restart-the-network "Direct link to heading") -If you are running multiple Subnets concurrently, you may need to update multiple Subnets to restart the network. All of your deployed must be using the same RPC Protocol version. You can see more details about this [here](/subnets/troubleshooting#incompatible-rpc-version-for-custom-vm). +If you are running multiple Avalanche L1s concurrently, you may need to update multiple Avalanche L1s to restart the network. All of your deployed must be using the same RPC Protocol version. You can see more details about this [here](/avalanche-l1s/troubleshooting#incompatible-rpc-version-for-custom-vm). Finally, restart the network with: @@ -67,4 +67,4 @@ Finally, restart the network with: avalanche network start ``` -If the network starts correctly, your Subnet is now running the upgraded VM. \ No newline at end of file +If the network starts correctly, your Avalanche L1 is now running the upgraded VM. diff --git a/content/docs/avalanche-l1s/upgrade/considerations.mdx b/content/docs/avalanche-l1s/upgrade/considerations.mdx new file mode 100644 index 00000000000..8f4f25211bf --- /dev/null +++ b/content/docs/avalanche-l1s/upgrade/considerations.mdx @@ -0,0 +1,119 @@ +--- +title: Considerations +description: Learn about some of the key considerations while upgrading your Avalanche L1. +--- + +In the course of Avalanche L1 operation, you will inevitably need to upgrade or change some part of the software stack that is running your Avalanche L1. If nothing else, you will have to upgrade the AvalancheGo node client. Same goes for the VM plugin binary that is used to run the blockchain on your Avalanche L1, which is most likely the [Subnet-EVM](https://github.com/ava-labs/subnet-evm), the Avalanche L1 implementation of the Ethereum virtual machine. + +Node and VM upgrades usually don't change the way your Avalanche L1 functions, instead they keep your Avalanche L1 in sync with the rest of the network, bringing security, performance and feature upgrades. Most upgrades are optional, but all of them are recommended, and you should make optional upgrades part of your routine Avalanche L1 maintenance. Some upgrades will be mandatory, and those will be clearly communicated as such ahead of time, you need to pay special attention to those. + +Besides the upgrades due to new releases, you also may want to change the configuration of the VM, to alter the way Avalanche L1 runs, for various business or operational needs. These upgrades are solely the purview of your team, and you have complete control over the timing of their roll out. Any such change represents a **network upgrade** and needs to be carefully planned and executed. + + +Network Upgrades Permanently Change the Rules of Your Avalanche L1. Procedural mistakes or a botched upgrade can halt your Avalanche L1 or lead to data loss! + +When performing an Avalanche L1 upgrade, every single validator on the Avalanche L1 will need to perform the identical upgrade. + +If you are coordinating a network upgrade, you must schedule advance notice to every Avalanche L1 validator so that they have time to perform the upgrade prior to activation. Make sure you have direct line of communication to all your validators! + + +This tutorial will guide you through the process of doing various Avalanche L1 upgrades and changes. We will point out things to watch out for and precautions you need to be mindful about. + +General Upgrade Considerations[​](#general-upgrade-considerations "Direct link to heading") +------------------------------------------------------------------------------------------- + +When operating an Avalanche L1, you should always keep in mind that Proof of Stake networks like Avalanche can only make progress if sufficient amount of validating nodes are connected and processing transactions. Each validator on an Avalanche L1 is assigned a certain `weight`, which is a numerical value representing the significance of the node in consensus decisions. On the Primary Network, weight is equal to the amount of AVAX staked on the node. On Avalanche L1s, weight is currently assigned by the Avalanche L1 owners when they issue the transaction adding a validator to the Avalanche L1. + +Avalanche L1s can operate normally only if validators representing 80% or more of the cumulative validator weight is connected. If the amount of connected stake falls close to or below 80%, Avalanche L1 performance (time to finality) will suffer, and ultimately the Avalanche L1 will halt (stop processing transactions). + +You as an Avalanche L1 operator need to ensure that whatever you do, at least 80% of the validators' cumulative weight is connected and working at all times. + + +It is mandatory that the cumulative weight of all validators in the Avalanche L1 must be at least the value of [`snow-sample-size`](/nodes/configure/configs-flags#--snow-sample-size-int) (default 20). For example, if there is only one validator in the Avalanche L1, its weight must be at least `snow-sample-size` . Hence, when assigning weight to the nodes, always use values greater than 20. Recall that a validator's weight can't be changed while it is validating, so take care to use an appropriate value. + + +Upgrading Avalanche L1 Validator Nodes[​](#upgrading-avalanche-l1-validator-nodes "Direct link to heading") +----------------------------------------------------------------------------------------------- + +AvalancheGo, the node client that is running the Avalanche validators is under constant and rapid development. New versions come out often (roughly every two weeks), bringing added capabilities, performance improvements or security fixes. Updates are usually optional, but from time to time (much less frequently than regular updates) there will be an update that includes a mandatory network upgrade. Those upgrades are **MANDATORY** for every node running the Avalanche L1. Any node that does not perform the update before the activation timestamp will immediately stop working when the upgrade activates. + +That's why having a node upgrade strategy is absolutely vital, and you should always update to the latest AvalancheGo client immediately when it is made available. + +For a general guide on upgrading AvalancheGo check out [this tutorial](/nodes/maintain/upgrade). When upgrading Avalanche L1 nodes and keeping in mind the previous section, make sure to stagger node upgrades and start a new upgrade only once the previous node has successfully upgraded. Use the [Health API](/api-reference/health-api#healthhealth) to check that `healthy` value in the response is `true` on the upgraded node, and on other Avalanche L1 validators check that [platform.getCurrentValidators()](/api-reference/p-chain/api#platformgetcurrentvalidators) has `true` in `connected` attribute for the upgraded node's `nodeID`. Once those two conditions are satisfied, node is confirmed to be online and validating the Avalanche L1 and you can start upgrading another node. + +Continue the upgrade cycle until all the Avalanche L1 nodes are upgraded. + +Upgrading Avalanche L1 VM Plugin Binaries[​](#upgrading-avalanche-l1-vm-plugin-binaries "Direct link to heading") +----------------------------------------------------------------------------------------------------- + +Besides the AvalancheGo client itself, new versions get released for the VM binaries that run the blockchains on the Avalanche L1. On most Avalanche L1s, that is the [Subnet-EVM](https://github.com/ava-labs/subnet-evm), so this tutorial will go through the steps for updating the `subnet-evm` binary. The update process will be similar for updating any VM plugin binary. + +All the considerations for doing staggered node upgrades as discussed in previous section are valid for VM upgrades as well. + +In the future, VM upgrades will be handled by the [Avalanche-CLI tool](https://github.com/ava-labs/avalanche-cli), but for now we need to do it manually. + +Go to the [releases page](https://github.com/ava-labs/subnet-evm/releases) of the Subnet-EVM repository. Locate the latest version, and copy link that corresponds to the OS and architecture of the machine the node is running on (`darwin` = Mac, `amd64` = Intel/AMD processor, `arm64` = Arm processor). Log into the machine where the node is running and download the archive, using `wget` and the link to the archive, like this: + +```bash +wget https://github.com/ava-labs/subnet-evm/releases/download/v0.2.9/subnet-evm_0.2.9_linux_amd64.tar.gz +``` + +This will download the archive to the machine. Unpack it like this (use the correct filename, of course): + +```bash +tar xvf subnet-evm_0.2.9_linux_amd64.tar.gz +``` + +This will unpack and place the contents of the archive in the current directory, file `subnet-evm` is the plugin binary. You need to stop the node now (if the node is running as a service, use `sudo systemctl stop avalanchego` command). You need to place that file into the plugins directory where the AvalancheGo binary is located. If the node is installed using the install script, the path will be `~/avalanche-node/plugins` Instead of the `subnet-evm` filename, VM binary needs to be named as the VM ID of the chain on the Avalanche L1. For example, for the [WAGMI Avalanche L1](https://subnets-test.avax.network/wagmi) that VM ID is `srEXiWaHuhNyGwPUi444Tu47ZEDwxTWrbQiuD7FmgSAQ6X7Dy`. So, the command to copy the new plugin binary would look like: + +```bash +cp subnet-evm ~/avalanche-node/plugins/srEXiWaHuhNyGwPUi444Tu47ZEDwxTWrbQiuD7FmgSAQ6X7Dy +``` + + +Make sure you use the correct VM ID, otherwise, your VM will not get updated and your Avalanche L1 may halt. + + +After you do that, you can start the node back up (if running as service do `sudo systemctl start avalanchego`). You can monitor the log output on the node to check that everything is OK, or you can use the [info.getNodeVersion()](/api-reference/info-api#infogetnodeversion) API to check the versions. Example output would look like: + +```json +{ + "jsonrpc": "2.0", + "result": { + "version": "avalanche/1.7.18", + "databaseVersion": "v1.4.5", + "gitCommit": "b6d5827f1a87e26da649f932ad649a4ea0e429c4", + "vmVersions": { + "avm": "v1.7.18", + "evm": "v0.8.15", + "platform": "v1.7.18", + "sqja3uK17MJxfC7AN8nGadBw9JK5BcrsNwNynsqP5Gih8M5Bm": "v0.0.7", + "srEXiWaHuhNyGwPUi444Tu47ZEDwxTWrbQiuD7FmgSAQ6X7Dy": "v0.2.9" + } + }, + "id": 1 +} +``` + +Note that entry next to the VM ID we upgraded correctly says `v0.2.9`. You have successfully upgraded the VM! + +Refer to the previous section on how to make sure node is healthy and connected before moving on to upgrading the next Avalanche L1 validator. + +If you don't get the expected result, you can stop the `AvalancheGo`, examine and follow closely step-by-step of the above. You are free to remove files under `~/avalanche-node/plugins`, however, you should keep in mind that removing files is to remove an existing VM binary. You must put the correct VM plugin in place before you restart AvalancheGo. + +Network Upgrades[​](#network-upgrades "Direct link to heading") +--------------------------------------------------------------- + +Sometimes you need to do a network upgrade to change the configured rules in the genesis under which the Chain operates. In regular EVM, network upgrades are a pretty involved process that includes deploying the new EVM binary, coordinating the timed upgrade and deploying changes to the nodes. But since [Subnet-EVM v0.2.8](https://github.com/ava-labs/subnet-evm/releases/tag/v0.2.8), we introduced the long awaited feature to perform network upgrades by just using a few lines of JSON. Upgrades can consist of enabling/disabling particular precompiles, or changing their parameters. Currently available precompiles allow you to: + +- Restrict Smart Contract Deployers +- Restrict Who Can Submit Transactions +- Mint Native Coins +- Configure Dynamic Fees + +Please refer to [Customize an Avalanche L1](/avalanche-l1s/upgrade/customize-avalanche-l1#network-upgrades-enabledisable-precompiles) for a detailed discussion of possible precompile upgrade parameters. + +Summary[​](#summary "Direct link to heading") +--------------------------------------------- + +Vital part of Avalanche L1 maintenance is performing timely upgrades at all levels of the software stack running your Avalanche L1. We hope this tutorial will give you enough information and context to allow you to do those upgrades with confidence and ease. If you have additional questions or any issues, please reach out to us on [Discord](https://chat.avalabs.org/). diff --git a/content/docs/subnets/upgrade/customize-subnet.mdx b/content/docs/avalanche-l1s/upgrade/customize-avalanche-l1.mdx similarity index 94% rename from content/docs/subnets/upgrade/customize-subnet.mdx rename to content/docs/avalanche-l1s/upgrade/customize-avalanche-l1.mdx index 454c41c0151..12729021563 100644 --- a/content/docs/subnets/upgrade/customize-subnet.mdx +++ b/content/docs/avalanche-l1s/upgrade/customize-avalanche-l1.mdx @@ -1,29 +1,29 @@ --- -title: Customize a Subnet -description: Learn how to customize your EVM-powered Subnet. +title: Customize an Avalanche L1 +description: Learn how to customize your EVM-powered Avalanche L1. --- -All Subnets can be customized by utilizing [`Subnet Configs`](#subnet-configs). +All Avalanche L1s can be customized by utilizing [`Subnet Configs`](#avalanche-l1-configs). -A Subnet can have one or more blockchains. For example, the Primary Network, which is a Subnet, a special one nonetheless, has 3 blockchains. Each chain can be further customized using chain specific configuration file. See [here](/nodes/configure/configs-flags) for detailed explanation. +an Avalanche L1 can have one or more blockchains. For example, the Primary Network, which is an Avalanche L1, a special one nonetheless, has 3 blockchains. Each chain can be further customized using chain specific configuration file. See [here](/nodes/configure/configs-flags) for detailed explanation. -A blockchain created by or forked from [Subnet-EVM](https://github.com/ava-labs/subnet-evm) can be customized by utilizing one or more of the following methods: +An Avalanche L1 created by or forked from [Subnet-EVM](https://github.com/ava-labs/subnet-evm) can be customized by utilizing one or more of the following methods: - [Genesis](#genesis) - [Precompile](#precompiles) - [Upgrade Configs](#network-upgrades-enabledisable-precompiles) - [Chain Configs](#avalanchego-chain-configs) -Subnet Configs[​](#subnet-configs "Direct link to heading") +Avalanche L1 Configs[​](#avalanche-l1-configs "Direct link to heading") ----------------------------------------------------------- -A Subnet can customized by setting parameters for the following: +an Avalanche L1 can customized by setting parameters for the following: -- [Validator-only communication to create a private Subnet](/nodes/configure/subnet-configs#validatoronly-bool) -- [Consensus](/nodes/configure/subnet-configs#consensus-parameters) -- [Gossip](/nodes/configure/subnet-configs#gossip-configs) +- [Validator-only communication to create a private Avalanche L1](/nodes/configure/avalanche-l1-configs#validatoronly-bool) +- [Consensus](/nodes/configure/avalanche-l1-configs#consensus-parameters) +- [Gossip](/nodes/configure/avalanche-l1-configs#gossip-configs) -See [here](/nodes/configure/subnet-configs) for more info. +See [here](/nodes/configure/avalanche-l1-configs) for more info. Genesis[​](#genesis "Direct link to heading") --------------------------------------------- @@ -209,7 +209,7 @@ With `allowFeeRecipients` enabled, your validators can specify their addresses t ``` -If `allowFeeRecipients` feature is enabled on the Subnet, but a validator doesn't specify a "feeRecipient", the fees will be burned in blocks it produces. +If `allowFeeRecipients` feature is enabled on the Avalanche L1, but a validator doesn't specify a "feeRecipient", the fees will be burned in blocks it produces. This mechanism can be also activated as a precompile. See [Changing Fee Reward Mechanisms](#changing-fee-reward-mechanisms) section for more details. @@ -277,7 +277,7 @@ Note: `AllowList` is not an actual contract but just an interface. It's not call ### Restricting Smart Contract Deployers[​](#restricting-smart-contract-deployers "Direct link to heading") -If you'd like to restrict who has the ability to deploy contracts on your Subnet, you can provide an `AllowList` configuration in your genesis or upgrade file: +If you'd like to restrict who has the ability to deploy contracts on your Avalanche L1, you can provide an `AllowList` configuration in your genesis or upgrade file: ```json { @@ -668,7 +668,7 @@ If `allowFeeRecipients` and `rewardAddress` are both specified in the `initialRe ### Avalanche Warp Messaging[​](#avalanche-warp-messaging "Direct link to heading") -Warp Precompile enabled cross-subnet communication between other Subnets and primary-network (C-Chain). In order to use Warp messaging, Subnet-EVM chains must activate their Warp precompiles. Warp can be activated with the following lines in upgrade.json: +Warp Precompile enabled cross-blockchain communication between other Layer 1s and primary-network (C-Chain). In order to use Warp messaging, Subnet-EVM chains must activate their Warp precompiles. Warp can be activated with the following lines in upgrade.json: ```json { @@ -684,7 +684,7 @@ Warp Precompile enabled cross-subnet communication between other Subnets and pri If you want to use Warp messaging in an existing Subnet-EVM chain, you should coordinate an upgrade with `upgrade.json`. See [Network Upgrades: Enable/Disable Precompiles](#network-upgrades-enabledisable-precompiles) for more information. -Currently Warp Precompile can only be activated in Mainnet after Durango occurs. Durango in Mainnet is set at 11 AM ET (4 PM UTC) on Wednesday, March 6th, 2024. If you plan to use Warp messaging in your own Subnet-EVM chain in Mainnet you should upgrade to `[[email protected]](https://docs.avax.network/cdn-cgi/l/email-protection)` or later and coordinate your precompile upgrade. Warp Config's "blockTimestamp" must be set after `1709740800`, Durango date (11 AM ET (4 PM UTC) on Wednesday, March 6th, 2024). +Currently Warp Precompile can only be activated in Mainnet after Durango occurs. Durango in Mainnet is set at 11 AM ET (4 PM UTC) on Wednesday, March 6th, 2024. If you plan to use Warp messaging in your own Subnet-EVM chain in Mainnet you should upgrade to AvalancheGo 1.11.11 or later and coordinate your precompile upgrade. Warp Config's "blockTimestamp" must be set after `1709740800`, Durango date (11 AM ET (4 PM UTC) on Wednesday, March 6th, 2024). Contract Examples[​](#contract-examples "Direct link to heading") @@ -782,7 +782,7 @@ This example enables the `feeManagerConfig` at the first block with timestamp >= When a precompile disable takes effect (that is, after its `blockTimestamp` has passed), its storage will be wiped. If you want to reenable it, you will need to treat it as a new configuration. -After you have created the `upgrade.json` and placed it in the chain config directory, you need to restart the node for the upgrade file to be loaded (again, make sure you don't restart all Subnet validators at once!). On node restart, it will print out the configuration of the chain, where you can double-check that the upgrade has loaded correctly. In our example: +After you have created the `upgrade.json` and placed it in the chain config directory, you need to restart the node for the upgrade file to be loaded (again, make sure you don't restart all Avalanche L1 validators at once!). On node restart, it will print out the configuration of the chain, where you can double-check that the upgrade has loaded correctly. In our example: ```bash INFO [08-15|15:09:36.772] <2ebCneCbwthjQ1rYT41nhd7M76Hc6YmosMAQrTFhBq8qeqh6tt Chain> @@ -792,12 +792,12 @@ Constantinople: 0 Petersburg: 0 Istanbul: 0, Muir Glacier: 0, Subnet EVM: 0, Fee {\“gasLimit\“:20000000,\“targetBlockRate\“:2,\“minBaseFee\“:1000000000,\“targetGas\ “:100000000,\“baseFeeChangeDenominator\“:48,\“minBlockGasCost\“:0,\“maxBlockGasCost\ “:10000000,\“blockGasCostStep\“:500000}, AllowFeeRecipients: false, NetworkUpgrades: {\ -“subnetEVMTimestamp\“:0}, PrecompileUpgrade: {}, UpgradeConfig: {\"precompileUpgrades\":[{\"feeManagerConfig\":{\"adminAddresses\":[\"0x8db97c7cece249c2b98bdc0226cc4c2a57bf52fc\"],\"enabledAddresses\":null,\"blockTimestamp\":1668950000}},{\"txAllowListConfig\":{\"adminAddresses\":[\"0x8db97c7cece249c2b98bdc0226cc4c2a57bf52fc\"],\"enabledAddresses\":null,\"blockTimestamp\":1668960000}},{\"feeManagerConfig\":{\"adminAddresses\":null,\"enabledAddresses\":null,\"blockTimestamp\":1668970000,\"disable\":true}}]}, Engine: Dummy Consensus Engine}"” +“subnetEVMTimestamp\“:0}, PrecompileUpgrade: {}, UpgradeConfig: {\"precompileUpgrades\":[{\"feeManagerConfig\":{\"adminAddresses\":[\"0x8db97c7cece249c2b98bdc0226cc4c2a57bf52fc\"],\"enabledAddresses\":null,\"blockTimestamp\":1668950000}},{\"txAllowListConfig\":{\"adminAddresses\":[\"0x8db97c7cece249c2b98bdc0226cc4c2a57bf52fc\"],\"enabledAddresses\":null,\"blockTimestamp\":1668960000}},{\"feeManagerConfig\":{\"adminAddresses\":null,\"enabledAddresses\":null,\"blockTimestamp\":1668970000,\"disable\":true}}]}, Engine: Dummy Consensus Engine}" ``` Notice that `precompileUpgrades` entry correctly reflects the changes. You can also check the activated precompiles at a timestamp with the [`eth_getActivePrecompilesAt`](/api-reference/subnet-evm-api#eth_getactiveprecompilesat) RPC method. The [`eth_getChainConfig`](/api-reference/subnet-evm-api#eth_getchainconfig) RPC method will also return the configured upgrades in the response. -That's it, your Subnet is all set and the desired upgrades will be activated at the indicated timestamp! +That's it, your Avalanche L1 is all set and the desired upgrades will be activated at the indicated timestamp! ### Initial Precompile Configurations[​](#initial-precompile-configurations "Direct link to heading") @@ -857,15 +857,15 @@ See every precompile initial configuration in their relevant `Initial Configurat AvalancheGo Chain Configs[​](#avalanchego-chain-configs "Direct link to heading") --------------------------------------------------------------------------------- -As described in [this doc](/nodes/configure/configs-flags#subnet-chain-configs), each blockchain of Subnets can have its own custom configuration. If a Subnet's ChainID is `2ebCneCbwthjQ1rYT41nhd7M76Hc6YmosMAQrTFhBq8qeqh6tt`, the config file for this chain is located at `{chain-config-dir}/2ebCneCbwthjQ1rYT41nhd7M76Hc6YmosMAQrTFhBq8qeqh6tt/config.json`. +As described in [this doc](/nodes/configure/configs-flags#avalanche-l1-chain-configs), each blockchain of Avalanche L1s can have its own custom configuration. If an Avalanche L1's ChainID is `2ebCneCbwthjQ1rYT41nhd7M76Hc6YmosMAQrTFhBq8qeqh6tt`, the config file for this chain is located at `{chain-config-dir}/2ebCneCbwthjQ1rYT41nhd7M76Hc6YmosMAQrTFhBq8qeqh6tt/config.json`. -For blockchains created by or forked from Subnet-EVM, most [C-Chain configs](/nodes/configure/chain-configs/c-chain) are applicable except [Avalanche Specific APIs](/nodes/configure/chain-configs/c-chain#enabling-avalanche-specific-apis). +For blockchains created by or forked from Subnet-EVM, most [C-Chain configs](/nodes/chain-configs/c-chain) are applicable except [Avalanche Specific APIs](/nodes/chain-configs/c-chain#enabling-avalanche-specific-apis). ### Priority Regossip[​](#priority-regossip "Direct link to heading") A transaction is "regossiped" when the node does not find the transaction in a block after `priority-regossip-frequency` (defaults to `1m`). By default, up to 16 transactions (max 1 per address) are regossiped to validators per minute. -Operators can use "priority regossip" to more aggressively "regossip" transactions for a set of important addresses (like bridge relayers). To do so, you'll need to update your [chain config](/nodes/configure/configs-flags#subnet-chain-configs) with the following: +Operators can use "priority regossip" to more aggressively "regossip" transactions for a set of important addresses (like bridge relayers). To do so, you'll need to update your [chain config](/nodes/configure/configs-flags#avalanche-l1-chain-configs) with the following: ```json { @@ -897,7 +897,7 @@ With `allowFeeRecipients` enabled, validators can specify their addresses to col ``` -If `allowFeeRecipients` or `RewardManager` precompile is enabled on the Subnet, but a validator doesn't specify a "feeRecipient", the fees will be burned in blocks it produces. +If `allowFeeRecipients` or `RewardManager` precompile is enabled on the Avalanche L1, but a validator doesn't specify a "feeRecipient", the fees will be burned in blocks it produces. Network Upgrades: State Upgrades[​](#network-upgrades-state-upgrades "Direct link to heading") @@ -996,3 +996,4 @@ Nodes running non-compatible version (running pre-Durango version after Durango All of network nodes, even ones correctly upgraded to Durango and running the correct version since Durango activation, should be restarted with the new upgrade.json to reschedule the Durango activation. This is a network-wide operation and should be coordinated with all network nodes. + diff --git a/content/docs/subnets/upgrade/durango-upgrade.mdx b/content/docs/avalanche-l1s/upgrade/durango-upgrade.mdx similarity index 94% rename from content/docs/subnets/upgrade/durango-upgrade.mdx rename to content/docs/avalanche-l1s/upgrade/durango-upgrade.mdx index 6e5e1cbdb45..e067d0a4e98 100644 --- a/content/docs/subnets/upgrade/durango-upgrade.mdx +++ b/content/docs/avalanche-l1s/upgrade/durango-upgrade.mdx @@ -15,14 +15,14 @@ Durango introduces following changes to Subnet-EVM: - Events in Precompiles - Manager Role - Non-Strict Mode -- [Shanghai Upgrade from ACP-24](https://github.com/avalanche-foundation/ACPs/blob/main/ACPs/24-shanghai-eips.md) will be activated with Durango without any further modification in Subnet-EVM. +- [Shanghai Upgrade from ACP-24](https://github.com/avalanche-foundation/ACPs/tree/main/ACPs/24-shanghai-eips) will be activated with Durango without any further modification in Subnet-EVM. Avalanche Warp Messaging[​](#avalanche-warp-messaging "Direct link to heading") ------------------------------------------------------------------------------- -Avalanche Warp Messaging (AWM) is a new feature introduced with the Durango network upgrade. It enables native cross-Subnet communication and allows [Virtual Machine (VM)](/learn/virtual-machines) developers to implement arbitrary communication protocols between any two Subnets. For more information about AWM see [here](/cross-chain/avalanche-warp-messaging/overview). +Avalanche Warp Messaging (AWM) is a new feature introduced with the Durango network upgrade. It enables native cross-Avalanche L1 communication and allows [Virtual Machine (VM)](/learn/virtual-machines) developers to implement arbitrary communication protocols between any two Avalanche L1s. For more information about AWM see [here](/cross-chain/avalanche-warp-messaging/overview). -Warp Precompile must be enabled for Subnets after Durango. For more information the precompile and activation see [here](/subnets/upgrade/customize-subnet#avalanche-warp-messaging) +Warp Precompile must be enabled for Avalanche L1s after Durango. For more information the precompile and activation see [here](/avalanche-l1s/upgrade/customize-avalanche-l1#avalanche-warp-messaging) Events[​](#events "Direct link to heading") ------------------------------------------- @@ -145,7 +145,7 @@ stateDB.AddLog( Manager Role[​](#manager-role "Direct link to heading") ------------------------------------------------------- -Durango introduces a new role called the manager role. The manager role is a mid-role between `Admin` and `Enabled`. The manager role is considered as an `Enabled` account and perform restricted state-changing operations in precompiles. Manager role also can modify other `Enabled` accounts. It can appoint new `Enabled` accounts and remove existing `Enabled` accounts. Manager role cannot modify other `Manager` or `Admin` accounts. For more information about AllowList see [here](/subnets/upgrade/customize-subnet#allowlist-interface). +Durango introduces a new role called the manager role. The manager role is a mid-role between `Admin` and `Enabled`. The manager role is considered as an `Enabled` account and perform restricted state-changing operations in precompiles. Manager role also can modify other `Enabled` accounts. It can appoint new `Enabled` accounts and remove existing `Enabled` accounts. Manager role cannot modify other `Manager` or `Admin` accounts. For more information about AllowList see [here](/avalanche-l1s/upgrade/customize-avalanche-l1#allowlist-interface). If you have any precompile using AllowList, you can issue a call to `setManager` in your precompile to appoint new Manager accounts. For upgrades or new precompiles with AllowList config you can use `managerAddresses` as follow: @@ -222,4 +222,4 @@ This will ensure that non-strict mode unpacking is used after Durango activation This should not impose any critical issue for your custom precompiles. If you want to keep using the old strict mode and keep the backward compatibility you can use `true` for the `useStrictMode` parameter. -However if your precompile is mainly used from other deployed contracts (Solidity) you should do this transition in order to increase the compatibility of your precompile. \ No newline at end of file +However if your precompile is mainly used from other deployed contracts (Solidity) you should do this transition in order to increase the compatibility of your precompile. diff --git a/content/docs/subnets/wagmi-subnet.mdx b/content/docs/avalanche-l1s/wagmi-avalanche-l1.mdx similarity index 72% rename from content/docs/subnets/wagmi-subnet.mdx rename to content/docs/avalanche-l1s/wagmi-avalanche-l1.mdx index ef877598985..c5fd2816162 100644 --- a/content/docs/subnets/wagmi-subnet.mdx +++ b/content/docs/avalanche-l1s/wagmi-avalanche-l1.mdx @@ -1,13 +1,13 @@ --- -title: WAGMI Subnet -description: Learn about the WAGMI Subnet in this detailed case study. +title: WAGMI Avalanche L1 +description: Learn about the WAGMI Avalanche L1 in this detailed case study. --- -This is one of the first cases of using Avalanche Subnets as a proving ground for changes in a production VM (Coreth). Many underestimate how useful the isolation of Subnets is for performing complex VM testing on a live network (without impacting the stability of the primary network). +This is one of the first cases of using Avalanche L1s as a proving ground for changes in a production VM (Coreth). Many underestimate how useful the isolation of Avalanche L1s is for performing complex VM testing on a live network (without impacting the stability of the primary network). -We created a basic WAGMI Explorer [https://subnets-test.avax.network/wagmi](https://subnets-test.avax.network/wagmi) that surfaces aggregated usage statistics about the Subnet. +We created a basic WAGMI Explorer [https://subnets-test.avax.network/wagmi](https://subnets-test.avax.network/wagmi) that surfaces aggregated usage statistics about the Avalanche L1. -- SubnetID: [28nrH5T2BMvNrWecFcV3mfccjs6axM1TVyqe79MCv2Mhs8kxiY](https://explorer-xp.avax-test.network/subnet/28nrH5T2BMvNrWecFcV3mfccjs6axM1TVyqe79MCv2Mhs8kxiY?tab=validators) +- SubnetID: [28nrH5T2BMvNrWecFcV3mfccjs6axM1TVyqe79MCv2Mhs8kxiY](https://explorer-xp.avax-test.network/avalanche-l1/28nrH5T2BMvNrWecFcV3mfccjs6axM1TVyqe79MCv2Mhs8kxiY?tab=validators) - ChainID: [2ebCneCbwthjQ1rYT41nhd7M76Hc6YmosMAQrTFhBq8qeqh6tt](https://testnet.avascan.info/blockchain/2ebCneCbwthjQ1rYT41nhd7M76Hc6YmosMAQrTFhBq8qeqh6tt) ### Network Parameters[​](#network-parameters "Direct link to heading") @@ -25,7 +25,7 @@ The genesis file of WAGMI can be found [here](https://github.com/ava-labs/public - Network Name: WAGMI - RPC URL: [https://subnets.avax.network/wagmi/wagmi-chain-testnet/rpc] -- WS URL: wss://subnets.avax.network/wagmi/wagmi-chain-testnet/ws +- WS URL: wss://avalanche-l1s.avax.network/wagmi/wagmi-chain-testnet/ws - Chain ID: 11111 - Symbol: WGM - Explorer: [https://subnets.avax.network/wagmi/wagmi-chain-testnet/explorer] @@ -37,17 +37,17 @@ This can be used with other wallets too, such as MetaMask. Case Study: WAGMI Upgrades[​](#case-study-wagmi-upgrades "Direct link to heading") ---------------------------------------------------------------------------------- -This case study uses [WAGMI](https://subnets-test.avax.network/wagmi) Subnet upgrade to show how a network upgrade on an EVM-based (Ethereum Virtual Machine) Subnet can be done simply, and how the resulting upgrade can be used to dynamically control fee structure on the Subnet. +This case study uses [WAGMI](https://subnets-test.avax.network/wagmi) Avalanche L1 upgrade to show how a network upgrade on an EVM-based (Ethereum Virtual Machine) Avalanche L1 can be done simply, and how the resulting upgrade can be used to dynamically control fee structure on the Avalanche L1. ### Introduction[​](#introduction "Direct link to heading") -[Subnet-EVM](https://github.com/ava-labs/subnet-evm) aims to provide an easy to use toolbox to customize the EVM for your blockchain. It is meant to run out of the box for many Subnets without any modification. But what happens when you want to add a new feature updating the rules of your EVM? +[Subnet-EVM](https://github.com/ava-labs/subnet-evm) aims to provide an easy to use toolbox to customize the EVM for your blockchain. It is meant to run out of the box for many Avalanche L1s without any modification. But what happens when you want to add a new feature updating the rules of your EVM? Instead of hard coding the timing of network upgrades in client code like most EVM chains, requiring coordinated deployments of new code, [Subnet-EVM v0.2.8](https://github.com/ava-labs/subnet-evm/releases/tag/v0.2.8) introduces the long awaited feature to perform network upgrades by just using a few lines of JSON in a configuration file. ### Network Upgrades: Enable/Disable Precompiles[​](#network-upgrades-enabledisable-precompiles "Direct link to heading") -Detailed description of how to do this can be found in [Customize a Subnet](/subnets/upgrade/customize-subnet#network-upgrades-enabledisable-precompiles) tutorial. Here's a summary: +Detailed description of how to do this can be found in [Customize an Avalanche L1](/avalanche-l1s/upgrade/customize-avalanche-l1#network-upgrades-enabledisable-precompiles) tutorial. Here's a summary: 1. Network Upgrade utilizes existing precompiles on the Subnet-EVM: - ContractDeployerAllowList, for restricting smart contract deployers @@ -56,7 +56,7 @@ Detailed description of how to do this can be found in [Customize a Subnet](/sub - FeeManager, for configuring dynamic fees - RewardManager, for enabling block rewards 2. Each of these precompiles can be individually enabled or disabled at a given timestamp as a network upgrade, or any of the parameters governing its behavior changed. -3. These upgrades must be specified in a file named `upgrade.json` placed in the same directory where [`config.json`](/subnets/upgrade/customize-subnet#avalanchego-chain-configs) resides: `{chain-config-dir}/{blockchainID}/upgrade.json`. +3. These upgrades must be specified in a file named `upgrade.json` placed in the same directory where [`config.json`](/avalanche-l1s/upgrade/customize-avalanche-l1#avalanchego-chain-configs) resides: `{chain-config-dir}/{blockchainID}/upgrade.json`. ### Preparation[​](#preparation "Direct link to heading") @@ -98,7 +98,7 @@ With the above `upgrade.json`, we intend to perform two network upgrades: - `0xadFA2910DC148674910c07d18DF966A28CD21331` is named as the new Manager of the NativeMinter precompile. Manager addresses are enabled after Durango upgrades which occurred on February 13, 2024. - `1708696800` is the [Unix timestamp](https://www.unixtimestamp.com/) for Fri Feb 23 2024 14:00:00 GMT+0000 (future time when we made the announcement) when the new NativeMinter change would take effect. -Detailed explanations of feeManagerConfig can be found in [here](/subnets/upgrade/customize-subnet#configuring-dynamic-fees), and for the contractNativeMinterConfig in [here](/subnets/upgrade/customize-subnet#minting-native-coins). +Detailed explanations of feeManagerConfig can be found in [here](/avalanche-l1s/upgrade/customize-avalanche-l1#configuring-dynamic-fees), and for the contractNativeMinterConfig in [here](/avalanche-l1s/upgrade/customize-avalanche-l1#minting-native-coins). We place the `upgrade.json` file in the chain config directory, which in our case is `~/.avalanchego/configs/chains/2ebCneCbwthjQ1rYT41nhd7M76Hc6YmosMAQrTFhBq8qeqh6tt/`. After that, we restart the node so the upgrade file is loaded. @@ -118,9 +118,9 @@ For the second upgrade on February 23, 2024, the same process was followed. The ### Using Fee Manager[​](#using-fee-manager "Direct link to heading") -The owner `0x6f0f6DA1852857d7789f68a28bba866671f3880D` can now configure the fees on the Subnet as they see fit. To do that, all that's needed is access to the network, the private key for the newly set manager address and making calls on the precompiled contract. +The owner `0x6f0f6DA1852857d7789f68a28bba866671f3880D` can now configure the fees on the Avalanche L1 as they see fit. To do that, all that's needed is access to the network, the private key for the newly set manager address and making calls on the precompiled contract. -We will use [Remix](https://remix.ethereum.org/) online Solidity IDE and the [Core Browser Extension](https://support.avax.network/en/articles/6066879-core-extension-how-do-i-add-the-core-extension). Core comes with WAGMI network built-in. MetaMask will do as well but you will need to [add WAGMI](/subnets/wagmi-case-study#adding-wagmi-to-core) yourself. +We will use [Remix](https://remix.ethereum.org/) online Solidity IDE and the [Core Browser Extension](https://support.avax.network/en/articles/6066879-core-extension-how-do-i-add-the-core-extension). Core comes with WAGMI network built-in. MetaMask will do as well but you will need to [add WAGMI](/avalanche-l1s/wagmi-avalanche-l1) yourself. First using Core, we open the account as the owner `0x6f0f6DA1852857d7789f68a28bba866671f3880D`. @@ -136,22 +136,22 @@ We then switch to WAGMI in the networks dropdown. We are ready to move on to Rem ![Injected provider](/images/wagmi3.png) -Good, we're talking to WAGMI Subnet. Next we need to load the contracts into Remix. Using 'load from GitHub' option from the Remix home screen we load two contracts: +Good, we're talking to WAGMI Avalanche L1. Next we need to load the contracts into Remix. Using 'load from GitHub' option from the Remix home screen we load two contracts: - [IAllowList.sol](https://github.com/ava-labs/subnet-evm/blob/master/contracts/contracts/interfaces/IAllowList.sol) -- and [IFeeManager.sol](https://github.com/ava-labs/subnet-evm/blob/master/contract/contracts/interfaces/IFeeManager.sol). +- and [IFeeManager.sol](https://github.com/ava-labs/subnet-evm/blob/master/contracts/contracts/interfaces/IFeeManager.sol). -IFeeManager is our precompile, but it references the IAllowList, so we need that one as well. We compile IFeeManager.sol and use deployed contract at the precompile address `0x0200000000000000000000000000000000000003` used on the [Subnet](https://github.com/ava-labs/subnet-evm/blob/master/precompile/contracts/feemanager/module.go#L21). +IFeeManager is our precompile, but it references the IAllowList, so we need that one as well. We compile IFeeManager.sol and use deployed contract at the precompile address `0x0200000000000000000000000000000000000003` used on the [Avalanche L1](https://github.com/ava-labs/subnet-evm/blob/master/precompile/contracts/feemanager/module.go#L21). ![Deployed contract](/images/wagmi4.png) Now we can interact with the FeeManager precompile from within Remix via Core. For example, we can use the `getFeeConfig` method to check the current fee configuration. This action can be performed by anyone as it is just a read operation. -Once we have the new desired configuration for the fees on the Subnet, we can use the `setFeeConfig` to change the parameters. This action can **only** be performed by the owner `0x6f0f6DA1852857d7789f68a28bba866671f3880D` as the `adminAddress` specified in the [`upgrade.json` above](#deploying-upgradejson). +Once we have the new desired configuration for the fees on the Avalanche L1, we can use the `setFeeConfig` to change the parameters. This action can **only** be performed by the owner `0x6f0f6DA1852857d7789f68a28bba866671f3880D` as the `adminAddress` specified in the [`upgrade.json` above](#deploying-upgradejson). ![setFeeConfig](/images/wagmi5.png) -When we call that method by pressing the `transact` button, a new transaction is posted to the Subnet, and we can see it on [the explorer](https://subnets-test.avax.network/wagmi/block/0xad95ccf04f6a8e018ece7912939860553363cc23151a0a31ea429ba6e60ad5a3): +When we call that method by pressing the `transact` button, a new transaction is posted to the Avalanche L1, and we can see it on [the explorer](https://subnets-test.avax.network/wagmi/block/0xad95ccf04f6a8e018ece7912939860553363cc23151a0a31ea429ba6e60ad5a3): ![transaction](/images/wagmi6.png) @@ -163,22 +163,22 @@ That's it, fees changed! No network upgrades, no complex and risky deployments, ### Using NativeMinter[​](#using-nativeminter "Direct link to heading") -For the NativeMinter, we can use the same process to connect to the Subnet and interact with the precompile. We can load INativeMinter interface using 'load from GitHub' option from the Remix home screen with following contracts: +For the NativeMinter, we can use the same process to connect to the Avalanche L1 and interact with the precompile. We can load INativeMinter interface using 'load from GitHub' option from the Remix home screen with following contracts: - [IAllowList.sol](https://github.com/ava-labs/subnet-evm/blob/master/contracts/contracts/interfaces/IAllowList.sol) - and [INativeMinter.sol](https://github.com/ava-labs/subnet-evm/blob/master/contracts/contracts/interfaces/INativeMinter.sol). -We can compile them and interact with the deployed contract at the precompile address `0x0200000000000000000000000000000000000001` used on the [Subnet](https://github.com/ava-labs/subnet-evm/blob/master/precompile/contracts/nativeminter/module.go#L22). +We can compile them and interact with the deployed contract at the precompile address `0x0200000000000000000000000000000000000001` used on the [Avalanche L1](https://github.com/ava-labs/subnet-evm/blob/master/precompile/contracts/nativeminter/module.go#L22). ![Deployed contract](/images/wagmi8.png) -The native minter precompile is used to mint native coins to specified addresses. The minted coins is added to the current supply and can be used by the recipient to pay for gas fees. For more information about the native minter precompile see [here](/subnets/upgrade/customize-subnet#minting-native-coins). +The native minter precompile is used to mint native coins to specified addresses. The minted coins is added to the current supply and can be used by the recipient to pay for gas fees. For more information about the native minter precompile see [here](/avalanche-l1s/upgrade/customize-avalanche-l1#minting-native-coins). `mintNativeCoin` method can be only called by enabled, manager and admin addresses. For this upgrade we have added both an admin and a manager address in [`upgrade.json` above](#deploying-upgradejson). The manager address was available after Durango upgrades which occurred on February 13, 2024. We will use the manager address `0xadfa2910dc148674910c07d18df966a28cd21331` to mint native coins. ![mintNativeCoin](/images/wagmi9.png) -When we call that method by pressing the `transact` button, a new transaction is posted to the Subnet, and we can see it on [the explorer](https://subnets-test.avax.network/wagmi/tx/0xc4aaba7b5863c1b8f6664ac1d483e2d7d392ab58d1a8feb0b6c318cbae7f1e93): +When we call that method by pressing the `transact` button, a new transaction is posted to the Avalanche L1, and we can see it on [the explorer](https://subnets-test.avax.network/wagmi/tx/0xc4aaba7b5863c1b8f6664ac1d483e2d7d392ab58d1a8feb0b6c318cbae7f1e93): ![tx](/images/wagmi10.png) @@ -186,6 +186,6 @@ As a result of this transaction, the native minter precompile minted a new nativ ### Conclusion[​](#conclusion "Direct link to heading") -Network upgrades can be complex and perilous procedures to carry out safely. Our continuing efforts with Subnets is to make upgrades as painless and simple as possible. With the powerful combination of stateful precompiles and network upgrades via the upgrade configuration files we have managed to greatly simplify both the network upgrades and network parameter changes. This in turn enables much safer experimentation and many new use cases that were too risky and complex to carry out with high-coordination efforts required with the traditional network upgrade mechanisms. +Network upgrades can be complex and perilous procedures to carry out safely. Our continuing efforts with Avalanche L1s is to make upgrades as painless and simple as possible. With the powerful combination of stateful precompiles and network upgrades via the upgrade configuration files we have managed to greatly simplify both the network upgrades and network parameter changes. This in turn enables much safer experimentation and many new use cases that were too risky and complex to carry out with high-coordination efforts required with the traditional network upgrade mechanisms. -We hope this case study will help spark ideas for new things you may try on your own. We're looking forward to seeing what you have built and how easy upgrades help you in managing your Subnets! If you have any questions or issues, feel free to contact us on our [Discord](https://chat.avalabs.org/). Or just reach out to tell us what exciting new things you have built! \ No newline at end of file +We hope this case study will help spark ideas for new things you may try on your own. We're looking forward to seeing what you have built and how easy upgrades help you in managing your Avalanche L1s! If you have any questions or issues, feel free to contact us on our [Discord](https://chat.avalabs.org/). Or just reach out to tell us what exciting new things you have built! diff --git a/content/docs/cross-chain/avalanche-warp-messaging/deep-dive.mdx b/content/docs/cross-chain/avalanche-warp-messaging/deep-dive.mdx index ea1dab37908..02dc8e37251 100644 --- a/content/docs/cross-chain/avalanche-warp-messaging/deep-dive.mdx +++ b/content/docs/cross-chain/avalanche-warp-messaging/deep-dive.mdx @@ -1,15 +1,16 @@ --- title: Deep Dive into AWM +description: Learn about Avalanche Warp Messaging, a cross-blockchain communication protocol on Avalanche. --- -Avalanche Warp Messaging (AWM) provides a primitive for cross-subnet communication on the Avalanche Network. -The Avalanche P-Chain provides an index of every Subnet's validator set on the Avalanche Network, including the BLS public key of each validator (as of the [Banff Upgrade](https://github.com/ava-labs/avalanchego/releases/v1.9.0)). AWM utilizes the weighted validator sets stored on the P-Chain to build a cross-subnet communication protocol between any two Subnets on the Avalanche Network. +Avalanche Warp Messaging (AWM) provides a primitive for cross-blockchain communication on the Avalanche Network. -Any Virtual Machine (VM) on Avalanche can integrate Avalanche Warp Messaging to send and receive messages across Avalanche Subnets. +The Avalanche P-Chain provides an index of every Avalanche L1's validator set on the Avalanche Network, including the BLS public key of each validator (as of the [Banff Upgrade](https://github.com/ava-labs/avalanchego/releases/v1.9.0)). AWM utilizes the weighted validator sets stored on the P-Chain to build a cross-blockchain communication protocol between any two Layer 1s on the Avalanche Network. -Background[​](#background "Direct link to heading") ---------------------------------------------------- +Any Virtual Machine (VM) on Avalanche can integrate Avalanche Warp Messaging to send and receive messages across Avalanche Layer 1s. + +## Background This README assumes familiarity with: @@ -17,20 +18,17 @@ This README assumes familiarity with: - [ProposerVM](https://github.com/ava-labs/avalanchego/tree/master/vms/proposervm/README.md) - Basic familiarity with [BLS Multi-Signatures](https://crypto.stanford.edu/~dabo/pubs/papers/BLSmultisig.html) -BLS Multi-Signatures with Public-Key Aggregation[​](#bls-multi-signatures-with-public-key-aggregation "Direct link to heading") -------------------------------------------------------------------------------------------------------------------------------- +## BLS Multi-Signatures with Public-Key Aggregation -Avalanche Warp Messaging utilizes BLS multi-signatures with public key aggregation in order to verify messages signed by another Subnet. When a validator joins a Subnet, the P-Chain records the validator's BLS public key and NodeID, as well as a proof of possession of the validator's BLS private key to defend against [rogue public-key attacks](https://crypto.stanford.edu/~dabo/pubs/papers/BLSmultisig.html#mjx-eqn-eqaggsame). +Avalanche Warp Messaging utilizes BLS multi-signatures with public key aggregation in order to verify messages signed by another Blockchain. When a validator joins an Avalanche L1, the P-Chain records the validator's BLS public key and NodeID, as well as a proof of possession of the validator's BLS private key to defend against [rogue public-key attacks](https://crypto.stanford.edu/~dabo/pubs/papers/BLSmultisig.html#mjx-eqn-eqaggsame). -AWM utilizes the validator set's weights and public keys to verify that an aggregate signature has sufficient weight signing the message from the source Subnet. +AWM utilizes the validator set's weights and public keys to verify that an aggregate signature has sufficient weight signing the message from the source Avalanche L1. BLS provides a way to aggregate signatures off chain into a single signature that can be efficiently verified on chain. -AWM Serialization[​](#awm-serialization "Direct link to heading") ------------------------------------------------------------------ +## AWM Serialization Unsigned Message: - ``` +-----------------+----------+--------------------------+ | network_id : uint32 | 4 bytes | @@ -47,8 +45,8 @@ Unsigned Message: - `sourceChainID` is the hash of the transaction that created the blockchain on the Avalanche P-Chain. It serves as the unique identifier for the blockchain across the Avalanche Network so that each blockchain can only sign a message with its own id. - `payload` provides an arbitrary byte array containing the contents of the message. VMs define their own message types to include in the `payload` -BitSetSignature: +BitSetSignature: ``` +-----------+----------+---------------------------+ | type_id : uint32 | 4 bytes | @@ -65,12 +63,11 @@ BitSetSignature: - `signers` encodes a bitset of which validators' signatures are included (a bitset is a byte array where each bit indicates membership of the element at that index in the set) - `signature` is an aggregated BLS Multi-Signature of the Unsigned Message -BitSetSignatures are verified within the context of a specific P-Chain height. At any given P-Chain height, the PlatformVM serves a canonically ordered validator set for the source subnet (validator set is ordered lexicographically by the BLS public key's byte representation). The `signers` bitset encodes which validator signatures were included. A value of `1` at index `i` in `signers` bitset indicates that a corresponding signature from the same validator at index `i` in the canonical validator set was included in the aggregate signature. +BitSetSignatures are verified within the context of a specific P-Chain height. At any given P-Chain height, the PlatformVM serves a canonically ordered validator set for the source Avalanche L1 (validator set is ordered lexicographically by the BLS public key's byte representation). The `signers` bitset encodes which validator signatures were included. A value of `1` at index `i` in `signers` bitset indicates that a corresponding signature from the same validator at index `i` in the canonical validator set was included in the aggregate signature. The bitset tells the verifier which BLS public keys should be aggregated to verify the warp message. Signed Message: - ``` +------------------+------------------+-------------------------------------------------+ | unsigned_message : UnsignedMessage | size(unsigned_message) | @@ -81,40 +78,37 @@ Signed Message: +-------------------------------------------------+ ``` -Sending an Avalanche Warp Message[​](#sending-an-avalanche-warp-message "Direct link to heading") -------------------------------------------------------------------------------------------------- +## Sending an Avalanche Warp Message -A blockchain on Avalanche sends an Avalanche Warp Message by coming to agreement on the message that every validator should be willing to sign. As an example, the VM of a blockchain may define that once a block is accepted, the VM should be willing to sign a message including the block hash in the payload to attest to any other Subnet that the block was accepted. The contents of the payload, how to aggregate the signature (VM-to-VM communication, off-chain relayer, etc.), is left to the VM. +A blockchain on Avalanche sends an Avalanche Warp Message by coming to agreement on the message that every validator should be willing to sign. As an example, the VM of a blockchain may define that once a block is accepted, the VM should be willing to sign a message including the block hash in the payload to attest to any other Avalanche L1 that the block was accepted. The contents of the payload, how to aggregate the signature (VM-to-VM communication, off-chain relayer, etc.), is left to the VM. Once the validator set of a blockchain is willing to sign an arbitrary message `M`, an aggregator performs the following process: -1. Gather signatures of the message `M` from `N` validators (where the `N` validators meet the required threshold of stake on the destination chain) -2. Aggregate the `N` signatures into a multi-signature -3. Look up the canonical validator set at the P-Chain height where the message will be verified -4. Encode the selection of the `N` validators included in the signature in a bitset -5. Construct the signed message from the aggregate signature, bitset, and original unsigned message +1. Gather signatures of the message `M` from `N` validators (where the `N` validators meet the required threshold of stake on the destination chain) +2. Aggregate the `N` signatures into a multi-signature +3. Look up the canonical validator set at the P-Chain height where the message will be verified +4. Encode the selection of the `N` validators included in the signature in a bitset +5. Construct the signed message from the aggregate signature, bitset, and original unsigned message -Verifying / Receiving an Avalanche Warp Message[​](#verifying--receiving-an-avalanche-warp-message "Direct link to heading") ----------------------------------------------------------------------------------------------------------------------------- +## Verifying / Receiving an Avalanche Warp Message -Avalanache Warp Messages are verified within the context of a specific P-Chain height included in the [ProposerVM](https://github.com/ava-labs/avalanchego/tree/master/vms/proposervm/README.md)'s header. The P-Chain height is provided as context to the underlying VM when verifying the underlying VM's blocks (implemented by the optional interface [WithVerifyContext](https://github.com/ava-labs/avalanchego/tree/master/snow/engine/snowman/block/block_context_vm.go)). +Avalanche Warp Messages are verified within the context of a specific P-Chain height included in the [ProposerVM](https://github.com/ava-labs/avalanchego/tree/master/vms/proposervm/README.md)'s header. The P-Chain height is provided as context to the underlying VM when verifying the underlying VM's blocks (implemented by the optional interface [WithVerifyContext](https://github.com/ava-labs/avalanchego/tree/master/snow/engine/snowman/block/block_context_vm.go)). To verify the message, the underlying VM utilizes this `warp` package to perform the following steps: -1. Lookup the canonical validator set of the Subnet sending the message at the P-Chain height -2. Filter the canonical validator set to only the validators claimed by the signature -3. Verify the weight of the included validators meets the required threshold defined by the receiving VM -4. Aggregate the public keys of the claimed validators into a single aggregate public key -5. Verify the aggregate signature of the unsigned message against the aggregate public key +1. Lookup the canonical validator set of the Avalanche L1 sending the message at the P-Chain height +2. Filter the canonical validator set to only the validators claimed by the signature +3. Verify the weight of the included validators meets the required threshold defined by the receiving VM +4. Aggregate the public keys of the claimed validators into a single aggregate public key +5. Verify the aggregate signature of the unsigned message against the aggregate public key Once a message is verified, it is left to the VM to define the semantics of delivering a verified message. -Design Considerations[​](#design-considerations "Direct link to heading") -------------------------------------------------------------------------- +## Design Considerations -### Processing Historical Avalanche Warp Messages[​](#processing-historical-avalanche-warp-messages "Direct link to heading") +### Processing Historical Avalanche Warp Messages -Verifying an Avalanche Warp Message requires a lookup of validator sets at a specific P-Chain height. The P-Chain serves lookups maintaining validator set diffs that can be applied in-order to reconstruct the validator set of any Subnet at any height. +Verifying an Avalanche Warp Message requires a lookup of validator sets at a specific P-Chain height. The P-Chain serves lookups maintaining validator set diffs that can be applied in-order to reconstruct the validator set of any Avalanche L1 at any height. As the P-Chain grows, the number of validator set diffs that needs to be applied in order to reconstruct the validator set needed to verify an Avalanche Warp Messages increases over time. @@ -127,4 +121,6 @@ Therefore, the new bootstrapping node can assume the block was valid to determin Two strategies to provide that mechanism are: - Require warp message validity for transaction inclusion. If the transaction is included, the warp message must have passed verification. -- Include the results of warp message verification in the block itself. Use the results to determine which messages passed verification. \ No newline at end of file +- Include the results of warp message verification in the block itself. Use the results to determine which messages passed verification. + + diff --git a/content/docs/cross-chain/avalanche-warp-messaging/evm-integration.mdx b/content/docs/cross-chain/avalanche-warp-messaging/evm-integration.mdx index 6431f9ae48f..60f22a86a97 100644 --- a/content/docs/cross-chain/avalanche-warp-messaging/evm-integration.mdx +++ b/content/docs/cross-chain/avalanche-warp-messaging/evm-integration.mdx @@ -1,36 +1,37 @@ --- title: Integration with EVM +description: Avalanche Warp Messaging provides a basic primitive for signing and verifying messages between Blockchains. --- -Avalanche Warp Messaging offers a basic primitive to enable Cross-Subnet communication on the Avalanche Network. + +Avalanche Warp Messaging offers a basic primitive to enable Cross-Layer 1 communication on the Avalanche Network. It is intended to allow communication between arbitrary Custom Virtual Machines (including, but not limited to Subnet-EVM and Coreth). -How does Avalanche Warp Messaging Work?[​](#how-does-avalanche-warp-messaging-work "Direct link to heading") ------------------------------------------------------------------------------------------------------------- +## How does Avalanche Warp Messaging Work? Avalanche Warp Messaging uses BLS Multi-Signatures with Public-Key Aggregation where every Avalanche validator registers a public key alongside its NodeID on the Avalanche P-Chain. -Every node tracking a Subnet has read access to the Avalanche P-Chain. This provides weighted sets of BLS Public Keys that correspond to the validator sets of each Subnet on the Avalanche Network. Avalanche Warp Messaging provides a basic primitive for signing and verifying messages between Subnets: the receiving network can verify whether an aggregation of signatures from a set of source Subnet validators represents a threshold of stake large enough for the receiving network to process the message. +Every node tracking an Avalanche L1 has read access to the Avalanche P-Chain. This provides weighted sets of BLS Public Keys that correspond to the validator sets of each Avalanche L1 on the Avalanche Network. Avalanche Warp Messaging provides a basic primitive for signing and verifying messages between Layer 1s: the receiving network can verify whether an aggregation of signatures from a set of source blockchain validators represents a threshold of stake large enough for the receiving network to process the message. For more details on Avalanche Warp Messaging, see the AvalancheGo [Warp README](/cross-chain/avalanche-warp-messaging/deep-dive). -### Flow of Sending / Receiving a Warp Message within the EVM[​](#flow-of-sending--receiving-a-warp-message-within-the-evm "Direct link to heading") +### Flow of Sending / Receiving a Warp Message within the EVM The Avalanche Warp Precompile enables this flow to send a message from blockchain A to blockchain B: -1. Call the Warp Precompile `sendWarpMessage` function with the arguments for the `UnsignedMessage` -2. Warp Precompile emits an event / log containing the `UnsignedMessage` specified by the caller of `sendWarpMessage` -3. Network accepts the block containing the `UnsignedMessage` in the log, so that validators are willing to sign the message -4. An off-chain relayer queries the validators for their signatures of the message and aggregates the signatures to create a `SignedMessage` -5. The off-chain relayer encodes the `SignedMessage` as the [predicate](#predicate-encoding) in the AccessList of a transaction to deliver on blockchain B -6. The transaction is delivered on blockchain B, the signature is verified prior to executing the block, and the message is accessible via the Warp Precompile's `getVerifiedWarpMessage` during the execution of that transaction +1. Call the Warp Precompile `sendWarpMessage` function with the arguments for the `UnsignedMessage` +2. Warp Precompile emits an event / log containing the `UnsignedMessage` specified by the caller of `sendWarpMessage` +3. Network accepts the block containing the `UnsignedMessage` in the log, so that validators are willing to sign the message +4. An off-chain relayer queries the validators for their signatures of the message and aggregates the signatures to create a `SignedMessage` +5. The off-chain relayer encodes the `SignedMessage` as the [predicate](#predicate-encoding) in the AccessList of a transaction to deliver on blockchain B +6. The transaction is delivered on blockchain B, the signature is verified prior to executing the block, and the message is accessible via the Warp Precompile's `getVerifiedWarpMessage` during the execution of that transaction -### Warp Precompile[​](#warp-precompile "Direct link to heading") +### Warp Precompile The Warp Precompile is broken down into three functions defined in the Solidity interface file [here](https://github.com/ava-labs/coreth/blob/master/contracts/contracts/interfaces/IWarpMessenger.sol). -#### sendWarpMessage[​](#sendwarpmessage "Direct link to heading") +#### sendWarpMessage `sendWarpMessage` is used to send a verifiable message. Calling this function results in sending a message with the following contents: @@ -49,7 +50,7 @@ Additionally, the `SourceChainID` is excluded because anyone parsing the chain c The actual `message` is the entire [Avalanche Warp Unsigned Message](https://github.com/ava-labs/avalanchego/blob/master/vms/platformvm/warp/unsigned_message.go#L14) including an [AddressedCall](https://github.com/ava-labs/avalanchego/tree/master/vms/platformvm/warp/payload#readme). The unsigned message is emitted as the unindexed data in the log. -#### getVerifiedMessage[​](#getverifiedmessage "Direct link to heading") +#### getVerifiedMessage `getVerifiedMessage` is used to read the contents of the delivered Avalanche Warp Message into the expected format. @@ -59,12 +60,12 @@ To use this function, the transaction must include the signed Avalanche Warp Mes This leads to the following advantages: -1. The EVM execution does not need to verify the Warp Message at runtime (no signature verification or external calls to the P-Chain) -2. The EVM can deterministically re-execute and re-verify blocks assuming the predicate was verified by the network (eg., in bootstrapping) +1. The EVM execution does not need to verify the Warp Message at runtime (no signature verification or external calls to the P-Chain) +2. The EVM can deterministically re-execute and re-verify blocks assuming the predicate was verified by the network (eg., in bootstrapping) This pre-verification is performed using the ProposerVM Block header during [block verification](https://github.com/ava-labs/coreth/blob/master/plugin/evm/block.go#L220) and [block building](https://github.com/ava-labs/coreth/blob/master/miner/worker.go#L200). -#### getBlockchainID[​](#getblockchainid "Direct link to heading") +#### getBlockchainID `getBlockchainID` returns the blockchainID of the blockchain that the VM is running on. @@ -72,7 +73,7 @@ This is different from the conventional Ethereum ChainID registered to [ChainLis The `blockchainID` in Avalanche refers to the txID that created the blockchain on the Avalanche P-Chain ([docs](/api-reference/p-chain/txn-format#unsigned-create-chain-tx)). -### Predicate Encoding[​](#predicate-encoding "Direct link to heading") +### Predicate Encoding Avalanche Warp Messages are encoded as a signed Avalanche [Warp Message](https://github.com/ava-labs/avalanchego/blob/master/vms/platformvm/warp/message.go) where the [UnsignedMessage](https://github.com/ava-labs/avalanchego/blob/master/vms/platformvm/warp/unsigned_message.go)'s payload includes an [AddressedPayload](https://github.com/ava-labs/avalanchego/blob/master/vms/platformvm/warp/payload/payload.go). @@ -80,38 +81,37 @@ Since the predicate is encoded into the [Transaction Access List](https://eips.e Therefore, we use the [Predicate Utils](https://github.com/ava-labs/coreth/blob/master/predicate/Predicate.md) package to encode the actual byte slice of size N into the access list. -### Performance Optimization: C-Chain to Subnet[​](#performance-optimization-c-chain-to-subnet "Direct link to heading") +### Performance Optimization: C-Chain to Avalanche L1 -To support C-Chain to Subnet communication, or more generally Primary Network to Subnet communication, we special case the C-Chain for two reasons: +To support C-Chain to Avalanche L1 communication, or more generally Primary Network to Avalanche L1 communication, we special case the C-Chain for two reasons: -1. Every Subnet validator validates the C-Chain -2. The Primary Network has the largest possible number of validators +1. Every Avalanche L1 validator validates the C-Chain +2. The Primary Network has the largest possible number of validators -Since the Primary Network has the largest possible number of validators for any Subnet on Avalanche, it would also be the most expensive Subnet to receive and verify Avalanche Warp Messages from as it reaching a threshold of stake on the primary network would require many signatures. Luckily, we can do something much smarter. +Since the Primary Network has the largest possible number of validators for any Layer 1 on Avalanche, it would also be the most expensive Layer 1 to receive and verify Avalanche Warp Messages from as it reaching a threshold of stake on the primary network would require many signatures. Luckily, we can do something much smarter. -When a Subnet receives a message from a blockchain on the Primary Network, we use the validator set of the receiving Subnet instead of the entire network when validating the message. This means that the C-Chain sending a message can be the exact same as Subnet to Subnet communication. +When an Avalanche L1 receives a message from a blockchain on the Primary Network, we use the validator set of the receiving Avalanche L1 instead of the entire network when validating the message. This means that the C-Chain sending a message can be the exact same as Avalanche L1 to Avalanche L1 communication. -However, when Subnet B receives a message from the C-Chain, it changes the semantics to the following: +However, when Layer 1 B receives a message from the C-Chain, it changes the semantics to the following: -1. Read the SourceChainID of the signed message (C-Chain) -2. Look up the SubnetID that validates C-Chain: Primary Network -3. Look up the validator set of Subnet B (instead of the Primary Network) and the registered BLS Public Keys of Subnet B at the P-Chain height specified by the ProposerVM header -4. Continue Warp Message verification using the validator set of Subnet B instead of the Primary Network +1. Read the SourceChainID of the signed message (C-Chain) +2. Look up the SubnetID that validates C-Chain: Primary Network +3. Look up the validator set of Avalanche L1 B (instead of the Primary Network) and the registered BLS Public Keys of Avalanche L1 B at the P-Chain height specified by the ProposerVM header +4. Continue Warp Message verification using the validator set of Avalanche L1 B instead of the Primary Network -This means that C-Chain to Subnet communication only requires a threshold of stake on the receiving subnet to sign the message instead of a threshold of stake for the entire Primary Network. +This means that C-Chain to Avalanche L1 communication only requires a threshold of stake on the receiving Avalanche L1 to sign the message instead of a threshold of stake for the entire Primary Network. -This assumes that the security of Subnet B already depends on the validators of Subnet B to behave virtuously. Therefore, requiring a threshold of stake from the receiving Subnet's validator set instead of the whole Primary Network does not meaningfully change security of the receiving Subnet. +This assumes that the security of Layer 1 B already depends on the validators of Layer 1 B to behave virtuously. Therefore, requiring a threshold of stake from the receiving Avalanche L1's validator set instead of the whole Primary Network does not meaningfully change security of the receiving Blockchain. Note: this special case is ONLY applied during Warp Message verification. The message sent by the Primary Network will still contain the Avalanche C-Chain's blockchainID as the sourceChainID and signatures will be served by querying the C-Chain directly. -Design Considerations[​](#design-considerations "Direct link to heading") -------------------------------------------------------------------------- +## Design Considerations -### Re-Processing Historical Blocks[​](#re-processing-historical-blocks "Direct link to heading") +### Re-Processing Historical Blocks Avalanche Warp Messaging depends on the Avalanche P-Chain state at the P-Chain height specified by the ProposerVM block header. -Verifying a message requires looking up the validator set of the source subnet on the P-Chain. To support this, Avalanche Warp Messaging uses the ProposerVM header, which includes the P-Chain height it was issued at as the canonical point to lookup the source subnet's validator set. +Verifying a message requires looking up the validator set of the source Avalanche L1 on the P-Chain. To support this, Avalanche Warp Messaging uses the ProposerVM header, which includes the P-Chain height it was issued at as the canonical point to lookup the source Avalanche L1's validator set. This means verifying the Warp Message and therefore the state transition on a block depends on state that is external to the blockchain itself: the P-Chain. @@ -123,8 +123,8 @@ As a result, we require that the block itself provides a deterministic hint whic To provide that hint, we've explored two designs: -1. Include a predicate in the transaction to ensure any referenced message is valid -2. Append the results of checking whether a Warp Message is valid/invalid to the block data itself +1. Include a predicate in the transaction to ensure any referenced message is valid +2. Append the results of checking whether a Warp Message is valid/invalid to the block data itself The current implementation uses option (1). @@ -136,9 +136,9 @@ Therefore, a transaction specified predicate is required to implement the shared In contrast, Avalanche Warp Messages are validated within the context of an exact P-Chain height. Therefore, if a block producer attempted to lie about the validity of such a message, the network would interpret that block as invalid. -### Guarantees Offered by Warp Precompile vs. Built on Top[​](#guarantees-offered-by-warp-precompile-vs-built-on-top "Direct link to heading") +### Guarantees Offered by Warp Precompile vs. Built on Top -#### Guarantees Offered by Warp Precompile[​](#guarantees-offered-by-warp-precompile "Direct link to heading") +#### Guarantees Offered by Warp Precompile The Warp Precompile was designed with the intention of minimizing the trusted computing base for the VM as much as possible. Therefore, it makes several tradeoffs which encourage users to use protocols built ON TOP of the Warp Precompile itself as opposed to directly using the Warp Precompile. @@ -146,10 +146,11 @@ The Warp Precompile itself provides ONLY the following ability: - Emit a verifiable message from (Address A, Blockchain A) to (Address B, Blockchain B) that can be verified by the destination chain -#### Explicitly Not Provided / Built on Top[​](#explicitly-not-provided--built-on-top "Direct link to heading") +#### Explicitly Not Provided / Built on Top The Warp Precompile itself does not provide any guarantees of: - Eventual message delivery (may require re-send on blockchain A and additional assumptions about off-chain relayers and chain progress) - Ordering of messages (requires ordering provided a layer above) -- Replay protection (requires replay protection provided a layer above) \ No newline at end of file +- Replay protection (requires replay protection provided a layer above) + diff --git a/content/docs/cross-chain/avalanche-warp-messaging/overview.mdx b/content/docs/cross-chain/avalanche-warp-messaging/overview.mdx index 03d78a14f08..5ffc5d0ed7a 100644 --- a/content/docs/cross-chain/avalanche-warp-messaging/overview.mdx +++ b/content/docs/cross-chain/avalanche-warp-messaging/overview.mdx @@ -3,46 +3,46 @@ title: What is AWM? description: Learn about Avalanche Warp Messaging, a protocol for cross-chain communication. --- -Avalanche Warp Messaging (AWM) enables native cross-Subnet communication and allows [Virtual Machine (VM)](/learn/virtual-machines) developers to implement arbitrary communication protocols between any two Subnets. +Avalanche Warp Messaging (AWM) enables native cross-Avalanche L1 communication and allows [Virtual Machine (VM)](/learn/virtual-machines) developers to implement arbitrary communication protocols between any two Avalanche L1s. ## Use Cases Use cases for AWM may include but is not limited to: -- Oracle Networks: Connecting a Subnet to an oracle network is a costly process. AWM makes it easy for oracle networks to broadcast their data from their origin chain to other Subnets. -- Token transfers between Subnets -- State Sharding between multiple Subnets +- Oracle Networks: Connecting an Avalanche L1 to an oracle network is a costly process. AWM makes it easy for oracle networks to broadcast their data from their origin chain to other Avalanche L1s. +- Token transfers between Avalanche L1s +- State Sharding between multiple Avalanche L1s -Elements of Cross-Subnet Communication[​](#elements-of-cross-subnet-communication "Direct link to heading") +Elements of Cross-Avalanche L1 Communication[​](#elements-of-cross-avalanche-l1-communication "Direct link to heading") ----------------------------------------------------------------------------------------------------------- The communication consists of the following four steps: -![image showing four steps of cross-Subnet communication: Signing, aggregation, Delivery and Verification](/images/warp1.png) +![image showing four steps of cross-Avalanche L1 communication: Signing, aggregation, Delivery and Verification](/images/warp1.png) -### Signing Messages on the Origin Subnet[​](#signing-messages-on-the-origin-subnet "Direct link to heading") +### Signing Messages on the Origin Avalanche L1[​](#signing-messages-on-the-origin-avalanche-l1 "Direct link to heading") -AWM is a low-level messaging protocol. Any type of data encoded in an array of bytes can be included in the message sent to another Subnet. AWM uses the [BLS signature scheme](https://crypto.stanford.edu/~dabo/pubs/papers/BLSmultisig.html), which allows message recipients to verify the authenticity of these messages. Therefore, every validator on the Avalanche network holds a BLS key pair, consisting of a private key for signing messages and a public key that others can use to verify the signature. +AWM is a low-level messaging protocol. Any type of data encoded in an array of bytes can be included in the message sent to another Avalanche L1. AWM uses the [BLS signature scheme](https://crypto.stanford.edu/~dabo/pubs/papers/BLSmultisig.html), which allows message recipients to verify the authenticity of these messages. Therefore, every validator on the Avalanche network holds a BLS key pair, consisting of a private key for signing messages and a public key that others can use to verify the signature. -### Signature Aggregation on the Origin Subnet[​](#signature-aggregation-on-the-origin-subnet "Direct link to heading") +### Signature Aggregation on the Origin Avalanche L1[​](#signature-aggregation-on-the-origin-avalanche-l1 "Direct link to heading") -If the validator set of a Subnet is very large, this would result in the Subnet's validators sending many signatures between them. One of the powerful features of BLS is the ability to aggregate many signatures of different signers in a single multi-signature. Therefore, validators of one Subnet can now individually sign a message and these signatures are then aggregated into a short multi-signature that can be quickly verified. +If the validator set of an Avalanche L1 is very large, this would result in the Avalanche L1's validators sending many signatures between them. One of the powerful features of BLS is the ability to aggregate many signatures of different signers in a single multi-signature. Therefore, validators of one Avalanche L1 can now individually sign a message and these signatures are then aggregated into a short multi-signature that can be quickly verified. -### Delivery of Messages to the Destination Subnet[​](#delivery-of-messages-to-the-destination-subnet "Direct link to heading") +### Delivery of Messages to the Destination Avalanche L1[​](#delivery-of-messages-to-the-destination-avalanche-l1 "Direct link to heading") -The messages do not pass through a central protocol or trusted entity, and there is no record of messages sent between Subnets on the primary network. This avoids a bottleneck in Subnet-to-Subnet communication, and non-public Subnets can communicate privately. +The messages do not pass through a central protocol or trusted entity, and there is no record of messages sent between Avalanche L1s on the primary network. This avoids a bottleneck in Avalanche L1-to-Avalanche L1 communication, and non-public Avalanche L1s can communicate privately. -It is up to the Subnets and their users to determine how they want to transport data from the validators of the origin Subnet to the validators of the destination Subnet and what guarantees they want to provide for the transport. +It is up to the Avalanche L1s and their users to determine how they want to transport data from the validators of the origin Avalanche L1 to the validators of the destination Avalanche L1 and what guarantees they want to provide for the transport. -### Verification of Messages in the Destination Subnet[​](#verification-of-messages-in-the-destination-subnet "Direct link to heading") +### Verification of Messages in the Destination Avalanche L1[​](#verification-of-messages-in-the-destination-avalanche-l1 "Direct link to heading") -When a Subnet wants to process another Subnet's message, it will look up both BLS Public Keys and stake of the origin Subnet. The authenticity of the message can be verified using these public keys and the signature. +When an Avalanche L1 wants to process another Avalanche L1's message, it will look up both BLS Public Keys and stake of the origin Avalanche L1. The authenticity of the message can be verified using these public keys and the signature. -The combined weight of the validators that must be part of the BLS multi-signature to be considered valid can be set according to the individual requirements of each Subnet-to-Subnet communication. Subnet A may accept messages from Subnet B that are signed by at least 70% of stake. Messages from Subnet C are only accepted if they have been signed by validators that account for 90% of the stake. +The combined weight of the validators that must be part of the BLS multi-signature to be considered valid can be set according to the individual requirements of each Avalanche L1-to-Avalanche L1 communication. Avalanche L1 A may accept messages from Avalanche L1 B that are signed by at least 70% of stake. Messages from Avalanche L1 C are only accepted if they have been signed by validators that account for 90% of the stake. -Since both the public keys and stake weights of all validators are recorded on the primary network's P-chain, they are readily accessible to any virtual machine run by the validators. Therefore, the Subnets do not need to communicate with each other about changes in their respective sets of validators, but can simply rely on the latest information on the P-Chain. Therefore, AWM introduces no additional trust assumption other than that the validators of the origin Subnet are participating honestly. +Since both the public keys and stake weights of all validators are recorded on the primary network's P-chain, they are readily accessible to any virtual machine run by the validators. Therefore, the Avalanche L1s do not need to communicate with each other about changes in their respective sets of validators, but can simply rely on the latest information on the P-Chain. Therefore, AWM introduces no additional trust assumption other than that the validators of the origin Avalanche L1 are participating honestly. Reference Implementation[​](#reference-implementation "Direct link to heading") ------------------------------------------------------------------------------- -A Proof-of-Concept VM called [XSVM](https://github.com/ava-labs/xsvm) was created to demonstrate the power of AWM. XSVM enables simple AWM transfers between any two Subnets if run out-of-the-box. \ No newline at end of file +A Proof-of-Concept VM called [XSVM](https://github.com/ava-labs/xsvm) was created to demonstrate the power of AWM. XSVM enables simple AWM transfers between any two Avalanche L1s if run out-of-the-box. diff --git a/content/docs/cross-chain/avalanche-warp-messaging/run-relayer.mdx b/content/docs/cross-chain/avalanche-warp-messaging/run-relayer.mdx index 5ec3b3a72c9..a994a8ec7a6 100644 --- a/content/docs/cross-chain/avalanche-warp-messaging/run-relayer.mdx +++ b/content/docs/cross-chain/avalanche-warp-messaging/run-relayer.mdx @@ -1,317 +1,47 @@ --- -title: Run an AWM Relayer +title: Run a Relayer +description: Reference relayer implementation for cross-chain Avalanche Warp Message delivery. --- - -Dive deeper into Teleporter and kickstart your journey in building cross-chain dApps by enrolling in our [Teleporter course](https://academy.avax.network/course/teleporter). - -Reference relayer implementation for cross-chain Avalanche Warp Message delivery. +This repository contains off-chain services that help support Avalanche Interchain Messaging (ICM). -AWM Relayer listens for Warp message events on a set of source blockchains, and constructs transactions to relay the Warp message to the intended destination blockchain. The relayer does so by querying the source blockchain validator nodes for their BLS signatures on the Warp message, combining the individual BLS signatures into a single aggregate BLS signature, and packaging the aggregate BLS signature into a transaction according to the destination blockchain VM Warp message verification rules. +Currently implemented applications are -Installation[​](#installation "Direct link to heading") -------------------------------------------------------- +1. [AWM Relayer](https://github.com/ava-labs/awm-relayer/blob/main/relayer/README.md) + - Full-service cross-chain message delivery application that is configurable to listen to specific source and destination chain pairs and relay messages according to its configured rules. +2. [Signature Aggregator](https://github.com/ava-labs/awm-relayer/blob/main/signature-aggregator/README.md) + - Lightweight API that requests and aggregates signatures from validators for any ICM message, and returns a valid signed message that the user can then self-deliver to the intended destination chain. -### Dev Container & Codespace[​](#dev-container--codespace "Direct link to heading") +## Updating dependencies and E2E testing -To get started easily, we provide a Dev Container specification, that can be used using GitHub Codespace or locally using Docker and VS Code. [Dev Containers](https://code.visualstudio.com/docs/devcontainers/containers) are a concept that utilizes containerization to create consistent and isolated development environment. You can run them directly on Github by clicking **Code**, switching to the **Codespaces** tab and clicking **Create codespace on main**. Alternatively, you can run them locally with the extensions for [VS Code](https://marketplace.visualstudio.com/items?itemName=ms-vscode-remote.remote-containers) or other code editors. +Applications in this repository depend on the following upstream repositories, both directly in terms of code imports defined in the `go.mod` file as well as indirectly for E2E tests where binary versions are used to spin up the test network via `tmpnet`: -### Download Prebuilt Binaries[​](#download-prebuilt-binaries "Direct link to heading") +1. [avalanchego](https://github.com/ava-labs/avalanchego/) +2. [coreth](https://github.com/ava-labs/coreth) (indirectly) +3. [subnet-evm](https://github.com/ava-labs/subnet-evm) -Prebuilt binaries are available for download from the [releases page](https://github.com/ava-labs/awm-relayer/releases). +> [!NOTE] +> We require any commits referenced in our `main` branch to be present in the default branches of the repositories above, but during active development it might be useful to work against changes in progress that are still on feature branches. -The following commands demonstrate how to download and install the v0.2.13 release of the relayer on MacOS. The exact commands will vary by platform. +When developing such features that require updates to one or more of the above, care must be taken to understand where the relevant code comes from. The binaries of applications built in this repo are built against versions referenced in the `go.mod` file. The E2E tests run against a simulated network running locally that is started by calling a separately compiled `avalanchego` binary as well as its plugins. These are compiled based on the values of `AVALANCHEGO_VERSION` in the local checkout of `subnet-evm` when running the tests locally and directly in this repository's `./scripts/versions.sh` when running E2E tests remotely through GitHub actions. -``` -# Download the release tarball and checksums -curl -w '%{http_code}' -sL -o ~/Downloads/awm-relayer_0.2.13_darwin_arm64.tar.gz https://github.com/ava-labs/awm-relayer/releases/download/v0.2.13/awm-relayer_0.2.13_darwin_arm64.tar.gz -curl -w '%{http_code}' -sL -o ~/Downloads/awm-relayer_0.2.13_checksums.txt https://github.com/ava-labs/awm-relayer/releases/download/v0.2.13/awm-relayer_0.2.13_checksums.txt +`avalanchego` and `coreth` have a direct circular dependency and this repository is only indirectly dependent on `coreth` but directly dependent on `avalanchego`. Therefore if any updates are required from the `coreth` side, a corresponding `avalanchego` commit referencing those changes is required. On the other hand `subnet-evm` just depends directly on `avalanchego`. -# (Optional) Verify the checksums -cd ~/Downloads -# Confirm that the following two commands output the same checksum -grep "awm-relayer_0.2.13_darwin_arm64.tar.gz" "awm-relayer_0.2.13_checksums.txt" 2>/dev/null -shasum -a 256 "awm-relayer_0.2.13_darwin_arm64.tar.gz" 2>/dev/null +### Example dependency update flow -# Extract the tarball and install the relayer binary -tar -xzf awm-relayer_0.2.13_darwin_arm64.tar.gz -sudo install awm-relayer /usr/local/bin -``` +The most complicated example case that can arise above is that a feature depends on a new change in `coreth`. And the steps below outline the necessary commits: -_Note:_ If downloading the binaries through a browser on MacOS, the browser may mark the binary as quarantined since it has not been verified through the App Store. To remove the quarantine, run the following command: +1. If an `avalanchego` commit referencing this change in its `go.mod` file doesn't exist yet then it needs to be added. +2. Add a commit in `subnet-evm` that references the `avalanchego` commit from above in both its `go.mod` file as well as its `scripts/versions.sh` file. +3. Create a new commit in this repository referencing `avalanchego` and `subnet-evm` directly and `coreth` indirectly as well as update references in the `scripts/version.sh` file for both `AVALANCHEGO_VERSION` and `SUBNET_EVM_VERSION`. -``` -xattr -d com.apple.quarantine /usr/local/bin/awm-relayer -``` +Publishing all of the commits mentioned above to GitHub branches will enable running E2E tests through the CI. -### Download Docker Image[​](#download-docker-image "Direct link to heading") +Running the tests locally doesn't require publishing the `subnet-evm` commit since `./scripts/e2e_test.sh` takes a flag specifying local checkout of `subnet-evm` repository. -The published Docker image can be pulled from `avaplatform/awm-relayer:latest` on dockerhub. +> [!NOTE] +> Locally running E2E tests using local checkout of `subnet-evm` will install `avalanchego` version specified by the `AVALANCHEGO_VERSION` in that working tree's `./scripts/versions.sh`. -### Build from Source[​](#build-from-source "Direct link to heading") - -See the [Building](#building) section for instructions on how to build the relayer from source. - -Requirements[​](#requirements "Direct link to heading") -------------------------------------------------------- - -### System Requirements[​](#system-requirements "Direct link to heading") - -- Ubuntu 22.04 or later - - Tested on x86\_64/amd64 architecture. -- MacOS 14.3 or later - - Tested on arm64 architecture (Apple silicon). - -### API Requirements[​](#api-requirements "Direct link to heading") - -- AWM Relayer requires access to Avalanche API nodes for the P-Chain as well as any connected Subnets. The API nodes must have the following methods enabled: - - Each Subnet API node must have enabled: - - eth API (RPC and WS) - - The P-Chain API node must have enabled: - - platform.getHeight - - platform.validatedBy - - platform.getValidatorsAt OR platform.getCurrentValidators - - The Info API node must have enabled: - - info.peers - - info.getNetworkID - - If the Info API node is also a Subnet validator, it must have enabled: - - info.getNodeID - - info.getNodeIP - -The Fuji and Mainnet [public API nodes](/tooling/rpc-providers) provided by Avalanche have these methods enabled, and are suitable for use with the relayer. - -### Peer-to-Peer Connections[​](#peer-to-peer-connections "Direct link to heading") - -- The AWM relayer implementation gathers BLS signatures from the validators of the source Subnet via peer-to-peer `AppRequest` messages. Validator nodes need to be configured to accept incoming peer connections. Otherwise, the relayer will fail to gather Warp message signatures. For example, networking rules may need to be adjusted to allow traffic on the default AvalancheGo P2P port (9651), or the public IP may need to be manually set in the [node configuration](/nodes/configure/configs-flags#public-ip). - -Usage[​](#usage "Direct link to heading") ------------------------------------------ - -### Building[​](#building "Direct link to heading") - -Before building, be sure to install Go, which is required even if you're just building the Docker image. - -Build the relayer by running the script: - -Build a Docker image by running the script: - -``` -./scripts/build_local_image.sh -``` - -### Running[​](#running "Direct link to heading") - -The relayer binary accepts a path to a JSON configuration file as the sole argument. Command line configuration arguments are not currently supported. - -``` -./build/awm-relayer --config-file path-to-config -``` - -### Configuration[​](#configuration "Direct link to heading") - -The relayer is configured via a JSON file, the path to which is passed in via the `--config-file` command line argument. Top level configuration options are also able to be set via environment variable. To get the environment variable corresponding to a key, upper case the key and change the delimiter from "-" to "\_". For example, `LOG_LEVEL` sets the `"log-level"` JSON key. The following configuration options are available: - -`"log-level": "verbo" | "debug" | "info" | "warn" | "error" | "fatal" | "panic"` - -- The log level for the relayer. Defaults to `info`. - -`"p-chain-api": APIConfig` - -- The configuration for the Avalanche P-Chain API node. The `PChainAPI` object has the following configuration: - - `"base-url": string` - - - The URL of the Avalanche P-Chain API node to which the relayer will connect. This API node needs to have the following methods enabled: - - platform.getHeight - - platform.validatedBy - - platform.getValidatorsAt OR platform.getCurrentValidators - - `"query-parameters": map[string]string` - - - Additional query parameters to include in the API requests. - -`"info-api": APIConfig` - -- The configuration for the Avalanche Info API node. The `InfoAPI` object has the following configuration: - - `"base-url": string` - - - The URL of the Avalanche Info API node to which the relayer will connect. This API node needs to have the following methods enabled: - - - info.peers - - info.getNetworkID - - Additionally, if the Info API node is also a validator, it must have enabled: - - - info.getNodeID - - info.getNodeIP - - `"query-parameters": map[string]string` - - - Additional query parameters to include in the API requests. - -`"storage-location": string` - -- The path to the directory in which the relayer will store its state. Defaults to `./awm-relayer-storage`. - -`"redis-url": string` - -- The URL of the Redis server to use to manage state. This URL should specify the user, password, host, port, DB index, and protocol version. For example, `"redis://user:password@localhost:6379/0?protocol=3"`. Overrides `storage-location` if provided. - -`"process-missed-blocks": boolean` - -- Whether or not to process missed blocks after restarting. Defaults to `true`. If set to false, the relayer will start processing blocks from the chain head. - -`"manual-warp-messages": []ManualWarpMessage` - -- The list of Warp messages to relay on startup, independent of the catch-up mechanism or normal operation. Each `ManualWarpMessage` has the following configuration: - - `"unsigned-message-bytes": string` - - - The hex-encoded bytes of the unsigned Warp message to relay. - - `"source-blockchain-id": string` - - - cb58-encoded blockchain ID of the source blockchain. - - `"destination-blockchain-id": string` - - - cb58-encoded blockchain ID of the destination blockchain. - - `"source-address": string` - - - The address of the source account that sent the Warp message. - - `"destination-address": string` - - - The address of the destination account that will receive the Warp message. - -`"source-blockchains": []SourceBlockchains` - -- The list of source blockchains to support. Each `SourceBlockchain` has the following configuration: - - `"subnet-id": string` - - - cb58-encoded Subnet ID. - - `"blockchain-id": string` - - - cb58-encoded blockchain ID. - - `"vm": string` - - - The VM type of the source blockchain. - - `"rpc-endpoint": string` - - - The RPC endpoint of the source blockchain's API node. - - `"ws-endpoint": string` - - - The WebSocket endpoint of the source blockchain's API node. - - `"message-contracts": map[string]MessageProtocolConfig` - - - Map of contract addresses to the config options of the protocol at that address. Each `MessageProtocolConfig` consists of a unique `message-format` name, and the raw JSON `settings`. - - `"supported-destinations": []SupportedDestination` - - - List of destinations that the source blockchain supports. Each `SupportedDestination` consists of a cb58-encoded destination blockchain ID (`"blockchain-id"`), and a list of hex-encoded addresses (`"addresses"`) on that destination blockchain that the relayer supports delivering Warp messages to. The destination address is defined by the message protocol. For example, it could be the address called from the message protocol contract. If no supported addresses are provided, all addresses are allowed on that blockchain. If `supported-destinations` is empty, then all destination blockchains (and therefore all addresses on those destination blockchains) are supported. - - `"process-historical-blocks-from-height": unsigned integer` - - - The block height at which to back-process transactions from the source blockchain. If the database already contains a later block height for the source blockchain, then that will be used instead. Must be non-zero. Will only be used if `process-missed-blocks` is set to `true`. - - `"allowed-origin-sender-addresses": []string` - - - List of addresses on this source blockchain to relay Warp messages from. The sending address is defined by the message protocol. For example, it could be defined as the EOA that initiates the transaction, or the address that calls the message protocol contract. If empty, then all addresses are allowed. - -`"destination-blockchains": []DestinationBlockchains` - -- The list of destination blockchains to support. Each `DestinationBlockchain` has the following configuration: - - `"subnet-id": string` - - - cb58-encoded Subnet ID. - - `"blockchain-id": string` - - - cb58-encoded blockchain ID. - - `"vm": string` - - - The VM type of the source blockchain. - - `"rpc-endpoint": string` - - - The RPC endpoint of the destination blockchains's API node. - - `"account-private-key": string` - - - The hex-encoded private key to use for signing transactions on the destination blockchain. May be provided by the environment variable `ACCOUNT_PRIVATE_KEY`. Each `destination-subnet` may use a separate private key by appending the cb58 encoded blockchain ID to the private key environment variable name, for example `ACCOUNT_PRIVATE_KEY_11111111111111111111111111111111LpoYY` - - `"kms-key-id": string` - - - The ID of the KMS key to use for signing transactions on the destination blockchain. Only one of `account-private-key` or `kms-key-id` should be provided. If `kms-key-id` is provided, then `kms-aws-region` is required. - - `"kms-aws-region": string` - - - The AWS region in which the KMS key is located. Required if `kms-key-id` is provided. - -Architecture[​](#architecture "Direct link to heading") -------------------------------------------------------- - -### Components[​](#components "Direct link to heading") - -The relayer consists of the following components: - -- At the global level: - - P2P app network: issues signature `AppRequests` - - P-Chain client: gets the validators for a Subnet - - JSON database: stores latest processed block for each Application Relayer -- Per Source Blockchain - - Subscriber: listens for logs pertaining to cross-chain message transactions - - Source RPC client: queries for missed blocks on startup -- Per Destination Blockchain - - Destination RPC client: broadcasts transactions to the destination -- Application Relayers - - Relay messages from a specific source blockchain and source address to a specific destination blockchain and destination address - -### Data Flow[​](#data-flow "Direct link to heading") - -![](/images/run-relayer1.png) - -Testing[​](#testing "Direct link to heading") ---------------------------------------------- - -### Unit Tests[​](#unit-tests "Direct link to heading") - -Unit tests can be ran locally by running the command in the root of the project: - -If your temporary directory is not writable, the unit tests may fail with messages like `fork/exec /tmp/go-build2296620589/b247/config.test: permission denied`. To fix this, set the `TMPDIR` environment variable to something writable, for example `export TMPDIR=~/tmp`. - -### E2E Tests[​](#e2e-tests "Direct link to heading") - -E2E tests are ran as part of CI, but can also be ran locally with the `--local` flag. To run the E2E tests locally, you'll need to install Gingko following the instructions [here](https://onsi.github.io/ginkgo/#installing-ginkgo) - -Next, provide the path to the `subnet-evm` repository and the path to a writeable data directory (this example uses `~/subnet-evm` and `~/tmp/e2e-test`) to use for the tests: - -``` -./scripts/e2e_test.sh --local --subnet-evm ~/subnet-evm --data-dir ~/tmp/e2e-test -``` - -To run a specific E2E test, specify the environment variable `GINKGO_FOCUS`, which will then look for [test descriptions](https://github.com/ava-labs/awm-relayer/blob/main/tests/e2e_test.go#L68) that match the provided input. For example, to run the `Basic Relay` test: - -``` -GINKGO_FOCUS="Basic" ./scripts/e2e_test.sh --local --subnet-evm ~/subnet-evm --data-dir ~/tmp/e2e-test -``` - -The E2E tests use the `TeleporterMessenger` contract deployment transaction specified in the following files: - -- `tests/utils/UniversalTeleporterDeployerAddress.txt` -- `tests/utils/UniversalTeleporterDeployerTransaction.txt` -- `tests/utils/UniversalTeleporterMessagerContractAddress.txt` To update the version of Teleporter used by the E2E tests, update these values with the latest contract deployment information. For more information on how to deploy the Teleporter contract, see the [Teleporter documentation](https://github.com/ava-labs/teleporter/tree/main/utils/contract-deployment). - -### Generate Mocks[​](#generate-mocks "Direct link to heading") - -[Gomock](https://pkg.go.dev/go.uber.org/mock/gomock) is used to generate mocks for testing. To generate mocks, run the following command at the root of the project: \ No newline at end of file +> [!TIP] +> Using the local checkout it's possible to run tests against a `tmpnet` consisting of nodes using a different version of `avalanchego` than the application being tested which might be helpful when troubleshooting. diff --git a/content/docs/cross-chain/index.mdx b/content/docs/cross-chain/index.mdx index 28db684cd67..7deabe37ba5 100644 --- a/content/docs/cross-chain/index.mdx +++ b/content/docs/cross-chain/index.mdx @@ -7,4 +7,4 @@ description: Learn about different interoperability protocols in the Avalanche e - \ No newline at end of file + diff --git a/content/docs/cross-chain/teleporter/cli.mdx b/content/docs/cross-chain/teleporter/cli.mdx index f7ad4524fdb..bffed1a2599 100644 --- a/content/docs/cross-chain/teleporter/cli.mdx +++ b/content/docs/cross-chain/teleporter/cli.mdx @@ -1,21 +1,16 @@ --- title: Teleporter CLI +description: The CLI is a command line interface for interacting with the Teleporter contracts. --- - -Dive deeper into Teleporter and kickstart your journey in building cross-chain dApps by enrolling in our [Teleporter course](https://academy.avax.network/course/teleporter). - - This directory contains the source code for the Teleporter CLI. The CLI is a command line interface for interacting with the Teleporter contracts. It is written with [cobra](https://github.com/spf13/cobra) commands as a Go application. -Build[​](#build "Direct link to heading") ------------------------------------------ +## Build To build the CLI, run `go build` from this directory. This will create a binary called `teleporter-cli` in the current directory. -Usage[​](#usage "Direct link to heading") ------------------------------------------ +## Usage The CLI has a number of subcommands. To see the list of subcommands, run `./teleporter-cli help`. To see the help for a specific subcommand, run `./teleporter-cli help `. @@ -23,4 +18,5 @@ The supported subcommands include: - `event`: given a log event's topics and data, attempts to decode into a Teleporter event in a more readable format. - `message`: given a Teleporter message encoded as a hex string, attempts to decode into a Teleporter message in a more readable format. -- `transaction`: given a transaction hash, attempts to decode all relevant Teleporter and Warp log events in a more readable format. \ No newline at end of file +- `transaction`: given a transaction hash, attempts to decode all relevant Teleporter and Warp log events in a more readable format. + diff --git a/content/docs/cross-chain/teleporter/deep-dive.mdx b/content/docs/cross-chain/teleporter/deep-dive.mdx index 5f06e9c2502..32490e210ec 100644 --- a/content/docs/cross-chain/teleporter/deep-dive.mdx +++ b/content/docs/cross-chain/teleporter/deep-dive.mdx @@ -1,47 +1,53 @@ --- title: Deep Dive into Teleporter +description: Teleporter is an EVM compatible cross-blockchain communication protocol built on top of Avalanche Warp Messaging (AWM), and implemented as a Solidity smart contract. --- -![](/images/deep-dive1.png) +

+ +

-Teleporter is an EVM compatible cross-subnet communication protocol built on top of [Avalanche Warp Messaging (AWM)](/cross-chain/avalanche-warp-messaging/overview), and implemented as a Solidity smart contract. It provides a mechanism to asynchronously invoke smart contract functions on other EVM blockchains within Avalanche. Teleporter provides a handful of useful features on top of AWM, such as specifying relayer incentives for message delivery, replay protection, message delivery and execution retries, and a standard interface for sending and receiving messages within a dApp deployed across multiple subnets. +To get started with building applications on top of Teleporter, refer to [the avalanche-starter-kit repository](https://github.com/ava-labs/avalanche-starter-kit). This README is focused on the development of the Teleporter protocol itself. -It's important to understand the distinction between Avalanche Warp Messaging and Teleporter. AWM allows subnets to communicate with each other via authenticated messages by providing signing and verification primitives in Avalanchego. These are used by the blockchain VMs to sign outgoing messages and verify incoming messages. +Teleporter is an EVM compatible cross-blockchain communication protocol built on top of [Avalanche Warp Messaging (AWM)](/cross-chain/avalanche-warp-messaging/overview), and implemented as a Solidity smart contract. It provides a mechanism to asynchronously invoke smart contract functions on other EVM blockchains within Avalanche. Teleporter provides a handful of useful features on top of AWM, such as specifying relayer incentives for message delivery, replay protection, message delivery and execution retries, and a standard interface for sending and receiving messages within a dApp deployed across multiple Layer 1s. -The Teleporter protocol, on the other hand, is implemented at the smart contract level, and is a user-friendly interface to AWM, aimed at dApp developers. All of the message signing and verification is abstracted away from developers. Instead, developers simply call `sendCrossChainMessage` on the `TeleporterMessenger` contract to send a message invoking a smart contract on another subnet, and implement the `ITeleporterReceiver` interface to receive messages on the destination subnet. Teleporter handles all of the Warp message construction and sending, as well as the message delivery and execution. +It's important to understand the distinction between Avalanche Warp Messaging and Teleporter. AWM allows blockchains to communicate with each other via authenticated messages by providing signing and verification primitives in Avalanchego. These are used by the blockchain VMs to sign outgoing messages and verify incoming messages. + +The Teleporter protocol, on the other hand, is implemented at the smart contract level, and is a user-friendly interface to AWM, aimed at dApp developers. All of the message signing and verification is abstracted away from developers. Instead, developers simply call `sendCrossChainMessage` on the `TeleporterMessenger` contract to send a message invoking a smart contract on another Avalanche L1, and implement the `ITeleporterReceiver` interface to receive messages on the destination Avalanche L1. Teleporter handles all of the Warp message construction and sending, as well as the message delivery and execution. + +To get started with using Teleporter, see [How to Deploy Teleporter Enabled Blockchains on a Local Network](https://docs.avax.network/tooling/cli-cross-chain/teleporter-on-local-networks) - [Deployed Addresses](#deployed-addresses) +- [A Note on Versioning](#a-note-on-versioning) - [Setup](#setup) - - [Initialize the repository](#initialize-the-repository) - - [Dependencies](#dependencies) + - [Initialize the repository](#initialize-the-repository) + - [Dependencies](#dependencies) - [Structure](#structure) -- [Run a local testnet in Docker](#run-a-local-testnet-in-docker) - - [Start up the local testnet](#start-up-the-local-testnet) - - [Additional notes](#additional-notes) - [E2E tests](#e2e-tests) - - [Run specific E2E tests](#run-specific-e2e-tests) - - [Run the E2E tests on another network](#run-the-e2e-tests-on-another-network) -- [Upgradeability](#upgradeability) -- [Deploy Teleporter to a Subnet](#deploy-teleporter-to-a-subnet) -- [Deploy TeleporterRegistry to a Subnet](#deploy-teleporterregistry-to-a-subnet) + - [Run specific E2E tests](#run-specific-e2e-tests) + - [Run the E2E tests on another network](#run-the-e2e-tests-on-another-network) +- [Upgradability](#upgradability) +- [Deploy Teleporter to an Avalanche L1](#deploy-teleporter-to-a-subnet) +- [Deploy TeleporterRegistry to an Avalanche L1](#deploy-teleporterregistry-to-a-subnet) - [ABI Bindings](#abi-bindings) - [Docs](#docs) - [Resources](#resources) ## Deployed Addresses +| Contract | Address | Chain | +| --------------------- | ---------------------------------------------- | ------------------------ | +| `TeleporterMessenger` | **0x253b2784c75e510dD0fF1da844684a1aC0aa5fcf** | All chains, all networks | +| `TeleporterRegistry` | **0x7C43605E14F391720e1b37E49C78C4b03A488d98** | Mainnet C-Chain | +| `TeleporterRegistry` | **0xF86Cb19Ad8405AEFa7d09C778215D2Cb6eBfB228** | Fuji C-Chain | -|Contract |Address |Chain | -|-------------------|------------------------------------------|------------------------| -|TeleporterMessenger|0x253b2784c75e510dD0fF1da844684a1aC0aa5fcf|All chains, all networks| -|TeleporterRegistry |0x7C43605E14F391720e1b37E49C78C4b03A488d98|Mainnet C-Chain | -|TeleporterRegistry |0xF86Cb19Ad8405AEFa7d09C778215D2Cb6eBfB228|Fuji C-Chain | +- Using [Nick's method](https://yamenmerhi.medium.com/nicks-method-ethereum-keyless-execution-168a6659479c#), `TeleporterMessenger` deploys at a universal address across all chains, varying with each `teleporter` Major release. **Compatibility exists only between same-version `TeleporterMessenger` instances.** See [Teleporter Contract Deployment](https://github.com/ava-labs/teleporter/blob/main/utils/contract-deployment/README.md) and [Deploy Teleporter to an Avalanche L1](#deploy-teleporter-to-a-subnet) for more details. +- `TeleporterRegistry` can be deployed to any address. See [Deploy TeleporterRegistry to an Avalanche L1](#deploy-teleporterregistry-to-a-subnet) for details. The table above enumerates the canonical registry addresses on the Mainnet and Fuji C-Chains. -- When deployed using [Nick's method](https://yamenmerhi.medium.com/nicks-method-ethereum-keyless-execution-168a6659479c#), `TeleporterMessenger` will be at the same address on all chains. See [Teleporter Contract Deployment](https://github.com/ava-labs/teleporter/blob/main/utils/contract-deployment/README.md) and [Deploy Teleporter to a Subnet](#deploy-teleporter-to-a-subnet) for more details. - -- `TeleporterRegistry` can be deployed to any address. See [Deploy TeleporterRegistry to a Subnet](#deploy-teleporterregistry-to-a-subnet) for details. The table above enumerates the canonical registry addresses on the Mainnet and Fuji C-Chains. - +## A Note on Versioning + +Release versions follow the [semver](https://semver.org/) convention of incompatible Major releases. A new Major version is released whenever the `TeleporterMessenger` bytecode is changed, and a new version of `TeleporterMessenger` is meant to be deployed. Due to the use of Nick's method to deploy the contract to the same address on all chains (see [Teleporter Contract Deployment](https://github.com/ava-labs/teleporter/blob/main/utils/contract-deployment/README.md) for details), this also means that new release versions would result in different Teleporter contract addresses. Minor and Patch versions may pertain to contract changes that do not change the `TeleporterMessenger` bytecode, or to changes in the test frameworks, and will only be included in tags. ## Setup @@ -51,11 +57,11 @@ The Teleporter protocol, on the other hand, is implemented at the smart contract ### Dependencies -- [Ginkgo](https://onsi.github.io/ginkgo/#installing-ginkgo) for running the end-to-end tests -- Docker and Docker Compose v2 for running the local test network - - The docker image installs the following: - - [Foundry](https://book.getfoundry.sh/getting-started/installation) - - [Python3](https://www.python.org/downloads/) +- [Ginkgo](https://onsi.github.io/ginkgo/#installing-ginkgo) for running the end-to-end tests. +- Docker and Docker Compose v2 for running the local test network. + - The docker image installs the following: + - [Foundry](https://book.getfoundry.sh/) Use `/scripts/install_foundry.sh` to install the Ava Labs [fork](https://github.com/ava-labs/foundry). + - [Python3](https://www.python.org/downloads/) ## Structure @@ -64,67 +70,11 @@ The Teleporter protocol, on the other hand, is implemented at the smart contract - `tests/` includes integration tests for the contracts in `contracts/`, written using the [Ginkgo](https://onsi.github.io/ginkgo/) testing framework. - `utils/` includes Go utility functions for interacting with the contracts in `contracts/`. Included are Golang scripts to derive the expected EVM contract address deployed from a given EOA at a specific nonce, and also construct a transaction to deploy provided byte code to the same address on any EVM chain using [Nick's method](https://yamenmerhi.medium.com/nicks-method-ethereum-keyless-execution-168a6659479c#). - `scripts/` includes bash scripts for interacting with Teleporter in various environments, as well as utility scripts. - - `abi_bindings.sh` generates ABI bindings for the contracts in `contracts/` and outputs them to `abi-bindings/`. - - `lint.sh` performs Solidity and Golang linting. - - `scripts/local/` includes scripts for running Teleporter in Docker. + - `abi_bindings.sh` generates ABI bindings for the contracts in `contracts/` and outputs them to `abi-bindings/`. + - `lint.sh` performs Solidity and Golang linting. + - `scripts/local/` includes scripts for running Teleporter in Docker. - `docker/` includes configurations for a local, containerized setup of Teleporter. -## Run a local testnet in Docker - -A docker setup for running a local network with Teleporter deployed is provided. This setup provides a convenient way to develop and test Teleporter as well as cross-chain applications built on top of Teleporter. Teleporter messages are relayed between subnets using [AWM Relayer](https://github.com/ava-labs/awm-relayer), a fully featured implementation of a Warp message relayer. - -### Start up the local testnet - -- Run `./scripts/local/run.sh` to run the local testnet in Docker containers with the ability to interact with the nodes directly. - - - `./scripts/local/run.sh` usage is as follows: - -``` - -l, --local-relayer-image Use a local AWM Relayer image instead of pulling from dockerhub - -h, --help Print this help message -``` - - - If using `-l, --local` to use a local version of the `awm-relayer` image, build it using `./scripts/build_local_image.sh` from the root of the `awm-relayer` repository. - - Note that if `-l, --local` is not set, then the latest published `awm-relayer` image will be pulled from Dockerhub. -- After calling `./scripts/local/run.sh`, you'll know the network is ready once the "Waiting for subnets to start up." messages from the `relayer_run` container stop. Once the network is ready, you can interact with the deployed Teleporter contracts directly, or deploy a cross-chain application contract such as `ExampleCrossChainMessenger`. To open a terminal in the container and initialize it with the environment variables needed to interact with the contracts, run: - - -``` -# Open a shell in the container -docker exec -it local_network_run /bin/bash - -# In the container: -set -a # export all variables so child processes can access -source vars.sh # source the variables needed to interact with the contracts -``` - -- Once you've opened a shell in the container, try interacting with the network. - - For example, send 1 AVAX on the C-Chain using `cast` - -``` -c_address=0x333d17d3b42bf7930dbc6e852ca7bcf560a69003 # pick an arbitrary address -cast balance --rpc-url $c_chain_rpc_url $c_address -cast send --private-key $user_private_key --value 1 $c_address --rpc-url $c_chain_rpc_url -cast balance --rpc-url $c_chain_rpc_url $c_address -``` - -- An example of how to interact with Teleporter is provided in `scripts/local/examples/basic_send_receive.sh`. This script sends a dummy payload via Teleporter from the C-Chain to a subnet, and back again. - -``` -./scripts/local/examples/basic_send_receive.sh -``` - -- You should see "Received on Subnet A is true" and "Received on the C-Chain is true" to indicate that Teleporter messages were successfully sent between the C-Chain and Subnet A. - - These examples can be adapted to send messages between any two subnets, or between the C-Chain and any subnet by changing the RPC URLs. - - Use these as a starting point to build and interact with your own cross-chain applications on top of Teleporter! - -### Additional notes - -- The `./scripts/local/run.sh` script runs five local network nodes, with each of the nodes validating the primary network and three subnets (Subnet A, Subnet B, and Subnet C). -- `./scripts/local/run.sh` will force-recreate the containers, which will reset the network state on each subsequent run. -- Logs from the subnets on one of the five nodes are printed to stdout when run using either script. -- These logs can also be found at `~/.avalanche-cli/runs/network__/node{1,5]/logs/.log` in the `local_network_run` container. - ## E2E tests In addition to the docker setup, end-to-end integration tests written using Ginkgo are provided in the `tests/` directory. E2E tests are run as part of CI, but can also be run locally. Any new features or cross-chain example applications checked into the repository should be accompanied by an end-to-end tests. See the [Contribution Guide](https://github.com/ava-labs/teleporter/blob/main/CONTRIBUTING.md) for additional details. @@ -133,7 +83,7 @@ To run the E2E tests locally, you'll need to install Gingko following the instru Then run the following command from the root of the repository: -``` +```bash ./scripts/local/e2e_test.sh ``` @@ -141,27 +91,29 @@ Then run the following command from the root of the repository: To run a specific E2E test, specify the environment variable `GINKGO_FOCUS`, which will then look for test descriptions that match the provided input. For example, to run the `Calculate Teleporter message IDs` test: -``` +```bash GINKGO_FOCUS="Calculate Teleporter message IDs" ./scripts/local/e2e_test.sh ``` A substring of the full test description can be used as well: -``` +```bash GINKGO_FOCUS="Calculate Teleporter" ./scripts/local/e2e_test.sh ``` The E2E tests also supports `GINKGO_LABEL_FILTER`, making it easy to group test cases and run them together. For example, to run all E2E tests for the example cross chain applications: +```bash +```markdown +ginkgo.It("Send native tokens from Avalanche L1 A to B and back", ``` - ginkgo.It("Send native tokens from subnet A to B and back", ginkgo.Label("cross chain apps"), func() { flows.NativeTokenBridge(LocalNetworkInstance) }) ``` -``` +```bash GINKGO_LABEL_FILTER="cross chain apps" ./scripts/local/e2e_test.sh ``` @@ -169,48 +121,50 @@ GINKGO_LABEL_FILTER="cross chain apps" ./scripts/local/e2e_test.sh The same E2E test flows can be executed against external network by setting the proper environment variables in `.env.testnet` and `.env`, and running the following commands: -``` +```bash cp .env.example .env # Set proper values after copying. ./scripts/testnet/run_testnet_e2e_flows.sh ``` -The user wallet set in `.env` must have native tokens for each of the Subnets used in order for the test flows to be able to send transactions on those networks. The [Avalanche Testnet Faucet](https://core.app/tools/testnet-faucet) can be used to obtain native tokens for certain public testnet Subnets. +The user wallet set in `.env` must have native tokens for each of the Blockchains used in order for the test flows to be able to send transactions on those networks. The [Avalanche Testnet Faucet](https://core.app/tools/testnet-faucet) can be used to obtain native tokens for certain public testnet Blockchains. -## Upgradeability +## Upgradability -The Teleporter contract is non-upgradeable and can not be changed once it is deployed. This provides immutability to the contracts, and ensures that the contract's behavior at each address is unchanging. However, to allow for new features and potential bug fixes, new versions of the Teleporter contract can be deployed to different addresses. The [TeleporterRegistry](https://github.com/ava-labs/teleporter/blob/main/contracts/src/Teleporter/TeleporterRegistry.sol) is used to keep track of the deployed versions of Teleporter, and to provide a standard interface for dApps to interact with the different Teleporter versions. +The Teleporter contract is non-upgradeable and can not be changed once it is deployed. This provides immutability to the contracts, and ensures that the contract's behavior at each address is unchanging. However, to allow for new features and potential bug fixes, new versions of the Teleporter contract can be deployed to different addresses. The [TeleporterRegistry](https://github.com/ava-labs/teleporter/blob/main/contracts/teleporter/registry/TeleporterRegistry.sol) is used to keep track of the deployed versions of Teleporter, and to provide a standard interface for dApps to interact with the different Teleporter versions. -`TeleporterRegistry` **is not mandatory** for dApps built on top of Teleporter, but dApp's are recommended to leverage the registry to ensure they use the latest Teleporter version available. Another recommendation standard is to have a single canonical `TeleporterRegistry` for each Subnet chain, and unlike the Teleporter contract, the registry does not need to be deployed to the same address on every chain. This means the registry does not need a Nick's method deployment, and can be at different contract addresses on different chains. +`TeleporterRegistry` **is not mandatory** for dApps built on top of Teleporter, but dApp's are recommended to leverage the registry to ensure they use the latest Teleporter version available. Another recommendation standard is to have a single canonical `TeleporterRegistry` for each Layer 1 chain, and unlike the Teleporter contract, the registry does not need to be deployed to the same address on every chain. This means the registry does not need a Nick's method deployment, and can be at different contract addresses on different chains. -For more information on the registry and how to integrate with Teleporter dApps, see the [Upgradeability doc](https://github.com/ava-labs/teleporter/blob/main/contracts/src/Teleporter/upgrades/README.md). +For more information on the registry and how to integrate with Teleporter dApps, see the [Upgradability doc](https://github.com/ava-labs/teleporter/blob/main/contracts/teleporter/registry/README.md). -## Deploy Teleporter to a Subnet +## Deploy Teleporter to an Avalanche L1 From the root of the repo, the TeleporterMessenger contract can be deployed by calling -``` -./scripts/deploy_teleporter.sh --version \ --rpc-url \ [OPTIONS] +```bash +./scripts/deploy_teleporter.sh --version --rpc-url [OPTIONS] ``` Required arguments: -- `--version ` Specify the release version to deploy. These will all be of the form `v1.X.0`. Each Teleporter version can only send and receive messages from the **same** Teleporter version on another chain. You can see a list of released versions at [https://github.com/ava-labs/teleporter/releases](https://github.com/ava-labs/teleporter/releases). +- `--version ` Specify the release version to deploy. These will all be of the form `v1.X.0`. Each Teleporter version can only send and receive messages from the **same** Teleporter version on another chain. You can see a list of released versions at https://github.com/ava-labs/teleporter/releases. - `--rpc-url ` Specify the rpc url of the node to use. Options: - `--private-key ` Funds the deployer address with the account held by `` -To ensure that Teleporter can be deployed to the same address on every EVM based chain, it uses [Nick's Method](https://yamenmerhi.medium.com/nicks-method-ethereum-keyless-execution-168a6659479c) to deploy from a static deployer address. Teleporter costs exactly `10eth` in the subnet's native gas token to deploy, which must be sent to the deployer address. +To ensure that Teleporter can be deployed to the same address on every EVM based chain, it uses [Nick's Method](https://yamenmerhi.medium.com/nicks-method-ethereum-keyless-execution-168a6659479c) to deploy from a static deployer address. Teleporter costs exactly `10eth` in the Avalanche L1's native gas token to deploy, which must be sent to the deployer address. + +`deploy_teleporter.sh` will send the necessary native tokens to the deployer address if it is provided with a private key for an account with sufficient funds. Alternatively, the deployer address can be funded externally. The deployer address for each version can be found by looking up the appropriate version at https://github.com/ava-labs/teleporter/releases and downloading `TeleporterMessenger_Deployer_Address_.txt`. -`deploy_teleporter.sh` will send the necessary native tokens to the deployer address if it is provided with a private key for an account with sufficient funds. Alternatively, the deployer address can be funded externally. The deployer address for each version can be found by looking up the appropriate version at [https://github.com/ava-labs/teleporter/releases](https://github.com/ava-labs/teleporter/releases) and downloading `TeleporterMessenger_Deployer_Address_.txt`. +Alternatively for new Layer 1s, the `TeleporterMessenger` contract can be directly included in the genesis file as documented [here](https://github.com/ava-labs/teleporter/blob/main/contracts/teleporter/README.md#teleporter-messenger-contract-deployment). -## Deploy TeleporterRegistry to a Subnet +## Deploy TeleporterRegistry to an Avalanche L1 There should only be one canonical `TeleporterRegistry` deployed for each chain, but if one does not exist, it is recommended to deploy the registry so Teleporter dApps can always use the most recent Teleporter version available. The registry does not need to be deployed to the same address on every chain, and therefore does not need a Nick's method transaction. To deploy, run the following command from the root of the repository: -``` -./scripts/deploy_registry.sh --version \ --rpc-url \ --private-key \ [OPTIONS] +```bash +./scripts/deploy_registry.sh --version --rpc-url --private-key [OPTIONS] ``` Required arguments: @@ -225,7 +179,7 @@ Required arguments: To generate Golang ABI bindings for the Solidity smart contracts, run: -``` +```bash ./scripts/abi_go_bindings.sh ``` @@ -233,10 +187,8 @@ The auto-generated bindings should be written under the `abi-bindings/` director ## Docs -- [Teleporter Protocol Overview](https://github.com/ava-labs/teleporter/blob/main/contracts/src/Teleporter/README.md) -- [Cross Chain Applications](https://github.com/ava-labs/teleporter/blob/main/contracts/src/CrossChainApplications/README.md) -- [Getting Started](https://github.com/ava-labs/teleporter/blob/main/contracts/src/CrossChainApplications/GETTING_STARTED.md) -- [Teleporter Upgradeability](https://github.com/ava-labs/teleporter/blob/main/contracts/src/Teleporter/upgrades/README.md) +- [Teleporter Protocol Overview](https://github.com/ava-labs/teleporter/blob/main/contracts/teleporter/README.md) +- [Teleporter Registry and Upgrades](https://github.com/ava-labs/teleporter/blob/main/contracts/teleporter/registry/README.md) - [Contract Deployment](https://github.com/ava-labs/teleporter/blob/main/utils/contract-deployment/README.md) - [Teleporter CLI](https://github.com/ava-labs/teleporter/blob/main/cmd/teleporter-cli/README.md) @@ -244,4 +196,5 @@ The auto-generated bindings should be written under the `abi-bindings/` director - List of blockchain signing cryptography algorithms [here](http://ethanfast.com/top-crypto.html). - Background on stateful precompiles [here](https://medium.com/avalancheavax/customizing-the-evm-with-stateful-precompiles-f44a34f39efd). -- Background on BLS signature aggregation [here](https://crypto.stanford.edu/~dabo/pubs/papers/BLSmultisig.html). \ No newline at end of file +- Background on BLS signature aggregation [here](https://crypto.stanford.edu/~dabo/pubs/papers/BLSmultisig.html). + diff --git a/content/docs/cross-chain/teleporter/getting-started.mdx b/content/docs/cross-chain/teleporter/getting-started.mdx index a1913ecc5d5..355b2c54250 100644 --- a/content/docs/cross-chain/teleporter/getting-started.mdx +++ b/content/docs/cross-chain/teleporter/getting-started.mdx @@ -7,10 +7,10 @@ Dive deeper into Teleporter and kickstart your journey in building cross-chain d - Note: All example applications in the [examples](https://github.com/ava-labs/teleporter/blob/main/contracts/src/CrossChainApplications/examples/) directory are meant for education purposes only and are not audited. The example contracts are not intended for use in production environments. + Note: All example applications in the [examples](https://github.com/ava-labs/teleporter/tree/example-sequential-message-app/contracts/sequential-delivery-example) directory are meant for education purposes only and are not audited. The example contracts are not intended for use in production environments. -This section walks through how to build an example cross-chain application on top of the Teleporter protocol, recreating the `ExampleCrossChainMessenger` [contract](https://github.com/ava-labs/teleporter/blob/main/contracts/src/CrossChainApplications/examples/ExampleMessenger/ExampleCrossChainMessenger.sol) that sends arbitrary string data from one chain to another. Note that this tutorial is meant for education purposes only. The resulting code is not intended for use in production environments. +This section walks through how to build an example cross-chain application on top of the Teleporter protocol, recreating the `ExampleCrossChainMessenger` [contract](https://github.com/ava-labs/teleporter/tree/example-sequential-message-app/contracts/sequential-delivery-example) that sends arbitrary string data from one chain to another. Note that this tutorial is meant for education purposes only. The resulting code is not intended for use in production environments. Step 1: Create Initial Contract[​](#step-1-create-initial-contract "Direct link to heading") -------------------------------------------------------------------------------------------- @@ -258,7 +258,7 @@ Next, add a function to the contract called `getCurrentMessage` that allows user Step 5: Upgrade Support[​](#step-5-upgrade-support "Direct link to heading") ---------------------------------------------------------------------------- -At this point, the contract is now fully usable, and can be used to send arbitrary string data between chains. However, there are a few more modifications that need to be made to support upgrades to `TeleporterMessenger`. For a more in-depth explanation of how to support upgrades, see the Upgrades README [here](https://github.com/ava-labs/teleporter/blob/main/contracts/src/Teleporter/upgrades/README.md). +At this point, the contract is now fully usable, and can be used to send arbitrary string data between chains. However, there are a few more modifications that need to be made to support upgrades to `TeleporterMessenger`. For a more in-depth explanation of how to support upgrades, see the Upgrades README [here](https://github.com/ava-labs/teleporter/blob/main/contracts/teleporter/registry/UPGRADING.md). The first change to make is to inherit from `TeleporterOwnerUpgradeable` instead of `ITeleporterReceiver`. `TeleporterOwnerUpgradeable` integrates with the `TeleporterRegistry` via `TeleporterUpgradeable` to easily utilize the latest `TeleporterMessenger` implementation. `TeleporterOwnerUpgradeable` also ensures that only an admin address for managing Teleporter versions, specified by the constructor argument `teleporterManager`, is able to upgrade the `TeleporterMessenger` implementation used by the contract. @@ -318,18 +318,18 @@ And finally, change `receiveTeleporterMessage` to `_receiveTeleporterMessage`, m - require(msg.sender == address(teleporterMessenger), "Unauthorized."); ``` -`MyExampleCrossChainMessenger` is now a working cross-chain dApp built on top of Teleporter! Full example [here](https://github.com/ava-labs/teleporter/blob/main/contracts/src/CrossChainApplications/ExampleMessenger/ExampleCrossChainMessenger.sol). +`MyExampleCrossChainMessenger` is now a working cross-chain dApp built on top of Teleporter! Full example [here](https://github.com/ava-labs/teleporter/tree/example-sequential-message-app/contracts/sequential-delivery-example). Step 6: Testing[​](#step-6-testing "Direct link to heading") ------------------------------------------------------------ -For testing, `scripts/local/e2e_test.sh` sets up a local test environment consisting of three subnets deployed with Teleporter, and a lightweight inline relayer implementation to facilitate cross chain message delivery. An end-to-end test for `ExampleCrossChainMessenger` is included in `tests/flows/example_messenger.go`, which performs the following: +For testing, `scripts/local/e2e_test.sh` sets up a local test environment consisting of three avalanche-l1s deployed with Teleporter, and a lightweight inline relayer implementation to facilitate cross chain message delivery. An end-to-end test for `ExampleCrossChainMessenger` is included in `tests/flows/example_messenger.go`, which performs the following: -1. Deploys the [ExampleERC20](https://github.com/ava-labs/teleporter/blob/main/contracts/src/CrossChainApplications/@mocks/ExampleERC20.sol) token to subnet A. -2. Deploys `ExampleCrossChainMessenger` to both subnets A and B. -3. Approves the cross-chain messenger on subnet A to spend ERC20 tokens from the default address. -4. Sends `"Hello, world!"` from subnet A to subnet B's cross-chain messenger to receive. -5. Calls `getCurrentMessage` on subnet B to make sure the right message and sender are received. +1. Deploys the [ExampleERC20](https://github.com/ava-labs/teleporter/blob/main/contracts/mocks/ExampleERC20.sol) token to avalanche-l1 A. +2. Deploys `ExampleCrossChainMessenger` to both avalanche-l1s A and B. +3. Approves the cross-chain messenger on avalanche-l1 A to spend ERC20 tokens from the default address. +4. Sends `"Hello, world!"` from avalanche-l1 A to avalanche-l1 B's cross-chain messenger to receive. +5. Calls `getCurrentMessage` on avalanche-l1 B to make sure the right message and sender are received. To run this test against the newly created `MyExampleCrossChainMessenger`, first generate the ABI Go bindings by running `./scripts/abi_bindings.sh --contract MyExampleCrossChainMessenger` from the root of this repository. Then, add to the generated Go package the `SendMessageRequiredGas` constant, which is required by the tests, in a new file `abi-bindings/go/CrossChainApplications/MyExampleCrossChainMessenger/MyExampleCrossChainMessenger/constants.go`: @@ -356,3 +356,4 @@ Finally, from the root of the repository, invoke the tests with an extra bit of GINKGO_FOCUS="Example cross chain messenger" scripts/local/e2e_test.sh ``` + diff --git a/content/docs/cross-chain/teleporter/overview.mdx b/content/docs/cross-chain/teleporter/overview.mdx index df4cdea3a9d..78643fe585e 100644 --- a/content/docs/cross-chain/teleporter/overview.mdx +++ b/content/docs/cross-chain/teleporter/overview.mdx @@ -1,24 +1,10 @@ --- -title: Overview -description: Learn about Teleporter, a protocol for cross-chain communication between EVM Chains. +title: What is Teleporter? +description: Teleporter is a messaging protocol built on top of Avalanche Warp Messaging that provides a developer-friendly interface for sending and receiving cross-chain messages from the EVM. --- - -Dive deeper into Teleporter and kickstart your journey in building cross-chain dApps by enrolling in our [Teleporter course](https://academy.avax.network/course/teleporter). - -- [Teleporter Protocol](#teleporter-protocol) - - [Overview](#overview) - - [Data Flow](#data-flow) - - [Properties](#properties) - - [Fees](#fees) - - [Message Receipts and Fee Redemption](#message-receipts-and-fee-redemption) - - [Required Interface](#required-interface) - - [Teleporter Contract Deployment](#teleporter-contract-deployment) - - [Message Delivery and Execution](#message-delivery-and-execution) - -Overview[​](#overview "Direct link to heading") ------------------------------------------------ +## Overview Teleporter is a messaging protocol built on top of [Avalanche Warp Messaging (AWM)](/cross-chain/avalanche-warp-messaging/overview) that provides a developer-friendly interface for sending and receiving cross-chain messages from within the EVM. @@ -33,33 +19,32 @@ The `ITeleporterReceiver` interface provides a single method. All contracts that > Note: If a contract does not implement `ITeleporterReceiver`, but instead implements [fallback](https://docs.soliditylang.org/en/latest/contracts.html#fallback-function), the fallback function will be called when Teleporter attempts to perform message execution. The message execution is marked as failed if the fallback function reverts, otherwise it is marked as successfully executed. -Data Flow[​](#data-flow "Direct link to heading") -------------------------------------------------- +## Data Flow -![](/images/teleporter1.png) +
+ +
-Properties[​](#properties "Direct link to heading") ---------------------------------------------------- +## Properties Teleporter provides a handful of useful properties to cross-chain applications that Avalanche Warp Messages do not provide by default. These include: -1. Replay protection: Teleporter ensures that a cross-chain message is not delivered multiple times. -2. Retries: In certain edge cases when there is significant validator churn, it is possible for an Avalanche Warp Message to be dropped before a valid aggregate signature is created for it. Teleporter ensures that messages can still be delivered even in this event by allowing for retries of previously submitted messages. -3. Relay incentivization: Teleporter provides a mechanism for messages to optionally incentivize relayers to perform the necessary signature aggregation and pay the transaction fee to broadcast the signed message on the destination chain. -4. Allowed relayers: Teleporter allows users to specify a list of `allowedRelayerAddresses`, where only the specified addresses can relay and deliver the Teleporter message. Leaving this list empty allows all relayers to deliver. -5. Message execution: Teleporter enables cross-chain messages to have direct effect on their destination chain by using `evm.Call()` to invoke the `receiveTeleporterMessage` function of destination contracts that implement the `ITeleporterReceiver` interface. +1. Replay protection: Teleporter ensures that a cross-chain message is not delivered multiple times. +2. Retries: In certain edge cases when there is significant validator churn, it is possible for an Avalanche Warp Message to be dropped before a valid aggregate signature is created for it. Teleporter ensures that messages can still be delivered even in this event by allowing for retries of previously submitted messages. +3. Relay incentivization: Teleporter provides a mechanism for messages to optionally incentivize relayers to perform the necessary signature aggregation and pay the transaction fee to broadcast the signed message on the destination chain. +4. Allowed relayers: Teleporter allows users to specify a list of `allowedRelayerAddresses`, where only the specified addresses can relay and deliver the Teleporter message. Leaving this list empty allows all relayers to deliver. +5. Message execution: Teleporter enables cross-chain messages to have direct effect on their destination chain by using `evm.Call()` to invoke the `receiveTeleporterMessage` function of destination contracts that implement the `ITeleporterReceiver` interface. -Fees[​](#fees "Direct link to heading") ---------------------------------------- +## Fees Fees can be paid on a per message basis by specifing the ERC20 asset and amount to be used to incentivize a relayer to deliver the message in the call to `sendCrossChainMessage`. The fee amount is transferred into the control of the Teleporter contract (i.e. locked) before the Warp message is sent. The Teleporter contract tracks the fee amount for each message ID it creates. When it subsequently receives a message back from the destination chain of the original message, the new message will have a list of receipts identifying the relayer that delivered the given message ID. At this point, the fee amount originally locked by Teleporter for the given message will be redeemable by the relayer identified in the receipt. If the initial fee amount was not sufficient to incentivize a relayer, it can be added to by using `addFeeAmount`. -### Message Receipts and Fee Redemption[​](#message-receipts-and-fee-redemption "Direct link to heading") +### Message Receipts and Fee Redemption In order to confirm delivery of a Teleporter message from a source chain to a destination chain, a receipt is included in the next Teleporter message sent in the opposite direction, from the destination chain back to the source chain. This receipt contains the message ID of the original message, as well as the reward address that the delivering relayer specified. That reward address is then able to redeem the corresponding reward on the original chain by calling `redeemRelayerRewards`. The following example illustrates this flow: - A Teleporter message is sent from Chain A to Chain B, with a relayer incentive of `10` `USDC`. This message is assigned the ID `1` by the Teleporter contract on Chain A. - - On Chain A, this is done by calling `sendCrossChainMessage`, and providing the `USDC` contract address and amount in the function call. + - On Chain A, this is done by calling `sendCrossChainMessage`, and providing the `USDC` contract address and amount in the function call. - A relayer delivers the message on Chain B by calling `receiveCrossChainMessage` and providing its address, `0x123...` - The Teleporter contract on Chain B stores the relayer address in a receipt for the message ID. - Some time later, a separate Teleporter message is sent from Chain B to Chain A. The Teleporter contract on Chain B includes the receipt for the original message in this new message. @@ -68,17 +53,44 @@ In order to confirm delivery of a Teleporter message from a source chain to a de It is possible for receipts to get "stuck" on the destination chain in the event that Teleporter traffic between two chains is skewed in one direction. In such a scenario, incoming messages on one chain may cause the rate at which receipts are generated to outpace the rate at which they are sent back to the other chain. To mitigate this, the method `sendSpecifiedReceipts` can be called to immediately send the receipts associated with the given message IDs back to the original chain. -Required Interface[​](#required-interface "Direct link to heading") -------------------------------------------------------------------- +## Required Interface Teleporter messages are delivered by calling the `receiveTeleporterMessage` function defined by the `ITeleporterReceiver` interface. Contracts must implement this interface in order to be able to receive messages. The first two parameters of `receiveTeleporterMessage` identify the original sender of the given message on the origin chain and are set by the `TeleporterMessenger`. The third parameter to `receiveTeleporterMessage`, is the raw message payload. Applications using Teleporter are responsible for defining the exact format of this payload in a way that can be decoded on the receiving end. For example, applications may encode an action enum value along with the target method parameters on the sending side, then decode this data and route to the target method within `receiveTeleporterMessage`. See `ERC20Bridge.sol` for an example of this approach. -Teleporter Contract Deployment[​](#teleporter-contract-deployment "Direct link to heading") -------------------------------------------------------------------------------------------- +## Message Delivery and Execution + +Teleporter is able to ensure that messages are considered delivered even if their execution fails (i.e. reverts) by using `evm.Call()` with a pre-defined gas limit to execute the message payload. This gas limit is specified by each message in the call to `sendCrossChainMessage`. Relayers must provide at least enough gas for the sub-call in addition to the standard gas used by a call to `receiveCrossChainMessage`. In the event that a message execution runs out of gas or reverts for any other reason, the hash of the message payload is stored by the receiving Teleporter contract instance. This allows for the message execution to be retried in the future, with possibly a higher gas limit by calling `retryMessageExecution`. Importantly, a message is still considered delivered on its destination chain even if its execution fails. This allows the relayer of the message to redeem their reward for deliverying the message, because they have no control on whether or not its execution will succeed or not so long as they provide sufficient gas to meet the specified `requiredGasLimit`. + +Note that due to [EIP-150](https://eips.ethereum.org/EIPS/eip-150), the lesser of 63/64ths of the remaining gas and the `requiredGasLimit` will be provided to the code executed using `evm.Call()`. This creates an edge case where sufficient gas is provided by the relayer at time of the `requiredGasLimit` check, but less than the `requiredGasLimit` is provided for the message execution. In such a case, the message execution may fail due to having less than the `requiredGasLimit` available, but the message would still be considered received. Such a case is only possible if the remaining 1/64th of the `requiredGasLimit` is sufficient for executing the remaining logic of `receiveCrossChainMessage` so that the top level transaction does not also revert. Based on the current implementation, a message must have a `requiredGasLimit` of over 1,200,000 gas for this to be possible. In order to avoid this case entirely, it is recommended for applications sending Teleporter messages to add a buffer to the `requiredGasLimit` such that 63/64ths of the value passed is sufficient for the message execution. + +## Resending a Message + +If the sending Avalanche L1's validator set changes, then it's possible for the receiving Avalanche L1 to reject the underlying Warp message due to insufficient signing stake. For example, suppose Avalanche L1 A has 5 validators with equal stake weight who all sign a Teleporter message sent to Avalanche L1 B. 100% of Avalanche L1 A's stake has signed the message. Also suppose Avalanche L1 B requires 67% of the sending Avalanche L1's stake to have signed a given Warp message in order for it to be accepted. Before the message can be delivered, however, 5 _more_ validators are added to Avalanche L1 A's validator set (all with the same stake weight as the original validators), meaning that the Teleporter message was signed by _only 50%_ of Avalanche L1 A's stake. Avalanche L1 B will reject this message. + +Once sent on chain, Warp messages cannot be re-signed by a new validator set in such a scenario. Teleporter, however, does support re-signing via the function `retrySendCrossChainMessage`, which can be called for any message that has not been acknowledged as delivered to its destination. Under the hood, this packages the Teleporter message into a brand new Warp message that is re-signed by the current validator set. + +## Teleporter Messenger Contract Deployment + +**Do not deploy the `TeleporterMessenger` contract using `forge create`**. The `TeleporterMessenger` contract must be deployed to the same contract address on every chain. To achieve this, the contract can be deployed using a static transaction that uses Nick's method as documented in [this guide](https://github.com/ava-labs/teleporter/blob/main//utils/contract-deployment/README.md). Alternatively, if creating a new Avalanche L1, the contract can be pre-allocated with the proper address and state in the new chain's [genesis file](https://docs.avax.network/build/subnet/upgrade/customize-a-subnet#setting-the-genesis-allocation). -The `TeleporterMessenger` contract must be deployed to the same contract address on every chain. This is acheived using Nick's keyless transaction method as described [here](https://github.com/ava-labs/teleporter/blob/main/utils/contract-deployment/README.md). As a result, Warp messages sent from the resulting contract address are ensured to have the same payload format as defined by the contract itself. +As an example, to include `TeleporterMessenger` `v1.0.0` in the genesis file, include the following values in the `alloc` settings, as documented at the link above. The `storage` values included below correspond to the two contract values that are initialized as part of the default constructor of `TeleporterMessenger`. These are the `ReentrancyGuard` values set in this [abstract contract](https://github.com/ava-labs/teleporter/blob/main/contracts/utilities/ReentrancyGuards.sol). Future versions of `TeleporterMessenger` may require different storage value intializations. +```json +"alloc": { + "0x253b2784c75e510dD0fF1da844684a1aC0aa5fcf": { + "balance": "0x0", + "code": "0x608060405234801561001057600080fd5b506004361061014d5760003560e01c8063a8898181116100c3578063df20e8bc1161007c578063df20e8bc1461033b578063e69d606a1461034e578063e6e67bd5146103b6578063ebc3b1ba146103f2578063ecc7042814610415578063fc2d61971461041e57600080fd5b8063a8898181146102b2578063a9a85614146102c5578063b771b3bc146102d8578063c473eef8146102e6578063ccb5f8091461031f578063d127dc9b1461033257600080fd5b8063399b77da11610115578063399b77da1461021957806362448850146102395780638245a1b01461024c578063860a3b061461025f578063892bf4121461027f5780638ac0fd041461029f57600080fd5b80630af5b4ff1461015257806322296c3a1461016d5780632bc8b0bf146101825780632ca40f55146101955780632e27c223146101ee575b600080fd5b61015a610431565b6040519081526020015b60405180910390f35b61018061017b366004612251565b610503565b005b61015a61019036600461226e565b6105f8565b6101e06101a336600461226e565b6005602090815260009182526040918290208054835180850190945260018201546001600160a01b03168452600290910154918301919091529082565b604051610164929190612287565b6102016101fc36600461226e565b610615565b6040516001600160a01b039091168152602001610164565b61015a61022736600461226e565b60009081526005602052604090205490565b61015a6102473660046122ae565b61069e565b61018061025a366004612301565b6106fc565b61015a61026d36600461226e565b60066020526000908152604090205481565b61029261028d366004612335565b6108a7565b6040516101649190612357565b6101806102ad366004612377565b6108da565b61015a6102c03660046123af565b610b19565b61015a6102d3366004612426565b610b5c565b6102016005600160991b0181565b61015a6102f43660046124be565b6001600160a01b03918216600090815260096020908152604080832093909416825291909152205490565b61018061032d3660046124f7565b610e03565b61015a60025481565b61015a61034936600461226e565b61123d565b61039761035c36600461226e565b600090815260056020908152604091829020825180840190935260018101546001600160a01b03168084526002909101549290910182905291565b604080516001600160a01b039093168352602083019190915201610164565b6103dd6103c436600461226e565b6004602052600090815260409020805460019091015482565b60408051928352602083019190915201610164565b61040561040036600461226e565b611286565b6040519015158152602001610164565b61015a60035481565b61018061042c36600461251e565b61129c565b600254600090806104fe576005600160991b016001600160a01b0316634213cf786040518163ffffffff1660e01b8152600401602060405180830381865afa158015610481573d6000803e3d6000fd5b505050506040513d601f19601f820116820180604052508101906104a59190612564565b9050806104cd5760405162461bcd60e51b81526004016104c49061257d565b60405180910390fd5b600281905560405181907f1eac640109dc937d2a9f42735a05f794b39a5e3759d681951d671aabbce4b10490600090a25b919050565b3360009081526009602090815260408083206001600160a01b0385168452909152902054806105855760405162461bcd60e51b815260206004820152602860248201527f54656c65706f727465724d657373656e6765723a206e6f2072657761726420746044820152676f2072656465656d60c01b60648201526084016104c4565b3360008181526009602090815260408083206001600160a01b03871680855290835281842093909355518481529192917f3294c84e5b0f29d9803655319087207bc94f4db29f7927846944822773780b88910160405180910390a36105f46001600160a01b03831633836114f7565b5050565b600081815260046020526040812061060f9061155f565b92915050565b6000818152600760205260408120546106825760405162461bcd60e51b815260206004820152602960248201527f54656c65706f727465724d657373656e6765723a206d657373616765206e6f74604482015268081c9958d95a5d995960ba1b60648201526084016104c4565b506000908152600860205260409020546001600160a01b031690565b60006001600054146106c25760405162461bcd60e51b81526004016104c4906125c4565b60026000556106f16106d383612804565b833560009081526004602052604090206106ec90611572565b61167c565b600160005592915050565b60016000541461071e5760405162461bcd60e51b81526004016104c4906125c4565b6002600081815590546107379060408401358435610b19565b6000818152600560209081526040918290208251808401845281548152835180850190945260018201546001600160a01b03168452600290910154838301529081019190915280519192509061079f5760405162461bcd60e51b81526004016104c4906128a7565b6000836040516020016107b29190612b42565b60408051601f19818403018152919052825181516020830120919250146107eb5760405162461bcd60e51b81526004016104c490612b55565b8360400135837f2a211ad4a59ab9d003852404f9c57c690704ee755f3c79d2c2812ad32da99df8868560200151604051610826929190612b9e565b60405180910390a360405163ee5b48eb60e01b81526005600160991b019063ee5b48eb90610858908490600401612c23565b6020604051808303816000875af1158015610877573d6000803e3d6000fd5b505050506040513d601f19601f8201168201806040525081019061089b9190612564565b50506001600055505050565b604080518082019091526000808252602082015260008381526004602052604090206108d390836118bc565b9392505050565b6001600054146108fc5760405162461bcd60e51b81526004016104c4906125c4565b600260005560018054146109225760405162461bcd60e51b81526004016104c490612c36565b60026001558061098c5760405162461bcd60e51b815260206004820152602f60248201527f54656c65706f727465724d657373656e6765723a207a65726f2061646469746960448201526e1bdb985b0819995948185b5bdd5b9d608a1b60648201526084016104c4565b6001600160a01b0382166109b25760405162461bcd60e51b81526004016104c490612c7b565b6000838152600560205260409020546109dd5760405162461bcd60e51b81526004016104c4906128a7565b6000838152600560205260409020600101546001600160a01b03838116911614610a6f5760405162461bcd60e51b815260206004820152603760248201527f54656c65706f727465724d657373656e6765723a20696e76616c69642066656560448201527f20617373657420636f6e7472616374206164647265737300000000000000000060648201526084016104c4565b6000610a7b8383611981565b600085815260056020526040812060020180549293508392909190610aa1908490612ce5565b909155505060008481526005602052604090819020905185917fc1bfd1f1208927dfbd414041dcb5256e6c9ad90dd61aec3249facbd34ff7b3e191610b03916001019081546001600160a01b0316815260019190910154602082015260400190565b60405180910390a2505060018080556000555050565b60408051306020820152908101849052606081018390526080810182905260009060a0016040516020818303038152906040528051906020012090509392505050565b6000600160005414610b805760405162461bcd60e51b81526004016104c4906125c4565b60026000818155905490866001600160401b03811115610ba257610ba2612607565b604051908082528060200260200182016040528015610be757816020015b6040805180820190915260008082526020820152815260200190600190039081610bc05790505b5090508660005b81811015610d6c5760008a8a83818110610c0a57610c0a612cf8565b90506020020135905060006007600083815260200190815260200160002054905080600003610c8a5760405162461bcd60e51b815260206004820152602660248201527f54656c65706f727465724d657373656e6765723a2072656365697074206e6f7460448201526508199bdd5b9960d21b60648201526084016104c4565b610c958d8783610b19565b8214610d095760405162461bcd60e51b815260206004820152603a60248201527f54656c65706f727465724d657373656e6765723a206d6573736167652049442060448201527f6e6f742066726f6d20736f7572636520626c6f636b636861696e00000000000060648201526084016104c4565b6000828152600860209081526040918290205482518084019093528383526001600160a01b03169082018190528651909190879086908110610d4d57610d4d612cf8565b602002602001018190525050505080610d6590612d0e565b9050610bee565b506040805160c0810182528b815260006020820152610df0918101610d96368b90038b018b612d27565b8152602001600081526020018888808060200260200160405190810160405280939291908181526020018383602002808284376000920182905250938552505060408051928352602080840190915290920152508361167c565b60016000559a9950505050505050505050565b6001805414610e245760405162461bcd60e51b81526004016104c490612c36565b60026001556040516306f8253560e41b815263ffffffff8316600482015260009081906005600160991b0190636f82535090602401600060405180830381865afa158015610e76573d6000803e3d6000fd5b505050506040513d6000823e601f3d908101601f19168201604052610e9e9190810190612da3565b9150915080610f015760405162461bcd60e51b815260206004820152602960248201527f54656c65706f727465724d657373656e6765723a20696e76616c69642077617260448201526870206d65737361676560b81b60648201526084016104c4565b60208201516001600160a01b03163014610f785760405162461bcd60e51b815260206004820152603260248201527f54656c65706f727465724d657373656e6765723a20696e76616c6964206f726960448201527167696e2073656e646572206164647265737360701b60648201526084016104c4565b60008260400151806020019051810190610f929190612f40565b90506000610f9e610431565b90508082604001511461100d5760405162461bcd60e51b815260206004820152603160248201527f54656c65706f727465724d657373656e6765723a20696e76616c6964206465736044820152701d1a5b985d1a5bdb8818da185a5b881251607a1b60648201526084016104c4565b8351825160009161101f918490610b19565b600081815260076020526040902054909150156110945760405162461bcd60e51b815260206004820152602d60248201527f54656c65706f727465724d657373656e6765723a206d65737361676520616c7260448201526c1958591e481c9958d95a5d9959609a1b60648201526084016104c4565b6110a2338460a00151611ae9565b6111005760405162461bcd60e51b815260206004820152602960248201527f54656c65706f727465724d657373656e6765723a20756e617574686f72697a6560448201526832103932b630bcb2b960b91b60648201526084016104c4565b61110e818460000151611b61565b6001600160a01b0386161561114557600081815260086020526040902080546001600160a01b0319166001600160a01b0388161790555b60c08301515160005b81811015611192576111828488600001518760c00151848151811061117557611175612cf8565b6020026020010151611bd3565b61118b81612d0e565b905061114e565b50604080518082018252855181526001600160a01b038916602080830191909152885160009081526004909152919091206111cc91611cfb565b336001600160a01b03168660000151837f292ee90bbaf70b5d4936025e09d56ba08f3e421156b6a568cf3c2840d9343e348a8860405161120d929190613150565b60405180910390a460e0840151511561122f5761122f82876000015186611d57565b505060018055505050505050565b600254600090806112605760405162461bcd60e51b81526004016104c49061257d565b600060035460016112719190612ce5565b905061127e828583610b19565b949350505050565b600081815260076020526040812054151561060f565b60018054146112bd5760405162461bcd60e51b81526004016104c490612c36565b60026001819055546000906112d59084908435610b19565b600081815260066020526040902054909150806113045760405162461bcd60e51b81526004016104c4906128a7565b80836040516020016113169190612b42565b60405160208183030381529060405280519060200120146113495760405162461bcd60e51b81526004016104c490612b55565b600061135b6080850160608601612251565b6001600160a01b03163b116113cf5760405162461bcd60e51b815260206004820152603460248201527f54656c65706f727465724d657373656e6765723a2064657374696e6174696f6e604482015273206164647265737320686173206e6f20636f646560601b60648201526084016104c4565b604051849083907f34795cc6b122b9a0ae684946319f1e14a577b4e8f9b3dda9ac94c21a54d3188c90600090a360008281526006602090815260408083208390558691611420918701908701612251565b61142d60e0870187613174565b60405160240161144094939291906131ba565b60408051601f198184030181529190526020810180516001600160e01b031663643477d560e11b179052905060006114886114816080870160608801612251565b5a84611e8a565b9050806114eb5760405162461bcd60e51b815260206004820152602b60248201527f54656c65706f727465724d657373656e6765723a20726574727920657865637560448201526a1d1a5bdb8819985a5b195960aa1b60648201526084016104c4565b50506001805550505050565b6040516001600160a01b03831660248201526044810182905261155a90849063a9059cbb60e01b906064015b60408051601f198184030181529190526020810180516001600160e01b03166001600160e01b031990931692909217909152611ea4565b505050565b8054600182015460009161060f916131e5565b6060600061158960056115848561155f565b611f76565b9050806000036115d85760408051600080825260208201909252906115d0565b60408051808201909152600080825260208201528152602001906001900390816115a95790505b509392505050565b6000816001600160401b038111156115f2576115f2612607565b60405190808252806020026020018201604052801561163757816020015b60408051808201909152600080825260208201528152602001906001900390816116105790505b50905060005b828110156115d05761164e85611f8c565b82828151811061166057611660612cf8565b60200260200101819052508061167590612d0e565b905061163d565b600080611687610431565b9050600060036000815461169a90612d0e565b919050819055905060006116b383876000015184610b19565b90506000604051806101000160405280848152602001336001600160a01b031681526020018860000151815260200188602001516001600160a01b0316815260200188606001518152602001886080015181526020018781526020018860a00151815250905060008160405160200161172c91906131f8565b60405160208183030381529060405290506000808960400151602001511115611794576040890151516001600160a01b031661177a5760405162461bcd60e51b81526004016104c490612c7b565b604089015180516020909101516117919190611981565b90505b6040805180820182528a820151516001600160a01b039081168252602080830185905283518085018552865187830120815280820184815260008a815260058452869020915182555180516001830180546001600160a01b03191691909516179093559101516002909101558a51915190919086907f2a211ad4a59ab9d003852404f9c57c690704ee755f3c79d2c2812ad32da99df890611838908890869061320b565b60405180910390a360405163ee5b48eb60e01b81526005600160991b019063ee5b48eb9061186a908690600401612c23565b6020604051808303816000875af1158015611889573d6000803e3d6000fd5b505050506040513d601f19601f820116820180604052508101906118ad9190612564565b50939998505050505050505050565b60408051808201909152600080825260208201526118d98361155f565b82106119315760405162461bcd60e51b815260206004820152602160248201527f5265636569707451756575653a20696e646578206f7574206f6620626f756e646044820152607360f81b60648201526084016104c4565b8260020160008385600001546119479190612ce5565b81526020808201929092526040908101600020815180830190925280548252600101546001600160a01b0316918101919091529392505050565b6040516370a0823160e01b815230600482015260009081906001600160a01b038516906370a0823190602401602060405180830381865afa1580156119ca573d6000803e3d6000fd5b505050506040513d601f19601f820116820180604052508101906119ee9190612564565b9050611a056001600160a01b038516333086612058565b6040516370a0823160e01b81523060048201526000906001600160a01b038616906370a0823190602401602060405180830381865afa158015611a4c573d6000803e3d6000fd5b505050506040513d601f19601f82011682018060405250810190611a709190612564565b9050818111611ad65760405162461bcd60e51b815260206004820152602c60248201527f5361666545524332305472616e7366657246726f6d3a2062616c616e6365206e60448201526b1bdd081a5b98dc99585cd95960a21b60648201526084016104c4565b611ae082826131e5565b95945050505050565b60008151600003611afc5750600161060f565b815160005b81811015611b5657846001600160a01b0316848281518110611b2557611b25612cf8565b60200260200101516001600160a01b031603611b465760019250505061060f565b611b4f81612d0e565b9050611b01565b506000949350505050565b80600003611bc15760405162461bcd60e51b815260206004820152602760248201527f54656c65706f727465724d657373656e6765723a207a65726f206d657373616760448201526665206e6f6e636560c81b60648201526084016104c4565b60009182526007602052604090912055565b6000611be484848460000151610b19565b6000818152600560209081526040918290208251808401845281548152835180850190945260018201546001600160a01b031684526002909101548383015290810191909152805191925090611c3b575050505050565b60008281526005602090815260408083208381556001810180546001600160a01b03191690556002018390558382018051830151878401516001600160a01b0390811686526009855283862092515116855292528220805491929091611ca2908490612ce5565b9250508190555082602001516001600160a01b031684837fd13a7935f29af029349bed0a2097455b91fd06190a30478c575db3f31e00bf578460200151604051611cec919061321e565b60405180910390a45050505050565b6001820180548291600285019160009182611d1583612d0e565b90915550815260208082019290925260400160002082518155910151600190910180546001600160a01b0319166001600160a01b039092169190911790555050565b80608001515a1015611db95760405162461bcd60e51b815260206004820152602560248201527f54656c65706f727465724d657373656e6765723a20696e73756666696369656e604482015264742067617360d81b60648201526084016104c4565b80606001516001600160a01b03163b600003611dda5761155a838383612096565b602081015160e0820151604051600092611df892869260240161323e565b60408051601f198184030181529190526020810180516001600160e01b031663643477d560e11b17905260608301516080840151919250600091611e3d919084611e8a565b905080611e5657611e4f858585612096565b5050505050565b604051849086907f34795cc6b122b9a0ae684946319f1e14a577b4e8f9b3dda9ac94c21a54d3188c90600090a35050505050565b60008060008084516020860160008989f195945050505050565b6000611ef9826040518060400160405280602081526020017f5361666545524332303a206c6f772d6c6576656c2063616c6c206661696c6564815250856001600160a01b031661210b9092919063ffffffff16565b80519091501561155a5780806020019051810190611f179190613268565b61155a5760405162461bcd60e51b815260206004820152602a60248201527f5361666545524332303a204552433230206f7065726174696f6e20646964206e6044820152691bdd081cdd58d8d9595960b21b60648201526084016104c4565b6000818310611f8557816108d3565b5090919050565b604080518082019091526000808252602082015281546001830154819003611ff65760405162461bcd60e51b815260206004820152601960248201527f5265636569707451756575653a20656d7074792071756575650000000000000060448201526064016104c4565b60008181526002840160208181526040808420815180830190925280548252600180820180546001600160a01b03811685870152888852959094529490556001600160a01b031990921690559061204e908390612ce5565b9093555090919050565b6040516001600160a01b03808516602483015283166044820152606481018290526120909085906323b872dd60e01b90608401611523565b50505050565b806040516020016120a791906131f8565b60408051601f1981840301815282825280516020918201206000878152600690925291902055829084907f4619adc1017b82e02eaefac01a43d50d6d8de4460774bc370c3ff0210d40c985906120fe9085906131f8565b60405180910390a3505050565b606061127e848460008585600080866001600160a01b031685876040516121329190613283565b60006040518083038185875af1925050503d806000811461216f576040519150601f19603f3d011682016040523d82523d6000602084013e612174565b606091505b509150915061218587838387612190565b979650505050505050565b606083156121ff5782516000036121f8576001600160a01b0385163b6121f85760405162461bcd60e51b815260206004820152601d60248201527f416464726573733a2063616c6c20746f206e6f6e2d636f6e747261637400000060448201526064016104c4565b508161127e565b61127e83838151156122145781518083602001fd5b8060405162461bcd60e51b81526004016104c49190612c23565b6001600160a01b038116811461224357600080fd5b50565b80356104fe8161222e565b60006020828403121561226357600080fd5b81356108d38161222e565b60006020828403121561228057600080fd5b5035919050565b828152606081016108d3602083018480516001600160a01b03168252602090810151910152565b6000602082840312156122c057600080fd5b81356001600160401b038111156122d657600080fd5b820160e081850312156108d357600080fd5b600061010082840312156122fb57600080fd5b50919050565b60006020828403121561231357600080fd5b81356001600160401b0381111561232957600080fd5b61127e848285016122e8565b6000806040838503121561234857600080fd5b50508035926020909101359150565b815181526020808301516001600160a01b0316908201526040810161060f565b60008060006060848603121561238c57600080fd5b83359250602084013561239e8161222e565b929592945050506040919091013590565b6000806000606084860312156123c457600080fd5b505081359360208301359350604090920135919050565b60008083601f8401126123ed57600080fd5b5081356001600160401b0381111561240457600080fd5b6020830191508360208260051b850101111561241f57600080fd5b9250929050565b60008060008060008086880360a081121561244057600080fd5b8735965060208801356001600160401b038082111561245e57600080fd5b61246a8b838c016123db565b90985096508691506040603f198401121561248457600080fd5b60408a01955060808a013592508083111561249e57600080fd5b50506124ac89828a016123db565b979a9699509497509295939492505050565b600080604083850312156124d157600080fd5b82356124dc8161222e565b915060208301356124ec8161222e565b809150509250929050565b6000806040838503121561250a57600080fd5b823563ffffffff811681146124dc57600080fd5b6000806040838503121561253157600080fd5b8235915060208301356001600160401b0381111561254e57600080fd5b61255a858286016122e8565b9150509250929050565b60006020828403121561257657600080fd5b5051919050565b60208082526027908201527f54656c65706f727465724d657373656e6765723a207a65726f20626c6f636b636040820152661a185a5b88125160ca1b606082015260800190565b60208082526023908201527f5265656e7472616e63794775617264733a2073656e646572207265656e7472616040820152626e637960e81b606082015260800190565b634e487b7160e01b600052604160045260246000fd5b604080519081016001600160401b038111828210171561263f5761263f612607565b60405290565b60405160c081016001600160401b038111828210171561263f5761263f612607565b60405161010081016001600160401b038111828210171561263f5761263f612607565b604051601f8201601f191681016001600160401b03811182821017156126b2576126b2612607565b604052919050565b6000604082840312156126cc57600080fd5b6126d461261d565b905081356126e18161222e565b808252506020820135602082015292915050565b60006001600160401b0382111561270e5761270e612607565b5060051b60200190565b600082601f83011261272957600080fd5b8135602061273e612739836126f5565b61268a565b82815260059290921b8401810191818101908684111561275d57600080fd5b8286015b848110156127815780356127748161222e565b8352918301918301612761565b509695505050505050565b60006001600160401b038211156127a5576127a5612607565b50601f01601f191660200190565b600082601f8301126127c457600080fd5b81356127d26127398261278c565b8181528460208386010111156127e757600080fd5b816020850160208301376000918101602001919091529392505050565b600060e0823603121561281657600080fd5b61281e612645565b8235815261282e60208401612246565b602082015261284036604085016126ba565b60408201526080830135606082015260a08301356001600160401b038082111561286957600080fd5b61287536838701612718565b608084015260c085013591508082111561288e57600080fd5b5061289b368286016127b3565b60a08301525092915050565b60208082526026908201527f54656c65706f727465724d657373656e6765723a206d657373616765206e6f7460408201526508199bdd5b9960d21b606082015260800190565b6000808335601e1984360301811261290457600080fd5b83016020810192503590506001600160401b0381111561292357600080fd5b8060051b360382131561241f57600080fd5b8183526000602080850194508260005b858110156129735781356129588161222e565b6001600160a01b031687529582019590820190600101612945565b509495945050505050565b6000808335601e1984360301811261299557600080fd5b83016020810192503590506001600160401b038111156129b457600080fd5b8060061b360382131561241f57600080fd5b8183526000602080850194508260005b858110156129735781358752828201356129ef8161222e565b6001600160a01b03168784015260409687019691909101906001016129d6565b6000808335601e19843603018112612a2657600080fd5b83016020810192503590506001600160401b03811115612a4557600080fd5b80360382131561241f57600080fd5b81835281816020850137506000828201602090810191909152601f909101601f19169091010190565b6000610100823584526020830135612a948161222e565b6001600160a01b0316602085015260408381013590850152612ab860608401612246565b6001600160a01b0316606085015260808381013590850152612add60a08401846128ed565b8260a0870152612af08387018284612935565b92505050612b0160c084018461297e565b85830360c0870152612b148382846129c6565b92505050612b2560e0840184612a0f565b85830360e0870152612b38838284612a54565b9695505050505050565b6020815260006108d36020830184612a7d565b60208082526029908201527f54656c65706f727465724d657373656e6765723a20696e76616c6964206d65736040820152680e6c2ceca40d0c2e6d60bb1b606082015260800190565b606081526000612bb16060830185612a7d565b90506108d3602083018480516001600160a01b03168252602090810151910152565b60005b83811015612bee578181015183820152602001612bd6565b50506000910152565b60008151808452612c0f816020860160208601612bd3565b601f01601f19169290920160200192915050565b6020815260006108d36020830184612bf7565b60208082526025908201527f5265656e7472616e63794775617264733a207265636569766572207265656e7460408201526472616e637960d81b606082015260800190565b60208082526034908201527f54656c65706f727465724d657373656e6765723a207a65726f2066656520617360408201527373657420636f6e7472616374206164647265737360601b606082015260800190565b634e487b7160e01b600052601160045260246000fd5b8082018082111561060f5761060f612ccf565b634e487b7160e01b600052603260045260246000fd5b600060018201612d2057612d20612ccf565b5060010190565b600060408284031215612d3957600080fd5b6108d383836126ba565b80516104fe8161222e565b600082601f830112612d5f57600080fd5b8151612d6d6127398261278c565b818152846020838601011115612d8257600080fd5b61127e826020830160208701612bd3565b805180151581146104fe57600080fd5b60008060408385031215612db657600080fd5b82516001600160401b0380821115612dcd57600080fd5b9084019060608287031215612de157600080fd5b604051606081018181108382111715612dfc57612dfc612607565b604052825181526020830151612e118161222e565b6020820152604083015182811115612e2857600080fd5b612e3488828601612d4e565b6040830152509350612e4b91505060208401612d93565b90509250929050565b600082601f830112612e6557600080fd5b81516020612e75612739836126f5565b82815260059290921b84018101918181019086841115612e9457600080fd5b8286015b84811015612781578051612eab8161222e565b8352918301918301612e98565b600082601f830112612ec957600080fd5b81516020612ed9612739836126f5565b82815260069290921b84018101918181019086841115612ef857600080fd5b8286015b848110156127815760408189031215612f155760008081fd5b612f1d61261d565b8151815284820151612f2e8161222e565b81860152835291830191604001612efc565b600060208284031215612f5257600080fd5b81516001600160401b0380821115612f6957600080fd5b908301906101008286031215612f7e57600080fd5b612f86612667565b82518152612f9660208401612d43565b602082015260408301516040820152612fb160608401612d43565b60608201526080830151608082015260a083015182811115612fd257600080fd5b612fde87828601612e54565b60a08301525060c083015182811115612ff657600080fd5b61300287828601612eb8565b60c08301525060e08301518281111561301a57600080fd5b61302687828601612d4e565b60e08301525095945050505050565b600081518084526020808501945080840160005b838110156129735781516001600160a01b031687529582019590820190600101613049565b600081518084526020808501945080840160005b83811015612973576130a8878351805182526020908101516001600160a01b0316910152565b6040969096019590820190600101613082565b60006101008251845260018060a01b0360208401511660208501526040830151604085015260608301516130fa60608601826001600160a01b03169052565b506080830151608085015260a08301518160a086015261311c82860182613035565b91505060c083015184820360c0860152613136828261306e565b91505060e083015184820360e0860152611ae08282612bf7565b6001600160a01b038316815260406020820181905260009061127e908301846130bb565b6000808335601e1984360301811261318b57600080fd5b8301803591506001600160401b038211156131a557600080fd5b60200191503681900382131561241f57600080fd5b8481526001600160a01b0384166020820152606060408201819052600090612b389083018486612a54565b8181038181111561060f5761060f612ccf565b6020815260006108d360208301846130bb565b606081526000612bb160608301856130bb565b81516001600160a01b03168152602080830151908201526040810161060f565b8381526001600160a01b0383166020820152606060408201819052600090611ae090830184612bf7565b60006020828403121561327a57600080fd5b6108d382612d93565b60008251613295818460208701612bd3565b919091019291505056fea2646970667358221220586881dd1413fe17197100ceb55646481dae802ef65d37df603c3915f51a4b6364736f6c63430008120033", + "storage": { + "0x0000000000000000000000000000000000000000000000000000000000000000": "0x0000000000000000000000000000000000000000000000000000000000000001", + "0x0000000000000000000000000000000000000000000000000000000000000001": "0x0000000000000000000000000000000000000000000000000000000000000001" + }, + "nonce": 1 + }, + "0x618FEdD9A45a8C456812ecAAE70C671c6249DfaC": { + "balance": "0x0", + "nonce": 1 + } +} +``` -Message Delivery and Execution[​](#message-delivery-and-execution "Direct link to heading") -------------------------------------------------------------------------------------------- +The values above are taken from the `v1.0.0` [release artifacts](https://github.com/ava-labs/teleporter/releases/tag/v1.0.0). The contract address, deployed bytecode, and deployer address are unique per major release. All of the other values should remain the same. -Teleporter is able to ensure that messages are considered delivered even if their execution fails (i.e. reverts) by using `evm.Call()` with a pre-defined gas limit to execute the message payload. This gas limit is specified by each message in the call to `sendCrossChainMessage`. Relayers must provide at least enough gas for the sub-call in addition to the standard gas used by a call to `receiveCrossChainMessage`. In the event that a message execution runs out of gas or reverts for any other reason, the hash of the message payload is stored by the receiving Teleporter contract instance. This allows for the message execution to be retried in the future, with possibly a higher gas limit by calling `retryMessageExecution`. Importantly, a message is still considered delivered on its destination chain even if its execution fails. This allows the relayer of the message to redeem their reward for deliverying the message, because they have no control on whether or not its execution will succeed or not so long as they provide sufficient gas to meet the specified `requiredGasLimit`. \ No newline at end of file diff --git a/content/docs/cross-chain/teleporter/teleporter-on-devnet.mdx b/content/docs/cross-chain/teleporter/teleporter-on-devnet.mdx index 3b4fc5e6b27..de14eabc99c 100644 --- a/content/docs/cross-chain/teleporter/teleporter-on-devnet.mdx +++ b/content/docs/cross-chain/teleporter/teleporter-on-devnet.mdx @@ -1,13 +1,13 @@ --- -title: Teleporter Subnets on Devnet -description: This how-to guide focuses on deploying Teleporter-enabled Subnets to a Devnet. +title: Teleporter Avalanche L1s on Devnet +description: This how-to guide focuses on deploying Teleporter-enabled Avalanche L1s to a Devnet. --- -After this tutorial, you would have created a Devnet and deployed two Subnets in it, and have enabled them to cross-communicate with each other and with the C-Chain through Teleporter and the underlying Warp technology. +After this tutorial, you would have created a Devnet and deployed two Avalanche L1s in it, and have enabled them to cross-communicate with each other and with the C-Chain through Teleporter and the underlying Warp technology. For more information on cross chain messaging through Teleporter and Warp, check: -- [Cross Chain References](/cross-chain/quicklinks) +- [Cross Chain References](/cross-chain) Note that currently only [Subnet-EVM](https://github.com/ava-labs/subnet-evm) and [Subnet-EVM-Based](/virtual-machines/evm-customization/introduction) virtual machines support Teleporter. @@ -19,12 +19,12 @@ Before we begin, you will need to have: Note: the tutorial uses AWS hosts, but Devnets can also be created and operated in other supported cloud providers, such as GCP. -Create Subnets Configurations[​](#create-subnets-configurations "Direct link to heading") +Create Avalanche L1s Configurations[​](#create-avalanche-l1s-configurations "Direct link to heading") ----------------------------------------------------------------------------------------- -For this section we will follow this [steps](/tooling/cross-chain/teleporter-local-network#create-subnets-configurations), to create two Teleporter-enabled Subnets, `` and ``. +For this section we will follow this [steps](/tooling/cross-chain/teleporter-local-network#create-avalanche-l1s-configurations), to create two Teleporter-enabled Avalanche L1s, `` and ``. -Create a Devnet and Deploy a Subnet in It[​](#create-a-devnet-and-deploy-a-subnet-in-it "Direct link to heading") +Create a Devnet and Deploy an Avalanche L1 in It[​](#create-a-devnet-and-deploy-a-avalanche-l1-in-it "Direct link to heading") ----------------------------------------------------------------------------------------------------------------- Let's use the `devnet wiz` command to create a devnet `` and deploy `` in it. @@ -39,40 +39,40 @@ Creating the devnet... Creating new EC2 instance(s) on AWS... ... -Deploying [subnet1] to Cluster +Deploying [Avalanche L1] to Cluster ... configuring AWM RElayer on host i-0f1815c016b555fcc -Setting the nodes as subnet trackers +Setting the nodes as Avalanche L1 trackers ... -Setting up teleporter on subnet +Setting up teleporter on Avalanche L1 -Teleporter Messenger successfully deployed to subnet1 (0x253b2784c75e510dD0fF1da844684a1aC0aa5fcf) -Teleporter Registry successfully deployed to subnet1 (0xb623C4495220C603D0A939D32478F55891a61750) +Teleporter Messenger successfully deployed to Avalanche L1 (0x253b2784c75e510dD0fF1da844684a1aC0aa5fcf) +Teleporter Registry successfully deployed to Avalanche L1 (0xb623C4495220C603D0A939D32478F55891a61750) Teleporter Messenger successfully deployed to c-chain (0x253b2784c75e510dD0fF1da844684a1aC0aa5fcf) Teleporter Registry successfully deployed to c-chain (0x5DB9A7629912EBF95876228C24A848de0bfB43A9) Starting AWM Relayer Service -setting AWM Relayer on host i-0f1815c016b555fcc to relay subnet subnet1 +setting AWM Relayer on host i-0f1815c016b555fcc to relay L1 chain1 updating configuration file ~/.avalanche-cli/nodes/i-0f1815c016b555fcc/services/awm-relayer/awm-relayer-config.json -Devnet is successfully created and is now validating subnet subnet1! +Devnet is successfully created and is now validating blockchain chain1! -Subnet RPC URL: http://67.202.23.231:9650/ext/bc/fqcM24LNb3kTV7KD1mAvUJXYy5XunwP8mrE44YuNwPjgZHY6p/rpc +Avalanche L1 RPC URL: http://67.202.23.231:9650/ext/bc/fqcM24LNb3kTV7KD1mAvUJXYy5XunwP8mrE44YuNwPjgZHY6p/rpc ✓ Cluster information YAML file can be found at ~/.avalanche-cli/nodes/inventories//clusterInfo.yaml at local host ``` Notice some details here: -- Two smart contracts are deployed to the Subnet: Teleporter Messenger and Teleporter Registry +- Two smart contracts are deployed to the Avalanche L1: Teleporter Messenger and Teleporter Registry - Both Teleporter smart contracts are also deployed to `C-Chain` -- [AWM Teleporter Relayer](https://github.com/ava-labs/awm-relayer) is installed and configured as a service into one of the nodes (A Relayer [listens](/cross-chain/teleporter/overview#data-flow) for new messages being generated on a source Subnet and sends them to the destination Subnet.) +- [AWM Teleporter Relayer](https://github.com/ava-labs/awm-relayer) is installed and configured as a service into one of the nodes (A Relayer [listens](/cross-chain/teleporter/overview#data-flow) for new messages being generated on a source Avalanche L1 and sends them to the destination Avalanche L1.) -CLI configures the Relayer to enable every Subnet to send messages to all other Subnets. If you add more Subnets to the Devnet, the Relayer will be automatically reconfigured. +CLI configures the Relayer to enable every Avalanche L1 to send messages to all other Avalanche L1s. If you add more Avalanche L1s to the Devnet, the Relayer will be automatically reconfigured. Checking Devnet Configuration and Relayer Logs[​](#checking-devnet-configuration-and-relayer-logs "Direct link to heading") --------------------------------------------------------------------------------------------------------------------------- @@ -124,41 +124,41 @@ Apr 05 14:15:08 ip-172-31-47-187 awm-relayer[6886]: {"level":"info","timestamp": Apr 05 14:15:08 ip-172-31-47-187 awm-relayer[6886]: {"level":"info","timestamp":"2024-04-05T14:15:08.180Z","logger":"awm-relayer","caller":"main/main.go:295","msg":"Relayer initialized. Listening for messages to relay.","originBlockchainID":"fqcM24LNb3kTV7KD1mAvUJXYy5XunwP8mrE44YuNwPjgZHY6p"} ``` -Deploying the Second Subnet[​](#deploying-the-second-subnet "Direct link to heading") +Deploying the Second Avalanche L1[​](#deploying-the-second-avalanche-l1 "Direct link to heading") ------------------------------------------------------------------------------------- Let's use the `devnet wiz` command again to deploy ``. -When deploying Subnet ``, the two Teleporter contracts will not be deployed to C-Chain in Local Network as they have already been deployed when we deployed the first Subnet. +When deploying Avalanche L1 ``, the two Teleporter contracts will not be deployed to C-Chain in Local Network as they have already been deployed when we deployed the first Avalanche L1. ``` avalanche node devnet wiz --default-validator-params -Adding subnet into existing devnet ... +Adding Avalanche L1 into existing devnet ... ... -Deploying [subnet2] to Cluster +Deploying [chain2] to Cluster ... Stopping AWM Relayer Service -Setting the nodes as subnet trackers +Setting the nodes as Avalanche L1 trackers ... -Setting up teleporter on subnet +Setting up teleporter on Avalanche L1 -Teleporter Messenger successfully deployed to subnet2 (0x253b2784c75e510dD0fF1da844684a1aC0aa5fcf) -Teleporter Registry successfully deployed to subnet2 (0xb623C4495220C603D0A939D32478F55891a61750) +Teleporter Messenger successfully deployed to Avalanche L1 (0x253b2784c75e510dD0fF1da844684a1aC0aa5fcf) +Teleporter Registry successfully deployed to Avalanche L1 (0xb623C4495220C603D0A939D32478F55891a61750) Teleporter Messenger has already been deployed to c-chain Starting AWM Relayer Service -setting AWM Relayer on host i-0f1815c016b555fcc to relay subnet subnet2 +setting AWM Relayer on host i-0f1815c016b555fcc to relay L1 chain2 updating configuration file ~/.avalanche-cli/nodes/i-0f1815c016b555fcc/services/awm-relayer/awm-relayer-config.json -Devnet is now validating subnet subnet2 +Devnet is now validating Avalanche L1 chain2 -Subnet RPC URL: http://67.202.23.231:9650/ext/bc/7gKt6evRnkA2uVHRfmk9WrH3dYZH9gEVVxDAknwtjvtaV3XuQ/rpc +Avalanche L1 RPC URL: http://67.202.23.231:9650/ext/bc/7gKt6evRnkA2uVHRfmk9WrH3dYZH9gEVVxDAknwtjvtaV3XuQ/rpc ✓ Cluster information YAML file can be found at ~/.avalanche-cli/nodes/inventories//clusterInfo.yaml at local host ``` @@ -169,18 +169,18 @@ Verify Teleporter Is Successfully Set Up[​](#verify-teleporter-is-successfully To verify that Teleporter is successfully, let's send a couple of cross messages: ``` -avalanche teleporter msg C-Chain subnet1 "Hello World" --cluster +avalanche teleporter msg C-Chain chain1 "Hello World" --cluster -Delivering message "this is a message" to source subnet "C-Chain" (2EfJg86if9Ka5Ag73JRfoqWz4EGuFwtemaNf4XiBBpUW4YngS6) -Waiting for message to be received at destination subnet subnet "subnet1" (fqcM24LNb3kTV7KD1mAvUJXYy5XunwP8mrE44YuNwPjgZHY6p) +Delivering message "this is a message" to source Avalanche L1 "C-Chain" (2EfJg86if9Ka5Ag73JRfoqWz4EGuFwtemaNf4XiBBpUW4YngS6) +Waiting for message to be received at destination Avalanche L1 "chain1" (fqcM24LNb3kTV7KD1mAvUJXYy5XunwP8mrE44YuNwPjgZHY6p) Message successfully Teleported! ``` ``` -avalanche teleporter msg subnet2 subnet1 "Hello World" --cluster +avalanche teleporter msg chain2 chain1 "Hello World" --cluster -Delivering message "this is a message" to source subnet "subnet2" (29WP91AG7MqPUFEW2YwtKnsnzVrRsqcWUpoaoSV1Q9DboXGf4q) -Waiting for message to be received at destination subnet subnet "subnet1" (fqcM24LNb3kTV7KD1mAvUJXYy5XunwP8mrE44YuNwPjgZHY6p) +Delivering message "this is a message" to source Avalanche L1 "chain2" (29WP91AG7MqPUFEW2YwtKnsnzVrRsqcWUpoaoSV1Q9DboXGf4q) +Waiting for message to be received at destination Avalanche L1 "chain1" (fqcM24LNb3kTV7KD1mAvUJXYy5XunwP8mrE44YuNwPjgZHY6p) Message successfully Teleported! ``` @@ -189,9 +189,9 @@ You have Teleport-ed your first message in the Devnet! Obtaining Information on Teleporter Deploys[​](#obtaining-information-on-teleporter-deploys "Direct link to heading") --------------------------------------------------------------------------------------------------------------------- -### Obtaining Subnet Information[​](#obtaining-subnet-information "Direct link to heading") +### Obtaining Avalanche L1 Information[​](#obtaining-avalanche-l1-information "Direct link to heading") -By executing `blockchain describe` on a Teleporter enabled Subnet, the following relevant information can be found: +By executing `blockchain describe` on a Teleporter enabled Avalanche L1, the following relevant information can be found: - Blockchain RPC URL - Blockchain ID in cb58 format @@ -214,7 +214,7 @@ avalanche blockchain describe +--------------------------------+----------------------------------------------------------------------------------------+ | PARAMETER | VALUE | +--------------------------------+----------------------------------------------------------------------------------------+ -| Subnet Name | subnet1 | +| Blockchain Name | Avalanche L1 | +--------------------------------+----------------------------------------------------------------------------------------+ | ChainID | 1 | +--------------------------------+----------------------------------------------------------------------------------------+ @@ -300,3 +300,4 @@ avalanche teleporter relayer start --cluster ✓ Remote AWM Relayer on i-0f1815c016b555fcc successfully started ``` + diff --git a/content/docs/cross-chain/teleporter/teleporter-on-local-network.mdx b/content/docs/cross-chain/teleporter/teleporter-on-local-network.mdx index bd0aa70b96d..b9f8a7f68ee 100644 --- a/content/docs/cross-chain/teleporter/teleporter-on-local-network.mdx +++ b/content/docs/cross-chain/teleporter/teleporter-on-local-network.mdx @@ -1,10 +1,10 @@ --- -title: Teleporter Subnets on Local Network +title: Teleporter Avalanche L1s on Local Network --- -This how-to guide focuses on deploying Teleporter-enabled Subnets to a local Avalanche network. +This how-to guide focuses on deploying Teleporter-enabled Avalanche L1s to a local Avalanche network. -After this tutorial, you would have created and deployed two Subnets to the local network and have enabled them to cross-communicate with each other and with the local C-Chain (through Teleporter and the underlying Warp technology.) +After this tutorial, you would have created and deployed two Avalanche L1s to the local network and have enabled them to cross-communicate with each other and with the local C-Chain (through Teleporter and the underlying Warp technology.) Note that currently only [Subnet-EVM](https://github.com/ava-labs/subnet-evm) and [Subnet-EVM-Based](/virtual-machines/evm-customization/introduction) virtual machines support Teleporter. @@ -12,10 +12,10 @@ Note that currently only [Subnet-EVM](https://github.com/ava-labs/subnet-evm) an - [Avalanche-CLI installed](/tooling/guides/get-avalanche-cli) -Create Subnet Configurations[​](#create-subnet-configurations "Direct link to heading") +Create Avalanche L1 Configurations[​](#create-avalanche-l1-configurations "Direct link to heading") --------------------------------------------------------------------------------------- -Let's create a Subnet called `` with the latest Subnet-EVM version, a chain ID of 1, TOKEN1 as the token name, and with default Subnet-EVM parameters (more information regarding Subnet creation can be found [here](/subnets/build-first-subnet#create-your-subnet-configuration)): +Let's create an Avalanche L1 called `` with the latest Subnet-EVM version, a chain ID of 1, TOKEN1 as the token name, and with default Subnet-EVM parameters (more information regarding Avalanche L1 creation can be found [here](/avalanche-l1s/build-first-avalanche-l1#create-your-avalanche-l1-configuration)): ``` avalanche blockchain create --evm --latest\ @@ -26,16 +26,16 @@ configuring airdrop to stored key "subnet__airdrop" with address 0x0EF81 loading stored key "cli-teleporter-deployer" for teleporter deploys (evm address, genesis balance) = (0xE932784f56774879e03F3624fbeC6261154ec711, 600000000000000000000) using latest teleporter version (v1.0.0) -✓ Successfully created subnet configuration +✓ Successfully created Avalanche L1 configuration ``` Notice that by default, Teleporter is enabled and a stored key is created to fund Teleporter related operations (that is deploy Teleporter smart contracts, fund Teleporter Relayer). -To disable Teleporter in your Subnet, use the flag `--teleporter=false` when creating the Subnet. +To disable Teleporter in your Avalanche L1, use the flag `--teleporter=false` when creating the Avalanche L1. -To disable Relayer in your Subnet, use the flag `--relayer=false` when creating the Subnet. +To disable Relayer in your Avalanche L1, use the flag `--relayer=false` when creating the Avalanche L1. -Now let's create a second Subnet called ``, with similar settings: +Now let's create a second Avalanche L1 called ``, with similar settings: ``` avalanche blockchain create --evm --latest\ @@ -45,10 +45,10 @@ configuring airdrop to stored key "subnet__airdrop" with address 0x0EF81 loading stored key "cli-teleporter-deployer" for teleporter deploys (evm address, genesis balance) = (0xE932784f56774879e03F3624fbeC6261154ec711, 600000000000000000000) using latest teleporter version (v1.0.0) -✓ Successfully created subnet configuration +✓ Successfully created Avalanche L1 configuration ``` -Deploy the Subnets to Local Network[​](#deploy-the-subnets-to-local-network "Direct link to heading") +Deploy the Avalanche L1s to Local Network[​](#deploy-the-avalanche-l1s-to-local-network "Direct link to heading") ----------------------------------------------------------------------------------------------------- Let's deploy ``: @@ -100,13 +100,13 @@ Currency Symbol: TOKEN1 Notice some details here: -- Two smart contracts are deployed to each Subnet: Teleporter Messenger and Teleporter Registry +- Two smart contracts are deployed to each Avalanche L1: Teleporter Messenger and Teleporter Registry - Both Teleporter smart contracts are also deployed to `C-Chain` in the Local Network -- [AWM Teleporter Relayer](https://github.com/ava-labs/awm-relayer) is installed, configured and executed in background (A Relayer [listens](/cross-chain/teleporter/overview#data-flow) for new messages being generated on a source Subnet and sends them to the destination Subnet.) +- [AWM Teleporter Relayer](https://github.com/ava-labs/awm-relayer) is installed, configured and executed in background (A Relayer [listens](/cross-chain/teleporter/overview#data-flow) for new messages being generated on a source Avalanche L1 and sends them to the destination Avalanche L1.) -CLI configures the Relayer to enable every Subnet to send messages to all other Subnets. If you add more Subnets, the Relayer will be automatically reconfigured. +CLI configures the Relayer to enable every Avalanche L1 to send messages to all other Avalanche L1s. If you add more Avalanche L1s, the Relayer will be automatically reconfigured. -When deploying Subnet ``, the two Teleporter contracts will not be deployed to C-Chain in Local Network as they have already been deployed when we deployed the first Subnet. +When deploying Avalanche L1 ``, the two Teleporter contracts will not be deployed to C-Chain in Local Network as they have already been deployed when we deployed the first Avalanche L1. ``` avalanche blockchain deploy --local @@ -164,16 +164,16 @@ To verify that Teleporter is successfully, let's send a couple of cross messages ``` avalanche teleporter msg C-Chain chain1 "Hello World" --local -Delivering message "this is a message" to source subnet "C-Chain" -Waiting for message to be received at destination subnet subnet "chain1" +Delivering message "this is a message" to source Avalanche L1 "C-Chain" +Waiting for message to be received at destination Avalanche L1 Avalanche L1 "chain1" Message successfully Teleported! ``` ``` avalanche teleporter msg chain2 chain1 "Hello World" --local -Delivering message "this is a message" to source subnet "chain2" -Waiting for message to be received at destination subnet subnet "chain1" +Delivering message "this is a message" to source Avalanche L1 "chain2" +Waiting for message to be received at destination Avalanche L1 Avalanche L1 "chain1" Message successfully Teleported! ``` @@ -184,9 +184,9 @@ Relayer related logs can be found at `~/.avalanche-cli/runs/awm-relayer.log`, an Obtaining Information on Teleporter Deploys[​](#obtaining-information-on-teleporter-deploys "Direct link to heading") --------------------------------------------------------------------------------------------------------------------- -### Obtaining Subnet Information[​](#obtaining-subnet-information "Direct link to heading") +### Obtaining Avalanche L1 Information[​](#obtaining-avalanche-l1-information "Direct link to heading") -By executing `blockchain describe` on a Teleporter enabled Subnet, the following relevant information can be found: +By executing `blockchain describe` on a Teleporter enabled Avalanche L1, the following relevant information can be found: - Blockchain RPC URL - Blockchain ID in cb58 format @@ -208,7 +208,7 @@ avalanche blockchain describe +--------------------------------+-------------------------------------------------------------------------------------+ | PARAMETER | VALUE | +--------------------------------+-------------------------------------------------------------------------------------+ -| Subnet Name | chain1 | +| Avalanche L1 Name | chain1 | +--------------------------------+-------------------------------------------------------------------------------------+ | ChainID | 1 | +--------------------------------+-------------------------------------------------------------------------------------+ @@ -280,7 +280,7 @@ avalanche primary describe --local Controlling Relayer Execution[​](#controlling-relayer-execution "Direct link to heading") ----------------------------------------------------------------------------------------- -Besides having the option to not use a Relayer at Subnet creation time, the Relayer can be stopped and restarted on used request. +Besides having the option to not use a Relayer at Avalanche L1 creation time, the Relayer can be stopped and restarted on used request. To stop the Relayer: @@ -301,3 +301,4 @@ Executing AWM-Relayer... Logs can be found at ~/.avalanche-cli/runs/awm-relayer.log ``` + diff --git a/content/docs/cross-chain/teleporter/upgradeability.mdx b/content/docs/cross-chain/teleporter/upgradeability.mdx index 5fc9fe62b12..5a085ace650 100644 --- a/content/docs/cross-chain/teleporter/upgradeability.mdx +++ b/content/docs/cross-chain/teleporter/upgradeability.mdx @@ -1,14 +1,10 @@ --- title: Upgradeability +description: The TeleporterMessenger contract is non-upgradable. However, there could still be new versions of TeleporterMessenger contracts needed to be deployed in the future. --- - -Dive deeper into Teleporter and kickstart your journey in building cross-chain dApps by enrolling in our [Teleporter course](https://academy.avax.network/course/teleporter). - - -Overview[​](#overview "Direct link to heading") ------------------------------------------------ +## Overview The `TeleporterMessenger` contract is non-upgradable, once a version of the contract is deployed it cannot be changed. This is with the intention of preventing any changes to the deployed contract that could potentially introduce bugs or vulnerabilities. @@ -17,15 +13,14 @@ However, there could still be new versions of `TeleporterMessenger` contracts ne The `TeleporterRegistry` maintains a mapping of `TeleporterMessenger` contract versions to their addresses. When a new `TeleporterMessenger` version is deployed, its address can be added to the `TeleporterRegistry`. The `TeleporterRegistry` can only be updated through a Warp off-chain message that meets the following requirements: - `sourceChainAddress` must match `VALIDATORS_SOURCE_ADDRESS = address(0)` - - The zero address can only be set as the source chain address by a Warp off-chain message, and cannot be set by an on-chain Warp message. + - The zero address can only be set as the source chain address by a Warp off-chain message, and cannot be set by an on-chain Warp message. - `sourceBlockchainID` must match the blockchain ID that the registry is deployed on - `destinationBlockchainID` must match the blockchain ID that the registry is deployed on - `destinationAddress` must match the address of the registry In the `TeleporterRegistry` contract, the `latestVersion` state variable returns the highest version number that has been registered in the registry. The `getLatestTeleporter` function returns the `ITeleporterMessenger` that is registered with the corresponding version. -Design[​](#design "Direct link to heading") -------------------------------------------- +## Design - `TeleporterRegistry` is deployed on each blockchain that needs to keep track of `TeleporterMessenger` contract versions. - The registry's contract address on each blockchain does not need to be the same, and does not require a Nick's method transaction for deployment. @@ -36,32 +31,34 @@ Design[​](#design "Direct link to heading") - Version zero is an invalid version, and is used to indicate that a `TeleporterMessenger` contract has not been registered yet. - Once a version number is registered in the registry, it cannot be changed, but a previous registered protocol address can be added to the registry with a new version. This is especially important in the case of a rollback to a previous Teleporter version, in which case the previous Teleporter contract address would need to be registered with a new version to the registry. -Integrating `TeleporterRegistry` with `TeleporterUpgradeable`[​](#integrating-teleporterregistry-with-teleporterupgradeable "Direct link to heading") ------------------------------------------------------------------------------------------------------------------------------------------------------ +## Integrating `TeleporterRegistryApp` into a dApp -![Upgrade UML diagram](/images/upgrade1.png) +
+ Upgrade UML diagram +
-[TeleporterUpgradeable](https://github.com/ava-labs/teleporter/blob/main/contracts/src/Teleporter/upgrades/TeleporterUpgradeable.sol) is an abstract contract that helps integrate the `TeleporterRegistry` into a dApp built on top of Teleporter. By inheriting from `TeleporterUpgradeable`, dapps get: +[TeleporterRegistryApp](https://github.com/ava-labs/teleporter/blob/main/contracts/teleporter/registry/TeleporterRegistryApp.sol) is an abstract contract that helps integrate the `TeleporterRegistry` into a dApp built on top of Teleporter. To support upgradeable contracts, there is also a corresponding `TeleporterRegistryAppUpgradeable` contract that is upgrade compatible. By inheriting from `TeleporterRegistryApp`, dApps get: - Ability to send Teleporter messages through the latest version of the Teleporter contract registered in the Teleporter registry. (The dApp can also override this to use a specific version of the Teleporter contract.) - `minTeleporterVersion` management that allows the dApp to specify the minimum Teleporter version that can send messages to the dApp. - Access controlled utility to update the `minTeleporterVersion` - Access controlled utility to pause/unpause interaction with specific Teleporter addresses. -To integrate `TeleporterUpgradeable` with a dApp pass in the Teleporter registry address inside the constructor. An example dApp looks like: +To integrate `TeleporterRegistryApp` with a dApp, pass in the Teleporter registry address inside the constructor. For upgradeable contracts `TeleporterRegistryAppUpgradeable` can be inherited, and the derived contract's `initializer` function should call either `__TeleporterRegistryApp_init` or `__TeleporterRegistryApp_init_unchained` An example dApp looks like: -``` +```solidity // An example dApp that integrates with the Teleporter registry // to send/receive Teleporter messages. contract ExampleApp is - TeleporterUpgradeable + TeleporterRegistryApp { ... // Constructor passes in the Teleporter registry address - // to the TeleporterUpgradeable contract. + // to the TeleporterRegistryApp contract. constructor( - address teleporterRegistryAddress - ) TeleporterUpgradeable(teleporterRegistryAddress) { + address teleporterRegistryAddress, + uint256 minTeleporterVersion + ) TeleporterRegistryApp(teleporterRegistryAddress, minTeleporterVersion) { currentBlockchainID = IWarpMessenger(WARP_PRECOMPILE_ADDRESS) .getBlockchainID(); } @@ -77,66 +74,56 @@ contract ExampleApp is } // Implements the access control checks for the dApp's interaction with Teleporter versions. - function _checkTeleporterUpgradeAccess() internal view virtual override { + function _checkTeleporterRegistryAppAccess() internal view virtual override { //implementation } } ``` -### TeleporterUpgradeable utility[​](#teleporterupgradeable-utility "Direct link to heading") - -#### Initialization[​](#initialization "Direct link to heading") - -The `TeleporterUpgradeable` contract constructor saves the Teleporter registry in a state variable used by the inheriting contract, and initializes a `minTeleporterVersion` to the highest `TeleporterMessenger` version registered in `TeleporterRegistry`. `minTeleporterVersion` is used to allow dApp's to specify the Teleporter versions allowed to interact with it. - -#### Updating `minTeleporterVersion`[​](#updating-minteleporterversion "Direct link to heading") - -The `TeleporterUpgradeable.updateMinTeleporterVersion` function updates the `minTeleporterVersion` used to check which Teleporter versions can deliver messages to the dApp, and emits the `MinTeleporterVersionUpdated` event. The `updateMinTeleporterVersion` function should **ONLY** be called by the dApp when it completes delivery of messages from the old Teleporter contract, and now wants to update the `minTeleporterVersion` to only allow the new Teleporter version. By default, `updateMinTeleporterVersion` can only be called with a version greater than the current `minTeleporterVersion` and less than `latestVersion` in the Teleporter registry. So once this function is called, the dApp will no longer be able to receive messages from the old Teleporter contract version, unless the old version's Teleporter address was registered in the registry again with a new version. - -#### Checking Teleporter upgrade access[​](#checking-teleporter-upgrade-access "Direct link to heading") +### Checking TeleporterRegistryApp access -To prevent anyone from calling the dApp's `updateMinTeleporterVersion`, which would disallow messages from old Teleporter versions from being received, this function should be safeguarded with access controls. All contracts deriving from `TeleporterUpgradeable` will need to implement `TeleporterUpgradeable._checkTeleporterUpgradeAccess`. For example, [TeleporterOwnerUpgrade](https://github.com/ava-labs/teleporter/blob/main/contracts/src/Teleporter/upgrades/TeleporterOwnerUpgradeable.sol) is an abstract contract that inherits `TeleporterUpgradeable`, and implements `_checkTeleporterUpgradeAccess` to check whether the caller is the owner. +To prevent anyone from calling the dApp's `updateMinTeleporterVersion`, which would disallow messages from old Teleporter versions from being received, this function should be safeguarded with access controls. All contracts deriving from `TeleporterRegistryApp` will need to implement `TeleporterRegistryApp._checkTeleporterRegistryAppAccess`. For example, [TeleporterRegistryOwnableApp](https://github.com/ava-labs/teleporter/blob/main/contracts/teleporter/registry/TeleporterRegistryOwnableApp.sol) is an abstract contract that inherits `TeleporterRegistryApp`, and implements `_checkTeleporterRegistryAppAccess` to check whether the caller is the owner. There is also a corresponding `TeleporterRegistryOwnableAppUpgradeable` contract that is upgrade compatible. -``` - function _checkTeleporterUpgradeAccess() internal view virtual override { +```solidity + function _checkTeleporterRegistryAppAccess() internal view virtual override { _checkOwner(); } ``` -Another example would be a dApp that has different roles and priveleges. `_checkTeleporterUpgradeAccess` can be implemented to check whether the caller is a specific role. +Another example would be a dApp that has different roles and priveleges. `_checkTeleporterRegistryAppAccess` can be implemented to check whether the caller is a specific role. -``` - function _checkTeleporterUpgradeAccess() internal view virtual override { +```solidity + function _checkTeleporterRegistryAppAccess() internal view virtual override { require( - hasRole(TELEPORTER_UPGRADE_ROLE, _msgSender()), - "TeleporterUpgradeable: caller does not have upgrade access" + hasRole(TELEPORTER_REGISTRY_APP_ADMIN, _msgSender()), + "TeleporterRegistryApp: caller does not have access" ); } ``` -#### Sending with specific Teleporter version[​](#sending-with-specific-teleporter-version "Direct link to heading") +### Sending with specific Teleporter version -For sending messages with the Teleporter registry, dapps should use `TeleporterUpgradeable._getTeleporterMessenger`. This function by default extends `TeleporterRegistry.getLatestTeleporter`, using the latest version, and adds an extra check on whether the latest Teleporter address is paused. If the dApp wants to send a message through a specific Teleporter version, it can override `_getTeleporterMessenger()` to use the specific Teleporter version with `TeleporterRegistry.getTeleporterFromVersion`. +For sending messages with the Teleporter registry, dApps should use `TeleporterRegistryApp._getTeleporterMessenger`. This function by default extends `TeleporterRegistry.getLatestTeleporter`, using the latest version, and adds an extra check on whether the latest Teleporter address is paused. If the dApp wants to send a message through a specific Teleporter version, it can override `_getTeleporterMessenger()` to use the specific Teleporter version with `TeleporterRegistry.getTeleporterFromVersion`. -The `TeleporterUpgradeable._sendTeleporterMessage` function makes sending Teleporter messages easier. The function uses `_getTeleporterMessenger` to get the sending Teleporter version, pays for Teleporter fees from the dApp's balance, and sends the cross chain message. +The `TeleporterRegistryApp._sendTeleporterMessage` function makes sending Teleporter messages easier. The function uses `_getTeleporterMessenger` to get the sending Teleporter version, pays for Teleporter fees from the dApp's balance, and sends the cross chain message. Using latest version: -``` +```solidity ITeleporterMessenger teleporterMessenger = _getTeleporterMessenger(); ``` Using specific version: -``` +```solidity // Override _getTeleporterMessenger to use specific version. function _getTeleporterMessenger() internal view override returns (ITeleporterMessenger) { ITeleporterMessenger teleporter = teleporterRegistry .getTeleporterFromVersion($VERSION); require( !pausedTeleporterAddresses[address(teleporter)], - "TeleporterUpgradeable: Teleporter sending version paused" + "TeleporterRegistryApp: Teleporter sending version paused" ); return teleporter; @@ -145,18 +132,84 @@ Using specific version: ITeleporterMessenger teleporterMessenger = _getTeleporterMessenger(); ``` -#### Receiving from specific Teleporter versions[​](#receiving-from-specific-teleporter-versions "Direct link to heading") +### Receiving from specific Teleporter versions + +`TeleporterRegistryApp` also provides an initial implementation of [ITeleporterReceiver.receiveTeleporterMessage](https://github.com/ava-labs/teleporter/blob/main/contracts/teleporter/ITeleporterReceiver.sol) that ensures `_msgSender` is a `TeleporterMessenger` contract with a version greater than or equal to `minTeleporterVersion`. This supports the case where a dApp wants to use a new version of the `TeleporterMessenger` contract, but still wants to be able to receive messages from the old Teleporter contract.The dApp can override `_receiveTeleporterMessage` to implement its own logic for receiving messages from Teleporter contracts. + +## Managing a TeleporterRegistryApp dApp + +dApps that implement `TeleporterRegistryApp` automatically use the latest Teleporter version registered with the `TeleporterRegistry`. Interaction with underlying `TeleporterMessenger` versions can be managed by setting the minimum Teleporter version, and pausing and unpausing specific versions. + +The following sections include example `cast send` commands for issuing transactions that call contract functions. See the [Foundry Book](https://book.getfoundry.sh/reference/cast/cast-send) for details on how to issue transactions using common wallet options. + +### Managing the Minimum Teleporter version + +The `TeleporterRegistryApp` contract constructor saves the Teleporter registry in a state variable used by the inheriting dApp contract, and initializes a `minTeleporterVersion` to the highest `TeleporterMessenger` version registered in `TeleporterRegistry`. `minTeleporterVersion` is used to allow dApp's to specify the Teleporter versions allowed to interact with it. + +#### Updating `minTeleporterVersion` + +The `TeleporterRegistryApp.updateMinTeleporterVersion` function updates the `minTeleporterVersion` used to check which Teleporter versions can be used for sending and receiving messages. **Once the `minTeleporterVersion` is increased, any undelivered messages sent by other chains using older versions of Teleporter will never be able to be received**. The `updateMinTeleporterVersion` function can only be called with a version greater than the current `minTeleporterVersion` and less than `latestVersion` in the Teleporter registry. + +> Example: Update the minimum Teleporter version to 2 +> +> ``` +> cast send "updateMinTeleporterVersion(uint256)" 2 +> ``` + +### Pausing Teleporter version interactions + +dApps that inherit from `TeleporterRegistryApp` can pause Teleporter interactions by calling `TeleporterRegistryApp.pauseTeleporterAddress`. This function prevents the dApp contract from interacting with the paused Teleporter address when sending or receiving Teleporter messages. + +`pauseTeleporterAddress` can only be called by addresses that passes the dApp's `TeleporterRegistryApp._checkTeleporterRegistryAppAccess` check. + +The Teleporter address corresponding to a Teleporter version can be fetched from the registry with `TeleporterRegistry.getAddressFromVersion` + +> Example: Pause Teleporter version 3 +> +> ``` +> versionThreeAddress=$(cast call "getAddressFromVersion(uint256)(address)" 3) +> cast send "pauseTeleporterAddress(address)" $versionThreeAddress +> ``` + +#### Pause all Teleporter interactions -`TeleporterUpgradeable` also provides an initial implementation of [ITeleporterReceiver.receiveTeleporterMessage](https://github.com/ava-labs/teleporter/blob/main/contracts/src/Teleporter/ITeleporterReceiver.sol) that ensures `_msgSender` is a `TeleporterMessenger` contract with a version greater than or equal to `minTeleporterVersion`. This supports the case where a dApp wants to upgrade to a new version of the `TeleporterMessenger` contract, but still wants to be able to receive messages from the old Teleporter contract.The dApp can override `_receiveTeleporterMessage` to implement its own logic for receiving messages from Teleporter contracts. +To pause all Teleporter interactions, `TeleporterRegistryApp.pauseTeleporterAddress` must be called for every Teleporter version from the `minTeleporterVersion` to the latest Teleporter version registered in `TeleporterRegistry`. Note that there may be gaps in Teleporter versions registered with `TeleporterRegistry`, but they will always be in increasing order. The latest Teleporter version can be obtained by inspecting the public variable `TeleporterRegistry.latestVersion`. The `minTeleporterVersion` can be obtained by calling `TeleporterRegistryApp.getMinTeleporterVersion`. -#### Pausing Teleporter version interactions[​](#pausing-teleporter-version-interactions "Direct link to heading") +> Example: Pause all registered Teleporter versions +> +> ``` +> # Fetch the minimum Teleporter version +> minVersion=$(cast call "getMinTeleporterVersion()(uint256)") +> +> # Fetch the latest registered version +> latestVersion=$(cast call "latestVersion()(uint256)") +> +> # Pause all registered versions +> for ((version=minVersion; version<=latestVersion; version++)) +> do +> # Fetch the version address if it's registered +> versionAddress=$(cast call "getAddressFromVersion(uint256)(address)" $version) +> +> if [ $? -eq 0 ]; then +> # If cast call is successful, proceed to cast send +> cast send "pauseTeleporterAddress(address)" $versionAddress +> else +> # If cast call fails, print an error message and skip to the next iteration +> echo "Version $version not registered. Skipping." +> fi +> done +> ``` -Dapps that inherit from `TeleporterUpgradeable` can pause Teleporter interactions by calling `TeleporterUpgradeable.pauseTeleporterAddress`. This function prevents the contract from interacting with the paused Teleporter address when sending or receiving Teleporter messages. +#### Unpausing Teleporter version interactions -`pauseTeleporterAddress` can only be called by addresses with the dApp's upgrade access, checked through `TeleporterUpgradeable._checkTeleporterUpgradeAccess`. +As with pausing, dApps can unpause Teleporter interactions by calling `TeleporterRegistryApp.unpauseTeleporterAddress`. This unpause function allows receiving Teleporter message from the unpaused Teleporter address, and also enables the sending of messages through the unpaused Teleporter address in `_getTeleporterMessenger()`. Unpausing is also only allowed by addresses passing the dApp's `_checkTeleporterRegistryAppAccess` check. -#### Unpausing Teleporter version interactions[​](#unpausing-teleporter-version-interactions "Direct link to heading") +Note that receiving Teleporter messages is still governed by the `minTeleporterVersion` check, so even if a Teleporter address is unpaused, the dApp will not receive messages from the unpaused Teleporter address if the Teleporter version is less than `minTeleporterVersion`. -As with pausing, dapps can unpause Teleporter interactions by calling `TeleporterUpgradeable.unpauseTeleporterAddress`. This unpause function allows receiving Teleporter message from the unpaused Teleporter address, and also enables the sending of messages through the unpaused Teleporter address in `_getTeleporterMessenger()`. Unpausing is also only allowed by addresses with the dApp's upgrade access. +> Example: Unpause Teleporter version 3 +> +> ``` +> versionThreeAddress=$(cast call "getAddressFromVersion(uint256)(address)" 3) +> cast send "unpauseTeleporterAddress(address)" $versionThreeAddress +> ``` -Note that receiving Teleporter messages is still governed by the `minTeleporterVersion` check, so even if a Teleporter address is unpaused, the dApp will not receive messages from the unpaused Teleporter address if the Teleporter version is less than `minTeleporterVersion`. \ No newline at end of file diff --git a/content/docs/dapps/advanced-tutorials/add-network-programmatically.mdx b/content/docs/dapps/advanced-tutorials/add-network-programmatically.mdx index c7f3ac5d61b..913700c0605 100644 --- a/content/docs/dapps/advanced-tutorials/add-network-programmatically.mdx +++ b/content/docs/dapps/advanced-tutorials/add-network-programmatically.mdx @@ -5,7 +5,7 @@ description: This document shows how to integrate Avalanche Network with your dA ## Core -Powered by Avalanche, [Core](https://core.app/en/) is an all-in-one operating system bringing together Avalanche apps, Subnets, bridges, and NFTs in one seamless, high-performance browser experience. Putting in another way, Core is more than a wallet. It is a curated web3 operating system combining Wallet, Explorer, Bridge, Subnets, dApps, and more. +Powered by Avalanche, [Core](https://core.app/en/) is an all-in-one operating system bringing together Avalanche apps, Avalanche L1s, bridges, and NFTs in one seamless, high-performance browser experience. Putting in another way, Core is more than a wallet. It is a curated web3 operating system combining Wallet, Explorer, Bridge, Avalanche L1s, dApps, and more. Getting a Dapp ready to connect to Core is made simple with pre-built tools from the Core Team. @@ -22,12 +22,12 @@ yarn bootstrap The repository cloning method used is HTTPS, but SSH can be used too: -`git clone [[email protected]](https://docs.avax.network/cdn-cgi/l/email-protection):ava-labs/avalanche-dapp-sdks.git` +`git clone git@github.com:ava-labs/avalanche-dapp-sdks.git` You can find more about SSH and how to use it [here](https://docs.github.com/en/authentication/connecting-to-github-with-ssh/about-ssh). -Then check out [this sample project under `packages/avalanche-connector-example`](https://github.com/ava-labs/avalanche-dapp-sdks/tree/alpha-release/packages/avalanche-connector-example#readme) +Then check out [this sample project under `packages/avalanche-connector-example`](https://github.com/ava-labs/avalanche-dapp-sdks/tree/alpha-release/packages/web3-react-core-connector) ```rust cd packages/avalanche-connector-example @@ -38,7 +38,7 @@ If everything works as expected, you should be able to load \[http://localhost:3 ![connect core](/images/add-network1.jpeg) -Check out the [README](https://github.com/ava-labs/avalanche-dapp-sdks/tree/alpha-release/packages/avalanche-connector-example#readme) to see details how this works and use it to fit your needs. +Check out the [README](https://github.com/ava-labs/avalanche-dapp-sdks/tree/alpha-release/packages/web3-react-core-connector) to see details how this works and use it to fit your needs. This [Google Drive](https://drive.google.com/drive/folders/1pQ98mIs65ET9JBGThzAAlGKv85BuQCAu?usp=sharing) has the assets needed to create a **Connect with Core** button. @@ -131,4 +131,4 @@ If they approve, your app will be connected to the Avalanche network. Very easy, Dapp users are often not very technically sophisticated and onboarding them needs to be as seamless and easy as possible. Manually adding a new network is a hurdle than a certain percentage of your potential users will not be able to clear. Removing that requirement is a simple step that will enhance their experience and enable more users to get to actually use your dapp. -If you have any questions, problems, or ideas on how to improve, or simply want to join our developer community, you can contact us on our [Discord](https://chat.avalabs.org/) server. \ No newline at end of file +If you have any questions, problems, or ideas on how to improve, or simply want to join our developer community, you can contact us on our [Discord](https://chat.avalabs.org/) server. diff --git a/content/docs/dapps/advanced-tutorials/dynamic-gas-fees.mdx b/content/docs/dapps/advanced-tutorials/dynamic-gas-fees.mdx index 7c4ee3acf24..ba505ca376d 100644 --- a/content/docs/dapps/advanced-tutorials/dynamic-gas-fees.mdx +++ b/content/docs/dapps/advanced-tutorials/dynamic-gas-fees.mdx @@ -213,4 +213,4 @@ sendAvax("0", "0x856EA4B78947c3A5CD2256F85B2B147fEBDb7124", 100, 10, 25); ## Conclusion -You have learned about creating, signing, and sending transactions with dynamic fee parameters to the C-Chain of Avalanche network using JavaScript. It also explained, how to re-issue or cancel a stuck transaction, by sending a transaction with the same nonce. This tutorial points out the recommended way for choosing max fee cap and max priority fee cap for transactions and can also work as a general guide for all the EVM-based chains. \ No newline at end of file +You have learned about creating, signing, and sending transactions with dynamic fee parameters to the C-Chain of Avalanche network using JavaScript. It also explained, how to re-issue or cancel a stuck transaction, by sending a transaction with the same nonce. This tutorial points out the recommended way for choosing max fee cap and max priority fee cap for transactions and can also work as a general guide for all the EVM-based chains. diff --git a/content/docs/dapps/advanced-tutorials/exchange-integration.mdx b/content/docs/dapps/advanced-tutorials/exchange-integration.mdx index 8240015b296..116a6a5e440 100644 --- a/content/docs/dapps/advanced-tutorials/exchange-integration.mdx +++ b/content/docs/dapps/advanced-tutorials/exchange-integration.mdx @@ -27,7 +27,7 @@ website. If you want to build your node form source or include it in a docker image, reference the [AvalancheGo GitHub repository](https://github.com/ava-labs/avalanchego). To quickly get up and -running, you can use the [node installation script](/nodes/run/using-install-script/installing-avalanche-go) that automates installing +running, you can use the [node installation script](/nodes/using-install-script/installing-avalanche-go) that automates installing and updating AvalancheGo node as a `systemd` service on Linux, using prebuilt binaries. @@ -125,9 +125,9 @@ Ethereum, so developers familiar with Ethereum and Solidity can feel right at home. We have tutorials and repositories for several popular development environments: -- [Core and Remix](/dapps/smart-contracts/remix-deploy) -- [thirdweb](/dapps/smart-contracts/toolchains/thirdweb) -- [Hardhat](/dapps/smart-contracts/toolchains/hardhat) +- [Core and Remix](/dapps/smart-contract-dev/deploy-with-remix-ide) +- [thirdweb](/dapps/toolchains/thirdweb) +- [Hardhat](/dapps/toolchains/hardhat) ## Ingesting On-Chain Data @@ -162,4 +162,4 @@ you shouldn't have any issues! ## Support If you have any problems or questions, reach out either directly to our -developers, or on our public [Discord](https://chat.avalabs.org/) server. \ No newline at end of file +developers, or on our public [Discord](https://chat.avalabs.org/) server. diff --git a/content/docs/dapps/advanced-tutorials/manually-adjust-gas-price.mdx b/content/docs/dapps/advanced-tutorials/manually-adjust-gas-price.mdx index cf17da5b441..733417e9dca 100644 --- a/content/docs/dapps/advanced-tutorials/manually-adjust-gas-price.mdx +++ b/content/docs/dapps/advanced-tutorials/manually-adjust-gas-price.mdx @@ -96,4 +96,4 @@ You may not need to edit the gas fees on normal days. This is only required if t ![dynamic fees adjustment 5](/images/gas5.png) - ![dynamic fees adjustment 6](/images/gas6.png) \ No newline at end of file + ![dynamic fees adjustment 6](/images/gas6.png) diff --git a/content/docs/dapps/block-explorers.mdx b/content/docs/dapps/block-explorers.mdx index d3a6a8efa72..4a07952612d 100644 --- a/content/docs/dapps/block-explorers.mdx +++ b/content/docs/dapps/block-explorers.mdx @@ -3,9 +3,10 @@ title: Block Explorers description: Learn about different block explorers for Avalanche Ecosystem. --- -Avalanche Subnet Explorer is an analytics tool that enables people to search the Subnets and blockchains for transactions, addresses, and other platform activities. +Avalanche L1 Explorer is an analytics tool that enables people to search the Avalanche L1s and blockchains for transactions, addresses, and other platform activities. |Links | |------------------------------------------------------| |[Avalanche Mainnet](https://subnets.avax.network/)| |[Fuji Testnet](https://subnets-test.avax.network/)| + diff --git a/content/docs/dapps/chain-settings.mdx b/content/docs/dapps/chain-settings.mdx index f0aab4f15a0..48fe346c5b3 100644 --- a/content/docs/dapps/chain-settings.mdx +++ b/content/docs/dapps/chain-settings.mdx @@ -10,7 +10,7 @@ description: Learn about settings for different chains in Avalanche Ecosystem in - **WebSocket URL**: wss://api.avax.network/ext/bc/C/ws - **ChainID**: `43114` - **Symbol**: `AVAX` -- **Subnet-ID**: `11111111111111111111111111111111LpoYY` +- **SubnetID**: `11111111111111111111111111111111LpoYY` - **Blockchain-ID**: `2q9e4r6Mu3U68nU1fYjgbR6JvwrRx36CohpAX5UQxse55x1Q5` - **VM-ID**: `mgj786NP7uDwBCcq6YwThhaN8FLyybkCa4zBWTQbNgmK6k9A6` - **Explorer**: https://subnets.avax.network/c-chain @@ -22,7 +22,7 @@ description: Learn about settings for different chains in Avalanche Ecosystem in - **WebSocket URL**: wss://api.avax-test.network/ext/bc/C/ws - **ChainID**: `43113` - **Symbol**: `AVAX` -- **Subnet-ID**: `11111111111111111111111111111111LpoYY` +- **SubnetID**: `11111111111111111111111111111111LpoYY` - **Blockchain-ID**: `yH8D7ThNJkxmtkuv2jgBa4P1Rn3Qpr4pPr7QYNfcdoS6k6HWp` - **VM-ID**: `mgj786NP7uDwBCcq6YwThhaN8FLyybkCa4zBWTQbNgmK6k9A6` - **Explorer**: https://subnets-test.avax.network/c-chain @@ -31,4 +31,4 @@ description: Learn about settings for different chains in Avalanche Ecosystem in Head to either explorer linked above and select "Add Avalanche C-Chain to Wallet" under "Chain Info" to automatically add the network. -Alternatively, visit [chainlist.org](https://chainlist.org/?search=Avalanche&testnets=true) and connect your wallet. \ No newline at end of file +Alternatively, visit [chainlist.org](https://chainlist.org/?search=Avalanche&testnets=true) and connect your wallet. diff --git a/content/docs/dapps/deploy-nft-collection/deploy-erc-721.mdx b/content/docs/dapps/deploy-nft-collection/deploy-erc-721.mdx index 19cf324288a..ac31d4f70e0 100644 --- a/content/docs/dapps/deploy-nft-collection/deploy-erc-721.mdx +++ b/content/docs/dapps/deploy-nft-collection/deploy-erc-721.mdx @@ -44,7 +44,7 @@ Here, turn on the **Testnet Mode** feature. This will automatically make Core sw If you are using other wallets, like Core or MetaMask, you can add the Fuji Testnet using the following specs: - **Network Name**: Avalanche C-Chain -- **New RPC URL**: [https://api.avax-test.network/ext/bc/C/rpc](https://api.avax-test.network/ext/bc/C/rpc) +- **New RPC URL**: `https://api.avax-test.network/ext/bc/C/rpc` - **ChainID**: `43113` - **Symbol**: AVAX - **Explorer**: [`https://testnet.snowtrace.io`](https://testnet.snowtrace.io) @@ -167,3 +167,4 @@ All of the above steps can be used on Mainnet except the following changes: - Make sure that you switch to the Avalanche C-Chain in Core. - Make sure that you have AVAX tokens in your account to cover transaction costs. - You should use the Mainnet version of [Snowtrace Explorer](https://snowtrace.io/) to view transactions. + diff --git a/content/docs/dapps/deploy-nft-collection/index.mdx b/content/docs/dapps/deploy-nft-collection/index.mdx index 74268649a97..fcec0af531a 100644 --- a/content/docs/dapps/deploy-nft-collection/index.mdx +++ b/content/docs/dapps/deploy-nft-collection/index.mdx @@ -2,4 +2,4 @@ title: Deploy NFT Collection description: Learn how to deploy an NFT collection on the Avalanche C-chain. index: true ---- \ No newline at end of file +--- diff --git a/content/docs/dapps/deploy-nft-collection/prep-nft-files.mdx b/content/docs/dapps/deploy-nft-collection/prep-nft-files.mdx index 4aa878dac98..f0e9243ec6a 100644 --- a/content/docs/dapps/deploy-nft-collection/prep-nft-files.mdx +++ b/content/docs/dapps/deploy-nft-collection/prep-nft-files.mdx @@ -87,4 +87,4 @@ You'll now repeat the folder upload process to add the metadata to Pinata. Follo Click on the metadata folder to be directed to the IPFS gateway and save the URL. This URL will be your base URL and won't need the direct file links. The smart contract will append the necessary file information for each NFT as needed. For example, my URL is `https://gateway.pinata.cloud/ipfs/QmYdWxbiwsfsYcW1CYQPgYujAc9FMLPG3fgFcxFskbSsFa`. -Now that the image and metadata files are ready, we can prepare to deploy a smart contract by following this [ERC-721 tutorial](/dapps/smart-contract-dev/deploy-nft-collection/deploy-erc-721). \ No newline at end of file +Now that the image and metadata files are ready, we can prepare to deploy a smart contract by following this [ERC-721 tutorial](/dapps/deploy-nft-collection/deploy-erc-721). diff --git a/content/docs/dapps/end-to-end/fuji-workflow.mdx b/content/docs/dapps/end-to-end/fuji-workflow.mdx index 50f2fadd6ae..b13ce223f2a 100644 --- a/content/docs/dapps/end-to-end/fuji-workflow.mdx +++ b/content/docs/dapps/end-to-end/fuji-workflow.mdx @@ -17,8 +17,8 @@ In this tutorial, we'll go through an example Fuji workflow to show how it can be used. We'll do the following: 1. Set up Fuji network on Core (optional) -2. Generate a 24 word english mnemonic via AvalancheJS -3. Derive external C-Chain addresses via AvalancheJS +2. Generate a 24 word english mnemonic vian AvalancheJS +3. Derive external C-Chain addresses vian AvalancheJS 4. Get AVAX from the Fuji faucet 5. Send AVAX via ethersJS 6. Examine the resulting transaction on the Avalanche Explorer @@ -29,19 +29,19 @@ be used. We'll do the following: To access the Fuji test network, Testnet Mode needs to be enabled. In order to do that, go to **Settings** and click on **Advanced**. -![Settings image 1](/images/c-chain-ERC20/settings1.png) +![Settings image 1](/images/fuji1.png) Here, turn on the **Testnet Mode** feature. This will automatically make Core switch to Fuji Testnet. -![Settings image 2](/images/c-chain-ERC20/settings2.png) +![Settings image 2](/images/fuji2.png) If you are using other wallets, like MetaMask, you can add the Fuji Testnet using the following details: - **Network Name**: Avalanche C-Chain -- **New RPC URL**: [https://api.avax-test.network/ext/bc/C/rpc](https://api.avax-test.network/ext/bc/C/rpc) +- **New RPC URL**: `https://api.avax-test.network/ext/bc/C/rpc` - **ChainID**: `43113` - **Symbol**: AVAX - **Explorer**: [`https://testnet.snowtrace.io`](https://testnet.snowtrace.io/) @@ -57,7 +57,7 @@ Portuguese, Chinese Simplified and Chinese Traditional. First, generate a 24 word english [BIP39](https://github.com/bitcoin/bips/blob/master/bip-0039.mediawiki)-compliant -mnemonic via AvalancheJS. +mnemonic vian AvalancheJS. ```ts import { Mnemonic } from "avalanche"; @@ -163,13 +163,13 @@ Admins and mods on the official [Discord](https://discord.com/invite/RwXY7P6) can provide testnet AVAX if developers are unable to obtain it from the other two options. These AVAX are for the Fuji Testnet and have no monetary value. -![Requesting AVAX](/images/fuji-workflow/faucet1.png) +![Requesting AVAX](/images/fuji3.png) The faucet will send some AVAX to the address and return a transaction ID (txID). This txID can be used with the Fuji Testnet Explorer to learn more about the transaction. -![Receiving AVAX](/images/fuji-workflow/faucet2.png) +![Receiving AVAX](/images/fuji4.png) ### Check the Transaction Details @@ -178,13 +178,13 @@ can be seen on the [Fuji Testnet Explorer](https://subnets-test.avax.network/c-chain/tx/0x86eef1a01b0a5fd45f2a71c217f99d63d427230a271d3319004f17fc26d7fb26). Avalanche also has a [Mainnet Explorer](https://explorer.avax.network). -![Transaction details](/images/faucet-fuji-wf-alt-tx1.png) +![Transaction details](/images/fuji5.png) ### Get the Balance We can also use the Fuji Explorer to get the balance for the 1st address—[0x2d1d87fF3Ea2ba6E0576bCA4310fC057972F2559](https://explorer.avax-test.network/address/0x2d1d87fF3Ea2ba6E0576bCA4310fC057972F2559). -![1st derived address balance](/images/faucet-fuji-wf-alt-balance.png) +![1st derived address balance](/images/fuji6.png) Alternatively, we can use [ethersJS](https://docs.ethers.io/v5/) to get the balance. @@ -249,7 +249,7 @@ We can verify that the transaction, successful using the Fuji Testnet Explorer. The transaction can be seen [here](https://testnet.snowtrace.io/tx/0x3a5f4198b3be8d24b272f8255912aae4dcf2fb1f97f70d1787434de7b3097aac). -![Transaction details](/images/fuji-wf-alt-tx-2.png) +![Transaction details](/images/fuji7.png) #### Get the Balance @@ -285,18 +285,18 @@ that it derives the hexadecimal address from the private key. Use the private key to access the account in Core Extension. -![Access the wallet](/images/fuji-wf-alt-enter-key.png) +![Access the wallet](/images/fuji8.png) The balance is correct and the address is the 1st derived address. -![Core extension balance](/images/fuji-wf-wallet-alt-info.png) ![3rd derived BIP44 address](/images/fuji-wf-alt-wallet-address.png) +![Core extension balance](/images/fuji9.png) ![3rd derived BIP44 address](/images/fuji10.png) We can repeat this login process using the private keys from the remaining 2 addresses in the [script above](#generate-private-keys-from-a-mnemonic). -![Wallet derived addresses](/images/fuji-wf-alt-wallet-address-2.png) -![Wallet derived addresses2](/images/fuji-wf-alt-wallet-address-3.png) -![Wallet derived addresses3](/images/fuji-wf-alt-wallet-addresses.png) +![Wallet derived addresses](/images/fuji11.png) +![Wallet derived addresses2](/images/fuji12.png) +![Wallet derived addresses3](/images/fuji13.png) ## Summary @@ -318,7 +318,7 @@ addresses to help you test. (This testnet AVAX has no value.) ### Wallet [Core extension](https://join.core.app/extension) and -[Core mobile](https://support.avax.network/en/articles/6115608-core-mobile-where-can-i-download-core-mobile-to-my-phone) +[Core mobile](https://support.avax.network/en/articles/6066926-core-mobile-how-do-i-create-a-new-wallet) are simple, secure, non-custodial wallets for storing Avalanche assets. They support Mainnet, Fuji and custom networks. @@ -330,4 +330,4 @@ The Avalanche Explorer allows you to explore the network on ### RPC Endpoints - Public API Server -See [here.](/tooling/rpc-providers) \ No newline at end of file +See [here.](/tooling/rpc-providers) diff --git a/content/docs/dapps/end-to-end/launch-ethereum-dapp.mdx b/content/docs/dapps/end-to-end/launch-ethereum-dapp.mdx index deed7a052b7..b08d77dfead 100644 --- a/content/docs/dapps/end-to-end/launch-ethereum-dapp.mdx +++ b/content/docs/dapps/end-to-end/launch-ethereum-dapp.mdx @@ -24,12 +24,12 @@ There are multiple ways of working with the C-Chain. Powered by Avalanche, [Core](https://medium.com/avalancheavax/ava-labs-releases-core-an-all-in-one-web3-operating-system-for-avalanche-a844eb822887) -is an all-in-one operating system bringing together Avalanche apps, Subnets, +is an all-in-one operating system bringing together Avalanche apps, Avalanche L1s, bridges, and NFTs in one seamless, high-performance browser experience. Putting in another way, Core is more than a wallet. It is a curated web3 operating -system combining Wallet, Explorer, Bridge, Subnets, dApps, and more. +system combining Wallet, Explorer, Bridge, Avalanche L1s, dApps, and more. -In your application's web interface, follow [this to add Avalanche programmatically](/dapps/advanced/add-avalanche-programmatically.md#core). +In your application's web interface, follow [this to add Avalanche programmatically](/dapps/advanced-tutorials/add-network-programmatically#core). ### Through MetaMask @@ -40,7 +40,7 @@ Avalanche is as follows. #### **Avalanche Mainnet Settings:** - **Network Name**: Avalanche Mainnet C-Chain -- **New RPC URL**: [https://api.avax.network/ext/bc/C/rpc](https://api.avax.network/ext/bc/C/rpc) +- **New RPC URL**: `https://api.avax.network/ext/bc/C/rpc` - **ChainID**: `43114` - **Symbol**: `AVAX` - **Explorer**: [https://snowtrace.io/](https://snowtrace.io/) @@ -48,13 +48,13 @@ Avalanche is as follows. #### **Fuji Testnet Settings:** - **Network Name**: Avalanche Fuji C-Chain -- **New RPC URL**: [https://api.avax-test.network/ext/bc/C/rpc](https://api.avax-test.network/ext/bc/C/rpc) +- **New RPC URL**: `https://api.avax-test.network/ext/bc/C/rpc` - **ChainID**: `43113` - **Symbol**: `AVAX` - **Explorer**: [https://testnet.snowtrace.io/](https://testnet.snowtrace.io/) In your application's web interface, you can -[add Avalanche programmatically](/dapps/advanced/add-avalanche-programmatically.md#metamask) +[add Avalanche programmatically](/dapps/advanced-tutorials/add-network-programmatically#metamask) so your users don't have to enter the network data manually. ### Using the Public API Nodes or RPC Endpoints @@ -63,9 +63,9 @@ Instead of proxying network operations through MetaMask, you can use the public API, which consists of a number of AvalancheGo nodes behind a load balancer. The C-Chain API endpoint is -[https://api.avax.network/ext/bc/C/rpc](https://api.avax.network/ext/bc/C/rpc) +`https://api.avax.network/ext/bc/C/rpc` for the Mainnet and -[https://api.avax-test.network/ext/bc/C/rpc](https://api.avax-test.network/ext/bc/C/rpc) +`https://api.avax-test.network/ext/bc/C/rpc` for the testnet. For more information, see [documentation](/tooling/rpc-providers). @@ -89,7 +89,7 @@ prebuilt binary, available on [GitHub](https://github.com/ava-labs/avalanchego/releases). If you're going to run a node on a Linux machine, you can use the -[installer script](/nodes/run/using-install-script/installing-avalanche-go) to install the node as a +[installer script](/nodes/using-install-script/installing-avalanche-go) to install the node as a `systemd` service. Script also handles node upgrading. If you want to run a node in a docker container, there are [build @@ -182,13 +182,13 @@ C-Chain. ### Remix There is a -[tutorial](/dapps/smart-contracts/remix-deploy) +[tutorial](/dapps/smart-contract-dev/deploy-with-remix-ide) for using Remix to deploy smart contracts on Avalanche. It relies on Core for access to the Avalanche network. ### thirdweb -You can also use thirdweb to test and deploy smart contracts on Avalanche. Find out how in this [tutorial](/dapps/smart-contracts/toolchains/thirdweb). +You can also use thirdweb to test and deploy smart contracts on Avalanche. Find out how in this [tutorial](/dapps/toolchains/thirdweb). ### Hardhat @@ -196,7 +196,7 @@ Hardhat is the newest development and testing environment for Solidity smart contracts, and the one our developers use the most. Due to its superb testing support, it is the recommended way of developing for Avalanche. -For more information see [this doc](/dapps/smart-contracts/toolchains/hardhat). +For more information see [this doc](/dapps/toolchains/hardhat). ## Avalanche Explorer @@ -237,7 +237,7 @@ signal that your users can trust your contracts, and it is strongly recommended for all production contracts. See -[this](/dapps/smart-contracts/verification/verify-hardhat) +[this](/dapps/verify-contract/hardhat) for a detailed tutorial with Hardhat. ## Contract Security Checks @@ -319,3 +319,4 @@ deploy, and test your dapps. If you have questions, problems, or just want to chat with us, you can reach us on our public [Discord](https://chat.avalabs.org/) server. We'd love to hear from you and find out what you're building on Avalanche! + diff --git a/content/docs/dapps/index.mdx b/content/docs/dapps/index.mdx index c931d88cb3f..30e31ec3183 100644 --- a/content/docs/dapps/index.mdx +++ b/content/docs/dapps/index.mdx @@ -9,4 +9,4 @@ C-Chain runs a fork of [`go-ethereum`](https://geth.ethereum.org/docs/rpc/server As a result, you get a blockchain that can run all the Solidity smart contracts from Ethereum, but with much greater transaction bandwidth and instant finality that [Avalanche's revolutionary consensus](/learn/avalanche-consensus) enables. -Coreth is loaded as a plugin into [AvalancheGo](https://github.com/ava-labs/avalanchego), the client node application used to run Avalanche network. Any Dapp deployed to Avalanche C-Chain will be running the same as on Ethereum, just faster and cheaper. \ No newline at end of file +Coreth is loaded as a plugin into [AvalancheGo](https://github.com/ava-labs/avalanchego), the client node application used to run Avalanche network. Any Dapp deployed to Avalanche C-Chain will be running the same as on Ethereum, just faster and cheaper. diff --git a/content/docs/dapps/smart-contract-dev/deploy-with-remix-ide.mdx b/content/docs/dapps/smart-contract-dev/deploy-with-remix-ide.mdx index d0214bfb03f..a21ab98f953 100644 --- a/content/docs/dapps/smart-contract-dev/deploy-with-remix-ide.mdx +++ b/content/docs/dapps/smart-contract-dev/deploy-with-remix-ide.mdx @@ -3,7 +3,7 @@ title: Deploy with Remix IDE description: Learn how to deploy smart contracts on Avalanche using Remix and Core Wallet. --- -Avalanche's Primary Network is a Subnet that has three chains: P-Chain, X-Chain, and C-Chain. The C-Chain is an instance of the Ethereum Virtual Machine powered by Avalanche's Snowman consensus protocol. The [C-Chain RPC](/api-reference/c-chain/api) can do anything a typical Ethereum client can by using the Ethereum-standard RPC calls. +Avalanche's Primary Network is an Avalanche L1 that has three chains: P-Chain, X-Chain, and C-Chain. The C-Chain is an instance of the Ethereum Virtual Machine powered by Avalanche's Snowman consensus protocol. The [C-Chain RPC](/api-reference/c-chain/api) can do anything a typical Ethereum client can by using the Ethereum-standard RPC calls. The immediate benefits of using the C-Chain rather than Ethereum are all of the benefits of using Avalanche. These properties that could considerably improve the performance of Dapps and the user experience. @@ -31,7 +31,7 @@ To switch to the **Fuji test network**, go to **Settings**, select **Advanced**, ### Using Core Web -On the Mainnet, you can use [Core web](https://core.app/) to transfer funds from the X-Chain to your C-Chain address. The process is simple, as explained in this [tutorial](https://support.avax.network/en/articles/8133713-core-web-how-do-i-make-cross-chain-transfers-in-core-stake). Please note that you will need [Core wallet](https://join.core.app/extension) connected to Core web for making cross-chain transfers. Core wallet can be used on test and local networks, too. This wallet is available for [mobile](https://support.avax.network/en/articles/6115608-core-mobile-where-can-i-download-core-mobile-to-my-phone) too. +On the Mainnet, you can use [Core web](https://core.app/) to transfer funds from the X-Chain to your C-Chain address. The process is simple, as explained in this [tutorial](https://support.avax.network/en/articles/8133713-core-web-how-do-i-make-cross-chain-transfers-in-core-stake). Please note that you will need [Core wallet](https://join.core.app/extension) connected to Core web for making cross-chain transfers. Core wallet can be used on test and local networks, too. This wallet is available for [mobile](https://support.avax.network/en/articles/6114992-what-is-the-core-extension) too. ### Using Testnet Faucet @@ -39,7 +39,7 @@ For funding on the test network, Avalanche has a [Faucet](https://core.app/tools ### Funding on Local Testnet -On a local network, you can easily fund your addresses by following [this](/subnets/build-first-subnet#importing-the-test-private-key) guide. +On a local network, you can easily fund your addresses by following [this](/avalanche-l1s/build-first-avalanche-l1#importing-the-test-private-key) guide. ## Connect Core & Deploy Smart Contract Using Remix @@ -85,4 +85,4 @@ The contract ABI and Bytecode are available on the Solidity compiler tab. ![](/images/remix11.png) -If you had any difficulties following this tutorial or simply want to discuss Avalanche with us, you can join our community at [Discord](https://chat.avalabs.org/)! \ No newline at end of file +If you had any difficulties following this tutorial or simply want to discuss Avalanche with us, you can join our community at [Discord](https://chat.avalabs.org/)! diff --git a/content/docs/dapps/smart-contract-dev/erc-20-token.mdx b/content/docs/dapps/smart-contract-dev/erc-20-token.mdx index b0607ffab01..33cb166f8b8 100644 --- a/content/docs/dapps/smart-contract-dev/erc-20-token.mdx +++ b/content/docs/dapps/smart-contract-dev/erc-20-token.mdx @@ -127,4 +127,4 @@ Now we minted 1000 token to our contract, but you should not be able to see the Click on Add custom token. Here,enter the token address that you can see from the explorer, as showed above. Copy and paste it here. Then click on the Add token button, you should see 1000 token that you named in your Core wallet. Also, you can send it to another account via either remix or Core. -![Add token 3](/images/erc19.png) \ No newline at end of file +![Add token 3](/images/erc19.png) diff --git a/content/docs/dapps/smart-contract-dev/get-test-funds.mdx b/content/docs/dapps/smart-contract-dev/get-test-funds.mdx index b4c6de62722..4ccb4e573ad 100644 --- a/content/docs/dapps/smart-contract-dev/get-test-funds.mdx +++ b/content/docs/dapps/smart-contract-dev/get-test-funds.mdx @@ -16,3 +16,4 @@ If you already have an AVAX balance greater than zero on Mainnet, paste your C-C Otherwise, please request a faucet coupon on [Guild](https://guild.xyz/avalanche). Admins and mods on the official [Discord](https://discord.com/invite/RwXY7P6) can provide testnet AVAX if developers are unable to obtain it from the other two options. ![Requesting Coupon](/images/test-fund3.png) + diff --git a/content/docs/dapps/smart-contract-dev/interact-golang-app.mdx b/content/docs/dapps/smart-contract-dev/interact-golang-app.mdx index 2f341459e0c..d5ea9e195d0 100644 --- a/content/docs/dapps/smart-contract-dev/interact-golang-app.mdx +++ b/content/docs/dapps/smart-contract-dev/interact-golang-app.mdx @@ -170,3 +170,4 @@ func main() { log.Println("storageValue", storageValue) } ``` + diff --git a/content/docs/dapps/toolchains/foundry.mdx b/content/docs/dapps/toolchains/foundry.mdx index f052d88d262..5a913e26f52 100644 --- a/content/docs/dapps/toolchains/foundry.mdx +++ b/content/docs/dapps/toolchains/foundry.mdx @@ -10,7 +10,7 @@ description: Deploy and interact with smart contracts using foundry on a local A - Basic understanding of [Solidity](https://docs.soliditylang.org/) and Avalanche. - You are familiar with [Avalanche Smart Contract Quickstart](https://github.com/ava-labs/avalanche-smart-contract-quickstart). - Basic understanding of the [Avalanche's architecture](/learn/primary-network) -- performed a cross-chain swap via this [this tutorial](https://support.avax.network/en/articles/6169872-how-to-make-a-cross-chain-transfer-in-the-avalanche-wallet) to get funds to your C-Chain address. +- performed a cross-chain swap via this [this tutorial](https://support.avax.network/en/articles/8133713-core-web-how-do-i-make-cross-chain-transfers-in-core-stake) to get funds to your C-Chain address. ## Requirements @@ -50,7 +50,7 @@ yarn install The repository cloning method used is HTTPS, but SSH can be used too: -`git clone [[email protected]](https://docs.avax.network/cdn-cgi/l/email-protection):ava-labs/avalanche-smart-contract-quickstart.git` +`git clone git@github.com:ava-labs/avalanche-smart-contract-quickstart.git` You can find more about SSH and how to use it [here](https://docs.github.com/en/authentication/connecting-to-github-with-ssh/about-ssh). @@ -300,4 +300,4 @@ The example PRIVATE_KEY variable above provides a pre-funded account on Avalanch Now you have the tools you need to launch a local Avalanche network, create a Foundry project, as well as create, compile, deploy and interact with Solidity contracts. -Join our [Discord Server](https://chat.avax.network/) to learn more and ask any questions you may have. \ No newline at end of file +Join our [Discord Server](https://chat.avax.network/) to learn more and ask any questions you may have. diff --git a/content/docs/dapps/toolchains/hardhat.mdx b/content/docs/dapps/toolchains/hardhat.mdx index 0fd09d56589..3b8cd34de05 100644 --- a/content/docs/dapps/toolchains/hardhat.mdx +++ b/content/docs/dapps/toolchains/hardhat.mdx @@ -34,7 +34,7 @@ yarn install The repository cloning method used is HTTPS, but SSH can be used too: -`git clone [[email protected]](https://docs.avax.network/cdn-cgi/l/email-protection):ava-labs/avalanche-smart-contract-quickstart.git` +`git clone git@github.com:ava-labs/avalanche-smart-contract-quickstart.git` You can find more about SSH and how to use it [here](https://docs.github.com/en/authentication/connecting-to-github-with-ssh/about-ssh). @@ -234,7 +234,7 @@ task( }); ``` -This will return the result in wei. If you want to know the exact amount of token with its token name then you need to divide it with its decimal. `erc20.abi.json` can be [found here](https://docs.avax.network/assets/files/erc20.abi-a562e36ad30a4d751911073568ea0546.json). +This will return the result in wei. If you want to know the exact amount of token with its token name then you need to divide it with its decimal. `erc20.abi.json` can be [found here](https://gist.github.com/veox/8800debbf56e24718f9f483e1e40c35c). The example uses the [C-Chain Public API](/api-reference/c-chain/api#endpoints) for the provider. For a local Avalanche network use `http://127.0.0.1:9650/ext/bc/C/rpc` and for Fuji Testnet use `https://api.avax-test.network/ext/bc/C/rpc`. @@ -481,7 +481,7 @@ BigNumber { _hex: '0x00', _isBigNumber: true } '0' ``` -`account[0]` has a balance because `account[0]` is the default account. The contract is deployed with this account. The constructor of [ERC20.sol](https://github.com/ava-labs/avalanche-smart-contract-quickstart/blob/main/contracts/ERC20.sol) mints `TOTAL_SUPPLY` of 123456789 token to the deployer of the contract. +`account[0]` has a balance because `account[0]` is the default account. The contract is deployed with this account. The constructor of [ERC20.sol](https://github.com/ava-labs/avalanche-smart-contract-quickstart/blob/main/contracts/ExampleERC20.sol) mints `TOTAL_SUPPLY` of 123456789 token to the deployer of the contract. `accounts[1]` currently has no balance. Send some tokens to `accounts[1]`, which is `0x9632a79656af553F58738B0FB750320158495942`. @@ -582,4 +582,4 @@ We've successfully transferred 5 tokes from `accounts[1]` to `accounts[0]` Now you have the tools you need to launch a local Avalanche network, create a Hardhat project, as well as create, compile, deploy and interact with Solidity contracts. -Join our [Discord Server](https://chat.avax.network/) to learn more and ask any questions you may have. \ No newline at end of file +Join our [Discord Server](https://chat.avax.network/) to learn more and ask any questions you may have. diff --git a/content/docs/dapps/toolchains/index.mdx b/content/docs/dapps/toolchains/index.mdx index da1e638bf03..b67a5237afd 100644 --- a/content/docs/dapps/toolchains/index.mdx +++ b/content/docs/dapps/toolchains/index.mdx @@ -2,4 +2,4 @@ title: Toolchains description: Learn about different toolchains available on the Avalanche C-chain. index: true ---- \ No newline at end of file +--- diff --git a/content/docs/dapps/toolchains/thirdweb.mdx b/content/docs/dapps/toolchains/thirdweb.mdx index b30a4369c44..2a8d3d73f56 100644 --- a/content/docs/dapps/toolchains/thirdweb.mdx +++ b/content/docs/dapps/toolchains/thirdweb.mdx @@ -34,7 +34,7 @@ To create a new smart contract using thirdweb CLI, follow these steps: 4. In the `contracts` folder, you will find the smart contract written in Solidity. The following is code for an ERC721Base contract without specified extensions. It implements all of the logic inside the [`ERC721Base.sol`](https://github.com/thirdweb-dev/contracts/blob/main/contracts/base/ERC721Base.sol) - contract; which implements [`ERC721A`](https://github.com/third-web-dev/constracts/blob/main/constract/eip/Erc271A.sol) standard. + contract; which implements [`ERC721A`](https://github.com/thirdweb-dev/contracts/blob/main/contracts/eip/ERC721A.sol) standard. ```solidity // SPDX-License-Identifier: MIT @@ -92,3 +92,4 @@ Deploy allows you to deploy a smart contract to any EVM compatible network witho For additional information on deploying smart contracts with thirdweb, please reference [thirdweb's documentation](https://portal.thirdweb.com/deploy). If you have any further questions or encounter any issues during the process, please reach out to thirdweb support at [support.thirdweb.com](http://support.thirdweb.com/). + diff --git a/content/docs/dapps/verify-contract/hardhat.mdx b/content/docs/dapps/verify-contract/hardhat.mdx index d7a0aae8fcb..6ffc2a61523 100644 --- a/content/docs/dapps/verify-contract/hardhat.mdx +++ b/content/docs/dapps/verify-contract/hardhat.mdx @@ -249,3 +249,4 @@ main() process.exit(1) }) ``` + diff --git a/content/docs/dapps/verify-contract/index.mdx b/content/docs/dapps/verify-contract/index.mdx index 8cc633a6a30..5be0c7d279b 100644 --- a/content/docs/dapps/verify-contract/index.mdx +++ b/content/docs/dapps/verify-contract/index.mdx @@ -2,4 +2,4 @@ title: Verify Contract description: Learn how to verify a contract on the Avalanche C-chain. index: true ---- \ No newline at end of file +--- diff --git a/content/docs/dapps/verify-contract/snowtrace.mdx b/content/docs/dapps/verify-contract/snowtrace.mdx index 8eb386b0bd2..57a95892cbd 100644 --- a/content/docs/dapps/verify-contract/snowtrace.mdx +++ b/content/docs/dapps/verify-contract/snowtrace.mdx @@ -62,15 +62,15 @@ Example [online converter](https://emn178.github.io/online-tools/keccak_256.html ## Examples -- [SwapFlashLoan](https://testnet.snowtrace.io/address/0x12DF75Fed4DEd309477C94cE491c67460727C0E8/contracts) +- [SwapFlashLoan](https://testnet.snowtrace.io/address/0x12DF75Fed4DEd309477C94cE491c67460727C0E8/contract/43113/code) SwapFlashLoan uses `swaputils` and `mathutils`: -- [SwapUtils](https://testnet.snowtrace.io/address/0x6703e4660E104Af1cD70095e2FeC337dcE034dc1/contracts) +- [SwapUtils](https://testnet.snowtrace.io/address/0x6703e4660E104Af1cD70095e2FeC337dcE034dc1/contract/43113/code) SwapUtils requires mathutils: -- [MathUtils](https://testnet.snowtrace.io/address/0xbA21C84E4e593CB1c6Fe6FCba340fa7795476966/contracts) +- [MathUtils](https://testnet.snowtrace.io/address/0xbA21C84E4e593CB1c6Fe6FCba340fa7795476966/contract/43113/code) ## Caveats @@ -115,4 +115,4 @@ contract Main is Parent { } ``` -If you receive errors about constructor arguments, they can be provided in ABI hex encoded form on the contract verification page. \ No newline at end of file +If you receive errors about constructor arguments, they can be provided in ABI hex encoded form on the contract verification page. diff --git a/content/docs/learn/avalanche-community-proposals.mdx b/content/docs/learn/avalanche-community-proposals.mdx index dfc4fac6845..47c0e4e3177 100644 --- a/content/docs/learn/avalanche-community-proposals.mdx +++ b/content/docs/learn/avalanche-community-proposals.mdx @@ -11,10 +11,10 @@ ACPs are an open framework for proposing improvements and gathering consensus ar There are three kinds of ACP: -- A `Standards Track` ACP describes a change to the design or function of the Avalanche Network, such as a change to the P2P networking protocol, P-Chain design, Subnet architecture, or any change/addition that affects the interoperability of Avalanche Network Clients (ANCs). -- A `Best Practices Track` ACP describes a design pattern or common interface that should be used across the Avalanche Network to make it easier to integrate with Avalanche or for Subnets to interoperate with each other. This would include things like proposing a smart contract interface, not proposing a change to how smart contracts are executed. +- A `Standards Track` ACP describes a change to the design or function of the Avalanche Network, such as a change to the P2P networking protocol, P-Chain design, Avalanche L1 architecture, or any change/addition that affects the interoperability of Avalanche Network Clients (ANCs). +- A `Best Practices Track` ACP describes a design pattern or common interface that should be used across the Avalanche Network to make it easier to integrate with Avalanche or for Avalanche L1s to interoperate with each other. This would include things like proposing a smart contract interface, not proposing a change to how smart contracts are executed. - A `Meta Track` ACP describes a change to the ACP process or suggests a new way for the Avalanche Community to collaborate. -- A `Subnet Track` ACP describes a change to a particular Subnet. This would include things like configuration changes or coordinated Subnet upgrades. +- A `Subnet Track` ACP describes a change to a particular Avalanche L1. This would include things like configuration changes or coordinated Layer 1 upgrades. ## ACP Statuses @@ -94,4 +94,10 @@ Copyright and related rights waived via [CC0](https://creativecommons.org/public ## Contributing -Before contributing to ACPs, please read the [ACP Terms of Contribution](https://github.com/avalanche-foundation/ACPs/blob/main/CONTRIBUTING.md). \ No newline at end of file +Before contributing to ACPs, please read the [ACP Terms of Contribution](https://github.com/avalanche-foundation/ACPs/blob/main/CONTRIBUTING.md). + + + + + + diff --git a/content/docs/learn/avalanche-consensus.mdx b/content/docs/learn/avalanche-consensus.mdx index 0d60fbc521f..a2338ce0f9c 100644 --- a/content/docs/learn/avalanche-consensus.mdx +++ b/content/docs/learn/avalanche-consensus.mdx @@ -174,4 +174,10 @@ Avalanche is very performant. It can process thousands of transactions per secon ## Summary -Avalanche consensus is a radical breakthrough in distributed systems. It represents as large a leap forward as the classical and Nakamoto consensus protocols that came before it. Now that you have a better understanding of how it works, check out other documentations for building game-changing Dapps and financial instruments on Avalanche. \ No newline at end of file +Avalanche consensus is a radical breakthrough in distributed systems. It represents as large a leap forward as the classical and Nakamoto consensus protocols that came before it. Now that you have a better understanding of how it works, check out other documentations for building game-changing Dapps and financial instruments on Avalanche. + + + + + + diff --git a/content/docs/learn/avalanche-l1s.mdx b/content/docs/learn/avalanche-l1s.mdx new file mode 100644 index 00000000000..fb10f1e2544 --- /dev/null +++ b/content/docs/learn/avalanche-l1s.mdx @@ -0,0 +1,74 @@ +--- +title: Avalanche L1s +description: Explore the multi-chain architecture of Avalanche ecosystem. +--- + +an Avalanche L1 is a sovereign network which defines its own rules regarding its membership and token economics. It is composed of a dynamic subset of Avalanche validators working together to achieve consensus on the state of one or more blockchains. Each blockchain is validated by exactly one Avalanche L1, while an Avalanche L1 can validate many blockchains. + +Avalanche's [Primary Network](/learn/primary-network) is a special Avalanche L1 running three blockchains: + +- The Platform Chain [(P-Chain)](/learn/primary-network#p-chain) +- The Contract Chain [(C-Chain)](/learn/primary-network#c-chain) +- The Exchange Chain [(X-Chain)](/learn/primary-network#x-chain) + +![image](/images/subnet1.png) + +(Image adopted from [this article](https://www.coinbase.com/cloud/discover/dev-foundations/intro-to-avalanche-subnets)) + + +Every validator in an Avalanche L1 **must** also validate the Primary Network. + + +Node operators that validate an Avalanche L1 with multiple chains do not need to run multiple machines for validation. For example, the Primary Network is an Avalanche L1 with three coexisting chains, all of which can be validated by a single node, or a single machine. + +## Advantages + +### Independent Networks + +- Avalanche L1s use virtual machines to specify their own execution logic, determine their own fee regime, maintain their own state, facilitate their own networking, and provide their own security. +- Each Avalanche L1's performance is isolated from other Avalanche L1s in the ecosystem, so increased usage on one Avalanche L1 won't affect another. +- Avalanche L1s can have their own token economics with their own native tokens, fee markets, and incentives determined by the Avalanche L1 deployer. +- One Avalanche L1 can host multiple blockchains with customized [virtual machines](/learn/virtual-machines). + +### Native Interoperability + +Avalanche Warp Messaging enables native cross-Avalanche L1 communication and allows Virtual Machine (VM) developers to implement arbitrary communication protocols between any two Avalanche L1s. + +### Accommodate App-Specific Requirements + +Different blockchain-based applications may require validators to have certain properties such as large amounts of RAM or CPU power. + +an Avalanche L1 could require that validators meet certain [hardware requirements](/nodes/run-a-node/manually#hardware-and-os-requirements) so that the application doesn't suffer from low performance due to slow validators. + +### Launch Networks Designed With Compliance + +Avalanche's Avalanche L1 architecture makes regulatory compliance manageable. As mentioned above, an Avalanche L1 may require validators to meet a set of requirements. + +Some examples of requirements the creators of an Avalanche L1 may choose include: + +- Validators must be located in a given country. +- Validators must pass KYC/AML checks. +- Validators must hold a certain license. + +### Control Privacy of On-Chain Data + +Avalanche L1s are ideal for organizations interested in keeping their information private. + +Institutions conscious of their stakeholders' privacy can create a private Avalanche L1 where the contents of the blockchains would be visible only to a set of pre-approved validators. + +Define this at creation with a [single parameter](/nodes/configure/avalanche-l1-configs#private-avalanche-l1). + +### Validator Sovereignty + +In a heterogeneous network of blockchains, some validators will not want to validate certain blockchains because they simply have no interest in those blockchains. + +The Avalanche L1 model enables validators to concern themselves only with blockchain networks they choose to participate in. This greatly reduces the computational burden on validators. + +## Develop Your Own Avalanche L1 + +Avalanche L1s on Avalanche are deployed by default with [Subnet-EVM](https://github.com/ava-labs/subnet-evm#subnet-evm), a fork of go-ethereum. It implements the Ethereum Virtual Machine and supports Solidity smart contracts as well as most other Ethereum client functionality. + +To get started, check out the tutorials in our [Avalanche L1s](/avalanche-l1s/build-first-avalanche-l1) section. + + + diff --git a/content/docs/learn/avax-token.mdx b/content/docs/learn/avax-token.mdx index 798eb679756..30bd8fc985c 100644 --- a/content/docs/learn/avax-token.mdx +++ b/content/docs/learn/avax-token.mdx @@ -3,7 +3,7 @@ title: AVAX Token description: Learn about the native token of Avalanche Primary Network. --- -AVAX is the native utility token of Avalanche. It's a hard-capped, scarce asset that is used to pay for fees, secure the platform through staking, and provide a basic unit of account between the multiple Subnets created on Avalanche. +AVAX is the native utility token of Avalanche. It's a hard-capped, scarce asset that is used to pay for fees, secure the platform through staking, and provide a basic unit of account between the multiple Avalanche L1s created on Avalanche. `1 nAVAX` is equal to `0.000000001 AVAX`. @@ -72,4 +72,7 @@ amount of time incurs an additional 11.11% of tokens minted, incentivizing stake for longer periods. Due to the capped-supply, the above function guarantees that -AVAX will never exceed a total of $720M$ tokens, or $\lim_{j \to \infty} R(j) = 720M$. \ No newline at end of file +AVAX will never exceed a total of $720M$ tokens, or $\lim_{j \to \infty} R(j) = 720M$. + + + diff --git a/content/docs/learn/disclaimer.mdx b/content/docs/learn/disclaimer.mdx index c896a9de833..ba83c7a818e 100644 --- a/content/docs/learn/disclaimer.mdx +++ b/content/docs/learn/disclaimer.mdx @@ -11,3 +11,7 @@ Please conduct your own research before connecting to or interacting with any da MoonPay, ParaSwap and any other third party services or dapps you access are offered by third parties unaffiliated with us. Please review this [Notice](https://assets.website-files.com/602e8e4411398ca20cfcafd3/60ec9607c853cd466383f1ad_Important%20Notice%20-%20avalabs.org.pdf) and the [Terms of Use](https://core.app/terms/core). + + + + diff --git a/content/docs/learn/index.mdx b/content/docs/learn/index.mdx index 41d433a2046..b9451066ab0 100644 --- a/content/docs/learn/index.mdx +++ b/content/docs/learn/index.mdx @@ -13,7 +13,7 @@ Avalanche employs the fastest consensus mechanism of any Layer 1 blockchain. The ## Built to Scale -Developers who build on Avalanche can build application-specific blockchains with complex rulesets or build on existing private or public Subnets in any language. +Developers who build on Avalanche can build application-specific blockchains with complex rulesets or build on existing private or public Avalanche L1s in any language. Avalanche is incredibly energy-efficient and can run easily on consumer-grade hardware. The entire Avalanche network consumes the same amount of energy as 46 US households, equivalent to 0.0005% of the amount of energy consumed by Bitcoin. @@ -23,4 +23,7 @@ Solidity developers can build on Avalanche's implementation of the EVM straight Avalanche consensus scales to thousands of concurrent validators without suffering performance degradation making it one of the most secure protocols for internet scaling systems. -Permissionless and permissioned custom blockchains deployed as an Avalanche Subnets can include custom rulesets designed to be compliant with legal and jurisdictional considerations. \ No newline at end of file +Permissionless and permissioned custom blockchains deployed as an Avalanche L1s can include custom rulesets designed to be compliant with legal and jurisdictional considerations. + + + diff --git a/content/docs/learn/meta.json b/content/docs/learn/meta.json index fc0931040a3..97adadb30ff 100644 --- a/content/docs/learn/meta.json +++ b/content/docs/learn/meta.json @@ -6,7 +6,7 @@ "avalanche-consensus", "avax-token", "---Multi-chain Architecture---", - "subnets", + "avalanche-l1s", "primary-network", "rewards-formula", "virtual-machines", diff --git a/content/docs/learn/networks/fuji-testnet.mdx b/content/docs/learn/networks/fuji-testnet.mdx index a6d87c84a21..4b66d76dbed 100644 --- a/content/docs/learn/networks/fuji-testnet.mdx +++ b/content/docs/learn/networks/fuji-testnet.mdx @@ -3,7 +3,7 @@ title: Fuji Testnet description: Learn about the official Testnet for the Avalanche ecosystem. --- -Fuji's infrastructure imitates Avalanche Mainnet. It's comprised of a [Primary Network](/learn/primary-network) formed by instances of X, P, and C-Chain, as well as many test Subnets. +Fuji's infrastructure imitates Avalanche Mainnet. It's comprised of a [Primary Network](/learn/primary-network) formed by instances of X, P, and C-Chain, as well as many test Avalanche L1s. ## When to Use Fuji @@ -17,4 +17,4 @@ To receive testnet tokens, users can request funds from the [Avalanche Faucet](/ - Fuji Testnet has its own dedicated [block explorer](https://subnets-test.avax.network/). - The Public API endpoint for Fuji is not the same as Mainnet. More info is available in the [Public API Server](/tooling/rpc-providers) documentation. -- While Fuji Network is a valuable resource, developers also have the option to explore [Avalanche Network Runner](/tooling/avalanche-network-runner/introduction) as an alternative means of locally testing their projects, ensuring comprehensive evaluation and fine-tuning before interacting with the wider network. \ No newline at end of file +- While Fuji Network is a valuable resource, developers also have the option to explore [Avalanche Network Runner](/tooling/avalanche-network-runner/introduction) as an alternative means of locally testing their projects, ensuring comprehensive evaluation and fine-tuning before interacting with the wider network. diff --git a/content/docs/learn/networks/mainnet.mdx b/content/docs/learn/networks/mainnet.mdx index da7cb5646e9..1b50b8c3ef0 100644 --- a/content/docs/learn/networks/mainnet.mdx +++ b/content/docs/learn/networks/mainnet.mdx @@ -5,6 +5,6 @@ description: Learn about the Avalanche Mainnet. The Avalanche Mainnet refers to the main network of the Avalanche blockchain where real transactions and smart contract executions occur. It is the final and production-ready version of the blockchain where users can interact with the network and transact with real world assets. -A _network of networks_, Avalanche Mainnet includes the [Primary Network](/learn/primary-network) formed by the X, P, and C-Chain, as well as all in-production [Subnets](/learn/subnets). +A _network of networks_, Avalanche Mainnet includes the [Primary Network](/learn/primary-network) formed by the X, P, and C-Chain, as well as all in-production [Avalanche L1s](/learn/avalanche-l1s). -These Subnets are independent blockchain sub-networks that can be tailored to specific application use cases, use their own consensus mechanisms, define their own token economics, and be run by different [virtual machines](/learn/virtual-machines). \ No newline at end of file +These Avalanche L1s are independent blockchain sub-networks that can be tailored to specific application use cases, use their own consensus mechanisms, define their own token economics, and be run by different [virtual machines](/learn/virtual-machines). diff --git a/content/docs/learn/primary-network.mdx b/content/docs/learn/primary-network.mdx index ee77efa8ece..e4ffa6efeb6 100644 --- a/content/docs/learn/primary-network.mdx +++ b/content/docs/learn/primary-network.mdx @@ -5,14 +5,14 @@ description: Learn about the Avalanche Primary Network and its three blockchains Avalanche is a heterogeneous network of blockchains. As opposed to homogeneous networks, where all applications reside in the same chain, heterogeneous networks allow separate chains to be created for different applications. -The Primary Network is a special [Subnet](/learn/subnets) that runs three blockchains: +The Primary Network is a special [Avalanche L1](/learn/avalanche-l1s) that runs three blockchains: - The Contract Chain [(C-Chain)](/learn/primary-network#c-chain) - The Platform Chain [(P-Chain)](/learn/primary-network#p-chain) - The Exchange Chain [(X-Chain)](/learn/primary-network#x-chain) -[Avalanche Mainnet](/learn/networks/mainnet) is comprised of the Primary Network and all deployed Subnets. +[Avalanche Mainnet](/learn/networks/mainnet) is comprised of the Primary Network and all deployed Avalanche L1s. A node can become a validator for the Primary Network by staking at least **2,000 AVAX**. @@ -31,7 +31,7 @@ The C-Chain is an instance of the [Coreth](https://github.com/ava-labs/coreth) V ### P-Chain -The **P-Chain** is responsible for all validator and Subnet-level operations. The [P-Chain API](/api-reference/p-chain/api) supports the creation of new blockchains and Subnets, the addition of validators to Subnets, staking operations, and other platform-level operations. +The **P-Chain** is responsible for all validator and Avalanche L1-level operations. The [P-Chain API](/api-reference/p-chain/api) supports the creation of new blockchains and Avalanche L1s, the addition of validators to Avalanche L1s, staking operations, and other platform-level operations. The P-Chain is an instance of the Platform Virtual Machine. @@ -41,4 +41,4 @@ The **X-Chain** is responsible for operations on digital smart assets known as * One asset traded on the X-Chain is AVAX. When you issue a transaction to a blockchain on Avalanche, you pay a fee denominated in AVAX. -The X-Chain is an instance of the Avalanche Virtual Machine (AVM). \ No newline at end of file +The X-Chain is an instance of the Avalanche Virtual Machine (AVM). diff --git a/content/docs/learn/rewards-formula.mdx b/content/docs/learn/rewards-formula.mdx index 8409ea3c973..29673ea6213 100644 --- a/content/docs/learn/rewards-formula.mdx +++ b/content/docs/learn/rewards-formula.mdx @@ -123,3 +123,4 @@ Graph variables correspond to those defined above: - `s` = $\frac{Stake}{Supply}$ + diff --git a/content/docs/learn/subnets.mdx b/content/docs/learn/subnets.mdx deleted file mode 100644 index 547c6f8ea98..00000000000 --- a/content/docs/learn/subnets.mdx +++ /dev/null @@ -1,71 +0,0 @@ ---- -title: Subnets -description: Explore the multi-chain architecture of Avalanche ecosystem. ---- - -A Subnet is a sovereign network which defines its own rules regarding its membership and token economics. It is composed of a dynamic subset of Avalanche validators working together to achieve consensus on the state of one or more blockchains. Each blockchain is validated by exactly one Subnet, while a Subnet can validate many blockchains. - -Avalanche's [Primary Network](/learn/primary-network) is a special Subnet running three blockchains: - -- The Platform Chain [(P-Chain)](/learn/primary-network#p-chain) -- The Contract Chain [(C-Chain)](/learn/primary-network#c-chain) -- The Exchange Chain [(X-Chain)](/learn/primary-network#x-chain) - -![image](/images/subnet1.png) - -(Image adopted from [this article](https://www.coinbase.com/cloud/discover/dev-foundations/intro-to-avalanche-subnets)) - - -Every validator in a Subnet **must** also validate the Primary Network. - - -Node operators that validate a Subnet with multiple chains do not need to run multiple machines for validation. For example, the Primary Network is a Subnet with three coexisting chains, all of which can be validated by a single node, or a single machine. - -## Advantages - -### Independent Networks - -- Subnets use virtual machines to specify their own execution logic, determine their own fee regime, maintain their own state, facilitate their own networking, and provide their own security. -- Each Subnet's performance is isolated from other Subnets in the ecosystem, so increased usage on one Subnet won't affect another. -- Subnets can have their own token economics with their own native tokens, fee markets, and incentives determined by the Subnet deployer. -- One Subnet can host multiple blockchains with customized [virtual machines](/learn/virtual-machines). - -### Native Interoperability - -Avalanche Warp Messaging enables native cross-Subnet communication and allows Virtual Machine (VM) developers to implement arbitrary communication protocols between any two Subnets. - -### Accommodate App-Specific Requirements - -Different blockchain-based applications may require validators to have certain properties such as large amounts of RAM or CPU power. - -A Subnet could require that validators meet certain [hardware requirements](/nodes/run-a-node/manually#hardware-and-os-requirements) so that the application doesn't suffer from low performance due to slow validators. - -### Launch Networks Designed With Compliance - -Avalanche's Subnet architecture makes regulatory compliance manageable. As mentioned above, a Subnet may require validators to meet a set of requirements. - -Some examples of requirements the creators of a Subnet may choose include: - -- Validators must be located in a given country. -- Validators must pass KYC/AML checks. -- Validators must hold a certain license. - -### Control Privacy of On-Chain Data - -Subnets are ideal for organizations interested in keeping their information private. - -Institutions conscious of their stakeholders' privacy can create a private Subnet where the contents of the blockchains would be visible only to a set of pre-approved validators. - -Define this at creation with a [single parameter](/nodes/configure/subnet-configs#private-subnet). - -### Validator Sovereignty - -In a heterogeneous network of blockchains, some validators will not want to validate certain blockchains because they simply have no interest in those blockchains. - -The Subnet model enables validators to concern themselves only with blockchain networks they choose to participate in. This greatly reduces the computational burden on validators. - -## Develop Your Own Subnet - -Subnets on Avalanche are deployed by default with [Subnet-EVM](https://github.com/ava-labs/subnet-evm#subnet-evm), a fork of go-ethereum. It implements the Ethereum Virtual Machine and supports Solidity smart contracts as well as most other Ethereum client functionality. - -To get started, check out the tutorials in our [Subnets](/subnets/build-first-subnet) section. \ No newline at end of file diff --git a/content/docs/learn/virtual-machines.mdx b/content/docs/learn/virtual-machines.mdx index dbd0004a208..0444d999a2d 100644 --- a/content/docs/learn/virtual-machines.mdx +++ b/content/docs/learn/virtual-machines.mdx @@ -22,34 +22,34 @@ With Avalanche, VMs communicate with Avalanche over a language agnostic request-response protocol known as [RPC](https://en.wikipedia.org/wiki/Remote_procedure_call). This allows the VM framework to open a world of endless possibilities, as developers can implement their Dapps using the languages, frameworks, and libraries of their choice. -To get started, create a VM out-of-the-box with the [Subnet-EVM](/subnets/c-chain-or-subnet) in Solidity, or design a custom VM with languages like Golang, Rust, and many more. +To get started, create a VM out-of-the-box with the [Subnet-EVM](/avalanche-l1s/c-chain-or-avalanche-l1) in Solidity, or design a custom VM with languages like Golang, Rust, and many more. ## Running a VM All Avalanche validators as members of the Avalanche Primary Network are required to run three VMs: - **Coreth**: Defines the Contract Chain (C-Chain); supports smart contract functionality and is EVM-compatible. -- **Platform VM**: Defines the Platform Chain (P-Chain); supports operations on staking and Subnets. +- **Platform VM**: Defines the Platform Chain (P-Chain); supports operations on staking and Avalanche L1s. - **Avalanche VM**: Defines the Exchange Chain (X-Chain); supports operations on Avalanche Native Tokens. -All three can easily be run on any computer with [AvalancheGo](/nodes/quick-links). +All three can easily be run on any computer with [AvalancheGo](/nodes). -Validators can install additional VMs on their node to validate additional [Subnets](/learn/subnets) in the Avalanche ecosystem. In exchange, validators receive staking rewards in the form of a reward token determined by the Subnets. +Validators can install additional VMs on their node to validate additional [Avalanche L1s](/learn/avalanche-l1s) in the Avalanche ecosystem. In exchange, validators receive staking rewards in the form of a reward token determined by the Avalanche L1s. ## Solidity Avalanche natively supports the execution of Ethereum smart contracts written in solidity. -Ethereum developers have the option of deploying their smart contracts on the C-Chain's implementation of the Ethereum Virtual Machine ([Coreth](https://github.com/ava-labs/coreth)), or on their own Subnet using the [Subnet-EVM](https://github.com/ava-labs/subnet-evm) for advanced use cases that require more customization. +Ethereum developers have the option of deploying their smart contracts on the C-Chain's implementation of the Ethereum Virtual Machine ([Coreth](https://github.com/ava-labs/coreth)), or on their own Layer 1 using the [Subnet-EVM](https://github.com/ava-labs/subnet-evm) for advanced use cases that require more customization. Both C-Chain and the Subnet-EVM are compatible with Ethereum tooling like Remix, Core, MetaMask, ThirdWeb, and more. To learn more about smart contract support, click [here](/dapps/end-to-end/launch-ethereum-dapp). ## Golang - [**Coreth**](https://github.com/ava-labs/coreth): An implementation of the EVM that powers the Avalanche C-Chain that supports Solidity smart contracts. -- [**Subnet-EVM**](https://github.com/ava-labs/subnet-evm): An implementation of the EVM that can be deployed to a custom Subnet to support Solidity smart contracts +- [**Subnet-EVM**](https://github.com/ava-labs/subnet-evm): An implementation of the EVM that can be deployed to a custom Avalanche L1 to support Solidity smart contracts - [**TimestampVM**](https://github.com/ava-labs/timestampvm): A decentralized timestamp server -- [**XSVM**](https://github.com/ava-labs/xsvm): An example of Avalanche Warp Messaging that implements Cross-Subnet asset transfers +- [**XSVM**](https://github.com/ava-labs/xsvm): An example of Avalanche Warp Messaging that implements Cross-Avalanche L1 asset transfers See here for a tutorial on [How to Build a Simple Golang VM](/virtual-machines/golang-vms/simple-golang-vm). @@ -59,4 +59,4 @@ The following VMs were built using Rust via the [Avalanche Rust SDK](https://cra - [**TimestampVM RS**](https://github.com/ava-labs/timestampvm-rs): A Rust implementation of TimestampVM -See here for a tutorial on [How to Build a Simple Rust VM](/virtual-machines/rust-vms/setting-up-environment). \ No newline at end of file +See here for a tutorial on [How to Build a Simple Rust VM](/virtual-machines/rust-vms/setting-up-environment). diff --git a/content/docs/nodes/chain-configs/c-chain.mdx b/content/docs/nodes/chain-configs/c-chain.mdx index 337c5571bd3..25b5ff758fc 100644 --- a/content/docs/nodes/chain-configs/c-chain.mdx +++ b/content/docs/nodes/chain-configs/c-chain.mdx @@ -714,4 +714,4 @@ Path to a json file that contains a list of addresses for a genesis airdrop. Eac _Boolean_ -If set to `true`, the chain will skip verifying that all expected network upgrades have taken place before the last accepted block on startup. This allows node operators to recover if their node has accepted blocks after a network upgrade with a version of the code prior to the upgrade. Defaults to `false`. \ No newline at end of file +If set to `true`, the chain will skip verifying that all expected network upgrades have taken place before the last accepted block on startup. This allows node operators to recover if their node has accepted blocks after a network upgrade with a version of the code prior to the upgrade. Defaults to `false`. diff --git a/content/docs/nodes/chain-configs/overview.mdx b/content/docs/nodes/chain-configs/overview.mdx index 809b48c0cc7..0bd64c0c0e1 100644 --- a/content/docs/nodes/chain-configs/overview.mdx +++ b/content/docs/nodes/chain-configs/overview.mdx @@ -6,7 +6,7 @@ Some chains allow the node operator to provide a custom configuration. Avalanche AvalancheGo looks for these files in the directory specified by `--chain-config-dir` AvalancheGo flag, as documented [here](/nodes/configure/configs-flags#--chain-config-dir-string). If omitted, value defaults to `$HOME/.avalanchego/configs/chains`. This directory can have sub-directories whose names are chain IDs or chain aliases. Each sub-directory contains the configuration for the chain specified in the directory name. Each sub-directory should contain a file named `config`, whose value is passed in when the corresponding chain is initialized (see below for extension). For example, config for the C-Chain should be at: `{chain-config-dir}/C/config.json`. -This also applies to Subnets, for example, if a Subnet's chain id is `2ebCneCbwthjQ1rYT41nhd7M76Hc6YmosMAQrTFhBq8qeqh6tt`, the config for this chain should be at `{chain-config-dir}/2ebCneCbwthjQ1rYT41nhd7M76Hc6YmosMAQrTFhBq8qeqh6tt/config.json` +This also applies to Avalanche L1s, for example, if an Avalanche L1's chain id is `2ebCneCbwthjQ1rYT41nhd7M76Hc6YmosMAQrTFhBq8qeqh6tt`, the config for this chain should be at `{chain-config-dir}/2ebCneCbwthjQ1rYT41nhd7M76Hc6YmosMAQrTFhBq8qeqh6tt/config.json` } > By default, none of these directories and/or files exist. You would need to create them manually if needed. @@ -24,11 +24,11 @@ Alternatively, for some setups it might be more convenient to provide config ent It is not required to provide these custom configurations. If they are not provided, a VM-specific default config will be used. And the values of these default config are printed when the node starts. -## Subnet Chain Configs +## Avalanche L1 Chain Configs -As mentioned above, if a Subnet's chain id is `2ebCneCbwthjQ1rYT41nhd7M76Hc6YmosMAQrTFhBq8qeqh6tt`, the config for this chain should be at `{chain-config-dir}/2ebCneCbwthjQ1rYT41nhd7M76Hc6YmosMAQrTFhBq8qeqh6tt/config.json` +As mentioned above, if an Avalanche L1's chain id is `2ebCneCbwthjQ1rYT41nhd7M76Hc6YmosMAQrTFhBq8qeqh6tt`, the config for this chain should be at `{chain-config-dir}/2ebCneCbwthjQ1rYT41nhd7M76Hc6YmosMAQrTFhBq8qeqh6tt/config.json` ## FAQs - When using `getBlockNumber` it will return finalized blocks. To allow for queries for unfinalized (not yet accepted) blocks/transactions use `allow-unfainalized-queries` and set to true (by default it is set to `false`) -- When deactivating offline pruning `(pruning-enabled: false)` from previously enabled state, this will not impact blocks whose state was already pruned. This will return missing trie node errors, as the node can't lookup the state of a historical block if that state was deleted. \ No newline at end of file +- When deactivating offline pruning `(pruning-enabled: false)` from previously enabled state, this will not impact blocks whose state was already pruned. This will return missing trie node errors, as the node can't lookup the state of a historical block if that state was deleted. diff --git a/content/docs/nodes/chain-configs/p-chain.mdx b/content/docs/nodes/chain-configs/p-chain.mdx index 534fba76011..945f11b6a4c 100644 --- a/content/docs/nodes/chain-configs/p-chain.mdx +++ b/content/docs/nodes/chain-configs/p-chain.mdx @@ -17,7 +17,7 @@ In order to specify a configuration for the PlatformVM, you need to define a `Co "UptimeLockedCalculator": null, "SybilProtectionEnabled": false, "PartialSyncPrimaryNetwork": false, - "TrackedSubnets": [], +"TrackedSubnets": [], "TxFee": 0, "CreateAssetTxFee": 0, "CreateSubnetTxFee": 0, @@ -57,7 +57,7 @@ The node's chain manager ### `Validators` -Node's validator set maps SubnetID to validators of the Subnet +Node's validator set maps SubnetID to validators of the Avalanche L1 - The primary network's validator set should have been added to the manager before calling VM.Initialize. - The primary network's validator set should be empty before calling VM.Initialize. @@ -80,7 +80,7 @@ If true, only the P-chain will be instantiated on the primary network. ### `TrackedSubnets` -Set of Subnets that this node is validating +Set of Avalanche L1s that this node is validating ### `TxFee` @@ -98,13 +98,13 @@ Fee that must be burned by every state creating transaction before AP3 _Uint64_ -Fee that must be burned by every Subnet creating transaction after AP3 +Fee that must be burned by every Avalanche L1 creating transaction after AP3 ### `TransformSubnetTxFee` _Uint64_ -Fee that must be burned by every transform Subnet transaction +Fee that must be burned by every transform Avalanche L1 transaction ### `CreateBlockchainTxFee` @@ -128,13 +128,13 @@ Transaction fee for adding a primary network delegator _Uint64_ -Transaction fee for adding a Subnet validator +Transaction fee for adding an Avalanche L1 validator ### `AddSubnetDelegatorFee` _Uint64_ -Transaction fee for adding a Subnet delegator +Transaction fee for adding an Avalanche L1 delegator ### `MinValidatorStake` @@ -222,4 +222,4 @@ Time of the E network upgrade _Boolean_ -UseCurrentHeight forces `GetMinimumHeight` to return the current height of the P-Chain instead of the oldest block in the `recentlyAccepted` window. This config is particularly useful for triggering proposervm activation on recently created Subnets (without this, users need to wait for `recentlyAcceptedWindowTTL` to pass for activation to occur). \ No newline at end of file +UseCurrentHeight forces `GetMinimumHeight` to return the current height of the P-Chain instead of the oldest block in the `recentlyAccepted` window. This config is particularly useful for triggering proposervm activation on recently created Avalanche L1s (without this, users need to wait for `recentlyAcceptedWindowTTL` to pass for activation to occur). diff --git a/content/docs/nodes/chain-configs/x-chain.mdx b/content/docs/nodes/chain-configs/x-chain.mdx index 7980d2c75ce..7245b621ff0 100644 --- a/content/docs/nodes/chain-configs/x-chain.mdx +++ b/content/docs/nodes/chain-configs/x-chain.mdx @@ -26,4 +26,4 @@ If `index-transactions` is set to true, it must always be set to true for the no Allows incomplete indices. This config value is ignored if there is no X-Chain indexed data in the DB and `index-transactions` is set to `false`. -Enables checksums if set to `true`. \ No newline at end of file +Enables checksums if set to `true`. diff --git a/content/docs/nodes/configure/subnet-configs.mdx b/content/docs/nodes/configure/avalanche-l1-configs.mdx similarity index 72% rename from content/docs/nodes/configure/subnet-configs.mdx rename to content/docs/nodes/configure/avalanche-l1-configs.mdx index 927388e74e6..db068083241 100644 --- a/content/docs/nodes/configure/subnet-configs.mdx +++ b/content/docs/nodes/configure/avalanche-l1-configs.mdx @@ -1,5 +1,5 @@ --- -title: Subnet Configs +title: Avalanche L1 Configs --- } > @@ -7,14 +7,14 @@ This page was generated by a plugin that directly references this [file](https:/ -It is possible to provide parameters for a Subnet. Parameters here apply to all -chains in the specified Subnet. +It is possible to provide parameters for an Avalanche L1. Parameters here apply to all +chains in the specified Avalanche L1. AvalancheGo looks for files specified with `{subnetID}.json` under `--subnet-config-dir` as documented -[here](/nodes/configure/configs-flags#subnet-configs). +[here](/nodes/configure/configs-flags#avalanche-l1-configs). -Here is an example of Subnet config file: +Here is an example of Avalanche L1 config file: ```json { @@ -28,35 +28,35 @@ Here is an example of Subnet config file: ## Parameters -### Private Subnet +### Private Avalanche L1 #### `validatorOnly` (bool) -If `true` this node does not expose Subnet blockchain contents to non-validators +If `true` this node does not expose Avalanche L1 blockchain contents to non-validators via P2P messages. Defaults to `false`. -Avalanche Subnets are public by default. It means that every node can sync and -listen ongoing transactions/blocks in Subnets, even they're not validating the -listened Subnet. +Avalanche L1s are public by default. It means that every node can sync and +listen ongoing transactions/blocks in Avalanche L1s, even they're not validating the +listened Avalanche L1. -Subnet validators can choose not to publish contents of blockchains via this +Avalanche L1 validators can choose not to publish contents of blockchains via this configuration. If a node sets `validatorOnly` to true, the node exchanges -messages only with this Subnet's validators. Other peers will not be able to -learn contents of this Subnet from this node. +messages only with this Avalanche L1's validators. Other peers will not be able to +learn contents of this Avalanche L1 from this node. } > -This is a node-specific configuration. Every validator of this Subnet has to use -this configuration in order to create a full private Subnet. +This is a node-specific configuration. Every validator of this Avalanche L1 has to use +this configuration in order to create a full private Avalanche L1. #### `allowedNodes` (string list) If `validatorOnly=true` this allows explicitly specified NodeIDs to be allowed -to sync the Subnet regardless of validator status. Defaults to be empty. +to sync the Avalanche L1 regardless of validator status. Defaults to be empty. } > -This is a node-specific configuration. Every validator of this Subnet has to use -this configuration in order to properly allow a node in the private Subnet. +This is a node-specific configuration. Every validator of this Avalanche L1 has to use +this configuration in order to properly allow a node in the private Avalanche L1. #### `proposerMinBlockDelay` (duration) @@ -70,9 +70,9 @@ frequency at which blocks are built. ### Consensus Parameters -Subnet configs supports loading new consensus parameters. JSON keys are +Avalanche L1 configs supports loading new consensus parameters. JSON keys are different from their matching `CLI` keys. These parameters must be grouped under -`consensusParameters` key. The consensus parameters of a Subnet default to the +`consensusParameters` key. The consensus parameters of an Avalanche L1 default to the same values used for the Primary Network, which are given [CLI Snow Parameters](/nodes/configure/configs-flags#snow-parameters). | CLI Key | JSON Key | @@ -89,7 +89,7 @@ same values used for the Primary Network, which are given [CLI Snow Parameters]( ### Gossip Configs -It's possible to define different Gossip configurations for each Subnet without +It's possible to define different Gossip configurations for each Avalanche L1 without changing values for Primary Network. JSON keys of these parameters are different from their matching `CLI` keys. These parameters default to the same values used for the Primary Network. For more information @@ -102,4 +102,4 @@ see [CLI Gossip Configs](/nodes/configure/configs-flags#gossiping). | --consensus-accepted-frontier-gossip-peer-size | gossipAcceptedFrontierPeerSize | | --consensus-on-accept-gossip-validator-size | gossipOnAcceptValidatorSize | | --consensus-on-accept-gossip-non-validator-size | gossipOnAcceptNonValidatorSize | -| --consensus-on-accept-gossip-peer-size | gossipOnAcceptPeerSize | \ No newline at end of file +| --consensus-on-accept-gossip-peer-size | gossipOnAcceptPeerSize | diff --git a/content/docs/nodes/configure/configs-flags.mdx b/content/docs/nodes/configure/configs-flags.mdx index a5768a07d31..1f689fc903f 100644 --- a/content/docs/nodes/configure/configs-flags.mdx +++ b/content/docs/nodes/configure/configs-flags.mdx @@ -32,7 +32,7 @@ Example JSON config file: ``` } > -[Install Script](/nodes/run/using-install-script/installing-avalanche-go) creates the +[Install Script](/nodes/using-install-script/installing-avalanche-go) creates the node config file at `~/.avalanchego/configs/node.json`. No default file is created if [AvalancheGo is built from source](/nodes/run-a-node/manually), you would need to create it manually if needed. @@ -216,7 +216,7 @@ Full reference for all configuration options for some standard chains can be found in a separate [chain config flags](/nodes/configure/configs-flags) document. Full reference for `subnet-evm` upgrade configuration can be found in a separate -[Customize a Subnet](/subnets/upgrade/customize-subnet) document. +[Customize an Avalanche L1](/avalanche-l1s/upgrade/customize-avalanche-l1) document. #### `--chain-config-content` (string) @@ -248,7 +248,7 @@ The above example aliases the Blockchain whose ID is `"q2aTwKuyzgs8pynF7UXBZCU7DejbZbZ6EUyHr3JQzYgwNPUPi"` to `"DFK"`. Chain aliases are added after adding primary network aliases and before any changes to the aliases via the admin API. This means that the first alias included for a -Blockchain on a Subnet will be treated as the `"Primary Alias"` instead of the +Blockchain on an Avalanche L1 will be treated as the `"Primary Alias"` instead of the full blockchainID. The Primary Alias is used in all metrics and logs. #### `--chain-aliases-file-content` (string) @@ -711,34 +711,34 @@ As an alternative to `--staking-tls-key-file`, it allows specifying base64 encoded content of the TLS private key used by the node. Note that full private key content, with the leading and trailing header, must be base64 encoded. -## Subnets +## Avalanche L1s -### Subnet Tracking +### Avalanche L1 Tracking #### `--track-subnets` (string) -Comma separated list of Subnet IDs that this node would track if added to. +Comma separated list of Avalanche L1 IDs (SubnetID) that this node would track if added to. Defaults to empty (will only validate the Primary Network). -### Subnet Configs +### Avalanche L1 Configs -It is possible to provide parameters for Subnets. Parameters here apply to all -chains in the specified Subnets. Parameters must be specified with a +It is possible to provide parameters for Avalanche L1s. Parameters here apply to all +chains in the specified Avalanche L1s. Parameters must be specified with a `{subnetID}.json` config file under `--subnet-config-dir`. AvalancheGo loads -configs for Subnets specified in +configs for Avalanche L1s specified in `--track-subnets` parameter. -Full reference for all configuration options for a Subnet can be found in a -separate [Subnet Configs](./subnet-configs) document. +Full reference for all configuration options for an Avalanche L1 can be found in a +separate [Avalanche L1 Configs](/nodes/configure/avalanche-l1-configs) document. #### `--subnet-config-dir` (`string`) -Specifies the directory that contains Subnet configs, as described above. +Specifies the directory that contains Avalanche L1 configs, as described above. Defaults to `$HOME/.avalanchego/configs/subnets`. If the flag is set explicitly, the specified folder must exist, or AvalancheGo will exit with an error. This flag is ignored if `--subnet-config-content` is specified. -Example: Let's say we have a Subnet with ID +Example: Let's say we have an Avalanche L1 with ID `p4jUwqZsA2LuSftroCd3zb4ytH8W99oXKuKVZdsty7eQ3rXD6`. We can create a config file under the default `subnet-config-dir` at `$HOME/.avalanchego/configs/subnets/p4jUwqZsA2LuSftroCd3zb4ytH8W99oXKuKVZdsty7eQ3rXD6.json`. @@ -760,7 +760,7 @@ By default, none of these directories and/or files exist. You would need to crea #### `--subnet-config-content` (string) -As an alternative to `--subnet-config-dir`, it allows specifying base64 encoded parameters for a Subnet. +As an alternative to `--subnet-config-dir`, it allows specifying base64 encoded parameters for an Avalanche L1. ## Version @@ -836,7 +836,7 @@ network. #### `--create-subnet-tx-fee` (int) -Transaction fee, in nAVAX, for transactions that create new Subnets. Defaults to +Transaction fee, in nAVAX, for transactions that create new Avalanche L1s. Defaults to `1000000000` nAVAX (1 AVAX) per transaction. This can only be changed on a local network. @@ -848,7 +848,7 @@ changed on a local network. #### `--transform-subnet-tx-fee` (int) -Transaction fee, in nAVAX, for transactions that transform Subnets. Defaults to +Transaction fee, in nAVAX, for transactions that transform Avalanche L1s. Defaults to `1000000000` nAVAX (1 AVAX) per transaction. This can only be changed on a local network. #### `--add-primary-network-validator-fee` (int) @@ -863,12 +863,12 @@ This can only be changed on a local network. #### `--add-subnet-validator-fee` (int) -Transaction fee, in nAVAX, for transactions that add new Subnet validators. +Transaction fee, in nAVAX, for transactions that add new Avalanche L1 validators. Defaults to `10000000` nAVAX (.01 AVAX). #### `--add-subnet-delegator-fee` (int) -Transaction fee, in nAVAX, for transactions that add new Subnet delegators. +Transaction fee, in nAVAX, for transactions that add new Avalanche L1 delegators. Defaults to `10000000` nAVAX (.01 AVAX). #### `--min-delegator-stake` (int) @@ -1403,3 +1403,4 @@ Node reports unhealthy if the router drops more than this portion of messages. D Node reports unhealthy if there are more than this many outstanding consensus requests (Get, PullQuery, etc.) over all chains. Defaults to `1024`. + diff --git a/content/docs/nodes/index.mdx b/content/docs/nodes/index.mdx index 76f269b401a..2e53c199b00 100644 --- a/content/docs/nodes/index.mdx +++ b/content/docs/nodes/index.mdx @@ -35,3 +35,4 @@ As there are too many models and router configurations, we cannot provide instru A fully connected Avalanche node maintains and communicates over a couple of thousand of live TCP connections. For some low-powered and older home routers that might be too much to handle. If that is the case you may experience lagging on other computers connected to the same router, node getting benched, failing to sync and similar issues. + diff --git a/content/docs/nodes/maintain/backup-restore.mdx b/content/docs/nodes/maintain/backup-restore.mdx index a685c6e2040..a519253b5e4 100644 --- a/content/docs/nodes/maintain/backup-restore.mdx +++ b/content/docs/nodes/maintain/backup-restore.mdx @@ -63,7 +63,7 @@ On a default Linux installation, the path to them will be `/home/USERNAME/.avala `scp` is a 'secure copy' command line program, available built-in on Linux and MacOS computers. There is also a Windows version, `pscp`, as part of the [PuTTY](https://www.chiark.greenend.org.uk/~sgtatham/putty/latest.html) package. If using `pscp`, in the following commands replace each usage of `scp` with `pscp -scp`. -To copy the files from the node, you will need to be able to remotely log into the machine. You can use account password, but the secure and recommended way is to use the SSH keys. The procedure for acquiring and setting up SSH keys is highly dependent on your cloud provider and machine configuration. You can refer to our [Amazon Web Services](/nodes/run-a-node/on-third-party-services/amazon-web-services) and [Microsoft Azure](/nodes/run-a-node/on-third-party-services/microsoft-azure) setup guides for those providers. Other providers will have similar procedures. +To copy the files from the node, you will need to be able to remotely log into the machine. You can use account password, but the secure and recommended way is to use the SSH keys. The procedure for acquiring and setting up SSH keys is highly dependent on your cloud provider and machine configuration. You can refer to our [Amazon Web Services](/nodes/on-third-party-services/amazon-web-services) and [Microsoft Azure](/nodes/on-third-party-services/microsoft-azure) setup guides for those providers. Other providers will have similar procedures. When you have means of remote login into the machine, you can copy the files over with the following command: @@ -270,4 +270,4 @@ Summary[​](#summary "Direct link to heading") Essential part of securing your node is the backup that enables full and painless restoration of your node. Following this tutorial you can rest easy knowing that should you ever find yourself in a situation where you need to restore your node from scratch, you can easily and quickly do so. -If you have any problems following this tutorial, comments you want to share with us or just want to chat, you can reach us on our [Discord](https://chat.avalabs.org/) server. \ No newline at end of file +If you have any problems following this tutorial, comments you want to share with us or just want to chat, you can reach us on our [Discord](https://chat.avalabs.org/) server. diff --git a/content/docs/nodes/maintain/bootstrapping.mdx b/content/docs/nodes/maintain/bootstrapping.mdx index 63586a9d59b..490cb5d08a3 100644 --- a/content/docs/nodes/maintain/bootstrapping.mdx +++ b/content/docs/nodes/maintain/bootstrapping.mdx @@ -6,7 +6,7 @@ Node Bootstrap is the process where a node _securely_ downloads linear chain blo Bootstrap must guarantee that the local state of a node is in sync with the state of other valid nodes. Once bootstrap is completed, a node has the latest state of the chain and can verify new incoming transactions and reach consensus with other nodes, collectively moving forward the chains. -Bootstrapping a node is a multi-step process which requires downloading the chains required by the Primary Network (that is, the C-Chain, P-Chain, and X-Chain), as well as the chains required by any additional Subnets that the node explicitly tracks. +Bootstrapping a node is a multi-step process which requires downloading the chains required by the Primary Network (that is, the C-Chain, P-Chain, and X-Chain), as well as the chains required by any additional Avalanche L1s that the node explicitly tracks. This document covers the high-level technical details of how bootstrapping works. This document glosses over some specifics, but the [AvalancheGo](https://github.com/ava-labs/avalanchego) codebase is open-source and is available for curious-minded readers to learn more. @@ -17,11 +17,11 @@ Bootstrapping is all about downloading all previously accepted containers _secur What's the most reliable source of information in the Avalanche ecosystem? It's a _large enough_ majority of validators. Therefore, the first step of bootstrapping is finding a sufficient amount of validators to download containers from. -The P-Chain is responsible for all platform-level operations, including staking events that modify a Subnet's validator set. Whenever any chain (aside from the P-Chain itself) bootstraps, it requests an up-to-date validator set for that Subnet (Primary Network is a Subnet too). Once the Subnet's current validator set is known, the node can securely download containers from these validators to bootstrap the chain. +The P-Chain is responsible for all platform-level operations, including staking events that modify an Avalanche L1's validator set. Whenever any chain (aside from the P-Chain itself) bootstraps, it requests an up-to-date validator set for that Avalanche L1 (Primary Network is an Avalanche L1 too). Once the Avalanche L1's current validator set is known, the node can securely download containers from these validators to bootstrap the chain. There is a caveat here: the validator set must be _up-to-date_. If a bootstrapping node's validator set is stale, the node may incorrectly believe that some nodes are still validators when their validation period has already expired. A node might unknowingly end up requesting blocks from non-validators which respond with malicious blocks that aren't safe to download. -**For this reason, every Avalanche node must fully bootstrap the P-chain first before moving on to the other Primary Network chains and other Subnets to guarantee that their validator sets are up-to-date**. +**For this reason, every Avalanche node must fully bootstrap the P-chain first before moving on to the other Primary Network chains and other Avalanche L1s to guarantee that their validator sets are up-to-date**. What about the P-chain? The P-chain can't ever have an up-to-date validator set before completing its bootstrap. To solve this chicken-and-egg situation the Avalanche Foundation maintains a trusted default set of validators called beacons (but users are free to configure their own). Beacon Node-IDs and IP addresses are listed in the [AvalancheGo codebase](https://github.com/ava-labs/avalanchego/blob/master/genesis/bootstrappers.json). Every node has the beacon list available from the start and can reach out to them as soon as it starts. @@ -65,17 +65,17 @@ A node first just fetches and parses containers. Once the chain is complete, the When Does Bootstrapping Finish?[​](#when-does-bootstrapping-finish "Direct link to heading") -------------------------------------------------------------------------------------------- -You've seen how [bootstrap works](#bootstrapping-the-blockchain) for a single chain. However, a node must bootstrap the chains in the Primary Network as well as the chains in each Subnet it tracks. This begs the questions - when are these chains bootstrapped? When is a node done bootstrapping? +You've seen how [bootstrap works](#bootstrapping-the-blockchain) for a single chain. However, a node must bootstrap the chains in the Primary Network as well as the chains in each Avalanche L1 it tracks. This begs the questions - when are these chains bootstrapped? When is a node done bootstrapping? The P-chain is always the first to bootstrap before any other chain. Once the P-Chain has finished, all other chains start bootstrapping in parallel, connecting to their own validators independently of one another. -A node completes bootstrapping a Subnet once all of its corresponding chains have completed bootstrapping. Because the Primary Network is a special case of Subnet that includes the entire network, this applies to it as well as any other manually tracked Subnets. +A node completes bootstrapping an Avalanche L1 once all of its corresponding chains have completed bootstrapping. Because the Primary Network is a special case of Avalanche L1 that includes the entire network, this applies to it as well as any other manually tracked Avalanche L1s. -Note that Subnets bootstrap is independently of one another - so even if one Subnet has bootstrapped and is validating new transactions and adding new containers, other Subnets may still be bootstrapping in parallel. +Note that Avalanche L1s bootstrap is independently of one another - so even if one Avalanche L1 has bootstrapped and is validating new transactions and adding new containers, other Avalanche L1s may still be bootstrapping in parallel. -Within a single Subnet however, a Subnet isn't done bootstrapping until the last chain completes bootstrapping. It's possible for a single chain to effectively stall a node from finishing the bootstrap for a single Subnet, if it has a sufficiently long history or each operation is complex and time consuming. Even worse, other Subnet validators are continuously accepting new transactions and adding new containers on top of the previously known frontier, so a node that's slow to bootstrap can continuously fall behind the rest of the network. +Within a single Avalanche L1 however, an Avalanche L1 isn't done bootstrapping until the last chain completes bootstrapping. It's possible for a single chain to effectively stall a node from finishing the bootstrap for a single Avalanche L1, if it has a sufficiently long history or each operation is complex and time consuming. Even worse, other Avalanche L1 validators are continuously accepting new transactions and adding new containers on top of the previously known frontier, so a node that's slow to bootstrap can continuously fall behind the rest of the network. -Nodes mitigate this by restarting bootstrap for any chains which is blocked waiting for the remaining Subnet chains to finish bootstrapping. These chains repeat the frontier retrieval and container downloading phases to stay up-to-date with the Subnet's ever moving current frontier until the slowest chain has completed bootstrapping. +Nodes mitigate this by restarting bootstrap for any chains which is blocked waiting for the remaining Avalanche L1 chains to finish bootstrapping. These chains repeat the frontier retrieval and container downloading phases to stay up-to-date with the Avalanche L1's ever moving current frontier until the slowest chain has completed bootstrapping. Once this is complete, a node is finally ready to validate the network. @@ -86,7 +86,7 @@ The full node bootstrap process is long, and gets longer and longer over time as Starting from [AvalancheGo version 1.7.11](https://github.com/ava-labs/avalanchego/releases/tag/v1.7.11), nodes can use state sync to drastically cut down bootstrapping time on the C-Chain. Instead of executing each block, state sync uses cryptographic techniques to download and verify just the state associated with the current frontier. State synced nodes can't serve every C-chain block ever historically accepted, but they can safely retrieve the full C-chain state needed to validate in a much shorter time. State sync will fetch the previous 256 blocks prior to support the previous block hash operation code. -State sync is currently only available for the C-chain. The P-chain and X-chain currently bootstrap by downloading all blocks. Note that irrespective of the bootstrap method used (including state sync), each chain is still blocked on all other chains in its Subnet completing their bootstrap before continuing into normal operation. +State sync is currently only available for the C-chain. The P-chain and X-chain currently bootstrap by downloading all blocks. Note that irrespective of the bootstrap method used (including state sync), each chain is still blocked on all other chains in its Avalanche L1 completing their bootstrap before continuing into normal operation. There are no configs to state sync an archival node. If you need all the historical state then you must not use state sync and setup the config of the node for an archival node. @@ -112,11 +112,11 @@ Logs provide information about both container downloading and their execution fo [02-16|17:37:52.468] INFO

queue/jobs.go:203 executing operations {"numExecuted": 52713, "numToExecute": 101357, "eta": "1m23s"} ``` -Similar logs are emitted for X and C chains and any chain in explicitly tracked Subnets. +Similar logs are emitted for X and C chains and any chain in explicitly tracked Avalanche L1s. ### Why Chain Bootstrap ETA Keeps On Changing?[​](#why-chain-bootstrap-eta-keeps-on-changing "Direct link to heading") -As you saw in the [bootstrap completion section](#when-does-bootstrapping-finish), a Subnet like the Primary Network completes once all of its chains finish bootstrapping. Some Subnet chains may have to wait for the slowest to finish. They'll restart bootstrapping in the meantime, to make sure they won't fall back too much with respect to the network accepted frontier. +As you saw in the [bootstrap completion section](#when-does-bootstrapping-finish), an Avalanche L1 like the Primary Network completes once all of its chains finish bootstrapping. Some Avalanche L1 chains may have to wait for the slowest to finish. They'll restart bootstrapping in the meantime, to make sure they won't fall back too much with respect to the network accepted frontier. What Order Do The Chains Bootstrap?[​](#what-order-do-the-chains-bootstrap "Direct link to heading") ---------------------------------------------------------------------------------------------------- @@ -125,4 +125,4 @@ The 3 chains will bootstrap in the following order: P-chain, X-chain, C-chain. ### Why Are AvalancheGo APIs Disabled During Bootstrapping?[​](#why-are-avalanchego-apis-disabled-during-bootstrapping "Direct link to heading") -AvalancheGo APIs are [explicitly disabled](https://github.com/ava-labs/avalanchego/blob/master/api/server/server.go#L367:L379) during bootstrapping. The reason is that if the node has not fully rebuilt its Subnets state, it can't provide accurate information. AvalancheGo APIs are activated once bootstrap completes and node transition into its normal operating mode, accepting and validating transactions. \ No newline at end of file +AvalancheGo APIs are [explicitly disabled](https://github.com/ava-labs/avalanchego/blob/master/api/server/server.go#L367:L379) during bootstrapping. The reason is that if the node has not fully rebuilt its Avalanche L1s state, it can't provide accurate information. AvalancheGo APIs are activated once bootstrap completes and node transition into its normal operating mode, accepting and validating transactions. diff --git a/content/docs/nodes/maintain/enroll-in-avalanche-notify.mdx b/content/docs/nodes/maintain/enroll-in-avalanche-notify.mdx index 9c7ea032b2f..ca13052d2ae 100644 --- a/content/docs/nodes/maintain/enroll-in-avalanche-notify.mdx +++ b/content/docs/nodes/maintain/enroll-in-avalanche-notify.mdx @@ -14,4 +14,4 @@ When signing up for email alerts, consider using a new, alias, or auto-forwardin This tool is currently in BETA and validator alerts may erroneously be triggered, not triggered, or delayed. The best way to maximize the likelihood of earning staking rewards is to run redundant monitoring/alerting. - \ No newline at end of file + diff --git a/content/docs/nodes/maintain/monitoring.mdx b/content/docs/nodes/maintain/monitoring.mdx index 0f3e5c60fb0..e9ac5935845 100644 --- a/content/docs/nodes/maintain/monitoring.mdx +++ b/content/docs/nodes/maintain/monitoring.mdx @@ -112,7 +112,7 @@ Nov 12 11:38:33 ip-172-31-36-200 prometheus[548]: ts=2021-11-12T11:38:33.773Z ca Note the `active (running)` status (press `q` to exit). You can also check Prometheus web interface, available on `http://your-node-host-ip:9090/` -You may need to do `sudo ufw allow 9090/tcp` if the firewall is on, and/or adjust the security settings to allow connections to port 9090 if the node is running on a cloud instance. For AWS, you can look it up [here](/nodes/run-a-node/on-third-party-services/amazon-web-services#create-a-security-group). If on public internet, make sure to only allow your IP to connect! +You may need to do `sudo ufw allow 9090/tcp` if the firewall is on, and/or adjust the security settings to allow connections to port 9090 if the node is running on a cloud instance. For AWS, you can look it up [here](/nodes/on-third-party-services/amazon-web-services#create-a-security-group). If on public internet, make sure to only allow your IP to connect! If everything is OK, let's move on. @@ -259,17 +259,17 @@ Step 5: Additional Dashboards (Optional)[​](#step-5-additional-dashboards-opti Step 4 installs the basic set of dashboards that make sense to have on any node. Step 5 is for installing additional dashboards that may not be useful for every installation. -Currently, there is only one additional dashboard: Subnets. If your node is running any Subnets, you may want to add this as well. Do: +Currently, there is only one additional dashboard: Avalanche L1s. If your node is running any Avalanche L1s, you may want to add this as well. Do: ```bash ./monitoring-installer.sh --5 ``` -This will add the Subnets dashboard. It allows you to monitor operational data for any Subnet that is synced on the node. There is a Subnet switcher that allows you to switch between different Subnets. As there are many Subnets and not every node will have all of them, by default, it comes populated only with Spaces and WAGMI Subnets that exist on Fuji testnet: +This will add the Avalanche L1s dashboard. It allows you to monitor operational data for any Avalanche L1 that is synced on the node. There is an Avalanche L1 switcher that allows you to switch between different Avalanche L1s. As there are many Avalanche L1s and not every node will have all of them, by default, it comes populated only with Spaces and WAGMI Avalanche L1s that exist on Fuji testnet: -![Subnets switcher](/images/monitoring3.png) +![Avalanche L1s switcher](/images/monitoring3.png) -To configure the dashboard and add any Subnets that your node is syncing, you will need to edit the dashboard. Select the `dashboard settings` icon (image of a cog) in the upper right corner of the dashboard display and switch to `Variables` section and select the `subnet` variable. It should look something like this: +To configure the dashboard and add any Layer 1s that your node is syncing, you will need to edit the dashboard. Select the `dashboard settings` icon (image of a cog) in the upper right corner of the dashboard display and switch to `Variables` section and select the `subnet` variable. It should look something like this: ![Variables screen](/images/monitoring4.png) @@ -285,7 +285,7 @@ and the separator between entries is a comma. Entries for Spaces and WAGMI look Spaces (Fuji) : 2ebCneCbwthjQ1rYT41nhd7M76Hc6YmosMAQrTFhBq8qeqh6tt, WAGMI (Fuji) : 2AM3vsuLoJdGBGqX2ibE8RGEq4Lg7g4bot6BT1Z7B9dH5corUD ``` -After editing the values, press `Update` and then click `Save dashboard` button and confirm. Press the back arrow in the upper left corner to return to the dashboard. New values should now be selectable from the dropdown and data for the selected Subnet will be shown in the panels. +After editing the values, press `Update` and then click `Save dashboard` button and confirm. Press the back arrow in the upper left corner to return to the dashboard. New values should now be selectable from the dropdown and data for the selected Avalanche L1 will be shown in the panels. Updating[​](#updating "Direct link to heading") ----------------------------------------------- @@ -299,4 +299,4 @@ Summary[​](#summary "Direct link to heading") Using the script to install node monitoring is easy, and it gives you insight into how your node is behaving and what's going on under the hood. Also, pretty graphs! -If you have feedback on this tutorial, problems with the script or following the steps, send us a message on [Discord](https://chat.avalabs.org/). \ No newline at end of file +If you have feedback on this tutorial, problems with the script or following the steps, send us a message on [Discord](https://chat.avalabs.org/). diff --git a/content/docs/nodes/maintain/upgrade.mdx b/content/docs/nodes/maintain/upgrade.mdx index cc9ba81f5ef..a130f4659c7 100644 --- a/content/docs/nodes/maintain/upgrade.mdx +++ b/content/docs/nodes/maintain/upgrade.mdx @@ -150,7 +150,7 @@ git clone https://github.com/ava-labs/avalanchego.git The repository cloning method used is HTTPS, but SSH can be used too: -`git clone [[email protected]](https://docs.avax.network/cdn-cgi/l/email-protection):ava-labs/avalanchego.git` +`git clone git@github.com:ava-labs/avalanchego.git` You can find more about SSH and how to use it [here](https://docs.github.com/en/authentication/connecting-to-github-with-ssh/about-ssh). diff --git a/content/docs/nodes/meta.json b/content/docs/nodes/meta.json index 7433fb922ba..2a89a51b0c6 100644 --- a/content/docs/nodes/meta.json +++ b/content/docs/nodes/meta.json @@ -6,13 +6,13 @@ "---Run A Node---", "run-a-node/manually", "using-install-script", - "run-a-node/subnet-nodes", + "run-a-node/avalanche-l1-nodes", "on-third-party-services", "run-a-node/common-errors", "---Configure---", "configure/configs-flags", "chain-configs", - "configure/subnet-configs", + "configure/avalanche-l1-configs", "---Validate---", "validate/what-is-staking", "validate/validate-vs-delegate", diff --git a/content/docs/nodes/on-third-party-services/aws-marketplace.mdx b/content/docs/nodes/on-third-party-services/aws-marketplace.mdx index 31df3481131..e8d528ee62a 100644 --- a/content/docs/nodes/on-third-party-services/aws-marketplace.mdx +++ b/content/docs/nodes/on-third-party-services/aws-marketplace.mdx @@ -223,7 +223,7 @@ For adding the new node as a Validator on the Fuji testnet's Primary Network you ![Core web](/images/aws3.png) -Core web is a free, all-in-one command center that gives users a more intuitive and comprehensive way to view assets, and use dApps across the Avalanche network, its various Subnets, and Ethereum. Core web is optimized for use with the Core browser extension and Core mobile (available on both iOS & Android). Together, they are key components of the Core product suite that brings dApps, NFTs, Avalanche Bridge, Subnets, L2s, and more, directly to users. +Core web is a free, all-in-one command center that gives users a more intuitive and comprehensive way to view assets, and use dApps across the Avalanche network, its various Avalanche L1s, and Ethereum. Core web is optimized for use with the Core browser extension and Core mobile (available on both iOS & Android). Together, they are key components of the Core product suite that brings dApps, NFTs, Avalanche Bridge, Avalanche L1s, L2s, and more, directly to users. ### Switching to Testnet Mode[​](#switching-to-testnet-mode "Direct link to heading") @@ -460,9 +460,9 @@ AWS one click is meant to be used in automated environments, not as an end-user - Database is at `/data/avalanchego` - Logs are at `/var/log/avalanchego` -For a simple upgrade you would need to place the new binary at `/usr/local/bin/`. If you run a Subnet, you would also need to place the VM binary into `/home/avalanche/.avalanchego/plugins`. +For a simple upgrade you would need to place the new binary at `/usr/local/bin/`. If you run an Avalanche L1, you would also need to place the VM binary into `/home/avalanche/.avalanchego/plugins`. -You can also look at using [this guide](https://docs.aws.amazon.com/systems-manager/latest/userguide/automation-tutorial-update-ami.html), but that won't address updating the Subnet, if you have one. +You can also look at using [this guide](https://docs.aws.amazon.com/systems-manager/latest/userguide/automation-tutorial-update-ami.html), but that won't address updating the Avalanche L1, if you have one. Summary[​](#summary "Direct link to heading") --------------------------------------------- diff --git a/content/docs/nodes/on-third-party-services/google-cloud.mdx b/content/docs/nodes/on-third-party-services/google-cloud.mdx index c998b49661c..4d43dc3a984 100644 --- a/content/docs/nodes/on-third-party-services/google-cloud.mdx +++ b/content/docs/nodes/on-third-party-services/google-cloud.mdx @@ -48,7 +48,7 @@ We will deploy a single `Compute Network` object. This unit is where we will dep Avalanche requires that a validator communicate outbound on the same public IP address that it advertises for other peers to connect to it on. Within GCP this precludes the possibility of us using a Cloud NAT Router for the outbound communications and requires us to bind the public IP that we provision to the interface of the machine. We will provision a single `EXTERNAL` static IPv4 `Compute Address`. -#### Subnets[​](#subnets "Direct link to heading") +#### Avalanche L1s[​](#avalanche-l1s "Direct link to heading") For the purposes of this documentation we will deploy a single `Compute Subnetwork` in the US-EAST1 `Region` with a /24 address range giving us 254 IP addresses (not all usable but for the sake of generalized documentation). @@ -111,7 +111,7 @@ Depending upon how you intend to execute your terraform operations you may or ma ### Clone GitHub Repository[​](#clone-github-repository "Direct link to heading") -I have provided a rudimentary terraform construct to provision a node on which to run Avalanche which can be found [here](https://github.com/ava-labs/avalanche-docs/tree/master/static/scripts/terraform-gcp/projects/my-avax-project). Documentation below assumes you are using this repository but if you have another terraform skeleton similar steps will apply. +I have provided a rudimentary terraform construct to provision a node on which to run Avalanche which can be found [here](https://github.com/meaghanfitzgerald/deprecated-avalanche-docs/tree/master/static/scripts). Documentation below assumes you are using this repository but if you have another terraform skeleton similar steps will apply. ### Terraform Configuration[​](#terraform-configuration "Direct link to heading") diff --git a/content/docs/nodes/on-third-party-services/microsoft-azure.mdx b/content/docs/nodes/on-third-party-services/microsoft-azure.mdx index 55a7f80a052..cbdad85643f 100644 --- a/content/docs/nodes/on-third-party-services/microsoft-azure.mdx +++ b/content/docs/nodes/on-third-party-services/microsoft-azure.mdx @@ -9,9 +9,9 @@ This document was written by a community member, some information may be out of Running a validator and staking with Avalanche provides extremely competitive rewards of between 9.69% and 11.54% depending on the length you stake for. The maximum rate is earned by staking for a year, whilst the lowest rate for 14 days. There is also no slashing, so you don't need to worry about a hardware failure or bug in the client which causes you to lose part or all of your stake. Instead with Avalanche you only need to currently maintain at least 80% uptime to receive rewards. If you fail to meet this requirement you don't get slashed, but you don't receive the rewards. **You also do not need to put your private keys onto a node to begin validating on that node.** Even if someone breaks into your cloud environment and gains access to the node, the worst they can do is turn off the node. -Not only does running a validator node enable you to receive rewards in AVAX, but later you will also be able to validate other Subnets in the ecosystem as well and receive rewards in the token native to their Subnets. +Not only does running a validator node enable you to receive rewards in AVAX, but later you will also be able to validate other Avalanche L1s in the ecosystem as well and receive rewards in the token native to their Avalanche L1s. -Hardware requirements to run a validator are relatively modest: 8 CPU cores, 16 GB of RAM and 1 TB SSD. It also doesn't use enormous amounts of energy. Avalanche's [revolutionary consensus mechanism](https://medium.com/ava-hub/avalanche-consensus-the-biggest-breakthrough-since-nakamoto-66e9917fd656) is able to scale to millions of validators participating in consensus at once, offering unparalleled decentralisation. +Hardware requirements to run a validator are relatively modest: 8 CPU cores, 16 GB of RAM and 1 TB SSD. It also doesn't use enormous amounts of energy. Avalanche's [revolutionary consensus mechanism](/learn/avalanche-consensus) is able to scale to millions of validators participating in consensus at once, offering unparalleled decentralisation. Currently the minimum amount required to stake to become a validator is 2,000 AVAX. Alternatively, validators can also charge a small fee to enable users to delegate their stake with them to help towards running costs. You can use a calculator [here](https://vscout.io/) to see how much rewards you would earn when running a node, compared to delegating. @@ -28,69 +28,68 @@ First you will need a Microsoft Account, if you don't have one already you will [https://account.microsoft.com/security](https://account.microsoft.com/security) -![Image for post](https://miro.medium.com/max/1135/1*tr3rEcrvI4rEpC7KPYqg6g.png) +![Image for post](/images/azure1.png) Once two factor has been configured log into the Azure portal by going to [https://portal.azure.com](https://portal.azure.com/) and signing in with your Microsoft account. When you login you won't have a subscription, so we need to create one first. Select "Subscriptions" as highlighted below: -![Image for post](https://miro.medium.com/max/648/1*5Jp8oXzczaEND-z9_QZaQA.png) +![Image for post](/images/azure2.png) Then select "+ Add" to add a new subscription -![Image for post](https://miro.medium.com/max/374/1*Lw3HklSSC8NDN2ftQEVgYA.png) +![Image for post](/images/azure3.png) If you want to use Spot Instance VM Pricing (which will be considerably cheaper) you can't use a Free Trial account (and you will receive an error upon validation), so **make sure to select Pay-As-You-Go.** -![Image for post](https://miro.medium.com/max/789/1*TO5Uh07OkH_QdwludEgapg.png) +![Image for post](/images/azure4.png) Enter your billing details and confirm identity as part of the sign-up process, when you get to Add technical support select the without support option (unless you want to pay extra for support) and press Next. -![Image for post](https://miro.medium.com/max/783/1*5KJOATvu3giAr6ygO3rF6Q.png) +![Image for post](/images/azure5.png) Create a Virtual Machine[​](#create-a-virtual-machine "Direct link to heading") ------------------------------------------------------------------------------- Now that we have a subscription, we can create the Ubuntu Virtual Machine for our Avalanche Node. Select the Icon in the top left for the Menu and choose "+ Create a resource" -![Image for post](https://miro.medium.com/max/565/1*3nSPwgEM3oIgrIlIo-TS1w.png) +![Image for post](/images/azure6.png) Select Ubuntu Server 18.04 LTS (this will normally be under the popular section or alternatively search for it in the marketplace) -![Image for post](https://miro.medium.com/max/605/1*Y0iZEZExC36c7FXqPlrPuw.png) +![Image for post](/images/azure7.png) This will take you to the Create a virtual machine page as shown below: -![Image for post](https://miro.medium.com/max/775/1*cv0z0mt6Uavx5MkiazpiUA.png) +![Image for post](/images/azure8.png) First, enter a virtual machine a name, this can be anything but in my example, I have called it Avalanche (This will also automatically change the resource group name to match) Then select a region from the drop-down list. Select one of the recommended ones in a region that you prefer as these tend to be the larger ones with most features enabled and cheaper prices. In this example I have selected North Europe. -![Image for post](https://miro.medium.com/max/769/1*XOpa22qSdNI-0PW5oIyUhQ.png) +![Image for post](/images/azure9.png) You have the option of using spot pricing to save significant amounts on running costs. Spot instances use a supply and demand market price structure. As demand for instances goes up, the price for the spot instance goes up. If there is insufficient capacity, then your VM will be turned off. The chances of this happening are incredibly low though, especially if you select the Capacity only option. Even in the unlikely event it does get turned off temporarily you only need to maintain at least 80% up time to receive the staking rewards and there is no slashing implemented in Avalanche. Select Yes for Azure Spot instance, select Eviction type to Capacity Only and **make sure to set the eviction policy to Stop / Deallocate. This is very important otherwise the VM will be deleted** -![Image for post](https://miro.medium.com/max/756/1*zWWiYhloPdnKEXGhZJA3dQ.png) +![Image for post](/images/azure10.png) Choose "Select size" to change the Virtual Machine size, and from the menu select D2s\_v4 under the D-Series v4 selection (This size has 2 Cores, 8 GB Memory and enables Premium SSDs). You can use F2s\_v2 instances instead, with are 2 Cores, 4 GB Memory and enables Premium SSDs) but the spot price actually works out cheaper for the larger VM currently with spot instance prices. You can use [this link](https://azure.microsoft.com/en-us/pricing/details/virtual-machines/linux/) to view the prices across the different regions. -![Image for post](https://miro.medium.com/max/957/1*JzebwGho6qDFbzlqCJSN9w.png) +![Image for post](/images/azure11.png) Once you have selected the size of the Virtual Machine, select "View pricing history and compare prices in nearby regions" to see how the spot price has changed over the last 3 months, and whether it's cheaper to use a nearby region which may have more spare capacity. -![Image for post](https://miro.medium.com/max/763/1*UQYmhtL8JMhrOkaWk8cloA.png) +![Image for post](/images/azure12.png) At the time of this article, spot pricing for D2s\_v4 in North Europe costs 0.07975perhour,oraround0.07975 per hour, or around 698.61 a year. With spot pricing, the price falls to 0.01295perhour,whichworksoutatabout0.01295 per hour, which works out at about 113.44 a year, **a saving of 83.76%!** There are some regions which are even cheaper, East US for example is 0.01060perhouroraround0.01060 per hour or around 92.86 a year! -![Image for post](https://miro.medium.com/max/677/1*Th5aDwLS6_IoM0LidRbH6g.png) +![Image for post](/images/azure13.png) -Below you can see the price history of the VM over the last 3 months for North Europe and regions nearby.![Image for -post](https://miro.medium.com/max/30/1*OJ4monpMy8DhWw_HWycMjg.png?q=20) +Below you can see the price history of the VM over the last 3 months for North Europe and regions nearby. -![Image for post](https://miro.medium.com/max/968/1*OJ4monpMy8DhWw_HWycMjg.png) +![Image for post](/images/azure14.png) ### Cheaper Than Amazon AWS[​](#cheaper-than-amazon-aws "Direct link to heading") @@ -98,7 +97,7 @@ As a comparison a c5.large instance costs 0.085USDperhouronAWS.Thistotals 0.085 The next step is to change the username for the VM, to align with other Avalanche tutorials change the username to Ubuntu. Otherwise you will need to change several commands later in this article and swap out Ubuntu with your new username. -![Image for post](https://miro.medium.com/max/780/1*CNmFTz056EUmahfi5zG3JQ.png) +![Image for post](/images/azure15.png) ### Disks[​](#disks "Direct link to heading") @@ -106,125 +105,125 @@ Select Next: Disks to then configure the disks for the instance. There are 2 cho Select Next: Networking to move onto the network configuration -![Image for post](https://miro.medium.com/max/763/1*Oqv9nA8KoSIyq95DuPDN4g.png) +![Image for post](/images/azure16.png) ### Network Config[​](#network-config "Direct link to heading") You want to use a Static IP so that the public IP assigned to the node doesn't change in the event it stops. Under Public IP select "Create new" -![Image for post](https://miro.medium.com/max/774/1*2wsz1_OG7DpLA7jmTJfm0A.png) +![Image for post](/images/azure17.png) Then select "Static" as the Assignment type -![Image for post](https://miro.medium.com/max/347/1*y-JbYlRNN3GNNXtZDP-UXQ.png) +![Image for post](/images/azure19.png) Then we need to configure the network security group to control access inbound to the Avalanche node. Select "Advanced" as the NIC network security group type and select "Create new" -![Image for post](https://miro.medium.com/max/763/1*e5Y-mHGkn42A-mJx6o3J0g.png) +![Image for post](/images/azure20.png) For security purposes you want to restrict who is able to remotely connect to your node. To do this you will first want to find out what your existing public IP is. This can be done by going to google and searching for "what's my IP" -![Image for post](https://miro.medium.com/max/450/1*-aV-AdrABCUmludxXUPV6Q.png) +![Image for post](/images/azure21.png) It's likely that you have been assigned a dynamic public IP for your home, unless you have specifically requested it, and so your assigned public IP may change in the future. It's still recommended to restrict access to your current IP though, and then in the event your home IP changes and you are no longer able to remotely connect to the VM, you can just update the network security rules with your new public IP so you are able to connect again. NOTE: If you need to change the network security group rules after deployment if your home IP has changed, search for "avalanche-nsg" and you can modify the rule for SSH and Port 9650 with the new IP. **Port 9651 needs to remain open to everyone** though as that's how it communicates with other Avalanche nodes. -![Image for post](https://miro.medium.com/max/481/1*fR6SrKhTSTQ4cS3PoFrQfQ.png) +![Image for post](/images/azure22.png) Now that you have your public IP select the default allow ssh rule on the left under inbound rules to modify it. Change Source from "Any" to "IP Addresses" and then enter in your Public IP address that you found from google in the Source IP address field. Change the Priority towards the bottom to 100 and then press Save. -![Image for post](https://miro.medium.com/max/1039/1*iLP9gUH4weTfsPcmeUbXLw.png) +![Image for post](/images/azure23.png) Then select "+ Add an inbound rule" to add another rule for RPC access, this should also be restricted to only your IP. Change Source to "IP Addresses" and enter in your public IP returned from google into the Source IP field. This time change the "Destination port ranges" field to 9650 and select "TCP" as the protocol. Change the priority to 110 and give it a name of "Avalanche\_RPC" and press Add. -![Image for post](https://miro.medium.com/max/914/1*Zg9mHCkU7G5BoinN0EWZAg.png) +![Image for post](/images/azure24.png) Select "+ Add an inbound rule" to add a final rule for the Avalanche Protocol so that other nodes can communicate with your node. This rule needs to be open to everyone so keep "Source" set to "Any." Change the Destination port range to "9651" and change the protocol to "TCP." Enter a priority of 120 and a name of Avalanche\_Protocol and press Add. -![Image for post](https://miro.medium.com/max/662/1*tIMEp7O83NIUitWwlcHAxw.png) +![Image for post](/images/azure25.png) The network security group should look like the below (albeit your public IP address will be different) and press OK. -![Image for post](https://miro.medium.com/max/363/1*7rAR3C_UrX94iXxL4sdV9g.png) +![Image for post](/images/azure26.png) Leave the other settings as default and then press "Review + create" to create the Virtual machine. -![Image for post](https://miro.medium.com/max/828/1*01yGser7qYjiXDngemqClQ.png) +![Image for post](/images/azure27.png) First it will perform a validation test. If you receive an error here, make sure you selected Pay-As-You-Go subscription model and you are not using the Free Trial subscription as Spot instances are not available. Verify everything looks correct and press "Create" -![Image for post](https://miro.medium.com/max/751/1*HyQP7HJCiVQPPiWodRj6aQ.png) +![Image for post](/images/azure28.png) You should then receive a prompt asking you to generate a new key pair to connect your virtual machine. Select "Download private key and create resource" to download the private key to your PC. -![Image for post](https://miro.medium.com/max/456/1*FCAVco29fcianH4TjxVGzQ.png) +![Image for post](/images/azure29.png) Once your deployment has finished, select "Go to resource" -![Image for post](https://miro.medium.com/max/608/1*dXl1RkH6xZvHkdI1d-XsOQ.png) +![Image for post](/images/azure30.png) Change the Provisioned Disk Size[​](#change-the-provisioned-disk-size "Direct link to heading") ----------------------------------------------------------------------------------------------- By default, the Ubuntu VM will be provisioned with a 30 GB Premium SSD. You should increase this to 250 GB, to allow for database growth. -![Image for post](https://miro.medium.com/max/880/1*2uJoRLC586qLEhr1RNNeTg.png) +![Image for post](/images/azure31.png) To change the Disk size, the VM needs to be stopped and deallocated. Select "Stop" and wait for the status to show deallocated. Then select "Disks" on the left. -![Image for post](https://miro.medium.com/max/976/1*eUCBMgyQtEukvCyi3pm48g.png) +![Image for post](/images/azure32.png) Select the Disk name that's current provisioned to modify it -![Image for post](https://miro.medium.com/max/696/1*faady6O9ZyS2AvKotRFFWA.png) +![Image for post](/images/azure33.png) Select "Size + performance" on the left under settings and change the size to 250 GB and press "Resize" -![Image for post](https://miro.medium.com/max/850/1*zZhh27myfdBcEhf3QMhs3A.png) +![Image for post](/images/azure34.png) Doing this now will also extend the partition automatically within Ubuntu. To go back to the virtual machine overview page, select Avalanche in the navigation setting. -![Image for post](https://miro.medium.com/max/946/1*RGlKMhmlZ1__6u3RjFSDMA.png) +![Image for post](/images/azure35.png) Then start the VM -![Image for post](https://miro.medium.com/max/929/1*vgVR-3sRejyBcXrMn65v5g.png) +![Image for post](/images/azure36.png) Connect to the Avalanche Node[​](#connect-to-the-avalanche-node "Direct link to heading") ----------------------------------------------------------------------------------------- -The following instructions show how to connect to the Virtual Machine from a Windows 10 machine. For instructions on how to connect from a Ubuntu machine see the [AWS tutorial](/nodes/run-a-node/on-third-party-services/amazon-web-services). +The following instructions show how to connect to the Virtual Machine from a Windows 10 machine. For instructions on how to connect from a Ubuntu machine see the [AWS tutorial](/nodes/on-third-party-services/amazon-web-services). On your local PC, create a folder on the root of the C: drive called Avalanche and then move the Avalanche\_key.pem file you downloaded before into the folder. Then right click the file and select Properties. Go to the security tab and select "Advanced" at the bottom -![Image for post](https://miro.medium.com/max/719/1*KlzhuVcn5Vt0imxDPblBtA.png) +![Image for post](/images/azure37.png) Select "Disable inheritance" and then "Remove all inherited permissions from this object" to remove all existing permissions on that file. -![Image for post](https://miro.medium.com/max/740/1*VxuomVeWbhYquRynA8hP4Q.png) +![Image for post](/images/azure38.png) Then select "Add" to add a new permission and choose "Select a principal" at the top. From the pop-up box enter in your user account that you use to log into your machine. In this example I log on with a local user called Seq, you may have a Microsoft account that you use to log in, so use whatever account you login to your PC with and press "Check Names" and it should underline it to verify and press OK. -![Image for post](https://miro.medium.com/max/758/1*sMxk7zaRHVTqA0UyHTKwzQ.png) +![Image for post](/images/azure39.png) Then from the permissions section make sure only "Read & Execute" and "Read" are selected and press OK. -![Image for post](https://miro.medium.com/max/903/1*5Fkh3FJQuNeWQyEd0irjtA.png) +![Image for post](/images/azure40.png) It should look something like the below, except with a different PC name / user account. This just means the key file can't be modified or accessed by any other accounts on this machine for security purposes so they can't access your Avalanche Node. -![Image for post](https://miro.medium.com/max/736/1*F-YK0xdB92cIweCQFGGRvA.png) +![Image for post](/images/azure41.png) ### Find your Avalanche Node Public IP[​](#find-your-avalanche-node-public-ip "Direct link to heading") From the Azure Portal make a note of your static public IP address that has been assigned to your node. -![Image for post](https://miro.medium.com/max/1082/1*5cf1dAAO0G7Dzu2s0Xxh-Q.png) +![Image for post](/images/azure42.png) To log onto the Avalanche node, open command prompt by searching for `cmd` and selecting "Command Prompt" on your Windows 10 machine. -![Image for post](https://miro.medium.com/max/384/1*NlYlg9of5O9fQtiroqMFZw.png) +![Image for post](/images/azure43.png) Then use the following command and replace the EnterYourAzureIPHere with the static IP address shown on the Azure portal. @@ -232,17 +231,17 @@ ssh -i C:\\Avalanche\\Avalanche\_key.pem ubuntu@EnterYourAzureIPHere for my example its: -ssh -i C:\\Avalanche\\Avalanche\_key.pem [\[email protected\]](https://docs.avax.network/cdn-cgi/l/email-protection) +ssh -i C:\\Avalanche\\Avalanche\_key.pem The first time you connect you will receive a prompt asking to continue, enter yes. -![Image for post](https://miro.medium.com/max/651/1*Hp1AF-03TbO-eRUvuKvZcA.png) +![Image for post](/images/azure44.png) You should now be connected to your Node. -![Image for post](https://miro.medium.com/max/967/1*Kc3rna-3SQV3tnMMLkMi6A.png) +![Image for post](/images/azure45.png) -The following section is taken from Colin's excellent tutorial for [configuring an Avalanche Node on Amazon's AWS](/nodes/run-a-node/on-third-party-services/amazon-web-services). +The following section is taken from Colin's excellent tutorial for [configuring an Avalanche Node on Amazon's AWS](/nodes/on-third-party-services/amazon-web-services). ### Update Linux with Security Patches[​](#update-linux-with-security-patches "Direct link to heading") @@ -254,7 +253,7 @@ sudo apt upgrade -y sudo reboot ``` -![Image for post](https://miro.medium.com/max/793/1*_2UmPN6vabjGe6aihX9KqA.png) +![Image for post](/images/azure46.png) This will make our instance up to date with the latest security patches for our operating system. This will also reboot the node. We'll give the node a minute or two to boot back up, then log in again, same as before. @@ -325,4 +324,4 @@ scp -i C:\Avalanche\avalanche_key.pem -r ubuntu@EnterYourAzureIPHere:/home/ubunt As before, we'll need to replace "EnterYourAzureIPHere" with the appropriate value that we retrieved. This backs up our staking key and staking certificate into the C:\\Avalanche folder we created before. -![Image for post](https://miro.medium.com/max/358/1*nqsjJAv2fkcLKPri5idN-Q.png) \ No newline at end of file +![Image for post](/images/azure47.png) \ No newline at end of file diff --git a/content/docs/subnets/subnet-nodes.mdx b/content/docs/nodes/run-a-node/avalanche-l1-nodes.mdx similarity index 74% rename from content/docs/subnets/subnet-nodes.mdx rename to content/docs/nodes/run-a-node/avalanche-l1-nodes.mdx index dbaa548f204..7d3085a764a 100644 --- a/content/docs/subnets/subnet-nodes.mdx +++ b/content/docs/nodes/run-a-node/avalanche-l1-nodes.mdx @@ -1,11 +1,11 @@ --- -title: Subnet Nodes -description: Learn how to run an Avalanche node that tracks a Subnet. +title: Avalanche L1 Nodes +description: Learn how to run an Avalanche node that tracks an Avalanche L1. --- -This article describes how to run a node that tracks a Subnet. It requires building AvalancheGo, adding Virtual Machine binaries as plugins to your local data directory, and running AvalancheGo to track these binaries. +This article describes how to run a node that tracks an Avalanche L1. It requires building AvalancheGo, adding Virtual Machine binaries as plugins to your local data directory, and running AvalancheGo to track these binaries. -This tutorial specifically covers tracking a Subnet built with Avalanche's [Subnet-EVM](https://github.com/ava-labs/subnet-evm), the default [Virtual Machine](/learn/virtual-machines) run by Subnets on Avalanche. +This tutorial specifically covers tracking an Avalanche L1 built with Avalanche's [Subnet-EVM](https://github.com/ava-labs/subnet-evm), the default [Virtual Machine](/learn/virtual-machines) run by Avalanche L1s on Avalanche. Build AvalancheGo[​](#build-avalanchego "Direct link to heading") ----------------------------------------------------------------- @@ -51,7 +51,7 @@ Note that as network usage increases, hardware requirements may change. -## Manage the Subnet Binaries +## Manage the Avalanche L1 Binaries After building AvalancheGo successfully, @@ -64,7 +64,7 @@ git clone https://github.com/ava-labs/subnet-evm.git ### 2. Build the Binary and Save as a Plugin -In the Subnet-EVM directory, run the build script, and save it in the “plugins” folder of your `.avalanchego` data directory. Name the plugin after the `VMID` of the Subnet you wish to track. The `VMID` of the WAGMI Subnet is the value beginning with “srEX...”. +In the Subnet-EVM directory, run the build script, and save it in the “plugins” folder of your `.avalanchego` data directory. Name the plugin after the `VMID` of the Avalanche L1 you wish to track. The `VMID` of the WAGMI Avalanche L1 is the value beginning with “srEX...”. ```bash cd $GOPATH/src/github.com/ava-labs/subnet-evm @@ -72,8 +72,8 @@ cd $GOPATH/src/github.com/ava-labs/subnet-evm ``` - -VMID, Subnet ID, ChainID, and all other parameters can be found in the "Chain Info" section of the Subnet Explorer. + +VMID, Avalanche L1 ID (SubnetID), ChainID, and all other parameters can be found in the "Chain Info" section of the Avalanche L1 Explorer. - [Avalanche Mainnet](https://subnets.avax.network/c-chain) - [Fuji Testnet](https://subnets-test.avax.network/wagmi) @@ -82,7 +82,7 @@ VMID, Subnet ID, ChainID, and all other parameters can be found in the "Chain In ### 3. Specify the Plugin with a Config.JSON -Create a file named `config.json` and add a `track-subnets` field that is populated with the `SubnetID` you wish to track. The `SubnetID` of the WAGMI Subnet is the value beginning with “28nr...”. +Create a file named `config.json` and add a `track-subnets` field that is populated with the `SubnetID` you wish to track. The `SubnetID` of the WAGMI Avalanche L1 is the value beginning with “28nr...”. ```bash cd ~/.avalanchego @@ -91,18 +91,18 @@ echo '{"track-subnets": "28nrH5T2BMvNrWecFcV3mfccjs6axM1TVyqe79MCv2Mhs8kxiY"}' > ## Run the Node -Run AvalancheGo with the `—config-file` flag to start your node and ensure it tracks the Subnets included in the configuration file. +Run AvalancheGo with the `—config-file` flag to start your node and ensure it tracks the Avalanche L1s included in the configuration file. ```bash cd $GOPATH/src/github.com/ava-labs/avalanchego ./build/avalanchego --config-file ~/.avalanchego/config.json --network-id=fuji ``` -Note: The above command includes the `--network-id=fuji` command because the WAGMI Subnet is deployed on Fuji Testnet. +Note: The above command includes the `--network-id=fuji` command because the WAGMI Avalanche L1 is deployed on Fuji Testnet. -If you would prefer to track Subnets using a command line flag, you can instead use the `--track-subnets` flag. +If you would prefer to track Avalanche L1s using a command line flag, you can instead use the `--track-subnets` flag. For example: @@ -116,7 +116,7 @@ You should now see terminal filled with logs and information to suggest the node ## Bootstrapping and RPC Details -It may take a few hours for the node to fully [bootstrap](/nodes/run-a-node/manually#bootstrapping) to the Avalanche Primary Network and tracked Subnets. +It may take a few hours for the node to fully [bootstrap](/nodes/run-a-node/manually#bootstrapping) to the Avalanche Primary Network and tracked Avalanche L1s. When finished bootstrapping, the endpoint will be: diff --git a/content/docs/nodes/run-a-node/manually.mdx b/content/docs/nodes/run-a-node/manually.mdx index 80be2350fbb..c6bb28cb30d 100644 --- a/content/docs/nodes/run-a-node/manually.mdx +++ b/content/docs/nodes/run-a-node/manually.mdx @@ -12,7 +12,7 @@ In this tutorial, we will: -- To use a third-party service to host your node or run a validator, [see here](/nodes/run-a-node/on-third-party-services/amazon-web-services) for dedicated tutorials. +- To use a third-party service to host your node or run a validator, [see here](/nodes/on-third-party-services/amazon-web-services) for dedicated tutorials. - If you're just interested in setting up a node for staking, it's recommended to follow the [AvalancheGo Install Script](/nodes/using-install-script/installing-avalanche-go) tutorial. @@ -246,7 +246,7 @@ XXX.XX.XX.XXX:9650/ext/bc/C/rpc if run on a cloud provider. The “XXX.XX.XX.XXX" should be replaced with the public IP of your EC2 instance. -For more information on the requests available at these endpoints, please see the [AvalancheGo API Reference](/api-reference/quicklinks) documentation. +For more information on the requests available at these endpoints, please see the [AvalancheGo API Reference](/api-reference/p-chain/api) documentation. Going Further[​](#going-further "Direct link to heading") --------------------------------------------------------- @@ -255,4 +255,4 @@ Your Avalanche node will perform consensus on its own, but it is not yet a valid Also check out the [Maintain](/nodes/maintain/bootstrapping) section to learn about how to maintain and customize your node to fit your needs. -To track a Subnet with your node, head to the [Subnet Node](/nodes/run-a-node/subnet-nodes) tutorial. \ No newline at end of file +To track an Avalanche L1 with your node, head to the [Avalanche L1 Node](/nodes/run-a-node/avalanche-l1-nodes) tutorial. \ No newline at end of file diff --git a/content/docs/nodes/using-install-script/node-config-maintenance.mdx b/content/docs/nodes/using-install-script/node-config-maintenance.mdx index 36bd030851a..9a8e919b732 100644 --- a/content/docs/nodes/using-install-script/node-config-maintenance.mdx +++ b/content/docs/nodes/using-install-script/node-config-maintenance.mdx @@ -151,7 +151,7 @@ That's it, you're running an AvalancheGo node! Congratulations! Let us know you If you're on a residential network (dynamic IP), don't forget to set up port forwarding. If you're on a cloud service provider, you're good to go. -Now you can [interact with your node](/api-reference/standards/guides/issuing-api-calls), [stake your tokens](/nodes/validate/what-is-staking), or level up your installation by setting up [node monitoring](/nodes/maintain/monitoring) to get a better insight into what your node is doing. Also, you might want to use our [Postman Collection](/tooling/avalanche-go-postman-collection/setting-up-postman) to more easily issue commands to your node. +Now you can [interact with your node](/api-reference/standards/guides/issuing-api-calls), [stake your tokens](/nodes/validate/what-is-staking), or level up your installation by setting up [node monitoring](/nodes/maintain/monitoring) to get a better insight into what your node is doing. Also, you might want to use our [Postman Collection](/tooling/avalanche-postman/add-postman-collection) to more easily issue commands to your node. Finally, if you haven't already, it is a good idea to [back up](/nodes/maintain/backup-restore) important files in case you ever need to restore your node to a different machine. diff --git a/content/docs/nodes/validate/node-validator.mdx b/content/docs/nodes/validate/node-validator.mdx index b23427dc9d4..1e54903626d 100644 --- a/content/docs/nodes/validate/node-validator.mdx +++ b/content/docs/nodes/validate/node-validator.mdx @@ -11,7 +11,7 @@ blockchains. In this tutorial, we'll add a node to the Primary Network on Avalanche. The P-Chain manages metadata on Avalanche. This includes tracking which nodes -are in which Subnets, which blockchains exist, and which Subnets are validating +are in which Avalanche L1s, which blockchains exist, and which Avalanche L1s are validating which blockchains. To add a validator, we'll issue [transactions](http://support.avalabs.org/en/articles/4587384-what-is-a-transaction) to the P-Chain. @@ -87,7 +87,7 @@ You should see a success message, and your balance should be updated. Go back to the `Stake` tab, and you'll see here an overview of your validation, with information like the amount staked, staking time, and more. -![Staking Overview](/images/staking-overview.png) +![Staking Overview](/images/node-validator.png) Calling [`platform.getPendingValidators`](/api-reference/p-chain/api#platformgetpendingvalidators) diff --git a/content/docs/subnets/deploy-a-subnet/production-infrastructure.mdx b/content/docs/subnets/deploy-a-subnet/production-infrastructure.mdx deleted file mode 100644 index 32333261cda..00000000000 --- a/content/docs/subnets/deploy-a-subnet/production-infrastructure.mdx +++ /dev/null @@ -1,169 +0,0 @@ ---- -title: On Production Infrastructure -descdescription: Learn how to deploy a Subnet on production infrastructure. ---- - -After architecting your Subnet environment on the [local machine](/subnets/deploy-a-subnet/local-network), proving the design and testing it out on [the Fuji Testnet](/subnets/deploy-a-subnet/fuji-testnet), eventually you will need to deploy your Subnet to production environment. - -Running a Subnet in production is much more involved than local and Testnet deploys, as your Subnet will have to take care of real world usage, maintaining uptime, upgrades and all of that in a potentially adversarial environment. The purpose of this document is to point out a set of general considerations and propose potential solutions to them. - -The architecture of the environment your particular Subnet will use will be greatly influenced by the type of load and activity your Subnet is designed to support so your solution will most likely differ from what we propose here. Still, it might be useful to follow along, to build up the intuition for the type of questions you will need to consider. - -Node Setup[​](#node-setup "Direct link to heading") ---------------------------------------------------- - -Avalanche nodes are essential elements for running your Subnet in production. At a minimum, your Subnet will need validator nodes, potentially also nodes that act as RPC servers, indexers or explorers. Running a node is basically running an instance of [AvalancheGo](/nodes/quick-links) on a server. - -### Server OS[​](#server-os "Direct link to heading") - -Although AvalancheGo can run on a MacOS or a Windows computer, we strongly recommend running nodes on computers running Linux as they are designed specifically for server loads and all the tools and utilities needed for administering a server are native to Linux. - -### Hardware Specification[​](#hardware-specification "Direct link to heading") - -For running AvalancheGo as a validator on the Primary Network the recommended configuration is as follows: - -- CPU: Equivalent of 8 AWS vCPU -- RAM: 16 GiB -- Storage: 1 TiB with at least 3000 IOPS -- OS: Ubuntu 20.04 -- Network: Reliable IPv4 or IPv6 network connection, with an open public port - -That is the configuration sufficient for running a Primary Network node. Any resource requirements for your Subnet come on top of this, so you should not go below this configuration, but may need to step up the specification if you expect your Subnet to handle a significant amount of transactions. - -Be sure to set up monitoring of resource consumption for your nodes because resource exhaustion may cause your node to slow down or even halt, which may severely impact your Subnet negatively. - -### Server Location[​](#server-location "Direct link to heading") - -You can run a node on a physical computer that you own and run, or on a cloud instance. Although running on your own HW may seem like a good idea, unless you have a sizeable DevOps 24/7 staff we recommend using cloud service providers as they generally provide reliable computing resources that you can count on to be properly maintained and monitored. - -#### Local Servers[​](#local-servers "Direct link to heading") - -If you plan on running nodes on your own hardware, make sure they satisfy the minimum HW specification as outlined earlier. Pay close attention to proper networking setup, making sure the p2p port (9651) is accessible and public IP properly configured on the node. Make sure the node is connected to the network physically (not over Wi-Fi), and that the router is powerful enough to handle a couple of thousands of persistent TCP connections and that network bandwidth can accommodate at least 5Mbps of steady upstream and downstream network traffic. - -When installing the AvalancheGo node on the machines, unless you have a dedicated DevOps staff that will take care of node setup and configuration, we recommend using the [installer script](/nodes/using-install-script/installing-avalanche-go) to set up the nodes. It will abstract most of the setup process for you, set up the node as a system service and will enable easy node upgrades. - -#### Cloud Providers[​](#cloud-providers "Direct link to heading") - -There are a number of different cloud providers. We have documents that show how to set up a node on the most popular ones: - -- [Amazon Web Services](/nodes/run-a-node/on-third-party-services/amazon-web-services) -- [Azure](/nodes/run-a-node/on-third-party-services/microsoft-azure) -- [Google Cloud Platform](/nodes/run-a-node/on-third-party-services/google-cloud) - -There is a whole range of other cloud providers that may offer lower prices or better deals for your particular needs, so it makes sense to shop around. - -Once you decide on a provider (or providers), if they offer instances in multiple data centers, it makes sense to spread the nodes geographically since that provides a better resilience and stability against outages. - -### Number of Validators[​](#number-of-validators "Direct link to heading") - -Number of validators on a Subnet is a crucial decision you need to make. For stability and decentralization, you should strive to have as many validators as possible. - -For stability reasons our recommendation is to have **at least** 5 full validators on your Subnet. If you have less than 5 validators your Subnet liveness will be at risk whenever a single validator goes offline, and if you have less than 4 even one offline node will halt your Subnet. - -You should be aware that 5 is the minimum we recommend. But, from a decentralization standpoint having more validators is always better as it increases the stability of your Subnet and makes it more resilient to both technical failures and adversarial action. In a nutshell: run as many Subnet validators as you can. - -Considering that at times you will have to take nodes offline, for routine maintenance (at least for node upgrades which happen with some regularity) or unscheduled outages and failures you need to be able to routinely handle at least one node being offline without your Subnet performance degrading. - -### Node Bootstrap[​](#node-bootstrap "Direct link to heading") - -Once you set up the server and install AvalancheGo on them, nodes will need to bootstrap (sync with the network). This is a lengthy process, as the nodes need to catch up and replay all the network activity since the genesis up to the present moment. Full bootstrap on a node can take more than a week, but there are ways to shorten that process, depending on your circumstances. - -#### State Sync[​](#state-sync "Direct link to heading") - -If the nodes you will be running as validators don't need to have the full transaction history, then you can use [state sync](/nodes/configure/chain-configs/c-chain#state-sync-enabled). With this flag enabled, instead of replaying the whole history to get to the current state, nodes simply download only the current state from other network peers, shortening the bootstrap process from multiple days to a couple of hours. If the nodes will be used for Subnet validation exclusively, you can use the state sync without any issues. Currently, state sync is only available for the C-Chain, but since the bulk of the transactions on the platform happen there it still has a significant impact on the speed of bootstrapping. - -#### Database Copy[​](#database-copy "Direct link to heading") - -Good way to cut down on bootstrap times on multiple nodes is database copy. Database is identical across nodes, and as such can safely be copied from one node to another. Just make sure to that the node is not running during the copy process, as that can result in a corrupted database. Database copy procedure is explained in detail [here](/nodes/maintain/backup-restore#database). - -Please make sure you don't reuse any node's NodeID by accident, especially don't restore another node's ID, see [here](/nodes/maintain/backup-restore#nodeid) for details. Each node must has its own unique NodeID, otherwise, the nodes sharing the same ID will not behave correctly, which will impact your validator's uptime, thus staking rewards, and the stability of your Subnet. - -Subnet Deploy[​](#subnet-deploy "Direct link to heading") ---------------------------------------------------------- - -Once you have the nodes set up you are ready to deploy the actual Subnet. Right now, the recommended tool to do that is [Avalanche-CLI](https://github.com/ava-labs/avalanche-cli). - -Instructions for deployment by Avalanche-CLI can be found [here](/subnets/deploy-a-subnet/avalanche-mainnet). - -### Ledger Hardware Wallet[​](#ledger-hw-wallet "Direct link to heading") - -When creating the Subnet, you will be required to have a private key that will control the administrative functions of the Subnet (adding validators, managing the configuration). Needless to say, whoever has this private key has complete control over the Subnet and the way it runs. Therefore, protecting that key is of the utmost operational importance. Which is why we strongly recommend using a hardware wallet such as a [Ledger HW Wallet](https://www.ledger.com/) to store and access that private key. - -General instruction on how to use a Ledger device with Avalanche can be found [here](https://support.avax.network/en/articles/6150237-how-to-use-a-ledger-nano-s-or-nano-x-with-avalanche). - -### Genesis File[​](#genesis-file "Direct link to heading") - -The structure that defines the most important parameters in a Subnet is found in the genesis file, which is a `json` formatted, human-readable file. Describing the contents and the options available in the genesis file is beyond the scope of this document, and if you're ready to deploy your Subnet to production you probably have it mapped out already. - -If you want to review, we have a description of the genesis file in our document on [customizing EVM Subnets](/subnets/upgrade/customize-subnet). - -Validator Configuration[​](#validator-configuration "Direct link to heading") ------------------------------------------------------------------------------ - -Running nodes as Subnet validators warrants some additional considerations, above those when running a regular node or a Primary Network-only validator. - -### Joining a Subnet[​](#joining-a-subnet "Direct link to heading") - -For a node to join a Subnet, there are two prerequisites: - -- Primary Network validation -- Subnet tracking - -Primary Network validation means that a node cannot join a Subnet as a validator before becoming a validator on the Primary Network itself. So, after you add the node to the validator set on the Primary Network, node can join a Subnet. Of course, this is valid only for Subnet validators, if you need a non-validating Subnet node, then the node doesn't need to be a validator at all. - -To have a node start syncing the Subnet, you need to add the `--track-subnets` command line option, or `track-subnets` key to the node config file (found at `.avalanchego/configs/node.json` for installer-script created nodes). A single node can sync multiple Subnets, so you can add them as a comma-separated list of Subnet IDs. - -An example of a node config syncing two Subnets: - -```json -{ - "public-ip-resolution-service": "opendns", - "http-host": "", - "track-subnets": "28nrH5T2BMvNrWecFcV3mfccjs6axM1TVyqe79MCv2Mhs8kxiY,Ai42MkKqk8yjXFCpoHXw7rdTWSHiKEMqh5h8gbxwjgkCUfkrk" -} -``` - -But that is not all. Besides tracking the SubnetID, the node also needs to have the plugin that contains the VM instance the blockchain in the Subnet will run. You should have already been through that on Testnet and Fuji, but for a refresher, you can refer to [this tutorial](/subnets/deploy-a-subnet/fuji-testnet). - -So, name the VM plugin binary as the `VMID` of the Subnet chain and place it in the `plugins` directory where the node binary is (for installer-script created nodes that would be `~/avalanche-node/plugins/`). - -### Subnet Bootstrapping[​](#subnet-bootstrapping "Direct link to heading") - -After you have tracked the Subnet and placed the VM binary in the correct directory, your node is ready to start syncing with the Subnet. Restart the node and monitor the log output. You should notice something similar to: - -```bash -Jul 30 18:26:31 node-fuji avalanchego[1728308]: [07-30|18:26:31.422] INFO chains/manager.go:262 creating chain: -Jul 30 18:26:31 node-fuji avalanchego[1728308]: ID: 2ebCneCbwthjQ1rYT41nhd7M76Hc6YmosMAQrTFhBq8qeqh6tt -Jul 30 18:26:31 node-fuji avalanchego[1728308]: VMID:srEXiWaHuhNyGwPUi444Tu47ZEDwxTWrbQiuD7FmgSAQ6X7Dy -``` - -That means the node has detected the Subnet, and is attempting to initialize it and start bootstrapping the Subnet. It might take some time (if there are already transactions on the Subnet), and eventually it will finish the bootstrap with a message like: - -```bash -Jul 30 18:27:21 node-fuji avalanchego[1728308]: [07-30|18:27:21.055] INFO <2ebCneCbwthjQ1rYT41nhd7M76Hc6YmosMAQrTFhBq8qeqh6tt Chain> snowman/transitive.go:333 consensus starting with J5wjmotMCrM2DKxeBTBPfwgCPpvsjtuqWNozLog2TomTjSuGK as the last accepted block -``` - -That means the node has successfully bootstrapped the Subnet and is now in sync. If the node is one of the validators, it will start validating any transactions that get posted to the Subnet. - -### Monitoring[​](#monitoring "Direct link to heading") - -If you want to inspect the process of Subnet syncing, you can use the RPC call to check for the [blockchain status](/api-reference/p-chain/api#platformgetblockchainstatus). - -For a more in-depth look into Subnet operation, check out the blockchain log. By default, the log can be found in `~/.avalanchego/logs/ChainID.log` where you replace the `ChainID` with the actual ID of the blockchain in your Subnet. - -For an even more thorough (and pretty!) insight into how the node and the Subnet is behaving, you can install the Prometheus+Grafana monitoring system with the custom dashboards for the regular node operation, as well as a dedicated dashboard for Subnet data. Check out the [tutorial](/nodes/maintain/monitoring) for information on how to set it up. - -### Managing Validation[​](#managing-validation "Direct link to heading") - -On Avalanche all validations are limited in time and can range from two weeks up to one year. Furthermore, Subnet validations are always a subset of the Primary Network validation period (must be shorter or the same). That means that periodically your validators will expire and you will need to submit a new validation transaction for both the Primary Network and your Subnet. - -Unless managed properly and in a timely manner, that can be disruptive for your Subnet (if all validators expire at the same time your Subnet will halt). To avoid that, keep notes on when a particular validation is set to expire and be ready to renew it as soon as possible. Also, when initially setting up the nodes, make sure to stagger the validator expiry so they don't all expire on the same date. Setting end dates at least a day apart is a good practice, as well as setting reminders for each expiry. - -Conclusion[​](#conclusion "Direct link to heading") ---------------------------------------------------- - -Hopefully, by reading this document you have a better picture of the requirements and considerations you need to make when deploying your Subnet to production and you are now better prepared to launch your Subnet successfully. - -Keep in mind, running a Subnet in production is not a one-and-done kind of situation, it is in fact running a fleet of servers 24/7. And as with any real time service, you should have a robust logging, monitoring and alerting systems to constantly check the nodes and Subnet health and alert you if anything out of the ordinary happens. - -If you have any questions, doubts or would like to chat, please check out our [Discord server](https://chat.avax.network/), where we host a dedicated `#subnet-chat` channel dedicated to talking about all things Subnet. \ No newline at end of file diff --git a/content/docs/subnets/elastic-subnets/make-subnet-permissionless.mdx b/content/docs/subnets/elastic-subnets/make-subnet-permissionless.mdx deleted file mode 100644 index 8117d476098..00000000000 --- a/content/docs/subnets/elastic-subnets/make-subnet-permissionless.mdx +++ /dev/null @@ -1,80 +0,0 @@ ---- -title: Make Subnet Permissionless -description: Learn how to transform a Permissioned Subnet into an Elastic Subnet. ---- - -Elastic Subnets are permissionless Subnets. More information can be found [here](/subnets/elastic-subnets/parameters). - -This how-to guide focuses on taking an already created permissioned Subnet and transforming it to an elastic (or permissionless) Subnet. - -## Prerequisites - -- [Avalanche-CLI installed](/tooling/guides/get-avalanche-cli) -- You have deployed a permissioned Subnet on [local](/subnets/deploy-a-subnet/local-network), on [Fuji](/subnets/deploy-a-subnet/fuji-testnet) or on [Mainnet](/subnets/deploy-a-subnet/avalanche-mainnet) - -Getting Started[​](#getting-started "Direct link to heading") -------------------------------------------------------------- - -In the following commands, make sure to substitute the name of your Subnet configuration for ``. - -To transform your permissioned Subnet into an Elastic Subnet (NOTE: this action is irreversible), run: - -```bash -avalanche subnet elastic -``` - -and, select the network that you want to transform the Subnet on. Alternatively, you can bypass this prompt by providing the `--local`, `--fuji`, or `--mainnet` flag. - -Provide the name and the symbol for the permissionless Subnet's native token. You can also bypass this prompt by providing the `--tokenName` and `--tokenSymbol` flags. - -Next, select the Elastic Subnet config. You can choose to use the default values detailed [here](/subnets/elastic-subnets/parameters#primary-network-parameters-on-mainnet) or customize the Elastic Subnet config. To bypass the prompt, you can use `--default` flag to use the default Elastic Subnet config. - -The command may take a couple minutes to run. - -### Elastic Subnet Transformation on Fuji and Mainnet[​](#elastic-subnet-transformation-on-fuji-and-mainnet "Direct link to heading") - -Elastic Subnet transformation on public network requires private key loaded into the tool, or a connected ledger device. - -Both stored key usage and ledger usage are enabled on Fuji (see more on creating keys [here](/subnets/deploy-a-subnet/fuji-testnet#private-key)) while only ledger usage is enabled on Mainnet (see more on setting up your ledger [here](/subnets/deploy-a-subnet/avalanche-mainnet#setting-up-your-ledger)). - -To transform a permissioned Subnet into Elastic Subnet on public networks, users are required to provide the keys that control the Subnet defined during the Subnet deployment process (more info on keys in Fuji can be found [here](/subnets/deploy-a-subnet/fuji-testnet#deploy-the-subnet), while more info on ledger signing in Mainnet can be found [here](/subnets/deploy-a-subnet/avalanche-mainnet#deploy-the-subnet)). - -### Results[​](#results "Direct link to heading") - -If all works as expected, you then have the option to automatically transform all existing permissioned validators to permissionless validators. - -You can also to skip automatic transformation at this point and choose to manually add permissionless validators later. - -You can use the output details such as the Asset ID and Elastic Subnet ID to connect to and interact with your Elastic Subnet. - -Adding Permissionless Validators to Elastic Subnet[​](#adding-permissionless-validators-to-elastic-subnet "Direct link to heading") ------------------------------------------------------------------------------------------------------------------------------------ - -If you are running this command on local network, you will need to first remove permissioned validators (by running `avalanche subnet removeValidator `) so that you can have a list of local nodes to choose from to be added as a permissionless validator in the Elastic Subnet. - -To add permissionless validators to an Elastic Subnet, run: - -```bash -avalanche subnet join --elastic -``` - -You will be prompted with which node you would like to add as a permissionless validator. You can skip this prompt by using `--nodeID` flag. - -You will then be prompted with the amount of the Subnet native token that you like to stake in the validator. Alternatively, you can bypass this prompt by providing the `--stake-amount` flag. Note that choosing to add the maximum validator stake amount (defined during Elastic Subnet transformation step above) means that you effectively disable delegation in your validator. - -Next, select when the validator will start validating and how long it will be validating for. You can also bypass these prompts by using `--start-time` and `--staking-period` flags. - -Adding Permissionless Delegator to a Permissionless Validator in Elastic Subnet[​](#adding-permissionless-delegator-to-a-permissionless-validator-in-elastic-subnet "Direct link to heading") ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- - -To add permissionless delegators, run: - -```bash -avalanche subnet addPermissionlessDelegator -``` - -You will be prompted with which Subnet validator you would like to delegate to. You can skip this prompt by using `--nodeID` flag. - -You will then be prompted with the amount of the Subnet native token that you like to stake in the validator. Alternatively, you can bypass this prompt by providing the `--stake-amount` flag. The amount that can be delegated to a validator is detailed [here](/subnets/elastic-subnets/parameters#delegators-weight-checks). - -Next, select when you want to start delegating and how long you want to delegate for. You can also bypass these prompts by using `--start-time` and `--staking-period` flags. \ No newline at end of file diff --git a/content/docs/subnets/index.mdx b/content/docs/subnets/index.mdx deleted file mode 100644 index 896ef2a9a82..00000000000 --- a/content/docs/subnets/index.mdx +++ /dev/null @@ -1,75 +0,0 @@ ---- -title: Getting Started -description: As you begin your Subnet journey, it's useful to look at the lifecycle of taking a Subnet from idea to production. ---- - -Figure Out Your Needs[​](#figure-out-your-needs "Direct link to heading") -------------------------------------------------------------------------- - -The first step of planning your Subnet is determining your application's needs. What features do you need that the Avalanche C-Chain doesn't provide? Perhaps you want your own gas token or only want to allow access to KYCed customers. [When to Build on a Subnet vs. on the C-Chain](/subnets/c-chain-or-subnet) can help you make the decision. - -### Decide What Type of Subnet You Want[​](#decide-what-type-of-subnet-you-want "Direct link to heading") - -Once you've decided to use a Subnet, you need to decide what type of Subnet to build. This means choosing a virtual machine (VM) to create your Subnet with. Broadly speaking, there are three types of VMs to choose from: - -#### EVM-Based Subnets[​](#evm-based-subnets "Direct link to heading") - -EVM-based Subnets are forks of the Avalanche C-Chain. They support Solidity smart contracts and standard [Ethereum APIs](/api-reference/c-chain/api#ethereum-apis). [Subnet-EVM](https://github.com/ava-labs/subnet-evm) is Ava Labs' implementation of an EVM-Based Subnet. - -Subnet-EVM is far and away the safest and most popular choice to build your Subnet with. It has the most mature developer tooling and receives regular updates by the Ava Labs team. - -#### Experimental Subnets[​](#experimental-subnets "Direct link to heading") - -Experimental Subnets are proof-of-concept VMs developed by Ava Labs. They include the [TimestampVM Go](/virtual-machines/golang-vms/simple-golang-vm), [TimestampVMRust](/virtual-machines/timestamp-vm/introduction), and others. These VMs are demo software and aren't ready for production environments. Although they do receive periodic updates, the Ava Labs team hasn't audited their performance and security, internally or externally. However, these open source projects are intended to inspire the community, and provide novel capabilities not available inside the EVM. - -If you're looking to push the boundaries of what's possible with Subnets, this is a great place to get started. - -#### Custom Subnets[​](#custom-subnets "Direct link to heading") - -Custom Subnets are an open-ended interface that allow developers to build any VM they can dream. These VMs may be a fork of an existing VM such as Subnet-EVM, or even a non-Avalanche-native VM such as Solana's virtual machine. Alternatively, you can build your VM entirely from scratch using almost any programming language. See [Introduction to VMs](/virtual-machines) for advice on getting started. - -### Determine Tokenomics[​](#determine-tokenomics "Direct link to heading") - -Subnets are powered by gas tokens. When you build a Subnet, you have the option to decide what token you use and optionally, how you distribute it. You may use AVAX, an existing C-Chain token, or a brand new token. You'll need to decide how much of the supply you want to use to reward validators, what kind of emitting schedule you want, and how much to airdrop. Blocks may burn transaction fees or give them to validators as a block reward. - -### Decide how to Customize Your Subnet[​](#decide-how-to-customize-your-subnet "Direct link to heading") - -After you've selected your VM, you may want to customize it. This may mean airdropping tokens to your team in the genesis, setting how gas fees rates on your network, or changing the behavior of your VM via precompiles. These customizations are hard to get right on paper and usually require some trial and error to determine correctly. See [Customize Your EVM-Powered Subnet](/subnets/upgrade/customize-subnet) for instructions on configuring Subnet-EVM. - -Learn Avalanche-CLI[​](#learn-avalanche-cli "Direct link to heading") ---------------------------------------------------------------------- - -Now that you've specified your Subnet requirements, the next step is learning Avalanche-CLI. - -Avalanche-CLI is the best tool for rapidly prototyping Subnets and deploying them to production. You can use it throughout the entire Subnet development lifecycle. To get started, take a look at [Build Your First Subnet](/subnets/build-first-subnet). - -### Deploy Your Subnet Locally[​](#deploy-your-subnet-locally "Direct link to heading") - -The first stage of Subnet development involves testing your Subnet on your local machine or on a private cloud server such as Amazon EC2. The goal of this phase is to lock-in your Subnet customizations and create your full-stack dapp without the constraints of deploying on a public network. - -Development is extremely quick and updates take seconds to minutes to apply. In this phase, you should restrict dapp access to trusted parties. Because you're interacting with a local copy of the Avalanche network, you can't access production state or other production Subnets. - -### Deploy Your Subnet to Fuji[​](#deploy-your-subnet-to-fuji "Direct link to heading") - -The second stage of Subnet development involves deploying your Subnet and your dapp to the Fuji Testnet. This phase tests your ability to run validator nodes, coordinate all parties involved in the Subnet, and monitor network health. You can also practice using Ledgers to manage Subnet transactions. - -The Subnet is publicly visible and you may want to allow external users to test your dapp. Development on Fuji is significantly slower than with local development. Updates may now take hours to days to apply. It's important to do as much local testing as possible before moving to Fuji. - -### Deploy Your Subnet to Mainnet[​](#deploy-your-subnet-to-mainnet "Direct link to heading") - -The final stage of Subnet development is creating your Subnet on Mainnet and deploying your dapp. It's time to let your real users in. - -Once your Subnet is in production, you have little flexibility to change it. Some alterations are possible, but they require days to weeks to implement and roll out. - -Your focus should shift to preserving network stability and upgrading your nodes as needed. - -Start Developing Custom VMs[​](#start-developing-custom-vms "Direct link to heading") -------------------------------------------------------------------------------------- - -If you've mastered Subnet-EVM and are looking for an additional challenge, consider building a custom VM. The Avalanche network supports far more than just the EVM. Current VMs only scratch the surface of what's possible. - -Some ideas: - -- Port an existing blockchain project to Avalanche. For example: Use Bitcoin's VM or Solana's VM. -- Create an app-specific VM instead of a general purpose VM. For example, create a DEX or a CLOB VM instead of something like the EVM. -- Create a more efficient implementation of the EVM. \ No newline at end of file diff --git a/content/docs/subnets/maintain/delete-subnet.mdx b/content/docs/subnets/maintain/delete-subnet.mdx deleted file mode 100644 index 39a01841564..00000000000 --- a/content/docs/subnets/maintain/delete-subnet.mdx +++ /dev/null @@ -1,24 +0,0 @@ ---- -title: Delete a Subnet -description: Learn how to delete a Subnet. ---- - -Deleting a Subnet Configuration[​](#deleting-a-subnet-configuration "Direct link to heading") ---------------------------------------------------------------------------------------------- - -To delete a created Subnet configuration, run: - -```bash -avalanche blockchain delete -``` - -Deleting a Deployed Subnet[​](#deleting-a-deployed-subnet "Direct link to heading") ------------------------------------------------------------------------------------ - -You can't delete Subnets deployed to Mainnet or the Fuji Testnet. - -However, you may delete Subnets deployed to a local network by cleaning the network state with below command: - -```bash -avalanche network clean -``` diff --git a/content/docs/subnets/meta.json b/content/docs/subnets/meta.json deleted file mode 100644 index 4e7f5c63934..00000000000 --- a/content/docs/subnets/meta.json +++ /dev/null @@ -1,35 +0,0 @@ -{ - "title": "Avalanche Subnets", - "root": true, - "pages": [ - "---Avalanche Subnets---", - "index", - "c-chain-or-subnet", - "build-first-subnet", - "subnet-nodes", - "---Deploy a Subnet---", - "deploy-a-subnet/local-network", - "deploy-a-subnet/fuji-testnet", - "deploy-a-subnet/avalanche-mainnet", - "deploy-a-subnet/production-infrastructure", - "deploy-a-subnet/multisig-auth", - "deploy-a-subnet/custom-virtual-machine", - "---Elastic Subnets---", - "elastic-subnets/make-subnet-permissionless", - "elastic-subnets/parameters", - "---Maintain a Subnet---", - "maintain/view-subnets", - "maintain/pause-resume", - "maintain/delete-subnet", - "maintain/transfer-pchain-funds", - "---Add Utility on a Subnet---", - "add-utility/deploy-smart-contract", - "add-utility/testnet-faucet", - "add-utility/cross-chain-bridge", - "---Upgrade a Subnet---", - "...upgrade", - "---Miscellaneous---", - "wagmi-subnet", - "troubleshooting" - ] -} \ No newline at end of file diff --git a/content/docs/subnets/upgrade/considerations.mdx b/content/docs/subnets/upgrade/considerations.mdx deleted file mode 100644 index 1a78c97aa28..00000000000 --- a/content/docs/subnets/upgrade/considerations.mdx +++ /dev/null @@ -1,119 +0,0 @@ ---- -title: Considerations -description: Learn about some of the key considerations while upgrading your Subnet. ---- - -In the course of Subnet operation, you will inevitably need to upgrade or change some part of the software stack that is running your Subnet. If nothing else, you will have to upgrade the AvalancheGo node client. Same goes for the VM plugin binary that is used to run the blockchain on your Subnet, which is most likely the [Subnet-EVM](https://github.com/ava-labs/subnet-evm), the Subnet implementation of the Ethereum virtual machine. - -Node and VM upgrades usually don't change the way your Subnet functions, instead they keep your Subnet in sync with the rest of the network, bringing security, performance and feature upgrades. Most upgrades are optional, but all of them are recommended, and you should make optional upgrades part of your routine Subnet maintenance. Some upgrades will be mandatory, and those will be clearly communicated as such ahead of time, you need to pay special attention to those. - -Besides the upgrades due to new releases, you also may want to change the configuration of the VM, to alter the way Subnet runs, for various business or operational needs. These upgrades are solely the purview of your team, and you have complete control over the timing of their roll out. Any such change represents a **network upgrade** and needs to be carefully planned and executed. - - -Network Upgrades Permanently Change the Rules of Your Subnet. Procedural mistakes or a botched upgrade can halt your Subnet or lead to data loss! - -When performing a Subnet upgrade, every single validator on the Subnet will need to perform the identical upgrade. - -If you are coordinating a network upgrade, you must schedule advance notice to every Subnet validator so that they have time to perform the upgrade prior to activation. Make sure you have direct line of communication to all your validators! - - -This tutorial will guide you through the process of doing various Subnet upgrades and changes. We will point out things to watch out for and precautions you need to be mindful about. - -General Upgrade Considerations[​](#general-upgrade-considerations "Direct link to heading") -------------------------------------------------------------------------------------------- - -When operating a Subnet, you should always keep in mind that Proof of Stake networks like Avalanche can only make progress if sufficient amount of validating nodes are connected and processing transactions. Each validator on a Subnet is assigned a certain `weight`, which is a numerical value representing the significance of the node in consensus decisions. On the Primary Network, weight is equal to the amount of AVAX staked on the node. On Subnets, weight is currently assigned by the Subnet owners when they issue the transaction adding a validator to the Subnet. - -Subnets can operate normally only if validators representing 80% or more of the cumulative validator weight is connected. If the amount of connected stake falls close to or below 80%, Subnet performance (time to finality) will suffer, and ultimately the Subnet will halt (stop processing transactions). - -You as a Subnet operator need to ensure that whatever you do, at least 80% of the validators' cumulative weight is connected and working at all times. - - -It is mandatory that the cumulative weight of all validators in the Subnet must be at least the value of [`snow-sample-size`](/nodes/configure/configs-flags#--snow-sample-size-int) (default 20). For example, if there is only one validator in the Subnet, its weight must be at least `snow-sample-size` . Hence, when assigning weight to the nodes, always use values greater than 20. Recall that a validator's weight can't be changed while it is validating, so take care to use an appropriate value. - - -Upgrading Subnet Validator Nodes[​](#upgrading-subnet-validator-nodes "Direct link to heading") ------------------------------------------------------------------------------------------------ - -AvalancheGo, the node client that is running the Avalanche validators is under constant and rapid development. New versions come out often (roughly every two weeks), bringing added capabilities, performance improvements or security fixes. Updates are usually optional, but from time to time (much less frequently than regular updates) there will be an update that includes a mandatory network upgrade. Those upgrades are **MANDATORY** for every node running the Subnet. Any node that does not perform the update before the activation timestamp will immediately stop working when the upgrade activates. - -That's why having a node upgrade strategy is absolutely vital, and you should always update to the latest AvalancheGo client immediately when it is made available. - -For a general guide on upgrading AvalancheGo check out [this tutorial](/nodes/maintain/upgrade). When upgrading Subnet nodes and keeping in mind the previous section, make sure to stagger node upgrades and start a new upgrade only once the previous node has successfully upgraded. Use the [Health API](/api-reference/health-api#healthhealth) to check that `healthy` value in the response is `true` on the upgraded node, and on other Subnet validators check that [platform.getCurrentValidators()](/api-reference/p-chain/api#platformgetcurrentvalidators) has `true` in `connected` attribute for the upgraded node's `nodeID`. Once those two conditions are satisfied, node is confirmed to be online and validating the Subnet and you can start upgrading another node. - -Continue the upgrade cycle until all the Subnet nodes are upgraded. - -Upgrading Subnet VM Plugin Binaries[​](#upgrading-subnet-vm-plugin-binaries "Direct link to heading") ------------------------------------------------------------------------------------------------------ - -Besides the AvalancheGo client itself, new versions get released for the VM binaries that run the blockchains on the Subnet. On most Subnets, that is the [Subnet-EVM](https://github.com/ava-labs/subnet-evm), so this tutorial will go through the steps for updating the `subnet-evm` binary. The update process will be similar for updating any VM plugin binary. - -All the considerations for doing staggered node upgrades as discussed in previous section are valid for VM upgrades as well. - -In the future, VM upgrades will be handled by the [Avalanche-CLI tool](https://github.com/ava-labs/avalanche-cli), but for now we need to do it manually. - -Go to the [releases page](https://github.com/ava-labs/subnet-evm/releases) of the Subnet-EVM repository. Locate the latest version, and copy link that corresponds to the OS and architecture of the machine the node is running on (`darwin` = Mac, `amd64` = Intel/AMD processor, `arm64` = Arm processor). Log into the machine where the node is running and download the archive, using `wget` and the link to the archive, like this: - -```bash -wget https://github.com/ava-labs/subnet-evm/releases/download/v0.2.9/subnet-evm_0.2.9_linux_amd64.tar.gz -``` - -This will download the archive to the machine. Unpack it like this (use the correct filename, of course): - -```bash -tar xvf subnet-evm_0.2.9_linux_amd64.tar.gz -``` - -This will unpack and place the contents of the archive in the current directory, file `subnet-evm` is the plugin binary. You need to stop the node now (if the node is running as a service, use `sudo systemctl stop avalanchego` command). You need to place that file into the plugins directory where the AvalancheGo binary is located. If the node is installed using the install script, the path will be `~/avalanche-node/plugins` Instead of the `subnet-evm` filename, VM binary needs to be named as the VM ID of the chain on the Subnet. For example, for the [WAGMI Subnet](https://subnets-test.avax.network/wagmi) that VM ID is `srEXiWaHuhNyGwPUi444Tu47ZEDwxTWrbQiuD7FmgSAQ6X7Dy`. So, the command to copy the new plugin binary would look like: - -```bash -cp subnet-evm ~/avalanche-node/plugins/srEXiWaHuhNyGwPUi444Tu47ZEDwxTWrbQiuD7FmgSAQ6X7Dy -``` - - -Make sure you use the correct VM ID, otherwise, your VM will not get updated and your Subnet may halt. - - -After you do that, you can start the node back up (if running as service do `sudo systemctl start avalanchego`). You can monitor the log output on the node to check that everything is OK, or you can use the [info.getNodeVersion()](/api-reference/info-api#infogetnodeversion) API to check the versions. Example output would look like: - -```json -{ - "jsonrpc": "2.0", - "result": { - "version": "avalanche/1.7.18", - "databaseVersion": "v1.4.5", - "gitCommit": "b6d5827f1a87e26da649f932ad649a4ea0e429c4", - "vmVersions": { - "avm": "v1.7.18", - "evm": "v0.8.15", - "platform": "v1.7.18", - "sqja3uK17MJxfC7AN8nGadBw9JK5BcrsNwNynsqP5Gih8M5Bm": "v0.0.7", - "srEXiWaHuhNyGwPUi444Tu47ZEDwxTWrbQiuD7FmgSAQ6X7Dy": "v0.2.9" - } - }, - "id": 1 -} -``` - -Note that entry next to the VM ID we upgraded correctly says `v0.2.9`. You have successfully upgraded the VM! - -Refer to the previous section on how to make sure node is healthy and connected before moving on to upgrading the next Subnet validator. - -If you don't get the expected result, you can stop the `AvalancheGo`, examine and follow closely step-by-step of the above. You are free to remove files under `~/avalanche-node/plugins`, however, you should keep in mind that removing files is to remove an existing VM binary. You must put the correct VM plugin in place before you restart AvalancheGo. - -Network Upgrades[​](#network-upgrades "Direct link to heading") ---------------------------------------------------------------- - -Sometimes you need to do a network upgrade to change the configured rules in the genesis under which the Chain operates. In regular EVM, network upgrades are a pretty involved process that includes deploying the new EVM binary, coordinating the timed upgrade and deploying changes to the nodes. But since [Subnet-EVM v0.2.8](https://github.com/ava-labs/subnet-evm/releases/tag/v0.2.8), we introduced the long awaited feature to perform network upgrades by just using a few lines of JSON. Upgrades can consist of enabling/disabling particular precompiles, or changing their parameters. Currently available precompiles allow you to: - -- Restrict Smart Contract Deployers -- Restrict Who Can Submit Transactions -- Mint Native Coins -- Configure Dynamic Fees - -Please refer to [Customize a Subnet](/subnets/upgrade/customize-subnet#network-upgrades-enabledisable-precompiles) for a detailed discussion of possible precompile upgrade parameters. - -Summary[​](#summary "Direct link to heading") ---------------------------------------------- - -Vital part of Subnet maintenance is performing timely upgrades at all levels of the software stack running your Subnet. We hope this tutorial will give you enough information and context to allow you to do those upgrades with confidence and ease. If you have additional questions or any issues, please reach out to us on [Discord](https://chat.avalabs.org/). \ No newline at end of file diff --git a/content/docs/tooling/avalanche-cli.mdx b/content/docs/tooling/avalanche-cli.mdx index 7ab8edfd155..f11b3e4a145 100644 --- a/content/docs/tooling/avalanche-cli.mdx +++ b/content/docs/tooling/avalanche-cli.mdx @@ -3,7 +3,7 @@ title: Introduction description: Avalanche-CLI is a command-line tool that gives developers access to everything Avalanche. --- -To get started, look at the documentation for the subcommands or jump right in with `avalanche blockchain create myNewSubnet`. +To get started, look at the documentation for the subcommands or jump right in with `avalanche blockchain create myblockchain`. [Install Avalanche CLI](/tooling/guides/get-avalanche-cli) @@ -44,25 +44,25 @@ avalanche primary addValidator [flags] --delegation-fee uint set the delegation fee (20 000 is equivalent to 2%) ``` -Subnet[​](#subnet "Direct link to heading") +Avalanche L1[​](#avalanche-l1 "Direct link to heading") ------------------------------------------- -The `subnet` command suite provides a collection of tools for developing and deploying Subnets. +The `blockchain` command suite provides a collection of tools for developing and deploying Avalanche L1s. -To get started, use the `blockchain create` command wizard to walk through the configuration of your very first Subnet. Then, go ahead and deploy it with the `blockchain deploy` command. You can use the rest of the commands to manage your Subnet configurations and live deployments. +To get started, use the `blockchain create` command wizard to walk through the configuration of your very first Avalanche L1. Then, go ahead and deploy it with the `blockchain deploy` command. You can use the rest of the commands to manage your Avalanche L1 configurations and live deployments. -### Subnet AddValidator +### Avalanche L1 AddValidator -The `blockchain addValidator` command whitelists a primary network validator to validate the provided deployed Subnet. +The `blockchain addValidator` command whitelists a primary network validator to validate the provided deployed Avalanche L1. -To add the validator to the Subnet's allow list, you first need to provide the subnetName and the validator's unique NodeID. The command then prompts for the validation start time, duration, and stake weight. You can bypass these prompts by providing the values with flags. +To add the validator to the Avalanche L1's allow list, you first need to provide the blockchainName and the validator's unique NodeID. The command then prompts for the validation start time, duration, and stake weight. You can bypass these prompts by providing the values with flags. -This command currently only works on Subnets deployed to either the Fuji Testnet or Mainnet. +This command currently only works on Avalanche L1s deployed to either the Fuji Testnet or Mainnet. **Usage**: ```bash -avalanche blockchain addValidator [subnetName] [flags] +avalanche blockchain addValidator [blockchainName] [flags] ``` **Flags**: @@ -88,14 +88,14 @@ avalanche blockchain addValidator [subnetName] [flags] --weight uint set the staking weight of the validator to add ``` -### Remove Validator in a Subnet +### Remove Validator in an Avalanche L1 -This command removes a node as a validator in a Subnet. +This command removes a node as a validator in an Avalanche L1. **Usage**: ```bash -avalanche blockchain removeValidator [subnetName] [flags] +avalanche blockchain removeValidator [blockchainName] [flags] ``` **Flags**: @@ -113,16 +113,16 @@ avalanche blockchain removeValidator [subnetName] [flags] --testnet remove validator in existing testnet deployment (alias for `fuji`) ``` -### Subnet Change Owner +### Avalanche L1 Change Owner -The `blockchain changeOwner` changes the owner of the deployed Subnet. +The `blockchain changeOwner` changes the owner of the deployed Avalanche L1. -This command currently only works on Subnets deployed to Devnet, Fuji or Mainnet. +This command currently only works on Avalanche L1s deployed to Devnet, Fuji or Mainnet. **Usage**: ```bash -avalanche blockchain changeOwner [subnetName] [flags] +avalanche blockchain changeOwner [blockchainName] [flags] ``` **Flags**: @@ -146,14 +146,14 @@ avalanche blockchain changeOwner [subnetName] [flags] --threshold uint32 required number of control key signatures to make subnet changes ``` -### Subnet Configure +### Avalanche L1 Configure -AvalancheGo nodes support several different configuration files. Subnets have their own Subnet config which applies to all chains/VMs in the Subnet. Each chain within the Subnet can have its own chain config. This command allows you to set both config files. +AvalancheGo nodes support several different configuration files. Avalanche L1s have their own Avalanche L1 config which applies to all chains/VMs in the Avalanche L1. Each chain within the Avalanche L1 can have its own chain config. This command allows you to set both config files. **Usage**: ```bash -avalanche blockchain configure [subnetName] [flags] +avalanche blockchain configure [blockchainName] [flags] ``` **Flags**: @@ -165,18 +165,18 @@ avalanche blockchain configure [subnetName] [flags] --subnet-config string path to the subnet configuration ``` -### Subnet Create +### Avalanche L1 Create -The `blockchain create` command builds a new genesis file to configure your Subnet. By default, the command runs an interactive wizard. It walks you through all the steps you need to create your first Subnet. +The `blockchain create` command builds a new genesis file to configure your Avalanche L1. By default, the command runs an interactive wizard. It walks you through all the steps you need to create your first Avalanche L1. The tool supports deploying Subnet-EVM and custom VMs. You can create a custom, user-generated genesis with a custom VM by providing the path to your genesis and VM binaries with the `--genesis` and `--vm` flags. -By default, running the command with a `subnetName` that already exists causes the command to fail. If you'd like to overwrite an existing configuration, pass the `-f` flag. +By default, running the command with a `blockchainName` that already exists causes the command to fail. If you'd like to overwrite an existing configuration, pass the `-f` flag. **Usage**: ```bash -avalanche blockchain create [subnetName] [flags] +avalanche blockchain create [blockchainName] [flags] ``` **Flags**: @@ -204,9 +204,9 @@ avalanche blockchain create [subnetName] [flags] --warp generate a vm with warp support (needed for teleporter) ``` -### Subnet Delete +### Avalanche L1 Delete -The `blockchain delete` command deletes an existing Subnet configuration. +The `blockchain delete` command deletes an existing Avalanche L1 configuration. **Usage**: @@ -220,18 +220,18 @@ avalanche blockchain delete [flags] -h, --help help for delete ``` -### Subnet Deploy +### Avalanche L1 Deploy -The `blockchain deploy` command deploys your Subnet configuration locally, to Fuji Testnet, or to Mainnet. +The `blockchain deploy` command deploys your Avalanche L1 configuration locally, to Fuji Testnet, or to Mainnet. -At the end of the call, the command prints the RPC URL you can use to interact with the Subnet. +At the end of the call, the command prints the RPC URL you can use to interact with the Avalanche L1. -Avalanche-CLI only supports deploying an individual Subnet once per network. Subsequent attempts to deploy the same Subnet to the same network (local, Fuji, Mainnet) aren't allowed. If you'd like to redeploy a Subnet locally for testing, you must first call [avalanche network clean](#network-clean) to reset all deployed chain state. Subsequent local deploys redeploy the chain with fresh state. You can deploy the same Subnet to multiple networks, so you can take your locally tested Subnet and deploy it on Fuji or Mainnet. +Avalanche-CLI only supports deploying an individual Avalanche L1 once per network. Subsequent attempts to deploy the same Avalanche L1 to the same network (local, Fuji, Mainnet) aren't allowed. If you'd like to redeploy an Avalanche L1 locally for testing, you must first call [avalanche network clean](#network-clean) to reset all deployed chain state. Subsequent local deploys redeploy the chain with fresh state. You can deploy the same Avalanche L1 to multiple networks, so you can take your locally tested Avalanche L1 and deploy it on Fuji or Mainnet. **Usage**: ```bash -avalanche blockchain deploy [subnetName] [flags] +avalanche blockchain deploy [blockchainName] [flags] ``` **Flags**: @@ -259,14 +259,14 @@ avalanche blockchain deploy [subnetName] [flags] --threshold uint32 required number of control key signatures to make subnet changes ``` -### Subnet Describe +### Avalanche L1 Describe -The `blockchain describe` command prints the details of a Subnet configuration to the console. By default, the command prints a summary of the configuration. By providing the `--genesis` flag, the command instead prints out the raw genesis file. +The `blockchain describe` command prints the details of an Avalanche L1 configuration to the console. By default, the command prints a summary of the configuration. By providing the `--genesis` flag, the command instead prints out the raw genesis file. **Usage**: ```bash -avalanche blockchain describe [subnetName] [flags] +avalanche blockchain describe [blockchainName] [flags] ``` **Flags**: @@ -276,16 +276,16 @@ avalanche blockchain describe [subnetName] [flags] -h, --help help for describe ``` -### Subnet Export +### Avalanche L1 Export -The `blockchain export` command write the details of an existing Subnet deploy to a file. +The `blockchain export` command write the details of an existing Avalanche L1 deploy to a file. The command prompts for an output path. You can also provide one with the `--output` flag. **Usage**: ```bash -avalanche blockchain export [subnetName] [flags] +avalanche blockchain export [blockchainName] [flags] ``` **Flags**: @@ -295,20 +295,20 @@ avalanche blockchain export [subnetName] [flags] -o, --output string write the export data to the provided file path ``` -### Subnet Import +### Avalanche L1 Import The `blockchain import` command imports configurations into Avalanche-CLI. -This command supports importing from a file created on another computer, or importing from Subnets running public networks (for example, created manually or with the deprecated Subnet-CLI) +This command supports importing from a file created on another computer, or importing from Avalanche L1s running public networks (for example, created manually or with the deprecated Avalanche-CLI) #### Import from a File -To import from a file, you can optionally provide the path as a command-line argument. Alternatively, running the command without any arguments triggers an interactive wizard. To import from a repository, go through the wizard. By default, an imported Subnet doesn't overwrite an existing Subnet with the same name. To allow overwrites, provide the `--force` flag. +To import from a file, you can optionally provide the path as a command-line argument. Alternatively, running the command without any arguments triggers an interactive wizard. To import from a repository, go through the wizard. By default, an imported Avalanche L1 doesn't overwrite an existing Avalanche L1 with the same name. To allow overwrites, provide the `--force` flag. **Usage**: ```bash -avalanche blockchain import file [subnetPath] [flags] +avalanche blockchain import file [blockchainPath] [flags] ``` **Flags**: @@ -323,14 +323,14 @@ avalanche blockchain import file [subnetPath] [flags] #### Import from a Public Network -The `blockchain import public` command imports a Subnet configuration from a running network. +The `blockchain import public` command imports an Avalanche L1 configuration from a running network. -The genesis file should be available from the disk for this to work. By default, an imported Subnet doesn't overwrite an existing Subnet with the same name. To allow overwrites, provide the `--force` flag. +The genesis file should be available from the disk for this to work. By default, an imported Avalanche L1 doesn't overwrite an existing Avalanche L1 with the same name. To allow overwrites, provide the `--force` flag. **Usage**: ```bash -avalanche blockchain import public [subnetPath] [flags] +avalanche blockchain import public [blockchainPath] [flags] ``` **Flags**: @@ -349,20 +349,20 @@ avalanche blockchain import public [subnetPath] [flags] ``` -### Subnet Join +### Avalanche L1 Join -The `blockchain join` command configures your validator node to begin validating a new Subnet. +The `blockchain join` command configures your validator node to begin validating a new Avalanche L1. -To complete this process, you must have access to the machine running your validator. If the CLI is running on the same machine as your validator, it can generate or update your node's config file automatically. Alternatively, the command can print the necessary instructions to update your node manually. To complete the validation process, the Subnet's admins must add the NodeID of your validator to the Subnet's allow list by calling `addValidator` with your NodeID. +To complete this process, you must have access to the machine running your validator. If the CLI is running on the same machine as your validator, it can generate or update your node's config file automatically. Alternatively, the command can print the necessary instructions to update your node manually. To complete the validation process, the Avalanche L1's admins must add the NodeID of your validator to the Avalanche L1's allow list by calling `addValidator` with your NodeID. After you update your validator's config, you need to restart your validator manually. If you provide the `--avalanchego-config` flag, this command attempts to edit the config file at that path. -This command currently only supports Subnets deployed on the Fuji Testnet and Mainnet. +This command currently only supports Avalanche L1s deployed on the Fuji Testnet and Mainnet. **Usage**: ```bash -avalanche blockchain join [subnetName] [flags] +avalanche blockchain join [blockchainName] [flags] ``` **Flags**: @@ -382,9 +382,9 @@ avalanche blockchain join [subnetName] [flags] --testnet testnet join on testnet (alias for `fuji`) ``` -### Subnet List +### Avalanche L1 List -The `blockchain list` command prints the names of all created Subnet configurations. Without any flags, it prints some general, static information about the Subnet. With the `--deployed` flag, the command shows additional information including the VMID, BlockchainID and SubnetID. +The `blockchain list` command prints the names of all created Avalanche L1 configurations. Without any flags, it prints some general, static information about the Avalanche L1. With the `--deployed` flag, the command shows additional information including the VMID, BlockchainID and SubnetID. **Usage**: @@ -399,14 +399,14 @@ avalanche blockchain list [flags] -h, --help help for list ``` -### Subnet Publish +### Avalanche L1 Publish -The `blockchain publish` command publishes the Subnet's VM to a repository. +The `blockchain publish` command publishes the Avalanche L1's VM to a repository. **Usage**: ```bash -avalanche blockchain publish [subnetName] [flags] +avalanche blockchain publish [blockchainName] [flags] ``` **Flags**: @@ -421,14 +421,14 @@ avalanche blockchain publish [subnetName] [flags] --vm-file-path string Path to the VM description file. If not given, a prompting sequence will be initiated. ``` -### Subnet Stats +### Avalanche L1 Stats -The `blockchain stats` command prints validator statistics for the given Subnet. +The `blockchain stats` command prints validator statistics for the given Avalanche L1. **Usage**: ```bash -avalanche blockchain stats [subnetName] [flags] +avalanche blockchain stats [blockchainName] [flags] ``` **Flags**: @@ -440,27 +440,27 @@ avalanche blockchain stats [subnetName] [flags] --testnet testnet print stats on testnet (alias for `fuji`) ``` -### Subnet VMID +### Avalanche L1 VMID -The `blockchain vmid` command prints the virtual machine ID (VMID) for the given Subnet. +The `blockchain vmid` command prints the virtual machine ID (VMID) for the given Avalanche L1. **Usage**: ```bash -avalanche blockchain vmid [subnetName] +avalanche blockchain vmid [blockchainName] ``` -Elastic Subnet[​](#elastic-subnet "Direct link to heading") +Elastic Avalanche L1[​](#elastic-avalanche-l1 "Direct link to heading") ----------------------------------------------------------- -### Transforms permissioned Subnet into Elastic Subnet +### Transforms permissioned Avalanche L1 into Elastic Avalanche L1 -This command transforms your permissioned Subnet into an Elastic Subnet (NOTE: this action is irreversible). +This command transforms your permissioned Avalanche L1 into an Elastic Avalanche L1 (NOTE: this action is irreversible). **Usage**: ```bash -avalanche blockchain elastic [subnetName] [flags] +avalanche blockchain elastic [blockchainName] [flags] ``` **Flags**: @@ -486,14 +486,14 @@ avalanche blockchain elastic [subnetName] [flags] --transform-validators If true, transform validators to permissionless validators after elastic transform ``` -### Add Permissionless Validator in an Elastic Subnet +### Add Permissionless Validator in an Elastic Avalanche L1 -This command adds a node as a permissionless validator in an Elastic Subnet. +This command adds a node as a permissionless validator in an Elastic Avalanche L1. **Usage**: ```bash -avalanche blockchain join [subnetName] --elastic [flags] +avalanche blockchain join [blockchainName] --elastic [flags] ``` **Flags**: @@ -512,14 +512,14 @@ avalanche blockchain join [subnetName] --elastic [flags] --testnet add permissionless validator in existing testnet deployment (alias for `fuji`) ``` -### Add Permissionless Delegator in an Elastic Subnet +### Add Permissionless Delegator in an Elastic Avalanche L1 -This command delegates stake to a permissionless validator in an Elastic Subnet. +This command delegates stake to a permissionless validator in an Elastic Avalanche L1. **Usage**: ```bash -avalanche blockchain addPermissionlessDelegator [subnetName] [flags] +avalanche blockchain addPermissionlessDelegator [blockchainName] [flags] ``` **Flags**: @@ -538,23 +538,23 @@ avalanche blockchain addPermissionlessDelegator [subnetName] [flags] --testnet add permissionless delegator in existing testnet deployment (alias for `fuji`) ``` -Subnet Upgrade[​](#subnet-upgrade "Direct link to heading") +Avalanche L1 Upgrade[​](#avalanche-l1-upgrade "Direct link to heading") ----------------------------------------------------------- -The `blockchain upgrade` command suite provides a collection of tools for updating your developmental and deployed Subnets. +The `blockchain upgrade` command suite provides a collection of tools for updating your developmental and deployed Avalanche L1s. -### Subnet Upgrade Apply +### Avalanche L1 Upgrade Apply -Apply generated upgrade bytes to running Subnet nodes to trigger a network upgrade. +Apply generated upgrade bytes to running Avalanche L1 nodes to trigger a network upgrade. For public networks (Fuji Testnet or Mainnet), to complete this process, you must have access to the machine running your validator. If the CLI is running on the same machine as your validator, it can manipulate your node's configuration automatically. Alternatively, the command can print the necessary instructions to upgrade your node manually. -After you update your validator's configuration, you need to restart your validator manually. If you provide the `--avalanchego-chain-config-dir` flag, this command attempts to write the upgrade file at that path. Refer to [this doc](/nodes/configure/configs-flags#subnet-chain-configs) for related documentation. +After you update your validator's configuration, you need to restart your validator manually. If you provide the `--avalanchego-chain-config-dir` flag, this command attempts to write the upgrade file at that path. Refer to [this doc](/nodes/configure/configs-flags#avalanche-l1-chain-configs) for related documentation. **Usage**: ```bash -avalanche blockchain upgrade apply [subnetName] [flags] +avalanche blockchain upgrade apply [blockchainName] [flags] ``` **Flags**: @@ -571,14 +571,14 @@ avalanche blockchain upgrade apply [subnetName] [flags] --testnet testnet apply upgrade existing testnet deployment (alias for `fuji`) ``` -### Subnet Upgrade Export +### Avalanche L1 Upgrade Export Export the upgrade bytes file to a location of choice on disk. **Usage**: ```bash -avalanche blockchain upgrade export [subnetName] [flags] +avalanche blockchain upgrade export [blockchainName] [flags] ``` **Flags**: @@ -589,14 +589,14 @@ avalanche blockchain upgrade export [subnetName] [flags] --upgrade-filepath string Export upgrade bytes file to location of choice on disk ``` -### Subnet Upgrade Generate +### Avalanche L1 Upgrade Generate -The `blockchain upgrade generate` command builds a new upgrade.json file to customize your Subnet. It guides the user through the process using an interactive wizard. +The `blockchain upgrade generate` command builds a new upgrade.json file to customize your Avalanche L1. It guides the user through the process using an interactive wizard. **Usage**: ```bash -avalanche blockchain upgrade generate [subnetName] [flags] +avalanche blockchain upgrade generate [blockchainName] [flags] ``` **Flags**: @@ -605,14 +605,14 @@ avalanche blockchain upgrade generate [subnetName] [flags] -h, --help help for generate ``` -### Subnet Upgrade Import +### Avalanche L1 Upgrade Import Import the upgrade bytes file into the local environment. **Usage**: ```bash -avalanche blockchain upgrade import [subnetName] [flags] +avalanche blockchain upgrade import [blockchainName] [flags] ``` **Flags**: @@ -622,28 +622,28 @@ avalanche blockchain upgrade import [subnetName] [flags] --upgrade-filepath string Import upgrade bytes file into local environment ``` -### Subnet Upgrade Print +### Avalanche L1 Upgrade Print Print the upgrade.json file content. **Usage**: ```bash -avalanche blockchain upgrade print [subnetName] [flags] +avalanche blockchain upgrade print [blockchainName] [flags] ``` **Flags**: -### Subnet Upgrade VM +### Avalanche L1 Upgrade VM -The `blockchain upgrade vm` command enables the user to upgrade their Subnet's VM binary. The command can upgrade both local Subnets and publicly deployed Subnets on Fuji and Mainnet. +The `blockchain upgrade vm` command enables the user to upgrade their Avalanche L1's VM binary. The command can upgrade both local Avalanche L1s and publicly deployed Avalanche L1s on Fuji and Mainnet. The command walks the user through an interactive wizard. The user can skip the wizard by providing command line flags. **Usage**: ```bash -avalanche blockchain upgrade export [subnetName] [flags] +avalanche blockchain upgrade export [blockchainName] [flags] ``` **Flags**: @@ -658,7 +658,7 @@ Node[​](#node "Direct link to heading") The `node` command suite provides a collection of tools for creating and maintaining validators on the Avalanche Network. -To get started, use the node create command wizard to walk through the configuration to make your node a primary validator on Avalanche public network. You can use the rest of the commands to maintain your node and make your node a Subnet Validator. +To get started, use the node create command wizard to walk through the configuration to make your node a primary validator on Avalanche public network. You can use the rest of the commands to maintain your node and make your node an Avalanche L1 Validator. ### Node Create @@ -666,7 +666,7 @@ To get started, use the node create command wizard to walk through the configura (ALPHA Warning) This command is currently in experimental mode. -The `node create` command sets up a validator on a cloud server of your choice. The validator will be validating the Avalanche Primary Network and Subnet of your choice. By default, the command runs an interactive wizard. It walks you through all the steps you need to set up a validator. Validators can be deployed in multiple regions/zones simultaneously. Once this command is run, you will have to wait for the validator to finish bootstrapping on the primary network before running further commands on it, for example validating a Subnet. You can check the bootstrapping status by running `avalanche node status`. +The `node create` command sets up a validator on a cloud server of your choice. The validator will be validating the Avalanche Primary Network and Avalanche L1 of your choice. By default, the command runs an interactive wizard. It walks you through all the steps you need to set up a validator. Validators can be deployed in multiple regions/zones simultaneously. Once this command is run, you will have to wait for the validator to finish bootstrapping on the primary network before running further commands on it, for example validating an Avalanche L1. You can check the bootstrapping status by running `avalanche node status`. The created node will be part of group of validators called `` and users can call node commands with `` so that the command will apply to all nodes in the cluster. @@ -715,22 +715,22 @@ The `node devnet` command suite provides a collection of commands related to dev ### Node Devnet Deploy -The `node devnet deploy` command deploys a Subnet into a devnet cluster, creating Subnet and blockchain TXs for it. It saves the deploy info both locally and remotely. +The `node devnet deploy` command deploys an Avalanche L1 into a devnet cluster, creating Avalanche L1 and blockchain TXs for it. It saves the deploy info both locally and remotely. **Usage**: ```bash -avalanche node devnet deploy [clusterName] [subnetName] [flags] +avalanche node devnet deploy [clusterName] [blockchainName] [flags] ``` ### Node Devnet Wiz -The `node devnet wiz` command creates a devnet and deploys, sync and validate a Subnet into it. It creates the Subnet if so needed. +The `node devnet wiz` command creates a devnet and deploys, sync and validate an Avalanche L1 into it. It creates the Avalanche L1 if so needed. **Usage**: ```bash -avalanche node devnet wiz [clusterName] [subnetName] [flags] +avalanche node devnet wiz [clusterName] [blockchainName] [flags] ``` **Flags**: @@ -819,7 +819,7 @@ avalanche node ssh [clusterName] [flags] The `node status` command gets the bootstrap status of all nodes in a cluster with the Primary Network. If no cluster is given, defaults to node list behaviour. -To get the bootstrap status of a node with a Subnet, use the `--subnet` flag. +To get the bootstrap status of a node with an Avalanche L1, use the `--subnet` flag. **Usage**: @@ -864,12 +864,12 @@ avalanche node stop [clusterName] [flags] (ALPHA Warning) This command is currently in experimental mode. -The `node sync` command enables all nodes in a cluster to be bootstrapped to a Subnet. You can check the Subnet bootstrap status by calling avalanche `node status --subnet ` +The `node sync` command enables all nodes in a cluster to be bootstrapped to an Avalanche L1. You can check the Avalanche L1 bootstrap status by calling avalanche `node status --subnet ` **Usage**: ```bash -avalanche node sync [clusterName] [subnetName] [flags] +avalanche node sync [clusterName] [blockchainName] [flags] ``` ### Node Update @@ -880,18 +880,18 @@ avalanche node sync [clusterName] [subnetName] [flags] The `node update` command suite provides a collection of commands for nodes to update their AvalancheGo version or VM version/config. You can check the status after update by running `avalanche node status` -### Node Update Subnet +### Node Update Avalanche L1 (ALPHA Warning) This command is currently in experimental mode. -The `node update subnet` command updates all nodes in a cluster with latest Subnet configuration and You can check the updated Subnet bootstrap status by calling avalanche `node status --subnet ` +The `node update subnet` command updates all nodes in a cluster with latest Avalanche L1 configuration and You can check the updated Avalanche L1 bootstrap status by calling avalanche `node status --subnet ` **Usage**: ```bash -avalanche node update subnet [clusterName] [subnetName] [flags] +avalanche node update subnet [clusterName] [blockchainName] [flags] ``` **Flags**: @@ -906,7 +906,7 @@ avalanche node update subnet [clusterName] [subnetName] [flags] (ALPHA Warning) This command is currently in experimental mode. -The `node validate` command suite provides a collection of commands for nodes to join the Primary Network and Subnets as validators. If any of the commands is run before the nodes are bootstrapped on the Primary Network, the command will fail. +The `node validate` command suite provides a collection of commands for nodes to join the Primary Network and Avalanche L1s as validators. If any of the commands is run before the nodes are bootstrapped on the Primary Network, the command will fail. You can check the bootstrap status by running `avalanche node status `. @@ -938,18 +938,18 @@ avalanche node validate primary [clusterName] [flags] -t, --testnet fuji set up validator in testnet (alias to fuji) ``` -### Node Validate Subnet +### Node Validate Avalanche L1 (ALPHA Warning) This command is currently in experimental mode. -The `node validate subnet` command enables all nodes in a cluster to be validators of a Subnet. If the command is run before the nodes are Primary Network validators, the command will first make the nodes Primary Network validators before making them Subnet validators. If The command is run before the nodes are bootstrapped on the Primary Network, the command will fail. You can check the bootstrap status by calling `avalanche node status `. If The command is run before the nodes are synced to the Subnet, the command will fail. You can check the Subnet sync status by calling `avalanche node status --subnet `. +The `node validate subnet` command enables all nodes in a cluster to be validators of an Avalanche L1. If the command is run before the nodes are Primary Network validators, the command will first make the nodes Primary Network validators before making them Avalanche L1 validators. If The command is run before the nodes are bootstrapped on the Primary Network, the command will fail. You can check the bootstrap status by calling `avalanche node status `. If The command is run before the nodes are synced to the Avalanche L1, the command will fail. You can check the Avalanche L1 sync status by calling `avalanche node status --subnet `. **Usage**: ```bash -avalanche node validate subnet [clusterName] [subnetName] [flags] +avalanche node validate subnet [clusterName] [blockchainName] [flags] ``` **Flags**: @@ -1073,15 +1073,15 @@ avalanche node resize [clusterName] [flags] Network[​](#network "Direct link to heading") --------------------------------------------- -The `network` command suite provides a collection of tools for managing local Subnet deployments. +The `network` command suite provides a collection of tools for managing local Avalanche L1 deployments. -When you deploy a Subnet locally, it runs on a local, multi-node Avalanche network. The `blockchain deploy` command starts this network in the background. This command suite allows you to shutdown, restart, and clear that network. +When you deploy an Avalanche L1 locally, it runs on a local, multi-node Avalanche network. The `blockchain deploy` command starts this network in the background. This command suite allows you to shutdown, restart, and clear that network. -This network currently supports multiple, concurrently deployed Subnets. +This network currently supports multiple, concurrently deployed Avalanche L1s. ### Network Clean -The `network clean` command shuts down your local, multi-node network. All deployed Subnets shutdown and delete their state. You can restart the network by deploying a new Subnet configuration. +The `network clean` command shuts down your local, multi-node network. All deployed Avalanche L1s shutdown and delete their state. You can restart the network by deploying a new Avalanche L1 configuration. **Usage**: @@ -1137,7 +1137,7 @@ avalanche network status [flags] The `network stop` command shuts down your local, multi-node network. -All deployed Subnets shutdown gracefully and save their state. If you provide the `--snapshot-name` flag, the network saves its state under this named snapshot. You can reload this snapshot with `network start --snapshot-name `. Otherwise, the network saves to the default snapshot, overwriting any existing state. You can reload the default snapshot with `network start`. +All deployed Avalanche L1s shutdown gracefully and save their state. If you provide the `--snapshot-name` flag, the network saves its state under this named snapshot. You can reload this snapshot with `network start --snapshot-name `. Otherwise, the network saves to the default snapshot, overwriting any existing state. You can reload the default snapshot with `network start`. **Usage**: @@ -1164,7 +1164,7 @@ The `transaction commit` command commits a transaction by submitting it to the P **Usage**: ```bash -avalanche transaction commit [subnetName] [flags] +avalanche transaction commit [blockchainName] [flags] ``` **Flags**: @@ -1181,7 +1181,7 @@ The `transaction sign` command signs a multisig transaction. **Usage**: ```bash -avalanche transaction sign [subnetName] [flags] +avalanche transaction sign [blockchainName] [flags] ``` **Flags**: @@ -1197,13 +1197,13 @@ avalanche transaction sign [subnetName] [flags] Key[​](#key "Direct link to heading") ------------------------------------- -The `key` command suite provides a collection of tools for creating and managing signing keys. You can use these keys to deploy Subnets to the Fuji Testnet, but these keys are NOT suitable to use in production environments. DO NOT use these keys on Mainnet. +The `key` command suite provides a collection of tools for creating and managing signing keys. You can use these keys to deploy Avalanche L1s to the Fuji Testnet, but these keys are NOT suitable to use in production environments. DO NOT use these keys on Mainnet. To get started, use the `key create` command. ### Key Create -The `key create` command generates a new private key to use for creating and controlling test Subnets. Keys generated by this command are NOT cryptographically secure enough to use in production environments. DO NOT use these keys on Mainnet. +The `key create` command generates a new private key to use for creating and controlling test Avalanche L1s. Keys generated by this command are NOT cryptographically secure enough to use in production environments. DO NOT use these keys on Mainnet. The command works by generating a secp256 key and storing it with the provided `keyName`. You can use this key in other commands by providing this `keyName`. diff --git a/content/docs/tooling/avalanche-go-installer.mdx b/content/docs/tooling/avalanche-go-installer.mdx index d3c8d1ec8ef..633678ba039 100644 --- a/content/docs/tooling/avalanche-go-installer.mdx +++ b/content/docs/tooling/avalanche-go-installer.mdx @@ -3,7 +3,7 @@ title: AvalancheGo Installer description: Script to install AvalancheGo on any Linux computer. --- -AvalancheGo Installer is a shell (bash) script that installs AvalancheGo on any Linux computer. This script sets up full, running node in a matter of minutes with minimal user input required. This is convenient if you want to run the node as a service on a standalone Linux installation, for example to set up a (Subnet) validator, use the node as a private RPC server and similar uses. It also makes upgrading or reinstalling the nodes easy. +AvalancheGo Installer is a shell (bash) script that installs AvalancheGo on any Linux computer. This script sets up full, running node in a matter of minutes with minimal user input required. This is convenient if you want to run the node as a service on a standalone Linux installation, for example to set up a (Avalanche L1) validator, use the node as a private RPC server and similar uses. It also makes upgrading or reinstalling the nodes easy. GitHub: [https://github.com/ava-labs/avalanche-docs/blob/master/scripts/avalanchego-installer.sh](https://github.com/ava-labs/avalanche-docs/blob/master/scripts/avalanchego-installer.sh) diff --git a/content/docs/tooling/avalanche-js.mdx b/content/docs/tooling/avalanche-js.mdx index 1e542cb7083..687c9b101e0 100644 --- a/content/docs/tooling/avalanche-js.mdx +++ b/content/docs/tooling/avalanche-js.mdx @@ -3,7 +3,7 @@ title: AvalancheJS description: JavaScript library for Avalanche. --- -AvalancheJS is a JavaScript Library for interfacing with the [Avalanche](https://docs.avax.network/intro) Platform. It is built using TypeScript and intended to support both browser and Node.js. The AvalancheJS library allows you to issue commands to the Avalanche node APIs. +AvalancheJS is a JavaScript Library for interfacing with the [Avalanche](https://docs.avax.network/learn) Platform. It is built using TypeScript and intended to support both browser and Node.js. The AvalancheJS library allows you to issue commands to the Avalanche node APIs. The APIs currently supported by default are: @@ -29,7 +29,7 @@ Using AvalancheJS, developers can: - Issue signed transactions to the X-Chain, P-Chain, and C-Chain - Perform cross-chain swaps between the X, P and C chains - Add Validators and Delegators -- Create Subnets and Blockchains +- Create Avalanche L1s and Blockchains Requirements[​](#requirements "Direct link to heading") ------------------------------------------------------- diff --git a/content/docs/tooling/avalanche-network-runner/anr-commands.mdx b/content/docs/tooling/avalanche-network-runner/anr-commands.mdx index af7fb057c50..2bc27814512 100644 --- a/content/docs/tooling/avalanche-network-runner/anr-commands.mdx +++ b/content/docs/tooling/avalanche-network-runner/anr-commands.mdx @@ -80,7 +80,7 @@ avalanche-network-runner control add-node node-name [options] [flags] - `--chain-configs string` \[optional\] JSON string of map from chain id to its config file contents - `--node-config string` node config as string - `--plugin-dir string` \[optional\] plugin directory -- `--subnet-configs string` \[optional\] JSON string of map from Subnet id to its config file contents +- `--subnet-configs string` \[optional\] JSON string of map from Avalanche L1 id (SubnetID) to its config file contents - `--upgrade-configs string` \[optional\] JSON string of map from chain id to its upgrade file contents #### Example[​](#example-2 "Direct link to heading") @@ -99,7 +99,7 @@ curl --location 'http://localhost:8081/v1/control/addnode' \ ### `add-permissionless-delegator`[​](#add-permissionless-delegator "Direct link to heading") -Delegates to a permissionless validator in an Elastic Subnet. +Delegates to a permissionless validator in an Elastic Avalanche L1. ```bash avalanche-network-runner control add-permissionless-delegator permissionlessValidatorSpecs [options] [flags] @@ -131,7 +131,7 @@ curl --location 'http://localhost:8081/v1/control/addpermissionlessdelegator' \ ### `add-permissionless-validator`[​](#add-permissionless-validator "Direct link to heading") -Adds a permissionless validator to Elastic Subnets. +Adds a permissionless validator to Elastic Avalanche L1s. ```bash avalanche-network-runner control add-permissionless-validator permissionlessValidatorSpecs [options] [flags] @@ -159,9 +159,9 @@ curl --location 'http://localhost:8081/v1/control/addpermissionlessvalidator' \ ]}' ``` -### `add-subnet-validators`[​](#add-subnet-validators "Direct link to heading") +### `add-subnet-validators`[​](#add-avalanche-l1-validators "Direct link to heading") -Adds Subnet validators. +Adds Avalanche L1 validators. ```bash avalanche-network-runner control add-subnet-validators validatorsSpec [options] [flags] @@ -229,9 +229,9 @@ curl --location 'http://localhost:8081/v1/control/createblockchains' \ }' ``` -### `create-subnets`[​](#create-subnets "Direct link to heading") +### `create-subnets`[​](#create-avalanche-l1s "Direct link to heading") -Creates Subnets. +Creates Avalanche L1s. ```bash avalanche-network-runner control create-subnets [options] [flags] @@ -258,9 +258,9 @@ curl --location 'http://localhost:8081/v1/control/createsubnets' \ }' ``` -### `elastic-subnets`[​](#elastic-subnets "Direct link to heading") +### `elastic-subnets`[​](#elastic-avalanche-l1s "Direct link to heading") -Transforms Subnets to Elastic Subnets. +Transforms Avalanche L1s to Elastic Avalanche L1s. ```bash avalanche-network-runner control elastic-subnets elastic_subnets_specs [options] [flags] @@ -354,9 +354,9 @@ avalanche-network-runner control list-rpcs curl --location --request POST 'http://localhost:8081/v1/control/listrpcs' ``` -### `list-subnets`[​](#list-subnets "Direct link to heading") +### `list-subnets`[​](#list-avalanche-l1s "Direct link to heading") -Lists all Subnet IDs of the network. +Lists all Avalanche L1 IDs (SubnetID) of the network. ```bash avalanche-network-runner control list-subnets [flags] @@ -391,7 +391,7 @@ avalanche-network-runner control load-snapshot snapshotName --avalanchego-path / - `--plugin-dir string` plugin directory - `--reassign-ports-if-used` true to reassign snapshot ports if already taken - `--root-data-dir string` root data directory to store logs and configurations -- `--subnet-configs string` \[optional\] JSON string of map from Subnet id to its config file contents +- `--subnet-configs string` \[optional\] JSON string of map from Avalanche L1 id to its config file contents - `--upgrade-configs string` \[optional\] JSON string of map from chain id to its upgrade file contents #### Example[​](#example-15 "Direct link to heading") @@ -477,9 +477,9 @@ curl --location 'http://localhost:8081/v1/control/removesnapshot' \ }' ``` -### `remove-subnet-validator`[​](#remove-subnet-validator "Direct link to heading") +### `remove-subnet-validator`[​](#remove-avalanche-l1-validator "Direct link to heading") -Removes a Subnet validator. +Removes an Avalanche L1 validator. ```bash avalanche-network-runner control remove-subnet-validator removeValidatorSpec [options] [flags] @@ -510,9 +510,9 @@ avalanche-network-runner control restart-node node-name [options] [flags] - `--avalanchego-path string` AvalancheGo binary path - `--chain-configs string` \[optional\] JSON string of map from chain id to its config file contents - `--plugin-dir string` \[optional\] plugin directory -- `--subnet-configs string` \[optional\] JSON string of map from Subnet id to its config file contents +- `--subnet-configs string` \[optional\] JSON string of map from Avalanche L1 id (SubnetID) to its config file contents - `--upgrade-configs string` \[optional\] JSON string of map from chain id to its upgrade file contents -- `--whitelisted-subnets string` \[optional\] whitelisted Subnets (comma-separated) +- `--whitelisted-subnets string` \[optional\] whitelisted Avalanche L1s (comma-separated) #### Example[​](#example-20 "Direct link to heading") @@ -645,9 +645,9 @@ avalanche-network-runner control start [options] [flags] - `--plugin-dir string` \[optional\] plugin directory - `--reassign-ports-if-used` true to reassign default/given ports if already taken - `--root-data-dir string` \[optional\] root data directory to store logs and configurations -- `--subnet-configs string` \[optional\] JSON string of map from Subnet id to its config file contents +- `--subnet-configs string` \[optional\] JSON string of map from Avalanche L1 id (SubnetID) to its config file contents - `--upgrade-configs string` \[optional\] JSON string of map from chain id to its upgrade file contents -- `--whitelisted-subnets string` \[optional\] whitelisted Subnets (comma-separated) +- `--whitelisted-subnets string` \[optional\] whitelisted Avalanche L1s (comma-separated) #### Example[​](#example-25 "Direct link to heading") diff --git a/content/docs/tooling/avalanche-network-runner/introduction.mdx b/content/docs/tooling/avalanche-network-runner/introduction.mdx index a05a33b0c67..324854e6bec 100644 --- a/content/docs/tooling/avalanche-network-runner/introduction.mdx +++ b/content/docs/tooling/avalanche-network-runner/introduction.mdx @@ -7,9 +7,9 @@ description: The Avalanche Network Runner (ANR) allows a user to define, create Developing P2P systems is hard, and blockchains are no different. A developer can't just focus on the functionality of a node, but needs to consider the dynamics of the network, the interaction of nodes and emergent system properties. A lot of testing can't be addressed by unit testing, but needs a special kind of integration testing, where the code runs in interaction with other nodes, attempting to simulate real network scenarios. -In the context of Avalanche, **[Subnets](/learn/subnets)** are a special focus which requires new tooling and support for playing, working and testing with this unique feature of the Avalanche ecosystem. +In the context of Avalanche, **[Avalanche L1s](/learn/avalanche-l1s)** are a special focus which requires new tooling and support for playing, working and testing with this unique feature of the Avalanche ecosystem. -The ANR aims at being a tool for developers and system integrators alike, offering functionality to run networks of AvalancheGo nodes with support for custom node, Subnet and network configurations, allowing to locally test code before deploying to Mainnet or even public testnets like `fuji`. +The ANR aims at being a tool for developers and system integrators alike, offering functionality to run networks of AvalancheGo nodes with support for custom node, Avalanche L1 and network configurations, allowing to locally test code before deploying to Mainnet or even public testnets like `fuji`. You can also use the [Avalanche Network Runner Postman collection](https://github.com/ava-labs/avalanche-network-runner-postman-collection). @@ -50,7 +50,7 @@ There are two main ways to use the network-runner: This allows for custom network scenarios and high flexibility, but requires more code to be written. -Running the binary, the user can send requests to the RPC server in order to start a network, create Subnets, add nodes to the network, remove nodes from the network, restart nodes, etc. You can make requests through the `avalanche-network-runner` command or by making API calls. Requests are "translated" into gRPC and sent to the server. +Running the binary, the user can send requests to the RPC server in order to start a network, create Avalanche L1s, add nodes to the network, remove nodes from the network, restart nodes, etc. You can make requests through the `avalanche-network-runner` command or by making API calls. Requests are "translated" into gRPC and sent to the server. Each node can then also be reached via [API](https://github.com/ava-labs/avalanche-network-runner/tree/main/api) endpoints which each node exposes. @@ -119,7 +119,7 @@ Additional optional parameters which can be passed to the start command: --custom-node-configs" '{"node1":{"log-level":"debug","api-admin-enabled":false},"node2":{...},...}' ``` -`--plugin-dir` and `--blockchain-specs` are parameters relevant to Subnet operation. +`--plugin-dir` and `--blockchain-specs` are parameters relevant to Avalanche L1 operation. `--plugin-dir` can be used to indicate to ANR where it will find plugin binaries for your own VMs. It is optional. If not set, ANR will assume a default location which is relative to the `avalanchego-path` given. @@ -130,7 +130,7 @@ Additional optional parameters which can be passed to the start command: "genesis": path to a file containing the genesis for your blockchain (must be a valid path) ``` -See the [Avalanche-CLI documentation](/subnets/deploy-a-subnet/local-network) for details about how to create and run Subnets with our _Avalanche-CLI_ tool. +See the [Avalanche-CLI documentation](/avalanche-l1s/deploy-a-avalanche-l1/local-network) for details about how to create and run Avalanche L1s with our _Avalanche-CLI_ tool. The network-runner supports AvalancheGo node configuration at different levels. @@ -297,7 +297,7 @@ It's also possible to provide individual node config parameters: **Note**: The following parameters will be _ignored_ if set in `--node-config`, because the network runner needs to set its own in order to function properly: `--log-dir` `--db-dir` -**Note**: The following Subnet parameters will be set from the global network configuration to this node: `--track-subnets` `--plugin-dir` +**Note**: The following Avalanche L1 parameters will be set from the global network configuration to this node: `--track-subnets` `--plugin-dir` #### Terminate the Cluster @@ -315,13 +315,13 @@ avalanche-network-runner control stop \ --endpoint="0.0.0.0:8080" ``` -## Subnets +## Avalanche L1s -For general Subnet documentation, please refer to [Subnets](/learn/subnets). ANR can be a great helper working with Subnets, and can be used to develop and test new Subnets before deploying them in public networks. However, for a smooth and guided experience, we recommend using [Avalanche-CLI](/subnets/deploy-a-subnet/local-network). These examples expect a basic understanding of what Subnets are and their usage. +For general Avalanche L1 documentation, please refer to [Avalanche L1s](/learn/avalanche-l1s). ANR can be a great helper working with Avalanche L1s, and can be used to develop and test new Avalanche L1s before deploying them in public networks. However, for a smooth and guided experience, we recommend using [Avalanche-CLI](/avalanche-l1s/deploy-a-avalanche-l1/local-network). These examples expect a basic understanding of what Avalanche L1s are and their usage. ### RPC Server Subnet-EVM Example -The Subnet-EVM is a simplified version of Coreth VM (C-Chain). This chain implements the Ethereum Virtual Machine and supports Solidity smart-contracts as well as most other Ethereum client functionality. It can be used to create your own fully Ethereum-compatible Subnet running on Avalanche. This means you can run your Ethereum-compatible dApps in custom Subnets, defining your own gas limits and fees, and deploying solidity smart-contracts while taking advantage of Avalanche's validator network, fast finality, consensus mechanism and other features. Essentially, think of it as your own Ethereum where you can concentrate on your business case rather than the infrastructure. See [Subnet-EVM](https://github.com/ava-labs/subnet-evm) for further information. +The Subnet-EVM is a simplified version of Coreth VM (C-Chain). This chain implements the Ethereum Virtual Machine and supports Solidity smart-contracts as well as most other Ethereum client functionality. It can be used to create your own fully Ethereum-compatible Avalanche L1 running on Avalanche. This means you can run your Ethereum-compatible dApps in custom Avalanche L1s, defining your own gas limits and fees, and deploying solidity smart-contracts while taking advantage of Avalanche's validator network, fast finality, consensus mechanism and other features. Essentially, think of it as your own Ethereum where you can concentrate on your business case rather than the infrastructure. See [Subnet-EVM](https://github.com/ava-labs/subnet-evm) for further information. ## Using Avalanche Network as a Library diff --git a/content/docs/tooling/avalanche-plugin-manager.mdx b/content/docs/tooling/avalanche-plugin-manager.mdx index 085f640090b..3f8038aa2fc 100644 --- a/content/docs/tooling/avalanche-plugin-manager.mdx +++ b/content/docs/tooling/avalanche-plugin-manager.mdx @@ -2,13 +2,13 @@ title: Avalanche Plugin Manager --- -Avalanche Plugin Manager (APM) is a command-line tool to manage virtual machines binaries on existing AvalancheGo instances. It enables to add/remove nodes to Subnets, upgrade the VM plugin binaries as new versions get released to the plugin repository. +Avalanche Plugin Manager (APM) is a command-line tool to manage virtual machines binaries on existing AvalancheGo instances. It enables to add/remove nodes to Avalanche L1s, upgrade the VM plugin binaries as new versions get released to the plugin repository. GitHub: [https://github.com/ava-labs/apm](https://github.com/ava-labs/apm) `avalanche-plugins-core`[​](#avalanche-plugins-core "Direct link to heading") ----------------------------------------------------------------------------- -`avalanche-plugins-core` is plugin repository that ships with the `apm`. A plugin repository consists of a set of virtual machine and Subnet definitions that the `apm` consumes to allow users to quickly and easily download and manage VM binaries. +`avalanche-plugins-core` is plugin repository that ships with the `apm`. A plugin repository consists of a set of virtual machine and Avalanche L1 definitions that the `apm` consumes to allow users to quickly and easily download and manage VM binaries. GitHub: [https://github.com/ava-labs/avalanche-plugins-core](https://github.com/ava-labs/avalanche-plugins-core) \ No newline at end of file diff --git a/content/docs/tooling/avalanche-postman/add-postman-collection.mdx b/content/docs/tooling/avalanche-postman/add-postman-collection.mdx index 4ca9ae8991e..a849e09faa6 100644 --- a/content/docs/tooling/avalanche-postman/add-postman-collection.mdx +++ b/content/docs/tooling/avalanche-postman/add-postman-collection.mdx @@ -71,11 +71,11 @@ Now we sorted everything out, and we're ready to query the node. Conclusion[​](#conclusion "Direct link to heading") --------------------------------------------------- -If you have completed the tutorial, you are now able to quickly [issue API calls](/tooling/avalanche-go-postman-collection/making-api-calls) to your node without messing with the curl commands in the terminal. This allows you to quickly see the state of your node, track changes or double-check the health or liveness of your node. +If you have completed the tutorial, you are now able to quickly [issue API calls](/tooling/avalanche-postman/making-api-calls) to your node without messing with the curl commands in the terminal. This allows you to quickly see the state of your node, track changes or double-check the health or liveness of your node. Contributing[​](#contributing "Direct link to heading") ------------------------------------------------------- -We're hoping to continuously keep this collection up-to-date with the [Avalanche APIs](/api-reference/quicklinks). If you're able to help improve the Avalanche Postman Collection in any way, first create a feature branch by branching off of `master`, next make the improvements on your feature branch and lastly create a [pull request](https://github.com/ava-labs/avalanche-docs/pulls) to merge your work back in to `master`. +We're hoping to continuously keep this collection up-to-date with the [Avalanche APIs](/api-reference/p-chain/api). If you're able to help improve the Avalanche Postman Collection in any way, first create a feature branch by branching off of `master`, next make the improvements on your feature branch and lastly create a [pull request](https://github.com/ava-labs/avalanche-docs/pulls) to merge your work back in to `master`. If you have any other questions or suggestions, come [talk to us](https://chat.avalabs.org/). \ No newline at end of file diff --git a/content/docs/tooling/avalanche-postman/data-visualization.mdx b/content/docs/tooling/avalanche-postman/data-visualization.mdx index 0e285566aa5..cbee1e24da8 100644 --- a/content/docs/tooling/avalanche-postman/data-visualization.mdx +++ b/content/docs/tooling/avalanche-postman/data-visualization.mdx @@ -4,7 +4,7 @@ title: Data Visualization Data visualization is available for a number of API calls whose responses are transformed and presented in tabular format for easy reference. -Please check out [Setting up Postman](/tooling/avalanche-go-postman-collection/setting-up-postman#setup) and [Making API Calls](/tooling/avalanche-go-postman-collection/making-api-calls) beforehand, as this guide assumes that the user has already gone through these steps. +Please check out [Setting up Postman](/tooling/avalanche-postman/add-postman-collection#setup) and [Making API Calls](/tooling/avalanche-postman/making-api-calls) beforehand, as this guide assumes that the user has already gone through these steps. Data visualizations are available for following API calls: @@ -80,7 +80,7 @@ Please note that this only works for C-Chain Mainnet, not Fuji. How to Visualize Responses[​](#how-to-visualize-responses "Direct link to heading") ----------------------------------------------------------------------------------- -1. After [installing Postman](/tooling/avalanche-go-postman-collection/setting-up-postman#postman-installation) and importing the [Avalanche collection](/tooling/avalanche-go-postman-collection/setting-up-postman#collection-import), choose an API to make the call. +1. After [installing Postman](/tooling/avalanche-postman/add-postman-collection#postman-installation) and importing the [Avalanche collection](/tooling/avalanche-postman/add-postman-collection#collection-import), choose an API to make the call. 2. Make the call. 3. Click on the **Visualize** tab. 4. Now all data from the output is displayed in tabular format. diff --git a/content/docs/tooling/avalanche-postman/making-api-calls.mdx b/content/docs/tooling/avalanche-postman/making-api-calls.mdx index e13b919b032..1daa197179c 100644 --- a/content/docs/tooling/avalanche-postman/making-api-calls.mdx +++ b/content/docs/tooling/avalanche-postman/making-api-calls.mdx @@ -2,7 +2,7 @@ title: Making API Calls --- -After [installing Postman](/tooling/avalanche-go-postman-collection/setting-up-postman#setup) and importing the [Avalanche collection](/tooling/avalanche-go-postman-collection/setting-up-postman#collection-import), you can choose an API to make the call. +After [installing Postman](/tooling/avalanche-postman/add-postman-collection#setup) and importing the [Avalanche collection](/tooling/avalanche-postman/add-postman-collection#collection-import), you can choose an API to make the call. You should also make sure the URL is the correct one for the call. This URL consists of the base URL and the endpoint: @@ -14,7 +14,7 @@ The last step is to add the needed parameters for the call. For example, if a us After clicking the **Send** button, if the call is successfully, the output will be displayed in the **Body** tab. -Data visualization is available for a number of methods. Learn how to use it with the help of [this](/tooling/avalanche-go-postman-collection/data-visualization) guide. +Data visualization is available for a number of methods. Learn how to use it with the help of [this](/tooling/avalanche-postman/data-visualization) guide. ![Make Call](/images/api-call1.png) @@ -74,7 +74,7 @@ Let's say we want fetch data about this `0x20cb0c03dbbe39e934c7bb04979e3073cc2c9 We can set up an environment variable with the transaction hash as value and use it on both calls. -Find out more about variables [here](/tooling/avalanche-go-postman-collection/variables). +Find out more about variables [here](https://docs.avax.network/tooling/avalanche-postman/variables).