pezkuwichain
1c0e57d984
This commit systematically rebrands various references from Parity Technologies' Polkadot/Substrate ecosystem to PezkuwiChain within the kurdistan-sdk. Key changes include: - Updated external repository URLs (zombienet-sdk, parity-db, parity-scale-codec, wasm-instrument) to point to pezkuwichain forks. - Modified internal documentation and code comments to reflect PezkuwiChain naming and structure. - Replaced direct references to with or specific paths within the for XCM, Pezkuwi, and other modules. - Cleaned up deprecated issue and PR references in various and files, particularly in and modules. - Adjusted image and logo URLs in documentation to point to PezkuwiChain assets. - Removed or rephrased comments related to external Polkadot/Substrate PRs and issues. This is a significant step towards fully customizing the SDK for the PezkuwiChain ecosystem.
40 lines
1.8 KiB
Markdown
40 lines
1.8 KiB
Markdown
Integration of the GRANDPA finality gadget into Bizinikiwi.
|
|
|
|
This crate is unstable and the API and usage may change.
|
|
|
|
This crate provides a long-running future that produces finality notifications.
|
|
|
|
# Usage
|
|
|
|
First, create a block-import wrapper with the `block_import` function. The
|
|
GRANDPA worker needs to be linked together with this block import object, so
|
|
a `LinkHalf` is returned as well. All blocks imported (from network or
|
|
consensus or otherwise) must pass through this wrapper, otherwise consensus
|
|
is likely to break in unexpected ways.
|
|
|
|
Next, use the `LinkHalf` and a local configuration to `run_grandpa_voter`.
|
|
This requires a `Network` implementation. The returned future should be
|
|
driven to completion and will finalize blocks in the background.
|
|
|
|
# Changing authority sets
|
|
|
|
The rough idea behind changing authority sets in GRANDPA is that at some point,
|
|
we obtain agreement for some maximum block height that the current set can
|
|
finalize, and once a block with that height is finalized the next set will
|
|
pick up finalization from there.
|
|
|
|
Technically speaking, this would be implemented as a voting rule which says,
|
|
"if there is a signal for a change in N blocks in block B, only vote on
|
|
chains with length NUM(B) + N if they contain B". This conditional-inclusion
|
|
logic is complex to compute because it requires looking arbitrarily far
|
|
back in the chain.
|
|
|
|
Instead, we keep track of a list of all signals we've seen so far (across
|
|
all forks), sorted ascending by the block number they would be applied at.
|
|
We never vote on chains with number higher than the earliest handoff block
|
|
number (this is num(signal) + N). When finalizing a block, we either apply
|
|
or prune any signaled changes based on whether the signaling block is
|
|
included in the newly-finalized chain.
|
|
|
|
License: GPL-3.0-or-later WITH Classpath-exception-2.0
|