Ocior: Byzantine Consensus Protocols
- Ocior is a family of asynchronous Byzantine consensus protocols that achieve optimal resilience (n ≥ 3t + 1) using leaderless and parallel transaction processing.
- The protocols employ threshold signatures, asynchronous rounds, and epochal key refresh to ensure fast and reliable transaction finality in distributed networks.
- OciorABA extends this approach with asynchronous partial vector agreement and erasure-coded broadcasts to offer error-free, information-theoretic secure multi-valued consensus.
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 . 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 (Chen, 1 Sep 2025). 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 bits and expected round complexity (Chen, 20 Jan 2025). 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 (Chen, 1 Sep 2025). 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 (Chen, 20 Jan 2025).
| Protocol | Problem setting | Core stated properties |
|---|---|---|
| Ocior | Practical asynchronous BFT consensus | Leaderless, parallel instances, two-round finality for legitimate two-party transactions, expected communication per transaction |
| OciorABA | Multi-valued asynchronous Byzantine agreement | Error-free, information-theoretically secure, APVA-based, 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
where up to nodes may be Byzantine. This shared threshold places both constructions within the standard optimal regime for asynchronous Byzantine agreement (Chen, 1 Sep 2025).
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 , and the protocol assumes throughout (Chen, 1 Sep 2025).
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 (Chen, 20 Jan 2025).
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 (Chen, 1 Sep 2025). Each of the nodes maintains its own chain and proposes transactions independently.
The protocol proceeds in epochs 0. Before epoch 1 starts, nodes run an asynchronous DKG to obtain fresh TS/LTS keys for that epoch, and old secret shares are erased. On node 2’s chain, heights increase as 3. At height 4, node 5 proposes a transaction 6 together with a virtual parent signature 7, defined as the threshold signature at height 8 on its own chain, and official parent signatures 9 on the parent transaction(s) cited in 0. A proposal message has the form
1
where 2 is the node’s 3-th proposal in epoch 4 (Chen, 1 Sep 2025).
Finality is obtained in two asynchronous rounds for a stated good case. In Round 1 (Propose), proposer 5 multicasts the proposal. In Round 2 (Vote), after validating the virtual parent, the parents, and the correctness of 6, each honest node 7 returns two partial signatures:
8
9
where
0
As soon as the proposer collects
1
valid TS partial shares, it combines them into a full threshold signature 2 via 3. The pair 4 is the Type I APS (Chen, 1 Sep 2025).
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 (Chen, 1 Sep 2025). 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 5, DKG yields a public key 6 and shares 7, and a partial signature is
8
The verification equation is
9
For a set 0 of at least 1 shares, combination is
2
and the final signature verifies by
3
The LTS structure defines 4 layers with parameters 5, satisfying 6 and 7. 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 (Chen, 1 Sep 2025).
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 8 group multiplications in the best case when the good LTS path succeeds, and 9 in the worst case when the protocol falls back to full BLS threshold combination (Chen, 1 Sep 2025).
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 0-bit message 1 and introduces Asynchronous Partial Vector Agreement (APVA) as a new primitive (Chen, 20 Jan 2025). In APVA, each node 2 inputs a length-3 vector
4
where 5 denotes a missing or unknown entry. Honest nodes must eventually output the same vector
6
APVA guarantees three stated properties. Consistency (Agreement) requires that if any honest node outputs 7, every honest node outputs 8. Validity requires that, for each index 9 with 0, there exists at least one honest node 1 whose input has 2, and the number of non-3 entries in 4 is at least 5. Termination requires eventual output when every honest node’s input vector has non-6 values in some common set of at least 7 positions (Chen, 20 Jan 2025).
The APVA protocol interleaves four components: an ACID instance to share each node’s entire input vector, repeated rounds indexed by 8 in which a CommonCoin elects a candidate node 9, a two-phase binary subroutine built from ABBBA + ABBA to decide whether to adopt node 0’s vector, and then a coordinate-wise confirmation using 1 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 (Chen, 20 Jan 2025).
OciorABA itself uses exactly one instance of APVA plus 2 reliable broadcasts. Each node encodes its 3-bit input under an 4 erasure code over an alphabet 5 of size 6, producing symbols
7
such that any 8 distinct symbols suffice to decode the original message. Node 9 RBC-broadcasts 0. 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 1, and decides as follows: if fewer than 2 coordinates equal 3, it outputs the indicator vector; otherwise it selects any 4 such indices, fetches the corresponding RBC outputs, and decodes the message (Chen, 20 Jan 2025).
The protocol’s stated complexity is expected communication complexity 5 bits and expected round complexity 6 rounds under 7 (Chen, 20 Jan 2025). The role of the erasure code is explicit: broadcasting a single coded fragment per node reduces the 8-dependent cost from the 9 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 0 expected communication per transaction, or 1 in bits when CTS signatures have size 2. The computation claim is 3 in the best case and 4 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) (Chen, 1 Sep 2025).
For OciorABA, the dominant metric is expected bit complexity for multi-valued ABA on an 5-bit message. The protocol achieves 6 bits and 7 expected rounds, and the paper positions this against prior error-free asynchronous ABA protocols cited there: Patra ’11 with 8 bits and Nayak et al. ’20 with 9 bits, both at 00 rounds, as well as Li–Chen ’21 with 01 and 02 bits (Chen, 20 Jan 2025).
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 03 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 (Chen, 1 Sep 2025).