Pith. sign in

REVIEW 3 major objections 5 minor 1 cited by

AsyncSC: An Asynchronous Sidechain for Multi-Domain Data Exchange in Internet of Things

T0 review · 3 major / 5 minor · reviewed 2026-08-11 · deepseek-v4-flash

Challenge this review Re-run · record.json Download PDF Read on arXiv ↗ Review JSON

Pith's one-line read 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.

desk verdict A serious async-sidechain idea with a real proof gap: DAS is deferred and Theorem 1's C1 case is internally inconsistent. read the letter →

arxiv 2412.12723 v1 pith:QOOVIQZ4 submitted 2024-12-17 cs.CR cs.DC

Lingxiao Yang , Xuewen Dong , Zhiguo Wan , Sheng Gao , Wei Tong , Di Lu , Yulong Shen , Xiaojiang Du This is my paper · ORCID
classification cs.CRcs.DC
keywords asynchronoussidechaincross-chaindataexchangedelayedaggregatesignatureverifiabledelayfunctionIoTpermissionedblockchaintransactionconsistencyCross-BlockchainasaService
verification ladder T0 review T1 audit T2 compute T3 formal

The pith

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The reading

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.

What carries the argument

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.

What would settle it

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.

Watch

Extended reading notes

Core claim

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.

Load-bearing premise

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.

Editorial extensions

If this is right

  • 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.

Reading between the lines

Editorial extensions of the paper, not claims the author makes directly.

  • 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.
Share X Bluesky LinkedIn Reddit HN

Signed reviews

No signed human review yet.

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, and a circularity audit.

Referee Report

3 major / 5 minor

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.

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 (3)
  1. [Section VI, Theorem 1 proof, case C1] 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.
  2. [Section IV-B] 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.
  3. [Section VI / Definition 2] 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.
minor comments (5)
  1. [Section IV-B] 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.
  2. [Section V-B] 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.
  3. [Section IV-C and Fig. 5] 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.
  4. [Table III] 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.
  5. [Section VII-A] 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.

Circularity Check

1 steps flagged · score 6.0 of 10

Theorem 1's security proof is partly circular: the stability property it claims to establish is already assumed in Section III-C, so the central theorem reduces to its own input.

  1. self definitional [Section III-C (Assumptions); Section VI Definition 2 and Theorem 1 proof]
    "The CTxs of each epoch eventually complete their execution through the C-BaaS provided by the committee. If the verification of MC’s cross-chain proof passes, then SC will accurately complete the corresponding cross-domain data on-chain and stabilize it. ... Stability. If CTxsend is as expected, then eventually CTxsend will be recorded in LMC and CTxrecv will be recorded in LSC."

    Definition 2's Stability is the same eventual-recording-and-stabilization guarantee that Section III-C assumes for every epoch ('eventually complete their execution' and 'accurately complete ... and stabilize it'). The proof of Theorem 1's stability paragraph does not derive this from the DAS/buffer-pool mechanics; it restates the assumption as the conclusion ('valid CTxrecv will be recorded in LSC' after 'verifies successfully'). The correctness proof also assumes the same delivery/completion behavior in case C1, and even asserts the impossible final state 'CTxsend /∈ LMC ∧ CTxrecv /∈ LSC' after conceding 'CTxsend ∈ LMC'. Thus the theorem's central security claim is assumed as input rather than derived.

full rationale

The main derivation chain is self-contained in its construction details (committee C-BaaS, multilevel buffer pool, and evaluation), and the paper does not fit parameters to predict benchmark outcomes; the measured throughput/latency gains are empirical. However, the central security theorem is partially circular: Section III-C assumes that CTxs of each epoch eventually complete and that SC accurately records and stabilizes them when the ACP verifies, which is essentially Definition 2's Stability property that Theorem 1 claims to prove. The proof's stability paragraph simply invokes MC/SC liveness and successful ACP verification to conclude what was already assumed. Separately, the C1 case of the correctness proof is internally inconsistent: once CTxsend is in LMC, an append-only ledger cannot reach the claimed final state 'CTxsend /∈ LMC'; this is a proof-soundness flaw, not a circularity, so I flag it as a correctness risk but do not add it to the circularity score. I also flag Section IV-B's deferral of the DAS construction and security proof to the unpublished 'full version' as a missing-support limitation; since Theorem 1's C2 argument is conditional on DAS security, the submission is incomplete, but this is a completeness gap rather than a circular reduction. Because the load-bearing stability theorem reduces to its own assumption, the circularity score is 6 rather than 0-2.

Assumptions & free parameters 1 free parameters · 5 assumptions · 2 invented entities

The protocol's security rests on standard blockchain liveness/persistence, an honest-majority assumption, a partial-synchrony network assumption, and the existence of a secure DAS primitive. The DAS primitive is described only at a syntax level and its security is deferred to an unpublished companion paper. The delay parameter δ is a hand-chosen value that must exceed stabilization time for the security argument to hold.

free parameters (1)
  • DAS delay parameter t / delay δ = δ configured between 400 and 600 ms in experiments (Section VII-D)
    The delay is set using the formula δ = TStab - TLastCTx - TSig (Section V-B) and tuned in evaluation; the security argument requires δ to be large enough for CTxSet stabilization, so the claimed security depends on this hand-chosen parameter.
assumptions (5)
  • domain assumption Underlying blockchains MC and SC satisfy persistence and liveness.
    Invoked in Definition 2 and Theorem 1 (Section VI) to derive correctness and stability of AsyncSC.
  • domain assumption Majority of committee nodes and organization nodes are honest.
    State in Section III-C threat model; needed so committee signatures and ACPs are trustworthy.
  • domain assumption Probability of unbounded message delay (Δ = ∞) is negligible; retransmission after Δasync eventually delivers messages.
    Section III-C assumptions; converts the 'asynchronous' model into partial synchrony, which underlies the liveness argument.
  • ad hoc to paper DAS is a secure delayed aggregate signature scheme (EUF-CMA, VDF soundness, IVC/SNARK soundness).
    Section IV-B states the construction and proof are in a full version; Theorem 1 treats DAS as a black box with these properties.
  • domain assumption The committee election protocol is secure.
    Section III-A borrows election schemes from Refs. [17], [29]-[31]; the security proof relies on election integrity.
invented entities (2)
  • Delayed aggregate signature (DAS)
    purpose: Combines aggregate signatures with a VDF so a batch of committee signatures becomes a single proof delayed by a predetermined amount of time.
    No construction, formal security proof, or independent implementation is given in this preprint; the authors defer it to a full version.
  • Asynchronous cross-chain proof (ACP)
    purpose: The message that transfers a batch of IoT data across chains; contains the DAS commitment and is verified by the destination chain.
    ACP is defined only through DAS; its security properties inherit from the unverified DAS.

how reviews work

0 comments
Cite this review

Pith. "Pith review of AsyncSC: An Asynchronous Sidechain for Multi-Domain Data Exchange in Internet of Things." pith.science (2026). https://pith.science/paper/QOOVIQZ4

@misc{pith2026241212723,
  author       = {Pith},
  title        = {Pith review of: AsyncSC: An Asynchronous Sidechain for Multi-Domain Data Exchange in Internet of Things},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/QOOVIQZ4}},
  note         = {Machine review of arXiv:2412.12723}
}
read the original abstract

Sidechain techniques improve blockchain scalability and interoperability, providing decentralized exchange and cross-chain collaboration solutions for Internet of Things (IoT) data across various domains. However, current state-of-the-art (SOTA) schemes for IoT multi-domain data exchange are constrained by the need for synchronous networks, hindering efficient cross-chain interactions in discontinuous networks and leading to suboptimal data exchange. In this paper, we propose AsyncSC, a novel asynchronous sidechain construction. It employs a committee to provide Cross-Blockchain as a Service (C-BaaS) for data exchange in multi-domain IoT. To fulfill the need for asynchronous and efficient data exchange, we combine the ideas of aggregate signatures and verifiable delay functions to devise a novel cryptographic primitive called delayed aggregate signature (DAS), which constructs asynchronous cross-chain proofs (ACPs) that ensure the security of cross-chain interactions. To ensure the consistency of asynchronous transactions, we propose a multilevel buffered transaction pool that guarantees the transaction sequencing. We analyze and prove the security of AsyncSC, simulate an asynchronous communication environment, and conduct a comprehensive evaluation. The results show that AsyncSC outperforms SOTA schemes, improving throughput by an average of 1.21 to 3.96 times, reducing transaction latency by 59.76% to 83.61%, and maintaining comparable resource overhead.

Figures

Figures reproduced from arXiv: 2412.12723 by the authors.

Figure 1
Figure 1. Illustration for current sidechain-based cross-chain interactions. Wavy d [PITH_FULL_IMAGE:figures/full_fig_p001_1.png] view at source ↗
Figure 2
Figure 2. Illustration for asynchronous cross-chain interactions. [PITH_FULL_IMAGE:figures/full_fig_p003_2.png] view at source ↗
Figure 3
Figure 3. System model of AsyncSC. epoch, and generate ACPs by the leader. Additionally, the committee maintains a buffer pool to ensure the consistency of asynchronous CTxs. Leader. It is a node C L with the highest election value in the committee, i.e., C L ∈ S C and C L ← max.ElecVal({Ci}|m i=1). It is responsible for performing delayed signature aggregation of the CTx set CTxSet := {CTxi}|n i=1 for each epoch of the commi… view at source ↗
Figures from the paper (4 more)
Figure 5
Figure 5. Figure 5: Procedure of applying DAS to AsyncSC. In the figure, organization [PITH_FULL_IMAGE:figures/full_fig_p005_5.png]
Figure 6
Figure 6. Figure 6: Asynchronous transaction sequence guarantee mechanism. [PITH_FULL_IMAGE:figures/full_fig_p006_6.png]
Figure 7
Figure 7. Figure 7: Performance comparison of different baselines across various metrics. [PITH_FULL_IMAGE:figures/full_fig_p008_7.png]
Figure 8
Figure 8. Figure 8: Evaluating system throughput vs. ACP’s DAS delay. [PITH_FULL_IMAGE:figures/full_fig_p009_8.png]

Discussion (0). Continue with ORCID to comment.

Forward citations

Cited by 1 Pith paper

Reviewed papers in the Pith corpus that reference this work. Sorted by Pith novelty score. Full citation record

  1. Enhancing Blockchain Cross Chain Interoperability: A Comprehensive Survey

    cs.CR 2025-05 conditional novelty 3.0 of 10

    A systematic survey that organizes blockchain cross-chain interoperability techniques into a classification and compares them with industry practice, while identifying open challenges.

Reference graph

Works this paper leans on

43 extracted references · 40 canonical work pages · cited by 1 Pith paper

  1. [28]

    Verifiable delay functions,

    D. Boneh, J. Bonneau, B. Bünz, and B. Fisch, “Verifiable delay functions,” in Annual international cryptology conference . Springer, 2018, pp. 757–788

    work page 2018

  2. [37]

    Efficient threshold signatures, multisignature and blind signature schemes based on the gap-diffie-hellman-group signature scheme,

    A. Boldyreva, “Efficient threshold signatures, multisignature and blind signature schemes based on the gap-diffie-hellman-group signature scheme,” in PKC 2003, 2002, pp. 31–46

    work page 2003

  3. [1]

    Collaborative sensing in internet of things: A comprehensive survey,

    S. He, K. Shi, C. Liu, B. Guo, J. Chen, and Z. Shi, “Collaborative sensing in internet of things: A comprehensive survey,” IEEE Communications Surveys & Tutorials, vol. 24, no. 3, pp. 1435–1474, 2022

    work page 2022

  4. [2]

    A survey of mobile crowdsensing techniques: A critical component for the internet of things,

    J. Liu, H. Shen, H. S. Narman, W. Chung, and Z. Lin, “A survey of mobile crowdsensing techniques: A critical component for the internet of things,” ACM Transactions on Cyber-Physical Systems , vol. 2, no. 3, pp. 1–26, 2018

    work page 2018

  5. [3]

    Powering an inclusive, digital future for all

    Cisco. Powering an inclusive, digital future for all. [Online]. Available: https://newsroom.cisco.com/c/r/newsroom/en/us/a/ y2023/m01/powering-an-inclusive-digital-future-for-all.html

    work page

  6. [4]

    A survey on blockchain- based trust management for Internet of Things,

    Y . Liu, J. Wang, Z. Yan, Z. Wan, and R. Jäntti, “A survey on blockchain- based trust management for Internet of Things,” IEEE Internet of Things Journal, vol. 10, no. 7, pp. 5898–5922, 2023

    work page 2023

  7. [5]

    A blockchain-driven data exchange model in multi-domain iot with controllability and parallelity,

    W. Tong, X. Dong, Y . Shen, X. Jiang et al., “A blockchain-driven data exchange model in multi-domain iot with controllability and parallelity,” Future Generation Computer Systems , vol. 135, pp. 85–94, 2022

    work page 2022

  8. [6]

    TI-BIoV: Traffic information interaction for blockchain-based IoV with trust and incentive,

    W. Tong, X. Dong, Y . Zhang, Z. Zhang, L. Yang, W. Yang, and Y . Shen, “TI-BIoV: Traffic information interaction for blockchain-based IoV with trust and incentive,” IEEE Internet of Things Journal , 2023

    work page 2023

Show all 43 references
  1. [7]

    Consortium blockchains: Overview, applications and challenges,

    O. Dib, K.-L. Brousmiche, A. Durand, E. Thea, and E. B. Hamida, “Consortium blockchains: Overview, applications and challenges,” Int. J. Adv. Telecommun, vol. 11, no. 1, pp. 51–64, 2018

    2018

  2. [8]

    A consortium blockchain- based access control framework with dynamic orderer node selection for 5G-enabled industrial IoT,

    Y . Feng, W. Zhang, X. Luo, and B. Zhang, “A consortium blockchain- based access control framework with dynamic orderer node selection for 5G-enabled industrial IoT,” IEEE Transactions on Industrial Infor- matics, vol. 18, no. 4, pp. 2840–2848, 2021

    2021

  3. [9]

    On time-aware cross-blockchain data migration,

    M. Zhang, Q. Qu, L. Ning, and J. Fan, “On time-aware cross-blockchain data migration,” Tsinghua Science and Technology , vol. 29, no. 6, pp. 1810–1820, 2024

    2024

  4. [10]

    Enabling blockchain innovations with pegged sidechains,

    A. Back, M. Corallo, L. Dashjr, M. Friedenbach, G. Maxwell, A. Miller, A. Poelstra, J. Timón, and P. Wuille, “Enabling blockchain innovations with pegged sidechains,” vol. 72, 2014, pp. 201–224

    2014

  5. [11]

    Proof-of-work sidechains,

    A. Kiayias and D. Zindros, “Proof-of-work sidechains,” in Interna- tional Conference on Financial Cryptography and Data Security (FC) . Springer, 2019, pp. 21–34

    2019

  6. [12]

    Proof-of-stake sidechains,

    P. Gaži, A. Kiayias, and D. Zindros, “Proof-of-stake sidechains,” in 2019 IEEE Symposium on Security and Privacy (SP) , 2019, pp. 139–156

    2019

  7. [13]

    Sidechains with fast cross-chain transfers,

    L. Yin, J. Xu, and Q. Tang, “Sidechains with fast cross-chain transfers,” IEEE Transactions on Dependable and Secure Computing, vol. 19, no. 6, pp. 3925–3940, 2021

    2021

  8. [14]

    Cosmos whitepaper,

    J. Kwon and E. Buchman, “Cosmos whitepaper,” A Netw. Distrib. Ledgers, 2019

    2019

  9. [15]

    [Online]

    FISCO BCOS. [Online]. Available: http://www.fisco-bcos.org/

  10. [16]

    Bitxhub: side-relay chain based heteroge- neous blockchain interoperable platform,

    S. Ye, X. Wang, C. Xu et al., “Bitxhub: side-relay chain based heteroge- neous blockchain interoperable platform,” Comput Sci, vol. 47, no. 06, pp. 300–308, 2020

    2020

  11. [17]

    Sidechains with optimally suc- cinct proof,

    L. Yin, J. Xu, K. Liang, and Z. Zhang, “Sidechains with optimally suc- cinct proof,” IEEE Transactions on Dependable and Secure Computing , vol. 21, no. 4, pp. 3375–3389, 2024

    2024

  12. [18]

    Zendoo: A zk-snark veri- fiable cross-chain transfer protocol enabling decoupled and decentralized sidechains,

    A. Garoffolo, D. Kaidalov, and R. Oliynykov, “Zendoo: A zk-snark veri- fiable cross-chain transfer protocol enabling decoupled and decentralized sidechains,” in 2020 IEEE 40th International Conference on Distributed Computing Systems (ICDCS) . IEEE, 2020, pp. 1257–1262

    2020

  13. [19]

    zkbridge: Trustless cross-chain bridges made practical,

    T. Xie, J. Zhang, Z. Cheng, F. Zhang, Y . Zhang, Y . Jia, D. Boneh, and D. Song, “zkbridge: Trustless cross-chain bridges made practical,” in Proceedings of the 2022 ACM SIGSAC Conference on Computer and Communications Security, 2022, pp. 3003–3017

    2022

  14. [20]

    Hyperledger fabric: a dis- tributed operating system for permissioned blockchains,

    E. Androulaki, A. Barger, V . Bortnikov, C. Cachin, K. Christidis, A. De Caro, D. Enyeart, C. Ferris et al. , “Hyperledger fabric: a dis- tributed operating system for permissioned blockchains,” in Proceedings of the thirteenth EuroSys conference , 2018, pp. 1–15

    2018

  15. [21]

    [Online]

    ChainMaker. [Online]. Available: https://chainmaker.org.cn/

  16. [22]

    Ouroboros praos: An adaptively-secure, semi-synchronous proof-of-stake blockchain,

    B. David, P. Gaži, A. Kiayias, and A. Russell, “Ouroboros praos: An adaptively-secure, semi-synchronous proof-of-stake blockchain,” in EU- ROCRYPT 2018: 37th Annual International Conference on the Theory and Applications of Cryptographic Techniques , 2018, pp. 66–98

    2018

  17. [23]

    Renovating blockchain with distributed databases: An open source system,

    M. Muzammal, Q. Qu, and B. Nasrulin, “Renovating blockchain with distributed databases: An open source system,” Future generation com- puter systems, vol. 90, pp. 105–117, 2019

    2019

  18. [24]

    Blockchain-based secure data storage protocol for sensors in the industrial internet of things,

    J. Lu, J. Shen, P. Vijayakumar, and B. B. Gupta, “Blockchain-based secure data storage protocol for sensors in the industrial internet of things,” IEEE Transactions on Industrial Informatics , vol. 18, no. 8, pp. 5422–5431, 2021

    2021

  19. [25]

    Fair cloud auditing based on blockchain for resource-constrained iot devices,

    L. Zhou, A. Fu, G. Yang, Y . Gao, S. Yu, and R. H. Deng, “Fair cloud auditing based on blockchain for resource-constrained iot devices,”IEEE Transactions on Dependable and Secure Computing , vol. 20, no. 5, pp. 4325–4342, 2023

    2023

  20. [26]

    Short signatures from the weil pairing,

    D. Boneh, B. Lynn, and H. Shacham, “Short signatures from the weil pairing,” in International conference on the theory and application of cryptology and information security . Springer, 2001, pp. 514–532

    2001

  21. [27]

    Practical aggregate signature from general elliptic curves, and applications to blockchain,

    Y . Zhao, “Practical aggregate signature from general elliptic curves, and applications to blockchain,” in ACM asia conference on computer and communications security, 2019, pp. 529–538

    2019

  22. [29]

    Scheduling most valuable committees for the sharded blockchain,

    H. Huang, X. Peng, Y . Lin, M. Xu, G. Ye, Z. Zheng, and S. Guo, “Scheduling most valuable committees for the sharded blockchain,” IEEE/ACM Transactions on Networking , vol. 31, pp. 3284–3299, 2023

    2023

  23. [30]

    Secret multiple leaders & committee election with application to sharding blockchain,

    M. Zhai, Q. Wu, Y . Liu, B. Qin, X. Dai, Q. Gao, and W. Susilo, “Secret multiple leaders & committee election with application to sharding blockchain,” IEEE Transactions on Information Forensics and Security , vol. 19, pp. 5060–5074, 2024

    2024

  24. [31]

    Approval-based committee voting in prac- tice: a case study of (over-) representation in the polkadot blockchain,

    N. Boehmer, M. Brill, A. Cevallos, J. Gehrlein, L. Sánchez-Fernández, and U. Schmidt-Kraepelin, “Approval-based committee voting in prac- tice: a case study of (over-) representation in the polkadot blockchain,” in Proceedings of the AAAI Conference on Artificial Intelligence,...

    2024

  25. [32]

    Practical byzantine fault tolerance,

    M. Castro, B. Liskov et al. , “Practical byzantine fault tolerance,” in OSDI, vol. 99, 1999, pp. 173–186

    1999

  26. [33]

    Aggregate and verifiably encrypted signatures from bilinear maps,

    D. Boneh, C. Gentry, B. Lynn, and H. Shacham, “Aggregate and verifiably encrypted signatures from bilinear maps,” in EUROCRYPT 2003: International Conference on the Theory and Applications of Cryptographic Techniques, 2003, pp. 416–432

    2003

  27. [34]

    Musig2: Simple two-round schnorr multi-signatures,

    J. Nick, T. Ruffing, and Y . Seurin, “Musig2: Simple two-round schnorr multi-signatures,” in Annual International Cryptology Confer- ence. Springer, 2021, pp. 189–221

    2021

  28. [35]

    Efficient verifiable delay functions,

    B. Wesolowski, “Efficient verifiable delay functions,” Journal of Cryp- tology, vol. 33, pp. 2113–2147, 2020

    2020

  29. [36]

    Continuous verifiable delay functions,

    N. Ephraim, C. Freitag, I. Komargodski, and R. Pass, “Continuous verifiable delay functions,” in EUROCRYPT 2020: 39th Annual Inter- national Conference on the Theory and Applications of Cryptographic Techniques, 2020, pp. 125–154

    2020

  30. [38]

    Version pool management in a multilevel secure multiversion transaction manager,

    A. Warner and T. F. Keefe, “Version pool management in a multilevel secure multiversion transaction manager,” in Proceedings 1995 IEEE Symposium on Security and Privacy , 1995, pp. 169–182

    1995

  31. [39]

    Tendermint: Byzantine fault tolerance in the age of blockchains,

    E. Buchman, “Tendermint: Byzantine fault tolerance in the age of blockchains,” Ph.D. dissertation, University of Guelph, 2016

    2016

  32. [40]

    Sok: Communication across distributed ledgers,

    A. Zamyatin, M. Al-Bassam, D. Zindros, E. Kokoris-Kogias, P. Moreno- Sanchez, A. Kiayias, and W. J. Knottenbelt, “Sok: Communication across distributed ledgers,” in International Conference on Financial Cryptography and Data Security (FC) . Springer, 2021, pp. 3–36

    2021

  33. [41]

    The bitcoin backbone protocol: Analysis and applications,

    J. A. Garay, A. Kiayias, and N. Leonardos, “The bitcoin backbone protocol: Analysis and applications,” Journal of the ACM , 2015

    2015

  34. [42]

    [Online]

    WeCross. [Online]. Available: https://github.com/WeBankBlockchain/ WeCross

  35. [43]

    ToN_IoT: The role of heterogeneity and the need for standardization of features and attack types in IoT network intrusion data sets,

    T. M. Booij, I. Chiscop, E. Meeuwissen, N. Moustafa et al., “ToN_IoT: The role of heterogeneity and the need for standardization of features and attack types in IoT network intrusion data sets,” IEEE Internet of Things Journal, vol. 9, no. 1, pp. 485–496, 2021

    2021

Pith tools

Reviewed August 11, 2026 · model on record in the stance chip above.