{"id":"feb353ea-1550-4ddb-aba7-e6a6e696668d","arxiv_id":"2504.21410","paper_version":1,"verdict":"CONDITIONAL","confidence":"MODERATE","novelty_score":6.0,"correctness_risk":"medium","formal_verification":"none","parameter_count":0,"one_line_summary":"ORION composes HotStuff and Damysus into a geo-replicated BFT protocol in which cluster confirmation replaces trusted components, tolerating up to F crashed clusters and Byzantine global representatives.","lead":"ORION is a hierarchical blockchain consensus protocol that keeps working even when every member of the global voting group is malicious or unreachable. It replaces trusted hardware with per-cluster majority confirmation and rotates representatives to recover liveness, achieving 20% higher throughput than GeoBFT in AWS tests.","discovery_kind":"new_method","skeptic_critique":{"model":"deepseek-v4-flash","headline":"Central safety theorem assumes a 'sequenced' cluster-confirmation state machine that Algorithm 2 does not implement; until the pseudocode enforces one-token-per-state approval, the all-Byzantine-global-group safety claim is unproved.","rationale":"The reader's weakest assumption identifies the same load-bearing gap I find: the compositional safety theorem depends on a sequenced cluster-confirmation property that Algorithms 1 and 2 do not implement. The paper's abstract claims safety even when all global-group members are Byzantine; that claim is the paper's central contribution, and it is supported only by the abstract equivalence in Theorem 2. Since the equivalence is not discharged by the supplied state machine, the correct verdict is conditional: the construction is plausible and the compositionality idea is genuinely interesting, but the safety guarantee is unproved for the code as given. I do not find additional independent objections beyond the reader's analysis; the rotation-liveness argument is also asserted rather than proved, but the safety gap alone is sufficient to block acceptance. The performance evaluation and the use of known building blocks (HotStuff, Damysus, consistent broadcast) are credible and do not affect this assessment. The fix is concrete: specify a per-replica state machine that advances the confirmed-superblock state before signing, records the signed (view, phase, hash) tuple, and rejects out-of-sequence requests, then prove that this machine satisfies Definition 4. With that addition, the central theorem could become sound.","tokens_in":15526,"tokens_out":6602,"duration_ms":77907,"concrete_test":"Build a TLA+ model of one cluster (n=4, f=1) plus one Byzantine representative executing Algorithms 1 and 2 exactly as written. Add the safety invariant: for each view and phase, at most one cluster confirmation can be produced from each cluster per distinct chain-extension state. Let the Byzantine representative send two Cl-Prepare requests for different superblock extensions before any local replica has advanced its committed chain state. Run TLC to see whether two distinct prepare confirmations are reachable, or whether the model is under-specified because no state-advance step precedes signing. Separately, check whether the 'phase++' in CreateClusterSign is ever reset or bound to the confirmed superblock hash; if no such binding exists, the sequencing requirement of Definition 4 is not implemented.","verdict_should_be":"UNCHANGED","load_bearing_attack":"The paper's headline safety claim rests on Theorem 2, which equates cluster confirmation with Damysus's trusted accumulator. That equivalence is only argued for 'sequenced' confirmation (Definition 4): replicas must advance the state they plan to change as part of obtaining a confirmation, and approve messages only from that advanced state. The supplied pseudocode does not implement this sequencing. In Algorithm 2, CreateClusterSign lets a replica sign the tuple (h, view, h', v', phase) and then executes 'phase++'; it never records the confirmed superblock hash h, never checks that h extends the replica's current confirmed chain state, and advances only an unrelated phase counter after signing rather than advancing the chain state before approval. Cl-Prepare (Algorithm 2, lines 17-20) verifies only the current view and h != bottom, not that the requested transition extends the replica's current state; Cl-Pcom similarly checks only view and phase. The proof of Lemma 1 and Theorem 2 requires that a healthy replica accept a state transition only after n-f replicas have confirmed the preceding transition, but no such per-chain-state tracking appears in Algorithms 1 or 2. A Byzantine representative can therefore solicit cluster signatures on messages that are not sequenced with respect to the cluster's confirmed superblock chain, or can request two confirmations at the same phase against different chain states if the phase counter is reset or reused across views. Whichever interleaving is possible, the trusted-component equivalence invoked in Theorem 2 is an assumption about the implementation, not a property the code establishes. The central claim that ORION 'safely operate[s] through situations where all members of the global consensus group are Byzantine' is therefore not proven for the algorithm as written.","agreement_with_reader":"agree"},"referee_report":{"model":"deepseek-v4-flash","summary":"The manuscript proposes ORION, a hierarchical Byzantine fault-tolerant consensus protocol for geo-replicated blockchains. It combines HotStuff for local cluster consensus, consistent broadcast for block dissemination, and a Damysus-style global consensus layer in which per-cluster confirmation is meant to replace Damysus's trusted checker and accumulator. The main theoretical contribution is a compositionality claim (Section VI, Theorems 1 and 2): if the local subprotocols are safe and live, then cluster-confirmed state transitions plus a rotating global group yield global safety and liveness, even when all global representatives are Byzantine. The paper also reports an AWS-based evaluation showing higher throughput than GeoBFT and non-hierarchical baselines.","tokens_in":15789,"tokens_out":11120,"duration_ms":117685,"significance":"The idea of replacing trusted components with cluster-level quorum confirmations is original and potentially useful; it would give a principled construction of hierarchical BFT protocols from non-hierarchical ones without trusted hardware, and the combination of HotStuff and Damysus is novel. The paper's proof strategy is clearly stated, and the comparison to GeoBFT provides a useful datapoint. However, the central safety theorem depends on a sequencing invariant that is not implemented in the pseudocode, and the rotation/liveness argument is asserted rather than proved. The paper also does not ship code or machine-checked proofs, so the formal claims are supported only by an informal proof sketch. Since the gaps are load-bearing for the headline claim, the paper as submitted is not yet publishable, but the issues appear addressable within the manuscript's scope.","major_comments":[{"comment":"The proof that cluster confirmation emulates Damysus's trusted accumulator assumes a sequencing property that the pseudocode does not implement. Definition 4 states that state transitions are executed under cluster confirmation only if n−f replicas approve, and the following paragraph requires confirmations to be 'sequenced'; Lemma 1's proof then assumes that a healthy replica accepts a new state s′ only after n−f replicas confirmed the transition leading to s′. In Algorithm 2, CreateClusterSign signs the tuple (h, view, h′, v′, phase) and only then executes phase++; it never records the confirmed hash h, never checks that h extends the replica's currently confirmed chain, and increments the phase counter after signing rather than advancing the chain state before approval. The pseudocode also does not specify whose `phase` is used when the leader combines partial signatures, since the replica branch increments a per-replica phase after signing. Cl-Prepare (lines 17–20) verifies only VERIFY(Ext), view = v, and h ≠ ⊥; Cl-Pcom verifies only view, phase, and signatures; Algorithm 1, line 17 checks only SB > h′. A Byzantine representative can therefore obtain cluster confirmations for two different superblocks at the same phase, or for a superblock that does not extend the highest confirmed superblock, because no per-chain-state monotonicity is enforced. Consequently the equivalence between cluster confirmation and a trusted accumulator is not established, and Theorem 2's safety guarantee for an all-Byzantine global group does not follow from the given protocol. Please modify CreateClusterSign and the local confirmation checks to record, for each view and phase, the last confirmed superblock hash and to reject any approval that does not extend it, or provide a precise invariant and proof that the current checks already guarantee sequencing.","section":"§V-C, Algorithm 2; §VI, Definition 4, Lemma 1, Theorem 2"},{"comment":"The liveness conclusion rests on the assertion that 'our rotation scheme iterates through all combinations of replicas from the individual clusters,' but this is not demonstrated. The pseudocode's NewView phase merely increments `view` on timeout or execution and sends a cluster-signed message to the next view's leader; there is no proof that this process deterministically enumerates all combinations of representatives, that it cannot be stalled indefinitely by Byzantine representatives suppressing messages, or that each configuration with at most F faulty representatives is held for time t. Since Theorem 1's precondition is t-rotation safety, this is a load-bearing gap. Please specify the rotation schedule and prove that it reaches and dwells in healthy configurations repeatedly after GST.","section":"§VI, final paragraph; Algorithm 1, lines 41–47"},{"comment":"The text states that a superblock is accepted only if blocks from a cluster are queued in a local-order preserving manner and stored durably in at least F+1 clusters, but no pseudocode path verifies these conditions. In the Prepare phase, representatives check only VERIFY and SB > h′ (Alg. 1, line 17), and Cl-Prepare checks only VERIFY(Ext), view, and h ≠ ⊥ (Alg. 2, lines 17–20). A Byzantine global leader can therefore obtain cluster confirmations for a superblock that references blocks that are absent, out of order, or not durably stored, and the Decide phase (lines 34–38) then instructs replicas to execute it. Global durability is thus not enforced by the protocol as written; either the confirmation functions must include the availability/ordering checks, or the paper must provide an additional argument that blocks referenced by a cluster-confirmed superblock are guaranteed to be present at all correct replicas.","section":"§IV (superblock acceptance conditions) vs. Algorithm 1 and Algorithm 2"}],"minor_comments":[{"comment":"The text says 'A cluster confirmation is referred to as an n-cluster confirmation if it encompasses N signatures from separate clusters'; the symbol n is already used for the number of replicas per cluster, so this should be 'N-cluster confirmation' or the notation should be made consistent.","section":"§V-C, 'Clusters confirmations' paragraph"},{"comment":"In Cl-Pcom, the assignment 'preph← h ; preph← v ;' overwrites preph with v; the second assignment should presumably set a separate variable (e.g., prepv).","section":"Algorithm 2, line 24"},{"comment":"'HotSuff-based consensus protocol' contains a typo; it should be 'HotStuff-based'.","section":"§V-B"},{"comment":"The phrase 'Since n−f>f' is used to argue about global quorums, but the global threshold is F+1 out of N=2F+1; please keep the cluster-level n/f and the global F/N notation distinct to avoid confusion.","section":"§VI, Theorem 2 proof"},{"comment":"No fault-injection experiments are described; the claim that ORION 'outperforms GeoBFT in terms of throughput under faults' is not supported by the reported evaluation, which only varies cluster sizes and numbers of clusters.","section":"§VII"}],"recommendation":"major_revision","confidential_remarks":"I am not recommending rejection: the primary gap is a missing protocol mechanism or invariant that can be added. However, the authors should not be allowed to respond that sequencing is 'implicit' without giving a precise invariant and showing where the pseudocode maintains it; the current text is too ambiguous. The evaluation also lacks fault-injection experiments, which the authors may wish to address in revision."},"author_rebuttal":null,"desk_editor":{"model":"deepseek-v4-flash","letter":"First, the important thing to know: ORION has a genuinely new mechanism — cluster confirmation as a software substitute for Damysus's trusted checker/accumulator — and the compositionality framing is the right way to evaluate it. The paper is not ready to be accepted, because the central safety theorem relies on a sequencing property that the supplied algorithms do not actually implement. But the gap is specific and fixable, not a dead end.\n\nWhat's new: most hierarchical BFT protocols are bespoke PBFT variants with heavy view changes. ORION instead assembles HotStuff, Damysus, and consistent broadcast; separates block formation, dissemination, and global ordering; and uses cluster confirmation plus rotation so the global group can be entirely Byzantine without trusted hardware. The 2F+1 cluster count and the 20% throughput improvement over GeoBFT are consistent with that design. The paper is well written and the related work is fair. There are no fitted parameters, no self-serving circularity, and nothing that smells fabricated.\n\nWhere the soft spots are: the proof of Theorem 2 equates cluster confirmation with Damysus's trusted accumulator. That equivalence depends on Definition 4's \"sequenced\" confirmation: a healthy replica must advance the state it intends to change before approving, and must approve only from that advanced state. The pseudocode in Algorithm 2 does not do this. CreateClusterSign signs (h, view, h', v', phase) and increments a phase counter; it never records the confirmed superblock hash h, never checks that h extends the replica's current chain, and Cl-Prepare only checks view and h != bottom. So a Byzantine representative can solicit two cluster confirmations at the same phase for different superblocks, or against a stale chain state. The trusted-component equivalence in Theorem 2 is then an assumption, not a property the code establishes. This is load-bearing: it is exactly the mechanism that supposedly keeps safety when all global-group members are Byzantine.\n\nThe liveness side has a smaller but real gap. The paper asserts that rotation iterates through all representative combinations and therefore repeatedly reaches healthy configurations, but no bound or schedule argument is given, and the \"t-rotation safe\" precondition is asserted rather than proved. The evaluation is credible but light — AWS, 30 views, no fault injection beyond what the baseline comparison implies.\n\nWho should read it: people working on hierarchical BFT or hybrid protocols will find the construction idea useful, even in its current incomplete form. Verdict: I would send this to peer review rather than desk-reject, because the novel mechanism and the compositionality result deserve referee attention — but I would require the authors to implement true per-chain-state sequencing in the cluster confirmation state machine and prove the rotation coverage property before acceptance.","headline":"A genuinely useful construction idea with a load-bearing gap: cluster confirmation as a trusted-component substitute is not sequenced in the pseudocode, so the headline all-Byzantine safety claim is unproved as written.","tokens_in":16397,"tokens_out":3870,"would_cite":false,"duration_ms":40852,"reading_group":"maybe","serious_thinker":"yes","would_accept_peer_review":true},"rs_alignment":null,"lean_confirmation":null,"pith_extraction":{"msc":[],"pacs":[],"model":"deepseek-v4-flash","headline":"ORION claims that cluster confirmation plus rotation keeps geo-replicated Byzantine consensus safe even when every member of the global group is Byzantine, and supports the claim with a compositionality proof and a 20% higher throughput…","keywords":["Byzantine fault tolerance","hierarchical consensus","geo-replication","blockchain","cluster confirmation","HotStuff","Damysus","partial synchrony"],"falsifier":"Inspect Algorithm 2's CreateClusterSign for a record of the last signed $(h, view, phase)$; if no such record exists, a Byzantine representative can obtain confirmations for two different superblocks in the same phase from healthy local replicas, violating the sequencing premise of Theorem 2. A run that produces two cluster-confirmed prepare messages for different superblocks in one view would settle the central safety claim in the negative.","tokens_in":15317,"feed_emoji":"🌍","tokens_out":9944,"duration_ms":94429,"temperature":0.7,"pith_summary":"The paper tries to establish that hierarchical Byzantine fault-tolerant consensus can be built safely from non-hierarchical building blocks without trusted hardware: a cluster's internal quorum of replicas can serve as the trusted checker and accumulator that hybrid protocols like Damysus use, and rotating which replicas form the global group preserves liveness even when every global representative is Byzantine. This matters because geo-replicated blockchains could then keep safety through accidental or malicious disasters that compromise the entire inter-cluster layer, while still gaining speed from local ordering. The paper demonstrates the construction by combining HotStuff for local ordering and Damysus for global consensus into ORION, proves a compositionality result, and reports about 20% higher throughput than GeoBFT with a modest latency increase.","feed_headline":"ORION stays safe even if every global consensus delegate is Byzantine","feed_subtitle":"Cluster confirmations replace trusted hardware, delivering 20% higher throughput than GeoBFT on geo-distributed blockchains.","key_machinery":"The load-bearing object is the cluster confirmation $\\varphi = \\langle h, v, h', v', ph, \\vec{\\sigma}_c^n \\rangle$, a certificate that $2f_i+1$ replicas of one cluster have signed off on a global-group message in a given phase. The functions C-combine and C-match turn $F+1$ cluster confirmations into a global quorum certificate and check that enough confirmations from distinct clusters arrived. The proof treats these confirmations as a faithful replacement for Damysus's trusted checker and accumulator, while the rotation scheme (replacing representatives after progress or timeout) repeatedly returns the global group to a configuration with at most $F$ faulty members; that combination is what extends local safety and liveness to the global level.","core_discovery":"The central claim is that cluster confirmation emulates Damysus's trusted services well enough to make the global group safe even when all of its representatives are Byzantine. A cluster confirmation is an approval signed by at least $2f_i+1$ replicas of a cluster for a message that the cluster's representative wants to send during global consensus; because a Byzantine representative cannot forge such an approval, the confirmation acts like an unforgeable token that has already checked the protocol's safety condition. The paper proves (Theorems 1 and 2) that if the cluster subprotocols are safe and live, then the composition with cluster confirmation and global rotation is safe and live, provided confirmations are sequenced and rotation repeatedly returns to a configuration with at most $F$ faulty representatives. ORION instantiates this with HotStuff for local pre-ordering and a three-phase Damysus-style global protocol in which superblocks carry only hashes of local blocks.","pith_inferences":["Editorial inference: the protocol text does not fully establish the sequenced-confirmation condition that Theorem 2 needs, because Algorithm 2's CreateClusterSign does not record previously signed $(h, view, phase)$ values; implementing that bookkeeping, such as rejecting any confirmation that does not extend the last confirmed superblock, would close the gap.","Editorial inference: the idea of replacing a trusted component with a cluster quorum is not limited to Damysus; other hybrid BFT protocols that rely on a trusted monotonic counter could in principle substitute cluster confirmations for the counter, reducing hardware requirements in geo-replicated settings.","Editorial inference: because global consensus runs on hashes, a natural next experiment is to map ORION's throughput against superblock size and inter-cluster bandwidth; the reported 20% improvement over GeoBFT is measured at one deployment configuration and may shift as those parameters change."],"forward_implications":["Global safety no longer depends on any member of the global group being honest: every global message that changes the chain must carry approval from honest local quorums, so the inter-cluster layer can delay but not corrupt the chain.","Geo-replicated blockchains built this way keep their durability guarantee through whole-cluster disasters, such as fires or blackouts, as long as each surviving cluster still has $2f_i+1$ correct replicas to confirm global messages.","Block dissemination becomes fully asynchronous and decoupled from ordering, because global superblocks only carry hashes of local blocks; throughput can then scale without paying wide-area bandwidth for transaction data.","The compositionality theorem means other safe and live local protocols can be lifted to the global level using cluster confirmation and rotation, without adding trusted hardware.","In the reported wide-area deployment, ORION beats GeoBFT by about 20% throughput at roughly 31% higher latency, and beats non-hierarchical PBFT and HotStuff on both throughput and latency."],"supporting_citations":[{"why":"Supplies Damysus, the hybrid global consensus protocol whose trusted checker and accumulator ORION replaces with cluster confirmation.","marker":"[11]"},{"why":"Supplies HotStuff, used inside clusters for local pre-ordering and rotation-based view changes.","marker":"[14]"},{"why":"Introduces Steward, the earlier hierarchical construction from non-hierarchical building blocks and the crash-cluster model ORION follows.","marker":"[2]"},{"why":"Supplies GeoBFT, the hierarchical BFT baseline against which ORION's throughput and latency are measured.","marker":"[4]"},{"why":"Supplies PBFT, a classical baseline used in the evaluation and in related hierarchical designs.","marker":"[15]"},{"why":"Provides the partial-synchrony model with a known bound after GST on which the liveness argument rests.","marker":"[38]"},{"why":"Provides the asynchronous reliable broadcast primitive used for consistent block dissemination between clusters.","marker":"[39]"},{"why":"Provides the practical consistent broadcast implementation the protocol uses for block dissemination.","marker":"[40]"}],"fun_headline_variants":["ORION: safe when every global delegate is Byzantine","Cluster confirmations replace trusted hardware against global Byzantine","ORION uses cluster confirmations to beat Byzantine delegates","No trusted hardware: ORION tolerates all-Byzantine global group","ORION: 20% faster, safe even with all-Byzantine delegates"],"cache_read_input_tokens":3200,"weakest_assumption_plain":"The safety proof assumes cluster confirmations are sequenced, namely that a local replica advances to the state it will approve and never approves two conflicting global messages for the same phase, but the Algorithm 2 pseudocode shown for creating a cluster confirmation does not implement that bookkeeping.","fun_headline_variants_meta":{"raw":{"variants":["ORION: safe when every global delegate is Byzantine","Cluster confirmations replace trusted hardware against global Byzantine","ORION uses cluster confirmations to beat Byzantine delegates","No trusted hardware: ORION tolerates all-Byzantine global group","ORION: 20% faster, safe even with all-Byzantine delegates"]},"model":"deepseek-v4-flash","effort":"low","cost_usd":0.000656,"raw_usage":{"total_tokens":2987,"prompt_tokens":911,"completion_tokens":2076,"prompt_tokens_details":{"cached_tokens":384},"prompt_cache_hit_tokens":384,"prompt_cache_miss_tokens":527,"completion_tokens_details":{"reasoning_tokens":1989}},"tokens_in":527,"tokens_out":2076,"duration_ms":15852,"temperature":1.0,"reasoning_tokens":1989,"cache_read_input_tokens":384,"cache_creation_input_tokens":0},"cache_creation_input_tokens":0},"created_at":"2026-08-16T05:03:35.360623+00:00","model_set":{"reader":"deepseek-v4-flash"},"falsifier":"Inspect Algorithm 2's CreateClusterSign for a record of the last signed $(h, view, phase)$; if no such record exists, a Byzantine representative can obtain confirmations for two different superblocks in the same phase from healthy local replicas, violating the sequencing premise of Theorem 2. A run that produces two cluster-confirmed prepare messages for different superblocks in one view would settle the central safety claim in the negative.","supporting_citations":[{"cited_title":"DAMYSUS: stream- lined BFT consensus leveraging trusted components,","cited_arxiv_id":null,"evidence_quote":"Supplies Damysus, the hybrid global consensus protocol whose trusted checker and accumulator ORION replaces with cluster confirmation."},{"cited_title":"Hot- Stuff: BFT consensus with linearity and responsiveness,","cited_arxiv_id":null,"evidence_quote":"Supplies HotStuff, used inside clusters for local pre-ordering and rotation-based view changes."},{"cited_title":"Steward: Scaling byzantine fault-tolerant repli- cation to wide area networks,","cited_arxiv_id":null,"evidence_quote":"Introduces Steward, the earlier hierarchical construction from non-hierarchical building blocks and the crash-cluster model ORION follows."},{"cited_title":"Resilientdb: Global scale resilient blockchain fabric,","cited_arxiv_id":null,"evidence_quote":"Supplies GeoBFT, the hierarchical BFT baseline against which ORION's throughput and latency are measured."},{"cited_title":"Asynchronous byzantine agreement protocols,","cited_arxiv_id":null,"evidence_quote":"Provides the asynchronous reliable broadcast primitive used for consistent block dissemination between clusters."},{"cited_title":"Practical byzantine reliable broadcast on partially connected networks,","cited_arxiv_id":null,"evidence_quote":"Provides the practical consistent broadcast implementation the protocol uses for block dissemination."}],"review_version":1}