Development (#172)

* docs: Add CLAUDE_RULES.md with strict rebrand protection rules - Define immutable rebrand rules that cannot be violated - Prohibit reverting rebrand for cargo check convenience - Establish checkpoint and audit trail requirements - Document correct error handling approach * refactor: Complete kurdistan-sdk to pezkuwi-sdk rebrand - Update README.md with pezkuwi-sdk branding - Replace all kurdistan-sdk URL references with pezkuwi-sdk - Replace kurdistan-tech with pezkuwichain in workflows - Update email domains from @kurdistan-tech.io to @pezkuwichain.io - Rename tool references: kurdistan-tech-publish → pezkuwi-publish - Update runner names: kurdistan-tech-* → pezkuwichain-* - Update analytics/forum/matrix domains to pezkuwichain.io - Keep 'Kurdistan Tech Institute' as organization name - Keep tech@kurdistan.gov as official government contact
2025-12-19 23:30:43 +03:00
parent 2093647fea
commit 3680848df2
209 changed files with 496 additions and 454 deletions
@@ -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/pezkuwichain/kurdistan-sdk/issues/136) and
-[2512](https://github.com/pezkuwichain/kurdistan-sdk/issues/137) for more information.
+[2509](https://github.com/pezkuwichain/pezkuwi-sdk/issues/136) and
+[2512](https://github.com/pezkuwichain/pezkuwi-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/pezkuwichain/kurdistan-sdk/issues/138) for more details.
+possible to have their chunk. See this [issue](https://github.com/pezkuwichain/pezkuwi-sdk/issues/138) for more details.


 ### Serving
@@ -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/pezkuwichain/kurdistan-sdk/issues/130
+> TODO: note the incremental validation function Ximin proposes at https://github.com/pezkuwichain/pezkuwi-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/pezkuwichain/kurdistan-sdk/issues/144) ticket.
+[this](https://github.com/pezkuwichain/pezkuwi-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/pezkuwichain/kurdistan-sdk/issues/161).
+issue](https://github.com/pezkuwichain/pezkuwi-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/pezkuwichain/kurdistan-sdk/issues/162) in case of high
+limit inclusion for example (as suggested [here](https://github.com/pezkuwichain/pezkuwi-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,7 +202,7 @@ 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
-Bizinikiwi level, but [are not](https://github.com/pezkuwichain/kurdistan-sdk/issues/30)
+Bizinikiwi level, but [are not](https://github.com/pezkuwichain/pezkuwi-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/pezkuwichain/kurdistan-sdk/issues/162).
+layer](https://github.com/pezkuwichain/pezkuwi-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/pezkuwichain/kurdistan-sdk/issues/141 for more details.
+See https://github.com/pezkuwichain/pezkuwi-sdk/issues/141 for more details.

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