Raft With Noosraft

Noosraft is NOOSChain's TypeScript Raft implementation for development and integration testing. It runs inside the TypeScript node process and orders NOOSChain block DTOs through a Raft-style leader, log, and commit path.

Use it when you want a local multi-node cluster without the external HashiCorp Go sidecar.

Configuration

NOOS_CONSENSUS_MODE=raft
RAFT_ENGINE=noosraft
RAFT_NODE_ID=node-a
RAFT_CLUSTER_ID=nooschain-dev-raft
RAFT_VOTER_NODE_IDS=node-a,node-b,node-c
RAFT_OBSERVER_NODE_IDS=node-observer-a
RAFT_TRANSPORT=http
RAFT_BIND_URL=http://127.0.0.1:9001
RAFT_PEERS=[{"nodeId":"node-b","baseUrl":"http://127.0.0.1:9002"},{"nodeId":"node-c","baseUrl":"http://127.0.0.1:9003"}]

For single-process verification, RAFT_TRANSPORT=in_process is also available. For multi-process local nodes, use RAFT_TRANSPORT=http.

Behavior

Noosraft keeps the consensus/application boundary strict:

1. A validator admits signed transactions through the normal mempool path.
2. The current Raft leader builds a candidate NOOSChain block.
3. The candidate is simulated to compute the expected block hash and state root.
4. Noosraft replicates the block DTO as a log entry.
5. Once committed, each node applies the block through deterministic execution.
6. Each node verifies its computed block hash and state root against the entry.

Observers do not vote or propose. They sync committed blocks and execute them locally for verification.

Persistence

Noosraft persists local Raft metadata in PostgreSQL:

• current term and voted-for node
• local log entries
• commit and apply progress

This metadata is consensus-engine state, not application domain state. Domain state still changes only through committed NOOSChain block execution.

Membership

Noosraft uses the configured runtime voter set. Validator governance transactions update the intended validator set in consensus state, but they do not hot-reconfigure Noosraft voters.

The operator reconciliation plan can report mismatches between governance intent and runtime voters. For Noosraft, that plan is guidance only; it is not live joint-consensus membership mutation.

Limitations

• Development/integration backend only.
• No Byzantine-fault tolerance.
• No live Noosraft joint-consensus membership changes.
• HTTP transport is MVP infrastructure, not a hardened production Raft network.
• Snapshot catch-up is full-document only.

Detailed adapter behavior is documented in Raft Consensus Adapter.

Useful Checks

npm run test:raft
npm run test:raft:http
npm run test:raft:snapshot
npm run stability:noosraft-chaos