Realm DHCP

Overview

The Anchor Protocol provides decentralised DHCP over the realm control channel (NATS). There is no central IP-allocation server or shared database. Each Conflux node participates in the channel to query which addresses in the realm’s subnet are in use and to claim one for itself. Overlay addressing stays entirely inside the control plane—no separate DHCP daemon, no database to replicate, and no sync-or-pull layer.

Shared memory and consensus

Existing nodes maintain a shared "shared memory" over the control channel: a live view of which addresses are in use, built from the claims they publish. When a new node joins, it reads this shared memory to see which IPs are available, then requests one. That request must be agreed on by all existing nodes before the claim is accepted, so allocation stays consistent and conflict-free across the realm.

In spirit, this is like blockchain—decentralised agreement over who owns what, without a central authority. Unlike a blockchain, there is no permanent chain storage; only the current state is maintained. The shared memory answers “who has which IP right now.” There is no append-only ledger to keep or replay, which keeps the design simple and avoids the cost of persisting history while still giving consensus for every new IP request.

Implemented in the control plane

This behaviour is implemented as a layer of caching inside the control plane via messaging (publish/subscribe over NATS)—similar to a Redis-style shared view of “what is in use,” but without a separate cache or database. The “cache” is the messaging layer: queries and claims are published and consumed over the realm control channel, and the control plane is the source of truth. There is no separate store for IP allocation and no sync or pull step to reconcile with. By keeping this inside the control plane, Anchor avoids introducing another database or sync machinery while still giving every Conflux node a decentralised way to discover used IPs and claim one.