From c1dd5fcf718165018961a80b2af86ce160e9d3a2 Mon Sep 17 00:00:00 2001 From: Hyunsoo Shin Date: Tue, 28 Jul 2026 12:42:24 +0900 Subject: [PATCH] kip-311: split P2P activation between the fork block and node upgrade Backwards Compatibility says legacy P2P behavior, including static AuthorizedNodes, continues unchanged until the fork block. Implementations cannot honor that for the node-local rules: AuthorizedNodes is removed outright, and gating discovery, dialing and peer budgets on the fork block would make every CN re-peer at the one block where consensus depends on them already being online. Split activation by what each rule depends on instead. R4 and R6 read AddressBookV2 and apply at the fork block; R1, R2, R3 and R5 are node-local and apply at node upgrade. Rejected: gate every rule on the fork block | forces a network-wide re-peer at the fork block, and kbn has no chain to read a height from Rejected: frame this as R2 contradicting Backwards Compatibility | R2 can be read as implicitly post-fork like R1, so the mismatch is with the implementation, not within the document Confidence: high Scope-risk: narrow --- KIPs/kip-311.md | 12 +++++++----- 1 file changed, 7 insertions(+), 5 deletions(-) diff --git a/KIPs/kip-311.md b/KIPs/kip-311.md index 59f1f02..28b9330 100644 --- a/KIPs/kip-311.md +++ b/KIPs/kip-311.md @@ -334,13 +334,15 @@ Each per-peer step is bounded by a single RTT, and `|CNPeers| ≤ MaxNodeCount = ## Backwards Compatibility -This KIP requires the permissionless hard fork. -Before the fork block, legacy P2P behavior (static `AuthorizedNodes`, permissioned CN set, PN role active) continues unchanged. -After the fork block: +R4 and R6 read `AddressBookV2` and take effect at the permissionless hard fork block. +Until then CN admission keeps using the permissioned council, and `static-nodes.json` still grants inbound CN authorization. + +R1, R2, R3, and R5 are node-local and take effect when a node upgrades. +Gating them on the fork block would make every CN re-peer at the one block where consensus depends on them already being online. +Peer policy therefore differs across the upgrade window, which affects neither consensus nor state. - The PN role is retired. Existing PN deployments remain operational under the compatibility rules in R1, R3, and R5 but MAY be deprecated without notice. -- CNs MUST admit peers based on `CNPeers` membership, not a static allowlist. -- `static-nodes.json` no longer grants inbound CN authorization after the fork. It only configures local static outbound dials, subject to the static outbound exemptions in R4, R5, and R6. +- `static-nodes.json` only configures local static outbound dials after the fork, subject to the static outbound exemptions in R4, R5, and R6. - Nodes that do not implement R4 will still interoperate as EN peers, but will be rejected on CN-claimed connections. Non-conforming CNs cannot join the post-fork mesh.