Pith. sign in

REVIEW 4 major objections 5 minor 63 references

HyperService: Interoperability and Programmability Across Heterogeneous Blockchains

T0 review · 4 major / 5 minor · reviewed 2026-08-14 · deepseek-v4-flash

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

Pith's one-line read HyperService claims to be the first platform that both lets developers write cross-chain dApps in one language and provably secures their execution across heterogeneous blockchains.

desk verdict A genuine systems contribution for cross-chain programmability with a real prototype, but the UC security proof in Section 8 is a sketch that omits the passive-corruption case, and the ideal functionality is cut to fit the protocol. read the letter →

arxiv 1908.09343 v3 pith:HZIOZBLR submitted 2019-08-25 cs.CR

Zhuotao Liu , Yangxi Xiang , Jian Shi , Peng Gao , Haoyu Wang , Xusheng Xiao , Bihan Wen , Yih-Chun Hu This is my paper · ORCID
classification cs.CR
keywords blockchaininteroperabilitycross-chaindAppssmartcontractsuniversalcomposabilityNetworkStatusInsuranceContractHSLprogramminglanguagefinancialatomicity
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

The paper argues that blockchain interoperability should mean programmability, not just token swaps, and claims HyperService is the first platform to deliver both across heterogeneous blockchains. Its programming framework (USM and the HSL language) abstracts different blockchains into a unified state model, so a developer can write one cross-chain dApp without implementing any cryptography. Its UIP protocol then executes the compiled transaction dependency graph through a Network Status Blockchain and an Insurance Smart Contract, which together provide an objective view of execution status, arbitrate deadlines and preconditions, and financially revert failed executions while blaming the responsible party. The paper's central security theorem states that UIP provably realizes an ideal functionality for cross-chain dApps in the UC framework under secure consensus, preimage-resistant hashing, and EU-CMA signatures. The paper also reports a roughly 35,000-line prototype with end-to-end latencies in seconds, and notes in its own discussion that the guarantee is financial atomicity rather than rollback of smart-contract state.

What carries the argument

The load-bearing machinery is the pair (NSB, ISC) under UIP: the Network Status Blockchain is a "blockchain of blockchains" that packs StatusRoot (finalized transaction state from underlying chains) and ActionRoot (certificates of actions by VESes and clients) into its blocks, giving an objective unified clock and proof medium; the Insurance Smart Contract is a code-arbitrator that, given proofs from the NSB, checks preconditions and deadlines, marks dirty transactions, and executes a decision tree to blame the right party and revert funds. Supporting this, the HSL compiler produces the Transaction Dependency Graph $G_T$ whose transaction wrappers carry fund-reversion tuples, state proofs, and deadlines, so the ISC can arbitrate mechanically. The ideal functionality $F_{\mathrm{UIP}}$ and its UC proof tie the real protocol's guarantees to a trusted abstraction.

What would settle it

Run a test on the prototype in which an adversary delays finality of one underlying transaction while the NSB advances, then call ProtISC and check whether a transaction whose precondition has not actually finalized can be marked correct and a payment settled; if the ISC ever pays out on a non-finalized precondition, the real protocol is distinguishable from $F_{\mathrm{UIP}}$ and Theorem 8.1 is false.

Watch

Extended reading notes

Core claim

On the paper's own terms, the discovery is that cross-chain dApps over heterogeneous blockchains can be made simultaneously programmable and secure: the UIP protocol provably UC-realizes the ideal functionality $F_{\mathrm{UIP}}$ (Theorem 8.1), meaning a dApp either completes with publicly verifiable correctness or aborts with misbehaving parties held accountable and committed funds reverted. Programmability comes from HSL, whose compiler validates the dApp and emits a transaction dependency graph; security comes from the NSB, which records finalized state and signed actions in Merkle trees, and the ISC, which arbitrates the graph's preconditions and deadlines and executes the decision tree for accountability. The paper further claims this is the first generic interoperability protocol whose scope goes beyond token exchange to arbitrary smart-contract invocations across chains.

Load-bearing premise

The whole guarantee leans on the Network Status Blockchain being correct: if fewer than K of its consensus nodes are honest, or if it finalizes a wrong StatusRoot, the insurance contract can misarbitrate and the promised financial atomicity breaks.

Editorial extensions

If this is right

  • Developers can write cross-chain dApps in HSL against a unified state model and have them compiled into executable transaction graphs for any set of public-ledger blockchains, without protocol changes to those chains.
  • A dApp either completes with publicly verifiable correctness or aborts with financial reversion and an identified accountable party, so VESes can operate as trust-free cross-chain service providers that misbehave at their own risk.
  • Any blockchain can serve as an oracle for other blockchains, so financial derivatives can obtain strike prices from a chain rather than from a trusted data-feed provider.
  • The same machinery generalizes to sharded blockchains, where an existing beacon or identity chain can play the NSB role and cross-shard contracts are simpler to write than cross-chain ones.
  • The measured NSB throughput of about 1000 KB/s of committed certificates bounds aggregate dApp capacity; with at most six NSB transactions per dApp transaction, capacity is about 170,000 divided by the certificate size in bytes transactions per second when off-chain channels are fully unavailable.

Reading between the lines

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

  • If Theorem 8.1 is sound, the practical trust bottleneck of a HyperService deployment is not the cryptography but the NSB: an adversary who controls the NSB quorum can corrupt the arbitration itself, so the "zero trust" framing in the introduction should be read as "trust the NSB quorum plus one honest participant."
  • The contrast between Theorem 8.1 (passive corruption) and Theorem 8.2 (Byzantine, but only with all communication through the NSB) implies a design trade-off: off-chain state channels buy latency at the cost of a weaker adversarial model, so production systems must pick a point on that curve.
  • The latency breakdown in Table 3 suggests that session creation (roughly 60% of end-to-end time) is the highest-leverage target for optimization, since ISC deployment and handshake dominate what HyperService itself controls.
  • A direct experimental check of the arbitration logic: deliberately stall a transaction at each of the six protocol states, invoke the ISC, and verify that the blamed party matches the decision tree in Figure 9; any mismatch would indicate the real protocol and $F_{\mathrm{UIP}}$ diverge.
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

4 major / 5 minor

Summary. The paper presents HyperService, a platform that aims to provide both interoperability and programmability across heterogeneous blockchains. The system has two main components: a developer-facing programming framework built around a Unified State Model (USM) and a high-level language HSL, which compiles cross-chain dApps into a transaction dependency graph; and a blockchain-facing cryptographic protocol UIP, which coordinates execution across blockchains using a Network Status Blockchain (NSB) and Insurance Smart Contracts (ISCs) to enforce correctness, accountability, and financial atomicity. The authors claim that UIP provably realizes an ideal functionality F_UIP in the Universal Composability framework, and they implement a prototype of roughly 35,000 lines of code, reporting end-to-end dApp latency on the order of seconds and an NSB throughput measurement. The paper also claims to be the first platform to simultaneously provide interoperability and programmability across heterogeneous blockchains.

Significance. If the security claims were fully established, this would be a substantial contribution to blockchain interoperability: it goes beyond atomic token swaps by offering a general programming model for cross-chain dApps and a protocol designed to execute them over heterogeneous ledgers. The paper is also strong on the systems side: it provides a detailed protocol specification, a working prototype, and experimental results on three categories of dApps, and it explicitly discusses extensions and limitations. The claimed UC-security theorem is the central load-bearing assertion, and as written the proof has significant gaps: it does not handle passively corrupted parties in the simulator construction, and the Byzantine result is proven only for a variant that removes the off-chain channels. The 'zero trust' language in the introduction is not supported by the paper's own trust assumptions on the NSB. For these reasons, the current version does not justify the security claims as stated, though the underlying design and prototype are valuable.

major comments (4)
  1. [§8.4–§8.5, Theorem 8.1] The proof of Theorem 8.1 does not address the simulation of passively corrupted parties, which is a required part of a UC security proof. The simulator S in §8.4 is constructed only for the dummy adversary that relays messages, and the hybrid argument in §8.5 replaces parties with dummy parties without giving any procedure for S to output the internal state (secret keys, random coins, session bookkeeping, received messages) of a party that the environment chooses to corrupt. Without such a procedure, the environment can distinguish a real execution from an ideal one by examining a corrupted party's state. The sentence in Fact 1 that this is 'immediately clear' is not a substitute for the missing simulator construction. Therefore Theorem 8.1 is not established as written.
  2. [§8.6, Theorem 8.2] The Byzantine security result is proven only for H-ProtUIP, which requires all communication through the NSB. The actual ProtUIP protocol uses off-chain state channels for agility, and §8.6 explicitly explains why the dual-medium design prevents the simulator from accurately emulating a Byzantine-corrupted party (conflicting messages can be sent to the channel and the NSB). Consequently, the paper's deployed protocol has no proof of security against a fully malicious (Byzantine) adversary; Theorem 8.1 covers only passive corruption, and Theorem 8.2 applies to a variant that is not the system described in §4 and evaluated in §5. The unqualified statements in the abstract and §1 that UIP 'provably realizes' applications and is 'fully trust-free' therefore outrun what the proofs actually demonstrate.
  3. [§2.5 vs. §1] The introduction claims that UIP is 'fully trust-free' and that HyperService coordinates execution 'in a fully decentralized manner with zero trust assumptions', but §2.5 states that 'The correctness of UIP relies on the correctness of the NSB' and assumes that at least K consensus nodes of the NSB are honest. This is a genuine trust assumption on a permissioned subsystem introduced by the paper. The security theorem also inherits any failure modes of the NSB, including delayed or incorrect finality. The claim of zero trust should be qualified or removed, and the concrete trust model for the NSB should be stated in the introduction where the strong claims are made.
  4. [§8.1, Figure 11] There is a circularity concern about the ideal functionality: the text states 'We intentionally define F_UIP verbosely ... to accurately match F_UIP to the real world protocol ProtUIP', and Figure 11 embeds the same arbitration decision tree and the same certificate and attestation steps used by ProtUIP. As a result, the UC-realization proof largely shows that ProtUIP implements an idealization of its own concrete logic. This does not invalidate the protocol design, but it substantially weakens the force of the 'provably realizes' claim, because the ideal functionality does not abstract away the protocol's implementation choices. To make the security claim meaningful, the authors should either present a more abstract F_UIP that captures only the desired correctness and financial-atomicity properties, or explicitly discuss why the verbosity is needed and what security properties are being guaranteed beyond the protocol's own definition.
minor comments (5)
  1. [Figure 6, lines 82 and 95] The protocol pseudocode uses 'ast.' where it should say 'assert', which is confusing in a formal protocol description.
  2. [§8.3] There is a grammatical error: 'We now the prove our main theorems' should be 'We now prove our main theorems'.
  3. [§4.6] The sentence 'Then we prove that ProtUIP, our the decentralized real-world protocol' contains a typo: 'our the' should be 'our'.
  4. [§8.5, Hybrid A1] The description of where the contract is deployed says 'on PNSB or PBC', but in the real protocol the insurance contract is deployed on the NSB; the reason for allowing either in the hybrid should be clarified.
  5. [Figure 4] Transaction T5 on ChainZ is listed without its detail fields, and the figure caption does not explain whether the omission is for space or because T5 has the same structure as T4. A brief note would improve readability.

Circularity Check

2 steps flagged · score 6.0 of 10

FUIP is deliberately defined to match ProtUIP, so Theorem 8.1 largely proves that the real protocol realizes a trusted copy of its own state machine and arbitration tree.

  1. self definitional [Section 8.1, 'Verbose Definition of FUIP' (Figure 11)]
    "We intentionally define FUIP verbosely (that is, sending many signed messages) in order to accurately match FUIP to the real world protocol ProtUIP."

    The ideal functionality is explicitly constructed from the real protocol rather than from an independent statement of desired security, so Theorem 8.1's conclusion that ProtUIP UC-realizes FUIP is close to 'ProtUIP realizes a trusted copy of ProtUIP.' The state-transition interfaces of FUIP (ReqTransInit/Inited/Open/Opened/Close and TermExecution) mirror the handlers of ProtVES/ProtCLI and ProtISC; hence the proof's hybrid arguments mostly show that the real-world attestations line up with the pre-transcribed ideal transcript. This does not add an external security derivation: the target specification was reverse-engineered from the implementation.

  2. self definitional [Section 8.1 TermExecution vs Section 4.4.2 / Figure 9]
    "The arbitration logic is also derived from decision tree mentioned in Figure 9."

    The real-world ISC's accountability logic is first defined in Section 4.4.2 by deriving the decision tree 'from the execution steps taken by ProtVES and ProtCLI' (Figure 9); FUIP then adopts the same decision tree in its TermExecution interface. When Theorem 8.1 concludes that ProtUIP holds misbehaving parties accountable, it is comparing the protocol's accountability rule to an ideal functionality that contains that very rule by construction. The accountability/financial-atomicity guarantee is therefore assumed in the ideal specification, not independently derived.

full rationale

The paper's central security theorem is not fully circular, but it is substantially weakened by construction. The authors explicitly state in Section 8.1 that FUIP is defined verbosely 'in order to accurately match FUIP to the real world protocol ProtUIP,' and the ideal functionality's TermExecution interface copies the same accountability decision tree (Figure 9) that ProtISC already implements (Section 4.4.2). Consequently, Theorem 8.1's conclusion that ProtUIP UC-realizes FUIP largely verifies that the real protocol is internally consistent with a trusted transcription of itself; the 'provably realizes' claim does not validate the arbitration/accountability semantics against an independent specification. There remains non-circular content: the proof connects the real cryptographic attestations (signatures, Merkle proofs, NSB quorum) to the ideal interface under the stated assumptions, and the implementation/evaluation, NSB honest-majority assumption, and external factors are independent of the theorem. The passive-corruption gap in Sections 8.4-8.5 is a proof-completeness issue rather than circularity, so it is not scored here.

Assumptions & free parameters 0 free parameters · 5 assumptions · 3 invented entities

The central claims rest on standard cryptographic assumptions, on the correctness of the underlying blockchains' consensus, on an honest-majority assumption for the NSB, and on the assertion that imported source code matches deployed code. No free parameters are fitted to data.

assumptions (5)
  • domain assumption Underlying blockchains have secure consensus and transaction finality.
    Section 2.5 assumes common-prefix for Nakamoto chains and quorum signatures for permissioned chains; finality proofs (Merkc1_T) require this.
  • domain assumption At least K consensus nodes of the NSB are honest.
    Section 2.5 states: "The correctness of UIP relies on the correctness of the NSB... at least K consensus nodes of the NSB are honest." The NSB is a permissioned Tendermint chain.
  • domain assumption Imported contract source code matches the bytecode actually deployed on chain.
    Section 3.2 says the compiler "should verify" this consistency for security, but no mechanism is specified or evaluated in the prototype; the correctness checks in Section 3.3 depend on it.
  • standard math Hash functions are preimage resistant and signatures are EU-CMA secure.
    Theorem 8.1 explicitly assumes these standard cryptographic assumptions for the UC security proof.
  • standard math The UC framework soundly captures protocol security.
    The proof is expressed in Canetti's UC framework [28] and relies on its composition and transitivity properties.
invented entities (3)
  • Network Status Blockchain (NSB) independent evidence
    purpose: Provides a unified, verifiable status view of finalized transactions and action proofs across chains; feeds Merkle proofs to the insurance contract.
    A new permissioned blockchain proposed by the authors; its honest-majority assumption is the trust anchor for UIP. It is implemented on Tendermint in the prototype.
  • Insurance Smart Contract (ISC) independent evidence
    purpose: Arbitrates execution correctness and executes fund reversion and accountability decisions.
    A contract whose arbitration logic is the decision tree in Figure 9; "correctness" is defined by this contract.
  • Verifiable Execution System (VES) independent evidence
    purpose: Compiles HSL programs, drives the UIP protocol, and can be held accountable via insurance.
    A new system role in the design; the prototype implements it.

how reviews work

0 comments
Cite this review

Pith. "Pith review of HyperService: Interoperability and Programmability Across Heterogeneous Blockchains." pith.science (2026). https://pith.science/paper/HZIOZBLR

@misc{pith2026190809343,
  author       = {Pith},
  title        = {Pith review of: HyperService: Interoperability and Programmability Across Heterogeneous Blockchains},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/HZIOZBLR}},
  note         = {Machine review of arXiv:1908.09343}
}
read the original abstract

Blockchain interoperability, which allows state transitions across different blockchain networks, is critical functionality to facilitate major blockchain adoption. Existing interoperability protocols mostly focus on atomic token exchange between blockchains. However, as blockchains have been upgraded from passive distributed ledgers into programmable state machines (thanks to smart contracts), the scope of blockchain interoperability goes beyond just token exchange. In this paper, we present HyperService, the first platform that delivers interoperability and programmability across heterogeneous blockchains. HyperService is powered by two innovative designs: (i) a developer-facing programming framework that allows developers to build cross-chain applications in a unified programming model; and (ii) a secure blockchain-facing cryptography protocol that provably realizes those applications on blockchains. We implement a prototype of HyperService in about 35,000 lines of code to demonstrate its practicality. Our experiment results show that HyperService imposes reasonable latency, in order of seconds, on the end-to-end execution of cross-chain applications

Figures

Figures reproduced from arXiv: 1908.09343 by the authors.

Figure 1
Figure 1. The architecture of HyperService. writing cross-chain dApps, and a blockchain-facing cryptography protocol to securely realize those dApps on blockchains. Within this programming framework, we propose Unified State Model (USM), a blockchain-neutral and extensible model to describe cross-chain dApps, and the HSL, a high-level programming language to write cross-chain dApps under the USM programming model. dApps writt… view at source ↗
Figure 2
Figure 2. A cross-chain Option dApp written in HSL. turn, prevents dApps from spreading their business across multi￾ple blockchains. For instance, a call-option contract deployed on Ethereum forces investors to exercise the option using Ether, but not in other cryptocurrencies. As an introductory example, we shall see how conceptually simple, yet elegant, it is, from developers’ perspective, to build a universal call-option d… view at source ↗
Figure 3
Figure 3. Workflow of HSL compilation. 3.1 Unified Type System The USM is designed to provide a unified virtualization layer for developers to define invocation operations in their HSL programs, without handling the heterogeneity of contract entities. Towards this end, the programming framework internally defines a Unified Type System so that state variables and methods of all contract entities can be abstracted using the uni… view at source ↗
Figures from the paper (9 more)
Figure 4
Figure 4. Figure 4: show the GT generated for the HSL program in [PITH_FULL_IMAGE:figures/full_fig_p006_4.png]
Figure 5
Figure 5. Figure 5: The architecture of NSB blocks. support the extra functionality of the NSB, an NSB block contains two additional Merkle tree roots: StatusRoot and ActionRoot. StatusRoot is the root of a Merkle tree (referred as StatusMT) that stores transaction status of underlying bl…
Figure 6
Figure 6. Figure 6: Protocol description of of ProtVES. Gray background denotes non-blocking operations triggered by status updates on ProtNSB. Handlers annotated with northbound and southbound process transactions originated from ProtVES and ProtCLI, respectively. Handlers annotated with…
Figure 7
Figure 7. Figure 7: The complete on-chain proof (denoted by Merkc T ) to prove that the state of a transaction is eligible to be pro￾moted as closed. The left-side part is the finalization proof (denoted by Merkc1 T ) for the transaction collected from its destination blockchain; the righ…
Figure 8
Figure 8. Figure 8: ProtISC: the protocol realization of the ISC arbitrator. searches the sorted ActionMT to look for any session-relevant cer￾tificates that have not been received via the off-chain channel. Sec￾ond, for each opened T whose closed attestation is still missing after ProtVE…
Figure 9
Figure 9. Figure 9: The decision tree to decide the accountable party [PITH_FULL_IMAGE:figures/full_fig_p011_9.png]
Figure 10
Figure 10. Figure 10: The throughput of the NSB, measured as the total size of committed certificates on the NSB per second. 5.3 Experiments We ran experiments with three blockchain testnets: one private Ethereum testnet, one Tendermint-based blockchain, and the NSB. Each of those testnets…
Figure 11
Figure 11. Figure 11: The ideal functionality FUIP. by (IFUIP , S), and the real world, featured by (ProtUIP, A). Math￾ematically, on any input, the probability that E outputs −→1 after interacting with (ProtUIP, A) in the real world differs by at most a negligible amount from the probabil…
Figure 12
Figure 12. Figure 12: Detailed protocol description of ProtNSB. Interfaces annotated with override are also implemented by ProtBC. Gray background denotes the protocol of honest peers in the NSB to ensure the correctness for the corresponding interface [PITH_FULL_IMAGE:figures/full_fig_p0…

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

63 extracted references · 62 canonical work pages

  1. [1]

    https://cosmos.network/resources/whitepaper, 2019

    Cosmos WhitePaper. https://cosmos.network/resources/whitepaper, 2019

    work page 2019

  2. [2]

    https://harmony.one/whitepaper.pdf, 2019

    Harmony: Technical Whitepaper. https://harmony.one/whitepaper.pdf, 2019

    work page 2019

  3. [3]

    In USENIX NSDI (2019)

    Monoxide: Scale Out Blockchain with Asynchronized Consensus Zones. In USENIX NSDI (2019)

    work page 2019

  4. [4]

    https://github

    Open Source Code for HyperService by HyperService-Consortium. https://github. com/HyperService-Consortium, 2019

    work page 2019

  5. [5]

    https://en.bitcoin.it/wiki/Atomic_ swap, Accessed on 2019

    Bitcoin Wiki: Atomic Cross-Chain Trading. https://en.bitcoin.it/wiki/Atomic_ swap, Accessed on 2019

    work page 2019

  6. [6]

    https://coinmarketcap.com, Accessed on 2019

    CoinMarketCap. https://coinmarketcap.com, Accessed on 2019

    work page 2019

  7. [7]

    https://cosmos.network, Accessed on 2019

    Cosmos. https://cosmos.network, Accessed on 2019

    work page 2019

  8. [8]

    https://steemit.com/dpos/@dantheman/dpos- consensus-algorithm-this-missing-white-paper, Accessed on 2019

    DPOS Consensus Algorithm. https://steemit.com/dpos/@dantheman/dpos- consensus-algorithm-this-missing-white-paper, Accessed on 2019

    work page 2019

Show all 63 references
  1. [9]

    Morgan: Blockchain and Distributed Ledger

    J.P. Morgan: Blockchain and Distributed Ledger. https://www.jpmorgan.com/ global/blockchain, Accessed on 2019

    2019

  2. [10]

    https://github.com/nebulasio, Accessed on 2019

    Nebulas. https://github.com/nebulasio, Accessed on 2019

    2019

  3. [11]

    http://www.oraclize.it, Accessed on 2019

    Oraclize. http://www.oraclize.it, Accessed on 2019

    2019

  4. [12]

    https://polkadot.network, Accessed on 2019

    Polkadot. https://polkadot.network, Accessed on 2019

    2019

  5. [13]

    https://rhombus.network, Accessed on 2019

    rhombus. https://rhombus.network, Accessed on 2019

    2019

  6. [14]

    https://solidity.readthedocs.io/en/v0.5.6/, Accessed on 2019

    Solidity. https://solidity.readthedocs.io/en/v0.5.6/, Accessed on 2019

    2019

  7. [15]

    https://github.com/ cosmos/ics, Accessed on 2019

    Standards for the Cosmos network & Interchain Ecosystem. https://github.com/ cosmos/ics, Accessed on 2019

    2019

  8. [16]

    https://github.com/paritytech/substrate, Accessed on 2019

    Substrate. https://github.com/paritytech/substrate, Accessed on 2019

    2019

  9. [17]

    https://tendermint.com, Accessed on 2019

    Tendermint Core. https://tendermint.com, Accessed on 2019

    2019

  10. [18]

    https://metrics.torproject.org/rs.html#search/flag: authority, Accessed on 2019

    Tor Directory Authorities. https://metrics.torproject.org/rs.html#search/flag: authority, Accessed on 2019

    2019

  11. [19]

    https://github.com/ethereum/vyper, Accessed on 2019

    Vyper. https://github.com/ethereum/vyper, Accessed on 2019

    2019

  12. [20]

    Chainspace: A Sharded Smart Contracts Platform

    Al-Bassam, M., Sonnino, A., Bano, S., Hrycyszyn, D., and Danezis, G. Chainspace: A Sharded Smart Contracts Platform. NDSS (2017)

    2017

  13. [21]

    Enabling Blockchain Innovations with Pegged Sidechains

    Back, A., Corallo, M., Dashjr, L., Friedenbach, M., Maxwell, G., Miller, A., Poelstra, A., Timón, J., and Wuille, P. Enabling Blockchain Innovations with Pegged Sidechains. URL: tinyurl. com/mj656p7 (2014)

    2014

  14. [22]

    L., Gao, V., Maurer, B., Nowacki, T., Pott, A., Qadeer, S., Rain, Russi, D., Sezer, S., Zakian, T., and Zhou, R

    Blackshear, S., Cheng, E., Dill, D. L., Gao, V., Maurer, B., Nowacki, T., Pott, A., Qadeer, S., Rain, Russi, D., Sezer, S., Zakian, T., and Zhou, R. Move: A language with programmable resources. Tech. rep., The Libra Association, 2019

    2019

  15. [23]

    Chimera: A Declarative Language for Streaming Network Traffic Analysis

    Borders, K., Springer, J., and Burnside, M. Chimera: A Declarative Language for Streaming Network Traffic Analysis. In USENIX Security Symposium (2012)

    2012

  16. [24]

    In 27th USENIX Security Symposium (2018)

    Breidenbach, L., Cornell Tech, I., Daian, P., Tramer, F., and Juels, A.Enter the Hydra: Towards Principled Bug Bounties and Exploit-Resistant Smart Contracts. In 27th USENIX Security Symposium (2018)

    2018

  17. [25]

    Bulletproofs: Short proofs for Confidential Transactions and More

    Bünz, B., Bootle, J., Boneh, D., Poelstra, A., Wuille, P., and Maxwell, G. Bulletproofs: Short proofs for Confidential Transactions and More. In 2018 IEEE Symposium on Security and Privacy (SP) (2018), IEEE, pp. 315–334

    2018

  18. [26]

    Chain Interoperability

    Buterin, V. Chain Interoperability. R3 Reports (2016)

    2016

  19. [27]

    A Next-Generation Smart Contract and Decentralized Appli- cation Platform

    Buterin, V., et al. A Next-Generation Smart Contract and Decentralized Appli- cation Platform. white paper (2014)

    2014

  20. [28]

    Universally Composable Security: A New Paradigm for Crypto- graphic Protocols

    Canetti, R. Universally Composable Security: A New Paradigm for Crypto- graphic Protocols. In IEEE Symposium on Foundations of Computer Science (2001)

    2001

  21. [29]

    M., Juels, A., Miller, A., and Song, D

    Cheng, R., Zhang, F., Kos, J., He, W., Hynes, N., Johnson, N. M., Juels, A., Miller, A., and Song, D. Ekiden: A Platform for Confidentiality-Preserving, Trustworthy, and Performant Smart Contract Execution. In IEEE EuroS&P (2019)

    2019

  22. [30]

    Intel SGX explained, Accessed on 2019

    Costan, V., and Devadas, S. Intel SGX explained, Accessed on 2019. https: //eprint.iacr.org/2016/086.pdf

    2019

  23. [31]

    Tor: The Second-Generation Onion Router

    Dingledine, R., Mathewson, N., and Syverson, P. Tor: The Second-Generation Onion Router. In USENIX Security Symposium (2004)

    2004

  24. [32]

    E., Sirer, E

    Eyal, I., Gencer, A. E., Sirer, E. G., and V an Renesse, R. Bitcoin-NG: A Scalable Blockchain Protocol. In USENIX NSDI (2016)

    2016

  25. [33]

    H., Kulkarni, S

    Gao, P., Xiao, X., Li, D., Li, Z., Jee, K., Wu, Z., Kim, C. H., Kulkarni, S. R., and Mittal, P. SAQL: A Stream-based Query System for Real-time Abnormal System Behavior Detection. In USENIX Security Symposium (2018)

    2018

  26. [34]

    R., and Mittal, P

    Gao, P., Xiao, X., Li, Z., Jee, K., Xu, F., Kulkarni, S. R., and Mittal, P. AIQL: Enabling Efficient Attack Investigation from System Monitoring Data. InUSENIX ATC (2018)

    2018

  27. [35]

    The Bitcoin Backbone Protocol with Chains of Variable Difficulty

    Garay, J., Kiayias, A., and Leonardos, N. The Bitcoin Backbone Protocol with Chains of Variable Difficulty. In Annual International Cryptology Conference (2017)

    2017

  28. [36]

    Proof-of-stake Sidechains

    Gazi, P., Kiayias, A., and Zindros, D. Proof-of-stake Sidechains. In IEEE Symposium on Security & Privacy (2019)

    2019

  29. [37]

    Bolt: Anonymous Payment Channels for Decentralized Currencies

    Green, M., and Miers, I. Bolt: Anonymous Payment Channels for Decentralized Currencies. In ACM CCS (2017)

    2017

  30. [38]

    Atomic Cross-Chain Swaps

    Herlihy, M. Atomic Cross-Chain Swaps. In ACM PODC (2018)

    2018

  31. [39]

    M., and Felten, E

    Kalodner, H., Goldfeder, S., Chen, X., Weinberg, S. M., and Felten, E. W. Arbitrum: Scalable, Private Smart Contracts. In USENIX Security Symposium (2018)

    2018

  32. [40]

    Revive: Rebalancing Off-blockchain Payment Net- works

    Khalil, R., and Gervais, A. Revive: Rebalancing Off-blockchain Payment Net- works. In ACM CCS (2017)

    2017

  33. [41]

    Proof-of-work Sidechains

    Kiayias, A., and Zindros, D. Proof-of-work Sidechains. Tech. rep., Cryptology ePrint Archive, Report 2018/1048, 2018

    2018

  34. [42]

    E., Anderson, J

    Killian, C. E., Anderson, J. W., Braud, R., Jhala, R., and V ahdat, A. M. Mace: Language support for building distributed systems. In ACM PLDI (2007)

    2007

  35. [43]

    K., Jovanovic, P., Gailly, N., Khoffi, I., Gasser, L., and Ford, B

    Kogias, E. K., Jovanovic, P., Gailly, N., Khoffi, I., Gasser, L., and Ford, B. En- hancing Bitcoin Security and Performance with Strong Consistency via Collective Signing. In USENIX Security Symposium (2016)

    2016

  36. [44]

    OmniLedger: A Secure, Scale-out, Decentralized Ledger via Sharding

    Kokoris-Kogias, E., Jovanovic, P., Gasser, L., Gailly, N., Syta, E., and Ford, B. OmniLedger: A Secure, Scale-out, Decentralized Ledger via Sharding. In IEEE Symposium on Security and Privacy (2018)

    2018

  37. [45]

    Hawk: The Blockchain Model of Cryptography and Privacy-preserving Smart Contracts

    Kosba, A., Miller, A., Shi, E., Wen, Z., and Papamanthou, C. Hawk: The Blockchain Model of Cryptography and Privacy-preserving Smart Contracts. In IEEE Symposium on Security and Privacy (2016)

    2016

  38. [46]

    teEther: Gnawing at Ethereum to Automatically Exploit Smart Contracts

    Krupp, J., and Rossow, C. teEther: Gnawing at Ethereum to Automatically Exploit Smart Contracts. In USENIX Security Symposium (2018)

    2018

  39. [47]

    Time, Clocks, and the Ordering of Events in a Distributed System

    Lamport, L. Time, Clocks, and the Ordering of Events in a Distributed System. Communications of the ACM (1978)

    1978

  40. [48]

    The Byzantine Generals Problem

    Lamport, L., Shostak, R., and Pease, M. The Byzantine Generals Problem. ACM Transactions on Programming Languages and Systems (TOPLAS) (1982)

    1982

  41. [49]

    Keystone: A Framework for Architecting TEEs

    Lee, D., Kohlbrenner, D., Shinde, S., Song, D., and Asanović, K. Keystone: A Framework for Architecting TEEs. arXiv preprint arXiv:1907.10119 (2019)

    2019 arXiv

  42. [50]

    T., Condie, T., Garofalakis, M., Gay, D

    Loo, B. T., Condie, T., Garofalakis, M., Gay, D. E., Hellerstein, J. M., Maniatis, P., Ramakrishnan, R., Roscoe, T., and Stoica, I. Declarative networking: Language, execution and optimization. In SIGMOD (2006)

    2006

  43. [51]

    Making Smart Contracts Smarter

    Luu, L., Chu, D.-H., Olickel, H., Saxena, P., and Hobor, A. Making Smart Contracts Smarter. In ACM CCS (2016)

    2016

  44. [52]

    A Secure Sharding Protocol for Open Blockchains

    Luu, L., Narayanan, V., Zheng, C., Baweja, K., Gilbert, S., and Saxena, P. A Secure Sharding Protocol for Open Blockchains. In ACM CCS (2016)

    2016

  45. [53]

    Con- currency and Privacy with Payment-channel Networks

    Malavolta, G., Moreno-Sanchez, P., Kate, A., Maffei, M., and Ravi, S. Con- currency and Privacy with Payment-channel Networks. In ACM CCS (2017)

    2017

  46. [54]

    Bitcoin: A Peer-to-Peer Electronic Cash System

    Nakamoto, S. Bitcoin: A Peer-to-Peer Electronic Cash System. https://bitcoin. org/bitcoin.pdf, 2008

    2008

  47. [55]

    Parr, T. Antlr. https://www.antlr.org/, 2014

    2014

  48. [56]

    A Concurrent Perspective on Smart Contracts

    Sergey, I., and Hobor, A. A Concurrent Perspective on Smart Contracts. In Financial Cryptography and Data Security (2017)

    2017

  49. [57]

    Hilti: An abstract execution environment for deep, stateful network traffic analysis

    Sommer, R., V allentin, M., De Carli, L., and Paxson, V. Hilti: An abstract execution environment for deep, stateful network traffic analysis. In IMC (2014)

    2014

  50. [58]

    VAST: A Unified Platform for Interactive Network Forensics

    V allentin, M., Paxson, V., and Sommer, R. VAST: A Unified Platform for Interactive Network Forensics. In USENIX NSDI (2016)

    2016

  51. [59]

    CryptoNote v 2.0

    V an Saberhagen, N. CryptoNote v 2.0. https://cryptonote.org/whitepaper.pdf, 2013

    2013

  52. [60]

    Ethereum: A secure decentralised generalised transaction ledger

    Wood, G. Ethereum: A secure decentralised generalised transaction ledger. Ethereum Project Yellow Paper (2014)

    2014

  53. [61]

    RapidChain: Scaling Blockchain via Full Sharding

    Zamani, M., Movahedi, M., and Raykova, M. RapidChain: Scaling Blockchain via Full Sharding. In ACM CCS (2018)

    2018

  54. [62]

    XCLAIM: Trustless, Interoperable, Cryptocurrency-Backed Assets

    Zamyatin, A., Harz, D., Lind, J., Panayiotou, P., Gervais, A., and Knottenbelt, W. XCLAIM: Trustless, Interoperable, Cryptocurrency-Backed Assets. In IEEE Symposium on Security and Privacy (2019)

    2019

  55. [63]

    Town Crier: An Authenticated Data Feed for Smart Contracts

    Zhang, F., Cecchetti, E., Croman, K., Juels, A., and Shi, E. Town Crier: An Authenticated Data Feed for Smart Contracts. In ACM CCS (2016). A APPENDIX A.1 Specification of ProtNSB and ProtBC The detailed protocol description of ProtNSB and ProtBC is given in Figure 12. We mode...

    2016

Pith tools

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