libp2p: Fully Implemented, and the Running Network Does Not Use It

What libp2p is

A networking toolkit rather than a network. It gives a peer an identity, an encrypted connection to other peers, a way to find them, and a way to broadcast a message to everyone interested in a subject.

It is the plumbing most modern chains use instead of writing their own peer protocol, and using it is an ordinary, sensible choice.

What is implemented here

A real transport. Encrypted connections, peer identities, bootstrap peers, and broadcast topics with names: one for blocks, and one for transactions.

And a genuinely careful detail: the transport identity is derived from the node's key with a domain separator mixed in, so the key that identifies a peer on the network is not the key that signs its consensus messages. Reusing one key for both is a classic mistake and this code deliberately avoids it.

Which is worth holding next to something else

The same codebase does not put a domain separator, or any chain identifier, in the transaction envelope.

So the discipline exists here and is missing there. That is the useful observation: it is not that the authors do not know about domain separation, it is that one place got it and another did not. A gap next to a correct example is a stronger finding than a gap alone.

And none of it is carrying traffic on this network

The mode this network runs does not construct the peer-to-peer transport at all.

It builds an in-process channel network instead: four engines inside one program, passing messages to each other over in-memory queues.

This explains a measurement taken earlier. The running process owns exactly one listening socket, bound to localhost, and nothing peer-to-peer. That was a reading before and it is an explanation now, which is the pairing worth having: a measurement and a source that account for each other.

What that means for anything said about the network layer

There is no gossip happening. No peers are discovered, no connections are encrypted, no topics carry anything, because there is nothing to carry it between.

So every property of the transport is untested on this deployment. The code is there, it compiles, and it is exercised by tests rather than by traffic.

This is completely normal for a development network and it is the sort of thing that quietly becomes a surprise later, which is the only reason to write it down.

It also finishes a picture

Three separate measurements now say the same thing about this deployment:

one process one database and now: no network between the participants at all

The four validators are four sets of keys inside one program, sharing one store, talking over in-memory queues. Everything this estate says about agreement, fork choice and fault tolerance has to be read against that, and every one of those pages says so.

What you can check yourself

nothing, from outside

That is the honest answer for this page. A network layer that is not carrying traffic exposes nothing to measure, and the closest a reader can get is noticing that the public endpoint is the only thing this deployment answers on.