Pith. sign in

REVIEW 2 major objections 3 minor 44 references

Setchain Algorithms for Blockchain Scalability

T0 review · 2 major / 3 minor · reviewed 2026-08-15 · deepseek-v4-flash

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

Pith's one-line read Setchain algorithms show that replacing a blockchain's total order with unordered epochs yields far higher throughput and verifiable light-client proofs.

desk verdict First, the stress-test is right: Hashchain can violate Consistent-Gets under its own model, and the same scenario breaks Eventual-Get; the epoch-proof idea and the two simpler algorithms are still worth a referee's time. read the letter →

arxiv 2509.09795 v1 pith:PDMMQSDM submitted 2025-09-11 cs.DC cs.DBcs.DScs.PF

Arivarasan Karmegam , Gabina Luz Bianchi , Margarita Capretto , Martín Ceresa , Antonio Fernández Anta , César Sánchez This is my paper · ORCID
classification cs.DCcs.DBcs.DScs.PF
keywords SetchainblockchainscalabilityByzantinefaulttoleranceepoch-proofsCometBFThashbatchingthroughputfinality
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

The paper aims to show that a blockchain's throughput bottleneck is largely due to requiring a total order over every transaction, and that replacing that with a sequence of unordered sets (epochs) removes much of the bottleneck. It proposes three algorithms built on top of an existing block-based ledger: Vanilla, which simply writes each element as a ledger transaction; Compresschain, which batches and compresses elements into one ledger transaction; and Hashchain, which appends only a signed hash of a batch and later reconstructs the batch through a distributed lookup. The reported measurements put Hashchain at tens of thousands of elements per second—more than an order of magnitude above the underlying ledger's roughly 955 elements per second—with commit latency below four seconds. The paper also introduces epoch-proofs, signatures that let a client verify an epoch by contacting a single server rather than many.

What carries the argument

The central object is the Setchain: a grow-only set of elements partitioned into epochs, where elements inside an epoch are unordered and only epoch boundaries impose a total order. The mechanism that carries the throughput argument is batching with hash anchoring: Hashchain collapses a large batch of elements to a fixed-size signed hash, appends that hash to the ledger, stores the batch off-chain, and only consolidates a batch into an epoch after f+1 servers have signed the same hash, guaranteeing at least one honest server can produce the original batch. Epoch-proofs—each server's signature over Hash(epoch, history[epoch])—are appended to the ledger so a client can trust an epoch with f+1 matching proofs. In Compresschain, the analogous mechanism is lossless compression of batches before appending; in Vanilla, each element is a separate ledger transaction and throughput matches the ledger.

What would settle it

On the performance side, reproduce the 10-server, 0.5 MB-block experiment with a 25,000 el/s sending rate and measure committed elements per second; a number far below the reported roughly 20,000 el/s with hash-reversal would refute the throughput claim. On the semantic side, give one Byzantine server client privileges and check whether an element no client ever added can enter an epoch; if it does, Property 7 (Add-before-Get) is violated.

Watch

Extended reading notes

Core claim

On its own terms, the paper's central claim is that a Byzantine-tolerant Setchain—an ordered sequence of unordered epochs—can be implemented on any block-based ledger, and that the hash-based version, Hashchain, achieves throughput orders of magnitude above the ledger itself while preserving the safety and liveness properties required of a Setchain. The key empirical claim is that Hashchain reaches an average of 20,061 elements per second with hash-reversal enabled and 133,882 elements per second when hash-reversal is disabled, compared with roughly 955 elements per second for the bare CometBFT ledger, with finality (f+1 epoch-proofs in the ledger) latency below four seconds.

Load-bearing premise

The argument that every element in an epoch was genuinely added by a client rests on the assumption that a server cannot create a valid element on its own and never colludes with clients; if a Byzantine server can also act as a client, that guarantee breaks even though throughput is unaffected.

Editorial extensions

If this is right

  • If the algorithms are correct, any application that needs ordering only across epoch barriers—digital registries, voting systems, certificate issuance—can run on a Setchain at a fraction of the ledger's per-element cost.
  • The throughput of Hashchain is bounded mainly by the ledger block size and the cost of off-chain batch retrieval, not by the consensus itself; the paper's analytical model predicts over one million elements per second at 4 MB blocks and over thirty million at 128 MB blocks.
  • Light clients can verify epoch membership with f+1 epoch-proofs obtained from a single server, reducing access cost from contacting multiple servers to one round trip per add and one per get.
  • Because the algorithms are implemented on CometBFT, they inherit its f < n/3 resilience bound even though the Setchain algorithms only require f < n/2, so switching to a weaker consensus service could raise fault tolerance or reduce overhead.
  • The measured bottleneck in hash-reversal suggests that replacing the naive batch-distribution service with a more efficient one, such as fewer signers or optimistic validation, would directly translate into higher throughput.

Reading between the lines

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

  • The same hash-anchoring pattern generalizes beyond Setchain: any replicated object whose payload is large and whose ordering is not the bottleneck can append a signed digest and serve the payload off-chain, at the cost of a retrieval step and a quorum of signers.
  • Because the paper's validity condition assumes clients and servers do not collude, a natural adversarial test is to let a Byzantine validator behave as an ordinary client and attempt to inject an element with no preceding client add; the Add-before-Get property would fail if such an element is ever included in an epoch.
  • The authors' proposed extension to a full blockchain—optimistically validating transactions in parallel within an epoch and applying effects sequentially only after consolidation—implies a trade-off between epoch size and per-validator resource requirements; larger epochs improve throughput but can exclude weaker servers.
  • Comparing the three algorithms suggests that compression gives a modest constant-factor gain over Vanilla, whereas the gain from Hashchain is structural because its on-chain footprint is fixed-size; further work should focus on making off-chain retrieval cheaper rather than improving compression.
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

2 major / 3 minor

Summary. The paper proposes a family of Setchain implementations on top of a block-based ledger (CometBFT): Vanilla, Compresschain, and Hashchain. It extends the Setchain object with epoch-proofs that let a light client validate an epoch from f+1 signatures, and it states eight correctness properties. Correctness proofs are given in Appendix C, and a performance evaluation on clusters of 4, 7, and 10 servers reports throughput up to tens of thousands of elements per second and commit latency below 4 seconds. Hashchain, the main contribution, replaces batches by hashes and consolidates an epoch when f+1 servers have signed the batch hash.

Significance. Setchain is a plausible scalability layer for applications that tolerate intra-epoch reordering, and the paper is the first to provide a real implementation on CometBFT with epoch-proofs. If the correctness claims held, the throughput results (20,061 el/s for Byzantine-tolerant Hashchain with hash-reversal versus about 955 el/s for the bare ledger) would be a useful data point. The paper's honest reporting of the hash-reversal bottleneck and its analytical throughput model are strengths. However, the central safety proof for Hashchain is flawed, so the contribution as written does not establish a correct Byzantine-tolerant Setchain.

major comments (2)
  1. [Appendix C.3 (Lemma 24); Algorithm Hashchain, Lines 25-31 and 39-40] Property 6 (Consistent-Gets) does not hold under the stated Byzantine model, so Lemma 24 is false. The proof assumes that because all correct servers observe the same ledger blocks in the same order, the f+1-th signature used to consolidate a hash is the same for all correct servers. But in Algorithm Hashchain a server counts signer w for hash h only after it has obtained a valid batch for h (Lines 25-31) and then executes Line 39. A Byzantine signer B can answer Request_batch(h1) to server C1 and drop it for server C2. Take n=4, f=1 and suppose the ledger order of hash-batches is B(h1), C1(h1), C2(h2), C3(h2), where C1 is correct and, after retrieving h1 from B, appends its own hash-batch. C1 counts B and itself for h1 and consolidates h1 before h2; C2 cannot count B, counts C2 and C3 for h2, and consolidates h2 before h1 (later consolidating h1 after retrieving it from C1). Both servers are correct and see the same ledger, but their epoch histories are [h1,h2] and [h2,h1], permanently violating Property 6. The local threshold event in Line 40 depends on network-dependent retrieval success rather than only on ledger order, so the proof's key step 'by Properties 9 and 10, it will be the f+1-th signature w receives for hash hs' is invalid. This is a safety violation in the central Hashchain algorithm and must be fixed, for example by making consolidation depend only on ledger-visible f+1 signatures and then retrieving the batch from a correct signer, with a reworked proof.
  2. [Section 2, Property 7; Lemmas 7, 15, 25] The Add-before-Get guarantee rests entirely on the assumption that 'a server cannot create a valid element by itself, and that clients and servers do not collude.' This is not a consequence of the stated PKI model, since servers are also processes with key pairs and can invoke client operations. In the 'open permissioned' model that the paper targets, validators are typically also clients, and in permissionless settings committee members are drawn from the same population as transaction issuers. As stated, the safety guarantee is therefore conditional on a substantial external restriction (e.g., elements must be signed by an authority that cannot be a server). The paper should state this restriction explicitly and, ideally, give an instantiation of valid_element that enforces it or discuss how the assumption can be relaxed.
minor comments (3)
  1. [Section 4.1, Table 2 and Figure 2] The quantitative throughput claims are based on single experimental runs; please report the number of repetitions and the variance (error bars or confidence intervals). In particular, the 133,882 el/s figure is obtained by the 'Hashchain Light' configuration that removes hash-reversal and validation and assumes all servers correct; this should be clearly labeled as an upper-bound study rather than as throughput of the Byzantine-tolerant Hashchain. Even with this caveat, the Byzantine-tolerant Hashchain throughput of about 20,061 el/s is still meaningfully above the bare ledger.
  2. [Section 4.1, right panel of Figure 2] There are typos: 'CommetBFT' and 'Haschain' should be 'CometBFT' and 'Hashchain'.
  3. [Appendix D] The analytical throughput formulas assume all n servers are correct and sign each hash-batch. Since the paper's model allows up to f Byzantine servers, the formulas should be described as upper bounds for the fully Byzantine case, and the text should make this explicit.

Circularity Check

0 steps flagged · score 0.0 of 10

No circularity: correctness proofs and throughput analysis are self-contained; prior-work citation is background only.

full rationale

The derivation chain is self-contained. The three analytical throughput formulas in Appendix D are derived from block capacity, element/proof/hash sizes, collector size, compression ratio, and block rate, and are used only as sanity-check envelopes against the measured throughput. No throughput value is fitted from the measurements, and the compression ratio is measured and reported rather than tuned to match the throughput curves. The correctness proofs for Vanilla, Compresschain, and Hashchain are inductive arguments from the ledger properties (Ledger-Add-Eventual-Notify, Ledger-Consistent-Notification, Notification-Implies-Append) and from explicit algorithm invariants; they do not assume the Setchain properties they establish (Consistent-Sets, Add-Get-Local, Get-Global, Eventual-Get, Unique-Epoch, Consistent-Gets, Add-before-Get, Valid-Epoch). The f+1 consolidation threshold and the f+1 epoch-proof verification rule are design choices justified by the f<n/2 Byzantine-server assumption, not conclusions smuggled from an earlier result. The only self-citations are background references to the authors' original Setchain paper [12] for the object's definition and motivation; no load-bearing theorem, uniqueness argument, or fitted parameter from that paper is used in the new proofs or benchmarks. Disputes about Hashchain's Consistent-Gets proof are correctness concerns, not circularity, because the proof does not reduce to its own conclusion. Hence, no circular step is present.

Assumptions & free parameters 1 free parameters · 5 assumptions · 2 invented entities

The central claims rest on a standard cryptographic layer, a set of domain assumptions about the ledger and communication, and the strong no-collusion assumption that distinguishes Setchain from general blockchain settings. No free parameters are fitted to make the results match; the reported compression ratio is measured.

free parameters (1)
  • Compression ratio r for Compresschain = r≈2.7 (collector 100), r≈3.5 (collector 500)
    Measured from the evaluation data (Section 4, 'The average length of a compressed batch...'), used in the analytical throughput formula Tc in Section D. This is a measured property of Brotli on the Arbitrum dataset, not a constant fit to make the measured throughput match the formula.
assumptions (5)
  • domain assumption A server cannot create a valid element by itself, and clients and servers do not collude.
    Invoked in the proof of Property 7 (Add-before-Get) for all three algorithms (Lemmas 7, 15, 25). If a server could create valid elements, it could populate epochs without client add operations, breaking Setchain semantics. Section 2, System Model.
  • domain assumption Reliable communication: messages between correct processes are eventually delivered only once, and no spurious messages are generated.
    Assumed in Section 2 and used throughout the liveness proofs (e.g., eventual delivery of blocks and hash-batch requests). Loss of messages could stall epoch increments or hash retrieval.
  • domain assumption The block-based ledger satisfies Properties 9-11: valid appended transactions are eventually and permanently in a block notified to all correct servers in the same order, and notification implies a prior append.
    The correctness proofs reduce all Setchain properties to these ledger guarantees (Section 2, Block-based Ledger, and Appendix C). If the ledger lacks finality or consistent notification, epoch consistency fails.
  • domain assumption At any given time, there will be a future epoch increment, ensured via timeouts.
    Stated in Section 2 as an assumption to guarantee liveness; the concrete timeout mechanism is not specified.
  • standard math SHA512 is collision-resistant and ed25519 signatures are unforgeable.
    Hashchain and epoch-proofs rely on hash integrity and signature validity (Section 4). If collisions or forgeries exist, a Byzantine server could forge epochs.
invented entities (2)
  • epoch-proof independent evidence
    purpose: A server's signature over the hash of an epoch number and its elements, stored in the Setchain proofs set so a light client can verify an epoch by checking f+1 signatures from a single server.
    Epoch-proofs are concrete cryptographic objects: any client with the server public keys can verify them, and they are propagated through the ledger. This is a new artifact introduced by this paper.
  • hash-batch independent evidence
    purpose: A ledger transaction containing a hash of a batch plus a server signature, used by Hashchain to reduce the data appended to the ledger; the batch contents are served out-of-band via a distributed hash-reversal service.
    Hash-batches are verifiable against the original batch via the hash, and the paper measures their effect on throughput. They add a communication assumption (availability of the batch-sharing service) that is the identified bottleneck.

how reviews work

0 comments
Cite this review

Pith. "Pith review of Setchain Algorithms for Blockchain Scalability." pith.science (2026). https://pith.science/paper/PDMMQSDM

@misc{pith2026250909795,
  author       = {Pith},
  title        = {Pith review of: Setchain Algorithms for Blockchain Scalability},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/PDMMQSDM}},
  note         = {Machine review of arXiv:2509.09795}
}
abstract

Setchain has been proposed to increase blockchain scalability by relaxing the strict total order requirement among transactions. Setchain organizes elements into a sequence of sets, referred to as epochs, so that elements within each epoch are unordered. In this paper, we propose and evaluate three distinct Setchain algorithms, that leverage an underlying block-based ledger. Vanilla is a basic implementation that serves as a reference point. Compresschain aggregates elements into batches, and compresses these batches before appending them as epochs in the ledger. Hashchain converts batches into fixed-length hashes which are appended as epochs in the ledger. This requires Hashchain to use a distributed service to obtain the batch contents from its hash. To allow light clients to safely interact with only one server, the proposed algorithms maintain, as part of the Setchain, proofs for the epochs. An epoch-proof is the hash of the epoch, cryptographically signed by a server. A client can verify the correctness of an epoch with $f+1$ epoch-proofs (where $f$ is the maximum number of Byzantine servers assumed). All three Setchain algorithms are implemented on top of the CometBFT blockchain application platform. We conducted performance evaluations across various configurations, using clusters of four, seven, and ten servers. Our results show that the Setchain algorithms reach orders of magnitude higher throughput than the underlying blockchain, and achieve finality with latency below 4 seconds.

Figures

Figures reproduced from arXiv: 2509.09795 by the authors.

Figure 1
Figure 1. Throughput over time of the Setchain algorithms for ( [PITH_FULL_IMAGE:figures/full_fig_p012_1.png] view at source ↗
Figure 2
Figure 2. (left) Highest throughput measured in the evaluatio [PITH_FULL_IMAGE:figures/full_fig_p013_2.png] view at source ↗
Figure 3
Figure 3. Efficiency values observed under different scenarios. [PITH_FULL_IMAGE:figures/full_fig_p014_3.png] view at source ↗
Figures from the paper (2 more)
Figure 4
Figure 4. Figure 4: Cumulative distribution function F(x) of the latency experienced by the ele￾ments added to the Setchain to reach several stages in their process for (left) Vanilla, (center) Compresschain and (right) Hashchain. Collector size is 100. The scenario is with 10 servers, a …
Figure 5
Figure 5. Figure 5: Commit times observed under different scenarios. The [PITH_FULL_IMAGE:figures/full_fig_p035_5.png]

Review history (2 revisions) →

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

44 extracted references · 26 canonical work pages

  1. [1]

    https://ethereum.org /en/roadmap/danksharding/

    Ethereum roadmap - danksharding. https://ethereum.org /en/roadmap/danksharding/

    work page

  2. [2]

    https://github.com/matter-la bs/zksync-era

    Matter labs - zksync era. https://github.com/matter-la bs/zksync-era

    work page

  3. [3]

    Ethereum development documentation - block size (2025), https://ethereum.org/en/developers/docs/blocks/#block-size

    work page 2025

  4. [4]

    RFC 7932 (Jul 2016)

    Alakuijala, J., Szabadka, Z.: Brotli Compressed Data For mat. RFC 7932 (Jul 2016). https://doi.org/10.17487/RFC7932, https://www.rfc-editor.org/info/rfc7932

    doi:10.17487/rfc7932 2016

  5. [5]

    Barger, A., Manevich, Y., Meir, H., Tock, Y.: A byzantine f ault-tolerant consensus library for hyperledger fabric (2021), https://arxiv.org /abs/2107.06922

    arXiv 2021

  6. [6]

    Journal of Cryptographic Engineer- ing 2(2), 77–89 (Sep 2012)

    Bernstein, D.J., Duif, N., Lange, T., Schwabe, P., Yang, B .Y.: High- speed high-security signatures. Journal of Cryptographic Engineer- ing 2(2), 77–89 (Sep 2012). https://doi.org/10.1007/s13389-0 12-0027-1, https://doi.org/10.1007/s13389-012-0027-1

    work page doi:10.1007/s13389-0 2012

  7. [7]

    Blockcerts: Blockcerts: The open standard for blockchai n credentials, https://github.com/blockchain-certificates

    work page

  8. [8]

    Blocknative: Ethereum merge: The impact of proof-of-sta ke (2022), https://www.blocknative.com/blog/ethereum-merge-proof-of-stake

    work page 2022

Show all 44 references
  1. [9]

    In: 2024 43rd International Symposium on Reliable Distributed Systems (SRDS)

    Boitier, W., Del Pozzo, A., Garcia-Perez, A., Gazut, S., J obic, P., Lemaire, A., Mahe, E., Mayoue, A., Perion, M., Rezende, T.F., Singh, D., T ucci-Piergiovanni, S.: Fantastyc: Blockchain-based federated learning made s ecure and practical. In: 2024 43rd International Symposi...

    2024 doi

  2. [10]

    CoRR abs/1807.04938 (2018), http://arxiv.org/abs/1807.04938

    Buchman, E., Kwon, J., Milosevic, Z.: The latest gossip o n BFT consensus. CoRR abs/1807.04938 (2018), http://arxiv.org/abs/1807.04938

    2018 arXiv

  3. [11]

    Buchnik, Y., Friedman, R.: Fireledger: A high throughpu t blockchain consensus protocol (2019), https://arxiv.org/abs/1901.03279

    2019 arXiv

  4. [12]

    Di stributed Ledger Tech- nologies: Research and Practice 3(2) (jun 2024)

    Capretto, M., Ceresa, M., Fernández Anta, A., Russo, A., Sánchez, C.: Improv- ing blockchain scalability with the setchain data-type. Di stributed Ledger Tech- nologies: Research and Practice 3(2) (jun 2024). https://doi.org/10.1145/3626963, https://doi.org/10.1145/3626963

    2024 doi

  5. [13]

    In: 2021 40th International Symposium on Reliable Distributed Systems (SRDS)

    Cason, D., Fynn, E., Milosevic, N., Milosevic, Z., Buchm an, E., Pedone, F.: The design, architecture and performance of the tendermint blo ckchain network. In: 2021 40th International Symposium on Reliable Distributed Systems (SRDS). pp. 23–33 (2021). https://doi.org/10.1109/...

    2021

  6. [14]

    ACM Trans

    Castro, M., Liskov, B.: Practical byzantine fault toler ance and proac- tive recovery. ACM Trans. Comput. Syst. 20(4), 398–461 (2002). https://doi.org/10.1145/571637.571640, https://doi.org/10.1145/571637.571640

    2002

  7. [15]

    In: 2021 IEEE Symposium on Security and Privacy (SP)

    Crain, T., Natoli, C., Gramoli, V.: Red belly: A secure, f air and scalable open blockchain. In: 2021 IEEE Symposium on Security and Privacy (SP). pp. 466–483 (2021). https://doi.org/10.1109/SP40001.2021.00087 Setchain Algorithms for Blockchain Scalability 17

    2021

  8. [16]

    In: Pro- ceedings of the Seventeenth European Conference on Compute r Sys- tems

    Danezis, G., Kokoris-Kogias, L., Sonnino, A., Spiegelm an, A.: Narwhal and tusk: a dag-based mempool and efficient bft consensus. In: Pro- ceedings of the Seventeenth European Conference on Compute r Sys- tems. p. 34–50. EuroSys ’22, Association for Computing Mach inery, New Yor...

    2022

  9. [17]

    Fabric, H.: Hyperledger fabric v3.0.0 release (2023), https://github.com/hyperledger/fabric/releases/tag/v3.0.0

    2023

  10. [18]

    Morgan & Claypool Publishers (2021)

    Fernández Anta, A., Georgiou, C., Herlihy, M., Potop-Bu tucaru, M.: Principles of Blockchain Systems. Morgan & Claypool Publishers (2021)

    2021

  11. [19]

    ACM Sigact News 49(2), 58–76 (2018)

    Fernández Anta, A., Konwar, K., Georgiou, C., Nicolaou, N.: Formalizing and implementing distributed ledger objects. ACM Sigact News 49(2), 58–76 (2018)

    2018

  12. [20]

    Fu, Y., Jing, M., Zhou, J., Wu, P., Wang, Y., Zhang, L., Hu, C.: Quantifying the blockchain trilemma: A comparative analysis of algoran d, ethereum 2.0, and beyond (2024), https://ar5iv.labs.arxiv.org/html/2407.14335v1, accessed: 2024-10- 01

    2024 arXiv

  13. [21]

    In: Proceedin gs of the 26th Symposium on Operating Systems Principles

    Gilad, Y., Hemo, R., Micali, S., Vlachos, G., Zeldovich, N.: Algorand: Scaling byzantine agreements for cryptocurrencies. In: Proceedin gs of the 26th Symposium on Operating Systems Principles. p. 51–68. SOSP ’17, Associ ation for Computing Machinery, New York, NY, USA (2017)....

    2017

  14. [22]

    In: Proceedings of the Eighteen th European Conference on Computer Systems

    Gramoli, V., Guerraoui, R., Lebedev, A., Natoli, C., Vor on, G.: Diablo: A bench- mark suite for blockchains. In: Proceedings of the Eighteen th European Conference on Computer Systems. p. 540–556. EuroSys ’23, Association f or Computing Ma- chinery, New York, NY, USA (2023). ...

    2023

  15. [23]

    In: Proceedings of the 2020 ACM SIGSAC Conferenc e on Computer and Communications Security

    Guo, B., Lu, Z., Tang, Q., Xu, J., Zhang, Z.: Dumbo: Faster asynchronous bft protocols. In: Proceedings of the 2020 ACM SIGSAC Conferenc e on Computer and Communications Security. p. 803–818. CCS ’20, Associat ion for Computing Machinery, New York, NY, USA (2020). https://doi....

    2020

  16. [24]

    Josefsson, S., Liusvaara, I.: Rfc 8032: Edwards-curve d igital signature algorithm (eddsa) (2017)

    2017

  17. [25]

    In: 27th USENIX Securit y Symposium (USENIX Security 18)

    Kalodner, H., Goldfeder, S., Chen, X., Weinberg, S.M., F elten, E.W.: Arbitrum: Scalable, private smart contracts. In: 27th USENIX Securit y Symposium (USENIX Security 18). pp. 1353–1370. USENIX Association, Baltimor e, MD (Aug 2018), https://www.usenix.org/conference/usenixse...

    2018

  18. [26]

    In: 2018 IEEE Symposium on Security and Privacy (SP)

    Kokoris-Kogias, E., Jovanovic, P., Gasser, L., Gailly, N., Syta, E., Ford, B.: Omniledger: A secure, scale-out, decentralized ledger via sharding. In: 2018 IEEE Symposium on Security and Privacy (SP). pp. 583–59 8 (2018). https://doi.org/10.1109/SP.2018.000-5

    2018 doi

  19. [27]

    In: Proceedings of the 2016 ACM SIGSAC Conference on Co mputer and Communications Security

    Miller, A., Xia, Y., Croman, K., Shi, E., Song, D.: The hon ey badger of bft proto- cols. In: Proceedings of the 2016 ACM SIGSAC Conference on Co mputer and Communications Security. p. 31–42. CCS ’16, Association fo r Computing Ma- chinery, New York, NY, USA (2016). https://do...

    2016

  20. [28]

    https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.180-4.pdf (Mar 2012), federal Information Processing Standards Publication 18 A

    National Institute of Standards and Technology (NIST): FIPS PUB 180-4: Secure Hash Standard (SHS). https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.180-4.pdf (Mar 2012), federal Information Processing Standards Publication 18 A. Karmegam et al

    2012

  21. [29]

    News, M.: Digital diploma debuts at mit (2017), https://news.mit.edu/2017/mit-debuts-secure-digital-diploma-using-bitcoin-blockchain-technology-1017

    2017

  22. [30]

    Poon, J., Buterin, V.: Plasma: Scalable autonomous smar t contracts (2017), https://plasma.io/plasma.pdf

    2017

  23. [31]

    Poon, J., Dryja, T.: The bitcoin lightning network: Scal able off-chain instant pay- ments (2016), https://lightning.network/lightning-net work-paper.pdf

    2016

  24. [32]

    In: 2024 54th Annual IEEE/IFIP Internation al Confer- ence on Dependable Systems and Networks (DSN)

    Ranchal-Pedrosa, A., Gramoli, V.: Zlb: A blockchain to t olerate collud- ing majorities. In: 2024 54th Annual IEEE/IFIP Internation al Confer- ence on Dependable Systems and Networks (DSN). pp. 209–222 ( 2024). https://doi.org/10.1109/DSN58291.2024.00032

    2024

  25. [33]

    Clus ter Comput- ing 27(5), 5547–5570 (Aug 2024)

    Rao, I.S., Kiah, M.L.M., Hameed, M.M., Memon, Z.A.: Scal ability of blockchain: a comprehensive review and future research direction. Clus ter Comput- ing 27(5), 5547–5570 (Aug 2024). https://doi.org/10.1007/s105 86-023-04257-7, https://doi.org/10.1007/s10586-023-04257-7

    2024 doi

  26. [34]

    In: Xiang, Y., Wang, Z., Wang, H., Niemi, V

    Russo, A., Fernández Anta, A., González Vasco, M.I., Rom ano, S.P.: Chi- rotonia: A scalable and secure e-voting framework based on b lockchains and linkable ring signatures. In: Xiang, Y., Wang, Z., Wang, H., Niemi, V. (eds.) 2021 IEEE International Conference on Bloc kchain,...

    2021

  27. [35]

    In: Proceedings of the 2022 ACM SIGSAC Conference on Computer and Communications Secu- rity

    Spiegelman, A., Giridharan, N., Sonnino, A., Kokoris-K ogias, L.: Bull- shark: Dag bft protocols made practical. In: Proceedings of the 2022 ACM SIGSAC Conference on Computer and Communications Secu- rity. p. 2705–2718. CCS ’22, Association for Computing Mach inery, New York, ...

    2022

  28. [36]

    Systems, I.: Malachite: Decentralize whatever, https://github.com/informalsystems/malachite

  29. [37]

    Wallet, A.: What is tps (transactions per second)? (2023 ), https://atomicwallet.io/academy/articles/what-is-tps

    2023

  30. [38]

    Webisoft: Cosmos tps (transactions per second): Unders tanding the speed of the internet of blockchains (2023), https://webisoft.com/ar ticles/cosmos-tps/

    2023

  31. [39]

    Wiki, B.: Confirmation - bitcoin wiki (2023), https://en.bitcoin.it/wiki/Confirmation, accessed: 202 4-10-01

    2023

  32. [40]

    In: Proceed- ings of the 2019 ACM Symposium on Principles of Distributed C om- puting

    Yin, M., Malkhi, D., Reiter, M.K., Gueta, G.G., Abraham, I.: Hot- stuff: Bft consensus with linearity and responsiveness. In: Proceed- ings of the 2019 ACM Symposium on Principles of Distributed C om- puting. p. 347–356. PODC ’19, Association for Computing Mac hinery, New York,...

    2019

  33. [41]

    In: Proceedings of the 2018 ACM SIGSAC Conference on Computer and Communications Security

    Zamani, M., Movahedi, M., Raykova, M.: Rapidchain: Scal ing blockchain via full sharding. In: Proceedings of the 2018 ACM SIGSAC Conference on Computer and Communications Security. p. 931–948. CCS ’18, Associat ion for Computing Machinery, New York, NY, USA (2018). https://doi...

    2018

  34. [42]

    The Merge

    Zhu, F., You, L., Wang, J., Li, L.: P-hotstuff: Parallel bf t algorithm with throughput insensitive to propagation delay. Computer Net works 262, 111183 (2025). https://doi.org/https://doi.org/10.101 6/j.comnet.2025.111183, https://www.sciencedirect.com/science/article/pii/S138...

    2025

  35. [44]

    or has requested the original batch using the hash hs found in hb (Line 27), if the original batch is not found locally. v proceeds to append the hash batch hb to the Ledger L, only after verifying (Line 28) that the batch_original is not empty and the hash of batch_original m...

  36. [424]

    https://doi.org/10.1109/BLOCKCHAIN53 845.2021.00065, https://doi.org/10.1109/Blockchain53845.2021.00065

    IEEE (2021). https://doi.org/10.1109/BLOCKCHAIN53 845.2021.00065, https://doi.org/10.1109/Blockchain53845.2021.00065

    2021

Pith tools

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