feat: Rebrand Polkadot/Substrate references to PezkuwiChain

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.
2025-12-14 00:04:10 +03:00
parent 286de54384
commit 1c0e57d984
9084 changed files with 997839 additions and 997557 deletions
@@ -55,7 +55,7 @@ requester is responsible of making that availability a reality.

 It does that by querying checking occupied cores for all active leaves. For each occupied core it will spawn a task
 fetching the erasure chunk which has the `ValidatorIndex` of the node. For this an `ChunkFetchingRequest` is issued, via
-Substrate's generic request/response protocol.
+Bizinikiwi's generic request/response protocol.

 The spawned task will start trying to fetch the chunk from validators in responsible group of the occupied core, in a
 random order. For ensuring that we use already open TCP connections wherever possible, the requester maintains a cache
@@ -65,13 +65,13 @@ Note however that, because not all validators in a group have to be actual backe
 the needed chunk. This in turn could lead to low throughput, as we have to wait for fetches to fail, before reaching a
 validator finally having our chunk. We do rank back validators not delivering our chunk, but as backers could vary from
 block to block on a perfectly legitimate basis, this is still not ideal. See issues
-[2509](https://github.com/paritytech/polkadot/issues/2509) and
-[2512](https://github.com/paritytech/polkadot/issues/2512) for more information.
+[2509](https://github.com/pezkuwichain/kurdistan-sdk/issues/136) and
+[2512](https://github.com/pezkuwichain/kurdistan-sdk/issues/137) for more information.

 The current implementation also only fetches chunks for occupied cores in blocks in active leaves. This means though, if
 active leaves skips a block or we are particularly slow in fetching our chunk, we might not fetch our chunk if
 availability reached 2/3 fast enough (slot becomes free). This is not desirable as we would like as many validators as
-possible to have their chunk. See this [issue](https://github.com/paritytech/polkadot/issues/2513) for more details.
+possible to have their chunk. See this [issue](https://github.com/pezkuwichain/kurdistan-sdk/issues/138) for more details.


 ### Serving
@@ -46,7 +46,7 @@ aware of this configuration:
 ///
 /// This differs from `CandidateCommitments` in two ways:
 ///
-/// - does not contain the erasure root; that's computed at the Pezkuwi level, not at Cumulus
+/// - does not contain the erasure root; that's computed at the Pezkuwi level, not at Pezcumulus
 /// - contains a proof of validity.
 pub struct Collation {
  /// Messages destined to be interpreted by the Relay chain itself.
@@ -19,7 +19,7 @@ not being wasted by attackers. Communicating across this trust-boundary is the m
 Validation of candidates is a heavy task, and furthermore, the [`PoV`][PoV] itself is a large piece of data.
 Empirically, `PoV`s are on the order of 10MB.

-> TODO: note the incremental validation function Ximin proposes at https://github.com/paritytech/polkadot/issues/1348
+> TODO: note the incremental validation function Ximin proposes at https://github.com/pezkuwichain/kurdistan-sdk/issues/130

 As this network protocol serves as a bridge between collators and validators, it communicates primarily with one
 subsystem on behalf of each. As a collator, this will receive messages from the [`CollationGeneration`][CG] subsystem.
@@ -176,7 +176,7 @@ current authority set will overlap with the ones in the previous set and will be

 Still, for maximum accountability we need to make sure a previous authority set can communicate votes to the next one,
 regardless of any chain: This is yet to be implemented see section "Resiliency" in dispute-distribution and
-[this](https://github.com/paritytech/polkadot/issues/3398) ticket.
+[this](https://github.com/pezkuwichain/kurdistan-sdk/issues/144) ticket.

 ## Coordinating Actual Dispute Participation

@@ -271,7 +271,7 @@ ordering as the priority one - by block heights of the relay parent, older block
 possibility not to be able to obtain the block number of the parent when we are inserting the dispute in the queue. To
 account for races, we will promote any existing participation request to the priority queue once we learn about an
 including block. NOTE: this is still work in progress and is tracked by [this
-issue](https://github.com/paritytech/polkadot/issues/5875).
+issue](https://github.com/pezkuwichain/kurdistan-sdk/issues/161).

 ### Abandoned Forks

@@ -468,7 +468,7 @@ finalized in the first place. Not allowing disputing already finalized blocks ac
 as it massively reduces the amount of candidates that can be disputed.

 This makes attempts to overwhelm the system with disputes significantly harder and counter measures way easier. We can
-limit inclusion for example (as suggested [here](https://github.com/paritytech/polkadot/issues/5898) in case of high
+limit inclusion for example (as suggested [here](https://github.com/pezkuwichain/kurdistan-sdk/issues/162) in case of high
 dispute load. Another measure we have at our disposal is that on finality lag block production will slow down,
 implicitly reducing the rate of new candidates that can be disputed. Hence, the cutting-off of the unlimited candidate
 supply of already finalized blocks, guarantees the necessary DoS protection and ensures we can have measures in place to
@@ -202,8 +202,8 @@ the dispute-coordinator already knows about the dispute.

 Goal 3 and 4 are obviously very related and both can easily be solved via rate
 limiting as we shall see below. Rate limits should already be implemented at the
-Substrate level, but [are not](https://github.com/paritytech/substrate/issues/7750)
-at the time of writing. But even if they were, the enforced Substrate limits would
+Bizinikiwi level, but [are not](https://github.com/pezkuwichain/kurdistan-sdk/issues/30)
+at the time of writing. But even if they were, the enforced Bizinikiwi limits would
 likely not be configurable and thus would still be to high for our needs as we can
 rely on the following observations:

@@ -246,7 +246,7 @@ This is probably an argument for not imposing a too low rate limit, although the
 issue is more general: Even without any rate limit, if an attacker generates
 disputes at a very high rate, nodes will be having trouble keeping participation
 up, hence the problem should be mitigated at a [more fundamental
-layer](https://github.com/paritytech/polkadot/issues/5898).
+layer](https://github.com/pezkuwichain/kurdistan-sdk/issues/162).

 For nodes that have been offline for a while, the same argument as for session
 changes holds, but matters even less: We assume 2/3 of nodes to be online, so
@@ -11,7 +11,7 @@ limits the amount of messages sent and received to be an order of sqrt of the
 validators. Our neighbors in this graph will be forwarded to the network bridge
 with the `NetworkBridgeMessage::NewGossipTopology` message.

-See https://github.com/paritytech/polkadot/issues/3239 for more details.
+See https://github.com/pezkuwichain/kurdistan-sdk/issues/141 for more details.

 The gossip topology is used by teyrchain distribution subsystems,
 such as Bitfield Distribution, (small) Statement Distribution and