Merge commit '392447f5c8f986ded2559a78457f4cd87942f393' into update-bridges-subtree-r/w

polkadot/bridges/docs/high-level-overview.md

@@ -48,33 +48,21 @@ High level sequence charts of the process can be found in [a separate document](
 
 ### Substrate (GRANDPA) Header Sync
 
-The header sync pallet (`pallet-substrate-bridge`) is an on-chain light client for chains which use
-GRANDPA finality. It is part of the target chain's runtime, and accepts headers from the source
-chain. Its main goals are to accept valid headers, track GRANDPA finality set changes, and verify
-GRANDPA finality proofs (a.k.a justifications).
+The header sync pallet (`pallet-bridge-grandpa`) is an on-chain light client for chains which use
+GRANDPA finality. It is part of the target chain's runtime, and accepts finality proofs from the source
+chain. Verify GRANDPA finality proofs (a.k.a justifications) and track GRANDPA finality set changes.
 
 The pallet does not care about what block production mechanism is used for the source chain
-(e.g Aura or BABE) as long as it uses the GRANDPA finality gadget. Due to this it is possible for
-the pallet to import (but not necessarily finalize) headers which are _not_ valid according to the
-source chain's block production mechanism.
+(e.g Aura or BABE) as long as it uses the GRANDPA finality gadget. In fact the pallet does not
+necessarily store all produced headers, we only import headers with valid GRANDPA justifications.
 
-The pallet has support for tracking forks and uses the longest chain rule to determine what the
-canonical chain is. The pallet allows headers to be imported on a different fork from the canonical
-one as long as the headers being imported don't conflict with already finalized headers (for
-example, it will not allow importing a header at a lower height than the best finalized header).
-
-When tracking authority set changes, the pallet - unlike the full GRANDPA protocol - does not
-support tracking multiple authority set changes across forks. Each fork can have at most one pending
-authority set change. This is done to prevent DoS attacks if GRANDPA on the source chain were to
-stall for a long time (the pallet would have to do a lot of expensive ancestry checks to catch up).
-
-Referer to the [pallet documentation](../modules/substrate/src/lib.rs) for more details.
+Referer to the [pallet documentation](../modules/grandpa/src/lib.rs) for more details.
 
 #### Header Relayer strategy
 
 There is currently no reward strategy for the relayers at all. They also are not required to be
 staked or registered on-chain, unlike in other bridge designs. We consider the header sync to be
-an essential part of the bridge and the incentivisation should be happening on the higher layers.
+an essential part of the bridge and the incentivization should be happening on the higher layers.
 
 At the moment, signed transactions are the only way to submit headers to the header sync pallet.
 However, in the future we would like to use  unsigned transactions for headers delivery. This will
@@ -110,7 +98,7 @@ Users of the pallet add their messages to an "outbound lane" on the source chain
 finalized message relayers are responsible for reading the current queue of messages and submitting
 some (or all) of them to the "inbound lane" of the target chain. Each message has a `nonce`
 associated with it, which serves as the ordering of messages. The inbound lane stores the last
-delivered nonce to prevent replaying messages. To succesfuly deliver the message to the inbound lane
+delivered nonce to prevent replaying messages. To successfully deliver the message to the inbound lane
 on target chain the relayer has to present present a storage proof which shows that the message was
 part of the outbound lane on the source chain.