Newer
Older
Svyatoslav Nikolsky
committed
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
# Bridge GRANDPA Pallet
The bridge GRANDPA pallet is a light client for the GRANDPA finality gadget, running at the bridged chain.
It may import headers and their GRANDPA finality proofs (justifications) of the bridged chain. Imported
headers then may be used to verify storage proofs by other pallets. This makes the bridge GRANDPA pallet
a basic pallet of all bridges with Substrate-based chains. It is used by all bridge types (bridge between
standalone chains, between parachains and any combination of those) and is used by other bridge pallets.
It is used by the parachains light client (bridge parachains pallet) and by messages pallet.
## A Brief Introduction into GRANDPA Finality
You can find detailed information on GRANDPA, by exploring its [repository](https://github.com/paritytech/finality-grandpa).
Here is the minimal reqiuired GRANDPA information to understand how pallet works.
Any Substrate chain may use different block authorship algorithms (like BABE or Aura) to determine block producers and
generate blocks. This has nothing common with finality, though - the task of block authorship is to coordinate
blocks generation. Any block may be reverted (if there's a fork) if it is not finalized. The finality solution
for (standalone) Substrate-based chains is the GRANDPA finality gadget. If some block is finalized by the gadget, it
can't be reverted.
In GRANDPA, there are validators, identified by their public keys. They select some generated block and produce
signatures on this block hash. If there are enough (more than `2 / 3 * N`, where `N` is number of validators)
signatures, then the block is considered finalized. The set of signatures for the block is called justification.
Anyone who knows the public keys of validators is able to verify GRANDPA justification and that it is generated
for provided header.
There are two main things in GRANDPA that help building light clients:
- there's no need to import all headers of the bridged chain. Light client may import finalized headers or just
some of finalized headders that it consider useful. While the validators set stays the same, the client may
import any header that is finalized by this set;
- when validators set changes, the GRANDPA gadget adds next set to the header. So light client doesn't need to
verify storage proofs when this happens - it only needs to look at the header and see if it changes the set.
Once set is changed, all following justifications are generated by the new set. Header that is changing the
set is called "mandatory" in the pallet. As the name says, the light client need to import all such headers
to be able to operate properly.
## Pallet Operations
The main entrypoint of the pallet is the `submit_finality_proof` call. It has two arguments - the finalized
headers and associated GRANDPA justification. The call simply verifies the justification using current
validators set and checks if header is better than the previous best header. If both checks are passed, the
header (only its useful fields) is inserted into the runtime storage and may be used by other pallets to verify
storage proofs.
The submitter pays regular fee for submitting all headers, except for the mandatory header. Since it is
required for the pallet operations, submitting such header is free. So if you're ok with session-length
lags (meaning that there's exactly 1 mandatory header per session), the cost of pallet calls is zero.
When the pallet sees mandatory header, it updates the validators set with the set from the header. All
following justifications (until next mandatory header) must be generated by this new set.
## Pallet Initialization
As the previous section states, there are two things that are mandatory for pallet operations: best finalized
header and the current validators set. Without it the pallet can't import any headers. But how to provide
initial values for these fields? There are two options.
First option, while it is easier, doesn't work in all cases. It is to start chain with initial header and
validators set specified in the chain specification. This won't work, however, if we want to add bridge
to already started chain.
For the latter case we have the `initialize` call. It accepts the initial header and initial validators set.
The call may be called by the governance, root or by the pallet owner (if it is set).
## Non-Essential Functionality
There may be a special account in every runtime where the bridge GRANDPA module is deployed. This
account, named 'module owner', is like a module-level sudo account - he's able to halt and
resume all module operations without requiring runtime upgrade. Calls that are related to this
account are:
- `fn set_owner()`: current module owner may call it to transfer "ownership" to another account;
- `fn set_operating_mode()`: the module owner (or sudo account) may call this function to stop all
module operations. After this call, all finality proofs will be rejected until further `set_operating_mode` call'.
This call may be used when something extraordinary happens with the bridge;
- `fn initialize()`: module owner may call this function to initialize the bridge.
If pallet owner is not defined, the governance may be used to make those calls.
## GRANDPA Finality Relay
We have an offchain actor, who is watching for GRANDPA justifications and submits them to the bridged chain.
It is the finality relay - you may look at the [crate level documentation and the code](../../relays/finality/).