Pith. sign in

REVIEW 4 major objections 7 minor 1 cited by

SPID-Chain: Verifiable Polar-Coded State Validation for Cross-Chain DAG Settlement

T0 review · 4 major / 7 minor · reviewed 2026-08-10 · deepseek-v4-flash

Pith's one-line read SPID-Chain proposes a cross-chain settlement layer that uses Polar-coded validation and a weighted DAG to settle escrowed transfers without changing native consensus.

desk verdict A competent design-and-simulation paper whose abstract promises five analytical results the body never actually derives. read the letter →

arxiv 2501.11794 v2 pith:L4WYOOSU submitted 2025-01-21 cs.DC

classification cs.DC
keywords cross-chainsettlementblockchaininteroperabilityDAGledgerPolarcodescodeddistributedcomputingstragglermitigationweightedquorumIOTACoordicide
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

SPID-Chain is a proposed settlement layer for escrow-backed transfers across heterogeneous blockchains. Its thesis is that cross-chain settlement can be made verifiable without touching native consensus: source-chain finality creates an immutable reservation, and confirmation on a stake-weighted DAG of blocks decides when the destination credit becomes executable. To keep slow validation workers from delaying settlement, the design stores settlement state as Polar-coded fragments and reconstructs it from whichever workers respond first. The abstract claims exact analytic results—a recovery-time distribution, a verification-soundness bound, an exact weighted-quorum condition, and a cross-layer stability theorem—together with an end-to-end settlement guarantee, and the body develops the architecture, balance-checking rule, and simulations intended to support those claims.

What carries the argument

The load-bearing mechanism is the combination of a stake-weighted DAG with aggregated-weight (AW) confirmation and Polar-coded distributed computation. The AW of a block is the sum of the stake weights of the block's issuer and every block that directly or indirectly validates it; a proposed block becomes confirmed when its AW crosses $\eta$, which is the protocol's quorum rule. Parallel to that, the payment-validation computation is coded by expanding each chain's token-flow matrices, zeroing the rows assigned to the $\lambda n$ slowest workers, and applying a Hadamard transform; workers accumulate coded sums across epochs, and committee nodes decode the true inflow and outflow matrices from the first decodable subset of responses, which is what removes the straggler bottleneck. The paper also relies on the critical spamming rate $\mu_{\mathrm{crit}}=(K-1)/K$ as the threshold where the DAG's tip pool becomes unstable.

What would settle it

Inspect the full text for the promised theorems: if Sections 2 through 6 contain no statement of the exact recovery-time distribution, the verification-soundness bound, the weighted-quorum condition, or the stability theorem, then the analytic claims are not established. Separately, run the simulation with weighted-AW confirmation at $\eta=67\%$ and measure tip-pool size for $\mu$ just below and above $(K-1)/K$: the predicted transition should occur exactly at that threshold for the claim to hold.

Watch

Extended reading notes

Core claim

On the paper's own terms, the discovery is that coded validation and weighted-DAG confirmation can be coupled into a single settlement protocol with a stability transition. Each chain encodes its input, inflow, and outflow matrices with a Hadamard-based Polar code, workers maintain coded running sums, and committee nodes decode as soon as enough fast workers respond, so the slowest worker no longer sets the latency. A block is confirmed when its aggregated weight—the issuing chain's stake weight plus the weights of all blocks in its future cone—exceeds the threshold $\eta$. The critical spamming rate $\mu_{\mathrm{crit}}=(K-1)/K$, imported from the IOTA Coordicide analysis, is said to govern whether the tip pool stays small or explodes, and simulations show the predicted transition, with larger $K$ and coded validation improving finality time and decentralization under adversarial issuance. The paper further claims that this construction yields an end-to-end guarantee covering balance non-negativity, asset conservation, conflict exclusion, replay protection, coded-state consistency, and finite expected lock-to-release latency.

Load-bearing premise

The stability and security conclusions assume that the IOTA Coordicide tip-pool threshold $\mu_{\mathrm{crit}}=(K-1)/K$, derived for a different issuance and confirmation model, still governs SPID-Chain's stake-weighted DAG with aggregated-weight confirmation at $\eta=67\%$.

Editorial extensions

If this is right

  • If the design works as claimed, a source transfer can be reserved by source-chain finality while the destination credit waits only for DAG confirmation, so native consensus need not change.
  • Coded validation should keep throughput from collapsing as the straggler fraction grows, whereas uncoded validation is bounded by the slowest worker.
  • Raising $K$ raises the critical spamming rate $\mu_{\mathrm{crit}}=(K-1)/K$, so the protocol can trade more validation work for a larger stable region against adversarial issuance.
  • Larger $K$ and lower spamming rates should produce shorter inter-chain finality times and a more even distribution of confirmed blocks across chains.
  • The claimed end-to-end guarantee would mean a user's escrowed transfer is either settled with conserved balances and no double spends, or released within finite expected time under the stated liveness conditions.

Reading between the lines

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

  • The analytic results advertised in the abstract—exact recovery-time distribution, verification-soundness bound, exact weighted-quorum condition, and stability theorem—do not appear as theorems or proofs in Sections 2 through 6, so a reader should treat them as claims to be established rather than demonstrated results.
  • The stability transition shown in the simulations is evidence only to the extent that the Coordicide tip-pool model, designed for a particular issuance and confirmation process, carries over to SPID-Chain's stake-weighted AW confirmation at $\eta=67\%$.
  • A natural test that the paper leaves implicit is to measure the empirical tip-pool size at $\mu$ slightly below and above $(K-1)/K$ under weighted-AW confirmation, and to compare the finality-time distribution against the promised exact recovery-time distribution.
  • The Hadamard-based encoding described is a linear code over row-blocks; whether it displays polar-code error behavior at finite $n$ depends on the decoding algorithm, so the consistency claims at large block lengths rest on the cited coding-theoretic results.
Share X Bluesky LinkedIn Reddit HN

Editorial analysis

A structured set of objections, weighed in public.

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

Referee Report

4 major / 7 minor

Summary. The manuscript, posted as 'SPID-Chain: Verifiable Polar-Coded State Validation for Cross-Chain DAG Settlement' but carrying the in-text title 'SPID-Chain: A Smart Contract-Enabled, Polar-Coded Interoperable DAG Chain,' proposes a cross-chain settlement architecture in which each blockchain runs an event-driven smart-contract (EDSC) pipeline with a committee/worker node split and Polar-coded distributed computation, while the chains jointly maintain a weighted DAG ledger on which blocks are confirmed by aggregated weight. Section 4 develops balance-checking arithmetic (Eqs. (1)-(3)), a zero-padded Hadamard/Polar encoding (Eqs. (5)-(10)), and a six-contract stage protocol (Section 4.4); Section 5 reports prototype-assisted simulations of intra- and inter-consensus throughput, scalability, Gini-based decentralization, tip-pool growth and finality, and double-spend detection. The posted abstract advertises derivations of an exact recovery-time distribution, a Byzantine verification-soundness bound, an exact weighted-quorum condition, a cross-layer stability theorem, and an end-to-end settlement guarantee, but the body contains no theorem statements, proofs, or derivations beyond the bookkeeping equations and the imported threshold μcrit=(K-1)/K.

Significance. Were the advertised analytical results present, the contribution would be substantial: quantitative coupling of straggler-resilient coded verification to weighted-DAG confirmation stability, plus provable settlement invariants across heterogeneous chains without native-consensus changes. The manuscript's genuine strengths are the detailed architectural narrative (Sections 2-4), the coherent cumulative in/out-flow bookkeeping of Section 4.1 (Eq. (3) is a sensible per-account sufficiency check that avoids double-counting confirmed versus proposed spending), the explicit simulation stack and parameters (Substrate, GoShimmer, Rust bridge, libsodium VRF, BigQuery Ethereum data, 10-run averages), and the honest in-paper contribution list, which claims only architecture, mechanisms, and simulations. However, the analytical backbone advertised in the posted abstract is absent; the sole stability input (Section 5.1) is imported from IOTA Coordicide without adapting it to SPID-Chain's issuance and weighted-confirmation model; and the stability 'prediction' of Fig. 7 therefore cannot be confirmed by simulating a protocol that embeds that very threshold.

major comments (4)
  1. [Abstract; Sections 1-6] The posted abstract advertises five analytical deliverables — an exact recovery-time distribution, a Byzantine verification-soundness bound, an exact weighted-quorum condition, a cross-layer stability theorem, and an end-to-end settlement guarantee covering six properties — but the body contains no theorem statements, lemmas, or proofs, and no closed-form derivations other than the bookkeeping equations (1)-(3), the Hadamard transform (5)-(10), the Gini statistic (11), and the imported threshold of Section 5.1. The paper's own contribution list (Section 1.2) claims only architecture, mechanisms, and simulations, so the posted abstract misrepresents the manuscript. This is load-bearing because the advertised value proposition — a 'verifiable and analytically grounded settlement layer' with an 'end-to-end settlement guarantee' — is exactly what the body does not provide; terms in the posted abstract such as 'hidden linear verification checks,' 'source-chain finality establishes an immutable reservation,' and 'finite expected lock-to-release latency' have no counterpart in Sections 2-6. Either the missing analyses must be added or the abstract must be rewritten to describe a design-and-simulation paper.
  2. [Section 5.1; Fig. 7; Section 5.2.3] The stability prediction rests entirely on the imported threshold μcrit = (K-1)/K, stated as 'demonstrated in [57] for the IOTA-type DAG ledger.' No argument is given that the Coordicide tip-pool analysis transfers to SPID-Chain's model: one block per chain per epoch, K tips selected subject to at most one block per chain (Remark 3, Section 4.1), validation via coded checks, and confirmation by stake-weighted aggregated weight at η = 67%. Since an honest block validates a subset of its K selected tips and attaches only to the valid subset, the tip-removal rate per honest block is not obviously K, and the interaction between the AW confirmation rule and tip-pool dynamics is unexamined. The stress-test concern is therefore well-founded: without a derivation tailored to this weighted-AW DAG (or an explicit statement of the regime in which [57] applies), the 'predicted transition between stable and unstable DAG operation' and the Section 5.2.3 security discussion are assertions, not results; simulating the protocol that embeds the imported threshold cannot independently confirm it.
  3. [Section 4.2, Eqs. (5)-(10)] The straggler-resilience claim of Remark 5 is not supported by the decodability analysis that would be needed to derive the promised 'exact recovery-time distribution for heterogeneous coded workers.' In the zero-padded Hadamard construction, the data occupy the non-straggler row-blocks of  and the committee must recover them from the responses of exactly the n(1-λ) non-straggler workers; this requires the principal submatrix of the Hadamard transform on the non-straggler index set to be invertible. That condition is not guaranteed for arbitrary straggler sets: already for n = 4, taking the data at indices {2,3} yields dependent output rows for the H_4 transform, so decoding fails even though the number of responding workers equals the code rate. The paper cites [48,49] for the recursive decoding algorithm but supplies neither a rank condition nor a straggler model under which decoding succeeds with rate R = 1-λ. Consequently the recovery-time distribution advertised in the abstract cannot be derived from the text as it stands, and the throughput and latency benefits claimed in Sections 5.2.1-5.2.2 lack the theoretical grounding that the abstract promises.
  4. [Section 5.2.3; Section 4.4] The double-spend evaluation measures whether the protocol's own Stage-2 exclusion and Stage-3 labeling mechanism identifies the injected duplicate transactions, rather than whether settlement safety (the abstract's 'conflict exclusion') holds under an adversarial confirmation strategy. No adversary model is analyzed for the case where conflicting blocks race toward the confirmation threshold η, P_d and P_fa are reported for a single configuration without sensitivity analysis, and the conclusion that 'SPID-Chain effectively resisted the attacks' at μ = 55% > μcrit is an observation about the prototype, not a soundness statement. Combined with the absence of any formal definition of conflict exclusion, replay protection, or coded-state consistency in Sections 2-4, this leaves the security component of the advertised end-to-end guarantee without evidentiary or analytical support; the side event ledger D_j introduced in Section 4.4 is never used in an argument that connects recorded events to settlement safety.
minor comments (7)
  1. [Title/Abstract] The in-text title and abstract ('A Smart Contract-Enabled, Polar-Coded Interoperable DAG Chain') differ from the arXiv metadata title and abstract; the authors should ensure the posted abstract describes the same paper as the body.
  2. [Section 4.2.1; Section 5.1] Section 4.2.1 defines the straggler set S as the λn workers with the highest straggler probabilities, while Section 5.1 randomly selects stragglers per simulation run; since the zero-padding in Eq. (5) requires knowing S at encoding time, the encoder's information about the straggler set should be stated unambiguously.
  3. [References] References [52] and [53] are cited for Docker and GoShimmer nodes, respectively, but [52] points to 'Goshimmer Docker network tools' and [53] to 'Goshimmer Orphanage'; additionally, 'Susy [36]' in Section 1.1 should cite [37].
  4. [Throughout] Typos and spacing errors should be corrected, including 'Coded Verfication' (Section 4.2 heading), 'eventpublished' (Section 4.3.1), 'detailes' (Section 4.2.2), and 'Table. 1' and 'Table. 3'.
  5. [Section 5.1; Section 5.2.3] The simulation duration is inconsistent: Section 5.1 states each simulation runs for 5 minutes with 500 blocks at γ = 100 blocks/min, while Section 5.2.3 reports 12-minute runs and a 400-block test set; these numbers should be reconciled.
  6. [Section 5.2.1; Section 5.2.3] The confirmation threshold η = 67% is introduced in the results sections without justification or sensitivity analysis, and Section 5.2.1's definition of a processed block mixes intra-consensus ('blocks correctly generated') with inter-consensus (AW exceeding 67%) notions; the throughput metrics should be defined precisely.
  7. [Fig. 7] The panels in each row of Fig. 7 are not individually labeled; the caption should state which row corresponds to K = 2 and which to K = 4, and what the filled and open markers denote.

Circularity Check

0 steps flagged · score 0.0 of 10

No circular dependency found: the body contains design and simulation content rather than the advertised derivations, and the imported Coordicide threshold is not circularly derived from this paper's own inputs.

full rationale

The paper contains no circular step that can be exhibited from its own equations. The abstract advertises an exact recovery-time distribution, a verification-soundness bound, an exact weighted-quorum condition, a cross-layer stability theorem, and an end-to-end settlement guarantee, but Sections 2–6 contain no theorem statements or proofs of these results; this is an absence of the promised derivation, not a derivation equivalent to its inputs. The only quantitative stability input, μcrit=(K−1)/K in Section 5.1, is explicitly imported from the external Coordicide analysis [57] and then used to split the simulated spamming rates. Because the paper does not derive this threshold for SPID-Chain's weighted-AW DAG, the Fig. 7 “predicted transition” is an imported assumption tested in simulation rather than a self-made prediction, but importing an external result is not circularity under the stated criteria. No fitted parameter is relabeled as a prediction, no load-bearing self-citation chain is present, and no equation reduces to another by construction. The balance-check arithmetic (Eqs. 1–3), the Polar-coded update recursion (Eqs. 7–10), and the AW confirmation rule are defined directly from the proposed architecture, so their simulation is an implementation check rather than a circular reduction. I therefore find no significant circularity, while noting as a separate correctness concern that the central analytical claims are not actually proved in the body.

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

The central claims depend on imported results (Coordicide stability threshold [57], Polar-code computing machinery [48,49]) and on unmodeled trust assumptions (honest committee majority, known straggler set). The free parameters lambda, K, eta, and the stake weights shape every simulation conclusion, and none receive a sensitivity analysis. Invented entities are the side event ledger D_j and the abstract's undefined hidden linear verification checks. No derivation in the body justifies these choices.

free parameters (4)
  • lambda (straggler fraction) = 10% and 30% in simulations
    Sets the Polar code rate R=1-lambda; the design assumes the worst lambda*n workers are known in advance and never respond (Section 4.2.1, Section 5.1).
  • K (tip blocks validated per epoch) = 2 and 4
    Controls the critical spamming rate mu_crit=(K-1)/K, the load-bearing stability threshold in the simulations (Section 5.1).
  • eta (confirmation AW threshold) = 67%
    Hand-set threshold for the proposed-to-confirmed status transition; no sensitivity analysis is provided (Section 2.2.2, Section 5.1).
  • Stake weights omega_j = constant, proportional to stake
    Assumed constant over epochs, with burn-based adjustment for malicious behavior; the adjustment dynamics are stated but never modeled (Section 2.2.2).
assumptions (5)
  • domain assumption Tip-pool stability threshold mu_crit=(K-1)/K for IOTA-type DAGs applies to SPID-Chain's weighted multi-chain DAG.
    Section 5.1 defines the critical spamming rate as 'demonstrated in [57] for the IOTA-type DAG ledger'; the paper's headline transition and Fig. 7 depend on this import, with no derivation for SPID-Chain's weighted confirmation setting.
  • domain assumption Straggler model: the set S of stragglers is known in advance with |S|=lambda*n, stragglers never return results, and non-stragglers always return correct results on time.
    Section 4.2.1 forms S as the lambda*n highest-probability workers and assigns them zero blocks; Section 5.1 states stragglers never return results. Real straggler behavior is time-varying and unknown, which the design assumes away.
  • domain assumption Honest majority within each chain's committee validates events, and the majority vote determines contract triggering.
    Sections 3.2.2 and 4.4 rely on committee majority approval for event validity; no Byzantine fault model or bound is given in the body, despite the abstract's promised 'verification-soundness bound for Byzantine responses.'
  • standard math Polar-coded computing decodes W_in and W_out whenever the received worker set is decodable, per Algorithms 1 and 2 of [48].
    Section 4.2.2 delegates decoding to the cited algorithms; the code-rate choice R=1-lambda assumes this external result transfers to the matrix updates of Eqs. (7)-(10).
  • domain assumption Confirmation by AW threshold on the DAG is safe against conflicting (double-spend) blocks.
    Section 5.2.3's double-spend detection assumes that monitoring Z_T and labeling conflicts is sufficient; no safety proof ties AW confirmation to conflict exclusion in the body.
invented entities (2)
  • Hidden linear verification checks (abstract)
    purpose: Claimed mechanism for validating candidate state transitions
    The abstract advertises 'hidden linear verification checks,' but the body only describes coded computation of balance matrices; the hidden-check mechanism is never defined or analyzed.
  • Side event ledger D_j
    purpose: Records per-epoch event pools T_j as blocks D_j(t)
    Introduced in Section 4.4 as a new ledger entry; no independent evidence or analysis of its consistency or finality is given.

how reviews work

0 comments
Cite this review

Pith. "Pith review of SPID-Chain: Verifiable Polar-Coded State Validation for Cross-Chain DAG Settlement." pith.science (2026). https://pith.science/paper/L4WYOOSU

@misc{pith2026250111794,
  author       = {Pith},
  title        = {Pith review of: SPID-Chain: Verifiable Polar-Coded State Validation for Cross-Chain DAG Settlement},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/L4WYOOSU}},
  note         = {Machine review of arXiv:2501.11794}
}
read the original abstract

Cross-chain settlement must preserve safety across heterogeneous ledgers while tolerating delayed computation, Byzantine participants, and adversarial transaction issuance. This paper presents SPID-Chain, an adapter-compatible settlement architecture for escrow-backed fungible transfers across programmable blockchains. SPID-Chain maintains settlement state through persistent Polar-coded fragments, validates candidate state transitions using hidden linear verification checks, and records certified transfers in a weighted directed acyclic graph (DAG). The design separates native-chain finality from cross-chain settlement: source-chain finality establishes an immutable reservation, whereas weighted DAG confirmation determines when the corresponding destination credit becomes executable. We derive an exact recovery-time distribution for heterogeneous coded workers, a verification-soundness bound for Byzantine responses, and an exact weighted-quorum condition for conflicting-block safety. These components are coupled in a cross-layer stability theorem showing how the coded-validation completion probability determines the effective honest issuance rate and, consequently, the stable adversarial-load region of the settlement DAG. We further establish an end-to-end settlement guarantee covering balance non-negativity, asset conservation, conflict exclusion, replay protection, coded-state consistency, and finite expected lock-to-release latency under the stated liveness conditions. Prototype-assisted simulations indicate that coded validation reduces sensitivity to stragglers, improves validation and confirmation throughput under heterogeneous delays, and produces the predicted transition between stable and unstable DAG operation. The resulting framework provides a verifiable and analytically grounded settlement layer without modifying the native consensus protocol of participating chains.

Figures

Figures reproduced from arXiv: 2501.11794 by the authors.

Figure 1
Figure 1. Evolution of a DAG ledger over two consecutive epochs. Nodes are color-coded to indicate their status: [PITH_FULL_IMAGE:figures/full_fig_p007_1.png] view at source ↗
Figure 2
Figure 2. Intra-consensus throughput with 𝑁 = 10, 𝑛 = 100, and for varying straggler worker percentages 𝜆 and incoming block rates. Intra-consensus throughput: Intra-consensus throughput is defined as the average number of blocks processed by a scheme per minute. The intra-consensus throughput focuses on the processing speed and accuracy of blocks within each individual blockchain. To measure intra￾consensus throughput, we ca… view at source ↗
Figure 3
Figure 3. Intra-consensus scalability with 𝜆 = 10%, 12 blocks per minute for rate of incoming blocks, and for varying numbers of nodes within each blockchain and different numbers of blockchains 𝑁. Inter-consensus throughput: The inter-consensus throughput measures the rate at which blocks are processed on the DAG ledger. For evaluating the inter-consensus throughput, it is crucial to consider both the accuracy, which indicat… view at source ↗
Figures from the paper (5 more)
Figure 4
Figure 4. Figure 4: Inter-consensus throughput with 𝜆 = 10%, 𝑁 = 10, 𝐾 = 2, 𝜇crit = 50%, and for varying rates of incoming blocks and spamming rates. In contrast, without encoding, it takes longer to process blocks and attach them to the DAG, al￾lowing adversarial blockchains to attach th…
Figure 5
Figure 5. Figure 5: Inter-consensus scalability for varying numbers of blockchains [PITH_FULL_IMAGE:figures/full_fig_p023_5.png]
Figure 6
Figure 6. Figure 6: Network decentralization measured by Gini coefficient for different [PITH_FULL_IMAGE:figures/full_fig_p024_6.png]
Figure 7
Figure 7. Figure 7: Impact of varying spamming rate (𝜇) on DAG ledger health, demonstrated by tip pool size and inter￾chain block finality time. Simulation parameters: 𝑁 = 10 blockchains, 𝑛 = 100 worker nodes with 𝜆 = 10%, 𝜂 = 67%, 𝐾 = 2, 𝜇crit = 50% and 𝜇 ∈ {35%, 55%}, 𝐾 = 4, 𝜇crit = 75%…
Figure 8
Figure 8. Figure 8: Performance of SPID-Chain in detecting double-spend blocks with [PITH_FULL_IMAGE:figures/full_fig_p026_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. Secure Decentralized Federated Learning via Gossip and Virtual Voting

    cs.LG 2026-07 conditional novelty 6.0 of 10

    A gossip-native DAG consensus layer for decentralized federated learning certifies model-origin provenance via Hashgraph-style virtual voting, achieving learning quality comparable to blockchain-assisted FL with lower...

Reference graph

Works this paper leans on

58 extracted references · 44 canonical work pages · cited by 1 Pith paper

  1. [57]

    Dziubałtowska, D. 2022. The security of the Coordicide: The implementation and analysis of possible attack vectors. arXiv preprint arXiv:2205.12568

  2. [1]

    Liu, Z., Yan, Z., Yang, B., Shen, Y., Zhang, H., and Jia, W. 2022. Make Web3.0 connected.IEEE Transactions on Dependable and Secure Computing 19, 5 (Sept.–Oct. 2022), 2965–2981. DOI:https://doi.org/10.1109/TDSC.2021.3079315

  3. [2]

    Qin, R., Wu, Y., Li, X., Wang, G., Yu, J., Yu, H., and Tian, Y. 2023. Web3-based decentralized autonomous organizations and operations: Architectures, models, and mechanisms. IEEE Transactions on Systems, Man, and Cybernetics: Systems 53, 4 (April 2023), 2073–2082. DOI:https://doi.org/10.1109/TSMC.2022.3228530

  4. [3]

    Liu, Z., Chai, W., Wang, Z., Wu, H., Li, X., Li, X., Liang, K., Xu, Z., He, J., Yang, B., and Jia, W. 2019. Hy- perService: Interoperability and programmability across heterogeneous blockchains. In Proceedings of the 2019 ACM SIGSAC Conference on Computer and Communications Security (CCS ’19) . ACM, New York, NY, 549–566. DOI:https://doi.org/10.1145/33195...

  5. [4]

    Bernabé-Rodríguez, J., Garreta, A., and Lage, O. 2024. A Decentralized Private Data Marketplace using Blockchain and Secure Multi-Party Computation. ACM Transactions on Privacy and Security , 27, 2, Article 19, 29 pages. DOI:https://doi.org/10.1145/3652162

  6. [5]

    K., and Tripathy, S

    Mohanty, S. K., and Tripathy, S. 2024. Flexichain: Flexible Payment Channel Network to Defend Against Channel Exhaus- tion Attack. ACM Transactions on Privacy and Security , 27, 4, Article 30, 26 pages.DOI:https://doi.org/10.1145/3687476

  7. [6]

    Chen, C., Liu, Z., Zhou, Y., Cai, M., Xu, F., Hu, S., Liu, C., Guo, R., Lian, X., Zhou, H., Yang, Y., and Liu, Z. 2022. When digital economy meets Web3.0: Applications and challenges. IEEE Open Journal of the Computer Society 3 (2022), 233–245. DOI:https://doi.org/10.1109/OJCS.2022.3217565

  8. [7]

    Otoni, R., Marescotti, M., Alt, L., Eugster, P., Hyvärinen, A., and Sharygina, N. 2023. A Solicitous Ap- proach to Smart Contract Verification. ACM Transactions on Privacy and Security , 26, 2, Article 15, 28 pages.DOI:https://doi.org/10.1145/3564699

Show all 58 references
  1. [8]

    Cao, L. 2022. Decentralized AI: Edge intelligence and smart blockchain, metaverse, Web3, and DeSci. IEEE Intelligent Systems 37, 3 (May/June 2022), 6–19

  2. [9]

    Qiao, Y., Wu, K., and Khabbazian, M. 2024. Non-intrusive Balance Tomography Using Reinforcement Learn- ing in the Lightning Network. ACM Transactions on Privacy and Security , 27, 1, Article 12, 32 pages. DOI:https://doi.org/10.1145/3639366

  3. [10]

    Chen, Y., and Bellavitis, C. 2020. Blockchain disruption and decentralized finance: The rise of decentralized business models. Journal of Business Venturing Insights 13 (2020), e00151. DOI:https://doi.org/10.1016/j.jbvi.2019.e00151

  4. [11]

    Han, X., Yuan, Y., and Wang, F.-Y. 2019. A blockchain-based framework for central bank digital currency. In Pro- ceedings of the IEEE International Conference on Service Operations and Logistics, and Informatics (SOLI) . 263–268. DOI:https://doi.org/10.1109/SOLI48380.2019.8955032

  5. [12]

    A., and Monfared, R

    Abeyratne, S. A., and Monfared, R. P. 2016. Blockchain ready manufacturing supply chain using dis- tributed ledger. International Journal of Research in Engineering and Technology 5, 9 (2016), 1–10. DOI:https://doi.org/10.15623/ijret.2016.0509001

  6. [13]

    C., Mahmoud, Q

    Agbo, C. C., Mahmoud, Q. H., and Eklund, J. M. 2019. Blockchain technology in healthcare: A systematic review. Healthcare 7, 2 (2019), 56. DOI:https://doi.org/10.3390/healthcare7020056

  7. [14]

    R., Liu, C

    McGhin, T., Choo, K. R., Liu, C. Z., and He, D. 2019. Blockchain in healthcare applications: Research challenges and oppor- tunities. Journal of Network and Computer Applications 135 (2019), 62–75. DOI:https://doi.org/10.1016/j.jnca.2019.02.027

  8. [16]

    Braun, L., Demmler, D., Schneider, T., and Tkachenko, O. 2022. MOTION – A Framework for Mixed-Protocol Multi-Party Computation. ACM Transactions on Privacy and Security , 25, 2, Article 8, 35 pages. DOI:https://doi.org/10.1145/3490390

  9. [17]

    Ren, K., Guan, Z., Yang, C., Liu, Y., Zheng, Z., and Yu, J. 2023. Interoperability in blockchain: A survey.IEEE Transactions on Knowledge and Data Engineering 35, 12 (Dec. 2023), 12750–12769. DOI:https://doi.org/10.1109/TKDE.2023.3275220

  10. [18]

    Gazi, P., Kiayias, A., and Zindros, D. 2019. Proof-of-stake sidechains. In Proceedings of the IEEE Symposium on Security and Privacy. 139–156. DOI:https://doi.org/10.1109/SP.2019.00040

  11. [19]

    Lerner, S. D. 2019. RSK: Bitcoin powered smart contracts. [Online]. Available: https://bit.ly/3OPKof

  12. [20]

    Garoffolo, A., Kaidalov, D., and Oliynykov, R. 2020. Zendoo: A zk-SNARK verifiable cross-chain transfer protocol enabling decoupled and decentralized sidechains. In Proceedings of the IEEE 40th International Conference on Distributed Computing Systems (ICDCS). 1257–1262. DOI:h...

  13. [21]

    Tian, H., Tang, Q., Wang, J., Jia, J., and Wang, S. 2021. Enabling cross-chain transactions: A decentralized cryp- tocurrency exchange protocol. IEEE Transactions on Information Forensics and Security 16 (2021), 3928–3941. DOI:https://doi.org/10.1109/TIFS.2021.3096124

  14. [22]

    Wang, K., Zhang, Z., and Kim, H. S. 2018. ReviewChain: Smart contract based review system with multi-blockchain gateway. In Proceedings of the IEEE International Conference on Internet of Things (iThings) . 1521–1526. 27 , , SPID-Chain: Interoperable DAG Chain

  15. [23]

    Xiong, A., Liu, G., Zhu, Q., Jing, A., and Loke, S. W. 2022. A notary group-based cross-chain mechanism. Digital Communications and Networks 8 (2022), 1059–1067. DOI:https://doi.org/10.1016/j.dcan.2022.04.012

  16. [24]

    Ren Project. 2022. RenVM white paper. [Online]. Available: https://github.com/renproject/ren/wiki

  17. [25]

    J., Hegnauer, T., Rodrigues, B., and Stiller, B

    Scheid, E. J., Hegnauer, T., Rodrigues, B., and Stiller, B. 2019. Bifröst: A modular blockchain interop- erability API. In Proceedings of the IEEE 44th Conference on Local Computer Networks (LCN) . 332–339. DOI:https://doi.org/10.1109/LCN44214.2019.8990860

  18. [26]

    Nolan, T. 2013. Alt chains and atomic transfers. In Bitcoin Forum. [Online]. Available: https://archive.ph/wWzna

  19. [27]

    Herlihy, M. 2018. Atomic cross-chain swaps. InProceedings of the ACM Symposium on Principles of Distributed Computing (PODC). 245–254. DOI:https://doi.org/10.1145/3212734.3212736

  20. [28]

    Pillai, B., Biswas, K., Hóu, Z., and Muthukkumarasamy, V. 2021. Burn-to-claim: An asset transfer protocol for blockchain interoperability. Computer Networks 200 (2021), 108495. DOI:https://doi.org/10.1016/j.comnet.2021.108495

  21. [29]

    Ethereum Foundation. 2017. BTCRelay: Ethereum contract for Bitcoin SPV. [Online]. Available: https://github.com/ethereum/btcrelay

  22. [30]

    Zamyatin, A., Harz, D., Lind, J., Panayiotou, P., Gervais, A., and Knottenbelt, W. J. 2019. XCLAIM: Trustless, in- teroperable, cryptocurrency-backed assets. In Proceedings of the IEEE Symposium on Security and Privacy . 193–210. DOI:https://doi.org/10.1109/SP.2019.00085

  23. [31]

    Westerkamp, M., and Diez, M. 2022. Verilay: A verifiable proof of stake chain relay. arXiv preprint arXiv:2201.08697

  24. [32]

    Bentov, I., Ji, Y., Zhang, F., Breidenbach, L., Daian, P., and Juels, A. 2019. Tesseract: Real-time cryptocurrency exchange using trusted hardware. In Proceedings of the 2019 ACM SIGSAC Conference on Computer and Communications Security (CCS ’19). ACM, New York, NY, 1521–1538....

  25. [33]

    Interledger Foundation. 2020. Interledger Protocol V4 (ILPv4). [Online]. Available: https://archive.ph/QZSOR

  26. [34]

    Perun Network. 2022. The Perun framework. [Online]. Available: https://archive.ph/VpMW1

  27. [35]

    Abebe, E., et al. 2019. Enabling enterprise blockchain interoperability with trusted data transfer (in- dustry track). In Proceedings of the 20th International Middleware Conference Industrial Track . 29–35. DOI:https://doi.org/10.1145/3366626.3368129

  28. [36]

    Pupyshev, A., Dzhafarov, E., Sapranidi, I., Kardanov, I., Khalilov, S., and Laureyssens, S. 2020. Gravity: A blockchain- agnostic cross-chain communication and data oracles protocol. arXiv preprint arXiv:2007.00966

  29. [37]

    Pupyshev, A., Dzhafarov, E., Sapranidi, I., Kardanov, I., Khalilov, S., and Laureyssens, S. 2020. SuSy: A blockchain- agnostic cross-chain asset transfer gateway protocol based on Gravity. arXiv preprint arXiv:2008.13515

  30. [38]

    C., Ruan, P., and Wang, T

    Ge, Z., Loghin, D., Ooi, B. C., Ruan, P., and Wang, T. 2022. Hybrid blockchain database systems: Design and performance. Proceedings of the VLDB Endowment 15, 5 (2022), 1092–1104. DOI:https://doi.org/10.14778/3510397.3510406

  31. [39]

    Dinh, T. T. A., Liu, R., Zhang, M., Chen, G., Ooi, B. C., and Wang, J. 2018. Untangling blockchain: A data processing view of blockchain systems. IEEE Transactions on Knowledge and Data Engineering 30, 10 (Oct. 2018), 2003–2024. DOI:https://doi.org/10.1109/TKDE.2018.2831687

  32. [40]

    J., Agrawal, D., and Abbadi, A

    Amiri, M. J., Agrawal, D., and Abbadi, A. E. 2019. CAPER: A cross-application permissioned blockchain. Proceedings of the VLDB Endowment 12, 11 (2019), 1385–1398. DOI:https://doi.org/10.14778/3342263.3342275

  33. [41]

    Ramakrishna, V. 2021. Meet Weaver, one of the new Hyperledger Labs taking on cross-chain and off-chain operations. [Online]. Available: https://archive.ph/rYjcG

  34. [42]

    CertiK Security Leaderboard. 2022. Wormhole token bridge attack. [Online]. Available: https://archive.ph/FAoFG

  35. [43]

    Poly Network. 2022. The analysis and Q and A of Poly Network being hacked. [Online]. Available: https://archive.ph/NCXGS

  36. [44]

    S., Lal, C., and Ruj, S

    Conti, M., Kumar, E. S., Lal, C., and Ruj, S. 2018. A survey on security and privacy issues of Bitcoin.IEEE Communications Surveys and Tutorials 20, 4 (Fourth Quarter 2018), 3416–3452. DOI:https://doi.org/10.1109/COMST.2018.2842460

  37. [45]

    Ren, M., et al. 2021. Empirical evaluation of smart contract testing: What is the best choice? In Proceedings of the 30th ACM SIGSOFT International Symposium on Software Testing and Analysis (ISSTA ’21) . ACM, New York, NY, 566–579. DOI:https://doi.org/10.1145/3460319.3464837

  38. [46]

    Kaleem, M., Kasichainula, K., Karanjai, R., Xu, L., Gao, Z., Chen, L., and Shi, W. 2021. An event-driven framework for smart contract execution. In Proceedings of the 15th ACM International Conference on Distributed and Event-based Systems (DEBS ’21). ACM, New York, NY, 78–89....

  39. [47]

    Müller, S., Penzkofer, A., Polyanskii, N., Theis, J., Sanders, W., and Moog, H. 2022. Tangle 2.0 leaderless Nakamoto con- sensus on the heaviest DAG. IEEE Access 10 (2022), 105807–105842. DOI:https://doi.org/10.1109/ACCESS.2022.3213121

  40. [48]

    Bartan, B., and Pilanci, M. 2019. Straggler resilient serverless computing based on polar codes. In Proceedings of the 57th Annual Allerton Conference on Communication, Control, and Computing (Allerton)

  41. [49]

    Pilanci, M. 2022. Computational polarization: An information-theoretic method for resilient computing. IEEE Transac- tions on Information Theory 68, 4 (April 2022), 2211–2238. DOI:https://doi.org/10.1109/TIT.2021.3139009

  42. [50]

    Fathollahi, D., and Mondelli, M. 2022. Polar coded computing: The role of the scaling exponent. In Proceedings of the IEEE International Symposium on Information Theory (ISIT) . 2154–2159. 28 SPID-Chain: A Smart Contract-Enabled, Polar-Coded Interoperable DAG Chain , ,

  43. [51]

    The blockchain framework for a multichain future

    Substrate. The blockchain framework for a multichain future. [Online]. Available: https://substrate.io/

  44. [52]

    Goshimmer Docker network tools

    IOTA Foundation. Goshimmer Docker network tools. [Online]. Available: https://github.com/iotaledger/goshimmer/tree/develop/tools/dockernetwork

  45. [53]

    [Online]

    Goshimmer Orphanage. [Online]. Available: https://github.com/daria305/goshimmer-orphanage

  46. [54]

    [Online]

    Rust Programming Language. [Online]. Available: https://www.rust-lang.org/

  47. [55]

    [Online]

    Libsodium documentation. [Online]. Available: https://doc.libsodium.org/

  48. [56]

    Ethereum BigQuery public dataset for smart contract analytics

    Google Cloud. Ethereum BigQuery public dataset for smart contract analytics. [Online]. Available: https://cloud.google.com/blog/products/data-analytics/ethereum-bigquery-public-dataset-smart-contract-analytics

  49. [58]

    Lin, Q., Li, C., Zhao, X., and Chen, X. 2021. Measuring decentralization in Bitcoin and Ethereum using multiple metrics and granularities. In Proceedings of the IEEE 37th International Conference on Data Engineering Workshops (ICDEW) . 80–87

  50. [59]

    Müller, S., Amigo, I., Reiffers-Masson, A., and Ruano-Rincón, S. 2023. Stability of local tip pool sizes. arXiv preprint arXiv:2302.01625. 29

Pith tools

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