Inside a Starknet full node. The P2P layer
How a Starknet full node discovers peers, propagates blocks, and syncs state, and why the networking layer is where decentralization is won or lost.
Why the P2P layer matters
A blockchain is only as decentralized as its ability to run full nodes independently. For most of Starknet's early life a single sequencer produced blocks, and nodes fetched data from a central feeder gateway. Moving to a real peer-to-peer network, where nodes discover each other, share blocks directly, and sync without a central dependency, is what turns "a chain with many users" into "a chain with many independent operators."
That makes the networking layer load-bearing in a way that is easy to underestimate. It is not glue between more interesting components. It is the component that decides whether the network can survive the loss of any single party.
Peer discovery and the gossip mesh
Like most modern chains, Starknet's node networking builds on libp2p. A node needs to find peers without a central registry, maintain a healthy set of connections, and gossip new data through the mesh so it reaches the whole network quickly.
The hard parts are not the happy path. They are the adversarial ones. Peers that advertise data they don't have, that send malformed messages, or that try to eclipse a node by monopolizing its connection slots. A production P2P stack has to assume every peer is potentially hostile and stay correct anyway.
Sync. Blocks, state, and the size problem
Propagating new blocks as they are produced is only half the job. A node joining the network also has to catch up from genesis, or from a trusted checkpoint, and Starknet's state is large. Naively replaying everything is slow, so sync protocols separate concerns. Headers first to establish the chain, then bodies, then state, each with its own request/response protocol over the P2P layer.
Getting this right means designing for interruption. Nodes go offline, peers disappear mid-transfer, and the network keeps producing blocks the whole time. Sync has to be resumable and reorg-aware rather than assuming a clean run from start to finish.
What we take from it
Node internals are the layer most teams route around, and it is exactly the layer we work in. Building P2P networking for a Starknet full node, and internals for a Starknet block explorer, is the kind of work that only holds up if the unglamorous cases are handled. The hostile peer, the interrupted sync, the reorg mid-transfer.
Common questions
- What does the P2P layer of a full node do?
- It handles peer discovery, maintains connections, propagates new blocks and transactions through a gossip mesh, and serves the request/response protocols that let a node sync headers, block bodies, and state from other nodes rather than a central server.
- Why is decentralization tied to the networking layer?
- If nodes depend on a central gateway for data, the network has a single point of failure regardless of how many participants it has. A working peer-to-peer layer lets nodes operate independently, which is what real decentralization requires.
- What makes node P2P hard to build?
- The adversarial cases. Peers that lie about data, send malformed messages, or try to eclipse a node, plus sync that has to be resumable and reorg-aware while the network keeps producing blocks. The happy path is easy. Production robustness is not.
Working on something like this?
This is the layer we work in. If you have a hard problem underneath a product, tell us the hard part.