{"id":"67681eb0-1eb7-49f4-b0ba-f707a66f157e","arxiv_id":"2508.01856","paper_version":1,"verdict":"REJECT","confidence":"MODERATE","novelty_score":3.0,"correctness_risk":"high","formal_verification":"none","parameter_count":5,"one_line_summary":"A reputation- and VRF-based PBFT variant (EBRC) is proposed for IoT blockchain, claiming lower latency, higher throughput, and improved security in experiments with up to 40 nodes.","lead":"This paper proposes EBRC, a reputation-based Byzantine fault tolerance consensus protocol for IoT blockchain networks, combining node reputation evaluation, VRF random election, and dynamic node join and exit. The authors report lower latency, higher throughput, and lower communication overhead compared to PBFT in simulations with up to 40 nodes.","discovery_kind":"extension","skeptic_critique":{"model":"deepseek-v4-flash","headline":"Two-phase Commit aggregation in §2.4(v)-(vi) cannot preserve PBFT safety: a Byzantine master can withhold or selectively forward the 2f+1 certificate, so the O(n) claim rests on trusting the primary.","rationale":"The reader's weakest_assumption correctly identifies the modified commit phase as the load-bearing fragility, and my analysis reaches the same conclusion: the protocol cannot claim PBFT-equivalent fault tolerance unless every correct replica can independently verify a commit certificate. A faulty primary can equivocate or selectively release the aggregated commits, breaking agreement. This alone invalidates the central efficiency-and-security claim, including the O(n) communication-complexity statement in Section 3.7. A separate, independent issue is that Equation (2) assigns positive weights to the incomplete rate and evil rate, so higher values of tau_i and psi_i increase reputation, directly contradicting the paper's stated goal of penalizing unreliable or malicious nodes. This reinforces the rejection but is not the primary concern. The experimental sections do not repair the protocol gap, since they compare implementations without providing a safety proof or a reproducible fault-injection scenario that exercises a Byzantine primary with selective commit forwarding. Therefore the reader's REJECT verdict stands; no change is needed.","tokens_in":16230,"tokens_out":6776,"duration_ms":96463,"concrete_test":"Run a TLA+ or Spin model of the EBRC commit phase with n=4, f=1, a primary that nondeterministically selects which verified Commit messages to forward to each correct node, and check the agreement invariant that no two correct nodes commit conflicting blocks in the same view. Re-run the same model with PBFT's all-to-all Commit phase as a control; the EBRC model should produce a reachable state violating agreement while the PBFT model does not, isolating the aggregation step as the source of the safety failure.","verdict_should_be":"UNCHANGED","load_bearing_attack":"The central claim requires EBRC to match PBFT's Byzantine fault tolerance while reducing communication to O(n). Section 2.4 steps (v)-(vi) and Figure 3 specify that slave nodes send Commit messages only to the master node, yet step (vi) asserts that 'all consensus nodes receive 2f+1 identical acknowledgment messages.' These statements are incompatible unless the master relays a commit certificate, and no such relay step is specified. In PBFT, every correct replica independently collects 2f+1 Commit messages before executing, making the commit certificate robust against a faulty primary. Here, only the master aggregates the threshold. A Byzantine master can therefore withhold the certificate from some correct replicas or selectively forward it, causing one correct replica to execute a request while another does not. No view-change protocol is described that would repair this divergence, and correct replicas cannot locally verify the 2f+1 count. The claimed reduction from O(n^2) to O(n) in Section 3.7 is thus obtained by moving the all-to-all certificate into a single trusted aggregator, which is exactly the Byzantine assumption the protocol is meant to tolerate. This is the most load-bearing flaw: even if all other components were repaired, the consensus protocol as specified does not preserve safety under the stated failure model.","agreement_with_reader":"agree"},"referee_report":{"model":"deepseek-v4-flash","summary":"The paper proposes EBRC, a PBFT-style consensus mechanism for IoT blockchains that combines reputation-based node evaluation, VRF-based random election, and a dynamic join/exit protocol (DJEP). The central claim, stated in the abstract and Section 3.7, is that EBRC achieves lower consensus delay, higher throughput, improved security, and lower verification costs than PBFT, with communication complexity reduced from O(n^2) to O(n). The consensus protocol is described in Section 2.4 as a two-phase prepare/commit process in which slave nodes send Commit messages only to the master; the reputation model in Section 2.2.1 assigns each node a weighted score; and Section 3 reports experiments comparing EBRC with PBFT on latency, throughput, communication times, and election fairness.","tokens_in":16542,"tokens_out":4680,"duration_ms":52169,"significance":"If the design were sound, the combination of reputation-based screening, VRF election, and reduced communication would be a useful contribution for resource-constrained IoT blockchain deployments. The paper includes a prototype and a reasonably extensive experimental comparison, and the VRF election fairness experiment is a good idea in principle. However, two load-bearing flaws undermine the central claims: the reputation formula in Eq. (2) rewards misbehavior instead of penalizing it, and the two-phase commit protocol with master-only aggregation does not preserve PBFT safety under Byzantine faults. Because these flaws invalidate the security and complexity claims, the significance of the proposed mechanism is not established by the manuscript as written.","major_comments":[{"comment":"The reputation formula R_i = 0.1δ_i + 0.3τ_i + 0.3ψ_i + 0.2φ_i + 0.1ρ_i adds the incomplete rate τ_i and the evil rate ψ_i with positive weights. Since higher τ_i and higher ψ_i denote worse behavior (more failed consensuses and more reported error messages), a node that misbehaves more receives a higher reputation score. This directly contradicts the stated design intent in the same section, where the weights are described as giving the most weight to non-completion and evil rates as a penalty, and it undermines the election mechanism in Table 3, which uses high reputation as a prerequisite for consensus participation. As written, the protocol preferentially elects misbehaving nodes, so the claimed security benefit from reputation screening is not supported.","section":"Section 2.2.1, Eq. (2)"},{"comment":"The protocol specifies that slave nodes send Commit messages only to the master node, and step (vi) states that 'all consensus nodes receive 2f+1 identical acknowledgment messages.' No relay or certificate-broadcast step is specified that would allow replicas other than the master to observe the 2f+1 quorum. A Byzantine master can selectively forward or withhold Commit messages, causing honest replicas to disagree on whether the quorum was reached, which violates safety. The O(n) communication complexity claimed in Section 3.7 is obtained by centralizing quorum validation in the master, which is exactly the entity that a Byzantine fault-tolerant protocol must not trust. The paper does not provide a view-change or certificate-distribution sub-protocol that would repair this divergence.","section":"Section 2.4, steps (v)-(vi); Figure 3"},{"comment":"The dynamic join/exit protocol replaces a failed consensus node with a candidate node without specifying any state transfer or view change. A replacement joining mid-epoch does not have the prepare/commit history or pending-request state of the current consensus round, so it cannot safely participate in an ongoing consensus. The paper does not prove liveness or safety under repeated failures, and the delay measurements in Section 3.6 do not address correctness of the replacement mechanism.","section":"Section 2.5 (DJEP)"}],"minor_comments":[{"comment":"The activity rate is written as φ_i = (t_i + t_i)/T_i; based on the definitions of t_i (offline level) and l_i (network latency level), this is likely a typo for (t_i + l_i)/T_i.","section":"Section 2.2.1"},{"comment":"The text states that with 10 nodes and ω = 0.4, the probability of a node not being selected is 0.01%; for a uniform VRF output, the probability that none of 10 nodes is selected is 0.6^10 ≈ 0.6%, so the quoted figure is inconsistent with the stated model.","section":"Section 2.3"},{"comment":"The Commit message format in Eq. (10) includes 'sn', which is never defined, and the signature is attributed to 'primary node i' rather than to the sending replica.","section":"Section 2.4, step (v)"},{"comment":"The definitions of T_sum and Δt appear to be swapped: the formula is T_tps = T_sum/Δt, but the text says T_tps stands for throughput, T_sum stands for block time, and Δt stands for the total number of transactions during that time.","section":"Section 3.3, Eq. (18)"},{"comment":"The narrative reports that the malicious node election count is 'two times less' than normal nodes in one place and 'fourfold' lower in the next; these statements are inconsistent.","section":"Section 3.5"},{"comment":"The condition 'if Count(CONS ≥ M)' is missing a closing parenthesis, and the subsequent assignment of 'top 85%' as consensus nodes conflicts with Section 2.3, which specifies top 50% consensus nodes and the next 35% as candidates.","section":"Algorithm 2"}],"recommendation":"reject","confidential_remarks":"The two major flaws are load-bearing and not local: the reputation formula in Eq. (2) is internally inconsistent with its stated purpose, and the master-only commit aggregation in Section 2.4 cannot preserve PBFT safety without adding a certificate-broadcast or view-change step, which would negate the claimed O(n) complexity. Fixing these issues would require redesigning the protocol and re-running the experiments, so rejection is appropriate."},"author_rebuttal":null,"desk_editor":{"model":"deepseek-v4-flash","letter":"Tran. Read EBRC. The stress-test concern is correct and it is the main story. In §2.4(v)-(vi), slaves send Commit only to the master; there is no step where the master relays a 2f+1 certificate to the rest. So \"all consensus nodes receive 2f+1 identical acknowledgment messages\" in step (vi) is simply false as specified. A Byzantine master can pick which replicas hear the commit, so one replica executes while another does not. The O(n) complexity claim is bought by trusting the primary, which defeats the purpose. No useful view-change is described. That is a load-bearing flaw, not a typo.\n\nSecond, Eq. (2) uses + weights for incomplete rate τ and evil rate ψ, so nodes that misbehave more get higher reputation. Table 3 then gives those nodes better election odds. Unless the intent was to reward unreliability, this is a sign error. The activity rate formula also has a duplicated t_i, and the text says \"broadcasts to master\" which is odd. These could be cleaned up, but the reputation formula needs a real fix.\n\nWhat is genuinely new: the specific combination of reputation-weighted VRF election, deposit penalties, and a dynamic join/exit protocol is not in the cited papers, and they did build a Sawtooth prototype with up to 40 nodes. The dynamic membership part is a reasonable direction and the experiments at least show the expected structural latency difference. Credit where due.\n\nThe experiments are otherwise weak: no code/data, no error bars, throughput axis labeled in milliseconds, and the election results are described with inconsistent ratios (\"two times less\" vs \"fourfold\"). The comparison to PBFT is unsurprising since EBRC removes an entire communication phase — that is the unsafe phase.\n\nThis paper should not be accepted as a consensus protocol. If the authors repaired the commit aggregation and the reputation sign, there might be a usable incremental contribution, but as written the safety claim does not hold and the incentive structure is backwards. I would not cite it and would not send it to a serious referee in this form.\n\nVerdict: reject.","headline":"A Byzantine master can break the two-phase commit, and Eq. (2) rewards misbehavior; neither is a minor fix.","tokens_in":17030,"tokens_out":3084,"would_cite":false,"duration_ms":37035,"reading_group":"no","serious_thinker":"no","would_accept_peer_review":false},"rs_alignment":null,"lean_confirmation":null,"pith_extraction":{"msc":["68M14"],"pacs":[],"model":"deepseek-v4-flash","headline":"EBRC, a reputation-based Byzantine consensus protocol, claims to reduce IoT blockchain communication overhead from O(n^2) to O(n) while improving latency and throughput.","keywords":["blockchain","Byzantine fault tolerance","PBFT","reputation","verifiable random function","IoT","consensus scalability"],"falsifier":"Run EBRC with a Byzantine master that receives Commit messages from honest slaves but only forwards a subset to the client, or that reorders them, and show that a block is committed although fewer than $2f+1$ distinct honest slaves actually committed; alternatively, run a formal model checker on the two-phase protocol and find a reachable safety violation when the master equivocates.","tokens_in":16045,"feed_emoji":"⛓","tokens_out":4149,"duration_ms":41959,"temperature":0.7,"pith_summary":"The paper proposes EBRC, a Byzantine fault-tolerant consensus protocol for IoT blockchains that combines reputation-based node scoring with verifiable random-function (VRF) election and a dynamic join/exit protocol. The central claim is that by pre-selecting trustworthy nodes and by having slave nodes send Commit messages only to the master, the protocol lowers consensus delay, raises transaction throughput, reduces verification costs, and scales better than classic PBFT. The authors report experiments on a Sawtooth-based prototype with up to 40 nodes showing lower latency and higher throughput than PBFT, including under Byzantine faults. If correct, EBRC offers a path toward practical Byzantine consensus on resource-constrained IoT devices and toward applications such as Internet courts that combine IoT and blockchain.","feed_headline":"Reputation-gated consensus slashes IoT blockchain costs to O(n)","feed_subtitle":"EBRC selects trusted nodes via VRF and shortens PBFT's two-phase commit, claiming lower delay and higher throughput.","key_machinery":"The load-bearing mechanism is the modified two-phase commit: in EBRC's commit phase, each slave node sends its signed Commit message only to the master node, which is responsible for collecting $2f+1$ identical Commit messages before finalizing. The VRF-based election and reputation scoring (with weights $[0.1, 0.3, 0.3, 0.2, 0.1]$ on margin ratio, incomplete rate, evil rate, activity rate, and transaction magnitude factor) determine which nodes are even eligible to be part of the consensus committee, and the dynamic join/exit protocol keeps the committee size above $3f+1$.","core_discovery":"The paper claims that a reputation-aware, VRF-elected committee can run a two-phase PBFT-like consensus with substantially lower communication complexity. The key change is that in the commit phase, slave nodes send their Commit messages only to the master node rather than broadcasting to all peers; the master aggregates $2f+1$ identical Commit messages, then replies to the client and writes the block. Combined with reputation-based election (nodes with low completion rates, high error rates, or low activity are unlikely to be chosen) and a dynamic join/exit protocol that replaces failed nodes with candidates from the top-85% reputation bracket, EBRC is claimed to maintain fault tolerance while reducing consensus delay, increasing throughput, and lowering communication cost from $O(n^2)$ to $O(n)$ in stable networks.","pith_inferences":["If the master in EBRC can equivocate or selectively forward Commit messages, honest replicas may not be able to verify that $2f+1$ distinct nodes actually committed, so the paper's safety claim rests on an unproven assumption about the aggregated-commit protocol.","The reputation inputs themselves depend on honest reporting by other nodes; a sybil or colluding group could inflate or deflate reputation values, so the security guarantee ultimately rests on reporting honesty rather than on cryptographic enforcement.","A testable extension would be to compare EBRC's committee-election fairness against a VRF-only baseline without a reputation gate, in order to isolate the contribution of reputation scoring."],"forward_implications":["If EBRC's claims hold, IoT blockchain deployments can support more nodes with fixed bandwidth, since per-round messages grow linearly rather than quadratically in committee size.","Reputation-based election implies that nodes with a history of failures or faults are systematically excluded, reducing the chance of Byzantine nodes entering the consensus set.","The dynamic join/exit protocol makes it practical to replace failed or leaving nodes during an epoch, keeping the network operational without restarting consensus.","The reduction in verification and communication cost could make Byzantine fault tolerance feasible on devices with constrained bandwidth and battery.","The comparison table suggests EBRC is the only algorithm among PBFT, DBFT, EPBFT, Trust-PBFT, T-PBFT, and Tu that combines reliability evaluation, election fairness, punishment, $O(m^2)$ complexity with $m < n$, and dynamic network suitability."],"supporting_citations":[{"why":"Castro and Liskov's PBFT is the baseline protocol EBRC modifies, providing the $3f+1$ fault-tolerance model and the original all-to-all communication pattern.","marker":"[22]"},{"why":"Micali-Rabin-Vadhan's verifiable random function supplies the primitive used for fair, unpredictable committee election.","marker":"[36]"},{"why":"Li et al.'s EPBFT is an earlier VRF-based PBFT variant whose election approach EBRC extends.","marker":"[31]"},{"why":"Tong et al.'s Trust-PBFT combines trust evaluation with PBFT and serves as a comparison point for EBRC's reputation mechanism.","marker":"[32]"},{"why":"Tu et al.'s reputation-voting PBFT scheme is criticized for lacking a detailed reputation calculation, which EBRC aims to supply.","marker":"[34]"}],"fun_headline_variants":["Reputation-gated consensus cuts IoT blockchain cost to O(n)","VRF-elected reputation committee slashes consensus delay","Two-phase PBFT with reputation: IoT blockchain at O(n)","Reputation-based committee slashes verification costs in IoT","EBRC: trust-based election turns Byzantine consensus linear"],"cache_read_input_tokens":3200,"weakest_assumption_plain":"The central assumption is that having slave nodes send Commit messages only to the master, and letting the master collect $2f+1$ of them, preserves the same Byzantine fault tolerance as PBFT's all-to-all broadcast commit phase.","fun_headline_variants_meta":{"raw":{"variants":["Reputation-gated consensus cuts IoT blockchain cost to O(n)","VRF-elected reputation committee slashes consensus delay","Two-phase PBFT with reputation: IoT blockchain at O(n)","Reputation-based committee slashes verification costs in IoT","EBRC: trust-based election turns Byzantine consensus linear"]},"model":"deepseek-v4-flash","effort":"low","cost_usd":0.000443,"raw_usage":{"total_tokens":2230,"prompt_tokens":919,"completion_tokens":1311,"prompt_tokens_details":{"cached_tokens":384},"prompt_cache_hit_tokens":384,"prompt_cache_miss_tokens":535,"completion_tokens_details":{"reasoning_tokens":1232}},"tokens_in":535,"tokens_out":1311,"duration_ms":10500,"temperature":1.0,"reasoning_tokens":1232,"cache_read_input_tokens":384,"cache_creation_input_tokens":0},"cache_creation_input_tokens":0},"created_at":"2026-08-06T05:20:36.209056+00:00","model_set":{"reader":"deepseek-v4-flash"},"falsifier":"Run EBRC with a Byzantine master that receives Commit messages from honest slaves but only forwards a subset to the client, or that reorders them, and show that a block is committed although fewer than $2f+1$ distinct honest slaves actually committed; alternatively, run a formal model checker on the two-phase protocol and find a reachable safety violation when the master equivocates.","supporting_citations":[{"cited_title":"Practical byzantine fault tolerance and proactive recovery,","cited_arxiv_id":null,"evidence_quote":"Castro and Liskov's PBFT is the baseline protocol EBRC modifies, providing the $3f+1$ fault-tolerance model and the original all-to-all communication pattern."},{"cited_title":"Verifiable random func- tions,","cited_arxiv_id":null,"evidence_quote":"Micali-Rabin-Vadhan's verifiable random function supplies the primitive used for fair, unpredictable committee election."},{"cited_title":"An extensible consensus algo- rithm based on PBFT,","cited_arxiv_id":null,"evidence_quote":"Li et al.'s EPBFT is an earlier VRF-based PBFT variant whose election approach EBRC extends."},{"cited_title":"Trust-PBFT: a peertrust- based practical byzantine consensus algorithm,","cited_arxiv_id":null,"evidence_quote":"Tong et al.'s Trust-PBFT combines trust evaluation with PBFT and serves as a comparison point for EBRC's reputation mechanism."},{"cited_title":"Improved PBFT scheme based on reputation voting,","cited_arxiv_id":null,"evidence_quote":"Tu et al.'s reputation-voting PBFT scheme is criticized for lacking a detailed reputation calculation, which EBRC aims to supply."}],"review_version":1}