The core developers from the Nexa team have begun integrating Tailstorm, a block-DAG-based design based on the Tailstorm research. The Tailstorm model represents a significant architectural evolution, moving away from a linear blockchain toward a directed acyclic graph (DAG) of subblocks, while preserving a conventional chain of “summary blocks.” Merging the summary-block model with the traditional chain allows Nexa to take advantage of both approaches while adopting more advanced mining and block-propagation mechanisms.
From a Linear Blockchain to a Tailstorm DAG
Tailstorm separates block production into two distinct roles: frequent subblocks and less frequent summary blocks. Subblocks are low-difficulty proofs of work that arrive rapidly and form a DAG structure. Summary blocks represent the conclusion of a mining “round” and are responsible for advancing the canonical chain state.
In the original Tailstorm and Bobtail papers, summary blocks are produced without proof of work. Once a sufficient number of subblocks exist, each node independently derives a summary block. While elegant on paper, this approach introduces ambiguity in practice, as an attacker can cheaply generate many different valid summary blocks and flood the network.
Nexa’s implementation deliberately avoids this issue by merging the two concepts. The final subblock of each round is itself the summary block. As a result, every summary block is backed by real proof of work. This cryptographically anchors the chain, removes ambiguity, and significantly simplifies both validation and network behavior.
Enhanced Subblock Linking
In the enhanced Tailstorm implementation, each subblock may link to one or more previous subblocks by including additional predecessor hashes in its minerData. This ensures that no branch tips are left unlinked within the subblock DAG.
By explicitly linking all known subblocks, miners cannot selectively prune earlier subblocks or replace them with conflicting alternatives, including double-spend subblocks. Once a subblock is referenced by later subblocks, removing it would require redoing the proof of work of all its descendants.
While the number of stored predecessor hashes can grow over time, this does not pose a problem because subblocks are not written to disk and exist only in memory near the chain tip.
The first image below illustrates the basic Tailstorm structure, where branch tips (shown in grey) may remain unlinked. The second image shows the enhanced linking model, in which all subblocks are referenced and cannot be pruned later.
Subblocks as an In-Memory Data Structure
Subblocks are not permanently stored on disk; instead, they exist only in memory while they are near the chain tip. Once a subblock reaches a configurable depth, controlled by the Params().tailstormEnforceCorrectSubblocks parameter, nodes no longer retain its full contents or enforce transaction correctness for it.
This design works because subblocks never define authoritative chain state. Only summary blocks do. Subblocks merely provide a probabilistic signal about transaction inclusion and mining progress within a round. Once the summary block is mined, that signal becomes irrelevant, and the detailed contents of older subblocks can no longer influence consensus. At that point, nodes retain only the minimal data required to prove that the subblock’s proof of work existed.
By aggressively trimming subblock contents, Nexa keeps disk usage comparable to that of a traditional blockchain despite the much higher rate of block-like objects.
Tip Consistency and Near-Tip Validation
Strict subblock validation is enforced only close to the chain tip, a policy referred to as Tip Consistency. Within this window, nodes verify that subblocks are structurally valid, that their transactions do not conflict with those in descendant subblocks, and that their difficulty target (nBits) matches the parent.
If a competing fork contains inconsistent subblocks within this near-tip window, nodes temporarily ignore it. This rejection is not permanent. Once the inconsistent subblocks fall deeper than the Tip Consistency window, nodes stop enforcing transaction correctness for them and re-evaluate the fork purely on accumulated proof of work.
This mechanism prevents timing-based attacks in which an adversary attempts to permanently poison a fork by exploiting partial knowledge or propagation delays. Ultimately, the branch with the most cumulative proof of work always remains eligible to become the best chain, ensuring convergence.
Proof of Work Under Tailstorm
Tailstorm modifies how difficulty and chainwork are accounted for, while preserving the core proof-of-work model. All subblocks beneath the same parent share a common difficulty target. This target is derived by taking the ASERT-computed difficulty of the parent and dividing it by the expected number of subblocks in a round. In a classical blockchain this divisor is one; under Tailstorm it reflects the Bobtail/Tailstorm parameterization.
From the miner’s perspective, this means solving many easier puzzles rather than a single hard one. Mining infrastructure does not need to change; miners still hash block headers in the usual way.
Total chainwork is calculated as the sum of the summary block itself plus the number of referenced subblocks included via the block’s minerData. This preserves a linear notion of accumulated work while accounting for the DAG beneath each summary block.
Summary Block Requirements
A valid summary block must satisfy several proof-of-work conditions. It must meet its own subblock difficulty target, and it must include references to K-1 additional proof-of-work solutions in its minerData, where K is the Bobtail/Tailstorm target number of subblocks per round. Each referenced solution corresponds to a valid subblock proof of work.
The referenced subblocks do not need to be transaction-valid or internally consistent. Only their proof of work matters. Each solution is cryptographically bound to the parent block hash, preventing reuse across rounds and blocking intermediate-state or precomputation attacks.
Preventing Proof-of-Work Reuse
Because subblocks are ephemeral and not stored long-term, the system must ensure that old proofs of work cannot be replayed or cheaply fabricated. The proof-of-work algorithm enforces this by injecting the parent summary block hash into the computation in a mandatory, non-bypassable way. This data must appear at the beginning of the computation and cannot be substituted with random or precomputed values.
To support this, each block’s minerData stores both a MiningHeaderCommitment, conceptually similar to a “pack” value, and the nonce. While a future proof-of-work revision may compress these fields, they are currently kept separate for compatibility and clarity.
Reorganizations and Fork Behavior
Introducing a subblock DAG changes the dynamics of forks and reorganizations, but not their ultimate resolution. Nodes may temporarily ignore forks that contain inconsistent subblocks near the tip. Once those subblocks age past the Tip Consistency window, the forks become valid candidates again and may trigger a reorganization if they contain more total work.
Reorganizations can occur both at summary-block boundaries and within diverging subblock DAGs. Nodes that join the network late may briefly mine on an attacker’s inconsistent branch, but this is equivalent to the attacker momentarily having additional hashpower. It does not compromise consensus or finality.
The key invariant remains intact: no fork is permanently invalidated due to missing subblocks, timing effects, or temporary near-tip inconsistency.
Configuration and Testing Tools
Several new tools support Tailstorm development and testing. Enabling stormtest=1 converts regtest into a mined network; previously, regtest bypassed proof of work entirely. A new diagnostic RPC, gettailstorminfo, exposes both the summary-block tip and the best subblock DAG tip, along with statistics about in-memory subblocks, competing branches, and double-spend attempts.
For development purposes, Nexa’s production proof-of-work algorithm is too slow to support rapid Tailstorm testing, with subblocks taking on the order of 10–20 seconds to mine. Difficulty cannot be reduced further without compromising ASERT precision, so a fast, regtest-only SHA256-style proof of work is likely to be introduced.
What Tailstorm Changes
Tailstorm adds a subblock DAG above a traditional summary-block chain, providing low-variance mining through Bobtail and fast transaction-probability signaling through Storm. Disk usage remains low due to aggressive trimming of subblocks, and proof-of-work security is preserved through strong cryptographic binding that prevents replay and intermediate-state attacks. New near-tip fork-handling rules ensure robust convergence without permanent invalidation.
At the same time, several core aspects remain unchanged. The summary-block chain remains the single source of truth. Miners continue to use largely the same infrastructure, and wallets and user behavior are unaffected.
Tailstorm is therefore a consensus-layer and mining-layer improvement. Its impact is primarily on block propagation, mining dynamics, and node internals, rather than on user-facing behavior or application design.
In Conclusion
The traditional blockchain model is evolving into a hybrid block-DAG-based design that preserves the traditional structure while taking advantage of, and adopting, the DAG system. This innovative approach is a major step forward and would not be possible without the contributions of our core developers Andrew Stone, Gregory Griffith, and Peter Tschipper. Thanks to our team members, and to everyone who is following Nexa’s journey.