Sync, Gossip, And Verification

NOOSChain separates three concerns that are easy to confuse:

• transaction gossip shares pending signed transactions between trusted nodes;
• sync pulls already committed blocks and executes them locally;
• verification proves that the local database still matches deterministic chain history.

None of these layers is consensus. Consensus chooses transaction order and finality. Gossip helps transactions reach consensus participants, sync helps lagging or observer nodes catch up, and verification keeps every node honest about its own stored chain.

Lifecycle

A typical transaction moves through the system like this:

1. A client submits a canonical signed transaction to a node that can admit transactions.
2. The receiving node verifies the transaction hash, signature, signer, nonce shape, protocol version, and transaction type before placing it in the local mempool.
3. Transaction gossip may forward the same canonical signed envelope to other active trusted peers.
4. A consensus backend orders accepted transactions into a block.
5. The block executor applies the ordered transactions through the deterministic state-machine pipeline and persists the block, transaction outcomes, Merkle root, block hash, and state root.
6. Other nodes sync committed blocks from trusted peers, execute those blocks locally, and compare the recomputed commitments with the fetched block data.
7. If encrypted payload bytes are missing locally and bucket policy allows this node to store them, payload backfill can fetch ciphertext as availability data.
8. Chain verification and replay verification can later recheck the local chain without trusting a peer's database state.

The important boundary is that remote materialized tables are never copied as truth. A peer may provide pending transactions, blocks, or ciphertext bytes, but the receiving node performs its own checks before accepting any local mutation.

Transaction Gossip

Transaction gossip is the distributed mempool layer. It sends pending canonical signed transactions to active trusted peers through POST /transactions/gossip. The route is protected by node-auth headers, not by end-user bearer tokens:

• x-noos-node-id
• x-noos-node-timestamp
• x-noos-node-signature

The receiver verifies the node identity, timestamp freshness, trusted-peer status, and governance validator status before considering the transaction. Then it reruns transaction admission checks locally. A gossiped transaction is not trusted just because a peer sent it.

Gossip checks nonces only as an admission filter. It does not consume nonces. Nonce consumption happens only during deterministic block execution after consensus includes the transaction in a block.

Gossip also preserves the canonical signed envelope. The transaction hash, signature, and createdAt value inside that envelope are consensus-significant; database insertion time is not. Later sync and replay use the same envelope to recompute transaction hashes.

Observer nodes reject transaction admission and transaction gossip with NODE_ROLE_READ_ONLY. They can still sync finalized blocks, replay and verify state, serve permitted reads, and backfill ciphertext that policy allows them to store. See Node Roles and Transaction Gossip.

Block Sync

HTTP node sync is a pull-based catch-up layer for trusted private deployments. It is not peer discovery and it is not a fork-choice rule. Peers are configured explicitly in trusted_peers.

The public chain-data endpoints expose read-only chain facts:

• chain head;
• block headers;
• full blocks;
• bounded block and header ranges;
• local verification results.

The local /sync/run operation is different. It contacts configured peers, pulls committed blocks, inserts each block as synced data, and mutates canonical domain state only by executing the block through the same deterministic block executor used for locally committed blocks.

Before a synced block is accepted, the node checks the fetched chain data:

• height continuity;
• previous-block hash linkage;
• transaction ordering and transaction hashes;
• Merkle root consistency;
• supported protocol version;
• final transaction statuses;
• block hash consistency;
• state-root consistency after local execution.

If local execution cannot reproduce the fetched block's commitments, the sync transaction rolls back and the peer can be penalized by local peer scoring.

/chain/blocks and /chain/headers are bounded APIs. NOOS_SYNC_MAX_BLOCK_RANGE controls the maximum number of blocks returned per request. The default is 1000, and the hard code ceiling is 10000. Malformed, negative, and unsafe huge heights are rejected before database queries run. Large HTTP responses are compressed with Brotli or gzip when the client advertises support.

For the deeper transport contract, see HTTP Node Sync.

Payload Backfill

Encrypted payload bytes are availability-layer data, not consensus state. A node can have the same blocks, transaction outcomes, and state roots as another node while storing fewer ciphertext bytes locally.

Consensus state for encrypted records is anchored by payload hashes, encryption metadata, key envelopes, public indexes, creator identifiers, bucket policy, permissions, and transaction hashes. State hashing does not include ciphertext bytes, block heights, local timestamps, or local availability flags.

Bucket replication policy decides whether a syncing node stores ciphertext:

• replicate_encrypted_to_all_nodes: synced nodes may store ciphertext;
• replicate_encrypted_to_authorized_nodes: synced nodes store ciphertext only when the verified local node organization is allowed to read encrypted data;
• metadata_only: synced nodes store metadata and commitments without ciphertext.

Payload backfill can fetch missing ciphertext later, but it never creates blocks, changes transactions, updates SMT storage, or changes state roots. It compares the remote payload hash with local consensus metadata before writing local availability storage. See Payload Backfill and Data Buckets.

Verification Layers

NOOSChain uses several verification layers, each with a different scope.

Layer	What It Checks	What It Does Not Trust
Gossip admission	Transaction hash, signature, signer, nonce shape, protocol, type, and duplicate/finalized status.	Peer claims that a transaction is valid.
Sync validation	Remote head/block shape, continuity, transaction ordering, Merkle roots, protocol support, block hash, and state root after local execution.	Remote materialized tables or remote state roots without local execution.
Deterministic execution	Transaction outcomes, permission checks, nonce consumption, state leaves, Merkle roots, and state roots.	API admission results from the original submitting node.
Lightweight chain verification	Local block continuity, hashes, Merkle roots, transaction counts, statuses, and stored root records.	Recomputed materialized domain state.
Replay verification	Full deterministic rebuild from genesis, snapshots, ordered blocks, and ordered transactions in an isolated schema.	Canonical domain tables, canonical SMT tables, and current environment defaults.
Snapshot verification	Snapshot checkpoint metadata and state-root reconstruction before bootstrap.	Snapshot contents without local validation.

The lightweight chain verifier is fast and useful for routine checks, but it does not execute blocks and does not rebuild state from domain tables. Full deterministic replay lives in Replay Verification. Use replay when a node must rebuild state from genesis or a verified snapshot checkpoint and compare deterministic SMT roots. For the root model itself, see State Root.

Periodic Local Verification

Each node can run local chain verification in the background with CHAIN_VERIFICATION_ENABLED=true. Incremental mode verifies the next unverified height range in configurable chunks. Full mode verifies genesis to the current head. Progress and run history are stored as local node metadata in chain_verification_state and chain_verification_runs.

Peer verification claims are never trusted. A peer can serve chain data, but each node verifies its own stored chain.

Peer Scoring And Incidents

Sync, gossip, and payload backfill all feed local peer scoring. Successful transport can raise a peer's score; malformed blocks, bad gossip auth, invalid transactions, payload mismatches, timeouts, and finalized conflicts can lower it.

Peer scoring is local transport defense. A quarantine or ban prevents this node from using that peer for normal sync, gossip, and backfill transport, but it does not change validator membership, voting power, finalized blocks, or protocol state. Those are consensus and governance concerns.

If sync sees a finalized block at an already-finalized local height with a different hash, the conflict layer records the conflict, quarantines the peer, enters incident mode, and refuses unsafe mutation until an operator resolves the incident. There is no automatic longest-chain reorg rule in the current closed trusted-validator topology.

See Peer Scoring and Fork Conflict Handling.

Consensus Boundary

Gossip does not finalize transactions. Sync does not choose the canonical chain. Payload backfill does not alter state roots. Verification does not ask peers whether the local database is valid.

Consensus orders transactions. The deterministic executor applies that order. Sync, gossip, payload backfill, and verification are supporting systems around that boundary.