1. Network Topology: Kademlia DHT, Node ID and Routing Algorithms
The decentralized transport engine of Lagrix is built on a modified Kademlia protocol. The standard Kademlia implementation is vulnerable to Sybil attacks, so our architecture rigidly binds P2P identifiers to registered super-node places. A place is earned by a year of paid work, which creates a real barrier to entering the routing table.
1.1 Node ID Generation and Crypto-Economic Binding
In classic P2P networks (for example, BitTorrent), nodes generate random 160-bit or 256-bit identifiers. In Lagrix this is strictly forbidden.
The Super-Node identifier (NodeID) is deterministically computed from the public key of the wallet (Ethereum/EVM-compatible) from which the place was registered in the SuperNodeRegistry.sol smart contract.
Formula: $NodeID = \text{SHA3-256}(PublicKey_{EVM})$
Handshake validation: When Node A tries to connect to Node B, it sends its NodeID and a cryptographic signature proving ownership of the private key. Node B takes the public key, queries a blockchain RPC node and checks that this address is an active super-node — it has entered under document 05, section 5.6 (a place assigned by random choice and registered on-chain) and carries no «proven violation» mark (document 06): isActiveSuperNode(PublicKey) == true.
Result: If the address is not an active super-node, the connection is dropped instantly at the socket level. An attacker cannot fill the network with a million fake NodeIDs, because each one requires a real entry: a place assigned by random choice among owners of provider agents with a year of paid work, and a server that passed the check.
1.2 Routing Mathematics (XOR Metric)
Routing between super-nodes relies on computing the logical exclusive OR (XOR) between identifiers. This makes it possible to determine the "distance" between nodes in a virtual 256-bit space.
Distance: $d(x, y) = x \oplus y$
Properties: The XOR metric is symmetric ($d(x,y) = d(y,x)$) and satisfies the triangle inequality. This means that a lookup among super-nodes always converges in logarithmic time $\mathcal{O}(\log N)$, where $N$ is the number of Super-Nodes in the network.
In practice: If a super-node needs to find the node with ID 0xABCD..., it looks in its local table for nodes whose XOR with the target is minimal and forwards the request to them.
1.3 Routing Tables (K-Buckets)
Each Super-Node maintains a local routing table divided into buckets (k-buckets). In a 256-bit space there are 256 buckets.
Parameter $k$: Each bucket stores at most $k=20$ active nodes. This provides sufficient redundancy (if 19 nodes go down, 1 remains available).
Eviction policy: Kademlia gives preference to "old" nodes. If a bucket is full, the new node is placed in a waiting buffer. A PING is sent to the existing nodes. If one of them does not respond (500 ms timeout), it is removed and the new node takes its place. This protects the topology from DDoS attacks aimed at pushing honest nodes out of the tables.
1.4 P2P Message Lifecycle (RPC Methods)
Interaction inside the transport ring is built on 4 basic binary UDP messages:
| RPC Method | Purpose in the Lagrix architecture |
|---|---|
| PING | Checks that a node is alive. Used to keep k-buckets up to date. |
| STORE | Writes a record on the $k$ closest super-nodes — records of the super-nodes' own routing. An agent's address, card and encryption key are not stored in the DHT: they travel in its signed announcement (document 17, section 17.1). |
| FIND_NODE | Requests a list of $k$ nodes closest to the target ID. Used to build the network map. |
| FIND_VALUE | Reads such a record. An agent is found by its announcement and the super-nodes' index, not by the DHT (document 17). |
1.5 Integration with the Local Data Plane (Envoy)
In the reference implementation the Kademlia module and the client's discovery code play the role of the Control Plane. It does not move the actual gigabytes of data between AI agents.
As soon as the client knows the target agent's address — from its announcement (document 17) and, behind a router, from the rendezvous through a super-node (document 02) — this information is instantly passed over a local gRPC channel (xDS API) to Envoy Proxy, which then opens a high-speed mTLS tunnel to transfer the payload. This separation of logic (Discovery separately, Data Streaming separately) makes it possible to achieve microsecond latencies comparable to the best Web2 load balancers. A node may use any other transport that gives the encrypted channel of document 19.