Pith. sign in

REVIEW 5 major objections 5 minor 180 references

A Survey on Ethereum Systems Security: Vulnerabilities, Attacks and Defenses

T0 review · 5 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 This survey attempts to establish that Ethereum's security landscape can be mapped end-to-end by enumerating 44 vulnerability types, 26 attacks, and 47 defenses and connecting them to root causes and consequences.

desk verdict Useful and systematic reference survey; the 'comprehensive' claim is under-supported by the undocumented selection method, but the taxonomy and cross-referencing earn it a serious referee. read the letter →

arxiv 1908.04507 v1 pith:DDDTLR32 submitted 2019-08-13 cs.CR

Huashan Chen , Marcus Pendleton , Laurent Njilla , Shouhuai Xu This is my paper · ORCID
classification cs.CR
keywords BlockchainEthereumSecuritySmartcontractsVulnerabilitiesAttacksDefenses
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

This paper tries to establish that the security of Ethereum is not an open-ended list of bugs but a structured landscape. The authors systematize 44 types of vulnerabilities, 26 attacks, and 47 defenses, and they connect each attack to the vulnerabilities it exploits and each defense to the vulnerabilities it mitigates. The value of the exercise is practical: a complete map shows which vulnerabilities are open, which attacks cause the largest losses, and where defense effort is concentrated. The paper claims to be the first treatment that covers vulnerabilities, attacks, and defenses together in this relational way, and it draws out insights about root causes, defense gaps, and decentralization.

What carries the argument

The organizing device is the layered model of the Ethereum system: smart contracts and the EVM at the application layer, blockchain data structures at the data layer, PoW consensus and incentives at the consensus layer, the peer-to-peer network at the network layer, and the web, database, cryptographic, and Internet infrastructure as the environment. Every vulnerability is placed in this model, every attack is expressed as a combination of vulnerabilities (written $A_i(V_j, \ldots)$), and every defense is classified as proactive or reactive and then assessed for how many vulnerability types it covers. The relationships drawn between these three sets are what allow the survey to convert an inventory into claims about root causes, attack consequences, and defense gaps.

What would settle it

A documented in-scope Ethereum vulnerability from the surveyed period that cannot be placed in any of the 44 types, or a real attack that cannot be expressed as exploiting a subset of the listed vulnerabilities, would refute the completeness claim.

Watch

Extended reading notes

Core claim

The central claim is that Ethereum's security problems fall into a layered architecture—application, data, consensus, and network layers plus a surrounding environment—and that each known vulnerability can be assigned to a layer and a root cause. Among the 44 vulnerability types, 14 trace to smart-contract programming, 5 to the Solidity language and toolchain, 18 to Ethereum design and implementation, and 7 to human, usability, and networking factors. The survey maps 26 real-world attacks, including the DAO reentrancy attack, the two Parity wallet attacks, under-priced opcode DDoS, eclipse attacks, and environment attacks such as the MyEtherWallet BGP and DNS hijack, onto those vulnerabilities, and classifies consequences as unauthorized code execution, denial of service, unfair income, double-spending, private key leakage, or webpage manipulation. Its headline findings include that ten of the smart-contract programming vulnerabilities have no traditional-software counterpart, that the largest single loss ($280M) came from a DoS attack that killed a shared library, and that reactive defenses cover only a few vulnerability types while proactive best practices cover many.

Load-bearing premise

The survey's completeness claim rests on the assumption that restricting attention to Solidity smart contracts, the Geth and Parity clients, and a five-layer model of Ethereum plus its environment captures the full space of what can be attacked.

Editorial extensions

If this is right

  • If the map is complete, then any future Ethereum vulnerability should be assignable to one of the 44 types or reveal a new type; the taxonomy gives a concrete place to look first.
  • Because application-layer attacks caused the largest financial losses, the paper's interpretation is that securing smart-contract logic and DApp interfaces is where protection of value is most needed.
  • Reactive defenses cover only four vulnerability types, all already covered by proactive defenses, so runtime monitoring cannot currently be the backstop for unknown vulnerabilities.
  • Nineteen vulnerabilities have zero or one dedicated defense, mostly in platform design and the environment; those are the areas where the survey predicts the next successful exploits are most likely.
  • DApps using centralized web interfaces inherit classic web vulnerabilities regardless of blockchain decentralization, so the decentralization property is only as strong as the weakest front-end component.

Reading between the lines

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

  • One testable extension would be to run the same layer-and-root-cause taxonomy on post-2019 Ethereum—proof-of-stake, fee-market changes, layer-2 systems, and newer languages—and ask whether the four root-cause classes still absorb the new vulnerabilities.
  • The defense-investment analysis implies a prediction: after a future large Ethereum financial loss, defenses for that vulnerability type will proliferate, because past effort has followed losses rather than anticipated them.
  • The four principles (call, data, resource, and tool control) could be turned into a checklist and evaluated against a vulnerability-scanner corpus: contracts following the checklist should show fewer findings across the 22 vulnerability types the best practices claim to cover.
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

5 major / 5 minor

Summary. This paper is a survey of security issues in the Ethereum ecosystem, organized around a five-layer architecture (application, data, consensus, network, environment). It enumerates 44 vulnerabilities (V1-V44), 26 attacks (A1-A26), and 47 defenses (D1-D47), and links these through root-cause analysis, attack-consequence analysis, and defense-capability/defense-investment analyses. The paper also distills 15 insights and suggests future research directions, with a short tutorial-style review of Ethereum's design. The central claim is that this is the first systematic and comprehensive treatment of Ethereum systems security, filling a gap left by prior surveys.

Significance. The survey has clear value as a reference: the V/A/D labeling is internally consistent, the layered decomposition is didactic, and the systematization of best practices into a small number of principles (Figure 15) plus the attack-to-vulnerability mapping (Figure 14) are useful for practitioners and newcomers. The defense-capability matrix in Table III consolidates a dispersed literature and will likely save subsequent researchers considerable effort. The paper does not ship machine-checked proofs or code (it is a survey), but its explicit cross-referencing of 44/26/47 items and its discussion of vulnerability status (eliminated / best-practice / open) are strengths. The main weakness is that the claimed comprehensiveness is not backed by a reproducible methodology, which limits confidence in the enumeration and in the associated quantitative claims.

major comments (5)
  1. [Section II.B] The central claim of being the first systematic and comprehensive treatment (Abstract and Section I.A) is underdetermined by the methodology. Section II.B.2 describes only a layered architecture and three security perspectives; it does not state search strategy, source databases, inclusion/exclusion criteria, time window, or an independent corpus against which completeness could be checked. Section II.B.1 explicitly restricts the scope to Solidity and to the Geth/Parity clients, yet the title and abstract refer unqualifiedly to Ethereum systems security. As written, the reader cannot distinguish between "not in the universe" and "not found." I request a methodology subsection with selection criteria and a limitation paragraph, or, alternatively, a softening of the "comprehensive" claims to the selected scope.
  2. [Section I.B, Table I] The comparison with prior surveys relies on raw counts (44 vs. 12/20/11) without demonstrating coverage. To substantiate the claim of a filling-the-void survey, the authors should provide a mapping showing how the vulnerability types from Atzei et al. [12], Li et al. [13], and Zhu et al. [14] map onto V1-V44, and ideally test V1-V44 against an independent pre-2019 incident corpus (e.g., SWC registry entries and known CVEs affecting smart contracts). Without such a recall test, the claim that the taxonomy is comprehensive is not supported.
  3. [Section V.C and Table III] The defense-capability analysis (e.g., proactive defenses cover 29 vulnerabilities, reactive defenses cover 4, and the subset relations stated in the text) depends on the authors' manual assignment of each defense to the vulnerabilities it can detect or mitigate. The paper does not state the evidence used for these assignments, such as which tool paper claims which detection capability, nor does it discuss false-positive/false-negative rates. Since Insights 10 and 12 are drawn directly from this mapping, the analysis should be framed explicitly as expert judgment, and the assignment criteria should be stated so that readers can evaluate or reproduce the mapping.
  4. [Section IV and Table II] Financial loss figures are taken from secondary or non-uniform sources (e.g., news reports) without specifying whether the amounts are denominated in USD at the time of the attack or at the time of writing. This matters for Insight 6 and Insight 8, which rank attacks by financial impact. Please clarify the valuation basis or add caveats to the affected claims.
  5. [Section VI.B] The recommendation of "cybersecurity dynamics" as a future methodology is supported almost entirely by the authors' own prior work [166]-[174], and the text explicitly states that no blockchain-specific results exist yet. This is not a correctness problem, but it reads as a self-promotional aside in a survey that is otherwise neutral. Either remove this recommendation or hedge it with a broader discussion of alternative formal methodologies.
minor comments (5)
  1. [Section V.C] The phrase "Vern diagram" on the page containing Figure 18 should be "Venn diagram."
  2. [References] Reference [13] is missing its author list and is nearly identical to reference [90]; the full citation should be supplied.
  3. [Section II.A.2] In the transaction description, "anther EOA" should be "another EOA."
  4. [Section II.A.1] The phrase "A Ethereum-based token" should be "An Ethereum-based token."
  5. [Figure 5] The legend symbols for vulnerability status may be hard to distinguish in grayscale; adding text labels (e.g., "eliminated", "best practice", "open") would improve readability.

Circularity Check

0 steps flagged · score 2.0 of 10

No significant circularity: survey content is externally sourced; self-citations appear only in future-directions discussion and are not load-bearing.

full rationale

This paper is a literature survey rather than a derivation, and its central content is an enumeration of 44 vulnerabilities, 26 attacks, and 47 defenses compiled from external primary sources (e.g., Atzei et al., DAO/Parity incident reports, academic tools such as Oyente and Securify). The taxonomy and insights follow from the cited reports and are not defined in terms of the survey's own conclusions. No parameter is fitted, no quantity is renamed as a prediction, and no uniqueness theorem from the authors' prior work is invoked to force a choice. The only notable self-citations appear in the future-directions section, where 'cybersecurity dynamics' [166]-[174] is recommended as a promising methodology and metrics references [175]-[181] include authors' own prior work. The paper itself admits that no published blockchain-specific applications of cybersecurity dynamics exist, and these citations are recommendations for future research rather than premises used to establish the survey's classification. The scope restriction to Solidity and Geth/Parity (Section II.B.1) and the absence of a formal search protocol (Section II.B.2) limit the defensibility of the 'comprehensive' claim, but this is a methodological completeness limitation, not circular reasoning: the enumeration is not derived from the claim of comprehensiveness. Therefore the central survey content is self-contained against external benchmarks, and the minor future-direction self-citations do not make the derivation circular.

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

The survey does not fit parameters or introduce entities; it is an exposition built on prior literature. Its central claims rest on the completeness of its cited sources and the validity of its classification scheme.

assumptions (3)
  • domain assumption The layered architecture (application, data, consensus, network, environment) is an appropriate complete model for organizing Ethereum security issues.
    Used throughout Sections III-V to categorize all vulnerabilities, attacks, and defenses; if this decomposition is not exhaustive, the survey's comprehensiveness claim fails.
  • domain assumption The information in the cited primary sources and news reports (e.g., financial loss figures) is accurate.
    The survey does not verify attack losses or vulnerability details independently; it relies on the accuracy of references such as [8]-[11], [39]-[118].
  • domain assumption Solidity and Geth/Parity are representative of Ethereum as a whole.
    Scope is limited to these languages/clients in Section II.B.1; the survey's 'comprehensive' claim implicitly assumes this scope is sufficient.

how reviews work

0 comments
Cite this review

Pith. "Pith review of A Survey on Ethereum Systems Security: Vulnerabilities, Attacks and Defenses." pith.science (2026). https://pith.science/paper/DDDTLR32

@misc{pith2026190804507,
  author       = {Pith},
  title        = {Pith review of: A Survey on Ethereum Systems Security: Vulnerabilities, Attacks and Defenses},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/DDDTLR32}},
  note         = {Machine review of arXiv:1908.04507}
}
read the original abstract

The blockchain technology is believed by many to be a game changer in many application domains, especially financial applications. While the first generation of blockchain technology (i.e., Blockchain 1.0) is almost exclusively used for cryptocurrency purposes, the second generation (i.e., Blockchain 2.0), as represented by Ethereum, is an open and decentralized platform enabling a new paradigm of computing --- Decentralized Applications (DApps) running on top of blockchains. The rich applications and semantics of DApps inevitably introduce many security vulnerabilities, which have no counterparts in pure cryptocurrency systems like Bitcoin. Since Ethereum is a new, yet complex, system, it is imperative to have a systematic and comprehensive understanding on its security from a holistic perspective, which is unavailable. To the best of our knowledge, the present survey, which can also be used as a tutorial, fills this void. In particular, we systematize three aspects of Ethereum systems security: vulnerabilities, attacks, and defenses. We draw insights into, among other things, vulnerability root causes, attack consequences, and defense capabilities, which shed light on future research directions.

Figures

Figures reproduced from arXiv: 1908.04507 by the authors.

Figure 1
Figure 1. Architecture of the Ethereum blockchain and its envi [PITH_FULL_IMAGE:figures/full_fig_p004_1.png] view at source ↗
Figure 2
Figure 2. An illustration of the lifecycle of an Ethereum transaction. [PITH_FULL_IMAGE:figures/full_fig_p005_2.png] view at source ↗
Figure 3
Figure 3. Storage structure of Ethereum blockchain. [PITH_FULL_IMAGE:figures/full_fig_p005_3.png] view at source ↗
Figures from the paper (16 more)
Figure 4
Figure 4. Figure 4: A sub-tree of an Ethereum blockchain (adapted from [PITH_FULL_IMAGE:figures/full_fig_p005_4.png]
Figure 5
Figure 5. Figure 5: A classification of Ethereum vulnerabilities and their state-of-the-art treatments ( [PITH_FULL_IMAGE:figures/full_fig_p007_5.png]
Figure 6
Figure 6. Figure 6: The tx.origin vulnerability and its exploitations [PITH_FULL_IMAGE:figures/full_fig_p007_6.png]
Figure 7
Figure 7. Figure 7: The type casts vulnerability. 18) Type casts (18): This vulnerability was first reported in [12]. Recall that a contract written in the Solidity lan￾guage can call another contract by directly referencing to the callee contract’s instance. As illustrated in [PITH_FUL…
Figure 9
Figure 9. Figure 9: Simplified vulnerable Parity multisignature wallet. [PITH_FULL_IMAGE:figures/full_fig_p014_9.png]
Figure 8
Figure 8. Figure 8: The DAO attack exploiting the reentrancy vulnerability [PITH_FULL_IMAGE:figures/full_fig_p014_8.png]
Figure 10
Figure 10. Figure 10: The vulnerable function in BECToken. 4) GovernMental attacks (5 , 6 , 7 , and 8 ): The contract GovernMental was an array-based pyramid Ponzi scheme, where the last participant wins a jackpot if no one joins the scheme within 12 hours after the last participant [1…
Figure 11
Figure 11. Figure 11: Simplified HYIP contract and attack. 6) Fomo3D attacks (10 and 11): The contract Fomo3D was an extremely popular Ponzi game in year 2018, where the last participant who buys a key before the timer runs out won the jackpot. The price of keys gradually grows with the …
Figure 12
Figure 12. Figure 12: A snippet source code of Fomo3D. 7) ERC-20 signature replay attack (12): This attack, which was first reported in [116], exploits the insufficient sig￾nature information vulnerability (13). When a user transfers ERC-20 tokens, the user must have enough Ether to pay …
Figure 13
Figure 13. Figure 13: Cross-contract replay attack via transferProxy(). that exploited the indistinguishable chains vulnerability (27), exchanges participating in both chains (e.g., Coinbase and Yunbi) lost a large amount of money [85]. 2) Under-priced DDoS attacks (15 and 16): These at…
Figure 14
Figure 14. Figure 14: The relation between vulnerabilities, attacks and attack consequences. [PITH_FULL_IMAGE:figures/full_fig_p019_14.png]
Figure 15
Figure 15. Figure 15: Best practices and principles for guiding contract development. [PITH_FULL_IMAGE:figures/full_fig_p021_15.png]
Figure 16
Figure 16. Figure 16: Workflow of vulnerability detector Securify. [PITH_FULL_IMAGE:figures/full_fig_p021_16.png]
Figure 17
Figure 17. Figure 17: Theorem proving for verifying smart contracts. [PITH_FULL_IMAGE:figures/full_fig_p022_17.png]
Figure 18
Figure 18. Figure 18: Vern diagram representation of defenses against [PITH_FULL_IMAGE:figures/full_fig_p023_18.png]
Figure 19
Figure 19. Figure 19: The number defenses with respect to each vulnerabil [PITH_FULL_IMAGE:figures/full_fig_p024_19.png]

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

180 extracted references · 66 canonical work pages

  1. [12]

    Asurveyofattacksonethereum smart contracts (sok),

    N.Atzei,M.Bartoletti,andT.Cimoli,“Asurveyofattacksonethereum smart contracts (sok),” inPrinciples of Security and Trust, pp. 164–186, Springer, 2017

    2017

  2. [13]

    A survey on the security of blockchain systems,

    “A survey on the security of blockchain systems,”Future Generation Computer Systems, 2017

    2017

  3. [14]

    Research on the Security of Blockchain Data: A Survey

    L. Zhu, B. Zheng, M. Shen, S. Yu, F. Gao, H. Li, K. Shi, and K. Gai, “Research on the security of blockchain data: A survey,”CoRR, vol. abs/1812.02009, 2018

    work page Pith review arXiv 2018

  4. [166]

    Cybersecurity dynamics,

    S. Xu, “Cybersecurity dynamics,” inProc. Symposium on the Science of Security (HotSoS’14), pp. 14:1–14:2, 2014. 29

    work page 2014

  5. [174]

    Unified preventive and reactive cyber defense dynamics is still globally convergent,

    Z. Lin, W. Lu, and S. Xu, “Unified preventive and reactive cyber defense dynamics is still globally convergent,”IEEE/ACM Trans. Netw., vol. 27, no. 3, pp. 1098–1111, 2019

    work page 2019

  6. [1]

    Bitcoin: A peer-to-peer electronic cash system,

    S. Nakamoto, “Bitcoin: A peer-to-peer electronic cash system,” 2008

    2008

  7. [2]

    Blind signatures for untraceable payments,

    D. Chaum, “Blind signatures for untraceable payments,” inAdvances in Cryptology: Proceedings of CRYPTO ’82, Santa Barbara, California, USA, August 23-25, 1982., pp. 199–203, 1982. 26

    1982

  8. [3]

    Impossibility of distributed consensus with one faulty process,

    M. J. Fischer, N. A. Lynch, and M. Paterson, “Impossibility of distributed consensus with one faulty process,”J. ACM, vol. 32, no. 2, pp. 374–382, 1985

    1985

Show all 180 references
  1. [4]

    Pricing via processing or combatting junk mail,

    C. Dwork and M. Naor, “Pricing via processing or combatting junk mail,” inAdvances in Cryptology - CRYPTO ’92, 12th Annual In- ternational Cryptology Conference, Santa Barbara, California, USA, August 16-20, 1992, Proceedings, pp. 139–147, 1992

    1992

  2. [5]

    Ethereum: A secure decentralised generalised transaction ledger,

    G. Wood, “Ethereum: A secure decentralised generalised transaction ledger,”Ethereum project yellow paper, vol. 151, pp. 1–32, 2014

    2014

  3. [6]

    Ethereum (eth) blockchain explorer

    “Ethereum (eth) blockchain explorer.” https://etherscan.io/

  4. [7]

    Smart contract analytics

    “Smart contract analytics.” https://stat.bloxy.info/superset/dashboard/ smart_contracts/?standalone=true

  5. [8]

    Dao at v1.0

    “Dao at v1.0.” https://github.com/slockit/DAO/tree/v1.0

  6. [9]

    The parity wallet hack explained – zeppelin blog

    “The parity wallet hack explained – zeppelin blog.” https://blog. zeppelin.solutions/on-the-parity-wallet-multisig-hack-405a8c12e8f7

  7. [10]

    Bgp leaks and cryptocurrencies

    “Bgp leaks and cryptocurrencies.” https://blog.cloudflare.com/bgp- leaks-and-crypto-currencies/

  8. [11]

    Solidity recommendations - ethereum smart contract best prac- tices

    “Solidity recommendations - ethereum smart contract best prac- tices.” https://consensys.github.io/smart-contract-best-practices/ recommendations/

  9. [16]

    Towards safer smart contracts: A survey of languages and verification methods,

    D. Harz and W. Knottenbelt, “Towards safer smart contracts: A survey of languages and verification methods,” arXiv preprint arXiv:1809.09805, 2018

    2018 arXiv

  10. [17]

    A survey of tools for analyzing ethereum smart contracts,

    M. Di Angelo and G. Salzer, “A survey of tools for analyzing ethereum smart contracts,” in2019 IEEE International Conference on Decentralized Applications and Infrastructures (DAPPCON), IEEE, 2019

    2019

  11. [18]

    Security and privacy on blockchain,

    R. Zhang, R. Xue, and L. Liu, “Security and privacy on blockchain,” CoRR (to appear in ACM Computing Survey), vol. abs/1903.07602, 2019

    1903 arXiv

  12. [19]

    Blockchain consensus protocols in the wild,

    C. Cachin and M. Vukolic, “Blockchain consensus protocols in the wild,”CoRR, vol. abs/1707.01873, 2017

    2017 arXiv

  13. [20]

    Consensus in the age of blockchains,

    S. Bano, A. Sonnino, M. Al-Bassam, S. Azouvi, P. McCorry, S. Meik- lejohn, and G. Danezis, “Consensus in the age of blockchains,”CoRR, vol. abs/1711.03936, 2017

    2017 arXiv

  14. [21]

    A survey on consensus mechanisms and mining management in blockchain networks,

    W. Wang, D. T. Hoang, Z. Xiong, D. Niyato, P. Wang, P. Hu, and Y. Wen, “A survey on consensus mechanisms and mining management in blockchain networks,”CoRR, vol. abs/1805.02707, 2018

    2018 arXiv

  15. [22]

    A survey of distributed consensus protocols for blockchain networks,

    Y. Xiao, N. Zhang, W. Lou, and Y. T. Hou, “A survey of distributed consensus protocols for blockchain networks,” CoRR, vol. abs/1904.04098, 2019

    1904 arXiv

  16. [23]

    Sok: Research perspectives and challenges for bitcoin and cryptocurrencies,

    J. Bonneau, A. Miller, J. Clark, A. Narayanan, J. A. Kroll, and E. W. Felten, “Sok: Research perspectives and challenges for bitcoin and cryptocurrencies,” in2015 IEEE Symposium on Security and Privacy, pp. 104–121, May 2015

    2015

  17. [24]

    A survey on security and privacy issues of bitcoin,

    M. Conti, E. Sandeep Kumar, C. Lal, and S. Ruj, “A survey on security and privacy issues of bitcoin,”IEEE Communications Surveys Tutorials, vol. 20, no. 4, pp. 3416–3452, 2018

    2018

  18. [25]

    Bitcoin and beyond: A technical survey on decentralized digital currencies,

    F. Tschorsch and B. Scheuermann, “Bitcoin and beyond: A technical survey on decentralized digital currencies,” IEEE Communications Surveys Tutorials, vol. 18, no. 3, pp. 2084–2123, 2016

    2016

  19. [26]

    State of the dapps — dapp statistics

    “State of the dapps — dapp statistics.” https://www.stateofthedapps. com/stats

  20. [27]

    Erc-20 token standard | ethereum improvement proposals

    “Erc-20 token standard | ethereum improvement proposals.” https:// eips.ethereum.org/EIPS/eip-20

  21. [28]

    Cryptocurrencies, smart contracts, and artificial intel- ligence,

    S. Omohundro, “Cryptocurrencies, smart contracts, and artificial intel- ligence,”AI matters, vol. 1, no. 2, pp. 19–21, 2014

    2014

  22. [29]

    Patricia tree

    “Patricia tree.” https://xlinux.nist.gov/dads/HTML/patriciatree.html

  23. [30]

    Secure high-rate transaction processing in bitcoin,

    Y. Sompolinsky and A. Zohar, “Secure high-rate transaction processing in bitcoin,” inInternational Conference on Financial Cryptography and Data Security, pp. 507–527, Springer, 2015

    2015

  24. [31]

    The bitcoin backbone pro- tocol: Analysis and applications,

    J. Garay, A. Kiayias, and N. Leonardos, “The bitcoin backbone pro- tocol: Analysis and applications,” inAnnual International Conference on the Theory and Applications of Cryptographic Techniques, pp. 281– 310, Springer, 2015

    2015

  25. [32]

    Asurveyonconsensusmechanismsandminingstrategy management in blockchain networks,

    W. Wang, D. T. Hoang, P. Hu, Z. Xiong, D. Niyato, P. Wang, Y. Wen, andD.I.Kim,“Asurveyonconsensusmechanismsandminingstrategy management in blockchain networks,”IEEE Access, vol. 7, pp. 22328– 22370, 2019

    2019

  26. [33]

    Selfish mining in ethereum,

    J. Niu and C. Feng, “Selfish mining in ethereum,”arXiv preprint arXiv:1901.04620, 2019

    1901 arXiv

  27. [34]

    Kim,Measuring Ethereum’s peer-to-peer network

    S. Kim,Measuring Ethereum’s peer-to-peer network. PhD thesis, 2017

    2017

  28. [35]

    Low-resource eclipse attacks on ethereum’s peer-to-peer network.,

    Y. Marcus, E. Heilman, and S. Goldberg, “Low-resource eclipse attacks on ethereum’s peer-to-peer network.,”IACR Cryptology ePrint Archive, vol. 2018, p. 236, 2018

    2018

  29. [36]

    devp2p/eth.md at master· ethereum/devp2p · github

    “devp2p/eth.md at master· ethereum/devp2p · github.” https://github. com/ethereum/devp2p/blob/master/caps/eth.md

  30. [37]

    Github - ethereum/go-ethereum: Official go implementation of the ethereum protocol

    “Github - ethereum/go-ethereum: Official go implementation of the ethereum protocol.” https://github.com/ethereum/go-ethereum

  31. [38]

    Github - paritytech/parity-ethereum: The fast, light, and robust evm and wasm client

    “Github - paritytech/parity-ethereum: The fast, light, and robust evm and wasm client..” https://github.com/paritytech/parity-ethereum

  32. [39]

    Analysis of the dao exploit

    “Analysis of the dao exploit.” http://hackingdistributed.com/2016/06/ 18/analysis-of-the-dao-exploit/

    2016

  33. [40]

    Sereum: Protecting existing smart contracts against re-entrancy attacks,

    M. Rodler, W. Li, G. O. Karame, and L. Davi, “Sereum: Protecting existing smart contracts against re-entrancy attacks,”arXiv preprint arXiv:1812.05934, 2018

    2018 arXiv

  34. [41]

    Ethereum smart contract best practices

    “Ethereum smart contract best practices.” https://consensys.github.io/ smart-contract-best-practices/

  35. [42]

    A hacker stole $31m of ether — how it happened, and what it means for ethereum

    “A hacker stole $31m of ether — how it happened, and what it means for ethereum.” https://medium.freecodecamp.org/a-hacker-stole- 31m-of-ether-how-it-happened-and-what-it-means-for-ethereum- 9e5dc29e33ce

  36. [43]

    teether: Gnawing at ethereum to automati- cally exploit smart contracts,

    J. Krupp and C. Rossow, “teether: Gnawing at ethereum to automati- cally exploit smart contracts,” in27th {USENIX} Security Symposium ({USENIX} Security 18), pp. 1317–1333, 2018

    2018

  37. [44]

    Comprehensive list of known attack vectors and common anti- patterns

    “Comprehensive list of known attack vectors and common anti- patterns.” https://github.com/sigp/solidity-security-blog

  38. [45]

    Security alert | parity technologies

    “Security alert | parity technologies.” https://www.parity.io/security- alert-2/

  39. [46]

    Contractfuzzer: Fuzzing smart contracts for vulnerability detection,

    B. Jiang, Y. Liu, and W. Chan, “Contractfuzzer: Fuzzing smart contracts for vulnerability detection,” in Proceedings of the 33rd ACM/IEEE International Conference on Automated Software Engineer- ing, pp. 259–269, ACM, 2018

    2018

  40. [47]

    Safety· ethereum/wiki wiki · github

    “Safety· ethereum/wiki wiki · github.” https://github.com/ethereum/ wiki/wiki/Safety#favor-pull-over-push-for-external-calls

  41. [48]

    Nvd - cve-2018-10299

    “Nvd - cve-2018-10299.” https://nvd.nist.gov/vuln/detail/CVE-2018- 10299

    2018

  42. [49]

    Safemath

    “Safemath.” https://github.com/OpenZeppelin/openzeppelin-solidity/ blob/master/contracts/math/SafeMath.sol

  43. [50]

    How to secure your smart contracts: 6 solidity vulnerabilities and how to avoid them (part 2)

    “How to secure your smart contracts: 6 solidity vulnerabilities and how to avoid them (part 2).” https://medium.com/loom-network/how- to-secure-your-smart-contracts-6-solidity-vulnerabilities-and-how-to- avoid-them-part-2-730db0aa4834

  44. [51]

    Tx.origin and ethereum oh my!

    “Tx.origin and ethereum oh my!.” https://vessenes.com/tx-origin-and- ethereum-oh-my/

  45. [52]

    Security considerations — solidity 0.5.10 documentation

    “Security considerations — solidity 0.5.10 documentation.” https: //solidity.readthedocs.io/en/develop/security-considerations.html#tx- origin

  46. [53]

    Solidity v0.5.0 breaking changes — solidity 0.5.0 documentation

    “Solidity v0.5.0 breaking changes — solidity 0.5.0 documentation.” https://solidity.readthedocs.io/en/v0.5.0/050-breaking-changes.html

  47. [54]

    Smart contract weakness classification and test cases

    “Smart contract weakness classification and test cases.” https:// smartcontractsecurity.github.io/SWC-registry/

  48. [55]

    Finding the greedy, prodigal, and suicidal contracts at scale,

    I. Nikoli/uni0107, A. Kolluri, I. Sergey, P. Saxena, and A. Hobor, “Finding the greedy, prodigal, and suicidal contracts at scale,” inProceedings of the 34th Annual Computer Security Applications Conference, pp. 653–663, ACM, 2018

    2018

  49. [56]

    Step by step towards creating a safe smart contract: Lessons and insights from a cryptocurrency lab,

    K. Delmolino, M. Arnett, A. Kosba, A. Miller, and E. Shi, “Step by step towards creating a safe smart contract: Lessons and insights from a cryptocurrency lab,” inInternational Conference on Financial Cryptography and Data Security, pp. 79–94, Springer, 2016

    2016

  50. [57]

    Replay attacks on ethereum smart contracts

    “Replay attacks on ethereum smart contracts.” https://github.com/ nkbai/defcon26/tree/master/docs

  51. [58]

    Solidity by example — solidity 0.5.3 documentation

    “Solidity by example — solidity 0.5.3 documentation.” https://solidity. readthedocs.io/en/v0.5.3/solidity-by-example.html#micropayment- channel

  52. [59]

    Programtheblockchain|signingandverifyingmessagesinethereum

    “Programtheblockchain|signingandverifyingmessagesinethereum.” https://programtheblockchain.com/posts/2018/02/17/signing-and- verifying-messages-in-ethereum/

    2018

  53. [60]

    Governmental’s 1100 eth jackpot payout is stuck because it uses too much gas : ethereum

    “Governmental’s 1100 eth jackpot payout is stuck because it uses too much gas : ethereum.” https://www.reddit.com/r/ethereum/comments/ 4ghzhv/governmentals_1100_eth_jackpot_payout_is_stuck/. 27

  54. [61]

    Known attacks - ethereum smart contract best practices

    “Known attacks - ethereum smart contract best practices.” https: //consensys.github.io/smart-contract-best-practices/known_attacks/

  55. [62]

    Madmax: Surviving out-of-gas conditions in ethereum smart contracts,

    N. Grech, M. Kong, A. Jurisevic, L. Brent, B. Scholz, and Y. Smarag- dakis, “Madmax: Surviving out-of-gas conditions in ethereum smart contracts,”Proceedings of the ACM on Programming Languages , vol. 2, no. OOPSLA, p. 116, 2018

    2018

  56. [63]

    Making smart contracts smarter,

    L. Luu, D.-H. Chu, H. Olickel, P. Saxena, and A. Hobor, “Making smart contracts smarter,” inProceedings of the 2016 ACM SIGSAC Conference on Computer and Communications Security, pp. 254–269, ACM, 2016

    2016

  57. [64]

    Zeus: Analyzing safety of smart contracts,

    S. Kalra, S. Goel, M. Dhawan, and S. Sharma, “Zeus: Analyzing safety of smart contracts,” NDSS, 2018

    2018

  58. [65]

    Storage allocation exploits in ethereum smart contracts

    “Storage allocation exploits in ethereum smart contracts.” https: //medium.com/cryptronics/storage-allocation-exploits-in-ethereum- smart-contracts-16c2aa312743

  59. [66]

    Storage pointers in solidity

    “Storage pointers in solidity.” https://blog.b9lab.com/storage-pointers- in-solidity-7dcfaa536089

  60. [67]

    Ethereum accounts, addresses and contracts

    “Ethereum accounts, addresses and contracts.” https://etherscan. io / address / 0xe82719202e5965Cf5D9B6673B7503a3b92DE20be # contracts

  61. [68]

    ‘constructor’ modifier· issue #3196 · ethereum/solidity · github

    “‘constructor’ modifier· issue #3196 · ethereum/solidity · github.” https://github.com/ethereum/solidity/issues/3196

  62. [69]

    Release version 0.4.22· ethereum/solidity · github

    “Release version 0.4.22· ethereum/solidity · github.” https://github. com/ethereum/solidity/releases/tag/v0.4.22

  63. [70]

    How to find $10m just by reading the blockchain

    “How to find $10m just by reading the blockchain.” https://medium. com/golem-project/how-to-find-10m-by-just-reading-blockchain- 6ae9d39fcd95

  64. [71]

    The erc20 short address attack explained

    “The erc20 short address attack explained.” https://vessenes.com/the- erc20-short-address-attack-explained/

  65. [72]

    Worry-some bug / exploit with erc20 token transactions from ex- changes : ethereum

    “Worry-some bug / exploit with erc20 token transactions from ex- changes : ethereum.” https://www.reddit.com/r/ethereum/comments/ 63s917/worrysome_bug_exploit_with_erc20_token/dfwmhc3/

  66. [73]

    Ethereum analysis: Gas economics and proof of work

    “Ethereum analysis: Gas economics and proof of work.” https://github. com/LeastAuthority/ethereum-analyses

  67. [74]

    Eips/eip-150.md at master· ethereum/eips · github

    “Eips/eip-150.md at master· ethereum/eips · github.” https://github. com/ethereum/EIPs/blob/master/EIPS/eip-150.md

  68. [75]

    Transaction spam attack: Next steps

    “Transaction spam attack: Next steps.” https://blog.ethereum.org/2016/ 09/22/transaction-spam-attack-next-steps/

    2016

  69. [76]

    A state clearing faq

    “A state clearing faq.” https://www.reddit.com/r/ethereum/comments/ 5es5g4/a_state_clearing_faq/?st=iw2e1mwo&sh=fa7768&depth=1

  70. [77]

    An adaptive gas cost mechanism for ethereum to defend against under-priced dos attacks,

    T. Chen, X. Li, Y. Wang, J. Chen, Z. Li, X. Luo, M. H. Au, and X. Zhang, “An adaptive gas cost mechanism for ethereum to defend against under-priced dos attacks,” inInternational Conference on Information Security Practice and Experience, pp. 3–24, Springer, 2017

    2017

  71. [78]

    How can i securely generate a random number in my smart contract? - ethereum stack exchange

    “How can i securely generate a random number in my smart contract? - ethereum stack exchange.” https://ethereum.stackexchange.com/ questions/191/how-can-i-securely-generate-a-random-number-in-my- smart-contract

  72. [79]

    To sink frontrunners, send in the submarines

    “To sink frontrunners, send in the submarines.” http : //hackingdistributed.com/2017/08/28/submarine-sends/

    2017

  73. [80]

    Predicting random numbers in ethereum smart contracts

    “Predicting random numbers in ethereum smart contracts.” https: //blog.positive.com/predicting-random-numbers-in-ethereum-smart- contracts-e5358c6b8620

  74. [81]

    Breaking randomness in the ethereum universe [part 1] - secu- rity boulevard

    “Breaking randomness in the ethereum universe [part 1] - secu- rity boulevard.” https://securityboulevard.com/2018/06/breaking- randomness-in-the-ethereum-universe-part-1/

    2018

  75. [82]

    Randomness

    “Randomness.” https://github.com/fravoll/solidity-patterns/blob/ master/docs/randomness.md

  76. [83]

    “Oracle.” https://github.com/fravoll/solidity-patterns/blob/master/docs/ oracle.md

  77. [84]

    Randao: A dao working as rng of ethereum

    “Randao: A dao working as rng of ethereum.” https://github.com/ randao/randao

  78. [85]

    Rise of replay attacks intensifies ethereum divide - coindesk

    “Rise of replay attacks intensifies ethereum divide - coindesk.” https: //www.coindesk.com/rise-replay-attacks-ethereum-divide

  79. [86]

    Eips/eip-155

    “Eips/eip-155..” https://github.com/ethereum/EIPs/blob/master/EIPS/ eip-155.md

  80. [87]

    Eip-161, state trie clearing

    “Eip-161, state trie clearing.” https://github.com/ethereum/EIPs/blob/ master/EIPS/eip-161.md

  81. [88]

    Nonoutsourceable scratch- off puzzles to discourage bitcoin mining coalitions,

    A. Miller, A. Kosba, J. Katz, and E. Shi, “Nonoutsourceable scratch- off puzzles to discourage bitcoin mining coalitions,” inProceedings of the 22nd ACM SIGSAC Conference on Computer and Communications Security, pp. 680–691, ACM, 2015

    2015

  82. [89]

    (short paper) piecework: Generalized outsourcing control for proofs of work,

    P. Daian, I. Eyal, A. Juels, and E. G. Sirer, “(short paper) piecework: Generalized outsourcing control for proofs of work,” inInternational Conference on Financial Cryptography and Data Security, pp. 182– 190, Springer, 2017

    2017

  83. [90]

    A survey on the security of blockchain systems,

    X. Li, P. Jiang, T. Chen, X. Luo, and Q. Wen, “A survey on the security of blockchain systems,”Future Generation Computer Systems, 2017

    2017

  84. [91]

    Exploring the attack surface of blockchain: A systematic overview,

    M. Saad, J. Spaulding, L. Njilla, C. Kamhoua, S. Shetty, D. Nyang, and A. Mohaisen, “Exploring the attack surface of blockchain: A systematic overview,”arXiv preprint arXiv:1904.03487, 2019

    1904 arXiv

  85. [92]

    From blockchain consensus back to byzantine consensus,

    V. Gramoli, “From blockchain consensus back to byzantine consensus,” Future Generation Computer Systems, 2017

    2017

  86. [93]

    Impossibility of distributed consensus with one faulty process.,

    M. J. Fischer, N. A. Lynch, and M. S. Paterson, “Impossibility of distributed consensus with one faulty process.,” tech. rep., MAS- SACHUSETTS INST OF TECH CAMBRIDGE LAB FOR COM- PUTER SCIENCE, 1982

    1982

  87. [94]

    The $3 million winner of fomo3d is still playing to win - longhash

    “The $3 million winner of fomo3d is still playing to win - longhash.” https://www.longhash.com/news/the-3-million-winner-of-fomo3d-is- still-playing-to-win

  88. [95]

    On the security and performance of proof of work blockchains,

    A. Gervais, G. O. Karame, K. Wüst, V. Glykantzis, H. Ritzdorf, and S. Capkun, “On the security and performance of proof of work blockchains,” inProceedings of the 2016 ACM SIGSAC Conference on Computer and Communications Security, pp. 3–16, ACM, 2016

    2016

  89. [96]

    The impact of uncle rewards on selfish mining in ethereum,

    F. Ritz and A. Zugenmaier, “The impact of uncle rewards on selfish mining in ethereum,” in2018 IEEE European Symposium on Security and Privacy Workshops (EuroS&PW), pp. 50–57, IEEE, 2018

    2018

  90. [97]

    Kademlia: A peer-to-peer informa- tion system based on the xor metric,

    P. Maymounkov and D. Mazieres, “Kademlia: A peer-to-peer informa- tion system based on the xor metric,” inInternational Workshop on Peer-to-Peer Systems, pp. 53–65, Springer, 2002

    2002

  91. [98]

    Measuring ethereum network peers,

    S. K. Kim, Z. Ma, S. Murali, J. Mason, A. Miller, and M. Bailey, “Measuring ethereum network peers,” inProceedings of the Internet Measurement Conference 2018, pp. 91–104, ACM, 2018

    2018

  92. [99]

    Ethereum eclipse attacks,

    K. Wüst and A. Gervais, “Ethereum eclipse attacks,” tech. rep., ETH Zurich, 2016

    2016

  93. [100]

    Billions of tokens theft case cause by eth ecological defects

    “Billions of tokens theft case cause by eth ecological defects.” https: //mp.weixin.qq.com/s/ia9nBhmqVEXiiQdFrjzmyg

  94. [101]

    Attack and defence of ethereum remote apis,

    X. Wang, X. Zha, G. Yu, W. Ni, R. P. Liu, Y. J. Guo, X. Niu, and K. Zheng, “Attack and defence of ethereum remote apis,” in2018 IEEE Globecom Workshops (GC Wkshps), pp. 1–6, IEEE, 2018

    2018

  95. [102]

    Hackers nab $500,000 as enigma is compromised weeks before its ico

    “Hackers nab $500,000 as enigma is compromised weeks before its ico.” https://techcrunch.com/2017/08/21/hack-enigma-500000-ico/

    2017

  96. [103]

    How one hacker stole thousands of dollars worth of cryptocurrency with a classic code injection

    “How one hacker stole thousands of dollars worth of cryptocurrency with a classic code injection....” https://hackernoon.com/how-one- hacker-stole-thousands-of-dollars-worth-of-cryptocurrency-with-a- classic-code-injection-a3aba5d2bff0

  97. [104]

    Coindash tge hack findings report

    “Coindash tge hack findings report.” https://blog.coindash.io/coindash- tge-hack-findings-report-15-11-17-9657465192e1

  98. [105]

    The state of affairs in bgp se- curity: A survey of attacks and defenses,

    A. Mitseva, A. Panchenko, and T. Engel, “The state of affairs in bgp se- curity: A survey of attacks and defenses,”Computer Communications, vol. 124, pp. 45–60, 2018

    2018

  99. [106]

    Cryptocurrency exchange etherdelta hacked in dns hijacking scheme

    “Cryptocurrency exchange etherdelta hacked in dns hijacking scheme.” https://www.ccn.com/cryptocurrency-exchange-etherdelta-hacked-in- dns-hijacking-scheme/

  100. [107]

    Domain name system security and privacy: old problems and new challenges,

    A. R. Kang, J. Spaulding, and A. Mohaisen, “Domain name system security and privacy: old problems and new challenges,”arXiv preprint arXiv:1606.07080, 2016

    2016 arXiv

  101. [108]

    An in-depth look at the parity multisig bug

    “An in-depth look at the parity multisig bug.” http://hackingdistributed. com/2017/07/22/deep-dive-parity-bug/

    2017

  102. [109]

    The $280m ethereum’s parity bug. – comae technologies

    “The $280m ethereum’s parity bug. – comae technologies.” https:// blog.comae.io/the-280m-ethereums-bug-f28e5de43513

  103. [110]

    The parity wallet hack reloaded - zeppelinos blog

    “The parity wallet hack reloaded - zeppelinos blog.” https://blog. zeppelinos.org/parity-wallet-hack-reloaded/

  104. [111]

    Smart contracts vulnerabilities: a call for blockchain software engineering?,

    G. Destefanis, M. Marchesi, M. Ortu, R. Tonelli, A. Bracciali, and R. Hierons, “Smart contracts vulnerabilities: a call for blockchain software engineering?,” in2018 International Workshop on Blockchain Oriented Software Engineering (IWBOSE), pp. 19–25, IEEE, 2018

    2018

  105. [112]

    Batchoverflow

    “Batchoverflow.” http://cve.mitre.org/cgi-bin/cvename.cgi?name= CVE-2018-10299

    2018

  106. [113]

    Detecting standard violation errors in smart contracts,

    A. Li and F. Long, “Detecting standard violation errors in smart contracts,”arXiv preprint arXiv:1812.07702, 2018

    2018 arXiv

  107. [114]

    Dissecting ponzi schemes on ethereum: identification, analysis, and impact,

    M. Bartoletti, S. Carta, T. Cimoli, and R. Saia, “Dissecting ponzi schemes on ethereum: identification, analysis, and impact,”arXiv preprint arXiv:1703.03779, 2017

    2017

  108. [115]

    What we learned from fomo3d

    “What we learned from fomo3d.” https://medium.com/@martinderka

  109. [116]

    Def con® 26 hacking conference speakers

    “Def con® 26 hacking conference speakers.” https://www.defcon.org/ html/defcon-26/dc-26-speakers.html#Bai2

  110. [117]

    Stick a fork in it: Analyzing the ethereumnetworkpartition,

    L. Kiffer, D. Levin, and A. Mislove, “Stick a fork in it: Analyzing the ethereumnetworkpartition,”in Proceedingsofthe16thACMWorkshop on Hot Topics in Networks, pp. 94–100, ACM, 2017

    2017

  111. [118]

    Etc 51 % attack

    “Etc 51 % attack.” https://bravenewcoin.com/insights/etc-51-attack- what-happened-and-how-it-was-stopped. 28

  112. [119]

    The balance attack or why forkable blockchains are ill-suited for consortium,

    C. Natoli and V. Gramoli, “The balance attack or why forkable blockchains are ill-suited for consortium,” in2017 47th Annual IEEE/I- FIP International Conference on Dependable Systems and Networks (DSN), pp. 579–590, IEEE, 2017

    2017

  113. [120]

    Impact of man-in-the- middle attacks on ethereum,

    P. Ekparinya, V. Gramoli, and G. Jourjon, “Impact of man-in-the- middle attacks on ethereum,” in 2018 IEEE 37th Symposium on Reliable Distributed Systems (SRDS), pp. 11–20, IEEE, 2018

    2018

  114. [121]

    Vyper—vyperdocumentation

    “Vyper—vyperdocumentation.”https://vyper.readthedocs.io/en/latest/ ?badge=latest#

  115. [122]

    “Bamboo.” https://github.com/pirapira/bamboo

  116. [123]

    Obsidian: a safer blockchain programming language,

    M. Coblenz, “Obsidian: a safer blockchain programming language,” in Proceedings of the 39th International Conference on Software Engineering Companion, pp. 97–99, IEEE Press, 2017

    2017

  117. [124]

    Writing safe smart contracts in flint,

    F. Schrans, S. Eisenbach, and S. Drossopoulou, “Writing safe smart contracts in flint,” inConference Companion of the 2nd Interna- tional Conference on Art, Science, and Engineering of Programming, pp. 218–219, ACM, 2018

    2018

  118. [125]

    Simplicity: A new language for blockchains,

    R. O’Connor, “Simplicity: A new language for blockchains,” inPro- ceedings of the 2017 Workshop on Programming Languages and Analysis for Security, pp. 107–120, ACM, 2017

    2017

  119. [126]

    Welcome! | the coq proof assistant

    “Welcome! | the coq proof assistant.” https://coq.inria.fr/

  120. [127]

    Scilla: a smart contract intermediate-level language,

    I. Sergey, A. Kumar, and A. Hobor, “Scilla: a smart contract intermediate-level language,”arXiv preprint arXiv:1801.00687

    arXiv

  121. [128]

    Software engineering techniques

    “Software engineering techniques.” https://consensys.github.io/smart- contract-best-practices/software_engineering/

  122. [129]

    Symbolicexecutionandprogramtesting,

    J.C.King,“Symbolicexecutionandprogramtesting,” Communications of the ACM, vol. 19, no. 7, pp. 385–394, 1976

    1976

  123. [130]

    Mythril

    “Mythril.” https://github.com/ConsenSys/mythril

  124. [131]

    scompile: Critical path identification and analysis for smart contracts,

    J. Chang, B. Gao, H. Xiao, J. Sun, and Z. Yang, “scompile: Critical path identification and analysis for smart contracts,”arXiv preprint arXiv:1808.00624, 2018

    2018 arXiv

  125. [132]

    Online detection of effectively callback free objects with applications to smart contracts,

    S. Grossman, I. Abraham, G. Golan-Gueta, Y. Michalevsky, N. Rinet- zky, M. Sagiv, and Y. Zohar, “Online detection of effectively callback free objects with applications to smart contracts,”Proceedings of the ACM on Programming Languages, vol. 2, no. POPL, p. 48, 2017

    2017

  126. [133]

    Abstract interpretation: a unified lattice model for static analysis of programs by construction or approximation of fixpoints,

    P. Cousot and R. Cousot, “Abstract interpretation: a unified lattice model for static analysis of programs by construction or approximation of fixpoints,” inProceedings of the 4th ACM SIGACT-SIGPLAN symposium on Principles of programming languages, pp. 238–252, ACM, 1977

    1977

  127. [134]

    Securify: Practical security analysis of smart contracts,

    P. Tsankov, A. Dan, D. D. Cohen, A. Gervais, F. Buenzli, and M. Vechev, “Securify: Practical security analysis of smart contracts,” arXiv preprint arXiv:1806.01143, 2018

    2018 arXiv

  128. [135]

    Designing secure ethereum smart contracts: A finite state machine based approach,

    A. Mavridou and A. Laszka, “Designing secure ethereum smart contracts: A finite state machine based approach,”arXiv preprint arXiv:1711.09327, 2017

    2017 arXiv

  129. [136]

    Vandal: A scalable security analysis frame- work for smart contracts,

    L. Brent, A. Jurisevic, M. Kong, E. Liu, F. Gauthier, V. Gramoli, R. Holz, and B. Scholz, “Vandal: A scalable security analysis frame- work for smart contracts,”arXiv preprint arXiv:1809.03981, 2018

    2018 arXiv

  130. [137]

    Porosity: A decompiler for blockchain-based smart con- tracts bytecode,

    M. Suiche, “Porosity: A decompiler for blockchain-based smart con- tracts bytecode,”DEF CON, vol. 25, p. 11, 2017

    2017

  131. [138]

    Erays: Reverse engineering ethereum’s opaque smart contracts,

    Y. Zhou, D. Kumar, S. Bakshi, J. Mason, A. Miller, and M. Bailey, “Erays: Reverse engineering ethereum’s opaque smart contracts,” in USENIX Security, 2018

    2018

  132. [139]

    Ethir: A framework for high-level analysis of ethereum bytecode,

    E. Albert, P. Gordillo, B. Livshits, A. Rubio, and I. Sergey, “Ethir: A framework for high-level analysis of ethereum bytecode,”arXiv preprint arXiv:1805.07208, 2018

    2018 arXiv

  133. [140]

    Defining the ethereum virtual machine for interactive theo- rem provers,

    Y. Hirai, “Defining the ethereum virtual machine for interactive theo- rem provers,” inInternational Conference on Financial Cryptography and Data Security, pp. 520–535, Springer, 2017

    2017

  134. [141]

    Nipkow, L

    T. Nipkow, L. C. Paulson, and M. Wenzel, Isabelle/HOL: a proof assistant for higher-order logic , vol. 2283. Springer Science & Business Media, 2002

    2002

  135. [142]

    Towards verifying ethereum smart contract bytecode in isabelle/hol,

    S. Amani, M. Bégel, M. Bortin, and M. Staples, “Towards verifying ethereum smart contract bytecode in isabelle/hol,” inProceedings of the 7th ACM SIGPLAN International Conference on Certified Programs and Proofs, pp. 66–77, ACM, 2018

    2018

  136. [143]

    Kevm: A complete formal semantics of the ethereum virtual machine,

    E. Hildenbrandt, M. Saxena, N. Rodrigues, X. Zhu, P. Daian, D. Guth, B. Moore, D. Park, Y. Zhang, A. Stefanescu,et al., “Kevm: A complete formal semantics of the ethereum virtual machine,” in2018 IEEE 31st Computer Security Foundations Symposium (CSF), pp. 204–217, IEEE, 2018

    2018

  137. [144]

    An overview of the k semantic frame- work,

    G. Ros,u and T. F. S,erb/uni0103nut/uni0103, “An overview of the k semantic frame- work,”The Journal of Logic and Algebraic Programming, vol. 79, no. 6, pp. 397–434, 2010

    2010

  138. [145]

    A formal verifi- cation tool for ethereum vm bytecode,

    D. Park, Y. Zhang, M. Saxena, P. Daian, and G. Ro/uni015Fu, “A formal verifi- cation tool for ethereum vm bytecode,” inProceedings of the 2018 26th ACM Joint Meeting on European Software Engineering Conference and Symposium on the Foundations of Software Engineering, pp. 912–91...

    2018

  139. [146]

    A semantic frame- work for the security analysis of ethereum smart contracts,

    I. Grishchenko, M. Maffei, and C. Schneidewind, “A semantic frame- work for the security analysis of ethereum smart contracts,” inInter- national Conference on Principles of Security and Trust, pp. 243–269, Springer, 2018

    2018

  140. [147]

    Dependent types and multi-monadic effects in f,

    N. Swamy, C. Hri/uni0163cu, C. Keller, A. Rastogi, A. Delignat-Lavaud, S. Forest, K. Bhargavan, C. Fournet, P.-Y. Strub, M. Kohlweiss,et al., “Dependent types and multi-monadic effects in f,” inACM SIGPLAN Notices, vol. 51, pp. 256–270, ACM, 2016

    2016

  141. [148]

    Ethertrust: Sound static analysis of ethereum bytecode,

    I. Grishchenko, M. Maffei, and C. Schneidewind, “Ethertrust: Sound static analysis of ethereum bytecode,”Technische Universität Wien, Tech. Rep, 2018

    2018

  142. [149]

    Foundations and tools for the static analysis of ethereum smart contracts,

    I. Grishchenko, M. Maffei, and C. Schneidewind, “Foundations and tools for the static analysis of ethereum smart contracts,” inInterna- tionalConferenceonComputerAidedVerification ,pp.51–78,Springer, 2018

    2018

  143. [150]

    Formal verification of smart contracts: Short paper,

    K. Bhargavan, A. Delignat-Lavaud, C. Fournet, A. Gollamudi, G. Gonthier, N. Kobeissi, N. Kulatova, A. Rastogi, T. Sibut-Pinote, N. Swamy, et al., “Formal verification of smart contracts: Short paper,” inProceedings of the 2016 ACM Workshop on Programming Languages and Analysis ...

    2016

  144. [151]

    “Why3.” http://why3.lri.fr/

  145. [152]

    Formal verification for solidity contracts

    “Formal verification for solidity contracts.” https://forum.ethereum.org/ discussion/3779/formal-verification-for-solidity-contracts

  146. [153]

    Reguard: finding reentrancy bugs in smart contracts,

    C. Liu, H. Liu, Z. Cao, Z. Chen, B. Chen, and B. Roscoe, “Reguard: finding reentrancy bugs in smart contracts,” inProceedings of the 40th International Conference on Software Engineering: Companion Proceeedings, pp. 65–68, ACM, 2018

    2018

  147. [154]

    Towards safer smart contracts: A sequence learning approach to detecting vulnerabilities,

    A. Tann, X. J. Han, S. S. Gupta, and Y.-S. Ong, “Towards safer smart contracts: A sequence learning approach to detecting vulnerabilities,” arXiv preprint arXiv:1811.06632, 2018

    2018 arXiv

  148. [155]

    Smartcheck: Static analysis of ethereum smart contracts,

    S. Tikhomirov, E. Voskresenskaya, I. Ivanitskiy, R. Takhaviev, E. Marchenko, and Y. Alexandrov, “Smartcheck: Static analysis of ethereum smart contracts,” in2018 IEEE/ACM 1st International Work- shop on Emerging Trends in Software Engineering for Blockchain (WETSEB), pp. 9–16,...

    2018

  149. [156]

    Hawk: The blockchain model of cryptography and privacy-preserving smart contracts,

    A. Kosba, A. Miller, E. Shi, Z. Wen, and C. Papamanthou, “Hawk: The blockchain model of cryptography and privacy-preserving smart contracts,” in2016 IEEE symposium on security and privacy (SP), pp. 839–858, IEEE, 2016

    2016

  150. [157]

    Town crier: An authenticated data feed for smart contracts,

    F. Zhang, E. Cecchetti, K. Croman, A. Juels, and E. Shi, “Town crier: An authenticated data feed for smart contracts,” inProceedings of the 2016 aCM sIGSAC conference on computer and communications security, pp. 270–282, ACM, 2016

    2016

  151. [158]

    Astraea: A decentralized blockchain oracle,

    J. Adler, R. Berryhill, A. Veneris, Z. Poulos, N. Veira, and A. Kas- tania, “Astraea: A decentralized blockchain oracle,”arXiv preprint arXiv:1808.00528, 2018

    2018 arXiv

  152. [159]

    A nonout- sourceable puzzle under ghost rule,

    G. Zeng, S. M. Yiu, J. Zhang, H. Kuzuno, and M. H. Au, “A nonout- sourceable puzzle under ghost rule,” in2017 15th Annual Conference on Privacy, Security and Trust (PST), pp. 35–358, IEEE, 2017

    2017

  153. [160]

    How to disincentivize large bitcoin mining pools

    “How to disincentivize large bitcoin mining pools.” http:// hackingdistributed.com/2014/06/18/how-to-disincentivize-large- bitcoin-mining-pools/

    2014

  154. [161]

    Smartpool: Practical decentralized pooled mining,

    L. Luu, Y. Velner, J. Teutsch, and P. Saxena, “Smartpool: Practical decentralized pooled mining,” in26th {USENIX} Security Symposium ({USENIX} Security 17), pp. 1409–1426, 2017

    2017

  155. [162]

    Dappguard: Active monitoring and defense for solidity smart contracts,

    T. Cook, A. Latham, and J. H. Lee, “Dappguard: Active monitoring and defense for solidity smart contracts,”Retrieved July, vol. 18, p. 2018, 2017

    2018

  156. [163]

    Runtime verification of ethereum smart contracts,

    J. Ellul and G. J. Pace, “Runtime verification of ethereum smart contracts,” in2018 14th European Dependable Computing Conference (EDCC), pp. 158–163, IEEE, 2018

    2018

  157. [164]

    Smart contracts: security patterns in the ethereum ecosystem and solidity,

    M. Wohrer and U. Zdun, “Smart contracts: security patterns in the ethereum ecosystem and solidity,” in2018 International Workshop on Blockchain Oriented Software Engineering (IWBOSE), pp. 2–8, IEEE, 2018

    2018

  158. [165]

    Rethinking blockchain security: Position paper,

    V. Chia, P. H. Hartel, Q. Hum, S. Ma, G. Piliouras, D. Reijsbergen, M. van Staalduinen, and P. Szalachowski, “Rethinking blockchain security: Position paper,”CoRR, vol. abs/1806.04358, 2018

    2018 arXiv

  159. [167]

    Emergent behavior in cybersecurity,

    S. Xu, “Emergent behavior in cybersecurity,” inProceedings of the 2014 Symposium on the Science of Security (HotSoS’14), pp. 13:1– 13:2, 2014

    2014

  160. [168]

    Cybersecurity dynamics: A foundation for the science of cybersecurity,

    S. Xu, “Cybersecurity dynamics: A foundation for the science of cybersecurity,” inProactive and Dynamic Network Defense (Z. Lu and C. Wang, eds.), vol. 74, pp. 1–31, Cham: Springer International Publishing, 2019

    2019

  161. [169]

    Push- and pull-based epidemic spreading in arbitrary networks: Thresholds and deeper insights,

    S. Xu, W. Lu, and L. Xu, “Push- and pull-based epidemic spreading in arbitrary networks: Thresholds and deeper insights,”ACM Transactions on Autonomous and Adaptive Systems (ACM TAAS), vol. 7, no. 3, pp. 32:1–32:26, 2012

    2012

  162. [170]

    Characterizing the power of moving target defense via cyber epidemic dynamics,

    Y. Han, W. Lu, and S. Xu, “Characterizing the power of moving target defense via cyber epidemic dynamics,” inProc. 2014 Symposium on the Science of Security (HotSoS’14), vol. 10, pp. 1–12, 2014

    2014

  163. [171]

    Active cyber defense dynamics exhibiting rich phenomena,

    R. Zheng, W. Lu, and S. Xu, “Active cyber defense dynamics exhibiting rich phenomena,” inProc. 2015 Symposium on the Science of Security (HotSoS’15), pp. 2:1–2:12, 2015

    2015

  164. [172]

    Cyber epidemic models with dependences,

    M. Xu, G. Da, and S. Xu, “Cyber epidemic models with dependences,” Internet Mathematics, vol. 11, no. 1, pp. 62–92, 2015

    2015

  165. [173]

    Preventive and reactive cyber defense dynamics is globally stable,

    R. Zheng, W. Lu, and S. Xu, “Preventive and reactive cyber defense dynamics is globally stable,”IEEE Trans. Network Science and Engi- neering, vol. 5, no. 2, pp. 156–170, 2018

    2018

  166. [175]

    Model-based evalu- ation: From dependability to security,

    D. M. Nicol, W. H. Sanders, and K. S. Trivedi, “Model-based evalu- ation: From dependability to security,”IEEE Trans. Dependable Sec. Comput., vol. 1, no. 1, pp. 48–65, 2004

    2004

  167. [176]

    A survey on systems security metrics,

    M. Pendleton, R. Garcia-Lebron, J.-H. Cho, and S. Xu, “A survey on systems security metrics,”ACM Comput. Surv., vol. 49, pp. 62:1–62:35, Dec. 2016

    2016

  168. [177]

    Model- based quantitative network security metrics: A survey,

    A. Ramos, M. Lazar, R. H. Filho, and J. J. P. C. Rodrigues, “Model- based quantitative network security metrics: A survey,”IEEE Commu- nications Surveys Tutorials, vol. 19, no. 4, pp. 2704–2734, 2017

    2017

  169. [178]

    Noel and S

    S. Noel and S. Jajodia,A Suite of Metrics for Network Attack Graph Analytics, pp. 141–176. Cham: Springer International Publishing, 2017

    2017

  170. [179]

    Quantifying the security effectiveness of firewalls and dmzs,

    H. Chen, J. Cho, and S. Xu, “Quantifying the security effectiveness of firewalls and dmzs,” inProceedings of the 5th Annual Symposium on Hot Topics in the Science of Security (HoTSoS’2018), pp. 9:1–9:11, 2018

    2018

  171. [180]

    Metrics towards measuring cyber agility

    J. D. Mireles, E. Ficke, J.-H. Cho, P. Hurley, and S. Xu, “Metrics towards measuring cyber agility.” IEEE Transaction on Information Forensics & Security, 2019 (accepted for publication)

    2019

  172. [181]

    Stram: Measuring the trustworthiness of computer- based systems,

    J.-H. Cho, S. Xu, P. M. Hurley, M. Mackay, T. Benjamin, and M. Beaumont, “Stram: Measuring the trustworthiness of computer- based systems,”ACM Comput. Surv., vol. 51, no. 6, pp. 128:1–128:47, 2019

    2019

Pith tools

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