Setchain: Scalable Partial-Order Data Type

• Setchain is a distributed concurrent data type that uses epoch-based partial ordering, where elements within an epoch are unordered and epochs are sequentially ordered.
• It leverages grow-only sets with synchronization barriers to achieve high scalability, reducing coordination overhead compared to total ordering in blockchain systems.
• By integrating Byzantine-resistant consensus and reliable broadcast, Setchain ensures safety and liveness, facilitating efficient batching and rapid add operations.

Setchain is a distributed concurrent data type for blockchain scalability in which the underlying object is a grow-only set, and ordering is relaxed from a per-operation total order to an epoch-based partial order. Elements added to the same epoch are unordered, while elements in different epochs are ordered by epoch number. The core motivation is that total order is often not fully necessary, or is “overkilling,” for advanced smart-contract applications; if a more relaxed order can be exploited under Byzantine fault tolerance, a much higher scalability can be achieved (Capretto et al., 2023, Capretto et al., 2022). The concept was introduced in the 2022 preprint “Setchain: Improving Blockchain Scalability with Byzantine Distributed Sets and Barriers” (Capretto et al., 2022) and published in revised form as “Improving Blockchain Scalability with the Setchain Data-type” (Capretto et al., 2023).

1. Ordering model and object semantics

A Setchain organizes elements into a sequence of sets, referred to as epochs. The object abstracts a grow-only set whose elements are not totally ordered, unlike conventional blockchain operations. When convenient, the system allows forcing a synchronization barrier that assigns permanently an epoch number to a subset of the latest elements added. Two operations in the same epoch are not ordered, while two operations in different epochs are ordered by their respective epoch number (Capretto et al., 2023).

In the formal presentation, if an element $e$ is assigned epoch $h$, then the induced ordering can be written as follows: if $$\operatorname{epoch}(e)\neq\operatorname{epoch}(e')$$, then $e\prec e'$ iff $\operatorname{epoch}(e)<\operatorname{epoch}(e')$; if $\operatorname{epoch}(e)=\operatorname{epoch}(e')$, then the two elements are concurrent and therefore unordered (Capretto et al., 2022). The 2023 formulation also expresses the cross-epoch order as

$(e,i) \prec (e',j)\quad\text{whenever}\quad i<j,$

with the explicit stipulation that each element appears in exactly one epoch (Capretto et al., 2023).

This semantics is neither a conventional blockchain log nor an unordered bag. It is a partially ordered history in which epoch boundaries act as synchronization barriers. A common misconception is to treat Setchain as merely a faster ledger; more precisely, it is a set object with on-demand ordering fences. The data show that its scalability gains come from implementing grow-only sets with epoch synchronization instead of total order (Capretto et al., 2023).

2. System model, server state, and API

In the original Byzantine-tolerant object model, clients and servers communicate by authenticated point-to-point message-passing. Up to $f$ of the $n$ servers may be Byzantine, with $n\ge 3f+1$. Channels between correct servers are reliable but asynchronous, while the set-Byzantine-consensus primitive runs under partial synchrony (Capretto et al., 2023).

Each server replica maintains three main pieces of state:

• $h$0 or $h$1, the grow-only local set of elements seen so far.
• $h$2, the current epoch counter.
• $h$3, a map from epoch numbers to the subsets stamped at those epochs (Capretto et al., 2023, Capretto et al., 2022).

The basic API consists of three operations in the 2023 presentation: add(e), get(), and epochinc(h'), where the last operation advances the state to the next epoch and stamps all current un-stamped elements (Capretto et al., 2023). The 2022 overview presents the same object in terms of add(e), get(), and epoch increment logic, with get() returning the local set, history, and current epoch (Capretto et al., 2022).

The state transition induced by an epoch barrier is central. Servers compute the pending set of un-stamped elements,

$h$4

propose it, and then assign a common next epoch to a decided subset of those elements (Capretto et al., 2023, Capretto et al., 2024). In the fast algorithm, the decided set for epoch $h$5 is constructed from the proposals received through set Byzantine consensus, and each correct server updates theset, history(h), and epoch accordingly (Capretto et al., 2023).

3. Byzantine-tolerant protocol architectures

The original line of work presents several implementations that progressively reduce coordination overhead. The architectures differ in whether the grow-only set is externalized as a Byzantine distributed set object and in whether epoch agreement is achieved through atomic broadcast or set Byzantine consensus (Capretto et al., 2022, Capretto et al., 2023).

Implementation	Core primitives	Characteristic
Centralized	Local state only	Intuition and sequential baseline
DSO + BAB	Byzantine grow-only set + Byzantine Atomic Broadcast	Uses $h$6 BAB deliveries to conclude an epoch
DSO + BRB + SBC	Byzantine Reliable Broadcast + Set Byzantine Consensus	One SBC instance per epoch
Local-set + BRB + SBC	Local in-memory set + BRB + SBC	Removes DSO overhead

In the most efficient formulation, additions are disseminated via Byzantine Reliable Broadcast: on add(e), a server broadcasts m_add(e); on BRB delivery, correct servers validate the element and insert it into the local set. Epoch increments are also announced by BRB: on epochinc(h), a server broadcasts m_epinc(h); after delivery, each server computes its proposal for epoch $h$7 and invokes one SBC instance. When the SBC instance returns the vector of proposals, each server computes the decided epoch set, stores it in history(h), and increments the epoch counter (Capretto et al., 2023).

The 2022 presentation emphasizes the asymptotic effect of this replacement. By combining BRB with one instance of SBC per epoch, the epoch-barrier latency is described as $h$8 rather than $h$9, because the protocol exploits batching of up to $$\operatorname{epoch}(e)\neq\operatorname{epoch}(e')$$0 simultaneous proposals rather than running separate consensus instances (Capretto et al., 2022). It also states that, in all implementations, each add and epoch barrier involves $$\operatorname{epoch}(e)\neq\operatorname{epoch}(e')$$1 point-to-point messages (Capretto et al., 2022).

Later work adapted the abstraction to a block-based ledger substrate. “Setchain Algorithms for Blockchain Scalability” defines three algorithms—Vanilla, Compresschain, and Hashchain—implemented on top of CometBFT (Karmegam et al., 11 Sep 2025). Vanilla appends each element directly to the ledger. Compresschain gathers up to $$\operatorname{epoch}(e)\neq\operatorname{epoch}(e')$$2 items in a collector batch, compresses it, and appends one compressed blob per epoch. Hashchain publishes only fixed-size hashes of batches and relies on a retrieval service to obtain the corresponding batch contents from the hash (Karmegam et al., 11 Sep 2025).

That later ledger-backed line also introduces epoch-proofs. Once epoch $$\operatorname{epoch}(e)\neq\operatorname{epoch}(e')$$3 with contents $$\operatorname{epoch}(e)\neq\operatorname{epoch}(e')$$4 is decided, server $$\operatorname{epoch}(e)\neq\operatorname{epoch}(e')$$5 computes

$$\operatorname{epoch}(e)\neq\operatorname{epoch}(e')$$6

and clients can verify an epoch using any $$\operatorname{epoch}(e)\neq\operatorname{epoch}(e')$$7 epoch-proofs with valid signatures on the same digest (Karmegam et al., 11 Sep 2025). This shifts some trust minimization to cryptographic proof collection while preserving light-client interaction through a single server.

4. Safety, liveness, and proof methodology

Setchain correctness is specified through a collection of safety and liveness properties. In the 2023 formulation, the required safety properties are Consistent Sets, Unique Epoch, Consistent Gets, and Add-before-Get; the liveness properties are Add-Get-Local, Get-Global, and Eventual-Get (Capretto et al., 2023). The 2022 overview presents a closely aligned list, including Consistent Sets, Add-Get-Local, Add-Get, Eventual-Get, Unique Epoch, Consistent Gets, and Add-before-Get (Capretto et al., 2022).

The core safety conditions can be summarized as follows:

• Consistent Sets: for every correct server and any returned history prefix, each stamped epoch set is included in the visible set (Capretto et al., 2023).
• Unique Epoch: no element is stamped in two different epochs; equivalently, the epoch sets are pairwise disjoint (Capretto et al., 2023).
• Consistent Gets: if two correct servers have completed epoch $$\operatorname{epoch}(e)\neq\operatorname{epoch}(e')$$8, they agree on the exact contents of that epoch (Capretto et al., 2023).
• Add-before-Get: every element returned by a correct get() must have been introduced through some add() (Capretto et al., 2023).

The liveness conditions ensure dissemination and eventual stamping:

• Add-Get-Local: once a correct server executes add(e), all its future get() operations eventually include $$\operatorname{epoch}(e)\neq\operatorname{epoch}(e')$$9 (Capretto et al., 2023).
• Get-Global or Add-Get: if one correct server contains an element, eventually every correct server contains it (Capretto et al., 2023, Capretto et al., 2022).
• Eventual-Get: every element visible at a correct server is eventually placed in some epoch history (Capretto et al., 2023, Capretto et al., 2022).

The proof structure relies on BRB termination and validity, SBC agreement and validity, and the server threshold $e\prec e'$0, which ensures enough overlap among correct proposals (Capretto et al., 2023). The 2022 overview makes the threshold filter explicit: in some constructions, an element is stamped only if it appears in at least $e\prec e'$1 distinct proposals, ensuring that at least one correct replica proposed it (Capretto et al., 2022).

Several named lemmas recur across the presentations: Stamp-Once or Unique Stamp, History-Agreement or Agreement, and Eventually-In-History or Eventual-Get (Capretto et al., 2023, Capretto et al., 2022). These establish, respectively, that elements are not duplicated across epochs, that all correct replicas agree on completed epochs, and that correctly added elements are eventually stamped.

A distinctive proof-engineering device in the 2023 paper is the unified attack model. All $e\prec e'$2 Byzantine servers can be collapsed into one nondeterministic process $e\prec e'$3 that can broadcast adds and epoch increments, propose subsets of its knowledge to SBC, or do nothing. The paper states an observational correspondence: any execution with $e\prec e'$4 independent Byzantine servers can be mapped one-for-one to an execution with a single nondeterministic $e\prec e'$5 and $e\prec e'$6 correct servers, and vice versa (Capretto et al., 2023). This reduction simplifies correctness proofs by encoding the general attacker in a concrete implementation.

5. Empirical performance and scalability

The empirical evaluations consistently report a large gap between the cost of ordinary additions and the cost of epoch barriers. In the 2023 prototype of Algorithm 2 and Algorithm 3, implemented in Go with ZeroMQ on 4–10 Docker containers, epoch-change throughput is reported as approximately $e\prec e'$7–$e\prec e'$8 epochs per minute depending on $e\prec e'$9 and $\operatorname{epoch}(e)<\operatorname{epoch}(e')$0, while pure-add throughput is approximately $\operatorname{epoch}(e)<\operatorname{epoch}(e')$1 adds per minute; add operations are therefore about $\operatorname{epoch}(e)<\operatorname{epoch}(e')$2 faster than epoch changes (Capretto et al., 2023).

That same study reports that the local-set design outperforms the DSO-based design by approximately $\operatorname{epoch}(e)<\operatorname{epoch}(e')$3–$\operatorname{epoch}(e)<\operatorname{epoch}(e')$4 when epochs are injected, because it avoids DSO gets. It also reports that local aggregation—batching pending adds into a single BRB message every $\operatorname{epoch}(e)<\operatorname{epoch}(e')$5 elements or $\operatorname{epoch}(e)<\operatorname{epoch}(e')$6 seconds—produces a further $\operatorname{epoch}(e)<\operatorname{epoch}(e')$7–$\operatorname{epoch}(e)<\operatorname{epoch}(e')$8 speedup (Capretto et al., 2023). Silent Byzantine servers that simply drop messages only modestly degrade add throughput at higher $\operatorname{epoch}(e)<\operatorname{epoch}(e')$9, and 30-minute experiments show stable stamp latency, with the majority of stamps below $\operatorname{epoch}(e)=\operatorname{epoch}(e')$0 second and occasional delays up to the batch timeout (Capretto et al., 2023).

The 2022 evaluation gives a finer-grained throughput and latency decomposition. In a Go prototype on Docker containers over TCP, the pure BRB+SBC algorithm reaches up to approximately $\operatorname{epoch}(e)=\operatorname{epoch}(e')$1 barriers per second at $\operatorname{epoch}(e)=\operatorname{epoch}(e')$2, approximately $\operatorname{epoch}(e)=\operatorname{epoch}(e')$3 at $\operatorname{epoch}(e)=\operatorname{epoch}(e')$4, and approximately $\operatorname{epoch}(e)=\operatorname{epoch}(e')$5 at $\operatorname{epoch}(e)=\operatorname{epoch}(e')$6 when no adds are present. Without aggregation, both major algorithms reach approximately $\operatorname{epoch}(e)=\operatorname{epoch}(e')$7–$\operatorname{epoch}(e)=\operatorname{epoch}(e')$8 adds per second; with message aggregation to 1M-element BRB packets, throughput increases by about $\operatorname{epoch}(e)=\operatorname{epoch}(e')$9 (Capretto et al., 2022). Under a workload with one barrier per second, the pure BRB+SBC design outperforms the DSO-based design by $(e,i) \prec (e',j)\quad\text{whenever}\quad i<j,$0 at $(e,i) \prec (e',j)\quad\text{whenever}\quad i<j,$1 and $(e,i) \prec (e',j)\quad\text{whenever}\quad i<j,$2 at $(e,i) \prec (e',j)\quad\text{whenever}\quad i<j,$3, sustaining about $(e,i) \prec (e',j)\quad\text{whenever}\quad i<j,$4 adds per second versus about $(e,i) \prec (e',j)\quad\text{whenever}\quad i<j,$5 in aggregated mode (Capretto et al., 2022). The same study reports 99th-percentile stamp latency of about $(e,i) \prec (e',j)\quad\text{whenever}\quad i<j,$6 second and worst-case latency of about $(e,i) \prec (e',j)\quad\text{whenever}\quad i<j,$7 seconds, with no long-term degradation (Capretto et al., 2022).

A concise 2023 aggregated-mode comparison for $(e,i) \prec (e',j)\quad\text{whenever}\quad i<j,$8 reports approximately $(e,i) \prec (e',j)\quad\text{whenever}\quad i<j,$9 adds per second for the DSO+BRB+SBC design and approximately $f$0 adds per second for the local+BRB+SBC design, a speed-up of $f$1, while epoch throughput is approximately $f$2 versus $f$3 epochs per second (Capretto et al., 2023). This pattern is consistent with the architectural claim that removing DSO gets primarily benefits the add path.

The ledger-backed CometBFT implementations extend the same scalability argument to a different deployment model. In 50-second experiments with default block time approximately $f$4 seconds and block size $f$5 MB, Hashchain achieves substantially higher throughput than Vanilla and Compresschain. For 10 servers and no extra delay, the reported average throughput at a sending rate of $f$6 elements per second is $f$7 for Vanilla, $f$8 for Compresschain with $f$9, and $n$0 for Hashchain with $n$1; at $n$2 elements per second, the reported values are $n$3, $n$4, $n$5, $n$6, and $n$7 for the specific configurations listed in the paper (Karmegam et al., 11 Sep 2025). Median and tail commit latencies are also differentiated: Vanilla is approximately $n$8 seconds median and above $n$9 seconds at the 90th percentile, Compresschain is about $n\ge 3f+1$0 seconds median and below $n\ge 3f+1$1 seconds at the 99th percentile, and Hashchain is about $n\ge 3f+1$2 second median and below $n\ge 3f+1$3 seconds at the 99th percentile (Karmegam et al., 11 Sep 2025). The paper summarizes these results as orders-of-magnitude higher throughput than the underlying blockchain and finality with latency below $n\ge 3f+1$4 seconds (Karmegam et al., 11 Sep 2025).

6. Sidechain integration, rollups, and subsequent developments

A direct blockchain integration pattern is to run a Setchain instance off-chain in parallel with an underlying blockchain $n\ge 3f+1$5. To anchor security, clients or relayers invoke Setchain.epochinc(h) exactly when $n\ge 3f+1$6 reaches block height $n\ge 3f+1$7H(h)$n\ge 3f+1$8h$ (Capretto et al., 2023). Between block-synchronized epochs, users obtain fast and cheaply-priced off-chain add operations, while final ordering is only by epoch number (Capretto et al., 2023). In this sense, Setchain serves as an L2 sidechain.

The 2022 overview identifies several use cases that fit the partial-order model. These include mempool logging and front-running detection, optimistic rollups, and side-chain storage for data-heavy smart-contract applications (Capretto et al., 2022). The underlying rationale is explicit: smart contracts that need only commutativity, such as grow-only registries or mempools, can exploit the much higher throughput of adds, while a barrier can act as a fence when stricter serialization is needed (Capretto et al., 2022). This suggests that Setchain is most natural where application semantics tolerate concurrency within an epoch.

“Fast and Secure Decentralized Optimistic Rollups Using Setchain” develops this idea into a fully decentralized optimistic-rollup “arranger” that combines the roles of sequencer and data availability committee (Capretto et al., 2024). In that construction, arranger nodes run Setchain to ingest user transactions, extract each epoch as a batch, compute a hash such as a Merkle root, sign it, and re-add the tuple $n\ge 3f+1$9 so that the same dissemination layer collects signatures (Capretto et al., 2024). Once a node collects at least $h$00 signatures on $h$01, a rotating on-chain poster eventually submits an aggregated signature

$h$02

to the L1 logger contract (Capretto et al., 2024). The paper attributes safety to Setchain-UniqueEpoch together with the $h$03-signature requirement, and liveness to Setchain’s dissemination guarantees plus the rotating poster under partial synchrony (Capretto et al., 2024).

That rollup work also adds an economic layer: staking by posters, confirmation delays, rewards $h$04 for participation, signing, and posting, off-chain translation fees via a hashed timelock protocol, and four on-chain fraud-proof games for signature, data-availability, validity, and integrity challenges (Capretto et al., 2024). These mechanisms are presented as a way to deter censorship or equivocation even in the presence of rational behavior.

The 2025 CometBFT-based paper extends the design space further with Vanilla, Compresschain, and Hashchain (Karmegam et al., 11 Sep 2025). Compresschain amortizes ledger cost through compression, with the implementation reporting Brotli compression ratios of about $h$05–$h$06 (Karmegam et al., 11 Sep 2025). Hashchain pushes the idea farther by appending only hashes to the ledger and retrieving batch contents through a distributed service; because epochs are consolidated only after at least $h$07 signatures on a hash, at least one correct signer must exist (Karmegam et al., 11 Sep 2025). The same paper also states that clients can safely interact with only one server by collecting $h$08 epoch-proofs from its get() response (Karmegam et al., 11 Sep 2025).

Across these later developments, the central Setchain principle remains unchanged: sacrificing strict total order among all elements, and retaining ordering only across epoch barriers, amortizes the expensive coordination path over many additions. The published evaluations and applications consistently frame Setchain as a partial-order substrate for decentralized systems that need Byzantine tolerance, efficient batching, and occasional globally ordered synchronization points (Capretto et al., 2023, Karmegam et al., 11 Sep 2025).