<!-- Canonical: https://docs.linea.build/network/overview/public-data -->

> For the complete Linea documentation index, see [llms.txt](/llms.txt).
> Agents can fetch this page as Markdown at [https://docs.linea.build/network/overview/public-data.md](https://docs.linea.build/network/overview/public-data.md).

# Public data

## What is public network data?

One of the main value propositions of a public blockchain network is that it be, well, _public_. This means that the information about what’s going on the network needs to be readily available. Networks like Ethereum have this more or less built in and available as part of the software: each node has an API that will return any information you ask for; if you have a lot of requests, well, you just need more nodes.

Linea works the same way. The difference is that Ethereum's incentive mechanisms let anyone stake ETH and run an Ethereum validator node, whereas Linea doesn't rely on staking for correctness. Consensys teams run Linea's nodes instead, and run enough of them to meet demand. That capacity lets dapps query network state without overloading the clients that execute transactions.

## What do the public RPCs do?

Receive and respond to requests from users and dapps according to the Ethereum JSON-RPC API standard. This includes providing information to MetaMask users about their accounts on Linea.

### How do they do it?

By leveraging the expertise and resources of Infura, Consensys, and the Ethereum ecosystem as a whole, Infura is running a number of nodes to provide this service, in two main capacities:

## Client-facing RPC-API nodes

[RPC nodes](/protocol/architecture/rpc-services) do the "traditional" work of EVM nodes:

-   They receive updated network state information from the [sequencer](/protocol/reference/zero-knowledge-glossary#sequencer)**Sequencer** The set of Linea Besu plugins responsible for ordering, building, and executing blocks in a way that allows the subsequent ZK proof to be made, including the tracer. The sequencer is a plugin set rather than a standalone process; a node that runs it alongside a Maru validator is a [sequencer node](/protocol/reference/zero-knowledge-glossary#sequencer-node). and [state manager](/protocol/reference/zero-knowledge-glossary#state-manager)**State manager** The Lineth component that maintains the network's state representation for proof generation and recovery. It consists of a Besu node with the Shomei plugin and a Shomei node that uses sparse Merkle trees to track state changes block by block, generate Merkle proofs for state transitions, and serve `linea_getProof` RPC requests., and provide information about that state to users and dapps when they request it.
-   They receive incoming transactions.

To handle the traffic, Infura runs the nodes behind a load balancer. Those transactions submitted by users are, therefore, balanced across the nodes, and are thereby routed into the memory pool, for subsequent ingestion and processing by the [coordinator](/protocol/reference/zero-knowledge-glossary#coordinator)**Coordinator** Lineth's coordination module for batching, proof generation, and finality submission. The coordinator monitors block production, manages conflation deadlines, batches blocks, combines batches into blobs, orchestrates execution, compression, and aggregation proofs, and submits proofs and data to the finalization layer..

### Archive nodes

[Archive nodes](/protocol/architecture/rpc-services#archive-nodes) support those dapps and those research activities that rely on historical data.

This type of data request can be resource-intensive, and could put the live network nodes at risk of having their performance impacted, and thus threaten the overall health of the network. For this reason, Infura deploys archive nodes in a scalable architecture; these kinds of transactions aren’t being run _all_ the time–-but when they are, more nodes are spun up as needed to keep up with demand.

## Next steps

-   [Connect to the network](/network/build/connect)
