From 986eeb5568eba7d8e461492458b83b7fefe255cc Mon Sep 17 00:00:00 2001 From: omahs <73983677+omahs@users.noreply.github.com> Date: Fri, 27 Jan 2023 12:21:40 +0100 Subject: [PATCH] Fix: typos (#1822) * Fix: typos Fix: typos * Fix: typos Fix: typos * Fix: typo Fix: typo * Fix: typos Fix: typos * Fix: typos Fix: typos --- docs/high-level-overview.md | 4 ++-- docs/polkadot-kusama-bridge-overview.md | 6 +++--- modules/messages/README.md | 6 +++--- relays/finality/README.md | 10 +++++----- relays/parachains/README.md | 2 +- 5 files changed, 14 insertions(+), 14 deletions(-) diff --git a/docs/high-level-overview.md b/docs/high-level-overview.md index f2806719256..449224124af 100644 --- a/docs/high-level-overview.md +++ b/docs/high-level-overview.md @@ -35,7 +35,7 @@ about the source chain headers which have been finalized. This is useful for hig The pallet tracks current GRANDPA authorities set and only accepts finality proofs (GRANDPA justifications), generated by the current authorities set. The GRANDPA protocol itself requires current authorities set to -generate explicit justificaion for the header that enacts next authorities set. Such headers and their finality +generate explicit justification for the header that enacts next authorities set. Such headers and their finality proofs are called mandatory in the pallet and relayer pays no fee for such headers submission. The pallet does not require all headers to be imported or provided. The relayer itself chooses which headers @@ -123,7 +123,7 @@ The relay connects to the source _relay_ chain and the target chain nodes. It do tracked parachain nodes. The relay looks at the [`Heads`](https://github.com/paritytech/polkadot/blob/1a034bd6de0e76721d19aed02a538bcef0787260/runtime/parachains/src/paras/mod.rs#L642) map of the [`paras` pallet](https://github.com/paritytech/polkadot/tree/1a034bd6de0e76721d19aed02a538bcef0787260/runtime/parachains/src/paras) in source chain, and compares the value with the best parachain head, stored in the bridge parachains pallet at -the taget chain. If new parachain head appears at the relay chain block `B`, the relay process **waits** +the target chain. If new parachain head appears at the relay chain block `B`, the relay process **waits** until header `B` or one of its ancestors appears at the target chain. Once it is available, the storage proof of the map entry is generated and is submitted to the target chain. diff --git a/docs/polkadot-kusama-bridge-overview.md b/docs/polkadot-kusama-bridge-overview.md index 302196718b9..9f407b6ba00 100644 --- a/docs/polkadot-kusama-bridge-overview.md +++ b/docs/polkadot-kusama-bridge-overview.md @@ -21,8 +21,8 @@ The runtime will have minimal set of non-bridge pallets, so there's not much you ## Connecting Parachains You won't be able to directly use bridge hub transactions to send XCM messages over the bridge. Instead, you'll need -to use other parachains transactions, which will use HRMP to deliver message to the Bridge Hub. The Bridge Hub will -just queue this messages in its outbound lane, which is dedicated to deliver messages between two parachains. +to use other parachains transactions, which will use HRMP to deliver messages to the Bridge Hub. The Bridge Hub will +just queue these messages in its outbound lane, which is dedicated to deliver messages between two parachains. Our first planned bridge will connect the Polkadot' Statemint and Kusama' Statemine. Bridge between those two parachains would allow Statemint accounts to hold wrapped KSM tokens and Statemine accounts to hold wrapped DOT @@ -107,7 +107,7 @@ is not used to cover rewards of bridging with some other Polkadot Parachain. Our goal is to incentivize running honest relayers. But we have no relayers sets, so at any time anyone may submit message delivery transaction, hoping that the cost of this transaction will be compensated. So what if some message is currently queued and two relayers are submitting two identical message delivery transactions at once? Without any -special means, the cost of first included transacton will be compensated and the cost of the other one won't. A honest, +special means, the cost of first included transaction will be compensated and the cost of the other one won't. A honest, but unlucky relayer will lose some money. In addition, we'll waste some portion of block size and weight, which may be used by other useful transactions. diff --git a/modules/messages/README.md b/modules/messages/README.md index 1cca1151c6e..b717db6ad62 100644 --- a/modules/messages/README.md +++ b/modules/messages/README.md @@ -94,7 +94,7 @@ In our Substrate-to-Substrate bridge we're using runtime storage proofs. Other b transaction proofs, Substrate header digests or anything else that may be proved. **IMPORTANT NOTE**: everything below in this chapter describes details of the messages module -configuration. But if you interested in well-probed and relatively easy integration of two +configuration. But if you're interested in well-probed and relatively easy integration of two Substrate-based chains, you may want to look at the [bridge-runtime-common](../../bin/runtime-common/) crate. This crate is providing a lot of helpers for integration, which may be directly used from within your runtime. Then if you'll decide @@ -153,7 +153,7 @@ The last type is the `pallet_bridge_messages::Config::DeliveryConfirmationPaymen transaction is received, we call the `pay_reward()` method, passing the range of delivered messages. You may use the [`pallet-bridge-relayers`](../relayers/) pallet and its [`DeliveryConfirmationPaymentsAdapter`](../relayers/src/payment_adapter.rs) adapter as a possible -implementation. It allows you to pay fixed reward for relaying the message and some its portion +implementation. It allows you to pay fixed reward for relaying the message and some of its portion for confirming delivery. ### I have a Messages Module in my Runtime, but I Want to Reject all Outbound Messages. What shall I do? @@ -183,7 +183,7 @@ implements all required traits and will simply reject all transactions, related ### What about other Constants in the Messages Module Configuration Trait? -Two setttings that are used to check messages in the `send_message()` function. The +Two settings that are used to check messages in the `send_message()` function. The `pallet_bridge_messages::Config::ActiveOutboundLanes` is an array of all message lanes, that may be used to send messages. All messages sent using other lanes are rejected. All messages that have size above `pallet_bridge_messages::Config::MaximalOutboundPayloadSize` will also be rejected. diff --git a/relays/finality/README.md b/relays/finality/README.md index edfd00192bc..effc3db6b12 100644 --- a/relays/finality/README.md +++ b/relays/finality/README.md @@ -19,11 +19,11 @@ More: [GRANDPA Finality Relay Sequence Diagram](../../docs/grandpa-finality-rela ## How to Use the Finality Relay The most important trait is the [`FinalitySyncPipeline`](./src/lib.rs), which defines the basic primitives of the -source chain (like block hash and number) and the type of finality proof (GRANDPA jusitfication or MMR proof). Once +source chain (like block hash and number) and the type of finality proof (GRANDPA justification or MMR proof). Once that is defined, there are two other traits - [`SourceClient`](./src/finality_loop.rs) and [`TarggetClient`](./src/finality_loop.rs). -The `SourceClient` represents the Substrate node client that connects to the source chain. The client need to +The `SourceClient` represents the Substrate node client that connects to the source chain. The client needs to be able to return the best finalized header number, finalized header and its finality proof and the stream of finality proofs. @@ -31,8 +31,8 @@ The `TargetClient` implementation must be able to craft finality delivery transa node. The transaction is then tracked by the relay until it is mined and finalized. The main entrypoint for the crate is the [`run` function](./src/finality_loop.rs), which takes source and target -clients and [`FinalitySyncParams`](./src/finality_loop.rs) parameters. The most imporant parameter is the -`only_mandatory_headers` - it it is set to `true`, the relay will only submit mandatory headers. Since transactions +clients and [`FinalitySyncParams`](./src/finality_loop.rs) parameters. The most important parameter is the +`only_mandatory_headers` - it is set to `true`, the relay will only submit mandatory headers. Since transactions with mandatory headers are fee-free, the cost of running such relay is zero (in terms of fees). ## Finality Relay Metrics @@ -55,4 +55,4 @@ change chain names. So the metrics are: breaks) this shall not happen and the metric will have `0` value. If relay operates properly, you should see that the `Rialto_to_Millau_Sync_best_source_at_target_block_number` -tries to reach the `Rialto_to_Millau_Sync_best_source_block_number`. And the latter one always increases. \ No newline at end of file +tries to reach the `Rialto_to_Millau_Sync_best_source_block_number`. And the latter one always increases. diff --git a/relays/parachains/README.md b/relays/parachains/README.md index 6cb68f2209f..9093dc617dc 100644 --- a/relays/parachains/README.md +++ b/relays/parachains/README.md @@ -24,7 +24,7 @@ finality delivery transaction to the target node. The main entrypoint for the crate is the [`run` function](./src/parachains_loop.rs), which takes source and target clients and [`ParachainSyncParams`](./src/parachains_loop.rs) parameters. The most imporant parameter is the -`parachains` - it it the set of parachains, which relay tracks and updates. The other important parameter that +`parachains` - it is the set of parachains, which relay tracks and updates. The other important parameter that may affect the relay operational costs is the `strategy`. If it is set to `Any`, then the finality delivery transaction is submitted if at least one of tracked parachain heads is updated. The other option is `All`. Then the relay waits until all tracked parachain heads are updated and submits them all in a single finality delivery