The mempool node is part of a bounded set of long-lived components that accept user transactions, batch them into blocks, and work with the mining network. Public miners still produce work; the design separates “who assembles the next block” from “who stores history forever” and “who expends hashrate this round.”
Balance of roles
Mempool and miner responsibilities are interdependent. If either side failed entirely, the system could not make progress. Storage nodes are the durable home for decided blocks. Engineering trade-offs in how many mempool vs. storage nodes run in production are policy and operations questions for each deployment.
Typical code layout (reference style)
In reference implementations you may see a node core, an interface to the outside world, and a request/response type set that describes the mempool’s RPC or HTTP contract. Use the name you find in the repository you are building against, not a historical label.
Block construction in outline
Each round, the mempool set advances a pool of valid transactions, agrees on ordering within protocol rules, and hands a candidate to miners. If the pool is large, a subset is chosen and the rest remains for a later block.
Interaction with miners and storage
Miners in the active set submit work back to the mempool; the winner’s block is checked and then forwarded to storage nodes for persistent replication. See Miner node, Storage node, and Block mining.