pezkuwichain/pezkuwi-subxt
1
0
Fork 0
mirror of https://github.com/pezkuwichain/pezkuwi-subxt.git synced 2026-05-31 06:21:02 +00:00
Code Issues Packages Projects Releases Wiki Activity

Fix: typos (#1822)

Browse Source 
* Fix: typos

Fix: typos

* Fix: typos

Fix: typos

* Fix: typo

Fix: typo

* Fix: typos

Fix: typos

* Fix: typos

Fix: typos
This commit is contained in:
omahs
2023-01-27 12:21:40 +01:00
committed by Bastian Köcher
parent f0c3cf4ca5
commit a417c707d6
5 changed files with 14 additions and 14 deletions
Download Patch File Download Diff File Expand all files Collapse all files
bridges/docs/high-level-overview.md
+2 -2
View File
@@ -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), 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 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. 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 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) 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) 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 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 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. proof of the map entry is generated and is submitted to the target chain.
bridges/docs/polkadot-kusama-bridge-overview.md
+3 -3
View File
@@ -21,8 +21,8 @@ The runtime will have minimal set of non-bridge pallets, so there's not much you
## Connecting Parachains ## Connecting Parachains
You won't be able to directly use bridge hub transactions to send XCM messages over the bridge. Instead, you'll need 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 to use other parachains transactions, which will use HRMP to deliver messages 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. 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 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 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 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 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 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 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. may be used by other useful transactions.
bridges/modules/messages/README.md
+3 -3
View File
@@ -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. 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 **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 Substrate-based chains, you may want to look at the
[bridge-runtime-common](../../bin/runtime-common/) crate. This crate is providing a lot of [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 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. 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 You may use the [`pallet-bridge-relayers`](../relayers/) pallet and its
[`DeliveryConfirmationPaymentsAdapter`](../relayers/src/payment_adapter.rs) adapter as a possible [`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. for confirming delivery.
### I have a Messages Module in my Runtime, but I Want to Reject all Outbound Messages. What shall I do? ### 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? ### 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 `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 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. size above `pallet_bridge_messages::Config::MaximalOutboundPayloadSize` will also be rejected.
bridges/relays/finality/README.md
+4 -4
View File
@@ -19,11 +19,11 @@ More: [GRANDPA Finality Relay Sequence Diagram](../../docs/grandpa-finality-rela
## How to Use the Finality Relay ## How to Use the Finality Relay
The most important trait is the [`FinalitySyncPipeline`](./src/lib.rs), which defines the basic primitives of the 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 that is defined, there are two other traits - [`SourceClient`](./src/finality_loop.rs) and
[`TarggetClient`](./src/finality_loop.rs). [`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 be able to return the best finalized header number, finalized header and its finality proof and the stream of
finality proofs. 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. 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 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 clients and [`FinalitySyncParams`](./src/finality_loop.rs) parameters. The most important parameter is the
`only_mandatory_headers` - it it is set to `true`, the relay will only submit mandatory headers. Since transactions `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). with mandatory headers are fee-free, the cost of running such relay is zero (in terms of fees).
## Finality Relay Metrics ## Finality Relay Metrics
bridges/relays/parachains/README.md
+1 -1
View File
@@ -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 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 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 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 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 the relay waits until all tracked parachain heads are updated and submits them all in a single finality delivery