RFC: decide whether Rings needs Chord-style virtual nodes

[rings-auto-reviewer]

Context

The DHT benchmark work in #656 needs to compare Rings against the original Chord paper. One of the paper's load-balance experiments (Fig. 9) evaluates virtual nodes: each real node owns multiple unrelated positions on the Chord identifier ring, and keys are assigned to those virtual positions before being aggregated back to the real node.

Rings currently appears to have a single routing identity (Did) per runtime node. The existing VNode/VirtualNode terminology was storage-entry terminology and is being separated from node membership in #607; it is not the same feature as Chord virtual nodes.

Because of that, the benchmark PR can only report Fig. 9 as simulator-only data today. It cannot honestly claim that Rings runtime supports virtual-node load balancing.

Why this matters

Chord uses virtual nodes to reduce key ownership skew. In the original paper's Fig. 9 setup, a 10^4 real-node network with 10^6 keys improves substantially as virtual nodes per real node increase. Without a runtime virtual-node design, Rings inherits the single-identifier consistent-hashing skew: some nodes own much larger identifier intervals than others.

This affects:

• storage/load balance for DHT entries;
• benchmark claims against Chord's load-balance results;
• interpretation of paper-aligned simulator data versus real Rings behavior;
• future scaling behavior when node count is large but each node contributes only one ring position.

Questions to resolve

• Do we need Chord-style virtual nodes in Rings runtime, or is simulator-only comparison enough for the paper?
• If needed, should a physical node advertise multiple routing Dids, or should virtual positions be derived from one authenticated node identity?
• How should WebRTC connections map to virtual identities: one transport peer with many ring positions, or separate logical peers over one transport?
• Should every virtual node maintain its own successor list and finger table, or should routing remain physical-node based with virtual ownership only for storage placement?
• How do entry ownership, replication, successor sync, and registration interact with multiple virtual positions per physical node?
• What operational cost is acceptable: O(v log N) routing state per physical node, fewer virtual nodes, or a bounded ownership-only scheme?

Proposed scope

Start with a design/RFC before implementation. The RFC should define the semantics separately for:

• routing membership;
• storage ownership and key placement;
• transport/session mapping;
• authentication of derived virtual identities;
• benchmark reporting.

A minimal implementation may choose ownership-only virtual positions first, if full routing virtual nodes are too invasive.

Acceptance criteria

• The repository has a documented decision on whether Rings supports Chord-style virtual nodes.
• The decision clearly distinguishes Chord virtual nodes from storage Entry/legacy VNode terminology.
• If accepted, there is a design for deriving or registering multiple ring positions per physical node.
• The design explains routing table, successor list, storage ownership, replication/sync, and WebRTC transport implications.
• Benchmarks can label Fig. 9 data as either runtime-supported or simulator-only without ambiguity.

[RyanKung]

Design note from the benchmark discussion: vnode_did = H(owner_did, index) looks like the most viable direction if we implement Chord-style virtual nodes.

The important protocol split would be:

• owner_did: the real signed account/session identity and WebRTC transport peer.
• vnode_did / ring_did: the derived Chord ring position used for ownership/routing decisions.

A concrete derivation should be domain-separated, for example:

vnode_did = H("rings:vnode", network_id, owner_did, vnode_index)

This avoids requiring a separate private key per virtual node. The owner would sign a virtual-node descriptor that binds { owner_did, vnode_did, vnode_index, network_id, expires_at }, and peers would accept vnode_did as a ring position only when that descriptor verifies against owner_did.

Implications to account for in the RFC:

• message signatures should remain owner-signed; virtual nodes should not become independent signing identities;
• online-node registration needs to advertise one owner with multiple derived ring positions;
• routing tables may store vnode_did, but transport send needs a vnode_did -> owner_did -> connection mapping;
• storage ownership/replication can use vnode_did, while authorization and CRDT actor/version fields should probably continue to use owner_did unless there is a specific reason to distinguish virtual actors;
• report-return and relay validation need to avoid assuming that every ring destination is also the signer DID.

This option preserves the security boundary around the real identity while still giving us Chord-style load-balance positions for Fig. 9 / large-scale storage distribution.