{"id":"db9b134c-7bfc-44db-9ca0-c3842e2eeebd","arxiv_id":"2412.12723","paper_version":1,"verdict":"REJECT","confidence":"MODERATE","novelty_score":5.0,"correctness_risk":"high","formal_verification":"none","parameter_count":1,"one_line_summary":"AsyncSC is an asynchronous sidechain that uses committee-produced delayed aggregate signatures to prove cross-chain IoT data transfers are valid without requiring synchronous network links.","lead":"This paper proposes AsyncSC, a way for independent blockchain networks to exchange IoT data even when the networks cannot stay in constant contact. It uses a new kind of delayed digital signature as proof that transactions are safely locked before being processed elsewhere.","discovery_kind":"new_method","skeptic_critique":{"model":"deepseek-v4-flash","headline":"Theorem 1's C1 case is internally inconsistent: once CTxsend is in LMC, retransmitting it cannot produce the claimed final state, so the proof does not establish correctness.","rationale":"The reader correctly identifies that the DAS construction, security definition, and proof are deferred to an unpublished full version, which alone prevents acceptance of the central security claim. My independent check finds a further, more elementary defect that would survive even a perfect DAS: the C1 case of Theorem 1's correctness proof asserts that retransmission can remove an already-recorded CTxsend from the append-only ledger LMC. That contradicts persistence. The two failure modes are related in that both undermine the security theorem, but they are not the same concern, so agreement is only partial. Since the reader's verdict is already REJECT and my concern strengthens that conclusion without changing it, the appropriate final verdict remains unchanged: the submission cannot be accepted as a proof of secure asynchronous cross-chain exchange.","tokens_in":16709,"tokens_out":6261,"duration_ms":65374,"concrete_test":"Model the C1 case as a minimal state-transition system: states track whether CTxsend is in LMC and whether CTxrecv is in LSC; actions include recording on MC, retransmitting the CTx message, and delivering/withholding the ACP. Check whether persistence (append-only LMC) and liveness of MC allow the proof's claimed transition from CTxsend ∈ LMC to CTxsend ∉ LMC after retransmission. The transition is not derivable; if a formal derivation of Theorem 1 is attempted under the stated assumptions, the C1 branch should fail, confirming that the proof needs an additional cross-chain delivery assumption.","verdict_should_be":"UNCHANGED","load_bearing_attack":"The central claim is that AsyncSC is secure whenever MC and SC satisfy persistence and liveness. Theorem 1's proof of the correctness property fails in case C1: CTxsend ∈ LMC ∧ CTxrecv ∉ LSC. The proof says that if the adversary delays or denies the ACP, MC retransmits timed-out CTxs, so the final state will be CTxsend ∉ LMC ∧ CTxrecv ∉ LSC. This is impossible in the model the paper itself defines. In the workflow of Section III-A and Figure 4, CTxsend is recorded on MC before the committee signs and before the leader runs DASig. Ledgers are append-only under persistence, so retransmitting the CTx message to SC cannot remove CTxsend from LMC. If the retransmission eventually succeeds, the final state is CTxsend ∈ LMC ∧ CTxrecv ∈ LSC, not both absent. If the ACP never reaches SC, C1 persists. The proof then appeals to honest-majority committees and DAS security, but those arguments are irrelevant to this delivery-failure case. Liveness of MC only guarantees eventual inclusion in LMC; it does not guarantee delivery of an ACP to SC. Therefore Theorem 1 does not prove correctness even if DAS were a perfect, fully specified primitive. This is a separate and more elementary barrier than the deferred DAS construction, and it leaves the paper's central security claim unsupported by the submitted argument.","agreement_with_reader":"partial"},"referee_report":{"model":"deepseek-v4-flash","summary":"The paper proposes AsyncSC, an asynchronous sidechain construction for multi-domain IoT data exchange between permissioned blockchains. The system uses an elected committee that provides Cross-Blockchain as a Service (C-BaaS): the committee signs a batch of cross-chain transactions (CTxSet) per epoch, and the leader generates a delayed aggregate signature (DAS), an asynchronous cross-chain proof (ACP), that commits to the CTxSet after a controlled delay. The paper argues that this delay allows the source chain to stabilize the transactions before the target chain processes them, removing the need for continuous synchronous monitoring. A multilevel buffer pool is introduced to preserve transaction ordering across asynchronous deliveries. The security section states Theorem 1, claiming that AsyncSC is secure whenever the mainchain and sidechain satisfy persistence and liveness. The evaluation implements a prototype on Hyperledger Fabric and ChainMaker, uses the TON_IoT dataset, and reports improved throughput, latency, and success ratio over several baselines, including Strawman, Ge-Co, ChainMaker, WeCross, and BitXHub.","tokens_in":16994,"tokens_out":6072,"duration_ms":57445,"significance":"If the claims were fully established, AsyncSC would address a real need: asynchronous, batch cross-chain data exchange for resource-constrained IoT deployments, with constant-size proofs and reduced monitoring overhead. The evaluation is concrete and unusually thorough for a systems paper, using a real IoT dataset, multiple baselines, and a running prototype; this is a genuine strength. However, the central security guarantee is not established in the submitted manuscript. The security proof of Theorem 1 contains an elementary correctness flaw in the handling of adversarial message delay, and the entire construction depends on a delayed aggregate signature primitive whose construction, security definition, and proof are deferred to an unpublished companion 'full version.' These are load-bearing issues that affect the paper's main claim, not presentation details. I therefore cannot recommend acceptance in the current form.","major_comments":[{"comment":"The proof of Theorem 1 is internally inconsistent in case C1 (CTxsend ∈ LMC ∧ CTxrecv ∉ LSC). The paper claims that if the adversary delays or denies the ACP, 'MC will retransmit CTxs that exceed the threshold ∆async, so the final state will be CTxsend ∉ LMC ∧ CTxrecv ∉ LSC.' This contradicts the protocol workflow of Section III-A, where CTxsend is recorded on MC in step ➊ before the committee signs (step ➋) and before the leader runs DASig (step ➌), and it contradicts the persistence property assumed in the theorem statement: ledgers are append-only, so retransmitting a CTx message cannot remove CTxsend from LMC. If retransmission eventually succeeds, the final state is CTxsend ∈ LMC ∧ CTxrecv ∈ LSC. If the ACP is denied forever, the final state is CTxsend ∈ LMC ∧ CTxrecv ∉ LSC, which is precisely the unilateral-recording violation forbidden by Definition 2. Liveness of MC only guarantees eventual inclusion in LMC; it does not guarantee delivery of an ACP to SC. The assumption in Section III-C that the probability of ∆ = ∞ is negligible is not formalized as a bounded adversarial delivery delay, and the appeals to committee honesty and DAS security are irrelevant to this delivery-failure case. The proof therefore does not establish correctness even if DAS were a fully specified, secure primitive.","section":"Section VI, Theorem 1 proof, case C1"},{"comment":"The paper defines the syntax of DAS in Definition 1 but explicitly states that 'the detailed construction of the DAS, along with its security definition and proof, can be found in the full version published online.' No such definition or proof is included in this submission. Theorem 1's argument for case C2 and for the stability property relies directly on the security of DAS, citing the collision-resistant hash function, the soundness and correctness of the IVC scheme [28], and the multi-signature scheme [37]. None of these is instantiated or proved for the composed DAS primitive in this manuscript. A reference to an unpublished companion version is not a substitute for a precise DAS security model (e.g., unforgeability, delay-soundness) and a proof relative to that model. This is load-bearing: if DAS is flawed or unrealizable, the central security claim of AsyncSC collapses.","section":"Section IV-B"},{"comment":"The correctness property in Definition 2 is not matched by the proof's state space. The definition says that 'if either does not match, both parties will abort' and that there is no case where CTxsend or CTxrecv is recorded in the ledger by only one party, but it does not define the abort action or its effect on LMC and LSC. In the proof's C1 case, the final state 'CTxsend ∉ LMC ∧ CTxrecv ∉ LSC' is not a state defined by the correctness property, and the protocol description in Fig. 4 has no rollback step that would remove an already-confirmed CTxsend from LMC. Moreover, the stability argument in the same proof assumes that 'the leader of MC generates the ACP and sends it to SC' and concludes CTxrecv ∈ LSC, while the C1 argument explicitly considers an adversary that delays or denies the ACP. The proof thus leaves the liveness guarantee of AsyncSC dependent on unstated assumptions about message delivery. The security definition and proof need to be reformulated with explicit ledger states for abort and with a precise adversarial delivery model before Theorem 1 can be evaluated.","section":"Section VI / Definition 2"}],"minor_comments":[{"comment":"Please make the full version of the DAS construction publicly accessible and provide a URL in the submission; the current sentence does not allow a reader to verify the referenced material.","section":"Section IV-B"},{"comment":"The notation TLastCTx is ambiguous: the text says 'the last CTx on-chain in this epoch is of length TLastCTx from the last time slot of the epoch,' and the formula δ = TStab − TLastCTx − TSig is not stated with explicit time units. Please clarify whether TLastCTx is a duration, a block height, or a timestamp, and define all terms of the formula precisely.","section":"Section V-B"},{"comment":"The text says that AKCheck confirms 'that ACP A is indeed produced by the honest committee,' but AKCheck only recomputes and checks the aggregate public key from the public key set. It does not by itself establish that the signers are honest or that the committee election was correct; please re-word to avoid overstating what this check guarantees.","section":"Section IV-C and Fig. 5"},{"comment":"In the row 'Comp. cost,' the entry O(|SC|/n) should be identified as the per-transaction amortized aggregation cost; as printed, it could be misread as the total cost of generating one ACP.","section":"Table III"},{"comment":"The prototype code availability statement says 'will be made public soon'; if the authors wish reproducibility to be assessed, a link or an archival release should be provided in the submission.","section":"Section VII-A"}],"recommendation":"reject","confidential_remarks":"The skeptical concern in the reader's report is confirmed by direct reading of the manuscript: Theorem 1's C1 case is not merely under-proved but inconsistent with the append-only ledger model, and the DAS construction is entirely deferred to an unpublished full version. These are not fixable with local edits; they require a substantially revised security model and a complete specification of the core primitive. I would not rule out future resubmission: the system concept and the experimental evaluation are promising, and the authors could provide a complete DAS construction and a corrected proof. But as submitted, the central security claim is unsupported."},"author_rebuttal":null,"desk_editor":{"model":"deepseek-v4-flash","letter":"Quick take: the paper tackles a real problem—cross-chain IoT data exchange without synchronous connectivity—and the high-level design is coherent. The committee-based C-BaaS, the buffered transaction pool, and the idea of batch-committing transactions via a delayed aggregate signature are all sensible. The prototype work is genuine: they built on Fabric and ChainMaker, used the ToN_IoT dataset, and report concrete throughput and latency gains against several baselines. Credit where due: the feature comparison, the proof-size analysis, and the buffer-pool parameter evaluation are useful contributions.\n\nThe soft spots are serious, not minor. First, the central primitive DAS is only sketched. The paper explicitly defers the construction, security definition, and proof to an unpublished 'full version' (Section IV-B). Theorem 1 then reduces AsyncSC security to DAS security. That is a load-bearing gap: the submission never establishes that DAS exists with the required properties.\n\nSecond, the proof of Theorem 1 has an internal inconsistency in case C1. The proof says that if the adversary delays or denies the ACP, MC retransmits timed-out CTxs and 'the final state will be CTxsend not in LMC and CTxrecv not in LSC.' But in the workflow, CTxsend is recorded on MC before the ACP is generated. Ledgers are append-only under persistence. Retransmitting cannot remove CTxsend from LMC. If the retransmission eventually succeeds, the final state is both recorded; if it never succeeds, C1 persists. So the proof does not establish correctness. This is a more elementary barrier than the missing DAS, and it leaves the central security claim unsupported.\n\nPerformance claims are plausible but only partly verifiable: code is promised, not shipped; there are no error bars; and the baselines include a custom Strawman but no other asynchronous cross-chain scheme. Those are minor compared with the proof issues.\n\nBottom line: this is a serious research idea with honest engineering behind it, but the submission does not prove what it claims. A careful referee could help the authors fix the proof and provide the DAS details. The potential payoff justifies engaging with the work, but not accepting it as-is.","headline":"A serious async-sidechain idea with a real proof gap: DAS is deferred and Theorem 1's C1 case is internally inconsistent.","tokens_in":17559,"tokens_out":3967,"would_cite":false,"duration_ms":33672,"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":"The paper claims that a committee-generated delayed aggregate signature can commit a whole epoch of cross-chain transactions, letting sidechains operate asynchronously without synchronized clocks or continuous block monitoring.","keywords":["asynchronous sidechain","cross-chain data exchange","delayed aggregate signature","verifiable delay function","IoT data exchange","permissioned blockchain","transaction consistency","Cross-Blockchain as a Service"],"falsifier":"Run the prototype under a network where the source chain reorganizes after the ACP is generated but before the nominal delay $\\delta$ elapses; if the target chain accepts the ACP and records transactions that are later rolled back on the source chain, then the delay did not actually commit stabilization and stability fails. Alternatively, exhibit a valid-looking ACP that passes DASVer in less than $\\delta$ or for an altered transaction set, which would break the correctness argument.","tokens_in":16474,"feed_emoji":"🔗","tokens_out":12981,"duration_ms":101496,"temperature":0.7,"pith_summary":"AsyncSC claims that cross-chain data exchange between permissioned blockchains can be made asynchronous and efficient by replacing per-transaction synchronous proofs with epoch-level asynchronous cross-chain proofs (ACPs). The ACP is produced by a committee that signs a batch of cross-chain transactions and by a leader who runs a delayed aggregate signature (DAS), which combines aggregate signatures with a verifiable delay function: the controlled delay $\\delta$ is set so that by the time the proof is output, the transactions have stabilized on the source chain. This lets the source chain begin the next epoch without waiting for the target chain to confirm the previous one, and lets the target chain verify one compact proof for the whole batch. The paper's Theorem 1 claims that if the mainchain and sidechain each satisfy persistence and liveness, AsyncSC as a whole is secure. If correct, the scheme would give IoT domains in discontinuous networks a sidechain path with higher throughput, lower latency, and comparable overhead to current synchronous schemes.","feed_headline":"Async sidechain cuts cross-chain latency by up to 84 percent","feed_subtitle":"Delayed aggregate signatures batch whole epochs, so blockchains can sync whenever they reconnect","key_machinery":"The load-bearing object is the delayed aggregate signature (DAS), a primitive defined as a tuple (ParGen, KeyGen, Sig, Ver, KeyAgg, AKCheck, DASig, DASVer) that combines aggregate-signature compression with VDF-style delayed verifiability. DASig takes a message $M$, a public-key set, and individual committee signatures, and after a controlled delay outputs a compact aggregate signature $\\sigma_{\\mathrm{DAS}}$ plus a proof $\\pi_{\\mathrm{DAS}}$; DASVer lets anyone quickly check both the aggregated signatures and the delay. The paper points to a Gap Diffie-Hellman multisignature construction and an incremental-verifiable-computation VDF for realization, while deferring the full construction, security definition, and proof to an online full version. The delay $\\delta$ is the mechanism that replaces synchronous monitoring: it commits the stabilization of an epoch's transaction set on the source chain, and the multilevel buffer pool supplies ordering consistency between asynchronously arriving epochs.","core_discovery":"On its own terms, the paper's central claim is that a committee of blockchain maintainers can provide Cross-Blockchain as a Service (C-BaaS) by signing each epoch's packaged set of cross-chain transactions, and a leader can then run a delayed aggregate signature algorithm DASig that outputs one aggregate signature $\\sigma_{\\mathrm{DAS}}$, a delay proof $\\pi_{\\mathrm{DAS}}$, and a unique output $M'$. Because DASig performs a controlled number of sequential steps, the proof is available only after a delay $\\delta$; choosing $\\delta \\ge T_{\\mathrm{Stab}} - T_{\\mathrm{LastCTx}} - T_{\\mathrm{Sig}}$ ensures the last transaction of the epoch has stabilized on the source ledger by the time the ACP exists. The target chain verifies the ACP with DASVer and then performs a sequentiality check against a multilevel buffer pool before recording the transactions. The paper proves Theorem 1 by arguing that violating correctness requires either corrupting a majority of a committee, ruled out by the honest-majority assumption, or breaking DAS security, which it reduces to collision resistance of the underlying multisignature scheme and soundness and correctness of the IVC-based VDF. It then argues that persistence and liveness of the two chains imply stability, meaning valid cross-chain transactions are eventually recorded and stabilized on both ledgers.","pith_inferences":["An implication the authors leave implicit: the same delayed-aggregate-signature pattern should generalize to any chain with a predictable stabilization window, not only permissioned chains.","Because the delay is set as $\\delta = T_{\\mathrm{Stab}} - T_{\\mathrm{LastCTx}} - T_{\\mathrm{Sig}}$, the scheme treats stabilization time as a tunable parameter; a natural experiment is to map throughput and safety against $\\delta$ across different block intervals and committee sizes.","The restricted-readable buffer pool requires authenticated leader-to-leader messaging before sequencing can be checked; under severe partitioning that handshake, not the cryptographic proofs, may become the practical bottleneck."],"forward_implications":["One asynchronous cross-chain proof per epoch commits an entire batch of transactions, so proof size is $O(1)$ and per-transaction verification cost drops to $O(|SC|/n)$.","The source chain can begin the next epoch's transactions while the previous proof is still in transit, so transaction timing can overlap instead of being strictly sequential.","Batch commitment plus the absence of continuous block monitoring reduces resource usage: the evaluation reports 5.1% to 16.44% lower CPU utilization and 25.02% to 37.77% lower memory utilization than the compared schemes.","Under simulated asynchrony with 10% to 50% timeouts, the prototype reports 1.21× to 3.96× higher throughput, 59.76% to 83.61% lower latency, and 46.03% to 135.9% higher success ratio than the baselines."],"supporting_citations":[{"why":"Supplies the original aggregate-signature construction whose signature-compression property DAS borrows.","marker":"[26]"},{"why":"Supplies the verifiable delay function and incremental-verifiable-computation machinery whose soundness and correctness the DAS security proof invokes.","marker":"[28]"},{"why":"Supplies the Gap Diffie-Hellman multisignature scheme whose collision resistance is cited as the basis for DAS security.","marker":"[37]"},{"why":"Provides the cross-chain correctness and atomicity definitions AsyncSC adopts in its security definition.","marker":"[40]"},{"why":"Provides the blockchain persistence and liveness properties that Theorem 1 assumes of the mainchain and sidechain.","marker":"[41]"}],"fun_headline_variants":["Async sidechain trims IoT cross-chain latency by 84%","Delayed aggregate signatures enable async sidechain sync","AsyncSC speeds IoT data exchange with delayed proofs","Asynchronous sidechain lifts IoT throughput up to 4x","Sidechain async design cuts latency 60-84% for IoT"],"cache_read_input_tokens":3200,"weakest_assumption_plain":"The whole security argument assumes that a secure and efficient delayed aggregate signature scheme exists, while the paper defers the DAS construction, security definition, and proof to an unpublished full version.","fun_headline_variants_meta":{"raw":{"variants":["Async sidechain trims IoT cross-chain latency by 84%","Delayed aggregate signatures enable async sidechain sync","AsyncSC speeds IoT data exchange with delayed proofs","Asynchronous sidechain lifts IoT throughput up to 4x","Sidechain async design cuts latency 60-84% for IoT"]},"model":"deepseek-v4-flash","effort":"low","cost_usd":0.00047,"raw_usage":{"total_tokens":2399,"prompt_tokens":1064,"completion_tokens":1335,"prompt_tokens_details":{"cached_tokens":384},"prompt_cache_hit_tokens":384,"prompt_cache_miss_tokens":680,"completion_tokens_details":{"reasoning_tokens":1253}},"tokens_in":680,"tokens_out":1335,"duration_ms":9649,"temperature":1.0,"reasoning_tokens":1253,"cache_read_input_tokens":384,"cache_creation_input_tokens":0},"cache_creation_input_tokens":0},"created_at":"2026-08-11T13:48:05.960096+00:00","model_set":{"reader":"deepseek-v4-flash"},"falsifier":"Run the prototype under a network where the source chain reorganizes after the ACP is generated but before the nominal delay $\\delta$ elapses; if the target chain accepts the ACP and records transactions that are later rolled back on the source chain, then the delay did not actually commit stabilization and stability fails. Alternatively, exhibit a valid-looking ACP that passes DASVer in less than $\\delta$ or for an altered transaction set, which would break the correctness argument.","supporting_citations":[{"cited_title":"Short signatures from the weil pairing,","cited_arxiv_id":null,"evidence_quote":"Supplies the original aggregate-signature construction whose signature-compression property DAS borrows."},{"cited_title":"Verifiable delay functions,","cited_arxiv_id":null,"evidence_quote":"Supplies the verifiable delay function and incremental-verifiable-computation machinery whose soundness and correctness the DAS security proof invokes."},{"cited_title":"Efficient threshold signatures, multisignature and blind signature schemes based on the gap-diffie-hellman-group signature scheme,","cited_arxiv_id":null,"evidence_quote":"Supplies the Gap Diffie-Hellman multisignature scheme whose collision resistance is cited as the basis for DAS security."},{"cited_title":"Sok: Communication across distributed ledgers,","cited_arxiv_id":null,"evidence_quote":"Provides the cross-chain correctness and atomicity definitions AsyncSC adopts in its security definition."},{"cited_title":"The bitcoin backbone protocol: Analysis and applications,","cited_arxiv_id":null,"evidence_quote":"Provides the blockchain persistence and liveness properties that Theorem 1 assumes of the mainchain and sidechain."}],"review_version":1}