Pith. sign in

REVIEW 5 major objections 7 minor 4 cited by

Security Analysis Methods on Ethereum Smart Contract Vulnerabilities: A Survey

T0 review · 5 major / 7 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 A survey mapping 16 Ethereum vulnerabilities to 19 classic software security issues predicts that many smart-contract attacks are still to come.

desk verdict Useful introductory survey of Ethereum smart contract vulnerabilities and analysis tools, but the correlation table driving its headline prediction inverts several definitions and the tool coverage table disagrees with the text. read the letter →

arxiv 1908.08605 v3 pith:7WLLSHYR submitted 2019-08-22 cs.CR

Purathani Praitheeshan , Lei Pan , Jiangshan Yu , Joseph Liu , Robin Doss This is my paper · ORCID
classification cs.CR
keywords Ethereumsmartcontractsvulnerabilitydetectionstaticanalysisdynamicformalverificationre-entrancyintegeroverflow
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 survey sets out to show that the security problems of Ethereum smart contracts are not a separate, exotic category but a concrete instance of classic software security weaknesses, and that the gap between the vulnerabilities already exploited and those that remain latent is large enough to predict many future attacks. The paper identifies 16 distinct Ethereum vulnerability classes, maps them onto the 19 software security issues, and uses that correlation to predict that many attacks are yet to be exploited. It then classifies the existing detection tools into static analysis, dynamic analysis, and formal verification, and compares them by which of the 16 vulnerability classes each tool can detect. A sympathetic reader would take the paper's contribution to be a structured map that connects each known smart-contract failure mode to its software-engineering root cause and to the tool most likely to catch it.

What carries the argument

The piece of machinery carrying the argument is the correlation table (Table II) that maps each of the 16 Ethereum vulnerability classes to one or more of the 19 software security issues in the '19 deadly sins' taxonomy. This mapping turns a list of blockchain-specific failure modes into familiar software flaws—race conditions, failure to handle errors, information leakage, improper access control—and provides the counting that grounds the prediction of future attacks. The second piece of machinery is the three-way classification of detection methods into static analysis, dynamic analysis, and formal verification, together with the coverage table showing which of the surveyed tools (Oyente, ZEUS, Vandal, Ethir, Securify, MAIAN, GASPER) detects which vulnerability classes; this is what lets the survey compare tools against the vulnerability list rather than against each other in the abstract.

What would settle it

The prediction would be falsified if a complete public record of Ethereum smart-contract exploits from 2019 to the present showed that all 16 of the vulnerability classes listed in Table II have already been exploited at least once in a real-world attack; in that case there would be no large class of 'yet to be exploited' vulnerabilities left. A weaker test would compare the number of new attack techniques appearing after the survey with the number of vulnerability classes the survey flags as having no proper solution.

Watch

Extended reading notes

Core claim

The paper's central claim is that the 16 well-documented Ethereum smart-contract vulnerability classes—re-entrancy, transaction-ordering dependence, block-timestamp dependence, mishandled exceptions, call-stack depth limits, integer overflow/underflow, unchecked send, destroyable contracts, unsecured balance, misuse of ORIGIN, unrestricted writes, unrestricted transfers, non-validated arguments, greedy contracts, prodigal contracts, and gas-costly patterns—can be systematically related to 19 general software security issues, and that this relation shows the attack surface is far from exhausted. To establish this, the survey builds a taxonomy (its Table II) listing each vulnerability, the mechanism that triggers it, the historical attack that exploited it, and the corresponding software security issues, and it surveys eleven analysis tools (Oyente, ZEUS, Vandal, Ethir, Securify, MAIAN, GASPER, F*, Isabelle/HOL, FEther, and KEVM) sorted into static analysis, dynamic analysis, and formal verification. The comparison demonstrates that no single tool detects all 16 vulnerability classes, and that certain classes—such as non-validated arguments, no-restricted-write, and gas-costly patterns—are each covered by only one or two tools. From the partial coverage and the existence of vulnerabilities with no proper solution, the paper concludes that many attacks are yet to be exploited.

Load-bearing premise

The paper's prediction that many attacks are yet to be exploited depends on the assumption that its table matching 16 Ethereum vulnerabilities to 19 software bugs is a real insight into what can still be attacked, not just a list of similar-sounding names that happen to line up.

Editorial extensions

If this is right

  • No single surveyed tool covers all 16 vulnerability classes, so a developer who relies on one analyzer will leave part of the listed attack surface undetected.
  • For vulnerabilities with known fixes—re-entrancy answered by send/transfer instead of call.value, integer overflow by SafeMath, unchecked send by explicit return-value checks—continued exploitation is a software-engineering failure that auditing can prevent.
  • Formal verification tools prove functional correctness and runtime-safety properties but are semi-automated and scale poorly, so they are suited to high-assurance contracts rather than mass screening.
  • Because deployed contracts are immutable, the survey's practical advice is to run detection during development; it suggests integrating detection tools with the Solidity compiler as a plugin as a future direction.
  • The taxonomy gives auditors a checklist for pairing each vulnerability class with a detection tool before deploying a contract.

Reading between the lines

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

  • If the Table II mapping is treated as a risk signal, the most dangerous contracts are those that instantiate several software security issues simultaneously—the DAO contract, for example, combined re-entrancy with data-protection failure and race conditions—so auditors could prioritize contracts showing such combined patterns.
  • The three-way classification implies a natural audit pipeline—static analysis for breadth, dynamic analysis to confirm exploitable traces, and formal verification for the highest-assurance properties—a combination the paper does not explicitly recommend.
  • The prediction that 'many attacks are yet to be exploited' could be made testable by defining a fixed post-survey window and counting newly observed exploit types; without such an operationalization, the sentence is a qualitative warning rather than a measurable forecast.
  • A natural follow-up would be a public registry that records each newly discovered real-world exploit against the 16 vulnerability classes, allowing the survey's prediction to be checked as data accumulates.
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 / 7 minor

Summary. This survey paper reviews security vulnerabilities in Ethereum smart contracts and the analysis methods used to detect them. The authors identify 16 Ethereum/Solidity vulnerabilities, map them onto 19 software security issues from Howard et al., and categorize security analysis approaches into static analysis, dynamic analysis, and formal verification. They describe major historical attacks (the DAO attack, the Parity multi-sig wallet attack, and integer overflow/underflow attacks), provide code snippets illustrating vulnerable patterns, and compare eleven analysis tools. The abstract's headline claim is that by correlating 16 Ethereum vulnerabilities with 19 software security issues, the paper predicts that many attacks are yet to be exploited.

Significance. If the survey's taxonomy and comparative tables were reliable, the paper would provide a useful structured map of known smart-contract vulnerabilities and available detection tools, particularly as an entry point for newcomers. The paper includes detailed narrative descriptions, illustrative Solidity code, open-source tool links, and a broad bibliography, which are valuable reference materials. The categorization into three analysis families is reasonable and consistent with the literature. However, the central comparative apparatus—Table II and Table IV—contains definitional inversions and contradictions with the body text, and the predictive claim in the abstract is not derived from any data or model. These issues affect the paper's main intended contribution rather than merely its presentation.

major comments (5)
  1. [Section III.C] The paragraph beginning 'An unsigned integer in Solidity is defined as uint256' states that uint256 values range 'between 0 and 4,294,967,295 (2^256 − 1)'. The bound 4,294,967,295 is 2^32−1, not 2^256−1, so the stated maximum value is incorrect by many orders of magnitude. This factual error directly affects the explanation of the integer overflow/underflow attack and should be corrected to the actual uint256 range, 0 to 2^256−1.
  2. [Table II] The rows for 'No restricted write' and 'No restricted transfer' describe the secure behavior rather than the vulnerability. Section IV.F defines 'No restricted write' as the absence of any restriction on storage writes, and 'No restricted transfer' as the ability of arbitrary users to invoke transfers; Table II states the opposite in both cases, saying writes 'is restricted by the modifier private' and transfers 'cannot be invoked by any user who is independent to the sender'. Because Table II is the sole basis for the abstract's correlation claim, these inversions make the mapping unreliable.
  3. [Section V.A.1 and Table IV] The text states that OYENTE detects four vulnerabilities (re-entrancy, transaction ordering, timestamp dependence, and mishandled exceptions), but Table IV lists six, adding call-stack depth limitation and integer overflow/underflow. Similarly, Section V.A.2 says ZEUS detects six vulnerabilities, while Table IV lists seven. These discrepancies between the body and the tool-comparison table need to be reconciled before the comparison can be used as a reference.
  4. [Table IV and Section V.A.6] Securify's seven checked properties are given in the text as 'Ether Liquidity', 'No writes after the call', 'Restricted write', 'Restricted transfer', 'Handled exception', 'Transaction ordering dependency', and 'Validated arguments'. Table IV instead lists 'No Restricted write', 'No Restricted transfer', 'Call stack depth limitation', 'Unchecked and Failed send', and 'Non-validated arguments', among others. The table thus reports the opposite of some Securify properties (e.g., 'restricted write' appears as 'No Restricted write'), conflating a security property with its violation.
  5. [Abstract and Section VI] The prediction that 'many attacks are yet to be exploited' is not supported by any empirical data or model in the paper; it is inferred from the mapping in Table II, which is itself inconsistent as noted above. The count of vulnerabilities is also inconsistent: the abstract and Table II use 16, but Section IV.E discusses 'Sequential execution of smart contracts' as an additional issue, and Figure 1 categorizes it under blockchain vulnerabilities rather than the Ethereum/Solidity list. The predictive claim should either be removed or substantiated with a concrete dataset and methodology.
minor comments (7)
  1. [Section III.C] The token 'POWH' is expanded as 'Proof-of-Week-Hands'; the correct name is 'Proof-of-Weak-Hands'.
  2. [Section IV.F and Figure 1] The term 'Prodegal contract' appears in the text and in Figure 1, but Table II and the literature use 'Prodigal contract'; the spelling should be made consistent.
  3. [Table II and Section IV.F] The table uses 'Misuse of ORIGIN' while Section IV.F uses 'Use of ORIGIN'; one term should be chosen and used throughout.
  4. [Table II] Rows 11 and 12 use 'Failure to store and protect data' while other rows and Table I use 'Failing to store and protect data'; the wording should be unified.
  5. [Figure 1] Item 16, 'Use of ?magic? URLs and hidden forms', contains stray question marks, and item 15, 'Signal race conditions', should be 'Race conditions' to match the terminology elsewhere.
  6. [References] References [85] and [87] both cite Di Angelo and Salzer, 'A survey of tools for analyzing ethereum smart contracts' in the same venue and year; this duplication should be removed.
  7. [Section V.D] The sentence 'The static analysis tool OYENTE that can detect four major vulnerabilities' lacks a main verb; it should be rephrased, and the typo 'analaysis' in the Section IV introductory text should be corrected.

Circularity Check

0 steps flagged · score 0.0 of 10

No significant circularity: the survey's categorization and tool comparison are descriptive, and its forward-looking prediction is an unsupported assertion rather than a derivation from its own inputs.

full rationale

This paper is a survey that organizes known Ethereum smart contract vulnerabilities, maps them to software security issues from Howard et al., and compares detection tools. There is no mathematical derivation chain, no fitted parameter that is later renamed as a prediction, and no uniqueness theorem imported from the authors' own prior work. The central claim that 'many attacks are yet to be exploited' is presented as a correlation-based prediction, but it is not obtained by reducing any definition or equation to itself; it is simply an asserted interpretation of the mapping in Table II. Even if that mapping is internally inconsistent or unreliable, as the skeptical review notes, unreliability is a correctness or soundness concern, not circularity. The paper also does not rely on load-bearing self-citations: the tools and formal verification frameworks are described with reference to their original independent publications, and the authors' own prior work is not invoked to justify the survey's organizational claims. Because the survey's conclusions are descriptive rather than derived, and because no step in the paper reduces by construction to an input, the appropriate circularity finding is none.

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

The survey's central content rests on platform behavioral assumptions, the applicability of a classic software-security taxonomy, and faithful representation of the cited tool papers. No free parameters or invented entities are introduced.

assumptions (3)
  • domain assumption Ethereum has the immutability, 1024 call stack depth limit, and send/call semantics described in [9], [62], [124].
    The vulnerability explanations in Sections III and IV rely on these platform properties being accurate; if any of them is incorrect, the attack narratives lose validity.
  • domain assumption Howard et al.'s '19 deadly sins' taxonomy is a valid basis for mapping general software security issues to Ethereum smart contract vulnerabilities.
    Table II's mapping and the resulting prediction depend on this taxonomy being applicable to smart contracts, but the paper does not justify the mapping criteria.
  • domain assumption The cited tool papers (Oyente, ZEUS, Vandal, Securify, MAIAN, GASPER, F*, Isabelle/HOL, FEther, KEVM) are accurately represented in the survey.
    The tool comparisons in Section V are taken from the primary papers and are not independently validated by the survey.

how reviews work

0 comments
Cite this review

Pith. "Pith review of Security Analysis Methods on Ethereum Smart Contract Vulnerabilities: A Survey." pith.science (2026). https://pith.science/paper/7WLLSHYR

@misc{pith2026190808605,
  author       = {Pith},
  title        = {Pith review of: Security Analysis Methods on Ethereum Smart Contract Vulnerabilities: A Survey},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/7WLLSHYR}},
  note         = {Machine review of arXiv:1908.08605}
}
read the original abstract

Smart contracts are software programs featuring both traditional applications and distributed data storage on blockchains. Ethereum is a prominent blockchain platform with the support of smart contracts. The smart contracts act as autonomous agents in critical decentralized applications and hold a significant amount of cryptocurrency to perform trusted transactions and agreements. Millions of dollars as part of the assets held by the smart contracts were stolen or frozen through the notorious attacks just between 2016 and 2018, such as the DAO attack, Parity Multi-Sig Wallet attack, and the integer underflow/overflow attacks. These attacks were caused by a combination of technical flaws in designing and implementing software codes. However, many more vulnerabilities of less severity are to be discovered because of the scripting natures of the Solidity language and the non-updateable feature of blockchains. Hence, we surveyed 16 security vulnerabilities in smart contract programs, and some vulnerabilities do not have a proper solution. This survey aims to identify the key vulnerabilities in smart contracts on Ethereum in the perspectives of their internal mechanisms and software security vulnerabilities. By correlating 16 Ethereum vulnerabilities and 19 software security issues, we predict that many attacks are yet to be exploited. And we have explored many software tools to detect the security vulnerabilities of smart contracts in terms of static analysis, dynamic analysis, and formal verification. This survey presents the security problems in smart contracts together with the available analysis tools and the detection methods. We also investigated the limitations of the tools or analysis methods with respect to the identified security vulnerabilities of the smart contracts.

Figures

Figures reproduced from arXiv: 1908.08605 by the authors.

Figure 1
Figure 1. The taxonomy of dependencies in smart contract vulnerabilities [PITH_FULL_IMAGE:figures/full_fig_p002_1.png] view at source ↗
Figure 2
Figure 2. A Real-world Example for Smart Contract Execution [PITH_FULL_IMAGE:figures/full_fig_p003_2.png] view at source ↗
Figure 3
Figure 3. The Transaction Ordering Dependency Problem [62], [76] [PITH_FULL_IMAGE:figures/full_fig_p007_3.png] view at source ↗
Figures from the paper (6 more)
Figure 4
Figure 4. Figure 4: The systematic mapping between Ethereum vulnerabilities, analysis tools, and attacks [PITH_FULL_IMAGE:figures/full_fig_p012_4.png]
Figure 5
Figure 5. Figure 5: The Architecture of the OYENTE Tool [62] 2) ZEUS: ZEUS [64] can verify the correctness of smart contracts and validate their fairness. Combining an abstract interpreter with a symbolic model checker, ZEUS verifies the safe programming practices of the vulnerable smart …
Figure 6
Figure 6. Figure 6: An Abstract Language Model for a solidity smart contract[64] [PITH_FULL_IMAGE:figures/full_fig_p013_6.png]
Figure 7
Figure 7. Figure 7: The Architecture of MAIAN [140] [PITH_FULL_IMAGE:figures/full_fig_p014_7.png]
Figure 8
Figure 8. Figure 8: An overview of graph analysis approach [70] [PITH_FULL_IMAGE:figures/full_fig_p015_8.png]
Figure 9
Figure 9. Figure 9: Architecture of the F* Framework [91] [PITH_FULL_IMAGE:figures/full_fig_p015_9.png]

Discussion (0). Continue with ORCID to comment.

Forward citations

Cited by 4 Pith papers

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

  1. MOS: Towards Effective Smart Contract Vulnerability Detection through Mixture-of-Experts Tuning of Large Language Models

    cs.SE 2025-04 reject novelty 6.0 of 10

    MOS applies mixture-of-experts tuning to a 3B-parameter LLM, specializing experts per vulnerability type and reporting state-of-the-art detection and explanation quality on reentrancy, timestamp, overflow, and delegat...

  2. SAEL: Leveraging Large Language Models with Adaptive Mixture-of-Experts for Smart Contract Vulnerability Detection

    cs.CR 2025-07 conditional novelty 5.0 of 10

    SAEL combines LLM predictions, LLM-generated explanations, and code features via an adaptive mixture-of-experts gate and reports state-of-the-art F1 on four smart contract vulnerability benchmarks.

  3. Smart-LLaMA-DPO: Reinforced Large Language Model for Explainable Smart Contract Vulnerability Detection

    cs.CR 2025-06 conditional novelty 5.0 of 10

    A LLaMA-3.1-8B model trained with continual pre-training, supervised fine-tuning, and direct preference optimization reports state-of-the-art accuracy and F1 for smart contract vulnerability detection and explanation.

  4. FedStrategist: A Meta-Learning Framework for Adaptive and Robust Aggregation in Federated Learning

    cs.LG 2025-07 reject novelty 4.0 of 10

    A LinUCB contextual bandit selects federated aggregation rules online based on update variance, cosine similarity, and mean norm, claiming superior accuracy and tunable risk posture.

Reference graph

Works this paper leans on

157 extracted references · 74 canonical work pages · cited by 4 Pith papers

  1. [1]

    The blockchain as a software connector,

    X. Xu, C. Pautasso, L. Zhu, V . Gramoli, A. Ponomarev, A. B. Tran, and S. Chen, “The blockchain as a software connector,” in Software Architecture (WICSA), 2016 13th Working IEEE/IFIP Conference on . IEEE, 2016, pp. 182–191

    2016

  2. [3]

    The future of finance: fintech, tech disruption, and orchestrating innovation,

    O. Bussmann, “The future of finance: fintech, tech disruption, and orchestrating innovation,” in Equity Markets in Transition . Springer, 2017, pp. 473–486

    2017

  3. [4]

    Transaction costs,

    J. Niehans, “Transaction costs,” in Money. Springer, 1989, pp. 320– 327

    1989

  4. [5]

    Blockchain technology innovations,

    T. Ahram, A. Sargolzaei, S. Sargolzaei, J. Daniels, and B. Amaba, “Blockchain technology innovations,” in Technology and Engineering Management Conference (TEMSCON), 2017 IEEE . IEEE, 2017, Conference Proceedings, pp. 137–141

    2017

  5. [6]

    A taxonomy of blockchain-based systems for architecture design,

    X. Xu, I. Weber, M. Staples, L. Zhu, J. Bosch, L. Bass, C. Pautasso, and P. Rimba, “A taxonomy of blockchain-based systems for architecture design,” in Software Architecture (ICSA), 2017 IEEE International Conference on. IEEE, 2017, pp. 243–252

    2017

  6. [7]

    Understanding modern banking ledgers through blockchain technologies: Future of transaction processing and smart contracts on the internet of money,

    G. W. Peters and E. Panayi, “Understanding modern banking ledgers through blockchain technologies: Future of transaction processing and smart contracts on the internet of money,” in Banking beyond banks and money. Springer, 2016, pp. 239–278

    2016

  7. [8]

    Sharing ledgers for sharing economies: an exploration of mutual distributed ledgers (aka blockchain technology),

    M. Mainelli and M. Smith, “Sharing ledgers for sharing economies: an exploration of mutual distributed ledgers (aka blockchain technology),” Journal of Financial Perspectives , vol. 3, no. 3, 2015

    2015

  8. [9]

    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

Show all 157 references
  1. [10]

    Architecture of the hyperledger blockchain fabric,

    C. Cachin, “Architecture of the hyperledger blockchain fabric,” in Workshop on Distributed Cryptocurrencies and Consensus Ledgers , 2016

    2016

  2. [11]

    Hyperledger fabric: a distributed operating system for permissioned blockchains,

    E. Androulaki, A. Barger, V . Bortnikov, C. Cachin, K. Christidis, A. De Caro, D. Enyeart, C. Ferris, G. Laventman, Y . Manevich et al., “Hyperledger fabric: a distributed operating system for permissioned blockchains,” in Proceedings of the Thirteenth EuroSys Conference . ACM...

    2018

  3. [12]

    Digital currencies, decentralized ledgers, and the future of central banking,

    M. Raskin and D. Yermack, “Digital currencies, decentralized ledgers, and the future of central banking,” National Bureau of Economic Research, Tech. Rep., 2016

    2016

  4. [13]

    On availability for blockchain-based systems,

    I. Weber, V . Gramoli, A. Ponomarev, M. Staples, R. Holz, A. B. Tran, and P. Rimba, “On availability for blockchain-based systems,” in Reliable Distributed Systems (SRDS), 2017 IEEE 36th Symposium on. IEEE, 2017, Conference Proceedings, pp. 64–73

    2017

  5. [14]

    Scripting smart contracts for distributed ledger technology

    P. L. Seijas, S. J. Thompson, and D. McAdams, “Scripting smart contracts for distributed ledger technology.” IACR Cryptology ePrint Archive, vol. 2016, p. 1156, 2016

    2016

  6. [15]

    Replacing paper contracts with ethereum smart contracts,

    W. Egbertsen, G. Hardeman, M. van den Hoven, G. van der Kolk, and A. van Rijsewijk, “Replacing paper contracts with ethereum smart contracts,” 2016

    2016

  7. [16]

    Blockchain-based smart contracts: A systematic mapping study,

    M. Alharby and A. van Moorsel, “Blockchain-based smart contracts: A systematic mapping study,” arXiv preprint arXiv:1710.06372, 2017

    2017 arXiv

  8. [17]

    Blockchain technology: Transforming libertarian cryptocur- rency dreams to finance and banking realities,

    I. Eyal, “Blockchain technology: Transforming libertarian cryptocur- rency dreams to finance and banking realities,” Computer, vol. 50, no. 9, pp. 38–49, 2017

    2017

  9. [18]

    Blockchain technology in finance,

    P. Treleaven, R. G. Brown, and D. Yang, “Blockchain technology in finance,” Computer, vol. 50, no. 9, pp. 14–17, 2017

    2017

  10. [19]

    Blockchain ready manufactur- ing supply chain using distributed ledger,

    S. A. Abeyratne and R. P. Monfared, “Blockchain ready manufactur- ing supply chain using distributed ledger,” International Journal of Research in Engineering and Technology , vol. 5, pp. 1–10, 2016

    2016

  11. [20]

    A blockchain- based supply chain quality management framework,

    S. Chen, R. Shi, Z. Ren, J. Yan, Y . Shi, and J. Zhang, “A blockchain- based supply chain quality management framework,” in 2017 IEEE 14th International Conference on e-Business Engineering (ICEBE) . IEEE, 2017, pp. 172–176

    2017

  12. [21]

    A supply chain traceability system for food safety based on haccp, blockchain & internet of things,

    F. Tian, “A supply chain traceability system for food safety based on haccp, blockchain & internet of things,” in 2017 International Conference on Service Systems and Service Management. IEEE, 2017, pp. 1–6

    2017

  13. [22]

    Medrec: Using blockchain for medical data access and permission management,

    A. Azaria, A. Ekblaw, T. Vieira, and A. Lippman, “Medrec: Using blockchain for medical data access and permission management,” in 2016 2nd International Conference on Open and Big Data (OBD) . IEEE, 2016, pp. 25–30

    2016

  14. [23]

    Blockchain technology in healthcare: The revolution starts here,

    M. Mettler, “Blockchain technology in healthcare: The revolution starts here,” in 2016 IEEE 18th International Conference on e-Health Networking, Applications and Services (Healthcom) . IEEE, 2016, pp. 1–3. 19

    2016

  15. [24]

    Blockchain tech- nology use cases in healthcare,

    P. Zhang, D. C. Schmidt, J. White, and G. Lenz, “Blockchain tech- nology use cases in healthcare,” in Advances in Computers . Elsevier, 2018, vol. 111, pp. 1–41

    2018

  16. [25]

    Healthcare blockchain system using smart contracts for secure automated remote patient monitoring,

    K. N. Griggs, O. Ossipova, C. P. Kohlios, A. N. Baccarini, E. A. Howson, and T. Hayajneh, “Healthcare blockchain system using smart contracts for secure automated remote patient monitoring,” Journal of medical systems, vol. 42, no. 7, p. 130, 2018

    2018

  17. [26]

    Privacy-preserving smart grid tariff decisions with blockchain-based smart contracts,

    F. Knirsch, A. Unterweger, G. Eibl, and D. Engel, “Privacy-preserving smart grid tariff decisions with blockchain-based smart contracts,” in Sustainable Cloud and Energy Services . Springer, 2018, pp. 85–116

    2018

  18. [27]

    A blockchain-based smart grid: towards sustainable local energy markets,

    E. Mengelkamp, B. Notheisen, C. Beer, D. Dauer, and C. Weinhardt, “A blockchain-based smart grid: towards sustainable local energy markets,” Computer Science-Research and Development , vol. 33, no. 1-2, pp. 207–214, 2018

    2018

  19. [28]

    Blockchain based decentralized management of demand response programs in smart energy grids,

    C. Pop, T. Cioara, M. Antal, I. Anghel, I. Salomie, and M. Bertoncini, “Blockchain based decentralized management of demand response programs in smart energy grids,” Sensors, vol. 18, no. 1, p. 162, 2018

    2018

  20. [29]

    Blockchain for smart grid resilience: Exchanging distributed energy at speed, scale and security,

    M. Mylrea and S. N. G. Gourisetti, “Blockchain for smart grid resilience: Exchanging distributed energy at speed, scale and security,” in 2017 Resilience Week (RWS) . IEEE, 2017, pp. 18–23

    2017

  21. [30]

    Blockchains and smart contracts for the internet of things,

    K. Christidis and M. Devetsikiotis, “Blockchains and smart contracts for the internet of things,” Ieee Access, vol. 4, pp. 2292–2303, 2016

    2016

  22. [31]

    Blockchain platform for industrial internet of things,

    A. Bahga and V . K. Madisetti, “Blockchain platform for industrial internet of things,” Journal of Software Engineering and Applications , vol. 9, no. 10, p. 533, 2016

    2016

  23. [32]

    Can blockchain strengthen the internet of things?

    N. Kshetri, “Can blockchain strengthen the internet of things?” IT professional, vol. 19, no. 4, pp. 68–72, 2017

    2017

  24. [33]

    Managing iot devices using blockchain platform,

    S. Huh, S. Cho, and S. Kim, “Managing iot devices using blockchain platform,” in 2017 19th international conference on advanced commu- nication technology (ICACT) . IEEE, 2017, pp. 464–467

    2017

  25. [34]

    Blockchain in government: Ben- efits and implications of distributed ledger technology for information sharing,

    S. Ølnes, J. Ubacht, and M. Janssen, “Blockchain in government: Ben- efits and implications of distributed ledger technology for information sharing,” 2017

    2017

  26. [35]

    Risks and opportunities for systems using blockchain and smart contracts. data61,

    M. Staples, S. Chen, S. Falamaki, A. Ponomarev, P. Rimba, A. Tran, I. Weber, X. Xu, and J. Zhu, “Risks and opportunities for systems using blockchain and smart contracts. data61,” 2017

    2017

  27. [36]

    The blockchain anomaly,

    C. Natoli and V . Gramoli, “The blockchain anomaly,” in Network Computing and Applications (NCA), 2016 IEEE 15th International Symposium on. IEEE, 2016, Conference Proceedings, pp. 310–317

    2016

  28. [37]

    The blockchain rev- olution: An analysis of regulation and technology related to distributed ledger technologies,

    H. Kakavand, N. Kost De Sevres, and B. Chilton, “The blockchain rev- olution: An analysis of regulation and technology related to distributed ledger technologies,” Bart, The Blockchain Revolution: An Analysis of Regulation and Technology Related to Distributed Ledger Technolog...

    2017

  29. [38]

    The political economy of bitcoin,

    J. R. Hendrickson, T. L. Hogan, and W. J. Luther, “The political economy of bitcoin,” Economic Inquiry , vol. 54, no. 2, pp. 925–939, 2016

    2016

  30. [39]

    Digital currencies: Principles, trends, opportunities, and risks,

    P. Tasca, “Digital currencies: Principles, trends, opportunities, and risks,” Trends, Opportunities, and Risks (September 7, 2015) , 2015

    2015

  31. [40]

    In code we trust?

    M. Fr ¨owis and R. B ¨ohme, “In code we trust?” in Data Privacy Management, Cryptocurrencies and Blockchain Technology. Springer, 2017, pp. 357–372

    2017

  32. [41]

    Rethinking permissioned blockchains,

    M. Vukoli ´c, “Rethinking permissioned blockchains,” in Proceedings of the ACM Workshop on Blockchain, Cryptocurrencies and Contracts . ACM, 2017, pp. 3–7

    2017

  33. [42]

    The truth about blockchain,

    M. Iansiti and K. R. Lakhani, “The truth about blockchain,” Harvard Business Review, vol. 95, no. 1, pp. 118–127, 2017

    2017

  34. [44]

    Secure and trustable electronic medical records sharing using blockchain,

    A. Dubovitskaya, Z. Xu, S. Ryu, M. Schumacher, and F. Wang, “Secure and trustable electronic medical records sharing using blockchain,” in AMIA Annual Symposium Proceedings, vol. 2017. American Medical Informatics Association, 2017, p. 650

    2017

  35. [45]

    Infrastructural grind: introducing blockchain technology in the shipping domain,

    K. Jabbar and P. Bjørn, “Infrastructural grind: introducing blockchain technology in the shipping domain,” in Proceedings of the 2018 ACM Conference on Supporting Groupwork . ACM, 2018, pp. 297–308

    2018

  36. [46]

    The use of authentication technology blockchain platform for the marine industry,

    D. G. Mamunts, V . E. Marley, L. S. Kulakov, E. M. Pastushok, and A. V . Makshanov, “The use of authentication technology blockchain platform for the marine industry,” in 2018 IEEE Conference of Russian Young Researchers in Electrical and Electronic Engineering (EICon- Rus). I...

    2018

  37. [47]

    The application of blockchain technology in the maritime industry,

    K. Czachorowski, M. Solesvik, and Y . Kondratenko, “The application of blockchain technology in the maritime industry,” in Green IT Engineering: Social, Business and Industrial Applications . Springer, 2019, pp. 561–577

    2019

  38. [48]

    Blockchain platform: Ethereum , https://www.ethereum.org/

  39. [49]

    Blockchain platform: EOS , https://eos.io/

  40. [50]

    Blockchain platform: Lisk , https://lisk.io/

  41. [51]

    Blockchain platform: Bitcoin , https://bitcoin.org/en/

  42. [52]

    Blockchain platform: RootStock , https://www.rsk.co/

  43. [53]

    Blockchain platform: Hyperledger fabric, https://www.hyperledger.org/ projects/fabric

  44. [54]

    Ethereums white paper , 2014, https://github

    Ethereum Foundation. Ethereums white paper , 2014, https://github. com/ethereum/wiki/wiki/White-Paper

    2014

  45. [55]

    Summary of Ethereum Upgradeable Smart Contract Research and Development , https://blog.indorse.io/ ethereum-upgradeable-smart-contract-strategies-456350d0557c

  46. [56]

    Lessons learned from implementing a privacy-preserving smart contract in ethereum,

    A. Unterweger, F. Knirsch, C. Leixnering, and D. Engel, “Lessons learned from implementing a privacy-preserving smart contract in ethereum,” in New Technologies, Mobility and Security (NTMS), 2018 9th IFIP International Conference on . IEEE, 2018, pp. 1–5

    2018

  47. [57]

    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,” in International Conference on Financial Cryptography and Data Security . Springer, 2016, pp. 79–94

    2016

  48. [58]

    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,” in 2018 International Workshop on Blockchain Oriented Software Engineering (IWBOSE) . IEEE, 2018, pp. 2–8

    2018

  49. [59]

    Smart contract programming languages on blockchains: An empirical evaluation of usability and security,

    R. M. Parizi, A. Dehghantanha et al. , “Smart contract programming languages on blockchains: An empirical evaluation of usability and security,” in International Conference on Blockchain. Springer, 2018, pp. 75–91

    2018

  50. [60]

    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?” in 2018 International Workshop on Blockchain Oriented Software Engineering (IWBOSE) . IEEE, 2018, pp. 19–25

    2018

  51. [61]

    An overview of smart contract: architecture, applications, and future trends,

    S. Wang, Y . Yuan, X. Wang, J. Li, R. Qin, and F.-Y . Wang, “An overview of smart contract: architecture, applications, and future trends,” in 2018 IEEE Intelligent Vehicles Symposium (IV) . IEEE, 2018, pp. 108–113

    2018

  52. [62]

    Making smart contracts smarter,

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

    2016

  53. [63]

    MAIAN: automatic tool for finding trace vulnerabilities in Ethereum smart contracts, https://github.com/MAIAN-tool/MAIAN

  54. [64]

    Zeus: Analyzing safety of smart contracts,

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

    2018

  55. [65]

    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

  56. [66]

    Securify: Practical security analysis of smart contracts,

    P. Tsankov, A. Dan, D. Drachsler-Cohen, A. Gervais, F. Buenzli, and M. Vechev, “Securify: Practical security analysis of smart contracts,” in Proceedings of the 2018 ACM SIGSAC Conference on Computer and Communications Security . ACM, 2018, pp. 67–82

    2018

  57. [67]

    Towards verifying ethereum smart contract bytecode in isabelle/hol,

    S. Amani, M. B ´egel, 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. ACM, 2018, pp. 66–77

    2018

  58. [68]

    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,” in In- ternational Symposium on Automated Technology for Verification and Analysis. Springer, 2018, pp. 513–520

    2018

  59. [69]

    Formal verification of smart contracts based on users and blockchain behaviors models,

    T. Abdellatif and K.-L. Brousmiche, “Formal verification of smart contracts based on users and blockchain behaviors models,” in 2018 9th IFIP International Conference on New Technologies, Mobility and Security (NTMS). IEEE, 2018, pp. 1–5

    2018

  60. [70]

    Understanding ethereum via graph analysis,

    T. Chen, Y . Zhu, Z. Li, J. Chen, X. Li, X. Luo, X. Lin, and X. Zhang, “Understanding ethereum via graph analysis,” in Proc. INFOCOM , 2018

    2018

  61. [71]

    Under-optimized smart contracts devour your money,

    T. Chen, X. Li, X. Luo, and X. Zhang, “Under-optimized smart contracts devour your money,” in Software Analysis, Evolution and Reengineering (SANER), 2017 IEEE 24th International Conference on . IEEE, 2017, Conference Proceedings, pp. 442–446

    2017

  62. [72]

    Formal specification technique in smart contract verification,

    S.-M. Lee, S. Park, and Y . B. Park, “Formal specification technique in smart contract verification,” in 2019 International Conference on Platform Technology and Service (PlatCon) . IEEE, 2019, pp. 1–4

    2019

  63. [73]

    Formal modeling and verifica- tion of smart contracts,

    X. Bai, Z. Cheng, Z. Duan, and K. Hu, “Formal modeling and verifica- tion of smart contracts,” in Proceedings of the 2018 7th International Conference on Software and Computer Applications. ACM, 2018, pp. 322–326. 20

    2018

  64. [74]

    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. Stefanescuet al., “Kevm: A complete formal semantics of the ethereum virtual machine,” in 2018 IEEE 31st Computer Security Foundations Symposium (CSF) . IEEE, 2018, pp. 204–217

    2018

  65. [75]

    Smartinspect: solidity smart contract inspector,

    S. Bragagnolo, H. Rocha, M. Denker, and S. Ducasse, “Smartinspect: solidity smart contract inspector,” in 2018 International Workshop on Blockchain Oriented Software Engineering (IWBOSE) . IEEE, 2018, pp. 9–18

    2018

  66. [76]

    A survey of attacks on ethereum smart contracts (sok),

    N. Atzei, M. Bartoletti, and T. Cimoli, “A survey of attacks on ethereum smart contracts (sok),” in International Conference on Principles of Security and Trust. Springer, 2017, Conference Proceedings, pp. 164– 186

    2017

  67. [77]

    An empirical analysis of smart contracts: platforms, applications, and design patterns,

    M. Bartoletti and L. Pompianu, “An empirical analysis of smart contracts: platforms, applications, and design patterns,” in International Conference on Financial Cryptography and Data Security . Springer, 2017, pp. 494–509

    2017

  68. [78]

    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

  69. [79]

    Security, performance, and applications of smart contracts: A systematic survey,

    S. Rouhani and R. Deters, “Security, performance, and applications of smart contracts: A systematic survey,” IEEE Access, 2019

    2019

  70. [80]

    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,” in Interna- tional Conference on Computer Aided Verification . Springer, 2018, pp. 51–78

    2018

  71. [81]

    A semantic framework for the security analysis of ethereum smart contracts,

    ——, “A semantic framework for the security analysis of ethereum smart contracts,” in International Conference on Principles of Security and Trust. Springer, 2018, pp. 243–269

    2018

  72. [82]

    Security vulnerabilities in ethereum smart contracts,

    A. Mense and M. Flatscher, “Security vulnerabilities in ethereum smart contracts,” in Proceedings of the 20th International Conference on Information Integration and Web-based Applications & Services . ACM, 2018, pp. 375–380

    2018

  73. [83]

    A survey of blockchain security issues and challenges

    I.-C. Lin and T.-C. Liao, “A survey of blockchain security issues and challenges.” IJ Network Security , vol. 19, no. 5, pp. 653–659, 2017

    2017

  74. [84]

    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

  75. [86]

    Cybercriminal minds: an investigative study of cryptocurrency abuses in the dark web,

    S. Lee, C. Yoon, H. Kang, Y . Kim, Y . Kim, D. Han, S. Son, and S. Shin, “Cybercriminal minds: an investigative study of cryptocurrency abuses in the dark web,” in Network and Distributed System Security Symposium. Internet Society, 2019, pp. 1–15

    2019

  76. [87]

    A survey of tools for analyzing ethereum smart contracts,

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

    2019

  77. [88]

    Understanding The DAO Attack , 2016, https://www.coindesk.com/ understanding-dao-hack-journalists/

    2016

  78. [89]

    An In-Depth Look at the Parity Multisig Bug , 2016, http:// hackingdistributed.com/2017/07/22/deep-dive-parity-bug/

    2016

  79. [90]

    Smart contracts-dumb idea,

    K. O’hara, “Smart contracts-dumb idea,” IEEE Internet Computing , vol. 21, no. 2, pp. 97–101, 2017

    2017

  80. [91]

    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, and N. Swamy, “Formal verification of smart contracts: Short paper,” in Proceedings of the 2016 ACM Workshop on Programming Languages and Analysis for...

    2016

  81. [92]

    Fether: An extensible definitional interpreter for smart-contract verifications in coq

    Z. Yang and H. Lei, “Fether: An extensible definitional interpreter for smart-contract verifications in coq.” IEEE Access, 2019

    2019

  82. [93]

    A hybrid formal verification system in coq for ensuring the reliability and security of ethereum-based service smart contracts,

    Z. Yang, H. Lei, and W. Qian, “A hybrid formal verification system in coq for ensuring the reliability and security of ethereum-based service smart contracts,” arXiv preprint arXiv:1902.08726 , 2019

    1902 arXiv

  83. [94]

    Validation of de- centralised smart contracts through game theory and formal methods,

    G. Bigi, A. Bracciali, G. Meacci, and E. Tuosto, “Validation of de- centralised smart contracts through game theory and formal methods,” in Programming Languages with Applications to Biology and Security . Springer, 2015, pp. 142–161

    2015

  84. [95]

    Formal process virtual machine for smart contracts verification,

    Z. Yang, “Formal process virtual machine for smart contracts verification,” International Journal of Performability Engineering ,

  85. [96]

    Formal specification and verification of smart contracts for azure blockchain,

    S. K. Lahiri, S. Chen, Y . Wang, and I. Dillig, “Formal specification and verification of smart contracts for azure blockchain,” arXiv preprint arXiv:1812.08829, 2018

    2018 arXiv

  86. [97]

    Smt-based verification of solidity smart contracts,

    L. Alt and C. Reitwiessner, “Smt-based verification of solidity smart contracts,” in International Symposium on Leveraging Applications of Formal Methods. Springer, 2018, pp. 376–388

    2018

  87. [98]

    Empir- ical vulnerability analysis of automated smart contracts security testing on blockchains,

    R. M. Parizi, A. Dehghantanha, K.-K. R. Choo, and A. Singh, “Empir- ical vulnerability analysis of automated smart contracts security testing on blockchains,” in Proceedings of the 28th Annual International Conference on Computer Science and Software Engineering . IBM Corp., 2...

    2018

  88. [99]

    Understanding blockchain consensus models,

    A. Baliga, “Understanding blockchain consensus models,” in Persistent, 2017

    2017

  89. [100]

    Decentralized networks: The future internet,

    I. Kremenova and M. Gajdos, “Decentralized networks: The future internet,” Mobile Networks and Applications , pp. 1–8, 2019

    2019

  90. [101]

    Comparison of ethereum, hyperledger fabric and corda,

    M. Valenta and P. Sandner, “Comparison of ethereum, hyperledger fabric and corda,” [ebook] Frankfurt School, Blockchain Center, 2017

    2017

  91. [102]

    A next-generation smart contract and decentralized application platform,

    V . Buterin et al., “A next-generation smart contract and decentralized application platform,” white paper, 2014

    2014

  92. [103]

    Solidity source compiler , http://solidity.readthedocs.io/en/develop/ installing-solidity.html

  93. [104]

    Dannen, Introducing Ethereum and Solidity

    C. Dannen, Introducing Ethereum and Solidity . Springer, 2017

    2017

  94. [105]

    Ethereum Wallet - MyCrypto , https://alterdice.com/

  95. [106]

    Ethereum Wallet - MyEtherWallet, https://www.myetherwallet.com/

  96. [107]

    Ethereum Wallet - MetaMask , https://metamask.io/

  97. [108]

    Ethereum Wallet - MyCrypto , https://mycrypto.com/account

  98. [109]

    Approaches to front-end iot application de- velopment for the ethereum blockchain,

    M. Pusti ˇsek and A. Kos, “Approaches to front-end iot application de- velopment for the ethereum blockchain,” Procedia Computer Science , vol. 129, pp. 410–419, 2018

    2018

  99. [110]

    The Ethereum block explorer , https://etherscan.io/

  100. [111]

    19 deadly sins of software security,

    M. Howard, D. LeBlanc, and J. Viega, “19 deadly sins of software security,” Programming Flaws and How to Fix Them , 2005

    2005

  101. [112]

    Seven pernicious kingdoms: A taxonomy of software security errors,

    K. Tsipenyuk, B. Chess, and G. McGraw, “Seven pernicious kingdoms: A taxonomy of software security errors,” IEEE Security & Privacy , vol. 3, no. 6, pp. 81–84, 2005

    2005

  102. [113]

    Automatically patching errors in deployed software,

    J. H. Perkins, S. Kim, S. Larsen, S. Amarasinghe, J. Bachrach, M. Carbin, C. Pacheco, F. Sherwood, S. Sidiroglou, G. Sullivan et al., “Automatically patching errors in deployed software,” in Proceedings of the ACM SIGOPS 22nd symposium on Operating systems principles. ACM, 200...

    2009

  103. [114]

    Setting standards for altering and undoing smart contracts,

    B. Marino and A. Juels, “Setting standards for altering and undoing smart contracts,” in International Symposium on Rules and Rule Markup Languages for the Semantic Web . Springer, 2016, pp. 151– 166

    2016

  104. [115]

    Ethereum Classic Network , https://ethereumclassic.org/

  105. [116]

    The Ethereum Classic 51 Percentage attack is the height of Crypto-Irony , https://breakermag.com/ the-ethereum-classic-51-attack-is-the-height-of-crypto-irony/

  106. [117]

    The parity wallet hack explained,

    S. Palladino, “The parity wallet hack explained,” July-2017.[Online]. Available: https://blog. zeppelin. solutions/on-the-parity-wallet- multisig-hack-405a8c12e8f7, 2017

    2017

  107. [118]

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

    H. Qureshi, “A hacker stole usd 31 m of ether-how it happened, and what it means for ethereum,” Appeared at FreeCodeCamp https://medium. freecodecamp. org/a-hacker-stole-31m-of-ether-how- ithappened-and-what-it-means-for-ethereum-9e5dc29e33ce, 2017

    2017

  108. [119]

    Parity Wallet Library , https://github.com/paritytech/parity/blob/ 4d08e7b0aec46443bf26547b17d10cb302672835/js/src/contracts/ snippets/enhanced-wallet.sol

  109. [120]

    Contract security,

    K. Iyer and C. Dannen, “Contract security,” in Building Games with Ethereum Smart Contracts . Springer, 2018, pp. 91–127

    2018

  110. [121]

    Ethereum Proposal To Resurrect Disabled 360 Mln Dollars Parity Contract Shut Down , https://cointelegraph.com/news/ ethereum-proposal-to-resurrect-disabled-360-mln-parity-contract-shut-down

  111. [122]

    com/2017/07/22/deep-dive-parity-bug/

    An In-Depth Look at the Parity Multisig Bug , http://hackingdistributed. com/2017/07/22/deep-dive-parity-bug/

    2017

  112. [123]

    Integer Overflow and Underflow attacks on Smart contracts , https:// blockgeeks.com/guides/underflow-attacks-smart-contracts/

  113. [124]

    Ethereum Homestead Documentation, http://ethdocs.org/en/latest/ether. html

  114. [125]

    Ethereum Known Attacks , https://consensys.github.io/ smart-contract-best-practices/known attacks/

  115. [126]

    Stackguard: Automatic adaptive detection and prevention of buffer-overflow attacks

    C. Cowan, C. Pu, D. Maier, J. Walpole, P. Bakke, S. Beattie, A. Grier, P. Wagle, Q. Zhang, and H. Hinton, “Stackguard: Automatic adaptive detection and prevention of buffer-overflow attacks.” in USENIX Secu- rity Symposium, vol. 98. San Antonio, TX, 1998, pp. 63–78

    1998

  116. [127]

    Pointguardtm: Pro- tecting pointers from buffer overflow vulnerabilities,

    C. Cowan, S. Beattie, J. Johansen, and P. Wagle, “Pointguardtm: Pro- tecting pointers from buffer overflow vulnerabilities,” in Proceedings of the 12th conference on USENIX Security Symposium , vol. 12, 2003, pp. 91–104. 21

    2003

  117. [128]

    Baggy bounds checking: An efficient and backwards-compatible defense against out- of-bounds errors

    P. Akritidis, M. Costa, M. Castro, and S. Hand, “Baggy bounds checking: An efficient and backwards-compatible defense against out- of-bounds errors.” in USENIX Security Symposium , 2009, pp. 51–66

    2009

  118. [129]

    Light-weight bounds check- ing,

    N. Hasabnis, A. Misra, and R. Sekar, “Light-weight bounds check- ing,” in Proceedings of the Tenth International Symposium on Code Generation and Optimization . ACM, 2012, pp. 135–144

    2012

  119. [130]

    Easyflow: Keep ethereum away from overflow,

    J. Gao, H. Liu, C. Liu, Q. Li, Z. Guan, and Z. Chen, “Easyflow: Keep ethereum away from overflow,” inProceedings of the 41st International Conference on Software Engineering: Companion Proceedings. IEEE Press, 2019, pp. 23–26

    2019

  120. [131]

    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 , 2018

    2018 arXiv

  121. [132]

    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,” in Proceedings of the 40th International Conference on Software Engineering: Companion Proceeedings. ACM, 2018, pp. 65–68

    2018

  122. [133]

    Blockchain disruption and smart contracts,

    L. W. Cong and Z. He, “Blockchain disruption and smart contracts,” The Review of Financial Studies , vol. 32, no. 5, pp. 1754–1797, 2019

    2019

  123. [134]

    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

  124. [135]

    A concurrent perspective on smart contracts,

    I. Sergey and A. Hobor, “A concurrent perspective on smart contracts,” in International Conference on Financial Cryptography and Data Security. Springer, 2017, Conference Proceedings, pp. 478–493

    2017

  125. [136]

    Adding concurrency to smart contracts,

    T. Dickerson, P. Gazzillo, M. Herlihy, and E. Koskinen, “Adding concurrency to smart contracts,” inProceedings of the ACM Symposium on Principles of Distributed Computing . ACM, 2017, Conference Proceedings, pp. 303–312

    2017

  126. [137]

    Smart-contract execution with concurrent block building,

    L. Yu, W.-T. Tsai, G. Li, Y . Yao, C. Hu, and E. Deng, “Smart-contract execution with concurrent block building,” in 2017 IEEE Symposium on Service-Oriented System Engineering (SOSE) . IEEE, 2017, pp. 160–167

    2017

  127. [138]

    Scalable blockchain based smart contract execution,

    Z. Gao, L. Xu, L. Chen, N. Shah, Y . Lu, and W. Shi, “Scalable blockchain based smart contract execution,” in 2017 IEEE 23rd In- ternational Conference on Parallel and Distributed Systems (ICPADS). IEEE, 2017, pp. 352–359

    2017

  128. [139]

    A security case study for blockchain games,

    T. Min and W. Cai, “A security case study for blockchain games,” arXiv preprint arXiv:1906.05538 , 2019

    1906 arXiv

  129. [140]

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

    I. Nikoli ´c, A. Kolluri, I. Sergey, P. Saxena, and A. Hobor, “Finding the greedy, prodigal, and suicidal contracts at scale,” arXiv preprint arXiv:1802.06038, 2018

    2018 arXiv

  130. [141]

    Mythril - Smart contract security analysis tool , https://github.com/ ConsenSys/mythril

  131. [142]

    Smartcheck: Static analysis of ethereum smart contracts,

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

    2018

  132. [143]

    Smart contracts–how will blockchain technology affect contractual practices?

    K. Lauslahti, J. Mattila, and T. Seppala, “Smart contracts–how will blockchain technology affect contractual practices?” Etla Reports , no. 68, 2017

    2017

  133. [145]

    ietf.org/html/rfc7061

    XACML - eXtensible Access Control Markup Language , https://tools. ietf.org/html/rfc7061

  134. [146]

    Z3: An efficient smt solver,

    L. De Moura and N. Bjørner, “Z3: An efficient smt solver,” in International conference on Tools and Algorithms for the Construction and Analysis of Systems . Springer, 2008, pp. 337–340

    2008

  135. [147]

    Souffl ´e: On synthesis of program analyzers,

    H. Jordan, B. Scholz, and P. Suboti ´c, “Souffl ´e: On synthesis of program analyzers,” in International Conference on Computer Aided Verification. Springer, 2016, pp. 422–430

    2016

  136. [148]

    A random graph model for massive graphs,

    W. Aiello, F. Chung, and L. Lu, “A random graph model for massive graphs,” in STOC, vol. 2000. Citeseer, 2000, pp. 1–10

    2000

  137. [149]

    Random graphs with clustering,

    M. E. Newman, “Random graphs with clustering,” Physical review letters, vol. 103, no. 5, p. 058701, 2009

    2009

  138. [150]

    Systematic topology analysis and generation using degree correlations,

    P. Mahadevan, D. Krioukov, K. Fall, and A. Vahdat, “Systematic topology analysis and generation using degree correlations,” in ACM SIGCOMM Computer Communication Review , vol. 36, no. 4. ACM, 2006, pp. 135–146

    2006

  139. [151]

    Overview of metrics and their corre- lation patterns for multiple-metric topology analysis on heterogeneous graph ensembles,

    G. Bounova and O. De Weck, “Overview of metrics and their corre- lation patterns for multiple-metric topology analysis on heterogeneous graph ensembles,” Physical Review E, vol. 85, no. 1, p. 016117, 2012

    2012

  140. [152]

    Separation logic: A logic for shared mutable data structures,

    J. C. Reynolds, “Separation logic: A logic for shared mutable data structures,” in Proceedings 17th Annual IEEE Symposium on Logic in Computer Science. IEEE, 2002, pp. 55–74

    2002

  141. [153]

    Lolisa: Formal syntax and semantics for a subset of the solidity programming language,

    Z. Yang and H. Lei, “Lolisa: Formal syntax and semantics for a subset of the solidity programming language,” arXiv preprint arXiv:1803.09885, 2018

    2018 arXiv

  142. [154]

    Securify - Security scanner for Ethereum smart contracts , https:// securify.chainsecurity.com/

  143. [155]

    docker.com/r/hrishioa/oyente/

    Securify - Security scanner for Ethereum smart contracts , https://hub. docker.com/r/hrishioa/oyente/

  144. [156]

    com/melonproject/oyente

    Git repository - An Analysis Tool for Smart Contracts , https://github. com/melonproject/oyente

  145. [157]

    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

  146. [158]

    Solidity parsing using smacc: Challenges and irregularities,

    H. Rocha, S. Ducasse, M. Denker, and J. Lecerf, “Solidity parsing using smacc: Challenges and irregularities,” in Proceedings of the 12th edition of the International Workshop on Smalltalk Technologies . ACM, 2017, p. 2

    2017

  147. [159]

    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,” in 27th {USENIX} Security Symposium ({USENIX} Security 18), 2018, pp. 1317–1333

    2018

  148. [160]

    From datalog to flix: A declarative language for fixed points on lattices,

    M. Madsen, M.-H. Yee, and O. Lhot ´ak, “From datalog to flix: A declarative language for fixed points on lattices,” in ACM SIGPLAN Notices, vol. 51, no. 6. ACM, 2016, pp. 194–208

    2016

  149. [2018]

    Available: http://dx.doi.org/10.23940/ijpe.18.08.p9

    [Online]. Available: http://dx.doi.org/10.23940/ijpe.18.08.p9. 17261734

    doi

Pith tools

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