diff --git a/chain-interactions/send-transactions/interoperability/transfer-assets-parachains.md b/chain-interactions/send-transactions/interoperability/transfer-assets-parachains.md index fe0b4e56a..7bad5d33e 100644 --- a/chain-interactions/send-transactions/interoperability/transfer-assets-parachains.md +++ b/chain-interactions/send-transactions/interoperability/transfer-assets-parachains.md @@ -21,7 +21,7 @@ In this guide, you will: - Build an XCM transfer transaction using ParaSpell XCM SDK. - Perform a dry run to validate the transfer. -- Verify the [Existential Deposit (ED)](/reference/glossary/#existential-deposit){target=\_blank} requirement on the destination chain. +- Verify the Existential Deposit (ED) requirement on the destination chain. - Retrieve information regarding the transfer, along with fee estimates. - Submit the transaction. @@ -109,7 +109,7 @@ The result of the dry run will look similar to the following example output: ## Verify the Existential Deposit -Check if the recipient account meets the [Existential Deposit (ED)](/reference/glossary/#existential-deposit){target=\_blank} requirement before sending by using [`verifyEdOnDestination`](https://paraspell.github.io/docs/xcm-api/xcm-sdk-functionality.html#verify-ed-on-destination){target=\_blank}: +Check if the recipient account meets the Existential Deposit (ED) requirement before sending by using [`verifyEdOnDestination`](https://paraspell.github.io/docs/xcm-api/xcm-sdk-functionality.html#verify-ed-on-destination){target=\_blank}: ```ts title="index.ts" --8<-- 'code/chain-interactions/send-transactions/interoperability/transfer-assets-parachains/index.ts:72:88' @@ -192,4 +192,4 @@ You have now successfully created and sent a cross-chain transfer using the Para - **Read the docs**: Dive deeper into the features of the [ParaSpell XCM SDK](https://paraspell.github.io/docs/xcm-sdk/getting-started.html){target=\_blank} documentation. -- **Learn about XCM**: Understand the underlying protocol by visiting the [Get Started with XCM](/parachains/interoperability/get-started/) guide. \ No newline at end of file +- **Learn about XCM**: Understand the underlying protocol by visiting the [Get Started with XCM](/parachains/interoperability/get-started/) guide. diff --git a/parachains/customize-runtime/index.md b/parachains/customize-runtime/index.md index ffcfd56f5..fb9e00781 100644 --- a/parachains/customize-runtime/index.md +++ b/parachains/customize-runtime/index.md @@ -8,7 +8,7 @@ categories: Basics, Parachains ## Introduction -A blockchain runtime is more than just a fixed set of rules—it's a dynamic foundation that you can shape to match your specific needs. With Polkadot SDK's [FRAME (Framework for Runtime Aggregation of Modularized Entities)](/reference/glossary/#frame-framework-for-runtime-aggregation-of-modularized-entities){target=\_blank}, customizing your runtime is straightforward and modular. Instead of building everything from scratch, you combine pre-built pallets with your own custom logic to create a runtime suited to your blockchain's purpose. +A blockchain runtime is more than just a fixed set of rules—it's a dynamic foundation that you can shape to match your specific needs. With Polkadot SDK's FRAME (Framework for Runtime Aggregation of Modularized Entities), customizing your runtime is straightforward and modular. Instead of building everything from scratch, you combine pre-built pallets with your own custom logic to create a runtime suited to your blockchain's purpose. This overview explains how runtime customization works, introduces the building blocks you'll use, and guides you through the key patterns for extending your runtime. @@ -111,4 +111,4 @@ This section covers the most common customization patterns you'll encounter: - **[Create Custom Pallets](/parachains/customize-runtime/pallet-development/create-a-pallet/)**: Build entirely custom pallets for features unique to your blockchain. -- **[Test Your Runtime](/parachains/customize-runtime/pallet-development/pallet-testing/)**: Unit test pallets and mock complete runtimes to ensure everything works correctly. \ No newline at end of file +- **[Test Your Runtime](/parachains/customize-runtime/pallet-development/pallet-testing/)**: Unit test pallets and mock complete runtimes to ensure everything works correctly. diff --git a/parachains/customize-runtime/pallet-development/pallet-testing.md b/parachains/customize-runtime/pallet-development/pallet-testing.md index 3a94f6ab5..db7ea8faf 100644 --- a/parachains/customize-runtime/pallet-development/pallet-testing.md +++ b/parachains/customize-runtime/pallet-development/pallet-testing.md @@ -35,7 +35,7 @@ Before you begin, ensure you: ## Understanding FRAME Testing Tools -[FRAME (Framework for Runtime Aggregation of Modularized Entities)](/reference/glossary/#frame-framework-for-runtime-aggregation-of-modularized-entities){target=\_blank} provides specialized testing macros and utilities that make pallet testing more efficient. +FRAME (Framework for Runtime Aggregation of Modularized Entities) provides specialized testing macros and utilities that make pallet testing more efficient. ### Assertion Macros diff --git a/parachains/interoperability/get-started.md b/parachains/interoperability/get-started.md index 47207b1e5..1d7e3e4e6 100644 --- a/parachains/interoperability/get-started.md +++ b/parachains/interoperability/get-started.md @@ -66,7 +66,7 @@ The message consists of three instructions described as follows: The first instruction takes as an input the MultiAsset that should be withdrawn. The MultiAsset describes the native parachain token with the `Here` keyword. The `amount` parameter is the number of tokens that are transferred. The withdrawal account depends on the origin of the message. In this example the origin of the message is Alice. The `WithdrawAsset` instruction moves `amount` number of native tokens from Alice's account into the holding register. -- **[BuyExecution](https://github.com/polkadot-fellows/xcm-format?tab=readme-ov-file#buyexecution){target=\_blank}**: Allocates fees to cover the execution [weight](/reference/glossary/#weight){target=\_blank} of the XCM instructions. +- **[BuyExecution](https://github.com/polkadot-fellows/xcm-format?tab=readme-ov-file#buyexecution){target=\_blank}**: Allocates fees to cover the execution Weight of the XCM instructions. ```rust --8<-- 'code/parachains/interoperability/get-started/XCM-first-look.rs:3:6' diff --git a/parachains/launch-a-parachain/deploy-to-polkadot.md b/parachains/launch-a-parachain/deploy-to-polkadot.md index 464cdff43..bc2d65ece 100644 --- a/parachains/launch-a-parachain/deploy-to-polkadot.md +++ b/parachains/launch-a-parachain/deploy-to-polkadot.md @@ -76,11 +76,7 @@ To reserve a parachain identifier, follow these steps: ## Generate Custom Keys for Your Collators -To securely deploy your parachain, it is essential to generate custom keys specifically for your collators (block producers). You should generate two sets of keys for each collator: - - +To securely deploy your parachain, it is essential to generate custom keys specifically for your Collators (block producers). You should generate two sets of keys for each collator: - **Account keys**: Used to interact with the network and manage funds. These should be protected carefully and should never exist on the filesystem of the collator node. @@ -100,7 +96,7 @@ Ensure that this command is executed twice to generate the keys for both the acc ## Generate the Chain Specification -Polkadot SDK-based parachains are defined by a file called the [chain specification](/reference/glossary/#chain-specification){target=\_blank}, or chain spec for short. There are two types of chain spec files: +Polkadot SDK-based parachains are defined by a file called the Chain Specification, or chain spec for short. There are two types of chain spec files: - **Plain chain spec**: A human-readable JSON file that can be modified to suit your parachain's requirements. It serves as a template for initial configuration and includes human-readable keys and structures. - **Raw chain spec**: A binary-encoded file used to start your parachain node. This file is generated from the plain chain spec and contains the encoded information necessary for the parachain node to synchronize with the blockchain network. It ensures compatibility across different runtime versions by providing data in a format directly interpretable by the node's runtime, regardless of upgrades since the chain's genesis. @@ -194,7 +190,7 @@ Once you have the genesis state and runtime, you can now register these with you ![](/images/parachains/launch-a-parachain/deploy-to-polkadot/deploy-to-polkadot-10.webp) -Your parachain's runtime logic and genesis are now part of the relay chain. The next step is to ensure you are able to run a collator to produce blocks for your parachain. +Your parachain's runtime logic and genesis are now part of the relay chain. The next step is to ensure you are able to run a Collator to produce blocks for your parachain. !!!note You may need to wait several hours for your parachain to onboard. Until it has onboarded, you will be unable to purchase coretime, and therefore will not be able to perform transactions on your network. @@ -264,4 +260,4 @@ With your parachain collator operational, the next step is acquiring coretime. T - Bulk coretime is purchased via the Broker pallet on the respective coretime system parachain. You can purchase bulk coretime on the coretime chain and assign the purchased core to the registered `ParaID`. - On-demand coretime is ordered via the [`OnDemand`](https://paritytech.github.io/polkadot-sdk/master/polkadot_runtime_parachains/on_demand/index.html){target=\_blank} pallet, which is located on the respective relay chain. -Once coretime is correctly assigned to your parachain, whether bulk or on-demand, blocks should be produced (provided your collator is running). \ No newline at end of file +Once coretime is correctly assigned to your parachain, whether bulk or on-demand, blocks should be produced (provided your collator is running). diff --git a/parachains/runtime-maintenance/coretime-renewal.md b/parachains/runtime-maintenance/coretime-renewal.md index a960f9005..64a329322 100644 --- a/parachains/runtime-maintenance/coretime-renewal.md +++ b/parachains/runtime-maintenance/coretime-renewal.md @@ -55,7 +55,7 @@ The coretime auto-renewal feature simplifies maintaining continuous coretime all When auto-renewal is enabled, the system follows this process at the start of each sale: 1. The system scans all registered auto-renewal records. -2. For each record, it attempts to process renewal payments from the task's [sovereign account](/reference/glossary/#sovereign-account){target=\_blank} (which is the sibling account on the Coretime chain derived from the parachain ID). +2. For each record, it attempts to process renewal payments from the task's Sovereign Account (which is the sibling account on the Coretime chain derived from the parachain ID). 3. Upon successful payment, the system emits a `Renewed` event and secures the core for the next period. 4. If payment fails due to insufficient funds or other issues, the system emits an `AutoRenewalFailed` event. diff --git a/reference/index.md b/reference/index.md index a90f3b685..9e302f94e 100644 --- a/reference/index.md +++ b/reference/index.md @@ -8,7 +8,7 @@ categories: Basics, Polkadot Protocol, Reference The Technical Reference section provides comprehensive documentation of Polkadot's architecture, core concepts, and development tooling. Whether you're exploring how Polkadot's relay chain coordinates parachains, understanding governance mechanisms, or building applications on the network, this reference covers the technical foundations you need. -Polkadot is a multi-chain network that enables diverse, interconnected blockchains to share security and communicate seamlessly. Understanding how these components interact from the [relay chain](/reference/glossary#relay-chain){target=\_blank} that validates [parachains](/reference/glossary#parachain){target=\_blank} to the [governance](/reference/glossary#governance){target=\_blank} mechanisms that evolve the protocol is essential for developers, validators, and network participants. +Polkadot is a multi-chain network that enables diverse, interconnected blockchains to share security and communicate seamlessly. Understanding how these components interact from the Relay Chain that validates parachains to the governance mechanisms that evolve the protocol is essential for developers, validators, and network participants. This guide organizes technical documentation across five core areas: Polkadot Hub, Parachains, On-Chain Governance, Glossary, and Tools, each providing detailed information on different aspects of the Polkadot ecosystem. diff --git a/reference/parachains/blocks-transactions-fees/fees.md b/reference/parachains/blocks-transactions-fees/fees.md index 006d6c68c..c381db14c 100644 --- a/reference/parachains/blocks-transactions-fees/fees.md +++ b/reference/parachains/blocks-transactions-fees/fees.md @@ -18,7 +18,7 @@ When transactions are executed, or data is stored on-chain, the activity changes The Polkadot SDK provides block authors with several ways to manage access to resources and to prevent individual components of the chain from consuming too much of any single resource. Two of the most important mechanisms available to block authors are weights and transaction fees. -[Weights](/reference/glossary/#weight){target=\_blank} manage the time it takes to validate a block and characterize the time it takes to execute the calls in the block's body. By controlling the execution time a block can consume, weights set limits on storage input, output, and computation. +Weights manage the time it takes to validate a block and characterize the time it takes to execute the calls in the block's body. By controlling the execution time a block can consume, weights set limits on storage input, output, and computation. Some of the weight allowed for a block is consumed as part of the block's initialization and finalization. The weight might also be used to execute mandatory inherent extrinsic calls. To help ensure blocks don’t consume too much execution time and prevent malicious users from overloading the system with unnecessary calls, weights are combined with transaction fees. @@ -222,4 +222,4 @@ You now know the weight system, how it affects transaction fee computation, and - [Benchmark](/parachains/customize-runtime/pallet-development/benchmark-pallet/) - [`SignedExtension`](https://paritytech.github.io/polkadot-sdk/master/sp_runtime/traits/trait.SignedExtension.html){target=\_blank} - [Custom weights for the Example pallet](https://github.com/paritytech/polkadot-sdk/blob/{{dependencies.repositories.polkadot_sdk.version}}/substrate/frame/examples/basic/src/weights.rs){target=\_blank} -- [Polkadot wiki](https://wiki.polkadot.com/learn/learn-transactions/#fee-multiplier){target=\_blank} \ No newline at end of file +- [Polkadot wiki](https://wiki.polkadot.com/learn/learn-transactions/#fee-multiplier){target=\_blank} diff --git a/reference/parachains/consensus/index.md b/reference/parachains/consensus/index.md index aa5b46948..84d0f98c0 100644 --- a/reference/parachains/consensus/index.md +++ b/reference/parachains/consensus/index.md @@ -26,7 +26,7 @@ Key responsibilities include: ## Consensus and Validation -Parachain consensus operates in tandem with the relay chain, leveraging [Nominated Proof of Stake (NPoS)](/reference/glossary/#nominated-proof-of-stake-npos){target=\_blank} for shared security. The process ensures parachain transactions achieve finality through the following steps: +Parachain consensus operates in tandem with the relay chain, leveraging Nominated Proof of Stake (NPoS) for shared security. The process ensures parachain transactions achieve finality through the following steps: 1. **Packaging transactions**: Collators bundle transactions into PoV blocks (parablocks). 2. **Submission to validator**: Parablocks are submitted to a randomly selected subset of relay chain validators, known as paravalidators. diff --git a/reference/parachains/index.md b/reference/parachains/index.md index cc7ecbf89..e10fbaa86 100644 --- a/reference/parachains/index.md +++ b/reference/parachains/index.md @@ -8,7 +8,7 @@ categories: Basics, Parachains ## Introduction -A parachain is a specialized blockchain that connects to the Polkadot relay chain, benefiting from shared security, interoperability, and scalability. Parachains are built using the [Polkadot SDK](https://github.com/paritytech/polkadot-sdk){target=\_blank}, a powerful toolkit written in Rust that provides everything needed to create custom blockchain logic while integrating seamlessly with the Polkadot network. +A Parachain is a specialized blockchain that connects to the Polkadot relay chain, benefiting from shared security, interoperability, and scalability. Parachains are built using the [Polkadot SDK](https://github.com/paritytech/polkadot-sdk){target=\_blank}, a powerful toolkit written in Rust that provides everything needed to create custom blockchain logic while integrating seamlessly with the Polkadot network. Unlike standalone blockchains that must bootstrap their own validator sets and security, parachains leverage Polkadot's pooled security model. This allows parachain developers to focus on their application-specific functionality rather than consensus and security infrastructure. Parachains can communicate with each other through Cross-Consensus Messaging (XCM), enabling seamless interoperability across the Polkadot ecosystem. @@ -82,7 +82,7 @@ graph TB ### FRAME: Building Blocks for Your Runtime -FRAME provides modular components called [pallets](/reference/glossary#pallet){target=\_blank} that you can compose to build your parachain's runtime. Each pallet provides specific functionality that you can customize and configure for your needs. This modular approach allows you to quickly assemble complex functionality without writing everything from scratch. +FRAME provides a modular component called a Pallet that you can configure and combine to build your parachain's runtime. Each pallet provides specific functionality that you can customize for your needs. This modular approach allows you to quickly assemble complex functionality without writing everything from scratch. ```mermaid graph LR @@ -183,4 +183,4 @@ The following sections provide detailed guidance on each aspect of parachain dev [:octicons-arrow-right-24: Maintain](/parachains/runtime-maintenance/runtime-upgrades/) - \ No newline at end of file + diff --git a/reference/polkadot-hub/assets.md b/reference/polkadot-hub/assets.md index f995ccbf2..9229723aa 100644 --- a/reference/polkadot-hub/assets.md +++ b/reference/polkadot-hub/assets.md @@ -44,7 +44,7 @@ Each asset is identified by a unique ID and stores: - Sufficiency–whether the asset can keep an account alive without DOT - Metadata (name, symbol, decimals) -If a balance falls below the configured minimum, called the [existential deposit](/reference/glossary/#existential-deposit){target=\_blank}, it may be removed as “dust.” This ensures efficient storage while giving developers control over asset economics. +If a balance falls below the configured minimum, called the Existential Deposit, it may be removed as “dust.” This ensures efficient storage while giving developers control over asset economics. ## Common Asset IDs @@ -173,4 +173,4 @@ To learn more about asset transfers with XCM, please refer to the [Introduction [:octicons-arrow-right-24: Get Started](/chain-interactions/token-operations/convert-assets/) - \ No newline at end of file + diff --git a/reference/polkadot-hub/bridging.md b/reference/polkadot-hub/bridging.md index 99b80a601..42d39582f 100644 --- a/reference/polkadot-hub/bridging.md +++ b/reference/polkadot-hub/bridging.md @@ -8,7 +8,7 @@ categories: Polkadot Protocol, Interoperability ## Introduction -The Bridge Hub system parachain plays a crucial role in facilitating trustless interactions between Polkadot, Kusama, Ethereum, and other blockchain ecosystems. By implementing on-chain light clients and supporting protocols like BEEFY and GRANDPA, Bridge Hub ensures seamless message transmission and state verification across chains. It also provides essential [pallets](/reference/glossary/#pallet){target=\_blank} for sending and receiving messages, making it a cornerstone of Polkadot’s interoperability framework. With built-in support for XCM (Cross-Consensus Messaging), Bridge Hub enables secure, efficient communication between diverse blockchain networks. +The Bridge Hub system parachain plays a crucial role in facilitating trustless interactions between Polkadot, Kusama, Ethereum, and other blockchain ecosystems. By implementing on-chain light clients and supporting protocols like BEEFY and GRANDPA, Bridge Hub ensures seamless message transmission and state verification across chains. It also provides essential Pallet functionality for sending and receiving messages, making it a cornerstone of Polkadot’s interoperability framework. With built-in support for XCM (Cross-Consensus Messaging), Bridge Hub enables secure, efficient communication between diverse blockchain networks. This guide covers the architecture, components, and deployment of the Bridge Hub system. You'll explore its trustless bridging mechanisms, key pallets for various blockchains, and specific implementations like Snowbridge and the Polkadot <> Kusama bridge. By the end, you'll understand how Bridge Hub enhances connectivity within the Polkadot ecosystem and beyond. diff --git a/reference/polkadot-hub/consensus-and-security/pos-consensus.md b/reference/polkadot-hub/consensus-and-security/pos-consensus.md index 902169cbb..d17eb2956 100644 --- a/reference/polkadot-hub/consensus-and-security/pos-consensus.md +++ b/reference/polkadot-hub/consensus-and-security/pos-consensus.md @@ -8,7 +8,7 @@ categories: Polkadot Protocol ## Introduction -Polkadot's Proof of Stake consensus model leverages a unique hybrid approach by design to promote decentralized and secure network operations. In traditional Proof of Stake (PoS) systems, a node's ability to validate transactions is tied to its token holdings, which can lead to centralization risks and limited validator participation. Polkadot addresses these concerns through its [Nominated Proof of Stake (NPoS)](/reference/glossary/#nominated-proof-of-stake-npos){target=\_blank} model and a combination of advanced consensus mechanisms to ensure efficient block production and strong finality guarantees. This combination enables the Polkadot network to scale while maintaining security and decentralization. +Polkadot's Proof of Stake consensus model leverages a unique hybrid approach by design to promote decentralized and secure network operations. In traditional Proof of Stake (PoS) systems, a node's ability to validate transactions is tied to its token holdings, which can lead to centralization risks and limited validator participation. Polkadot addresses these concerns through its Nominated Proof of Stake (NPoS) model and a combination of advanced consensus mechanisms to ensure efficient block production and strong finality guarantees. This combination enables the Polkadot network to scale while maintaining security and decentralization. ## Nominated Proof of Stake @@ -125,4 +125,3 @@ Key features of BEEFY include: - diff --git a/reference/polkadot-hub/consensus-and-security/relay-chain.md b/reference/polkadot-hub/consensus-and-security/relay-chain.md index ddfd9e2ab..59703f99b 100644 --- a/reference/polkadot-hub/consensus-and-security/relay-chain.md +++ b/reference/polkadot-hub/consensus-and-security/relay-chain.md @@ -8,7 +8,7 @@ categories: Basics, Polkadot Protocol, Parachains ## Introduction -Polkadot is a next-generation blockchain protocol designed to support a multi-chain future by enabling secure communication and interoperability between different blockchains. Built as a Layer-0 protocol, Polkadot introduces innovations like application-specific Layer-1 chains ([parachains](/reference/parachains/){targe=\_blank}), shared security through [Nominated Proof of Stake (NPoS)](/reference/glossary/#nominated-proof-of-stake-npos){target=\_blank}, and cross-chain interactions via its native [Cross-Consensus Messaging Format (XCM)](/parachains/interoperability/get-started/){target=\_blank}. +Polkadot is a next-generation blockchain protocol designed to support a multi-chain future by enabling secure communication and interoperability between different blockchains. Built as a Layer-0 protocol, Polkadot introduces innovations like application-specific Layer-1 chains ([parachains](/reference/parachains/){targe=\_blank}), shared security through Nominated Proof of Stake (NPoS), and cross-chain interactions via its native [Cross-Consensus Messaging Format (XCM)](/parachains/interoperability/get-started/){target=\_blank}. This guide covers key aspects of Polkadot’s architecture, including its high-level protocol structure, blockspace commoditization, and the role of its native token, DOT, in governance, staking, and resource allocation. @@ -139,4 +139,4 @@ JAM removes many of the opinions and constraints of the current relay chain whil - **Permissionless code execution**: JAM is designed to be more generic and flexible, allowing for permissionless code execution through services that can be deployed without governance approval. - **More effective block time utilization**: JAM's efficient pipeline processing model places the prior state root in block headers instead of the posterior state root, enabling more effective utilization of block time for computations. -This architectural evolution promises to enhance Polkadot's scalability and flexibility while maintaining robust security guarantees. JAM is planned to be rolled out to Polkadot as a single, complete upgrade rather than a stream of smaller updates. This approach seeks to minimize the developer overhead required to address any breaking changes. \ No newline at end of file +This architectural evolution promises to enhance Polkadot's scalability and flexibility while maintaining robust security guarantees. JAM is planned to be rolled out to Polkadot as a single, complete upgrade rather than a stream of smaller updates. This approach seeks to minimize the developer overhead required to address any breaking changes. diff --git a/reference/tools/light-clients.md b/reference/tools/light-clients.md index 46873d48e..b90537f1f 100644 --- a/reference/tools/light-clients.md +++ b/reference/tools/light-clients.md @@ -8,7 +8,7 @@ categories: Parachains, Tooling ## Introduction -Light clients enable secure and efficient blockchain interaction without running a full node. They provide a trust-minimized alternative to JSON-RPC by verifying data through cryptographic proofs rather than blindly trusting remote nodes. +Light clients enable secure and efficient blockchain interaction without running a Full Node. They provide a trust-minimized alternative to JSON-RPC by verifying data through cryptographic proofs rather than blindly trusting remote nodes. This guide covers: @@ -36,21 +36,21 @@ FN -- Response (validated via Merkle proof) --> LC In the diagram above, the decentralized application queries on-chain account information through the light client. The light client runs as part of the application and requires minimal memory and computational resources. It uses Merkle proofs to verify the state retrieved from a full node in a trust-minimized manner. Polkadot-compatible light clients utilize warp syncing, which downloads only block headers. -Light clients can quickly verify the blockchain's state, including [GRANDPA finality](/reference/glossary#grandpa){target=\_blank} justifications. +Light clients can quickly verify the blockchain's state, including GRANDPA finality justifications. !!!note "What does it mean to be trust-minimized?" _Trust-minimized_ means that the light client does not need to fully trust the full node from which it retrieves the state. This is achieved through the use of Merkle proofs, which allow the light client to verify the correctness of the state by checking the Merkle tree root. ## JSON-RPC and Light Client Comparison -Another common method of communication between a user interface (UI) and a node is through the JSON-RPC protocol. Generally, the UI retrieves information from the node, fetches network or [pallet](/reference/glossary#pallet){target=\_blank} data, and interacts with the blockchain. This is typically done in one of two ways: +Another common method of communication between a user interface (UI) and a node is through the JSON-RPC protocol. Generally, the UI retrieves information from the node, fetches network or Pallet data, and interacts with the blockchain. This is typically done in one of two ways: - **User-controlled nodes**: The UI connects to a node client installed on the user's machine. - These nodes are secure, but installation and maintenance can be inconvenient. - **Publicly accessible nodes**: The UI connects to a third-party-owned publicly accessible node client. - These nodes are convenient but centralized and less secure. Applications must maintain a list of backup nodes in case the primary node becomes unavailable. -While light clients still communicate with [full nodes](/reference/glossary#full-node), they offer significant advantages for applications requiring a secure alternative to running a full node: +While light clients still communicate with full nodes, they offer significant advantages for applications requiring a secure alternative to running a full node: | Full Node | Light Client | | :---------------------------------------------------------------------------------------------: | :------------------------------------------------------------: | diff --git a/reference/tools/omninode.md b/reference/tools/omninode.md index afd7906e7..0f9c96773 100644 --- a/reference/tools/omninode.md +++ b/reference/tools/omninode.md @@ -8,7 +8,7 @@ categories: Parachains, Tooling ## Introduction -The [`polkadot-omni-node`](https://crates.io/crates/polkadot-omni-node/{{dependencies.crates.polkadot_omni_node.version}}){target=\_blank} crate is a versatile, pre-built binary designed to simplify running parachains in the Polkadot ecosystem. Unlike traditional node binaries that are tightly coupled to specific runtime code, the `polkadot-omni-node` operates using an external [chain specification](/reference/glossary#chain-specification){target=\_blank} file, allowing it to adapt dynamically to different parachains. +The [`polkadot-omni-node`](https://crates.io/crates/polkadot-omni-node/{{dependencies.crates.polkadot_omni_node.version}}){target=\_blank} crate is a versatile, pre-built binary designed to simplify running parachains in the Polkadot ecosystem. Unlike traditional node binaries that are tightly coupled to specific runtime code, the `polkadot-omni-node` operates using an external Chain Specification file, allowing it to adapt dynamically to different parachains. This approach enables it to act as a white-labeled node binary, capable of running most parachains that do not require custom node-level logic or extensions. Developers can leverage this flexibility to test, deploy, or operate parachain nodes without maintaining a dedicated codebase for each network. @@ -190,4 +190,4 @@ Your runtime must include and properly configure the following pallets: pub type ParachainInfo = parachain_info::Pallet; ``` -If you're migrating an existing parachain to use the `polkadot-omni-node`, you may need to perform runtime upgrades to add the required runtime APIs and pallets. Follow the standard parachain [runtime upgrade](/parachains/runtime-maintenance/runtime-upgrades/){target=\_blank} procedures to implement these changes on your live network. \ No newline at end of file +If you're migrating an existing parachain to use the `polkadot-omni-node`, you may need to perform runtime upgrades to add the required runtime APIs and pallets. Follow the standard parachain [runtime upgrade](/parachains/runtime-maintenance/runtime-upgrades/){target=\_blank} procedures to implement these changes on your live network. diff --git a/smart-contracts/for-eth-devs/evm-vs-pvm.md b/smart-contracts/for-eth-devs/evm-vs-pvm.md index 55aa026d2..146bf610f 100644 --- a/smart-contracts/for-eth-devs/evm-vs-pvm.md +++ b/smart-contracts/for-eth-devs/evm-vs-pvm.md @@ -8,7 +8,7 @@ categories: Smart Contracts, Polkadot Protocol ## Introduction -While [PVM](/reference/glossary#pvm){target=\_blank} strives for maximum Ethereum compatibility, several fundamental design decisions create necessary divergences from the [EVM](https://ethereum.org/developers/docs/evm/){target=\_blank}. These differences represent trade-offs that enhance performance and resource management while maintaining accessibility for Solidity developers. +While PVM strives for maximum Ethereum compatibility, several fundamental design decisions create necessary divergences from the [EVM](https://ethereum.org/developers/docs/evm/){target=\_blank}. These differences represent trade-offs that enhance performance and resource management while maintaining accessibility for Solidity developers. ## Core Virtual Machine Architecture @@ -294,4 +294,4 @@ YUL functions accepting memory buffer offset pointers or size arguments are limi For standard Solidity development, this limitation is unlikely to be hit as the compiler handles memory addresses correctly within typical contract sizes. However, if you are writing extremely large contracts using YUL assembly that manually and extensively manipulate memory addresses, ensure that your memory offsets and sizes do not exceed PVM's **fixed 64KB memory limit per contract**. While the YUL functions might accept 32-bit pointers (up to 2^32-1), attempting to access memory beyond the allocated 64KB buffer will trap the contract immediately. -These incompatibilities reflect the fundamental architectural differences between EVM and PVM while maintaining high-level Solidity compatibility. Most developers using standard Solidity patterns will encounter no issues, but those working with assembly code or advanced contract patterns should carefully review these differences during migration. \ No newline at end of file +These incompatibilities reflect the fundamental architectural differences between EVM and PVM while maintaining high-level Solidity compatibility. Most developers using standard Solidity patterns will encounter no issues, but those working with assembly code or advanced contract patterns should carefully review these differences during migration.