Skip to content

kip-311: split P2P activation between the fork block and node upgrade #129

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
ian0371 merged 1 commit into from
Jul 30, 2026
Merged

kip-311: split P2P activation between the fork block and node upgrade #129

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
12 changes: 7 additions & 5 deletions KIPs/kip-311.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -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.

Expand Down
Loading