Pith. sign in

REVIEW 5 major objections 6 minor 49 references

StreamNet: A DAG System with Streaming Graph Computing

T0 review · 5 major / 6 minor · reviewed 2026-08-14 · deepseek-v4-flash

Challenge this review Re-run · record.json Download PDF Read on arXiv ↗ Review JSON

Pith's one-line read StreamNet claims that a growing proof-of-work DAG can maintain a total order of blocks without a central authority, using two-tip attachment and streaming graph updates.

desk verdict A novel DAG consensus combination with a real implementation, but the central algorithm as written does not terminate and the correctness proof is an unproven inheritance; not ready for serious review. read the letter →

arxiv 1908.06405 v2 pith:JBQAOZG7 submitted 2019-08-18 cs.DC

Zhaoming Yin , Anbang Ruan , Ming Wei , Huafeng Li , Kai Yuan , Junqing Wang , Yahui Wang , Ming Ni
show 1 more author
Andrew Martin
This is my paper · ORCID
classification cs.DC
keywords StreamNetDAGblockchaintotalorderGHOSTpivotchainMCMCtipselectionstreaminggraphcomputinggossipprotocolgenesisforwarding
verification ladder T0 review T1 audit T2 compute T3 formal

The pith

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The reading

StreamNet is a proof-of-work DAG blockchain design that aims to keep transaction validation fast even as its block graph grows, and to do so without a central coordinator. The paper claims that attaching each new block to exactly two tips—one picked deterministically along a GHOST-style pivot chain, one picked by a Markov-chain random walk—allows every node to compute the same total order over all blocks. It then argues that the expensive graph properties behind that order can be maintained incrementally as the DAG streams in, instead of being recomputed from scratch each time. The reported experiments on small clusters of three to seven nodes show transaction throughput staying roughly flat as the number of transactions grows, which is what the streaming design predicts.

What carries the argument

The key machinery is the two-tip attachment rule together with the epoch decomposition of the pivot chain. A new block's parent edge follows the pivot chain, and its reference edge follows an MCMC random walk; the pivot chain partitions the DAG into epochs $Past(G,b)-Past(G,P(b))$, and the ordering algorithm emits earlier epochs first, then topologically sorts the current epoch with hash tie-breaking. The streaming optimizations maintain the required graph properties incrementally: BFS score updates on new blocks, a dual-direction BFS with a covered set for epoch differences, an $O(1)$ topological-position update via $\min(\mathrm{TopScore}(parent),\mathrm{TopScore}(reference))+1$, and a genesis-forwarding threshold that snapshots old history.

What would settle it

Build a small StreamNet testbed, let one miner add blocks whose MCMC reference edges always point into the losing sibling's subtree, and watch whether the pivot chain reorgs more often than the bound in equation (1) predicts; a decay failure or a post-snapshot reorg would refute the inherited-safety claim.

Watch

Extended reading notes

Core claim

StreamNet's central claim is that the total order of a growing DAG can be computed without a centralized authority, and maintained efficiently, by combining deterministic pivot-chain attachment with randomized reference attachment. Every new block gets one parent edge selected by following the pivot chain (the child with the largest subtree score, hashes breaking ties) and one reference edge selected by an MCMC random walk. The pivot chain divides the graph into epochs; recursively ordering past epochs and topologically sorting each epoch's new blocks yields a total order, with block hashes as tie-breakers. Streaming variants of the score, parent-score, epoch-difference, and topological-order computations turn the per-block cost of updating these structures from repeated full-graph traversals into incremental updates. A genesis-forwarding rule periodically freezes old, deeply confirmed history into a persisted snapshot order, and a hash-first gossip protocol separates block announcements from block bodies so that nodes request content on demand.

Load-bearing premise

The paper assumes the GHOST-style pivot-chain safety proof still holds after adding a second, MCMC-chosen reference edge to every block, because that extra edge changes the subtree structure the proof counts.

Editorial extensions

If this is right

  • If the central claim is right, a StreamNet node can keep validating new blocks at a stable rate as the DAG grows, because the expensive graph properties are updated incrementally rather than recomputed from scratch.
  • The absence of a coordinator means every node can derive the same total order from its local DAG view, with hash tie-breaking resolving orderings deterministically.
  • The hash-first gossip protocol should let block updates spread at per-node cost roughly independent of block size, since only hashes are broadcast and bodies are pulled on demand.
  • A periodic genesis forward turns old, approved history into a fixed chain, so applications see a stable prefix of the total order while the new DAG keeps growing.

Reading between the lines

Editorial extensions of the paper, not claims the author makes directly.

  • A testable extension would compare confirmation latency and reorg rates under an adversary that withholds reference edges: the MCMC reference edge changes the subtree shape on which the inherited GHOST-style confirmation bound is proven.
  • The choice of the MCMC scaling constant $\alpha$ is likely to control how evenly reference edges spread across tips; in practice, calibrating it to network delay may matter as much as block generation rate, though the paper does not measure that trade-off.
  • The genesis-forwarding snapshot introduces a checkpoint; a formal argument that a persisted snapshot cannot later be contradicted would be needed, since the paper's correctness discussion does not cover the interaction between forwarding and reorgs.
Share X Bluesky LinkedIn Reddit HN

Signed reviews

No signed human review yet.

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, and a circularity audit.

Referee Report

5 major / 6 minor

Summary. The paper proposes StreamNet, a permissionless DAG-based blockchain protocol. Each new block attaches to two earlier blocks: a deterministic 'parent' chosen by a GHOST-style pivot chain and a random 'reference' chosen by an MCMC walk. The authors define a total order over the DAG using pivot-chain epochs, introduce streaming algorithms to maintain graph properties dynamically, propose a genesis-forwarding mechanism, and design a 'direct signal' gossip protocol. They report an implementation based on IOTA's IRI and experiments on AWS clusters of 3 to 7 nodes with several topologies. The central claims are that StreamNet achieves a decentralized total order, scales to a growing DAG via streaming graph computing, and scales out through its gossip protocol.

Significance. The paper's streaming-maintenance idea and the two-tip attachment rule (one deterministic, one random) are potentially interesting engineering directions, and the authors deserve credit for providing an implementation and releasing the code. However, as written, the core protocol is not well-defined: the MCMC routine in Algorithm 2 cannot terminate as specified, the topological-order update in Eq. (2) is incorrect, and the correctness argument in Section 2.7 is an unsupported assertion that simply transfers Conflux's proof to a different attachment rule. Because these issues affect the central construction, the significance of the paper is currently limited; the experimental evaluation also does not establish the claimed scalability.

major comments (5)
  1. [Algorithm 2 (Section 2.2/2.3)] Algorithm 2 cannot terminate or return a tip. Score(G,t)=|Later(G,t)| is at least 1 for every block, including tips, because Later includes the block itself (Figure 4), so the loop condition `while Score(G,t) != 0` is never false. In addition, the transition step iterates over Child(G,t)={b'|P(b')=t}, i.e., only parent edges; a vertex whose only children are reference-edge children is not a tip by the definition in Section 2.1 but can be reached and returned by this walk. Since every block generation invokes MCMC for the second edge (Algorithm 1, line 9), the two-tip DAG construction is not specified by the stated protocol.
  2. [Section 3.3, Eq. (2)] The O(1) TopOrder update in Eq. (2) is incorrect for topological ordering. A valid topological label must be larger than the label of every immediate predecessor, so with two predecessors the correct recurrence is max(TopScore(Parent(b)), TopScore(Reference(b)))+1. The min+1 rule can assign a block a score lower than one of its own ancestors, violating the order relations that StreamNetOrder relies on. Consequently, the TopOrder row of Table 2 does not follow from the presented algorithm.
  3. [Section 2.7] The correctness argument is an unsupported assertion. The paper states that StreamNet 'shares the same safety and correctness property as Conflux' solely because both use the GHOST pivot rule, but Conflux's proof is tied to its attachment rule (approving all current tips) and to a total order over all blocks. StreamNet's two-tip rule changes the graph and the Past-based epoch structure. In particular, StreamNetOrder (Algorithm 4) returns only blocks in Past(G,Pivot(G,g)); nothing in the protocol guarantees that a block never chosen as the MCMC reference of a pivot-chain block is in that past, so the existence of a total order over the whole DAG is not established. A concrete example of a side block with no path to the pivot tip is not addressed.
  4. [Section 3.4, Eq. (3)] The genesis forwarding condition in Eq. (3) is not well-formed. For any b on the pivot chain, taking b'=b yields ParentScore(b)>ParentScore(b)+h, which is false for h>0; the intended quantification over 'side chains' is not expressed. Moreover, h is said to be n-m, but n and m are not defined in this section. These problems make Algorithm 8's trigger condition ambiguous and the claim of 'forwarding the genesis' unsupported.
  5. [Section 4.3] The experiments do not substantiate the scalability claim in the abstract. Figures 11 and 12 show absolute TPS values in narrow ranges (about 21-24 and 40-55) with no error bars, no comparison to the non-streaming IRI baseline, and no comparison to other DAG systems; the clusters have at most 7 nodes, and increasing the transaction count from 5k to 20k is not a test of DAG growth over time. The conclusion that 'our method is proven to be able to tolerate the increasing complexity' is therefore not supported by the reported data.
minor comments (6)
  1. [Algorithm 2, line 4] The denominator Σ_{z:z→b} is undefined; the summation variable and the direction of the arrow should be specified (presumably over children of t).
  2. [Section 3.3] The text says the update rule is 'as (1) shows', but the displayed equation is numbered (2).
  3. [Figure 4] The definition of Chain appears twice on the same line; the second definition seems to be the complement of the chain, but the notation is not clear and should be clarified.
  4. [Table 2] The TopOrder complexity is recorded as O(|1|); this should be O(1).
  5. [Algorithm 8] The persistence step computes O−O' where O and O' are total orders; set difference of ordered lists is undefined, and the intended operation should be stated precisely.
  6. [Eq. (1)] The formula for ζ_k contains a negative mean (-qλh t) and appears to be a garbled version of the Conflux bound; it should be corrected and properly referenced.

Circularity Check

0 steps flagged · score 1.0 of 10

No significant circularity; StreamNet's safety claim imports external Conflux/GHOST theorems and no fitted quantity is renamed as a prediction.

full rationale

StreamNet's derivation chain is not circular. The central total-order construction (Algorithm 4, StreamNetOrder) is defined directly from the pivot chain and epoch sets; the pivot chain is chosen by the GHOST-like ParentScore rule, and the confirmation bound in Section 2.7 is imported from Conflux [1] and Theorem 10 of [30]. These are external results, not self-citations by the StreamNet authors, and the paper does not re-derive them from its own fitted constants. The MCMC parameter α and the genesis-forward threshold h are free design parameters with stated roles; they are not fit to the experimental TPS data and then reported as predictions. The only self-reference is the implementation link [46], which is a code pointer and not load-bearing for any correctness claim. One internal defect exists: Algorithm 2's stopping test 'while Score(G,t) != 0' can never become false because Score(G,b) = |Later(G,b)| and Later(G,b) always includes b, and the walk only traverses parent edges; but that is an algorithmic non-termination/type error, not a circular equivalence between an output and an input. Therefore no step in the paper reduces by construction to its own inputs.

Assumptions & free parameters 2 free parameters · 3 assumptions · 0 invented entities

The central claim rests on free parameters alpha and h, plus domain assumptions inherited from prior DAG protocols. No new physical or conceptual entities are introduced. The main weakness is the unproven inheritance of safety properties.

free parameters (2)
  • alpha (MCMC randomness scale)
    In Algorithm 2, alpha controls the randomness of the MCMC tip selection. The paper does not specify a value or a method for choosing it, making it a free protocol parameter.
  • h (genesis forwarding threshold) = 5 (example value in Figure 8)
    In Section 3.4, Eq. (3) defines a threshold h for when to forward the genesis. The paper gives an example value h=5 but no general rule for setting it, so it acts as a hand-chosen parameter.
assumptions (3)
  • domain assumption StreamNet inherits the safety and liveness of Conflux/GHOST because it uses the same pivot chain selection rule.
    Section 2.7 states 'it shares the same safety and correctness property as Conflux' without a proof specific to StreamNet's two-parent attachment rule.
  • domain assumption MCMC tip selection with parameter alpha produces an unbiased random tip.
    Algorithm 2 relies on this; no analysis of the random walk's mixing time or bias is given.
  • domain assumption Standard PoW honest-majority assumption.
    Implicit in inheriting the security arguments from Conflux and GHOST, since those protocols assume a majority of computing power is honest.

how reviews work

0 comments
Cite this review

Pith. "Pith review of StreamNet: A DAG System with Streaming Graph Computing." pith.science (2026). https://pith.science/paper/JBQAOZG7

@misc{pith2026190806405,
  author       = {Pith},
  title        = {Pith review of: StreamNet: A DAG System with Streaming Graph Computing},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/JBQAOZG7}},
  note         = {Machine review of arXiv:1908.06405}
}
read the original abstract

To achieve high throughput in the POW based blockchain systems, researchers proposed a series of methods, and DAG is one of the most active and promising fields. We designed and implemented the StreamNet, aiming to engineer a scalable and endurable DAG system. When attaching a new block in the DAG, only two tips are selected. One is the parent tip whose definition is the same as in Conflux[1]; another is using Markov Chain Monte Carlo (MCMC) technique by which the definition is the same as IOTA [2]. We infer a pivotal chain along the path of each epoch in the graph, and a total order of the graph could be calculated without a centralized authority. To scale up, we leveraged the graph streaming property; high transaction validation speed will be achieved even if the DAG is growing. To scale out, we designed the direct signal gossip protocol to help disseminate block updates in the network, such that messages can be passed in the network more efficiently. We implemented our system based on IOTA's reference code (IRI) and ran comprehensive experiments over the different sizes of clusters of multiple network topologies.

Figures

Figures reproduced from arXiv: 1908.06405 by the authors.

Figure 1
Figure 1. Example of the StreamNet data structure. 2.2 StreamNet Architecture Algorithm 1: StreamNet node main loop. Input: Graph G =< B, g, P, E > 1 while Node is running do 2 if Received G 0 =< B0 , g, P0 , E0 > then 3 G 00 ←< B ∪ B 0 , g, P ∪ P 0 , E ∪ E 0 >; 4 if G 6= G 00 then 5 G ← G 00 ; 6 Broadcase updated G to neighbors ; 7 if Generate block b then 8 a ← P ivot(G, g) ; 9 r ← MCMC(G, g) ; 10 G ←< B ∪ b, g, P∪ < b, a >… view at source ↗
Figure 2
Figure 2. StreamNet architecture. Tx 1 Tx i Tx n Tx 1 Tx 2 Tx i Tx n Tx 1 Tx 2 Tx i Tx n Tx 1 Tx 2 Tx i Tx n CoinBase Tx 1 Tx 2 Tx 3 Tx i Tx n Tx pool Block Generator pack generate [PITH_FULL_IMAGE:figures/full_fig_p005_2.png] view at source ↗
Figure 3
Figure 3. One node in StreamNet protocol [PITH_FULL_IMAGE:figures/full_fig_p005_3.png] view at source ↗
Figures from the paper (9 more)
Figure 4
Figure 4. Figure 4: The Definitions of Chain(), Child(), Sibling(), Subtree(), Before(), Past(), Af￾ter(), Later(), SubGraph(), ParentScore(), Score(), and TotalOrder() [PITH_FULL_IMAGE:figures/full_fig_p006_4.png]
Figure 5
Figure 5. Figure 5: An example of total order calculation. Parent tip Selection by pivotal chain The algorithm Algorithm 3 presents our pivot chain selection algorithm(i.e., the definition of P ivot(G, b)). Given a StreamNet state G, Pivot(G,g) returns the last block in the pivoting chain…
Figure 6
Figure 6. Figure 6: An example of UTXO [PITH_FULL_IMAGE:figures/full_fig_p009_6.png]
Figure 7
Figure 7. Figure 7: shows the example of the GetDiffSet() method for block 5. It first performs forward BFS to find block 4, which does not have children, then it will be added to the diff set. 4, then move forward to 1, which has three children. If it detects 3, which is the parent of 5,…
Figure 8
Figure 8. Figure 8: Example of genesis forward method. historical snapshot total order and be returned. Also, the vertices in the UTXO graph that belongs to the fixed blocks will be eliminated from the memory and be persisted to disk as well. The algorithm is as Algorithm 8 shows. 3.5 The…
Figure 9
Figure 9. Figure 9: Block header format, the main transaction information is stored in the sig￾nature part. The addr is sender’s address, the timestamp is the time the block has been created, current/last index and the bundle is used for storing the bundle informa￾tion, trunk and branch a…
Figure 10
Figure 10. Figure 10: Cluster set up for different network topologies. We have used the AWS cloud services with 7 virtual machines, for each node, it includes a four-core AMD EPYC 7571, with 16 Gb of memory size and 296Gb of disk size. The JAVA version is 1.8, we have deployed our service …
Figure 11
Figure 11. Figure 11: Experimental results for block generation rate. our method is proven to be able to tolerate the increasing complexity of the graph computation problems involved. This is due to the streaming graph computing techniques we have introduced in this paper. References 1. Ch…
Figure 12
Figure 12. Figure 12: Experimental results for bundle transaction. 8. Saveen A Abeyratne and Radmehr P Monfared. Blockchain ready manufacturing supply chain using distributed ledger. 2016. 9. Asaph Azaria, Ariel Ekblaw, Thiago Vieira, and Andrew Lippman. Medrec: Using blockchain for medica…

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

49 extracted references · 43 canonical work pages

  1. [1]

    Scal- ing nakamoto consensus to thousands of transactions per second

    Chenxing Li, Peilun Li, Wei Xu, Fan Long, and Andrew Chi-chih Yao. Scal- ing nakamoto consensus to thousands of transactions per second. arXiv preprint arXiv:1805.03870, 2018

    arXiv 2018

  2. [2]

    The tangle

    Serguei Popov. The tangle. cit. on , page 131, 2016

    work page 2016

  3. [3]

    Bitcoin: A peer-to-peer electronic cash system

    Satoshi Nakamoto. Bitcoin: A peer-to-peer electronic cash system. 2008

    2008

  4. [4]

    Blockchain technology

    JW MICHAEL, ALAN COHN, and JARED R BUTCHER. Blockchain technology. The Journal , 2018

    work page 2018

  5. [5]

    How blockchain is changing finance

    Alex Tapscott and Don Tapscott. How blockchain is changing finance. Harvard Business Review, 1, 2017

    work page 2017

  6. [6]

    Digital supply chain transforma- tion toward blockchain integration

    Kari Korpela, Jukka Hallikas, and Tomi Dahlberg. Digital supply chain transforma- tion toward blockchain integration. In proceedings of the 50th Hawaii international conference on system sciences , 2017

    work page 2017

  7. [7]

    An agri-food supply chain traceability system for china based on rfid & blockchain technology

    Feng Tian. An agri-food supply chain traceability system for china based on rfid & blockchain technology. In Service Systems and Service Management (ICSSSM), 2016 13th International Conference on , pages 1–6. IEEE, 2016. 22 Zhaoming Yin et al. 40 45 50 55 5000 10000 15000 20000 num_txn TPS cluster_size 3_clique 4_circle 4_clique 7_bridge 7_circle 7_clique ...

    work page 2016

  8. [8]

    Blockchain ready manufacturing supply chain using distributed ledger

    Saveen A Abeyratne and Radmehr P Monfared. Blockchain ready manufacturing supply chain using distributed ledger. 2016

    2016

Show all 49 references
  1. [9]

    Medrec: Using blockchain for medical data access and permission management

    Asaph Azaria, Ariel Ekblaw, Thiago Vieira, and Andrew Lippman. Medrec: Using blockchain for medical data access and permission management. In Open and Big Data (OBD), International Conference on , pages 25–30. IEEE, 2016

    2016

  2. [10]

    Healthcare data gateways: found healthcare intelligence on blockchain with novel privacy risk control

    Xiao Yue, Huiju Wang, Dawei Jin, Mingqiang Li, and Wei Jiang. Healthcare data gateways: found healthcare intelligence on blockchain with novel privacy risk control. Journal of medical systems , 40(10):218, 2016

    2016

  3. [11]

    Blockchains and smart con- tracts for the internet of things

    Konstantinos Christidis and Michael Devetsikiotis. Blockchains and smart con- tracts for the internet of things. Ieee Access, 4:2292–2303, 2016

    2016

  4. [12]

    Segregated witness, 2015

    Eric Lombrozo, Johnson Lau, and P WUILLE. Segregated witness, 2015

    2015

  5. [13]

    The bitcoin lightning network: Scalable off- chain instant payments, 2016

    Joseph Poon and Thaddeus Dryja. The bitcoin lightning network: Scalable off- chain instant payments, 2016

    2016

  6. [14]

    Plasma: Scalable autonomous smart contracts

    Joseph Poon and Vitalik Buterin. Plasma: Scalable autonomous smart contracts. White paper, pages 1–47, 2017

    2017

  7. [15]

    Dash: A payments-focused cryptocurrency, 2018

    Evan Duffield and Daniel Diaz. Dash: A payments-focused cryptocurrency, 2018

    2018

  8. [16]

    Advanced decentralized blockchain platform

    TRON Foundation. Advanced decentralized blockchain platform. Whitepaper) https://tron.network/static/doc/white paper v 2 0.pdf, 2018

    2018

  9. [17]

    Ouroboros praos: An adaptively-secure, semi-synchronous proof-of-stake protocol

    Bernardo Machado David, Peter Gazi, Aggelos Kiayias, and Alexander Russell. Ouroboros praos: An adaptively-secure, semi-synchronous proof-of-stake protocol. IACR Cryptology ePrint Archive , 2017:573, 2017. StreamNet 23

    2017

  10. [18]

    Ethereum: A secure decentralised generalised transaction ledger

    Gavin Wood. Ethereum: A secure decentralised generalised transaction ledger. Ethereum project yellow paper , 151:1–32, 2014

    2014

  11. [19]

    Tezosa self-amending crypto-ledger white paper

    LM Goodman. Tezosa self-amending crypto-ledger white paper. URL: https://www. tezos. com/static/papers/white paper. pdf, 2014

    2014

  12. [20]

    Aion: Enabling the decentralized internet

    Spoke Matthew and Engineering Team Nuco. Aion: Enabling the decentralized internet. Aion project yellow paper , 151:1–22, 2017

    2017

  13. [21]

    Practical byzantine fault tolerance

    Miguel Castro, Barbara Liskov, et al. Practical byzantine fault tolerance. In OSDI, volume 99, pages 173–186, 1999

    1999

  14. [22]

    Bitcoin- ng: A scalable blockchain protocol

    Ittay Eyal, Adem Efe Gencer, Emin G¨ un Sirer, and Robbert Van Renesse. Bitcoin- ng: A scalable blockchain protocol. In NSDI, pages 45–59, 2016

    2016

  15. [23]

    The honey badger of bft protocols

    Andrew Miller, Yu Xia, Kyle Croman, Elaine Shi, and Dawn Song. The honey badger of bft protocols. In Proceedings of the 2016 ACM SIGSAC Conference on Computer and Communications Security , pages 31–42. ACM, 2016

    2016

  16. [24]

    Enhancing bitcoin security and performance with strong consistency via collective signing

    Eleftherios Kokoris Kogias, Philipp Jovanovic, Nicolas Gailly, Ismail Khoffi, Linus Gasser, and Bryan Ford. Enhancing bitcoin security and performance with strong consistency via collective signing. In 25th USENIX Security Symposium (USENIX Security 16), pages 279–296, 2016

    2016

  17. [25]

    Algorand: Scaling byzantine agreements for cryptocurrencies

    Yossi Gilad, Rotem Hemo, Silvio Micali, Georgios Vlachos, and Nickolai Zeldovich. Algorand: Scaling byzantine agreements for cryptocurrencies. In Proceedings of the 26th Symposium on Operating Systems Principles , pages 51–68. ACM, 2017

    2017

  18. [26]

    The ripple protocol consensus algorithm

    David Schwartz, Noah Youngs, Arthur Britto, et al. The ripple protocol consensus algorithm. Ripple Labs Inc White Paper , 5, 2014

    2014

  19. [27]

    The stellar consensus protocol: A federated model for internet- level consensus

    David Mazieres. The stellar consensus protocol: A federated model for internet- level consensus. Stellar Development Foundation , 2015

    2015

  20. [28]

    Cosmos: A network of distributed ledgers

    Jae Kwon and Ethan Buchman. Cosmos: A network of distributed ledgers. URL https://cosmos. network/whitepaper, 2016

    2016

  21. [29]

    Accelerating bitcoins transaction process- ing

    Yonatan Sompolinsky and Aviv Zohar. Accelerating bitcoins transaction process- ing. Fast Money Grows on Trees, Not Chains , 2013

    2013

  22. [30]

    Secure high-rate transaction processing in bitcoin

    Yonatan Sompolinsky and Aviv Zohar. Secure high-rate transaction processing in bitcoin. In International Conference on Financial Cryptography and Data Security , pages 507–527. Springer, 2015

    2015

  23. [31]

    Inclusive block chain pro- tocols

    Yoad Lewenberg, Yonatan Sompolinsky, and Aviv Zohar. Inclusive block chain pro- tocols. In International Conference on Financial Cryptography and Data Security , pages 528–547. Springer, 2015

    2015

  24. [32]

    Spectre: Serialization of proof-of-work events: confirming transactions via recursive elections, 2016

    Yonatan Sompolinsky, Yoad Lewenberg, and Aviv Zohar. Spectre: Serialization of proof-of-work events: confirming transactions via recursive elections, 2016

    2016

  25. [33]

    Phantom, ghostdag

    Yonatan Sompolinsky and Aviv Zohar. Phantom, ghostdag

  26. [34]

    Byteball: A decentralized system for storage and transfer of value

    Anton Churyumov. Byteball: A decentralized system for storage and transfer of value. URL https://byteball. org/Byteball. pdf , 2016

    2016

  27. [35]

    The swirlds hashgraph consensus algorithm: Fair, fast, byzantine fault tolerance

    Leemon Baird. The swirlds hashgraph consensus algorithm: Fair, fast, byzantine fault tolerance. Swirlds Tech Reports SWIRLDS-TR-2016-01, Tech. Rep. , 2016

    2016

  28. [36]

    Blockmania: from block dags to consensus

    George Danezis and David Hrycyszyn. Blockmania: from block dags to consensus. arXiv preprint arXiv:1809.01620 , 2018

    2018 arXiv

  29. [37]

    Nano: A feeless distributed cryptocurrency network

    Colin LeMahieu. Nano: A feeless distributed cryptocurrency network. Nano [On- line resource]. URL: https://nano. org/en/whitepaper (date of access: 24.03. 2018) , 2018

    2018

  30. [38]

    Vite: A high performance asyn- chronous decentralized application platform

    Chunming Liu, Daniel Wang, and Ming Wu. Vite: A high performance asyn- chronous decentralized application platform

  31. [39]

    Tracking structure of streaming social networks

    David Ediger, Jason Riedy, David A Bader, and Henning Meyerhenke. Tracking structure of streaming social networks. In 2011 IEEE International Parallel & 24 Zhaoming Yin et al. Distributed Processing Symposium Workshops and PhD Forum , pages 1691–1699. IEEE, 2011

    2011

  32. [40]

    A fast algorithm for incremental betweenness centrality

    Oded Green, Robert McColl, and DA Bader. A fast algorithm for incremental betweenness centrality. In Proceeding of SE/IEEE international conference on social computing (SocialCom) , pages 3–5, 2012

    2012

  33. [41]

    Stinger: High per- formance data structure for streaming graphs

    David Ediger, Rob McColl, Jason Riedy, and David A Bader. Stinger: High per- formance data structure for streaming graphs. In 2012 IEEE Conference on High Performance Extreme Computing , pages 1–5. IEEE, 2012

    2012

  34. [42]

    Epidemic algorithms for repli- cated database maintenance

    Alan Demers, Dan Greene, Carl Houser, Wes Irish, John Larson, Scott Shenker, Howard Sturgis, Dan Swinehart, and Doug Terry. Epidemic algorithms for repli- cated database maintenance. ACM SIGOPS Operating Systems Review , 22(1):8– 32, 1988

    1988

  35. [43]

    bloxroute: A scalable trustless blockchain distribution network whitepaper

    Uri Klarman, Soumya Basu, Aleksandar Kuzmanovic, and Emin G¨ un Sirer. bloxroute: A scalable trustless blockchain distribution network whitepaper

  36. [44]

    Hyperledger fabric: a distributed operating system for permissioned blockchains

    Elli Androulaki, Artem Barger, Vita Bortnikov, Christian Cachin, Konstantinos Christidis, Angelo De Caro, David Enyeart, Christopher Ferris, Gennady Lavent- man, Yacov Manevich, et al. Hyperledger fabric: a distributed operating system for permissioned blockchains. In Proceedi...

    2018

  37. [45]

    https://github.com/iotaledger/iri

    Iota reference implementation. https://github.com/iotaledger/iri

  38. [46]

    https://github.com/triasteam/iri

    Streamnet reference implementation. https://github.com/triasteam/iri

  39. [47]

    http://rocksdb.org

    Rocksdb reference implementation. http://rocksdb.org

  40. [48]

    Apache JMeter: A practical beginner’s guide to automated testing and performance measurement for your websites

    Emily H Halili. Apache JMeter: A practical beginner’s guide to automated testing and performance measurement for your websites . Packt Publishing Ltd, 2008

    2008

  41. [49]

    Nginx HTTP Server: Adopt Nginx for Your Web Applications to Make the Most of Your Infrastructure and Serve Pages Faster Than Ever

    Cl´ ement Nedelcu. Nginx HTTP Server: Adopt Nginx for Your Web Applications to Make the Most of Your Infrastructure and Serve Pages Faster Than Ever . Packt Publishing Ltd, 2010

    2010

Pith tools

Reviewed August 14, 2026 · model on record in the stance chip above.