---
title: 'Setchain: Scalable Partial-Order Data Type'
url: https://www.emergentmind.com/topics/setchain
type: topic
---

# Setchain: Scalable Partial-Order Data Type

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 [2302.04744][2206.11845]. The concept was introduced in the 2022 preprint “Setchain: Improving Blockchain Scalability with Byzantine Distributed Sets and Barriers” [2206.11845] and published in revised form as “Improving Blockchain Scalability with the Setchain Data-type” [2302.04744].

## 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 [2302.04744].

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 [2206.11845]. 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 [2302.04744].

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 [2302.04744].

## 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 [2302.04744].

Each server replica maintains three main pieces of state:

- $v.\mathit{theset}\subseteq U$ or $T\subseteq U$, the grow-only local set of elements seen so far.
- $v.\mathit{epoch}\in\mathbb N$, the current epoch counter.
- $v.\mathit{history}:[1..v.\mathit{epoch}]\to\mathcal P(U)$, a map from epoch numbers to the subsets stamped at those epochs [2302.04744][2206.11845].

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 [2302.04744]. 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 [2206.11845].

The state transition induced by an epoch barrier is central. Servers compute the pending set of un-stamped elements,
$$
P_v = v.\mathit{theset}\setminus \bigcup_{i=1}^{v.\mathit{epoch}} v.\mathit{history}(i),
$$
propose it, and then assign a common next epoch to a decided subset of those elements [2302.04744][2406.02316]. In the fast algorithm, the decided set for epoch $h$ is constructed from the proposals received through set Byzantine consensus, and each correct server updates `theset`, `history(h)`, and `epoch` accordingly [2302.04744].

## 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 [2206.11845][2302.04744].

| Implementation | Core primitives | Characteristic |
|---|---|---|
| Centralized | Local state only | Intuition and sequential baseline |
| DSO + BAB | Byzantine grow-only set + Byzantine Atomic Broadcast | Uses $2f+1$ 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$ 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 [2302.04744].

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 $O(f)$ rather than $O(nf)$, because the protocol exploits batching of up to $n$ simultaneous proposals rather than running separate consensus instances [2206.11845]. It also states that, in all implementations, each add and epoch barrier involves $O(n)$ point-to-point messages [2206.11845].

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 [2509.09795]. Vanilla appends each element directly to the ledger. Compresschain gathers up to $c$ 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 [2509.09795].

That later ledger-backed line also introduces epoch-proofs. Once epoch $i$ with contents $G$ is decided, server $v$ computes
$$
p_v(i)=\operatorname{Sign}_{sk_v}\bigl(\operatorname{HASH}(i\parallel \operatorname{sort}(G))\bigr),
$$
and clients can verify an epoch using any $f+1$ epoch-proofs with valid signatures on the same digest [2509.09795]. 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 [2302.04744]. 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 [2206.11845].

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 [2302.04744].
- **Unique Epoch**: no element is stamped in two different epochs; equivalently, the epoch sets are pairwise disjoint [2302.04744].
- **Consistent Gets**: if two correct servers have completed epoch $h$, they agree on the exact contents of that epoch [2302.04744].
- **Add-before-Get**: every element returned by a correct `get()` must have been introduced through some `add()` [2302.04744].

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 $e$ [2302.04744].
- **Get-Global** or **Add-Get**: if one correct server contains an element, eventually every correct server contains it [2302.04744][2206.11845].
- **Eventual-Get**: every element visible at a correct server is eventually placed in some epoch history [2302.04744][2206.11845].

The proof structure relies on BRB termination and validity, SBC agreement and validity, and the server threshold $n\ge 3f+1$, which ensures enough overlap among correct proposals [2302.04744]. The 2022 overview makes the threshold filter explicit: in some constructions, an element is stamped only if it appears in at least $f+1$ distinct proposals, ensuring that at least one correct replica proposed it [2206.11845].

Several named lemmas recur across the presentations: Stamp-Once or Unique Stamp, History-Agreement or Agreement, and Eventually-In-History or Eventual-Get [2302.04744][2206.11845]. 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 $f$ Byzantine servers can be collapsed into one nondeterministic process $B$ 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 $f$ independent Byzantine servers can be mapped one-for-one to an execution with a single nondeterministic $B$ and $n-f$ correct servers, and vice versa [2302.04744]. 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 $1$–$100$ epochs per minute depending on $n$ and $f$, while pure-add throughput is approximately $10^5$ adds per minute; add operations are therefore about $10^3\times$ faster than epoch changes [2302.04744].

That same study reports that the local-set design outperforms the DSO-based design by approximately $2$–$5\times$ when epochs are injected, because it avoids DSO gets. It also reports that local aggregation—batching pending adds into a single BRB message every $10^6$ elements or $5$ seconds—produces a further $10\times$–$30\times$ speedup [2302.04744]. Silent Byzantine servers that simply drop messages only modestly degrade add throughput at higher $n$, and 30-minute experiments show stable stamp latency, with the majority of stamps below $1$ second and occasional delays up to the batch timeout [2302.04744].

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 $25$ barriers per second at $n=4$, approximately $18$ at $n=7$, and approximately $15$ at $n=10$ when no adds are present. Without aggregation, both major algorithms reach approximately $10^3$–$10^4$ adds per second; with message aggregation to 1M-element BRB packets, throughput increases by about $10\times$ [2206.11845]. Under a workload with one barrier per second, the pure BRB+SBC design outperforms the DSO-based design by $5\times$ at $n=4$ and $2\times$ at $n=7,10$, sustaining about $5000$ adds per second versus about $1000$ in aggregated mode [2206.11845]. The same study reports 99th-percentile stamp latency of about $1$ second and worst-case latency of about $5$ seconds, with no long-term degradation [2206.11845].

A concise 2023 aggregated-mode comparison for $n=7,f=2$ reports approximately $800$ adds per second for the DSO+BRB+SBC design and approximately $6000$ adds per second for the local+BRB+SBC design, a speed-up of $\times 7.5$, while epoch throughput is approximately $1.2$ versus $1.1$ epochs per second [2302.04744]. 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 $1.25$ seconds and block size $0.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 $5000$ elements per second is $171$ for Vanilla, $996$ for Compresschain with $c=100$, and $4183$ for Hashchain with $c=100$; at $10000$ elements per second, the reported values are $100$, $571$, $743$, $2540$, and $7369$ for the specific configurations listed in the paper [2509.09795]. Median and tail commit latencies are also differentiated: Vanilla is approximately $25$ seconds median and above $40$ seconds at the 90th percentile, Compresschain is about $2$ seconds median and below $4$ seconds at the 99th percentile, and Hashchain is about $1$ second median and below $3$ seconds at the 99th percentile [2509.09795]. The paper summarizes these results as orders-of-magnitude higher throughput than the underlying blockchain and finality with latency below $4$ seconds [2509.09795].

## 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 $\mathcal B$. To anchor security, clients or relayers invoke `Setchain.epochinc(h)` exactly when $\mathcal B$ reaches block height $h`, and on-chain smart contracts can read, via `get()`, a Setchain commitment such as a hash of $H(h)$ posted in block $h$ [2302.04744]. Between block-synchronized epochs, users obtain fast and cheaply-priced off-chain `add` operations, while final ordering is only by epoch number [2302.04744]. 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 [2206.11845]. 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 [2206.11845]. 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 [2406.02316]. 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 $(i,h,\sigma_v)$ so that the same dissemination layer collects signatures [2406.02316]. Once a node collects at least $f+1$ signatures on $(i,h)$, a rotating on-chain poster eventually submits an aggregated signature
$$
\Sigma(i,h)=\mathsf{Agg}\{\sigma_u(i,h)\}
$$
to the L1 logger contract [2406.02316]. The paper attributes safety to Setchain-UniqueEpoch together with the $f+1$-signature requirement, and liveness to Setchain’s dissemination guarantees plus the rotating poster under partial synchrony [2406.02316].

That rollup work also adds an economic layer: staking by posters, confirmation delays, rewards $(k_1,k_2,k_3)$ 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 [2406.02316]. 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 [2509.09795]. Compresschain amortizes ledger cost through compression, with the implementation reporting Brotli compression ratios of about $2.7$–$3.5\times$ [2509.09795]. 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 $f+1$ signatures on a hash, at least one correct signer must exist [2509.09795]. The same paper also states that clients can safely interact with only one server by collecting $f+1$ epoch-proofs from its `get()` response [2509.09795].

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 [2302.04744][2509.09795].

Source: https://www.emergentmind.com/topics/setchain