Reading Teranode's Gossip Layer

libp2p — A modular peer-to-peer networking library, originally built for IPFS, now used by Ethereum, Filecoin, and Teranode. Handles peer discovery, encrypted connections (Noise), stream multiplexing (Yamux), and pub/sub messaging.

gossipsub — The pub/sub protocol layered on libp2p. Peers subscribe to topics; messages published to a topic are forwarded ("gossiped") through the mesh of subscribed peers until they reach everyone. Each peer only directly knows a few others, but messages propagate to the whole mesh in seconds.

Topic / topic prefix — A named stream within gossipsub. Teranode's mainnet topics share the prefix teranode/bitcoin/1.0.0/mainnet-, with suffixes block, subtree, rejected_tx, node_status.

Bootstrap peer — A well-known, hardcoded peer used for initial connectivity. Teranode mainnet currently advertises bootstraps via a /dnsaddr/ TXT record at mainnet.bootstrap.teranode.bsvb.tech. Bootstraps are entry points; they are not necessarily mining or producing operators.

Relay — In gossipsub, any peer that forwards a message it received to other peers. The "relay" of a given message is whoever passed it to the local listener — not who originated it. A single message may pass through many relays.

Broadcast — Publishing a message to a gossipsub topic so that all subscribers receive it. Broadcasts are not addressed to a specific recipient; they are visible to anyone in the mesh subscribed to the topic.

Operator — Whoever runs a Teranode instance: an individual, a company, a foundation, a mining pool, anyone. Operators self-report a client_name in their node_status broadcasts, but the term has no formal protocol meaning — it's shorthand for "the entity behind a given node."

client_name — The operator's self-chosen identifier, broadcast in every node_status message (e.g. bsva-mainnet-eu-2, mainnet.gorillanode.io). Operators name themselves; the unconfigured default is teranode.

producer — In block and subtree messages, the operator that originated the message. Distinct from relay (whoever passed it along).

Teranode — BSV's modern node implementation, succeeding the legacy SVNode. Designed for high transaction throughput. Written in Go.

Microservices — Teranode is not a single program. Per the official architecture overview, it is "a collection of microservices that work together to provide a horizontally scalable and highly efficient blockchain network." A single Teranode deployment runs roughly a dozen services in coordination, including:

• Asset Server — HTTP access to blockchain data
• Propagation Service — receives and forwards transactions
• Validator Service — validates transactions against network rules
• Subtree Validation Service — validates and persists newly received subtrees
• Block Validation Service — processes and validates new blocks
• Block Assembly Service — creates subtrees and assembles block templates for miners
• Blockchain Service — maintains blockchain state through a finite state machine
• Alert Service — distributes network alerts
• P2P Service — manages peer-to-peer communications, including the gossip layer described in this glossary
• Legacy Service — communicates with traditional BSV nodes
• RPC Service — provides Bitcoin RPC compatibility
• Block Persister / UTXO Persister Services — post-process blocks and maintain UTXO set files

FSM (Finite State Machine) — A computer-science construct in which a system is always in exactly one of a small set of named states, transitioning between them on defined events. Teranode's Blockchain Service is implemented as an FSM.

Blockchain Service vs. mining — The Blockchain Service is one specific microservice within Teranode. It "maintains the node's copy of the blockchain through a Finite State Machine that coordinates blockchain state transitions." It is not the whole node; it is the service that owns the lifecycle FSM. Mining, separately, is performed by external hardware (typically ASICs) that connects to the Block Assembly Service to receive block templates and submit proof-of-work solutions. Per the docs, "Miners are responsible for the computational work of finding valid blocks" and "receive block templates from Block Assembly Service." Running Teranode and mining are therefore two separable activities: an operator runs the node software; whether they also mine depends on whether mining hardware is connected to their Block Assembly service.

P2P Service — The microservice that owns Teranode's gossip-layer participation. Per the docs, it "uses libp2p for network communication" and "uses GossipSub for PubSub messaging, with automated topic subscription and management." Its responsibilities include broadcasting the operator's own node_status on startup ("the server's Start() method is invoked and publishes a node status message to announce its presence to the network"), publishing block / subtree / rejected-tx messages on their respective topics, and forwarding ("relaying") other operators' messages through the mesh. The P2P Service also exposes an HTTP server with a WebSocket endpoint (/ws) for external real-time subscribers. It is the service that an external libp2p listener connects to — a listener subscribing to mainnet-node_status is, on the wire, peering with the P2P Service of each operator in its mesh.

UTXO Store — Teranode's representation of the unspent transaction output set: "the current state of ownership of all Satoshi tokens in existence." Architecturally distinct from most other components: per the docs, "The UTXO Store is a shared library component that is used by multiple Teranode services to retrieve, store, and modify UTXOs" — i.e., it is not a microservice with its own API. Instead, multiple services (Validator, Block Validation, Block Assembly, etc.) link the UTXO Store library directly into their process and each open their own client connection to a configured backend. Supported backends:

• Aerospike — primary production datastore; high-performance clustered NoSQL
• SQL — PostgreSQL or SQLite
• Memory — in-memory store, development and testing only
• Nullstore — dummy implementation for testing

Note: Teranode does not use LevelDB. Legacy BSV nodes (SVNode) used LevelDB for the UTXO set; Teranode replaced that pattern with the shared-library + clustered-backend design above. A separate UTXO Persister Service writes UTXO set snapshots to files for backup or external export; it is not the live UTXO store but a sidecar that operates alongside it.

block — New block announcement: height, hash, header, coinbase, and a DataHubURL for HTTP fetch. Carries small notifications; the actual block data is fetched out-of-band over HTTP.

subtree — Subtree (transaction-batch) announcement, broadcast continuously between blocks. Carries a hash and a DataHubURL.

rejected_tx — Transaction rejection with reason code (e.g., fee too low, double-spend, invalid signature).

Subtree — A batch of transactions represented by its root hash. Per the Teranode data-model docs, "Subtrees are used to optimize the propagation of transactions and blocks." A Teranode block is structured as "a container of a group of subtrees" of equal size (except possibly the last). Rather than including full transaction data, a block contains lists of subtree identifiers. Operators continuously process subtrees as transactions arrive, so block assembly becomes "sequence these already-validated subtrees" rather than "process tens of thousands of fresh transactions at once."

DataHubURL / base_url — HTTP endpoint where the actual block or subtree data can be fetched. The architectural rule: announce on P2P, fetch on HTTP.