The Tailstorm implementation represents a major conceptual and architectural advancement in blockchain technology, blending the Directed Acyclic Graph (DAG) paradigm with the traditional blockchain structure. It accomplishes this seamlessly, innovatively, and without breaking the foundational model of a linear chain. The DAG runs entirely in memory, leveraging subblocks to improve mining performance and transaction propagation, while the traditional blockchain is preserved through the storage of summary blocks. In effect, this design achieves the advantages of a DAG, like reduced variance and more granular transaction signaling, without compromising the security, simplicity, or determinism of a standard chain.
Tailstorm: A Secure and Fair Blockchain for Cash Transactions
The core mechanism involves two types of blocks: subblocks and summary blocks. In the original Tailstorm and Bobtail papers, these are distinct entities, but in this implementation, they are syntactically nearly identical. Rather than using separate data structures, a summary block is simply a subblock that includes enough proof-of-work to qualify as final. This avoids unnecessary duplication and allows subblocks to serve their signaling purpose while culminating in a single, valid summary block that is committed to disk. This subtle redefinition ensures a secure, consistent blockchain while retaining the full performance benefits of the DAG.
Critically, subblocks are not stored on disk; they reside only in RAM. Once a summary block is deeply buried in the chain (beyond a depth specified by tailstormEnforceCorrectSubblocks), the consistency of its associated subblocks is no longer required. This allows the full node to discard those subblocks and retain only the minimum data needed to validate proof-of-work. The chain’s disk footprint remains nearly identical to that of a traditional blockchain.
Subblock consistency is enforced only near the chain tip, in a concept called “Tip Consistency”. This means that subblocks must be valid and non-conflicting when they are freshly mined, but can be forgotten once buried. The design defends against attacks by ensuring that creating inconsistent subblocks offers no advantage over producing valid ones. Even if an attacker mines a temporary fork with inconsistent subblocks, the network converges once one chain surpasses the other in total work. This allows the network to tolerate temporary inconsistencies without risk of permanent divergence.
The proof-of-work model is adapted accordingly. Each subblock carries a difficulty target (nBits) that is a fraction of the full block target, based on the number of subblocks required (neededSubblocks). All children of a given parent block inherit the same nBits value, allowing miners to reuse existing infrastructure with minimal changes, they are simply solving easier, smaller puzzles more frequently.
A summary block must include its own valid proof-of-work and reference K-1 additional subblocks that also meet the difficulty criteria. These references are stored in the minerData field. For efficiency and modularity, the implementation does not require these references to be valid subblocks, they could be arbitrary bytes that solve the PoW puzzle. However, these solutions are bound to the parent block’s hash, preventing attackers from reusing past work.
The implementation also includes thoughtful analysis and design of subblock proof-of-work validation. To prevent intermediate work or subblock reuse attacks, the hash of the parent block is embedded in the PoW puzzle. Various design options are explored, including interleaving nonce and parent data to ensure that the effort spent solving the puzzle cannot be bypassed through precomputation. Future upgrades might optimize this further by packing the nonce and the commitment hash into a single value.
An optional enhancement is proposed: allowing a variable number of subblocks per summary block. Instead of hardcoding the subblock count, the implementation could require that total subblock work meets a threshold. However, this requires careful encoding of difficulty in the PoW data to prevent abuse by lucky or low-difficulty subblocks.
From a testing and configuration standpoint, the implementation is flexible. Developers can enable Tailstorm mode with a simple configuration change and adjust the number of subblocks dynamically. This makes it straightforward to test various scenarios, including chain convergence and performance under load.
In Conclusion
In conclusion, this Tailstorm implementation blends the best of both DAGs and blockchains. It uses RAM-resident subblocks for efficient mining and transaction signaling, while preserving all core blockchain properties via on-disk summary blocks. The architecture is robust against common attack vectors, avoids introducing ambiguity, and ensures deterministic chain progression. It is an elegant and practical evolution of the blockchain data structure, suitable for high-performance networks without sacrificing decentralization or trustlessness.
To learn more about Tailstorm, you can read the full paper here:
https://people.cs.umass.edu/~gbiss/tailstorm.pdf