---
title: 'Ocior: Byzantine Consensus Protocols'
url: https://www.emergentmind.com/topics/ocior
type: topic
---

# Ocior: Byzantine Consensus Protocols

Searching arXiv for papers on "Ocior" and closely related protocol variants.
arxiv_search(query="Ocior consensus OR OciorABA", max_results=10, sort_by="relevance")
Ocior is the name used in recent arXiv literature for asynchronous Byzantine agreement and consensus protocols under the optimal resilience condition $n \ge 3t+1$. In its primary usage, Ocior denotes a practical asynchronous Byzantine fault-tolerant consensus protocol that is leaderless, processes transactions individually and concurrently via parallel consensus instances, and provides two asynchronous rounds of good-case finality for legitimate two-party transactions [2509.01118]. In a related usage, the compound name **OciorABA** denotes an error-free, information-theoretically secure multi-valued asynchronous Byzantine agreement protocol built around the primitive of asynchronous partial vector agreement (APVA), with expected communication complexity $O(n\ell + n^3 \log q)$ bits and expected round complexity $O(1)$ [2501.11788]. This suggests that “Ocior” functions less as a single algorithmic artifact than as a protocol line centered on low-latency asynchronous agreement under Byzantine faults.

## 1. Nomenclature and protocol scope

The literature distinguishes between two constructions carrying the Ocior name. **Ocior** is a transaction-oriented asynchronous BFT consensus protocol with threshold-signature-based fast finality and adaptive security [2509.01118]. **OciorABA** is a multi-valued asynchronous Byzantine agreement protocol that is error-free and information-theoretically secure, and it uses APVA as a key building block [2501.11788].

| Protocol | Problem setting | Core stated properties |
|---|---|---|
| Ocior | Practical asynchronous BFT consensus | Leaderless, parallel instances, two-round finality for legitimate two-party transactions, $O(n)$ expected communication per transaction |
| OciorABA | Multi-valued asynchronous Byzantine agreement | Error-free, information-theoretically secure, APVA-based, $O(n\ell + n^3 \log q)$ expected communication bits |

The distinction is substantive. Ocior is framed as a protocol for transaction finalization in a fully asynchronous network with authenticated channels, threshold signatures, epochal key refresh, and adaptive Byzantine corruption. OciorABA is framed as an ABA construction without cryptographic hardness assumptions, apart from the availability of a common-coin primitive. A common misconception would be to treat them as interchangeable formulations of the same protocol. The papers instead describe different agreement tasks, different proof models, and different implementation mechanisms.

## 2. System model and resilience assumptions

Both protocols operate under the optimal resilience condition
$$
n \ge 3t + 1,
$$
where up to $t$ nodes may be Byzantine. This shared threshold places both constructions within the standard optimal regime for asynchronous Byzantine agreement [2509.01118].

For Ocior, the network model is **fully asynchronous point-to-point links**: messages between honest nodes may be delayed arbitrarily but eventually arrive and cannot be forged because the channels are authenticated. There is no global clock and no known upper bound on message delay. The protocol measures an **asynchronous round** as one send plus one receive step. The adversary is **adaptive Byzantine**, may corrupt nodes at any time subject to the bound $t$, and the protocol assumes $n \ge 3t+1$ throughout [2509.01118].

For OciorABA, communication is likewise asynchronous in the sense that messages may be delayed arbitrarily but eventually arrive. The protocol is explicitly **error-free** if it satisfies agreement, validity, and termination in every execution, and **information-theoretically secure** if it does so without computational hardness assumptions. The only non-information-theoretic assumption stated is the availability of a **common-coin primitive** [2501.11788].

This contrast is central to the protocol family’s interpretation. Ocior targets practical consensus with cryptographic acceleration and adaptive-security machinery. OciorABA targets the ABA problem with no signatures or hash functions and pursues information-theoretic guarantees. The common ground is asynchronous operation and optimal Byzantine resilience; the divergence is in the operational layer at which each protocol is meant to function.

## 3. Ocior consensus workflow

Ocior departs from classic single-block protocols in two stated ways: it is **leaderless**, and it runs **parallel instances** in which **every incoming transaction spawns a fresh two-round “Propose→Vote” instance** rather than being batched into a single leader proposal [2509.01118]. Each of the $n$ nodes maintains its own chain and proposes transactions independently.

The protocol proceeds in epochs $e = 1,2,3,\ldots$. Before epoch $e$ starts, nodes run an asynchronous DKG to obtain fresh TS/LTS keys for that epoch, and old secret shares are erased. On node $i$’s chain, heights increase as $h=0,1,2,\ldots$. At height $h$, node $i$ proposes a transaction $tx$ together with a **virtual parent signature** $sig_{VP}$, defined as the threshold signature at height $h-1$ on its own chain, and **official parent signatures** $\{sig_{OP}\}$ on the parent transaction(s) cited in $tx$. A proposal message has the form
$$
(\mathrm{PROP}, i, e, m, h, tx, sig_{VP}, \{sig_{OP}\}, \ldots),
$$
where $m$ is the node’s $m$-th proposal in epoch $e$ [2509.01118].

Finality is obtained in two asynchronous rounds for a stated good case. In **Round 1 (Propose)**, proposer $i$ multicasts the proposal. In **Round 2 (Vote)**, after validating the virtual parent, the parents, and the correctness of $tx$, each honest node $j$ returns two partial signatures:
$$
vote^{TS}_j = \mathrm{TS.Sign}(sk_{e,j}, H(content)),
$$
$$
vote^{LTS}_j = \mathrm{LTS.Sign}(skl_{e,\mathrm{shuffled}(j)}, H(content)),
$$
where
$$
content = (i,e,m,h,tx,sig_{VP},\{sig_{OP}\}).
$$
As soon as the proposer collects
$$
k=\left\lceil\frac{n+t+1}{2}\right\rceil
$$
valid TS partial shares, it combines them into a full threshold signature $\sigma$ via $\mathrm{TS.Combine}(\cdot)$. The pair $(\sigma, content)$ is the **Type I APS** [2509.01118].

The protocol’s liveness claim is framed as **stable liveness** in a **leaderless** setting. No designated proposer exists; every node may propose at high rate, up to a configured per-epoch cap. Continuous progress is stated to be guaranteed as long as at least one honest proposer remains uncorrupted and transactions remain legitimate. A second common misconception is therefore that leaderlessness implies the absence of ordering structure. In Ocior, leaderlessness coexists with per-node chains, parent-signature dependencies, and explicit epochal state.

## 4. OciorBLSts and threshold-signature acceleration

A central component of Ocior is **OciorBLSts**, described as a novel non-interactive threshold signature scheme that offers fast signature aggregation, is adaptively secure, and supports **Instantaneous TS Aggregation**, meaning that partial signatures can be aggregated in real time as they arrive [2509.01118]. The protocol states that this reduces waiting time and improves responsiveness.

OciorBLSts combines one standard BLS-style threshold signature scheme with one or multiple **Layered Threshold Signature (LTS)** structures. In the TS layer, the setup provides public parameters $(G,p,e,H)$, DKG yields a public key $pk=g^s$ and shares $sk_j=s(j)$, and a partial signature is
$$
\sigma_j = H(w)^{sk_j}.
$$
The verification equation is
$$
e(\sigma_j,g)=e(H(w),pk_j).
$$
For a set $S$ of at least $k$ shares, combination is
$$
\sigma = \prod_{j\in S}\sigma_j^{\lambda_j},
\qquad
\lambda_j=\prod_{i\in S,\, i\ne j}\frac{i}{i-j}\in \mathbb{F}_p,
$$
and the final signature verifies by
$$
e(\sigma,g)=e(H(w),pk).
$$
The LTS structure defines $L$ layers with parameters $\{n_\ell,k_\ell\}_{\ell=1}^L$, satisfying $\prod n_\ell=n$ and $\prod k_\ell \ge k$. Bottom-layer shares are partitioned into groups, and whenever enough child shares arrive, they are combined immediately and propagated upward without waiting for all upper-level inputs. This is the mechanism behind the paper’s **instantaneous aggregation** property [2509.01118].

The stated security goals include **TS-ROB-ACMA**, **TS-UNF-ACMA**, LTS good-case robustness, LTS unforgeability, and **adaptive security in algebraic group model under one-more discrete-log hardness**. The stated computational cost is $O(n)$ group multiplications in the best case when the good LTS path succeeds, and $O(n\log^2 n)$ in the worst case when the protocol falls back to full BLS threshold combination [2509.01118].

Within the Ocior construction, this signature subsystem is not ancillary. It is the mechanism through which the protocol seeks to reconcile asynchronous operation with low proposer CPU cost and two-round good-case finality. The paper’s complexity claims for the consensus layer are tightly coupled to the existence of fast, non-interactive threshold aggregation.

## 5. OciorABA and the APVA primitive

OciorABA studies **multi-valued asynchronous Byzantine agreement** on an $\ell$-bit message $w \in \{0,1\}^\ell$ and introduces **Asynchronous Partial Vector Agreement (APVA)** as a new primitive [2501.11788]. In APVA, each node $i$ inputs a length-$n$ vector
$$
w_i \in \{0,1\}\cup\{\perp\})^n,
$$
where $\perp$ denotes a missing or unknown entry. Honest nodes must eventually output the same vector
$$
w \in (\{0,1\}\cup\{\perp\})^n.
$$

APVA guarantees three stated properties. **Consistency (Agreement)** requires that if any honest node outputs $w$, every honest node outputs $w$. **Validity** requires that, for each index $j$ with $w[j]\neq \perp$, there exists at least one honest node $i$ whose input has $w_i[j]=w[j]\neq \perp$, and the number of non-$\perp$ entries in $w$ is at least $n-t$. **Termination** requires eventual output when every honest node’s input vector has non-$\perp$ values in some common set of at least $n-t$ positions [2501.11788].

The APVA protocol interleaves four components: an **ACID** instance to share each node’s entire input vector, repeated rounds indexed by $r=1,2,3,\ldots$ in which a **CommonCoin** elects a candidate node $\ell$, a two-phase binary subroutine built from **ABBBA + ABBA** to decide whether to adopt node $\ell$’s vector, and then a coordinate-wise confirmation using $n-t$ parallel ABBBA+ABBA instances if the candidate vector is adopted. The paper describes ACID as **Asynchronous Complete Information Dispersal** and uses **RBC** to deliver candidate vectors [2501.11788].

OciorABA itself uses **exactly one instance of APVA plus $n$ reliable broadcasts**. Each node encodes its $\ell$-bit input under an $(n,k=n-t)$ erasure code over an alphabet $\Sigma$ of size $q$, producing symbols
$$
(y_i[1], y_i[2], \ldots, y_i[n]),
$$
such that any $k=t+1$ distinct symbols suffice to decode the original message. Node $i$ RBC-broadcasts $y_i[i]$. Each node then forms a local indicator vector by comparing received symbols to its own codeword symbols, runs one APVA instance on these vectors, obtains a common vector $w$, and decides as follows: if fewer than $t+1$ coordinates equal $1$, it outputs the indicator vector; otherwise it selects any $t+1$ such indices, fetches the corresponding RBC outputs, and decodes the message [2501.11788].

The protocol’s stated complexity is **expected communication complexity $O(n\ell + n^3 \log q)$ bits** and **expected round complexity $O(1)$ rounds** under $n \ge 3t+1$ [2501.11788]. The role of the erasure code is explicit: broadcasting a single coded fragment per node reduces the $\ell$-dependent cost from the $O(n^2\ell)$ behavior that would arise if every node RBC-broadcast the full message.

## 6. Complexity, performance, and conceptual distinctions

Ocior and OciorABA optimize different objects. For Ocior, the communication claim is **$O(n)$ expected communication per transaction**, or $O(n\kappa)$ in bits when CTS signatures have size $\kappa$. The computation claim is **$O(n)$ in the best case** and **$O(n\log^2 n)$ in the worst case**. The round claim is **two asynchronous rounds for two-party transactions (Type I) in the good case**, and the paper’s performance table states **4 rounds for general ones**. It also reports **millions of transactions/sec and sub-second finality in 128-node geo-distributed experiments (e.g., 200 ms end-to-end)** [2509.01118].

For OciorABA, the dominant metric is expected bit complexity for multi-valued ABA on an $\ell$-bit message. The protocol achieves **$O(n\ell + n^3 \log q)$ bits** and **$O(1)$ expected rounds**, and the paper positions this against prior error-free asynchronous ABA protocols cited there: Patra ’11 with $O(n\ell + n^5 \log n)$ bits and Nayak et al. ’20 with $O(n\ell + n^4 \log n)$ bits, both at $O(1)$ rounds, as well as Li–Chen ’21 with $n \ge 5t+1$ and $O(\max\{n\ell, nt\log q\})$ bits [2501.11788].

Several conceptual distinctions follow directly from these descriptions. First, **two-round finality in Ocior is not a blanket statement about all agreement tasks**; it is stated for a **legitimate two-party transaction** in the **good case**, where the transaction is proposed by any honest node. Second, **leaderless** in Ocior does not mean the absence of concurrency control; rather, the system uses per-node chains, parent-signature dependencies, and per-transaction instances. Third, **OciorABA’s error-free and information-theoretic formulation is not inherited by Ocior**. Ocior instead relies on threshold signatures, DKG, adaptive-security assumptions in the algebraic group model, and epochal key refresh.

Taken together, the Ocior literature represents two adjacent lines of asynchronous Byzantine protocol design. One line prioritizes practical transaction finalization with threshold-signature acceleration and leaderless concurrency; the other prioritizes error-free, information-theoretic multi-valued ABA via APVA and erasure-coded reliable broadcast. Their shared resilience threshold $n \ge 3t+1$ and their emphasis on low asynchronous round complexity give the name “Ocior” a coherent thematic identity, even though the underlying mechanisms and formal objectives differ substantially [2509.01118].

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