Tailstorm replaces single 2-minute blocks with a DAG of subblocks that are tied together by a summary block, while keeping the 2-minute settlement cadence. The code already ships inside Full Node 2.2.0.0 and stays dormant until the second hard fork is activated. Since that release our developers have been working on closing gaps in the consensus checks, making fork comparison more accurate, and building tests that put Tailstorm through the situations a live network will throw at it.
This article walks you through the improvements and refinements made in the past weeks.
Summary Block Proof-of-Work
A block must meet its own proof-of-work as a subblock and it must also reference enough subblocks to meet the summary block proof of work. A block meets the proof of work requirement if K minus 1 distinct PoW puzzle solutions are provided, where K is the targeted number of subblocks per summary block. The PoW puzzle includes the known hash of the previous summary block, so it is not possible to reuse old or forked solutions.
The node now checks for duplicate mining hashes in the summary block proof-of-work. Regression coverage was added for duplicate proofs, distinct nonce solutions, invalid PoW, proof-count rejection, and null uncle parents.
Read-Only Inputs and Block Height Inside Subblocks
Read-only inputs within subblocks only use UTXOs that exist at the time of the prior summary block. We evaluate the subblock at its height, not at the summary block root height. Regression coverage queues child and grandchild transactions before their parent becomes available, then checks that replay matches parent-first validation and accepts both descendants.
Comparing Forks
Uncles are subblocks that were created for the prior summary block but did not get included. Summary blocks aggregate the subblock DAG and uncle subblocks are included when scoring reorgs.
In order to make an accurate comparison of various potential forks we need a proper set of valid subblocks and uncles. Uncles are included first and subblocks second, since uncles could have greater or lesser work than the subblocks and could skew the reorg. While this scenario would likely never happen on mainnet, the potential exists in a fast mining regime where accuracy could make a slight difference in how fast a node reorgs to the correct fork.
The reorg test creates a subblock that got orphaned in the previous epoch, then creates two fork blocks that will pull in that orphaned block as an uncle, then reconnects the two peers to see that the fork blocks are actually pulled in and they have also pulled in the uncles, then initiates a reorg which should get both peers onto the same summary block.
Convergence Across Nodes
A multi-node functional test adds the case where a transaction in one subblock spends an output created in an unrelated sibling subblock. Two isolated nodes receive these subblocks in opposite orders. The node receiving the spender first mines a summary, which the other node receives and validates over P2P. The test checks matching chain tips and confirmed transaction outputs, then verifies continued convergence after the other node mines the next summary.
A common descendant does not permanently settle a double spend: extending only the losing branch can increase its score and reverse the winner. A unit test checks both the score change and the resulting transaction exclusion set.
Emergent consensus testing is re-enabled. A tweak disables the requesting of missing subblocks, so we can set up a test where a chain can fall behind by enough blocks to trigger the emergent consensus mechanism.
Block Relay and Peer Policy
Since we are moving to fewer bans for the full node, bans for unrequested thinblocks can be removed, as there is no real threat from receiving an unrequested thinblock. All we want to do is prevent their processing, which we do by returning an error. We check admission before storing reconstruction state for Compact, Graphene, Thin and XThin blocks. The no-ban policy is preserved, and thinblock download timeouts are removed entirely: there really is not any need for the thinblock timeout, and it could end up timing out subblocks, which we don’t want to do and which the block download timeout prevents.
Node Robustness and the DAG Viewer
Failure to open the debug log no longer aborts the process, and directory-creation errors can be reported without a crash. Normal startup is unchanged, and the block and DAG viewer in the RPC console received fixes as well: items are no longer put on the screen in the wrong place when they should have been deferred, every item is always removed from the scene, and the block description dialog gets fully destroyed after it closes.
In Conclusion
The Tailstorm protocol is still under active development, and the team continues testing and polishing all the details. Node operators on the stormtest network, where Tailstorm is already active, can use gettailstorminfo to see what is happening: the current summary block tip, the best DAG subblock, the number of subblocks in the forest, the number of subblocks in the best DAG, and the number of double spend subblocks.
We will keep working and will report on the protocol refinements. There is still a lot to test and review to make sure every detail functions as intended. However, we are steadily moving towards the upcoming hard fork with the activation of Tailstorm.