Conversation
| - **state(n)**: assuming `R(n)`, the `AddressBookV2` state of node `n` as defined in [KIP-286](./kip-286.md). | ||
| - **peerNodes**: `{ n ∈ ℕ | R(n) ∧ state(n) ∈ { CandReady, CandTesting, ValActive, ValReady, ValPaused } }`. | ||
| - **nonPeerNodes**: `ℕ \ peerNodes`, equivalent to `{ n ∈ ℕ | ¬R(n) ∨ (R(n) ∧ state(n) ∈ { Registered, ValInactive, ValExiting }) }`. | ||
| - **ConnType**: the peer-role label declared by each side at the Layer 2 RLPx handshake. Post-fork values for new topology: `{ CN, EN, BN }`. `PN` remains a valid legacy value for backwards compatibility with existing deployments. |
There was a problem hiding this comment.
PN is retained as a valid legacy ConnType, but admission rules don't specify how post-fork CNs treat PN connections (MaxCN vs MaxEN budget? R2 applies? R11 BN acceptance?).
Should PN ConnType be either:
- Fully deprecated post-fork (explicit reject), or
- Treated equivalently to EN (counted in MaxEN, bypass R2, included in R11)?
The current ambiguity risks client implementations diverging.
There was a problem hiding this comment.
IMO "treated equivalently to EN" seems better in terms of graceful shutdown. wdyt?
There was a problem hiding this comment.
Agree, EN-equivalent treatment makes sense.
One follow-up: does a PN connection count toward MaxEN? That seems reasonable to me. If so, would it make sense to add a single statement in the Terms section — e.g., "PN is treated equivalently to EN in all rules" — so that all requirements cover PN implicitly?
There was a problem hiding this comment.
added. Yes, PN should count as EN. Let's treat them equally; PN = EN after HF
|
|
||
| - MUST accept UDP ping (bond) requests from ENs. | ||
| - MUST accept peer requests from ENs. | ||
| - MUST limit the number of EN connections to `MaxEN`. |
There was a problem hiding this comment.
R4 defines MaxEN as "ingress + egress combined" with no egress reservation. If inbound saturates first, CN cannot dial ENs under R6.
go-ethereum's devp2p (same stack Kaia inherits) solves this with DialRatio — a fraction of MaxPeers reserved for dialed connections (default 1/3, see p2p/server.go MaxInboundConns/MaxDialedConns).
Should KIP-311 adopt a similar DialRatio or explicit split?
There was a problem hiding this comment.
If inbound saturates first, CN cannot dial ENs under R6.
If CN has EN connections, I think it's sufficient to sync blocks regardless of ingress or egress.
Do you think having separate room for ingress/egress for CN-EN connections is required?
If so, DialRatio seems to be ok.
However, MinEN and MaxEN seem to solve a different problem: separating room for CN/EN connections.
There was a problem hiding this comment.
Agreed, my original framing ("CN cannot dial ENs under R6") was incorrect — if inbound ENs already fill MaxEN, MinEN is already satisfied and R6 doesn't trigger.
The actual concern is simpler: if all MaxEN slots are occupied by inbound connections, CN has no room to make outbound EN dials at all. This is precisely the problem DialRatio is designed for — go-ethereum introduced it to partition the slot budget so inbound connections cannot starve outbound capacity (see PR #20592).
So DialRatio still seems warranted here. wdyt?
There was a problem hiding this comment.
added targets. I didn't use the direct term DialRatio. Should I use it?
- Remove the Roster feature (R5); the existing Node Discovery and dial protocol is sufficient for CN mesh convergence within the one-epoch lead time the validator lifecycle provides. - Replace MaxCN/MaxEN/MinEN with discoverTargets / dialTarget / peerTarget, indexed as [observer role][counterparty role] to match the implementation. - Add R3 "Peer Budgets" gathering the three targets as normative MUSTs; strip redundant per-role caps from R4 (CN Acceptance) and R5 (EN Acceptance), and point R6 (Sync Discipline) at the dialTarget[CN][EN] floor. Renumber subsequent Rs accordingly. - Add rationale "Why the existing discovery and dial protocol suffices for CN mesh convergence" decomposing the few-minutes convergence budget and noting the discoverTargets[CN][CN]=100 headroom over |peerNodes|. - Fold "Why BN performs no admission filtering" and "Why R2 enforces only on ConnType == CN" into one subsection; note BN holds no Layer 2 peer slots. - Clarify in Terms and Backwards Compatibility that ConnType == PN is treated equivalently to ConnType == EN by all post-fork nodes, so no PN-specific handling is required.
2 participants
Proposed changes
This PR adds new KIP-311: Permissionless P2P Network Topology
Types of changes
Checklist
Put an x in the boxes that apply. You can also fill these out after creating the PR. If you're unsure about any of them, don't hesitate to ask. We're here to help! This is simply a reminder of what we are going to look for before merging your code.
I have read the CLA Document and I hereby sign the CLAin first time contributionRelated issues
#111
Further comments