Teranode Beta 8 Addresses Early Transaction Cleanup and Recovery Delays

Latest News, Scaling & Teranode, Node Software

Scaling & Teranode / Node Software

In Brief

Teranode’s latest beta addresses two reliability problems: local transaction records being removed too soon, and unnecessary work that could pause the preparation of new blocks when the active blockchain branch changes.

Version 0.16.1-beta-8 is available as a prerelease for node operators. Its changes focus on record retention and recovery during blockchain reorganizations, when a node switches to a competing branch with more accumulated work.

News Report

Published on November 9, 2026, at 15:15 UTC, Beta 8 contains two changes beyond Beta 7. They affect the node’s working transaction database and block assembly, the service that prepares transactions for new blocks.

Keeping Transaction Records Long Enough

Teranode schedules certain records in its working database for cleanup after a retention window measured in blocks. A delayed internal view of the latest block could produce an earlier cleanup point than intended, allowing a mined transaction’s record to be removed prematurely.

The updated SQL and Aerospike storage code enforces a minimum cleanup point based on the block in which the transaction was mined, plus the configured retention window. It also improves coordination between a transaction’s main record and additional records holding its outputs.

The fix is preventive. It does not automatically revisit all earlier cleanup dates or repair records already missing. An optional Aerospike native-operation mode, disabled by default, remains outside this protection.

Less Work When the Chain Changes

During a reorganization, the node must update which transactions belong to the active chain and which remain available for future blocks. Previously, part of that process updated records for the entire pool held by block assembly, even when the chain change affected only a small portion.

The contributor describes a scaling environment where a short reorganization paused transaction intake into block assembly for 10–16 minutes. In one reported run, updating 380 million records accounted for about 7.7 minutes.

Beta 8 narrows that routine update to transactions affected by the reorganization. Full resets and some exceptional recovery paths can still involve the wider pool. The reported timings describe the earlier implementation; no comparable overall recovery time is provided for Beta 8.

Recovery Across Restarts

The update also tracks unfinished corrections for a branch that briefly led the chain but was skipped during recovery. Block assembly attempts to finish that work before reloading its transaction pool after a restart.

This introduces an operational consideration: the service can refuse to start if the required storage is unavailable or its saved recovery record is invalid. Operators should consult the tagged upgrade notes, including the earlier beta notes that still apply.

The contributors report database tests and regression checks covering recovery across restarts. These are project-reported checks, rather than an independent assessment of production performance.

BSV TIMES Read

Large transaction volumes put pressure on routine housekeeping as well as payment processing. This release connects record retention with recovery efficiency: a node must keep information it still needs while avoiding repeated work over an enormous pool whenever a small chain change occurs.

Developer Context

GitHub contributor ordishs contributed the transaction-retention change. Siggi, who contributes as icellan, contributed the block-assembly and restart-recovery change.

Source Links

Posted on November 11, 2026 (UTC)