{"id":"dbf0c77e-af9c-4831-adb2-9dd7e4a0936a","arxiv_id":"2411.13039","paper_version":3,"verdict":"CONDITIONAL","confidence":"MODERATE","novelty_score":5.0,"correctness_risk":"medium","formal_verification":"none","parameter_count":2,"one_line_summary":"A permissioned-blockchain framework for IoT that uses a two-phase PBFT protocol to approve non-deterministic task schedules while keeping Byzantine fault tolerance across heterogeneous edge nodes.","lead":"TrustMesh is a blockchain-based framework that lets Internet of Things devices run computing jobs across untrusted edge nodes while recording every decision on an auditable ledger. It adds a multi-phase voting protocol so non-deterministic scheduling policies can still get Byzantine fault tolerance, and tests it on a 21-node cold chain monitoring setup.","discovery_kind":"new_method","skeptic_critique":{"model":"deepseek-v4-flash","headline":"Designation phase lacks a Byzantine-safe mechanism for agreeing on resource state R; Safety Property 1 fails under asynchronous updates, so the non-deterministic scheduling + BFT claim is unsupported.","rationale":"The reader's weakest assumption, inconsistent resource state R, is the decisive soft spot. My stress-test confirms that the problem is deeper than a missing synchronization detail: the paper leaves the actor and consensus mechanism for designation unspecified, and the implementation choices (sharded Redis, multi-master CouchDB) actively preclude a global R snapshot. Safety Property 1 is the foundation for Agreement and Validity, so this gap undermines the central claim before PBFT is even invoked. I also note that even with a synchronized R, the non-deterministic scheduling allowance means a Byzantine designated node can propose any schedule that satisfies the static validation rules V, and PBFT will confirm it; the framework provides Byzantine agreement on a schedule, not Byzantine-fault-tolerant scheduling in the sense the abstract advertises. The paper deserves credit for a working implementation, a real testbed, and plausible measurements, but the key innovation as stated is not established. The concrete test would settle whether the designation gap manifests in practice. I recommend keeping the reader's CONDITIONAL verdict, because the issue is fixable in principle by adding a consensus step that agrees on a resource snapshot or by using a verified deterministic designation; however, as written the main claim is unsupported.","tokens_in":12010,"tokens_out":11600,"duration_ms":127798,"concrete_test":"Independently re-derive Safety Property 1 from Section III-B2 without the 'atomic operations' assertion, then inspect the Zenodo code (doi 10.5281/zenodo.14677989) to see how the schedule request transaction captures nd and whether the smart contract recomputes f(N,R) from local cache. Run a 4-node TrustMesh deployment, deliberately desynchronize the resource caches (e.g., stop resource updates on one node), and submit one schedule request; record whether all nodes compute the same nd and whether the confirmation phase accepts a proposal from the 'wrong' node. If honest nodes disagree on nd, or both proposals pass validation, Safety Property 1 fails and the BFT claim is refuted.","verdict_should_be":"UNCHANGED","load_bearing_attack":"Safety Property 1 and the entire multi-phase protocol require all nodes to compute the same designated node nd = f(N,R) from Eq. (2). Section IV-A asserts this follows from 'atomic operations for consistent views', but Sections III-B1 and V-C specify a sharded Redis cache for R with asynchronous batched updates and CouchDB multi-master persistence; neither provides a globally consistent snapshot of R. The paper does not specify which actor executes phi_1 or how the resulting nd is agreed upon. If each node evaluates f against its local cache, honest nodes can disagree and both consider themselves designated, breaking validity and agreement before PBFT runs. If instead nd is fixed by a single proposer and recorded in a PBFT transaction, a Byzantine proposer can choose an arbitrary nd, so deterministic designation is not enforced. Either way, the claimed ability to support non-deterministic scheduling while maintaining Byzantine fault tolerance lacks a working mechanism for the designation phase. The unverifiable nature of non-deterministic schedule output then compounds this: a Byzantine designated node can propose any schedule satisfying the static rules V (Eq. 5), and PBFT will confirm it.","agreement_with_reader":"agree"},"referee_report":{"model":"deepseek-v4-flash","summary":"The paper proposes TrustMesh, a three-layer permissioned-blockchain framework for trusted distributed computing in heterogeneous IoT environments. Its central contribution is a multi-phase PBFT-based protocol (designation, generation, confirmation) that is claimed to allow non-deterministic scheduling algorithms, such as heuristics or machine learning, while preserving Byzantine fault tolerance. The protocol uses a deterministic designation function f(N,R) to select a designated node that generates a schedule, which is then validated and confirmed via PBFT. The paper presents informal safety and liveness proofs, an implementation using Hyperledger Sawtooth, CouchDB, Redis, and Kubernetes, and an experimental evaluation on a 21-node testbed with a cold-chain monitoring workflow, reporting resource utilization, scalability, and Byzantine fault tolerance results.","tokens_in":12213,"tokens_out":2986,"duration_ms":31839,"significance":"If the central claim holds, the paper addresses a real limitation of BFT-based blockchains: the usual requirement of deterministic transaction validation rules. TrustMesh's approach of separating non-deterministic schedule generation from deterministic validation is conceptually promising and could enable ML-based and heuristic schedulers in permissioned BFT networks. The paper provides direct experimental measurements, a public code repository, and falsifiable performance claims (e.g., fault detection under 150 ms, consistent framework overhead). However, the significance is contingent on the multi-phase protocol actually providing a Byzantine-safe designation mechanism, which the current manuscript does not establish. The 'formal verification' is an informal prose proof that glosses over the most load-bearing step, namely consistent agreement on resource state R.","major_comments":[{"comment":"Safety Property 1 claims that the designation function f(N,R) always produces the same designated node nd, but the manuscript provides no mechanism by which all honest nodes obtain a consistent view of R. Sections III-B1 and V-C describe R as maintained in a sharded Redis cache with asynchronous batched updates, and CouchDB uses multi-master replication with eventual consistency; neither provides a globally consistent snapshot. If nodes evaluate f against different local views of R, they can disagree on nd, which breaks validity and agreement before PBFT is even invoked. The proof's reference to 'atomic operations for consistent views' is not a mechanism. The paper must specify how a Byzantine-safe consistent R is obtained (e.g., by including resource-state updates in PBFT-ordered transactions) or the deterministic designation claim is unsupported.","section":"Section IV-A, Eq. (2)"},{"comment":"The protocol does not specify which actor executes phase ϕ1 or how the resulting nd is agreed upon and enforced. If every node independently computes f(N,R) and both an honest node and a Byzantine node consider themselves designated, the system can have competing proposals, defeating the single-proposer structure that PBFT confirmation relies on. If instead a single proposer computes nd and records it in a transaction, a Byzantine proposer can choose an arbitrary nd. The paper needs a concrete mechanism for securely determining and committing nd before the generation phase, or the claim that non-deterministic scheduling can be supported while preserving Byzantine fault tolerance remains unsupported.","section":"Section III-B2, phases ϕ1–ϕ3"},{"comment":"The liveness proof assumes synchrony and 'reliable event delivery via blockchain subscription', but these assumptions are not stated precisely or reconciled with the eventual-consistency properties of the Redis/CouchDB data layer described in Sections V-C and III-B1. The paper states in Section V-C that the combination 'supports the eventual consistency model appropriate for IoT environments', which is in tension with the synchrony and atomicity assumptions used in the safety proof. The authors should either provide a clean asynchronous or partially-synchronous model with explicit guarantees for the cache and persistent store, or weaken the liveness claims accordingly. The current informal proof, which lists bullet points rather than establishing invariant preservation, is not sufficient as a 'formal verification'.","section":"Section IV, Liveness Property 1 and C"},{"comment":"The Byzantine fault tolerance evaluation considers only two synthetic attack scenarios on a 16-node network with 5 Byzantine nodes, and reports 100% detection with zero false positives. These scenarios are narrow: they test unauthorized schedule proposals by a non-designated node and request interference by a designated node, but they do not test equivocation, collusion among multiple Byzantine nodes, or attacks that exploit the inconsistent-R ambiguity described above. The '100% accuracy' is to be expected because the test was set up to reject these specific attempts. The paper should compare against a baseline (e.g., standard PBFT or a prior framework), test more diverse Byzantine behaviors, and discuss why these scenarios are representative enough to support the general claim of Byzantine fault tolerance.","section":"Section VI-D, Table III"}],"minor_comments":[{"comment":"In the load equation, the terms cpuused/cputotal and memused/memtotal are used but cpuused and memused are not formally defined; the resource state R in Eq. (2) uses cn and mn, so the notation should be unified for consistency.","section":"Section III-B2, Eq. (11)"},{"comment":"The Perception Layer's 'zero-process baseline' is described as a design principle, but the manuscript does not explain how IoT nodes can initiate requests or receive responses when no processes are running; the Transaction Initiator and Response Manager are described as libraries, yet the operational flow is unclear.","section":"Section III-C"},{"comment":"The scalability analysis in Section VI-C claims 'efficient consensus operation at scale' based on a 4-to-16-node range, while Section VIII-C correctly cautions that PBFT has O(n^2) complexity and larger deployments would show quadratic behavior. The main text should present the scaling claim with the same caveat to avoid overstatement.","section":"Section VI-C and VIII-C"},{"comment":"The fault tolerance analysis states the protocol 'inherits Byzantine fault tolerance from PBFT', but it should clarify which properties are inherited exactly, since the schedule proposal p is not a deterministic transaction and the validation rules V in Eq. (5) are evaluated by nodes on a non-deterministic output; the inheritance argument is not automatic.","section":"Section IV-C"},{"comment":"The qualitative comparison marks TrustMesh as fully supporting all listed features, including 'Complete Decentralized Control', yet Section III-A admits control nodes introduce some centralization. The table's checkmarks should be reconciled with the text's caveats or the criteria should be defined more precisely.","section":"Table I"}],"recommendation":"major_revision","confidential_remarks":"The central idea is timely and the experimental work is genuine, but the designation-phase gap is a load-bearing flaw in the claimed contribution. I believe the issue is fixable in principle by integrating resource-state updates into the PBFT-ordered ledger or by using PBFT to agree on the designated node, so I recommend major revision rather than rejection. The authors should also be encouraged to replace the term 'formal verification' with 'correctness argument' unless they provide a machine-checked or fully formal model."},"author_rebuttal":null,"desk_editor":{"model":"deepseek-v4-flash","letter":"Short version: this is a plausible systems paper with a real, modest idea—let one designated node run any scheduler, then have the network validate the result against static rules and commit it via PBFT—and it includes actual code and a real testbed. The idea is not present in the cited prior frameworks, and the implementation looks serious. But the designation phase that makes the whole safety argument work has a mechanism gap, and the paper calls informal prose proofs \"formal verification.\"\n\nWhat's good: the three-phase protocol is a natural extension of PBFT, and the paper is honest that it's an extension. The implementation is concrete: Sawtooth, Kubernetes, Redis, CouchDB, ZeroMQ, and a released Zenodo artifact. The evaluation, while small, is internally consistent: measured RRT, framework overhead, and two BFT attack scenarios with detection latencies under 150 ms. The threats-to-validity section is unusually candid, admitting no baseline comparison and limited attack coverage.\n\nWhere it falls down: the stress-test hits the real weak point. Safety Property 1 requires all nodes to compute the same designated node from Eq. (2), which depends on resource state R. But R is maintained in a sharded Redis cache with asynchronous batched updates and CouchDB multi-master—neither provides a globally consistent snapshot. The proof in Section IV-A says \"atomic operations for consistent views\" without specifying which operation gives all nodes the same R. If honest nodes see different snapshots, they can disagree on who is designated, and then PBFT never even runs on a coherent proposal set. Worse, if the designated node is Byzantine, it can propose any schedule that passes the static validation rules V, and the network will confirm it. The paper's central claim—that you can have non-deterministic scheduling with BFT—needs a mechanism for agreeing on R and for bounding what the designated node can inject. This is fixable, but it's not a nit.\n\nThe \"formal verification\" is informal prose; that's fine as a design argument, but it should not be labeled formal. The BFT evaluation is thin: two synthetic attacks, 16 nodes, no comparison with FogBus, CoopEdge, or any baseline. That was admitted, but it limits how much the paper can claim.\n\nWho benefits: systems people working on permissioned blockchain plus edge orchestration, and anyone designing consensus around non-deterministic proposers. It deserves peer review—there is enough original architecture and working code to justify a careful revision. My recommendation: send it to reviewers, but flag the designation mechanism as the central question.","headline":"A plausible, genuinely implemented framework for combining non-deterministic scheduling with PBFT-style validation, but the designation phase that carries the safety claim lacks a mechanism for global resource-state consistency.","tokens_in":12740,"tokens_out":2793,"would_cite":false,"duration_ms":28157,"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":"TrustMesh claims that a permissioned blockchain can run non-deterministic scheduling algorithms without losing Byzantine fault tolerance, by splitting scheduling into designation, generation, and PBFT-confirmed validation.","keywords":["TrustMesh","Internet of Things","permissioned blockchain","Practical Byzantine Fault Tolerance","non-deterministic scheduling","edge computing","distributed consensus","cold chain monitoring"],"falsifier":"Run the framework with two honest nodes given deliberately different resource snapshots for the same schedule request and check whether they designate different proposers; if they do, the same request can produce two Active schedules, violating Agreement and Validity. A simpler check is to inject a divergent cache update and observe whether conflicting proposals pass validation.","tokens_in":1460,"feed_emoji":"🔗","tokens_out":2525,"duration_ms":75426,"temperature":0.7,"pith_summary":"The paper proposes TrustMesh, a three-layer framework for untrusted, heterogeneous IoT computing in which scheduling decisions are recorded on a permissioned blockchain. Its central claim is that non-deterministic scheduling algorithms, including heuristics, genetic algorithms, and machine learning, can be used without giving up Byzantine fault tolerance, a combination usually taken to be impossible because blockchain consensus requires deterministic proposals. TrustMesh achieves this with a multi-phase protocol: a deterministic function designates one node to generate the schedule, that node runs any algorithm it likes, and then PBFT consensus validates the result against a configurable rule set before it is committed. If true, this lets open IoT networks keep an auditable, tamper-evident ledger while choosing schedules by flexible, smart algorithms. The evaluation on a 21-node cold-chain testbed reports fault detection under 150 ms and roughly constant framework overhead as nodes scale from 4 to 16.","feed_headline":"Blockchains can now agree on non-deterministic schedules","feed_subtitle":"Three-phase protocol keeps Byzantine fault tolerance while allowing heuristics and machine-learning schedulers.","key_machinery":"The multi-phase PBFT commit protocol is the load-bearing mechanism. Its three phases are the Request and Designation phase ($\\phi_1$), where the deterministic function $f(N,R) = \\max_{n \\in N}(w_c c_n + w_m m_n)$ picks the designated node $n_d$; the Generation phase ($\\phi_2$), where $n_d$ runs any scheduling algorithm $A: S \\to P$; and the Confirmation phase ($\\phi_3$), where PBFT consensus validates the proposal $p$ against a rule set $V$ and commits it under the request identifier $id_r$. The protocol separates who may propose, what is acceptable, and how the proposal is computed, which is the step that lets nondeterminism coexist with Byzantine fault tolerance.","core_discovery":"On its own terms, the paper's central discovery is that the apparent conflict between Byzantine fault tolerance and non-deterministic scheduling is an artifact of demanding both from the same step. TrustMesh splits scheduling into three phases. In Phase 1 every node applies the same deterministic resource-weighting function $f(N,R)$ to agree on a designated node $n_d$. In Phase 2 that node runs any scheduling algorithm $A$ and produces a proposal $p$. In Phase 3 the network runs PBFT over $p$, but instead of requiring $p$ to match some precomputed deterministic output, it checks $p$ against a set of validation rules $V$ and the identity of the proposer. Since designation and validation are deterministic and consensus only confirms a proposal satisfying publicly checkable predicates, the ledger records schedules produced by arbitrary algorithms without sacrificing agreement or validity.","pith_inferences":["The safety guarantee depends on every honest node computing the same $f(N,R)$; because resource state is updated asynchronously in this design, a production deployment would need a synchronizing mechanism or deterministic snapshot for the proof to hold.","The same designate-generate-confirm pattern could be applied to other non-deterministic decisions in permissioned blockchains, such as model updates, placement choices, or dynamic pricing, whenever a deterministic designation rule and public validation predicates can be written.","A natural test is to compare TrustMesh against a standard PBFT chain running the same scheduling algorithm in deterministic form; the difference in round-trip time would quantify the cost of admitting nondeterminism.","If resource-state consistency cannot be guaranteed, the protocol's guarantees degrade, because honest nodes might disagree on who is allowed to propose even before PBFT runs."],"forward_implications":["Scheduling policies become pluggable: an operator can swap heuristics, genetic algorithms, or machine-learning policies without changing the consensus layer or losing Byzantine fault tolerance.","The blockchain becomes an audit trail for scheduling: every accepted or rejected schedule is committed, so violations of vendor, geographic, resource, or security constraints can be checked afterward.","With $n \\geq 3f+1$, up to one-third of compute nodes can behave maliciously; the 16-node experiment with five malicious nodes detected both tested attack scenarios with 100% accuracy and zero false positives.","Fault recovery is bounded: after a malicious proposal is rejected, a new schedule is generated in about 5 seconds, and detection latency stays below 150 ms.","Framework overhead is governed by consensus rather than application complexity, so increasing compute nodes from 4 to 16 raised round-trip time by only about 8.3%."],"supporting_citations":[{"why":"Supplies the Practical Byzantine Fault Tolerance protocol whose determinism constraint the multi-phase protocol is designed to relax.","marker":"[11]"},{"why":"Establishes the FogBus baseline blockchain fog framework that TrustMesh extends and whose partial centralization motivates the design.","marker":"[3]"},{"why":"Provides the CoopEdge permissioned-blockchain cooperative edge platform as the main comparison point for decentralized control.","marker":"[4]"},{"why":"Shows HIDRA as a practical blockchain deployment on resource-constrained devices, the implementation standard TrustMesh's testbed aims to advance.","marker":"[8]"},{"why":"Provides the Sawtooth performance benchmark, 500-2000 TPS with 0.5-5 second latency, that justifies the permissioned blockchain platform used in the implementation.","marker":"[13]"}],"fun_headline_variants":["Three-phase PBFT separates scheduling from consensus for safety","TrustMesh lets IoT blockchains use AI schedulers safely","Non-deterministic schedules now Byzantine fault tolerant","Scheduling flexibility and Byzantine safety, no longer a trade-off","Blockchain consensus that verifies any scheduler's proposals"],"cache_read_input_tokens":14976,"weakest_assumption_plain":"The whole construction leans on every honest node seeing the same resource state $R$ when the designation function runs; the paper assumes atomic operations give that consistent view, but does not specify how asynchronously refreshed resource data is kept globally consistent.","fun_headline_variants_meta":{"raw":{"variants":["Three-phase PBFT separates scheduling from consensus for safety","TrustMesh lets IoT blockchains use AI schedulers safely","Non-deterministic schedules now Byzantine fault tolerant","Scheduling flexibility and Byzantine safety, no longer a trade-off","Blockchain consensus that verifies any scheduler's proposals"]},"model":"deepseek-v4-flash","effort":"low","cost_usd":0.000371,"raw_usage":{"total_tokens":1963,"prompt_tokens":900,"completion_tokens":1063,"prompt_tokens_details":{"cached_tokens":384},"prompt_cache_hit_tokens":384,"prompt_cache_miss_tokens":516,"completion_tokens_details":{"reasoning_tokens":985}},"tokens_in":516,"tokens_out":1063,"duration_ms":23890,"temperature":1.0,"reasoning_tokens":985,"cache_read_input_tokens":384,"cache_creation_input_tokens":0},"cache_creation_input_tokens":0},"created_at":"2026-08-12T16:53:54.314001+00:00","model_set":{"reader":"deepseek-v4-flash"},"falsifier":"Run the framework with two honest nodes given deliberately different resource snapshots for the same schedule request and check whether they designate different proposers; if they do, the same request can produce two Active schedules, violating Agreement and Validity. A simpler check is to inject a divergent cache update and observe whether conflicting proposals pass validation.","supporting_citations":[{"cited_title":"Practical Byzantine Fault Tolerance,","cited_arxiv_id":null,"evidence_quote":"Supplies the Practical Byzantine Fault Tolerance protocol whose determinism constraint the multi-phase protocol is designed to relax."},{"cited_title":"FogBus: A Blockchain- based Lightweight Framework for Edge and Fog Computing,","cited_arxiv_id":null,"evidence_quote":"Establishes the FogBus baseline blockchain fog framework that TrustMesh extends and whose partial centralization motivates the design."},{"cited_title":"HIDRA: A Distributed Blockchain-Based Architecture for Fog/Edge Computing Environments,","cited_arxiv_id":null,"evidence_quote":"Shows HIDRA as a practical blockchain deployment on resource-constrained devices, the implementation standard TrustMesh's testbed aims to advance."},{"cited_title":"Performance Evaluation on Blockchain Systems: A Case Study on Ethereum, Fabric, Sawtooth and Fisco-Bcos,","cited_arxiv_id":null,"evidence_quote":"Provides the Sawtooth performance benchmark, 500-2000 TPS with 0.5-5 second latency, that justifies the permissioned blockchain platform used in the implementation."}],"review_version":1}