From 7a493a043609e9cc62ee54f755965f48249ac000 Mon Sep 17 00:00:00 2001 From: Filippo <110459737+filippoweb3@users.noreply.github.com> Date: Thu, 19 Sep 2024 09:27:13 +0200 Subject: [PATCH] edits (#6244) --- docs/build/build-client-side.md | 4 +- docs/build/build-guide.md | 8 ++-- docs/build/build-hrmp-channels.md | 8 ++-- docs/build/build-integrate-assets.md | 30 +++++++-------- docs/build/build-parachains.md | 32 ++++++++-------- docs/build/build-protocol-info.md | 2 +- docs/build/build-smart-contracts.md | 10 ++--- docs/build/build-transaction-construction.md | 2 +- docs/general/chain-state-values.md | 4 +- docs/general/contributors.md | 2 +- docs/general/faq.md | 18 ++++----- docs/general/glossary.md | 32 ++++++++-------- docs/general/how-to-dyor.md | 6 +-- docs/general/ledger.md | 10 ++--- docs/general/parity-data-dashboards.md | 2 +- docs/general/polkadot-v1.md | 10 ++--- docs/general/staking-apps.md | 4 +- docs/learn/learn-agile-coretime.md | 24 ++++++------ docs/learn/learn-architecture.md | 22 +++++------ docs/learn/learn-assets.md | 10 ++--- docs/learn/learn-auction.md | 2 +- docs/learn/learn-collator.md | 10 ++--- docs/learn/learn-comparisons-cosmos.md | 18 ++++----- docs/learn/learn-comparisons.md | 2 +- docs/learn/learn-consensus.md | 2 +- docs/learn/learn-crowdloans.md | 2 +- docs/learn/learn-guides-identity.md | 2 +- docs/learn/learn-guides-ledger.md | 2 +- docs/learn/learn-guides-treasury.md | 6 +-- docs/learn/learn-jam-chain.md | 10 ++--- docs/learn/learn-jam-faq.md | 12 +++--- docs/learn/learn-nominator.md | 2 +- docs/learn/learn-offenses.md | 2 +- docs/learn/learn-parachains-faq.md | 24 ++++++------ docs/learn/learn-parachains-protocol.md | 38 +++++++++---------- docs/learn/learn-parachains.md | 34 ++++++++--------- docs/learn/learn-runtime-upgrades.md | 2 +- docs/learn/learn-spree.md | 6 +-- docs/learn/learn-system-chains.md | 10 ++--- docs/learn/learn-transactions.md | 8 ++-- docs/learn/learn-validator.md | 12 +++--- docs/learn/learn-xcm-transport.md | 10 ++--- docs/learn/xcm/fundamentals/multiasset.md | 4 +- docs/maintain/maintain-endpoints.md | 2 +- .../maintain-guides-validator-payout.md | 4 +- 45 files changed, 233 insertions(+), 233 deletions(-) diff --git a/docs/build/build-client-side.md b/docs/build/build-client-side.md index 33229d586a4c..8ea3c9a75a7d 100644 --- a/docs/build/build-client-side.md +++ b/docs/build/build-client-side.md @@ -13,8 +13,8 @@ As with any blockchain, building decentralized applications (dApps) is a signifi developer can build on Polkadot. As an application developer, you can compose your front-end apps in a few different ways. Because -the Relay Chain and its parachains are all built using the Polkadot SDK. You can often use the same -SDK to communicate with the Relay Chain, a parachain, or any other Substrate-based chain. +the relay chain and its parachains are all built using the Polkadot SDK. You can often use the same +SDK to communicate with the relay chain, a parachain, or any other Substrate-based chain. :::note Substrate-based chains use an SS58 encoding for their address formats. diff --git a/docs/build/build-guide.md b/docs/build/build-guide.md index 2578e781c5c6..6e4b6323e3bd 100644 --- a/docs/build/build-guide.md +++ b/docs/build/build-guide.md @@ -111,7 +111,7 @@ in order to gain context about the application you could make. ## Building Parachains -Polkadot is canonically referred to as the Relay Chain. It is also considered a _layer zero_ +Polkadot is canonically referred to as the relay chain. It is also considered a _layer zero_ protocol, as it enables the interoperability and shared security of multiple [parachains](../learn/learn-parachains.md), which are _layer one_ protocols. Parachains currently connect to a relay chain using the [Parachains Protocol](../learn/learn-parachains-protocol.md). @@ -140,8 +140,8 @@ benchmarks. :::info What is an on-demand parachain? On-demand parachains use a "pay-as-you-go" model enabled by Agile Coretime to interact with the -Relay Chain. On-demand parachains will only produce a block when needed, unlike full parachains, -which have access to bulk coretime to produce a block at every block of the Relay Chain. When +relay chain. On-demand parachains will only produce a block when needed, unlike full parachains, +which have access to bulk coretime to produce a block at every block of the relay chain. When building an on-demand parachain, you will use the same tools (like PDKs) and get all the benefits of building a parachain without the cost drawback of purchasing bulk coretime. @@ -221,7 +221,7 @@ get started on building and deploying a parachain. #### Parachains Benefits Parachains contain their own runtime/STF logic and benefit from the shared security and the -cross-consensus messaging provided by the Relay Chain. Parachains permit high flexibility and +cross-consensus messaging provided by the relay chain. Parachains permit high flexibility and customization but require more effort to create and maintain over time. A production-grade parachain is typically more involved to create due to the complexity involved in blockchain networks' technical and economic aspects. diff --git a/docs/build/build-hrmp-channels.md b/docs/build/build-hrmp-channels.md index d4ef67320cb7..accc1f64b06d 100644 --- a/docs/build/build-hrmp-channels.md +++ b/docs/build/build-hrmp-channels.md @@ -8,9 +8,9 @@ slug: ../build-hrmp-channels --- In order to communicate over [HRMP](../learn/learn-xcm-transport.md#hrmp-xcmp-lite), parachains must -establish channels by registering them on the Relay Chain. Like +establish channels by registering them on the relay chain. Like [XCMP](../learn/learn-xcm-transport.md#xcmp-cross-chain-message-passing), HRMP is a message -transport protocol, but passes all messages via the Relay Chain. When XCMP is implemented on +transport protocol, but passes all messages via the relay chain. When XCMP is implemented on Polkadot, HRMP is planned to be deprecated and phased out. HRMP channels are uni-directional. Bi-directional communication between two parachains will require @@ -23,7 +23,7 @@ channel request and then the second chain accepting it. When neither chain is a [system chain](../learn/learn-system-chains.md), they will use the `hrmpInitOpenChannel` and `hrmpAcceptOpenChannel` calls, respectively. -Each chain must dispatch the following calls on the Relay Chain from its parachain origin. +Each chain must dispatch the following calls on the relay chain from its parachain origin. 1. `hrmp > hrmpInitOpenChannel(recipient, proposedMaxCapacity, proposedMaxMessageSize)`: Initiates channel establishment by creating a channel request with a given configuration. Note that the max @@ -32,7 +32,7 @@ Each chain must dispatch the following calls on the Relay Chain from its paracha 2. `hrmp > hrmpAcceptOpenChannel(sender)`: Accept the channel open request from the given sender. In order to dispatch a call from its sovereign origin, a parachain may use governance to send the -encoded call in a `Transact` instruction to the Relay Chain, but it may also execute this logic +encoded call in a `Transact` instruction to the relay chain, but it may also execute this logic autonomously (e.g. on the notification that a channel was requested). ### Examples of HRMP Channel Management diff --git a/docs/build/build-integrate-assets.md b/docs/build/build-integrate-assets.md index 0161c80ee070..b0ae902fa5fe 100644 --- a/docs/build/build-integrate-assets.md +++ b/docs/build/build-integrate-assets.md @@ -7,7 +7,7 @@ keywords: [assets, integration, api, operations] slug: ../build-integrate-assets --- -The Relay Chain does not natively support assets beyond its native token. This functionality exists +The relay chain does not natively support assets beyond its native token. This functionality exists in parachains. On both Polkadot and Kusama, this parachain is called Asset Hub. The Asset Hub provides a first-class interface for creating, managing, and using fungible and @@ -19,18 +19,18 @@ Beyond merely supporting assets, integrating an Asset Hub into your systems has infrastructure providers and users: - Support for on-chain assets. -- Significantly lower transaction fees (about 1/10) than the Relay Chain. -- Significantly lower deposits (1/100) than the Relay Chain. This includes the existential deposit +- Significantly lower transaction fees (about 1/10) than the relay chain. +- Significantly lower deposits (1/100) than the relay chain. This includes the existential deposit and deposits for proxy/multisig operations. - Ability to pay transaction fees in certain assets. As in, accounts would **not** need DOT to exist on-chain or pay fees. -The Asset Hub will use DOT as its native currency. Users can transfer DOT from the Relay Chain into -the Asset Hub and use it natively. The Relay Chain will also accept DOT transfers from the Asset Hub -back to the Relay Chain for staking, governance, or any other activity. +The Asset Hub will use DOT as its native currency. Users can transfer DOT from the relay chain into +the Asset Hub and use it natively. The relay chain will also accept DOT transfers from the Asset Hub +back to the relay chain for staking, governance, or any other activity. -Using the Asset Hub for DOT/KSM balance transfers will be much more efficient than the Relay Chain -and is highly recommended. Until domain-specific parachains are built, the Relay Chain will still +Using the Asset Hub for DOT/KSM balance transfers will be much more efficient than the relay chain +and is highly recommended. Until domain-specific parachains are built, the relay chain will still need to be used for staking and governance. ## Assets Basics @@ -71,7 +71,7 @@ transfers. Note that you can use the same addresses (except [pure proxies](../learn/learn-proxies-pure.md#anonymous-proxy-pure-proxy)!) on the Asset Hub that -you use on the Relay Chain. The SS58 encodings are the same; only the chain information (genesis +you use on the relay chain. The SS58 encodings are the same; only the chain information (genesis hash, etc.) will change on transaction construction. #### Paying Transaction Fees in Another Asset @@ -138,7 +138,7 @@ issue so a developer can help. ### Parachain Node Using the Asset Hub will require running a parachain node to sync the chain. This is very similar to -running a Relay Chain node, with the addition of some extra flags. You can follow +running a relay chain node, with the addition of some extra flags. You can follow [these guidelines](https://github.com/paritytech/polkadot-sdk/tree/master/cumulus#asset-hub-) to set up an Asset Hub node. @@ -154,7 +154,7 @@ the complete documentation, including installation guide and usage examples. ### Sidecar -API Sidecar is a REST service for Relay Chain and parachain nodes. It comes with endpoints to query +API Sidecar is a REST service for relay chain and parachain nodes. It comes with endpoints to query information about assets and asset balances on the Asset Hub. - Asset lookups always use the `AssetId` to refer to an asset class. On-chain metadata is subject to @@ -182,7 +182,7 @@ or any other critical purpose. TxWrapper Polkadot is a library designed to facilitate transaction construction and signing in offline environments. It comes with asset-specific functions to use on the Asset Hub. When -constructing parachain transactions, you can use `txwrapper-polkadot` exactly as on the Relay Chain, +constructing parachain transactions, you can use `txwrapper-polkadot` exactly as on the relay chain, but construct transactions with the appropriate parachain metadata like genesis hash, spec version, and type registry. @@ -190,11 +190,11 @@ and type registry. #### Monitoring of XCM deposits -Thanks to XCM and a growing number of parachains, the Relay Chain native token can exist across +Thanks to XCM and a growing number of parachains, the relay chain native token can exist across several blockchains, which means the providers need to monitor cross-chain transfers on top of local transfers and corresponding `balances.transfer` events. -Currently, DOT can be sent and received in the Relay Chain and in the Asset Hub either with a +Currently, DOT can be sent and received in the relay chain and in the Asset Hub either with a [Teleport](https://wiki.polkadot.network/docs/learn-teleport) from [system parachains](https://wiki.polkadot.network/docs/learn-system-chains) or with a [Reserve Backed Transfer](https://wiki.polkadot.network/docs/learn-xcm-pallet#transfer-reserve-vs-teleport) @@ -212,7 +212,7 @@ that emitted the relevant `balances.minted` event. This can be done as follows: 1. Query the relevant chain `at` the block the `balances.minted` event was emitted. 2. Filter for a `messageQueue(Processed)` event, also emitted during block initialization. This event has a parameter `Id`. The value of `Id` identifies the cross-chain message received in the - Relay Chain or in the Asset Hub. It can be used to track back the message in the origin parachain + relay chain or in the Asset Hub. It can be used to track back the message in the origin parachain if needed. Note that a block may contain several `messageQueue(Processed)` events corresponding to several cross-chain messages processed for this block. diff --git a/docs/build/build-parachains.md b/docs/build/build-parachains.md index 9b2768d87ca5..3e8230cc5c65 100644 --- a/docs/build/build-parachains.md +++ b/docs/build/build-parachains.md @@ -7,7 +7,7 @@ keywords: [build, parachain, develop, implement, PDK] slug: ../build-pdk --- -Parachains are connected to and secured by the Relay Chain. They benefit from the _pooled security_, +Parachains are connected to and secured by the relay chain. They benefit from the _pooled security_, _thought-through governance_, and overall _scalability_ of the heterogeneous sharding approach of the network. Creating a parachain can be seen as creating a **Layer-1 blockchain**, which has its own logic and runs in parallel within the Polkadot ecosystem. @@ -66,7 +66,7 @@ faced with the network constraint of processing transactions in sequence, causin #### Interoperability Any decentralised application or chain that wants to enable trustless messaging to other parachains -already connected to the Relay Chain would want to become a parachain. Interoperability between +already connected to the relay chain would want to become a parachain. Interoperability between sovereign chains involves certain constraints and complex protocols to enable across a wide breadth of chains. @@ -125,7 +125,7 @@ parachain. They can be incentivized with a native token payout from: ### Para-objects -:::info The Relay Chain can host arbitrary state machines, not just blockchains. +:::info The relay chain can host arbitrary state machines, not just blockchains. The Polkadot network will encourage the connection and interoperability between different _para-objects_. @@ -139,12 +139,12 @@ These could be in the form of: - System level chains (permanent chains): [leased slots](../learn/learn-auction.md) - [Bridge](../learn/learn-bridges.md) Hubs -- Nested Relay Chains +- Nested relay chains ### Migration Projects that are already functioning as "solochains" or in isolated environments may be interested -in migrating onto the Relay Chain as a para-object. While the parachain model has its benefits, it +in migrating onto the relay chain as a para-object. While the parachain model has its benefits, it may not be the go-to strategy for some projects. As a path for migration onto Polkadot, it may be more viable to migrate to one of the chains in one @@ -196,7 +196,7 @@ Currently, the only PDK is **[Substrate](https://substrate.io/)** is a blockchain framework that provides the basic building blocks of a blockchain (things like the networking layer, consensus, a Wasm interpreter) while providing an intuitive way to construct your runtime. Substrate is made to ease the process of -creating a new chain, but it does not provide support for Relay Chain compatibility directly. For +creating a new chain, but it does not provide support for relay chain compatibility directly. For this reason, `Cumulus`, an added _library_ contains all of the Polkadot compatibility glue code. :::note Get started with Substrate @@ -220,7 +220,7 @@ beautiful and functional. Substrate that makes it easy to make any Substrate-built runtime into a Polkadot-compatible parachain. -Cumulus Consensus is a consensus engine for Substrate that follows a Relay Chain. This runs a Relay +Cumulus Consensus is a consensus engine for Substrate that follows a relay chain. This runs a Relay Chain node internally, and dictates to the client and synchronization algorithms which chain to follow, finalize, and treat as correct. @@ -243,11 +243,11 @@ Everything else is up to the implementer of the PDK. ::: Cumulus handles the network compatibility overhead that any parachain would need to implement to be -connected to the Relay Chain. This includes: +connected to the relay chain. This includes: - Cross-chain message passing (XCMP) - Out-of-the-box Collator node setup -- An embedded full client of the Relay Chain +- An embedded full client of the relay chain - Block authorship compatibility Are you interested in building a PDK? See the [future PDKs](#future-pdks) section for details. @@ -256,21 +256,21 @@ Are you interested in building a PDK? See the [future PDKs](#future-pdks) sectio After creating your chain runtime logic with Substrate, you will be able to compile it down to a Wasm executable. This Wasm code blob will contain the entire state transition function of your -chain, and is what you will need to deploy your project to the Relay Chain as a parachain. +chain, and is what you will need to deploy your project to the relay chain as a parachain. -Validators on the Relay Chain will use the submitted Wasm code to validate the state transitions of +Validators on the relay chain will use the submitted Wasm code to validate the state transitions of your chain or thread, but doing this requires some additional infrastructure. A validator needs some -way to stay up to date with the most recent state transitions, since Relay Chain nodes will not be +way to stay up to date with the most recent state transitions, since relay chain nodes will not be required to also be nodes of your chain. This is where the collator node comes into play. A collator is a maintainer of your parachain and performs the critical action of producing new block candidates for your chain and passing them to -Relay Chain validators for inclusion in the Relay Chain. +relay chain validators for inclusion in the relay chain. Substrate comes with its own networking layer built-in but unfortunately only supports solo chains (that is, chains that do not connect to the relay chain). However, there is the Cumulus extension that includes a collator node and allows for your Substrate-built logic to be compatible with the -Relay Chain as a parachain. +relay chain as a parachain. ### Future PDKs @@ -290,7 +290,7 @@ updates** into a single on-chain update. It should be straightforward to see how this to the parachain terms. The state transition function for a roll-up-like parachain would be updating the state (in practice, most likely a Merkle tree, which would be easily verifiable) from the user inputs. The operator would act as the collator node, which would aggregate the state and -create the zk-SNARK proof that it would hand to a Relay Chain's validators for verification. +create the zk-SNARK proof that it would hand to a relay chain's validators for verification. If you or your team are interested in developing a PDK feel free to apply for a grant on the [W3F Grants Program repository](https://github.com/w3f/Grants-Program). There may be grants @@ -355,7 +355,7 @@ Then, connect your local node with Polkadot-JS Apps. ## Deploy -Substrate-based chains, including the Polkadot and Kusama Relay Chains, use an +Substrate-based chains, including the Polkadot and Kusama relay chains, use an [SS58 encoding](../learn/learn-account-advanced.md#address-format) for their address formats. [This page](https://github.com/paritytech/ss58-registry/blob/main/ss58-registry.json) serves as the canonical registry for teams to see which chain corresponds to a given prefix, and which prefixes diff --git a/docs/build/build-protocol-info.md b/docs/build/build-protocol-info.md index fb60dabd638c..55e0a83f6a2c 100644 --- a/docs/build/build-protocol-info.md +++ b/docs/build/build-protocol-info.md @@ -255,7 +255,7 @@ interface is broken/not compatible. ## Smart Contracts -The Polkadot Relay Chain does not support smart contracts, but a number of its parachains do, +The Polkadot relay chain does not support smart contracts, but a number of its parachains do, [see here for more.](./build-smart-contracts.md) ## Other F.A.Q. diff --git a/docs/build/build-smart-contracts.md b/docs/build/build-smart-contracts.md index 5a08a2654d78..90116e82d88e 100644 --- a/docs/build/build-smart-contracts.md +++ b/docs/build/build-smart-contracts.md @@ -7,7 +7,7 @@ keywords: [build, smart contract, evm, wasm] slug: ../build-smart-contracts --- -The Relay Chain which is a layer 0 blockchain, does not support smart contracts natively. However, +The relay chain which is a layer 0 blockchain, does not support smart contracts natively. However, parachains which are layer 1 blockchains are equipped with the functionality to support smart contracts. @@ -51,12 +51,12 @@ Leaving certain logic, such as complex loops that could run indefinitely, to a n layer, or even trying to eliminate it, will often be a wiser choice. Parachains try to be proactive, while smart contract platforms are event-driven. -Relay Chain and parachians typically use the _weight-fee model_ and not a _gas-metering model_. +relay chain and parachians typically use the _weight-fee model_ and not a _gas-metering model_. ## Building a Smart Contract -The Relay Chain does not natively support smart contracts. However, since the parachains that -connect to the Relay Chain can support arbitrary state transitions, they support smart contracts. +The relay chain does not natively support smart contracts. However, since the parachains that +connect to the relay chain can support arbitrary state transitions, they support smart contracts. Substrate presently supports smart contracts out-of-the-box in several ways: @@ -168,7 +168,7 @@ smart contract example? Ask us to add it to this page!** ## Smart Contract Environments -It is still early for smart contracts on the Relay Chain and the development is only now +It is still early for smart contracts on the relay chain and the development is only now stabilizing. We are actively producing content to help developers get up to speed and will maintain the Wiki with the latest resources. You should also keep up to date with the following links: diff --git a/docs/build/build-transaction-construction.md b/docs/build/build-transaction-construction.md index 5623fe3d5b96..37c0bc31fed9 100644 --- a/docs/build/build-transaction-construction.md +++ b/docs/build/build-transaction-construction.md @@ -62,7 +62,7 @@ the `metadataHash` field is empty/None. **Serialized transactions and metadata** Before being submitted, transactions are serialized. Serialized transactions are hex encoded -SCALE-encoded bytes. The Relay Chain runtimes are upgradable and therefore any interfaces are +SCALE-encoded bytes. The relay chain runtimes are upgradable and therefore any interfaces are subject to change, the metadata allows developers to structure any extrinsics or storage entries accordingly. The metadata provides you with all of the information required to know how to construct the serialized call data specific to your transaction. You can read more about the metadata, its diff --git a/docs/general/chain-state-values.md b/docs/general/chain-state-values.md index 59f8c1bb982e..ef66cdc4efbe 100644 --- a/docs/general/chain-state-values.md +++ b/docs/general/chain-state-values.md @@ -89,7 +89,7 @@ One conviction voting lock period on Polkadot equals . +The minimum number of tokens to keep an account alive on the Polkadot relay chain is . #### Inactive Issuance @@ -273,7 +273,7 @@ One conviction voting lock period on Kusama equals . +The minimum number of tokens to keep an account alive on the Kusama relay chain is . #### Inactive Issuance diff --git a/docs/general/contributors.md b/docs/general/contributors.md index 8f2e0982a790..3a1d79468604 100644 --- a/docs/general/contributors.md +++ b/docs/general/contributors.md @@ -96,7 +96,7 @@ fullest potential and focuses on making it as simple and useful to digest as pos Joe leads Technical Integrations at Web3 Foundation and was previously a Research Analyst at Parity Technologies. He focuses on making Substrate chain integration as smooth as possible, from educating users on Substrate and Polkadot fundamentals to building tools to create great user experiences and -occasionally writing a bit of code. He also hosts the [Relay Chain](https://relaychain.fm) podcast. +occasionally writing a bit of code. He also hosts the [relay chain](https://relaychain.fm) podcast. Prior to working at Parity, Joe worked in shock and vibration simulation for satellite launch, algorithmic trading, and professional cycling. He has a Bachelor of Science in Aeronautical and diff --git a/docs/general/faq.md b/docs/general/faq.md index fc741417276f..4d5d99559dfe 100644 --- a/docs/general/faq.md +++ b/docs/general/faq.md @@ -100,7 +100,7 @@ validators if they apply and fit the requirements. ### How are validators rewarded? -Validators are rewarded from the [inflation of the Relay Chain](../learn/learn-inflation.md), +Validators are rewarded from the [inflation of the relay chain](../learn/learn-inflation.md), [transaction fees](../learn/learn-transactions.md#transaction-fees), and tips. However, they only take a percentage of the former two. More details can be read on the page for [validator payouts](../maintain/maintain-guides-validator-payout.md). @@ -154,7 +154,7 @@ node can still share in staking rewards. ## Relay Chain -### What is the block time of the Relay Chain? +### What is the block time of the relay chain? Both the Kusama and Polkadot networks are currently operating at a rate of one block every six seconds. @@ -165,11 +165,11 @@ environment. ### Does Polkadot have smart contracts? -No - and yes. The Polkadot Relay Chain does not implement smart contracts natively. The reason for -not having smart contracts on the Relay Chain is part of the design philosophy for Polkadot that -dictates that the Relay Chain should be the minimal logic required to accomplish its job. +No - and yes. The Polkadot relay chain does not implement smart contracts natively. The reason for +not having smart contracts on the relay chain is part of the design philosophy for Polkadot that +dictates that the relay chain should be the minimal logic required to accomplish its job. -While the Polkadot Relay Chain does not implement smart contracts directly, there are numerous +While the Polkadot relay chain does not implement smart contracts directly, there are numerous parachains that do. It's possible for parachains to enable smart contract functionality and then benefit from the security and interoperability features of Polkadot. Additionally, existing smart contract chains can connect to Polkadot as a parachain, or via a bridge. @@ -177,7 +177,7 @@ contract chains can connect to Polkadot as a parachain, or via a bridge. So it's better to say that the Polkadot _ecosystem_ has smart contracts versus "Polkadot has smart contracts." -### How does the Polkadot Relay Chain connect to external chains in the ecosystem? +### How does the Polkadot relay chain connect to external chains in the ecosystem? One of the cornerstone interoperability technologies being researched and developed for deployment on Polkadot is cross-chain [bridges](../learn/learn-bridges.md). Bridges come in a variety of @@ -280,7 +280,7 @@ details on the subtleties of Polkadot's governance system, please see the Parachains have the flexibility to implement their own monetary system or incentive structure for collators. However, this is not strictly necessary. Since the collator's job is to continue to give -recent state transitions to the validators on the Relay Chain who validate each transition, the +recent state transitions to the validators on the relay chain who validate each transition, the security of the parachain and the Polkadot network is completely separate from parachain economics. Parachains need collators to continue to progress, so it wouldn't be unreasonable to see them incentivize collator nodes in some way, but the specific mechanism is completely up to parachain @@ -296,7 +296,7 @@ produce blocks when their usage and throughput makes it necessary. When a parachain loses an auction for renewal, that parachain has a few options. In most cases, becoming an on-demand parachain instead would be a suitable choice. On-demand parachains are still -secured by the Relay Chain, but don't need to hold a parachain slot and can produce a block when its +secured by the relay chain, but don't need to hold a parachain slot and can produce a block when its economically feasible for them. For more on parachains please see the [parachains page](../learn/learn-parachains.md#parachains-vs-on-demand-parachains). diff --git a/docs/general/glossary.md b/docs/general/glossary.md index 50be0ec9395a..41e95731d411 100644 --- a/docs/general/glossary.md +++ b/docs/general/glossary.md @@ -105,10 +105,10 @@ achieved milestones by the recipient. ## Bridge -A parachain that acts as an intermediary between the Relay Chain and an external chain, in such a -way that it appears to the Relay Chain that the external chain is a parachain (i.e., meets the +A parachain that acts as an intermediary between the relay chain and an external chain, in such a +way that it appears to the relay chain that the external chain is a parachain (i.e., meets the network Host's requirements of parachains). Bridges allow for interaction between other blockchains, -such as Ethereum and Bitcoin, that are not natively compatible with the Relay Chain. +such as Ethereum and Bitcoin, that are not natively compatible with the relay chain. ## Byzantine Fault Tolerance @@ -129,7 +129,7 @@ being referred to as a candidate as soon it has been finalized. ## Collations -Parachain blocks or candidates that are being proposed to the Relay Chain validators. More +Parachain blocks or candidates that are being proposed to the relay chain validators. More specifically, a collation is a [data structure](https://spec.polkadot.network/#defn-collation) which contains the proposed parachain candidate, including an optional validation parachain Runtime update and upward messages. @@ -190,7 +190,7 @@ network as opposed to being run on a specific system or set of systems. The native token for Polkadot. DOT serves three purposes: network governance (allowing them to vote on-chain upgrades and other exceptional events), general operation (rewarding good actors and punishing bad actors), and bonding (adding new parachains by "freezing" DOT while they are connected -the Relay Chain). +the relay chain). ## Duty Roster @@ -237,7 +237,7 @@ contain the technical knowledge base of the Kusama and/or Polkadot networks and ## Finality The property of a block that cannot be reverted. Generally, created blocks are not final until some -point in the future - perhaps never, in the case of "probabilistic finality". The Relay Chain uses a +point in the future - perhaps never, in the case of "probabilistic finality". The relay chain uses a deterministic finality gadget known as [GRANDPA](#grandpa-finality-gadget). ## Finality Gadget @@ -294,7 +294,7 @@ of the underlying blockchain and creates a new branch of _the same blockchain_. Horizontal Relay-routed Message Passing, also known as HRMP, is a precursor to the complete XCMP implementation, that mimics the same interface and semantics of XCMP. It is similar to XCMP except -for how it stores all messages in the Relay Chain storage, therefore making it more expensive and +for how it stores all messages in the relay chain storage, therefore making it more expensive and demanding more resources than XCMP. The plan is to retire HRMP once the implementation of XCMP is complete. @@ -338,7 +338,7 @@ is entirely in the hands of the community (i.e., Kusama token holders). ## Lease Period -A particular amount of time that a parachain for which the parachain can connect to the Relay Chain. +A particular amount of time that a parachain for which the parachain can connect to the relay chain. ## LIBP2P @@ -450,7 +450,7 @@ A unique numeric (non-negative integer) identifier for a parachain. Historically, the term "parathread" has been used in two contexts: a chain registered with a `ParaID` on the [relay chain](#relay-chain) that has not yet become a parachain (i.e. not connected -to a Relay Chain core), or as an on-demand parachain (i.e. a parachain using on-demand coretime) +to a relay chain core), or as an on-demand parachain (i.e. a parachain using on-demand coretime) which does not produce blocks at regular intervals. ## Parachain Registry @@ -515,7 +515,7 @@ systems limit the number of participants. A proof produced by parachain collators. Based on this proof and the parachain registry, a validator can verify that a parachain has properly executed its state transition function. Proofs of Validity -go into the Relay Chain blocks. +go into the relay chain blocks. ## Proof of Work (PoW) @@ -599,7 +599,7 @@ network to scale in capabilities (e.g. processing more transactions) when needed ## Sealing -The process of adding a block to the Relay Chain. Note that finalization is a separate process - +The process of adding a block to the relay chain. Note that finalization is a separate process - blocks are finalized sometime after they are sealed. ## Session @@ -619,7 +619,7 @@ Hot keys that are used for performing network operations by validators, for exam ## Shared Security The security model used whereby all chains are equally secured. This is achieved by placing proofs -of the validity of parachain blocks into the Relay Chain such that, in order to revert finality of a +of the validity of parachain blocks into the relay chain such that, in order to revert finality of a single parachain, an attacker would need to attack the entire system. ## Slashing @@ -719,16 +719,16 @@ send funds to Bob by the fact that she signed a transfer-funds message with her ## Validator -A node that secures the Relay Chain by staking DOT, validating proofs from collators on parachains +A node that secures the relay chain by staking DOT, validating proofs from collators on parachains and voting on consensus along with other validators. ## Vertical Message Passing Vertical message passing consists of two separate types of message passing, Downward Message Passing -(DMP) and Upward Message Passing (UMP). Downward messages pass from the Relay Chain to a parachain, +(DMP) and Upward Message Passing (UMP). Downward messages pass from the relay chain to a parachain, although they may also originate from another parachain via [HRMP](#Horizontal-Relay-routed-Message-Passing). Upward messages originate from parachains and go -up to the Relay Chain via runtime entry points. +up to the relay chain via runtime entry points. ## Voting @@ -782,7 +782,7 @@ execution. Checkout this section of the Substrate docs covering ## Westend -The [testnet](#testnet) is set aside for testing the Polkadot Relay Chain. Contrary to the +The [testnet](#testnet) is set aside for testing the Polkadot relay chain. Contrary to the [Paseo testnet](#paseo), the Westend testnet is used by the core developers to iterate on protocol-level features like [asynchronous backing](../learn/learn-async-backing.md), etc, that are not relevant for parachain developers. diff --git a/docs/general/how-to-dyor.md b/docs/general/how-to-dyor.md index 40de479c3dae..5f32798bd758 100644 --- a/docs/general/how-to-dyor.md +++ b/docs/general/how-to-dyor.md @@ -192,13 +192,13 @@ shows which projects are gathering funds from their community to participate in But not all projects that build a chain using [Substrate](https://substrate.io) aim to become a parachain. Some use it simply because of its infrastructure to build their customised chain, without -any plans to connect to the Relay Chain. And other projects may aim to become a parachain only on +any plans to connect to the relay chain. And other projects may aim to become a parachain only on Kusama or directly on Polkadot. However, building a potential parachain is not the only way to build on Polkadot and expand its ecosystem. A project might aim to build a DeFi platform on a parachain, launch a stablecoin or other token on the Asset Hub, build a decentralized exchange, or any other dApp that one might think of, -without ever touching the Relay Chain. +without ever touching the relay chain. But in all of those cases, their plans to build on Polkadot whatever they may be, should be clearly stated on their site and in their documentation. Most importantly, you should look for an @@ -210,7 +210,7 @@ This is especially true for projects that are already running on another network or Binance Smart Chain, and have issued tokens there. Many projects do that either to raise funds and test their infrastructure or because they aim to build a "multi-chain" solution or both. But because those projects are not currently built on Substrate, the existence of a clear and robust -integration plan with the Relay Chain should be essential in your research to ensure that they will +integration plan with the relay chain should be essential in your research to ensure that they will indeed build on it one day. ## _Soft_ metrics diff --git a/docs/general/ledger.md b/docs/general/ledger.md index f7137e77ee47..ca160ff4a166 100644 --- a/docs/general/ledger.md +++ b/docs/general/ledger.md @@ -95,19 +95,19 @@ App. ::: -The Polkadot Migration app is for users having **old Ledger accounts not on the Polkadot Relay Chain +The Polkadot Migration app is for users having **old Ledger accounts not on the Polkadot relay chain and [Polkadot System Chains](./glossary.md#system-parachains)**. Old Ledger accounts are accounts that have been created using the old Kusama Ledger app and any parachain Ledger apps (for both Kusama and Polkadot) except for Polkadot System Chains. -Suppose you have accounts on any Polkadot parachain, Kusama Relay Chain, and Kusama parachains. In +Suppose you have accounts on any Polkadot parachain, Kusama relay chain, and Kusama parachains. In that case, you will need the Polkadot Migration app to move fungible and non-fungible assets (NFT), identities, etc., from old Ledger accounts to a new one or an existing one created with the Polkadot Ledger app. ### Polkadot (Generic) App -The Polkadot Ledger Generic App will allow you to use your Ledger device on the Relay Chain and +The Polkadot Ledger Generic App will allow you to use your Ledger device on the relay chain and parachains without being affected by runtime upgrades. The goal is to provide a single application for the entire Polkadot ecosystem without compromising security. This new app will also count with Clear Signing, allowing you to see what you sign on a trusted display. This way, unintentionally @@ -135,8 +135,8 @@ and [Zondax beryx page](https://substrate.beryx.io/new_polkadot_ledger_app). ## Migration Process -The migration process is not meant for Polkadot Relay Chain and System Chains users. Those users can -install the Polkadot app and operate it as usual. For users of Kusama Relay Chain, Kusama System +The migration process is not meant for Polkadot relay chain and System Chains users. Those users can +install the Polkadot app and operate it as usual. For users of Kusama relay chain, Kusama System Chains and parachains, and Polkadot parachains, see the procedure below: - Install Polkadot Migration and Polkadot App. diff --git a/docs/general/parity-data-dashboards.md b/docs/general/parity-data-dashboards.md index 1dee544fa334..d8d46f9f28b6 100644 --- a/docs/general/parity-data-dashboards.md +++ b/docs/general/parity-data-dashboards.md @@ -20,7 +20,7 @@ provided are grouped into the following sections: - [Staking](https://dashboards.data.paritytech.io/staking.html) - metrics pertaining to staking, nomination pools and more. - [Ecosystem](https://dashboards.data.paritytech.io/parachains.html) - high level activity metrics - for Relay Chains and Parachains. + for relay chains and Parachains. - [Monthly Report](https://dashboards.data.paritytech.io/eoyr.html) - an updated version of the [Polkadot in Numbers: Annual Report 2023](https://dashboards.data.paritytech.io/reports/2023/index.html). diff --git a/docs/general/polkadot-v1.md b/docs/general/polkadot-v1.md index 6a993bd4c665..2f430f9a5350 100644 --- a/docs/general/polkadot-v1.md +++ b/docs/general/polkadot-v1.md @@ -49,22 +49,22 @@ initiatives: ### Polkadot's Representation -Polkadot has a Relay Chain acting as the main chain of the system. The Polkadot relay chain has been +Polkadot has a relay chain acting as the main chain of the system. The Polkadot relay chain has been represented as a ring surrounded by multiple parachains attached to it. Based on Polkadot's design, -as long as a chain's logic can compile to Wasm and adheres to the Relay Chain API, then it can +as long as a chain's logic can compile to Wasm and adheres to the relay chain API, then it can connect to the Polkadot network as a parachain. ![polkadot-relay-chain](../assets/polkadot_relay_chain.png) -Parachains construct and propose blocks to validators on the Relay Chain, where the blocks undergo +Parachains construct and propose blocks to validators on the relay chain, where the blocks undergo rigorous [availability and validity](../learn/learn-parachains-protocol.md) checks before being -added to the finalized chain. As the Relay Chain provides the security guarantees, +added to the finalized chain. As the relay chain provides the security guarantees, [collators](../learn/learn-collator.md) - full nodes of these parachains - don't have any security responsibilities, and thus do not require a robust incentive system. This is how the entire network stays up to date with the many transactions that take place. The [Cross-Consensus Messaging Format (XCM)](../learn/learn-xcm.md) allows parachains to send -messages of any type to each other. The shared security and validation logic of the Relay Chain +messages of any type to each other. The shared security and validation logic of the relay chain provide the environment for trust-free message passing that opens up true interoperability. In order to interact with chains that want to use their own finalization process (e.g. Bitcoin), diff --git a/docs/general/staking-apps.md b/docs/general/staking-apps.md index 7cbac931e647..bf672b7cb365 100644 --- a/docs/general/staking-apps.md +++ b/docs/general/staking-apps.md @@ -23,7 +23,7 @@ and add your protocol native, permissionless, non-custodial NPoS Staking app to ## Polkadot Staking Dashboard The [Polkadot Staking Dashboard](https://staking.polkadot.cloud/#/overview) is a web3 application -dedicated to native non-custodial [staking](../learn/learn-staking.md) on the Relay Chain. The +dedicated to native non-custodial [staking](../learn/learn-staking.md) on the relay chain. The dashboard allows to stake as a solo nominator or as a [nomination pool](../learn/learn-nomination-pools.md) member. Users can also create their nomination pools. The dashboard supports [Ledger](../general/ledger.md), @@ -95,7 +95,7 @@ choose their preferred validators or stake with the recommended validator set. ## NOMI [NOMI](https://apps.turboflakes.io/?app=nomi) is designed to actively involve nominators in native -staking on the Relay Chain. It aims to offer a unique and enhanced nomination experience, using +staking on the relay chain. It aims to offer a unique and enhanced nomination experience, using [Multiple-Criteria Decision Analysis](https://en.wikipedia.org/wiki/Multiple-criteria_decision_analysis) (MCDA) as a base for the analytical research. MCDA is an open and transparent approach for evaluating numerous conflicting traits in the decision-making process. For the analysis, validator diff --git a/docs/learn/learn-agile-coretime.md b/docs/learn/learn-agile-coretime.md index 227933a1d3f7..e6ea090bd148 100644 --- a/docs/learn/learn-agile-coretime.md +++ b/docs/learn/learn-agile-coretime.md @@ -76,7 +76,7 @@ reserved specifically for on-demand orders. :::info Parathreads are renamed to on-demand parachains On-demand parachains (previously called parathreads) are parachains that buy on-demand coretime and -use it to access the Relay Chain through the on-demand coretime pool. +use it to access the relay chain through the on-demand coretime pool. ::: @@ -93,7 +93,7 @@ cores on the relay chain to the parachains. ### Timeslice -A timeslice represents the granularity the Coretime Chain schedules cores on the Relay Chain. The +A timeslice represents the granularity the Coretime Chain schedules cores on the relay chain. The Coretime Chain announces a schedule for each core, comprising the next 80 relay chain blocks in advance. 5,040 timeslices corresponds to the region length of 28 days (which is the initial configuration set for bulk coretime). @@ -107,7 +107,7 @@ limited to securing parachains. Coretime is managed through the [broker pallet](https://github.com/paritytech/polkadot-sdk/blob/eefd5fe4499515da66d088505093f75b5aa22550/substrate/frame/broker/src/lib.rs) -which is deployed on the Coretime Chain. In theory, the Polkadot Relay Chain can support around a +which is deployed on the Coretime Chain. In theory, the Polkadot relay chain can support around a hundred cores seamlessly and can support over a few hundred cores through optimizations. Preliminary tests ran successfully with 80 cores with 12-second block times. @@ -144,7 +144,7 @@ these actions makes you lose the right to a price-capped renewal. With elastic scaling (still under development) projects can scale seamlessly and without being limited to previously allocated resources. Elastic scaling is the process of getting multiple cores -for one task. This allows parachains to include more blocks per unit time (Relay Chain-side), and +for one task. This allows parachains to include more blocks per unit time (relay chain-side), and produce more blocks per unit time (async backing on the parachain side). Elastic scaling can be paired with on-demand coretime to increase your bandwidth seamlessly. @@ -208,7 +208,7 @@ another one gets it at block Y. This may change in future. #### What limits are there to the number of cores? Successful tests were made with around 80 cores and 12-second block times for parachains. A single -test validator set is able to validate 80 blockchains simultaneously. In theory a single Relay Chain +test validator set is able to validate 80 blockchains simultaneously. In theory a single relay chain should be able to support a few hundred cores. Optimizations to get closer to this theoretical limit will be developed and deployed continuously. @@ -363,7 +363,7 @@ Specific benefits for decision makers and developers: coretime on secondary marketplaces. - With elastic scaling (not supported yet) projects can scale seamlessly and without being limited to previously allocated resources. Elastic scaling is the process of getting multiple cores for - one task. This allows parachains to include more blocks per unit time (Relay Chain-side), and + one task. This allows parachains to include more blocks per unit time (relay chain-side), and produce more blocks per unit time (async backing on the parachain side). With elastic scaling, add on-demand coretime to increase your bandwidth seamlessly. - Bulk coretime enables strategic resource planning: secure bulk coretime at a fixed price to @@ -390,7 +390,7 @@ Agile Coretime mainly improves allocation efficiency. With [elastic scaling](https://github.com/paritytech/polkadot-sdk/issues/1829), we take a big step towards enabling Web2 scale in Web3 by reducing parachain block production below 6 seconds. Theoretically, parachains will be able to produce blocks very fast and the limitations will lie on -the Relay Chain side’s cores and how many cores a parachain uses. +the relay chain side’s cores and how many cores a parachain uses. ### Implementation @@ -474,19 +474,19 @@ cores offered in the sales. The Coretime Chain is a proposed new system parachain within the Polkadot network that is responsible for the management of coretime. It is designed to handle the allocation of bulk coretime and track ownership of coretime as non-fungible assets (NFTs). The Coretime Chain provides -information to the Relay Chain regarding the number of cores available, the tasks running on each +information to the relay chain regarding the number of cores available, the tasks running on each core, and accounting information for on-demand coretime credit. Additionally, it processes renewals and allows for various manipulations of bulk coretime, such as transfers, partitioning, interlacing, assignment to tasks, and pooling for on-demand coretime. -#### Why are sales of on-demand coretime happening on the Relay Chain? +#### Why are sales of on-demand coretime happening on the relay chain? -In the beginning, sales are executed on the Relay Chain, but they could move to the Coretime Chain. +In the beginning, sales are executed on the relay chain, but they could move to the Coretime Chain. Latency is the only drawback: at low demand, the buyer would receive the coretime instantly when via -the Relay Chain, but there’ll be a delay when executed on the Coretime Chain. At times of high +the relay chain, but there’ll be a delay when executed on the Coretime Chain. At times of high demand, there will be a queue anyway and this delay matters less. -#### What's the best way for on-demand tasks (previously known as on-demand parachains) to regularly send extrinsics to the Relay Chain for allowing a block to be validate? +#### What's the best way for on-demand tasks (previously known as on-demand parachains) to regularly send extrinsics to the relay chain for allowing a block to be validate? A ready-to-use automated and decentralized method for ordering on-demand coretime is currently [being implemented](https://github.com/paritytech/polkadot-sdk/issues/1487). Some teams diff --git a/docs/learn/learn-architecture.md b/docs/learn/learn-architecture.md index 37f532874587..f01369c806f4 100644 --- a/docs/learn/learn-architecture.md +++ b/docs/learn/learn-architecture.md @@ -16,12 +16,12 @@ shared security and interoperability. ## Relay Chain -The Relay Chain is the central chain of +The relay chain is the central chain of {{ polkadot: Polkadot :polkadot }}{{ kusama: Kusama :kusama }}. All validators of -{{ polkadot: Polkadot :polkadot }}{{ kusama: Kusama :kusama }} are staked on the Relay Chain in DOT -and validate for the Relay Chain. The Relay Chain is composed of a relatively small number of +{{ polkadot: Polkadot :polkadot }}{{ kusama: Kusama :kusama }} are staked on the relay chain in DOT +and validate for the relay chain. The relay chain is composed of a relatively small number of transaction types that include ways to interact with the governance mechanism, parachain auctions, -and participating in NPoS. The Relay Chain has deliberately minimal functionality - for instance, +and participating in NPoS. The relay chain has deliberately minimal functionality - for instance, smart contracts are not supported. The main responsibility is to coordinate the system as a whole, including parachains. Other specific work is delegated to the parachains, which have different implementations and features. @@ -56,15 +56,15 @@ switch between being on-demand and permanent. ### [Shared Security](learn-parachains.md) Parachains connected to the {{ polkadot: Polkadot :polkadot }}{{ kusama: Kusama :kusama }} Relay -Chain all share in the security of the Relay Chain. +Chain all share in the security of the relay chain. {{ polkadot: Polkadot :polkadot }}{{ kusama: Kusama :kusama }} has a shared state between the Relay -Chain and all of the connected parachains. If the Relay Chain must revert for any reason, then all +Chain and all of the connected parachains. If the relay chain must revert for any reason, then all of the parachains would also revert. This is to ensure that the validity of the entire system can persist and no individual part is corruptible. The shared state ensures that the trust assumptions when using {{ polkadot: Polkadot :polkadot }}{{ kusama: Kusama :kusama }} parachains are only those of the -Relay Chain validator set and no other. Since the validator set on the Relay Chain is expected to be +relay chain validator set and no other. Since the validator set on the relay chain is expected to be secure with a large amount of stake put up to back it, parachains should benefit from this security. ## Interoperability @@ -83,7 +83,7 @@ reading the [specification](https://github.com/paritytech/xcm-format). A blockchain [bridge](../general/glossary.md#bridge) is a connection that allows for arbitrary data to transfer from one network to another. These chains are interoperable through the bridge but can exist as standalone chains with different protocols, rules, and governance models. In -{{ polkadot: Polkadot :polkadot }}{{ kusama: Kusama :kusama }}, bridges connect to the Relay Chain +{{ polkadot: Polkadot :polkadot }}{{ kusama: Kusama :kusama }}, bridges connect to the relay chain and are secured through the {{ polkadot: Polkadot :polkadot }}{{ kusama: Kusama :kusama }} consensus mechanism, maintained by [collators](#collators). @@ -96,7 +96,7 @@ acting as a [secure and robust] communication channel for chains in isolation. ## Validators [Validators](../general/glossary.md#validator), if elected to the validator set, produce blocks on -the Relay Chain. They also accept proofs of valid state transition from collators and receive +the relay chain. They also accept proofs of valid state transition from collators and receive staking rewards in return. Validators are required to keep enough parachain blocks available for later use in their local @@ -113,9 +113,9 @@ nominators are generally rewarded with a portion of the staking rewards from tha ## Collators -[Collators](../general/glossary.md#collator) are full nodes on both a parachain and the Relay Chain. +[Collators](../general/glossary.md#collator) are full nodes on both a parachain and the relay chain. They collect parachain transactions and produce state transition proofs for the validators on the -Relay Chain. They can also send and receive messages from other parachains using XCMP. +relay chain. They can also send and receive messages from other parachains using XCMP. Parachain blocks themselves are produced by collators, whereas the relay chain validators only verify their validity (and later, their availability). diff --git a/docs/learn/learn-assets.md b/docs/learn/learn-assets.md index 4776b9a98656..2b64f2b02a26 100644 --- a/docs/learn/learn-assets.md +++ b/docs/learn/learn-assets.md @@ -20,13 +20,13 @@ parachains can host applications dealing with assets on the Asset Hub, the hub c a trusted "home base" of assets in the network. The Asset Hub uses {{ polkadot: DOT :polkadot }}{{ kusama: KSM :kusama }} as its native token. The -chain yields its governance to its parent Relay Chain and has no inflation or era-based rewards for +chain yields its governance to its parent relay chain and has no inflation or era-based rewards for collators (although collators receive a portion of transaction fees). As a [system parachain](https://polkadot.network/blog/common-good-parachains-an-introduction-to-governance-allocated-parachain-slots/), -the Asset Hub has a trusted relationship with the Relay Chain, and as such, can teleport -{{ polkadot: DOT :polkadot }}{{ kusama: KSM :kusama }} between itself and the Relay Chain. That is, +the Asset Hub has a trusted relationship with the relay chain, and as such, can teleport +{{ polkadot: DOT :polkadot }}{{ kusama: KSM :kusama }} between itself and the relay chain. That is, {{ polkadot: DOT :polkadot }}{{ kusama: KSM :kusama }} on the Asset Hub is just as good as -{{ polkadot: DOT :polkadot }}{{ kusama: KSM :kusama }} on the Relay Chain. +{{ polkadot: DOT :polkadot }}{{ kusama: KSM :kusama }} on the relay chain. The Asset Hub does not support smart contracts. See the [Advanced](#advanced-techniques) section at the bottom for a discussion on using proxy and multisig accounts to replicate oft-used contract @@ -36,7 +36,7 @@ logic. A sufficient asset on Asset Hub can allow for an account to exist on-chain even though it does not have any account balance in {{ polkadot: DOT :polkadot }}{{ kusama: KSM :kusama }}. Any registered -asset on the Asset Hub can be made _sufficient_ through governance on the Relay Chain. A balance of +asset on the Asset Hub can be made _sufficient_ through governance on the relay chain. A balance of a non-sufficient asset can only exist on accounts that are on-chain (i.e., accounts having the [existential deposit](./learn-accounts.md#existential-deposit-and-reaping) of a sufficient asset). That is, a user could not keep an account on-chain by transferring a non-sufficient asset to it; the diff --git a/docs/learn/learn-auction.md b/docs/learn/learn-auction.md index 55fa57d15bb1..ad3cc0088434 100644 --- a/docs/learn/learn-auction.md +++ b/docs/learn/learn-auction.md @@ -16,7 +16,7 @@ For a [parachain](learn-parachains.md) to be added to parachain slots. The number of parachain slots is not unbounded on {{ polkadot: Polkadot :polkadot }}{{ kusama: Kusama :kusama }}, as only a limited number are available. A limited number of slots are unlocked every few months through on-chain governance. If a -parachain wants to have guaranteed block inclusion at every Relay Chain block, it must acquire a +parachain wants to have guaranteed block inclusion at every relay chain block, it must acquire a parachain slot. The development of [on-demand parachains](https://forum.polkadot.network/t/on-demand-parachains/2208) is complete, and they can be deployed after Agile Coretime is live on the network. diff --git a/docs/learn/learn-collator.md b/docs/learn/learn-collator.md index d6ac94893c4e..85fbba641f0f 100644 --- a/docs/learn/learn-collator.md +++ b/docs/learn/learn-collator.md @@ -18,11 +18,11 @@ can read the [Parachain Protocol Overview](./learn-parachains-protocol.md). ## Collators' Role Collators maintain parachains by collecting parachain transactions from users and producing state -transition proofs for Relay Chain validators. In other words, collators maintain parachains by +transition proofs for relay chain validators. In other words, collators maintain parachains by aggregating parachain transactions into parachain block candidates and producing state transition proofs (Proof-of-Validity, PoV) for validators. -Collators maintain a full node for the Relay Chain and a full node for their particular parachain; +Collators maintain a full node for the relay chain and a full node for their particular parachain; meaning they retain all necessary information to be able to author new blocks and execute transactions in much the same way as miners do on PoW blockchains. Under normal circumstances, they will collate and execute transactions to create an unsealed block and provide it, together with a @@ -58,7 +58,7 @@ having just one honest collator. ## XCM Collators are a key element of the [XCM (Cross-Consensus Message Passing Format)](learn-xcm.md). By -being full nodes of the Relay Chain, they are all aware of each other as peers. This makes it +being full nodes of the relay chain, they are all aware of each other as peers. This makes it possible for them to send messages from parachain A to parachain B. ## Taking the Case for One Parachain @@ -77,12 +77,12 @@ with the relay chain. The validators on the relay chain will try to reach a consensus on the block candidate. Upon reaching consensus, the now validated block candidate is shared with the validators and collators, and the process repeats for new transactions. A collator cannot continue building blocks on a -parachain until the block candidate they proposed to the Relay Chain validators have been validated. +parachain until the block candidate they proposed to the relay chain validators have been validated. A block is produced every 6 seconds. ## Collators in the Wild -Blockchains that are built using Substrate are unable to hook onto the Relay Chain on their own. The +Blockchains that are built using Substrate are unable to hook onto the relay chain on their own. The Parity team built the [Cumulus library](https://github.com/paritytech/polkadot-sdk/tree/master/cumulus/) to address this. Collators are being used on the diff --git a/docs/learn/learn-comparisons-cosmos.md b/docs/learn/learn-comparisons-cosmos.md index 79b64ea5d70f..f4f82c985706 100644 --- a/docs/learn/learn-comparisons-cosmos.md +++ b/docs/learn/learn-comparisons-cosmos.md @@ -21,9 +21,9 @@ as long as the validators on Polkadot can execute it within a Wasm environment. The shards of Polkadot are called "[parachains](learn-parachains.md)". Every time a parachain wants to make a state transition, it submits a block (batch of state transitions) along with a state proof that Polkadot validators can independently verify. These blocks are finalized for the parachains -when they are finalized by Polkadot's Relay Chain, the main chain of the system. As such, all +when they are finalized by Polkadot's relay chain, the main chain of the system. As such, all parachains share state with the entire system, meaning that a chain re-organization of a single -parachain would require a re-organization of all parachains and the Relay Chain. +parachain would require a re-organization of all parachains and the relay chain. Cosmos employs horizontal scalability using [app-chains](https://www.alchemy.com/overviews/what-is-an-appchain). The Cosmos Network consists of @@ -38,10 +38,10 @@ message is trust-bound by the recipient's trust in the security of the sender. ### Polkadot -Polkadot has a Relay Chain acting as the main chain of the system. All validators in Polkadot are on -the Relay Chain. Parachains have collators, who construct and propose parachain blocks to +Polkadot has a relay chain acting as the main chain of the system. All validators in Polkadot are on +the relay chain. Parachains have collators, who construct and propose parachain blocks to validators. Collators don't have any security responsibilities, and thus do not require a robust -incentive system. Collators can submit a single parachain block for every Relay Chain block every 6 +incentive system. Collators can submit a single parachain block for every relay chain block every 6 seconds. Once a parachain submits a block, validators perform a series of availability and validity checks before committing it to the final chain. @@ -122,12 +122,12 @@ nominating a validator does not assign any governance voting rights to the valid Polkadot uses [Cross-Consensus Message Passing Format (XCM)](learn-xcm.md) for parachains to send arbitrary messages to each other. Parachains open connections with each other and can send messages via their established channels. [Collators](learn-collator.md) are full nodes of parachains and full -nodes of the Relay Chain, so collator nodes are a key component of message passing. Messages do not -pass through the Relay Chain, only proofs of post and channel operations (open, close, etc.) go into -the Relay Chain. This enhances scalability by keeping data on the edges of the system. +nodes of the relay chain, so collator nodes are a key component of message passing. Messages do not +pass through the relay chain, only proofs of post and channel operations (open, close, etc.) go into +the relay chain. This enhances scalability by keeping data on the edges of the system. In the case of a chain re-organization, messages can be rolled back to the point of the -re-organization based on the proofs of post in the Relay Chain. The shared state amongst parachains +re-organization based on the proofs of post in the relay chain. The shared state amongst parachains means that messages are free from trust bounds; they all operate in the same context. Polkadot has an additional protocol called [SPREE](learn-spree.md) that provides shared logic for diff --git a/docs/learn/learn-comparisons.md b/docs/learn/learn-comparisons.md index e38d16f2fdd0..3e1a71bffebb 100644 --- a/docs/learn/learn-comparisons.md +++ b/docs/learn/learn-comparisons.md @@ -38,7 +38,7 @@ on a single virtual machine, called the Ethereum Virtual Machine (EVM). In logic into individual blockchains, where the interface is part of the state transition function of the blockchain itself. {{ polkadot: Polkadot :polkadot }}{{ kusama: Kusama :kusama }} will also support smart contract blockchains for Wasm and EVM to provide compatibility with existing -contracts, but will not have smart contract functionality on its core chain, the Relay Chain. +contracts, but will not have smart contract functionality on its core chain, the relay chain. As such, {{ polkadot: Polkadot :polkadot }}{{ kusama: Kusama :kusama }} is a possible augmentation and scaling method for Ethereum 1.x, rather than competition. diff --git a/docs/learn/learn-consensus.md b/docs/learn/learn-consensus.md index e8ab26a0d328..6a4660a882a3 100644 --- a/docs/learn/learn-consensus.md +++ b/docs/learn/learn-consensus.md @@ -97,7 +97,7 @@ For more details on BABE, please see the ## Finality Gadget: GRANDPA GRANDPA (GHOST-based Recursive ANcestor Deriving Prefix Agreement) is the finality gadget that is -implemented for the {{ polkadot: Polkadot :polkadot }}{{ kusama: Kusama :kusama }} Relay Chain. +implemented for the {{ polkadot: Polkadot :polkadot }}{{ kusama: Kusama :kusama }} relay chain. The {{ polkadot: Polkadot :polkadot }}{{ kusama: Kusama :kusama }} Host uses the GRANDPA Finality protocol to finalize blocks. Finality is obtained by consecutive rounds of voting by the validator diff --git a/docs/learn/learn-crowdloans.md b/docs/learn/learn-crowdloans.md index 41748da68c07..bde6d04ed9f0 100644 --- a/docs/learn/learn-crowdloans.md +++ b/docs/learn/learn-crowdloans.md @@ -147,7 +147,7 @@ It is up to individual parachain teams to decide if and how they want to reward forgo staking and choose to lock their tokens in support of the parachain’s campaign. As one can imagine, rewards will take many forms and may vary widely among projects. -If a crowdloan campaign is successful, that parachain will be on-boarded to the Relay Chain. The +If a crowdloan campaign is successful, that parachain will be on-boarded to the relay chain. The collective tokens will be locked in that parachain's account for the entire duration that it is active. diff --git a/docs/learn/learn-guides-identity.md b/docs/learn/learn-guides-identity.md index f4512a01483e..7fe576b5e70f 100644 --- a/docs/learn/learn-guides-identity.md +++ b/docs/learn/learn-guides-identity.md @@ -14,7 +14,7 @@ import MessageBox from "../../components/MessageBox"; import "../../components/M [Polkadot Support Team](https://support.polkadot.network/support/home). For more user-friendly tools see the [wallets](./wallets-index), [apps](./apps-index) and [dashboard](./dashboards-index) pages." /> -:::warning The identity pallet is no longer on the Kusama Relay Chain. +:::warning The identity pallet is no longer on the Kusama relay chain. If you are on **Kusama**, any of the extrinsics which require you to use the relay chain now have to be called via the system parachain, diff --git a/docs/learn/learn-guides-ledger.md b/docs/learn/learn-guides-ledger.md index 82fd229be69e..90fd2930e419 100644 --- a/docs/learn/learn-guides-ledger.md +++ b/docs/learn/learn-guides-ledger.md @@ -121,7 +121,7 @@ The easiest way to get your address is to click on the account name. This will o showing your address and other information, such as on-chain identity. Another method is just clicking on your account's avatar icon - this immediately copies your address to the clipboard. -:::note Your Asset Hub address is the same as your Relay Chain address +:::note Your Asset Hub address is the same as your relay chain address Make sure that you clarify to the sender that you wish to receive your tokens on the Asset Hub parachain, otherwise (if you're receiving {{ polkadot: DOT :polkadot }}{{ kusama: KSM :kusama }} diff --git a/docs/learn/learn-guides-treasury.md b/docs/learn/learn-guides-treasury.md index 679835eb8314..ce1dce6d30aa 100644 --- a/docs/learn/learn-guides-treasury.md +++ b/docs/learn/learn-guides-treasury.md @@ -58,7 +58,7 @@ and is You may notice that the Treasury pallet contains two extrinsics - `treasury.spend` and `treasury.spendLocal`. `treasury.spendLocal` (formally called `treasury.spend`) refers to a spend of -DOT that is locally available, i.e., DOT from the Relay Chain's treasury account. `spend` actually +DOT that is locally available, i.e., DOT from the relay chain's treasury account. `spend` actually allows the caller to specify an asset other than DOT, or even assets in other locations, e.g. [Asset Hub](../general/glossary.md#asset-hub). @@ -216,7 +216,7 @@ Now, let's go through each field one-by-one and fill them in accordingly: - The relative location of the asset, and - How it is identified within this location. -For this example, we are using USDT, which from the perspective of the Relay Chain would be: +For this example, we are using USDT, which from the perspective of the relay chain would be: `Parachain 1000 (AssetHub) > AssetId (Concrete) > PalletInstance 50 > General Index 1984` @@ -267,7 +267,7 @@ an account address on the chain. ### Specifying `validFrom` (optional) -The `validFrom` field is optional, and refers to the block height of the Relay Chain upon which the +The `validFrom` field is optional, and refers to the block height of the relay chain upon which the payout can be issued. If the `validFrom` parameter is not set, the spend can be paid out immediately after approval. For more information on this field, refer to the [guide below](#creating-a-staged-proposal-with-validfrom). diff --git a/docs/learn/learn-jam-chain.md b/docs/learn/learn-jam-chain.md index 3ab29e6c61db..b29b245d62af 100644 --- a/docs/learn/learn-jam-chain.md +++ b/docs/learn/learn-jam-chain.md @@ -43,7 +43,7 @@ been doing for the last five years, it is already a highly domain-specific roll- essentially makes it less opinionated and more generic. The JAM chain accepts outputs of roll-ups, in more general terms, bits of computation done -elsewhere, and integrates the outputs into a shared state, similarly to how the Polkadot Relay Chain +elsewhere, and integrates the outputs into a shared state, similarly to how the Polkadot relay chain functions. The job of the JAM chain is to provide the necessary apparatus to ensure that the output correctly @@ -287,7 +287,7 @@ current setup. ## Architectural Differences: JAM vs. Relay Chain -One of the architectural distinctions between JAM and the Relay Chain lies in the degree to which +One of the architectural distinctions between JAM and the relay chain lies in the degree to which functionality is fixed. While the relay chain fixes certain elements, such as the language used to define the protocol (WASM), JAM goes further in this regard. For instance, it dictates the type used for encoding the block header and the hashing scheme, making alterations to these aspects @@ -311,7 +311,7 @@ reasons support this decision: Despite these differences, JAM retains flexibility in application-level functionalities, such as coretime sales, staking, and governance, all managed within services. Additionally, JAM introduces a novel concept by associating a token balance with a service, providing opportunities for economic -model adjustments that are not easily achievable in purely upgradable chains like the Relay Chain. +model adjustments that are not easily achievable in purely upgradable chains like the relay chain. ## JAM Toaster @@ -320,7 +320,7 @@ establishing a comprehensive test environment for the JAM chain. Unlike small-sc running on unreliable hardware to manage cloud computing costs, this initiative entails a substantial investment. Introducing the JAM toaster, essentially a test platform designed for conducting large-scale trials and performance assessments of JAM. This addresses a prior challenge -encountered during the development of the Polkadot Relay Chain, where understanding the emergent +encountered during the development of the Polkadot relay chain, where understanding the emergent effects and dynamics of operating a network at such scale proved difficult. Previous attempts were limited to a few dozen nodes on a test network and the Kusama network, which lacks comprehensive monitoring capabilities due to restrictions on accessing validator nodes. Conversely, the @@ -352,7 +352,7 @@ within the relay chain, there's a provision for passing more data via a candidat be practical if all parachains transmitted all data all the time. JAM adheres strictly to rules, even for parachain services, including limitations on data transmission between the "refine" and "accumulate" phases. Currently, with -[Horizontal Relay Chain Message Passing (HRMP)](./learn-xcm-transport.md#hrmp-xcmp-lites), all +[Horizontal relay chain Message Passing (HRMP)](./learn-xcm-transport.md#hrmp-xcmp-lites), all messages traverse the relay chain, constraining the data payload to 4 kB or less, which might not be realistic. Thus, XCMP, where only message headers are relayed via the chain while the actual message data is transmitted off-chain, emerges as a necessary and overdue improvement. diff --git a/docs/learn/learn-jam-faq.md b/docs/learn/learn-jam-faq.md index 5f0a999fd6cc..2d5521ee870d 100644 --- a/docs/learn/learn-jam-faq.md +++ b/docs/learn/learn-jam-faq.md @@ -80,17 +80,17 @@ the network's integrity and security. ## Is JAM related to Polkadot? -Yes, JAM is a potential candidate for evolving the Polkadot Relay Chain. The key change is that -parachains are no longer enshrined on the Relay Chain and will be running on top of a service that +Yes, JAM is a potential candidate for evolving the Polkadot relay chain. The key change is that +parachains are no longer enshrined on the relay chain and will be running on top of a service that is compatible with parachain protocol. One service will be, for example, the current parachains service. Anyone can permissionlessly add a service to the JAM Chain by specifying the entry points Refine, Accumulate and onTransfer. ## How would the Relay Chain change with JAM? -JAM would be a successor to the Relay Chain, with a more straightforward and flexible architecture. +JAM would be a successor to the relay chain, with a more straightforward and flexible architecture. Only the consensus functionality would be kept, while the rest, such as security, governance, etc., -would run on system-level services. The current Relay Chain will run on multiple cores in the new +would run on system-level services. The current relay chain will run on multiple cores in the new JAM architecture, guaranteeing full compatibility. ## In the new architecture, what does the tech stack look like? @@ -125,11 +125,11 @@ feedback and iterates on it. ## What about Polkadot? Will there be a hard fork? -JAM isn’t a successor to Polkadot but a potential evolution of the Polkadot Relay Chain. It can only +JAM isn’t a successor to Polkadot but a potential evolution of the Polkadot relay chain. It can only proceed if it passes through Polkadot’s decentralized governance system, winning approval from token holders. The current parachain-centered logic would continue as a service on top of the new JAM architecture. Part of the proposal will include tooling and hard-coded compatibility guarantees. The -Relay Chain will upgrade, and parachains can then enjoy a much richer environment, synchronous +relay chain will upgrade, and parachains can then enjoy a much richer environment, synchronous compatibility, and excellent scaling capabilities better than current L2s but built inside the L0/L1 layer. diff --git a/docs/learn/learn-nominator.md b/docs/learn/learn-nominator.md index 2dbd08198ab9..5d95584cfda8 100644 --- a/docs/learn/learn-nominator.md +++ b/docs/learn/learn-nominator.md @@ -77,7 +77,7 @@ being [slashed](./learn-offenses.md) if the validator gets slashed. - By getting [staking](./learn-staking.md) rewards you keep up with or (likely) stay ahead of {{ polkadot: Polkadot :polkadot }}{{ kusama: Kusama :kusama }} inflation. -Nominators secure the Relay Chain by staking {{ polkadot: DOT :polkadot }}{{ kusama: KSM :kusama }} +Nominators secure the relay chain by staking {{ polkadot: DOT :polkadot }}{{ kusama: KSM :kusama }} and nominating validators. You may have an account with {{ polkadot: DOT :polkadot }}{{ kusama: KSM :kusama }} and want to earn fresh {{ polkadot: DOT :polkadot }}{{ kusama: KSM :kusama }}. You could do so as a validator, which diff --git a/docs/learn/learn-offenses.md b/docs/learn/learn-offenses.md index e2d338a4feb7..f0d47d36ff09 100644 --- a/docs/learn/learn-offenses.md +++ b/docs/learn/learn-offenses.md @@ -53,7 +53,7 @@ offenses as shown below. - **Equivocation:** A validator produces two or more of the same block or vote. - GRANDPA and BEEFY Equivocation: A validator signs two or more votes in the same round on different chains. - - BABE Equivocation: A validator produces two or more blocks on the Relay Chain in the same time + - BABE Equivocation: A validator produces two or more blocks on the relay chain in the same time slot. - **Double Seconded Equivocation:** Within a backing group of 5 para-validators, at most 5 backed parablocks are possible. Each parablock requires exactly one seconded and at least two more valid diff --git a/docs/learn/learn-parachains-faq.md b/docs/learn/learn-parachains-faq.md index 3cc207a3cda5..e85bdd98a068 100644 --- a/docs/learn/learn-parachains-faq.md +++ b/docs/learn/learn-parachains-faq.md @@ -16,8 +16,8 @@ import MessageBox from "../../components/MessageBox"; import "../../components/M ### What is "parachain consensus"? "Parachain consensus" is special in that it will follow the {{ polkadot: Polkadot :polkadot }} -{{ kusama: Kusama :kusama }} Relay Chain. Parachains cannot use other consensus algorithms that -provide their own finality. Only sovereign chains (that must bridge to the Relay Chain via a +{{ kusama: Kusama :kusama }} relay chain. Parachains cannot use other consensus algorithms that +provide their own finality. Only sovereign chains (that must bridge to the relay chain via a parachain) can control their own consensus. Parachains have control over how blocks are authored and by whom. {{ polkadot: Polkadot :polkadot }} {{ kusama: Kusama :kusama }} guarantees valid state transitions. Executing a block finality outside the context of the relay chain is outside the scope @@ -41,7 +41,7 @@ Substrate-based. No.{{ polkadot: Polkadot :polkadot }} {{ kusama: Kusama :kusama }} network went through a significant number of optimizations, and there are [several updates planned](https://polkadot.network/blog/polkadot-roadmap-roundup/) in the near -future. The exact number of parachains that the Relay Chain can support without any degradation in +future. The exact number of parachains that the relay chain can support without any degradation in performance is yet to be discovered. Also, with the [blockspace over blockchains](https://www.rob.tech/polkadot-blockspace-over-blockchains/) paradigm which brings on-demand parachains into the picture, there is no hard limit number on the number of @@ -67,10 +67,10 @@ validator group again. If anywhere from 30% to 50% of the validators go offline, availability will suffer because we need two-thirds of the validator set to back the parachain candidates. In other words, all parachains will stop until the situation is resolved. Finality will also stop, but low-value transactions on -the Relay Chain should be safe enough to execute, despite common forks. Once the required number of +the relay chain should be safe enough to execute, despite common forks. Once the required number of validators are in the validator set again, parachains will resume block production. -Given that collators are full nodes of the Relay Chain and the parachain they are running, they will +Given that collators are full nodes of the relay chain and the parachain they are running, they will be able to recognize a disruption as soon as it occurs and should stop producing block candidates. Likewise, it should be easy for them to recognize when it's safe to restart block production - perhaps based on finality delay, validator set size or some other factor that is yet to be decided @@ -87,7 +87,7 @@ content](../build/build-parachains.md#parachain-development-kit-pdk) and ### Is security correlated to the number of validators? What about the number of parachains? -Security is independent of the number of parachains that are connected to the Polkadot Relay Chain. +Security is independent of the number of parachains that are connected to the Polkadot relay chain. The correlation of security and the number of validators exists as the higher number of validators will give the network stronger decentralization properties and make it harder to try to take down. However, the biggest indicator of the security of the network is the economic signal of the number @@ -97,16 +97,16 @@ nominators, the higher the minimum amount of DOT an attacker would need to acqui ### In what scenarios do parachains need their own security? Most parachains will not need to worry about their own security, since all state transitions will be -secured by the Polkadot Relay Chain validator set. However, in some cases (which are considered more +secured by the Polkadot relay chain validator set. However, in some cases (which are considered more experimental), parachains may require their own security. In general, these cases will revolve -around lack of data available to Relay Chain validators. +around lack of data available to relay chain validators. One example is if the state transition function is some succinct or zero-knowledge proof, the -parachain would be responsible for keeping its data available as the Relay Chain won't have it. +parachain would be responsible for keeping its data available as the relay chain won't have it. Additionally, for chains with their own consensus, like the one that enables fast payments on [Blink Network](https://www.youtube.com/watch?v=sf5GMDlG7Uk), there would probably need to be a Byzantine agreement between stakers before a parachain block is valid. The agreement would be -necessary because the data associated with the fast consensus would be unknown to Relay Chain +necessary because the data associated with the fast consensus would be unknown to relay chain validators. ## Slot Auctions @@ -115,7 +115,7 @@ validators. Parachain slots are acquirable through auction. For more information on the auction process, please see the [parachain slot auctions](learn-auction.md) article. Additionally, parachains will be able -to access the Relay Chain [on-demand](./learn-parachains.md#on-demand-parachains). +to access the relay chain [on-demand](./learn-parachains.md#on-demand-parachains). ### Why doesn't everyone bid for the max length? @@ -155,7 +155,7 @@ that are locked up to another buyer. This would allow the seller to get liquid t for the parachain slot and the buyer to acquire the slot as well as the deposited tokens. A number of system or common-good parachains may be granted slots by the -[governance](./learn-polkadot-opengov.md) of the Relay Chain. System parachains can be recognized by +[governance](./learn-polkadot-opengov.md) of the relay chain. System parachains can be recognized by a parachain ID lower than 1_000, and common-good parachains by a parachain ID between 1_000 and 1_999. Other parachains will have IDs 2_000 or higher. Such parachains would not have to bid for or renew their slots as they would be considered essential to the ecosystem's future. diff --git a/docs/learn/learn-parachains-protocol.md b/docs/learn/learn-parachains-protocol.md index a0dabb009534..f96e89797195 100644 --- a/docs/learn/learn-parachains-protocol.md +++ b/docs/learn/learn-parachains-protocol.md @@ -76,7 +76,7 @@ The parachain protocol is divided into two main phases: - [**Inclusion Pipeline**](#inclusion-pipeline): Collators send parachain blocks (parablocks) with PoV to Validators. Validators verify if the parablocks follow the state transition rules of the parachain and sign statements that can have a positive or negative outcome. With enough positive - statements, the block is **backed** and **included** in the Relay Chain, but is still pending + statements, the block is **backed** and **included** in the relay chain, but is still pending approval. - [**Approval Process**](#approval-process): Validators perform additional checks that, if positive, allow the parablock to be **approved**. @@ -91,7 +91,7 @@ Approval Process. The Availability and Validity (AnV) Protocol is a way of looking at the Parachain Protocol from another perspective, emphasizing the importance of a parablock being available and valid before -being included in the finalized Relay Chain. It is divided into five different phases, three within +being included in the finalized relay chain. It is divided into five different phases, three within the [Inclusion Pipeline](#inclusion-pipeline) and two within the [Approval Process](#approval-process): @@ -111,7 +111,7 @@ Process a parablock is checked if it is valid or not. ### Overview The inclusion pipeline is the path of a parachain block (or parablock) from its creation to its -inclusion into the non-finalized Relay Chain (i.e. in a fork of the Relay Chain). +inclusion into the non-finalized relay chain (i.e. in a fork of the relay chain). ![parachain-inclusion-pipeline](../assets/parachain-inclusion-pipeline.png) @@ -129,10 +129,10 @@ changes its status through this path as follows: is shown as white square with a white tick mark and three yellow tick marks on top of it. The yellow marks show the PoV from the para-validators, while the white mark the PoV from the collator. -- Backed: The block is backed and noted in a fork on the Relay Chain by a relay chain block author +- Backed: The block is backed and noted in a fork on the relay chain by a relay chain block author (in this case V4). The backed block is shown as a square with white background and yellow border - enclosing a "B". The backed block can still fail to be included in the Relay Chain. Note that for - simplicity here the backed parachain block is represented within the Relay Chain block, but in + enclosing a "B". The backed block can still fail to be included in the relay chain. Note that for + simplicity here the backed parachain block is represented within the relay chain block, but in reality a relay chain block does not contain the parablocks themselves (more about this later). - Pending availability: The block is backed but not considered available yet. - Included: The block is backed and considered available (we have a parablock). Included parablocks @@ -170,7 +170,7 @@ Once a para-validator has the PoV, it gossips this information to the other para check the candidate block against the PoV. Candidates that gather more than half of signed validity statements are considered **backable** (i.e. they _seem_ to represent a valid state transition), and their backing is the set of signed statements. The para-validators can then start to construct the -[**candidate receipt**](#candidate-receipts) (this is what goes into the Relay Chain block) and an +[**candidate receipt**](#candidate-receipts) (this is what goes into the relay chain block) and an [**erasure coding**](#erasure-codes) (this is what will make the parablock available, more on this later on) that will be sent to all validators in the network. @@ -188,16 +188,16 @@ parablock is fully valid. ### Relay Chain Submission Phase -The [receipt](#candidate-receipts) of the backable parablock is added to the Relay Chain transaction +The [receipt](#candidate-receipts) of the backable parablock is added to the relay chain transaction queue together with other receipts from other parachains. Receipts are gossiped around, and when a relay chain block author wins [BABE](./learn-consensus.md#block-production-babe) slot leadership, it -will select a candidate receipt to include in a block on a fork of the Relay Chain. +will select a candidate receipt to include in a block on a fork of the relay chain. A block author can note up to 1 backable candidate for each parachain to be included in the Relay -Chain block alongside its backing. Once included in a fork of the Relay Chain the candidate is +Chain block alongside its backing. Once included in a fork of the relay chain the candidate is considered **backed** in that fork. The candidate is considered to be in **"pending availability"** status, and it can only be considered a part of the parachain once proven available. Remember, at -this stage validators of the Relay Chain already received the +this stage validators of the relay chain already received the [erasure coding information](#erasure-codes) of that specific parablock. ### Availability and Unavailability Phase @@ -207,7 +207,7 @@ Distribution Subsystem** to ensure availability of the candidate. They gossip th [erasure coded](#erasure-codes) pieces among the network. At least 1/3 + 1 validators must report that they possess their piece of the code word. Once this threshold of validators has been reached, the network can consider the candidate block available. The block is graduated to being a full -parachain block, and its header will be included in that fork of the Relay Chain. The information +parachain block, and its header will be included in that fork of the relay chain. The information about the candidate availability is noted in the subsequent relay chain blocks of that fork. The availability check by the block author ensures that @@ -243,7 +243,7 @@ The candidate can fail to be included in the parachain in any of the following w - The candidate is not backed by validators participating in the Candidate Backing subsystem. - A relay chain block author does not select the candidate. - The candidate's PoV is not considered available within a timeout, and the block is discarded from - the Relay Chain. + the relay chain. ## Approval Process @@ -301,7 +301,7 @@ The result of the dispute must be transplantable to all other forks so that mali slashed in all possible histories and so that honest validators will ignore any forks containing that parablock. -:::info Parablocks vs. Relay Chain Blocks +:::info Parablocks vs. relay chain Blocks It is important to understand that a relay chain block does not contain parablocks, but para-headers. Parachain blocks are within the parachain. Thus, it makes more sense to think of @@ -386,9 +386,9 @@ For detailed information about chain selection, see dedicated section in ## Candidate Receipts -PoV are typically between 1 MB and 10 MB in size and are not included in the Relay Chain blocks. For +PoV are typically between 1 MB and 10 MB in size and are not included in the relay chain blocks. For {{ polkadot: Polkadot :polkadot }}{{ kusama: Kusama :kusama }} to scale to hundreds of parachains, -PoV need to be represented by something smaller on the Relay Chain: candidate receipts. A +PoV need to be represented by something smaller on the relay chain: candidate receipts. A para-validator constructs a candidate receipt for a parachain block by signing: - The parachain ID. @@ -406,7 +406,7 @@ transition contained inside of it. ## Erasure Codes -Before sending the candidate receipt to the Relay Chain transaction queue, the para-validator who +Before sending the candidate receipt to the relay chain transaction queue, the para-validator who constructs the receipt must also construct an erasure coding of the parachain block. An erasure coding takes a message (in this case, the parachain block and PoV) and creates a set of @@ -417,7 +417,7 @@ total number of smaller messages is equal to the total number of validators and The para-validator creates the erasure coding chunks, puts them into their Merkle tree, and sends out each chunk (together with the candidate receipt) to a corresponding validator on the Relay Chain. Validators who receive the receipts with an erasure coding chunk will include the receipt in -the Relay Chain queue, where an author can include it in a block. +the relay chain queue, where an author can include it in a block. The type of erasure codes used by {{ polkadot: Polkadot :polkadot }}{{ kusama: Kusama :kusama }}'s availability scheme are @@ -448,7 +448,7 @@ include something invalid is caught and the offending validators are punished. False positives can happen; those actors responsible for it will be [slashed](./learn-offenses.md). To detect false positives, PoV information must be available after the block has been included to -the Relay Chain via the [availability scheme](#availability-and-unavailability-phase). +the relay chain via the [availability scheme](#availability-and-unavailability-phase). Disputes are _independent from a particular fork_, while backing and approval operate on particular forks. The approval voting stops if an alternative fork (which might not contain the diff --git a/docs/learn/learn-parachains.md b/docs/learn/learn-parachains.md index c269ed64f702..8b4897c886f5 100644 --- a/docs/learn/learn-parachains.md +++ b/docs/learn/learn-parachains.md @@ -24,8 +24,8 @@ on the parachain development guide. ## Definition of a Parachain A parachain is an application-specific data structure that is globally coherent and can be validated -by the validators of the Relay Chain. They take their name from the concept of parallelized chains -that run parallel to the Relay Chain. Most commonly, a parachain will take the form of a blockchain, +by the validators of the relay chain. They take their name from the concept of parallelized chains +that run parallel to the relay chain. Most commonly, a parachain will take the form of a blockchain, but there is no specific need for them to be actual blockchains. ![One parachain](../assets/one-parachain.png) @@ -37,7 +37,7 @@ parachains through the [XCM](learn-xcm.md) format. Parachains are maintained by a network maintainer known as a [collator](learn-collator.md). The role of the collator node is to maintain a full node of the parachain, retain all necessary information -about the parachain, and produce new block candidates to pass to the Relay Chain validators for +about the parachain, and produce new block candidates to pass to the relay chain validators for verification and inclusion in the shared state of {{ polkadot: Polkadot. :polkadot }}{{ kusama: Kusama. :kusama }} The incentivization of a collator node is an implementation detail of the parachain. They are not required to be staked on the Relay @@ -64,10 +64,10 @@ looking at the new values and the paths that are affected within the tree. The {{ polkadot: Polkadot :polkadot }}{{ kusama: Kusama :kusama }} Host requires that the state transitions performed on parachains be specified as a [Wasm](learn-wasm.md) executable. Proofs of new state transitions that occur on a parachain must be validated against the registered state -transition function (STF) that is stored on the Relay Chain by the validators before +transition function (STF) that is stored on the relay chain by the validators before {{ polkadot: Polkadot :polkadot }}{{ kusama: Kusama :kusama }} acknowledges a state transition has occurred on a parachain. The key constraint regarding the logic of a parachain is that it must be -verifiable by the Relay Chain validators. Verification most commonly takes the form of a bundled +verifiable by the relay chain validators. Verification most commonly takes the form of a bundled proof of a state transition known as a Proof-of-Verification (PoV) block, which is submitted for checking to the validators from one or more parachain collators. @@ -113,8 +113,8 @@ Shared security, sometimes referred as _pooled security_, is one of the unique v for chains considering becoming a [parachain](learn-parachains.md) and joining the {{ polkadot: Polkadot :polkadot }}{{ kusama: Kusama :kusama }} network. On a high level, shared security means that all parachains that are connected to the -{{ polkadot: Polkadot :polkadot }}{{ kusama: Kusama :kusama }} Relay Chain by leasing a parachain -slot will benefit from the economic security provided by the Relay Chain +{{ polkadot: Polkadot :polkadot }}{{ kusama: Kusama :kusama }} relay chain by leasing a parachain +slot will benefit from the economic security provided by the relay chain [validators](learn-validator.md). The notion of shared security is different from inter-chain protocols that build on an architecture @@ -130,7 +130,7 @@ recently ( two more 51% attacks on ETC. {{ polkadot: Polkadot :polkadot }}{{ kusama: Kusama :kusama }} overcomes security scalability -concerns since it gravitates all the economic incentives to the Relay Chain and allows the +concerns since it gravitates all the economic incentives to the relay chain and allows the parachains to tap into stronger guarantees at genesis. Sovereign chains must expend much more effort to grow the value of their coin so that it is sufficiently secure against well-funded attackers. @@ -176,7 +176,7 @@ ways to incentivize the collator nodes that do not involve inflating the native Transaction fees in a native parachain token can also be an implementation choice of parachains. {{ polkadot: Polkadot :polkadot }}{{ kusama: Kusama :kusama }} makes no hard and fast rules for how the parachains decide on the original validity of transactions. For example, a parachain may be -implemented so that transactions must pay a minimum fee to collators to be valid. The Relay Chain +implemented so that transactions must pay a minimum fee to collators to be valid. The relay chain will enforce this validity. Similarly, a parachain could not include that in their implementation, and {{ polkadot: Polkadot :polkadot }}{{ kusama: Kusama :kusama }} would still enforce its validity. @@ -195,7 +195,7 @@ There are two ways to allocate parachain slots on {{ polkadot: Polkadot :polkadot }}{{ kusama: Kusama :kusama }}'s on-chain [governance](./learn-polkadot-opengov.md) and are part of the network's protocol, such as bridges to other networks or chains. These typically do not have an economic model and help remove transactions -from the Relay Chain, allowing for more efficient parachain processing. +from the relay chain, allowing for more efficient parachain processing. [Auction granted parachains](learn-auction.md) are granted in a permissionless auction. Parachain teams can either bid with their own {{ polkadot: DOT :polkadot }}{{ kusama: KSM :kusama }} tokens, @@ -211,7 +211,7 @@ of a parathread (i.e., a chain with a registered `ParaID` but has no access to a ## System Parachains [System parachains](./learn-system-chains.md) are parachains that use execution cores allocated by -the network's governance. These chains remove transactions from the Relay Chain, allowing network +the network's governance. These chains remove transactions from the relay chain, allowing network validators to allocate resources to validating parachains. System chains are Polkadot using its scaling technology to host itself. @@ -238,7 +238,7 @@ would not be able to acquire a full parachain slot or do not find it economicall can participate in {{ polkadot: Polkadot :polkadot }}{{ kusama: Kusama :kusama }}'s shared security as the [on-demand coretime](./learn-agile-coretime.md#on-demand-coretime) offers a graceful off-ramp to parachains that no longer require a dedicated parachain slot, but would like to continue using -the Relay Chain. +the relay chain. ### Historical Context of On-demand parachains @@ -257,8 +257,8 @@ that a chain developed with Substrate can at different points in its lifetime as states: - an independent chain with secured bridge, -- a parachain continuously connected to the Relay Chain, -- or a parachain intermittently connected to the Relay Chain (i.e. on-demand) +- a parachain continuously connected to the relay chain, +- or a parachain intermittently connected to the relay chain (i.e. on-demand) It can switch between these states with relatively minimal effort since the difference is more of an economic distinction than a technological one. @@ -381,8 +381,8 @@ maintain the stronger property of single block composability. - [Polkadot: The Parachain](https://medium.com/polkadot-network/polkadot-the-parachain-3808040a769a) - Blog post by Polkadot co-founder Rob Habermeier who introduced parachains in 2017 as "a simpler - form of blockchain, which attaches to the security provided by a Relay Chain rather than providing - its own. The Relay Chain provides security to attached parachains, but also provides a guarantee + form of blockchain, which attaches to the security provided by a relay chain rather than providing + its own. The relay chain provides security to attached parachains, but also provides a guarantee of secure message-passing between them." - [The Path of a Parachain Block](https://polkadot.network/the-path-of-a-parachain-block/) - A - technical walk-through of how parachains interact with the Relay Chain. + technical walk-through of how parachains interact with the relay chain. diff --git a/docs/learn/learn-runtime-upgrades.md b/docs/learn/learn-runtime-upgrades.md index 30aa31f1feec..796e33214193 100644 --- a/docs/learn/learn-runtime-upgrades.md +++ b/docs/learn/learn-runtime-upgrades.md @@ -148,7 +148,7 @@ Polkadot Fellowship's changes in the runtime logic. Runtime upgrades are voted on and executed via [Polkadot OpenGov](./learn-polkadot-opengov.md). You -should monitor the Relay Chain as follows to know when the next runtime upgrade will be enacted: +should monitor the relay chain as follows to know when the next runtime upgrade will be enacted: 1. Check each block for `referenda (Submitted)` events and check if the `track` is `0` or `1`, which correspond to the `Root` and `whitelistedCaller` tracks, respectively. These are the only tracks diff --git a/docs/learn/learn-spree.md b/docs/learn/learn-spree.md index 13ec763f3509..2b516352df67 100644 --- a/docs/learn/learn-spree.md +++ b/docs/learn/learn-spree.md @@ -10,7 +10,7 @@ slug: ../learn-spree Shared Protected Runtime Execution Enclaves (SPREE) sometimes referred to as "trust wormholes," are fragments of logic comparable to runtime modules in Substrate, but live on the -{{ polkadot: Polkadot :polkadot }}{{ kusama: Kusama :kusama }} Relay Chain and maybe opted into by +{{ polkadot: Polkadot :polkadot }}{{ kusama: Kusama :kusama }} relay chain and maybe opted into by parachains. SPREE in brief was described with the following properties and functions: @@ -29,7 +29,7 @@ On 28 March, 2019 u/Tawaren, a member of the Polkadot community, made a post on [Smart Protocols](https://www.reddit.com/r/dot/comments/b6kljn/smartprotocols_idea/). The core insight of the post was that XCMP had a complication in that it was difficult to verify and prove code was executed on a parachain without trust. A solution was to install the SmartProtocols in the -Relay Chain that would be isolated blobs of code with their own storage per instance that could only +relay chain that would be isolated blobs of code with their own storage per instance that could only be changed through an interface with each parachain. SmartProtocols are the precursor to SPREE. ## What is a SPREE module? @@ -86,7 +86,7 @@ The diagram above is a simplification of the {{ polkadot: Polkadot :polkadot }}{{ kusama: Kusama :kusama }} system. In this diagram, we see that the Wasm code for SPREE module "X" has been uploaded to the -{{ polkadot: Polkadot :polkadot }}{{ kusama: Kusama :kusama }} Relay Chain. The two cylinders "A" +{{ polkadot: Polkadot :polkadot }}{{ kusama: Kusama :kusama }} relay chain. The two cylinders "A" and "B" represent two distinct parachains that have both opted-in to this SPREE module creating two distinct instances of it with their own XCMP endpoints "A.X" and "B.X". diff --git a/docs/learn/learn-system-chains.md b/docs/learn/learn-system-chains.md index 8f325e9ac96c..69b57bba4cda 100644 --- a/docs/learn/learn-system-chains.md +++ b/docs/learn/learn-system-chains.md @@ -20,12 +20,12 @@ provides. ## Overview System parachains are those that contain core Polkadot protocol features, but in parachains rather -than the Relay Chain. Rather than leasing an execution core by economic means (e.g., auction), +than the relay chain. Rather than leasing an execution core by economic means (e.g., auction), execution cores are allocated by network [governance](./learn-guides-polkadot-opengov.md). -By hosting core protocol logic in parachains instead of the Relay Chain, Polkadot uses its own +By hosting core protocol logic in parachains instead of the relay chain, Polkadot uses its own scaling technology -- namely, parallel execution -- to host _itself_. System parachains remove -transactions from the Relay Chain, allowing more Relay Chain +transactions from the relay chain, allowing more relay chain [blockspace](https://www.rob.tech/polkadot-blockspace-over-blockchains/) to be used for Polkadot's primary purpose: validating parachains. @@ -67,7 +67,7 @@ NFTs see the [dedicated wiki page](./learn-nft-pallets.md). This logic for asset management is not encoded in smart contracts, but rather directly in the runtime of the chain. Because of the efficiency of executing logic in a parachain, fees and deposits -are about 1/10th of their respective value on the Relay Chain. +are about 1/10th of their respective value on the relay chain. These low fee levels mean that the Asset Hub is well suited for handling {{ polkadot: DOT :polkadot }}{{ kusama: KSM :kusama }} balances and transfers as well as managing @@ -91,7 +91,7 @@ within other networks. This is achieved with the assistance from a [bridge hub]( ### Bridge Hub Before Polkadot and Kusama supported their first parachains, the only way to design a bridge was to -put the logic onto the Relay Chain itself. Since both networks now support parachains, it makes +put the logic onto the relay chain itself. Since both networks now support parachains, it makes sense to have a parachain on each network dedicated to bridges. This is because of the execution isolation provided by parachains. diff --git a/docs/learn/learn-transactions.md b/docs/learn/learn-transactions.md index 1123be6a9db0..c54272d96c37 100644 --- a/docs/learn/learn-transactions.md +++ b/docs/learn/learn-transactions.md @@ -201,16 +201,16 @@ transactions warrant limiting resources with other strategies. For example: ## Parachain Transactions The transactions that take place within -{{ polkadot: Polkadot :polkadot }}{{ kusama: Kusama :kusama }}'s parachains do not incur Relay Chain +{{ polkadot: Polkadot :polkadot }}{{ kusama: Kusama :kusama }}'s parachains do not incur relay chain transaction fees. Users of shard applications do not even need to hold DOT tokens, as each shard has its own economic model and may or may not have a token. There are, however, situations where shards -themselves make transactions on the Relay Chain. +themselves make transactions on the relay chain. -[Parachains](learn-parachains.md) have a dedicated slot on the Relay Chain for execution, so their +[Parachains](learn-parachains.md) have a dedicated slot on the relay chain for execution, so their collators do not need to own DOT in order to include blocks. The parachain will make some transactions itself, for example, opening or closing an [XCM](learn-xcm.md) channel, participating in an [auction](learn-auction.md) to renew its slot, or upgrading its runtime. Parachains have their -own accounts on the Relay Chain and will need to use those funds to issue transactions on the +own accounts on the relay chain and will need to use those funds to issue transactions on the parachain's behalf. ## Block Limits and Transaction Priority diff --git a/docs/learn/learn-validator.md b/docs/learn/learn-validator.md index fb3b1359b27f..13744e3c912e 100644 --- a/docs/learn/learn-validator.md +++ b/docs/learn/learn-validator.md @@ -30,9 +30,9 @@ trust-free environment. Parachain validators (i.e. para-validators) participate to the [Parachain Phase of the AnV Protocol](./learn-parachains-protocol.md/#parachain-phase), and submit -[candidate receipts](./learn-parachains-protocol.md/#candidate-receipts) to the Relay Chain +[candidate receipts](./learn-parachains-protocol.md/#candidate-receipts) to the relay chain transaction queue so that a block author can include information on the parablock in a fork of of -the Relay Chain. +the relay chain. Para-validators work in groups and are selected by the runtime in every epoch to validate parachain blocks for all parachains connected to the relay chain. The selected para-validators are part of the @@ -47,15 +47,15 @@ _backable_. ## Block Authors -There are validators on the Relay Chain who participate in the consensus mechanism to produce the +There are validators on the relay chain who participate in the consensus mechanism to produce the relay chain blocks based on validity statements from other validators. These validators are called block authors, they are selected by [BABE](./learn-consensus.md/#block-production-babe) and can note up to one backable candidate for each parachain to include in the relay chain. A backable candidate included in the relay chain is considered _backed_ in that fork of the chain. -In a Relay Chain block, block authors will only include +In a relay chain block, block authors will only include [candidate receipts](./learn-parachains-protocol.md/#candidate-receipts) that have a parent -candidate receipt in an earlier Relay Chain block. This ensures the parachain follows a valid chain. +candidate receipt in an earlier relay chain block. This ensures the parachain follows a valid chain. Also, the block authors will only include a receipt for which they have an erasure coding chunk, ensuring that the system can perform the next round of availability and validity checks. @@ -87,7 +87,7 @@ for their activities. Finally, validators participate in the [chain selection process within GRANDPA](./learn-parachains-protocol.md/#chain-selection), ensuring -that only available and valid blocks end within the finalized Relay Chain. +that only available and valid blocks end within the finalized relay chain. :::info Within an era roles can change diff --git a/docs/learn/learn-xcm-transport.md b/docs/learn/learn-xcm-transport.md index 6b401bd45e70..481298143d70 100644 --- a/docs/learn/learn-xcm-transport.md +++ b/docs/learn/learn-xcm-transport.md @@ -45,9 +45,9 @@ _Direct_ and _Relayed_. queue growth. Cross-chain transactions are resolved using a simple queuing mechanism based around a Merkle tree to -ensure fidelity. It is the task of the Relay Chain validators to move transactions on the output +ensure fidelity. It is the task of the relay chain validators to move transactions on the output queue of one parachain into the input queue of the destination parachain. However, only the -associated metadata is stored as a hash in the Relay Chain storage. +associated metadata is stored as a hash in the relay chain storage. The input and output queue are sometimes referred to in the {{ polkadot: Polkadot :polkadot }}{{ kusama: Kusama :kusama }} codebase and associated documentation @@ -85,7 +85,7 @@ For detailed information about VMP see dedicated section in While XCMP is still being implemented, a stop-gap protocol (see definition below) known as **Horizontal Relay-routed Message Passing (HRMP)** exists in its place. HRMP has the same interface and functionality as XCMP but is much more demanding on resources since it stores all messages in -the Relay Chain storage. When XCMP has been implemented, HRMP is planned to be deprecated and phased +the relay chain storage. When XCMP has been implemented, HRMP is planned to be deprecated and phased out in favor of it. ![xcm](../assets/cross-consensus/hrmp-ex.png) @@ -120,7 +120,7 @@ XCMP. ::: -- Cross-chain messages will _not_ be delivered to the Relay Chain. +- Cross-chain messages will _not_ be delivered to the relay chain. - Cross-chain messages will be constrained to a maximum size specified in bytes. - Parachains are allowed to block messages from other parachains, in which case the dispatching parachain would be aware of this block. @@ -167,4 +167,4 @@ asset transfer as intended. The collator now hands this block to the validator, which itself will verify that this message was processed. If the message was processed and all other aspects of the block are valid, the validator -will include this block for parachain `B` into the Relay Chain. +will include this block for parachain `B` into the relay chain. diff --git a/docs/learn/xcm/fundamentals/multiasset.md b/docs/learn/xcm/fundamentals/multiasset.md index c9164363cfe8..b469c5e77f1d 100644 --- a/docs/learn/xcm/fundamentals/multiasset.md +++ b/docs/learn/xcm/fundamentals/multiasset.md @@ -51,7 +51,7 @@ allow assets to be specified by a 32-byte blob. This is convenient, but it relie interpret the blob in the way that the sender expects, which will require a common definition between the sender and the receiver, and may not be simple to achieve. Concrete identities use a `MultiLocation` to identify an asset unambiguously. For native assets (such as DOT), the asset is -identified as the chain which mints the asset (the Polkadot Relay Chain in this case, which would be +identified as the chain which mints the asset (the Polkadot relay chain in this case, which would be the location `..` from one of its parachains). Other assets (e.g. non-native assets or NFTs) can be identified by a `GeneralIndex` junction. Depending on the implementation of the encapsulating consensus system, the exact location may differ (e.g. `GeneralIndex(AssetID)` or @@ -140,7 +140,7 @@ For more information about the MultiLocations used to define concrete assets, se [MultiLocation](multilocation/summary.md) and [Junction](multilocation/junction.md). ```rust -// Location Relay Chain +// Location relay chain // 100 Native Asset (three ways) MultiAsset {id: Concrete(MultiLocation {parents: 0, interior: Here}), fun: Fungible(100u128)}; MultiAsset {id: Here.into(), fun: 100.into()}; diff --git a/docs/maintain/maintain-endpoints.md b/docs/maintain/maintain-endpoints.md index 27af220d9fff..1735b29b8b8a 100644 --- a/docs/maintain/maintain-endpoints.md +++ b/docs/maintain/maintain-endpoints.md @@ -23,7 +23,7 @@ tables below list these endpoints. Endpoints for all production and test networks are listed on the [Polkadot-JS UI](https://polkadot.js.org/apps/#/accounts) which are accessed from [here](https://github.com/polkadot-js/apps/tree/master/packages/apps-config/src/endpoints). -Endpoints for Polkadot Relay Chain and Kusama Relay Chain, parachains, and Paseo test network are +Endpoints for Polkadot relay chain and Kusama relay chain, parachains, and Paseo test network are maintained by the community. System Chains as well as Westend and Rococo test network endpoints maintained by Parity Technologies are listed below: diff --git a/docs/maintain/maintain-guides-validator-payout.md b/docs/maintain/maintain-guides-validator-payout.md index 2ebd7b1b68c2..83e8123e5e38 100644 --- a/docs/maintain/maintain-guides-validator-payout.md +++ b/docs/maintain/maintain-guides-validator-payout.md @@ -16,13 +16,13 @@ Polkadot), validators are paid proportionally to the amount of _era points_ they points are reward points earned for payable actions like: - issuing validity statements for [parachain](../learn/learn-parachains.md) blocks. -- producing a non-uncle block in the Relay Chain. +- producing a non-uncle block in the relay chain. - producing a reference to a previously unreferenced uncle block. - producing a referenced uncle block. :::note -An uncle block is a Relay Chain block that is valid in every regard, but which failed to become +An uncle block is a relay chain block that is valid in every regard, but which failed to become canonical. This can happen when two or more validators are block producers in a single slot, and the block produced by one validator reaches the next block producer before the others. We call the lagging blocks uncle blocks.