Static analysis ethereum smart contracts

Why is it important to test smart contracts? Testing smart contracts is important for the following reasons: 1. Smart contracts are high-value applications Smart contracts often deal with high-value financial assets, especially in industries like decentralized finance DeFi , and valuable items, such as non-fungible tokens NFTs. As such, minor vulnerabilities in smart contracts can and often lead to massive, irrecoverable losses for users.

Comprehensive testing can, however, expose errors in smart contract code and reduce security risks before deployment. While traditional developers may be used to fixing software bugs after launching, Ethereum development leaves little room for patching security flaws once a smart contract is live on the blockchain. While upgradeability mechanisms for smart contracts, such as proxy patterns, these can be difficult to implement.

Besides reducing immutability and introducing complexity, upgrades often demand complex governance processes. For the most part, upgrades should be considered a last resort and avoided unless necessary. Detecting potential vulnerabilities and flaws in your smart contract during the pre-launch phase reduces the need for a logic upgrade. Automated testing for smart contracts 1.

Functional testing Functional testing verifies the functionality of a smart contract and provides assurance that each function in the code works as expected. Functional testing requires understanding how your smart contract should behave in certain conditions.

Then you can test each function by running computations with selected values and comparing the returned output with the expected output. Functional testing covers three methods: unit testing, integration testing, and system testing. Unit testing Unit testing involves testing individual components in a smart contract for correctness. A unit test is simple, quick to run, and provides a clear idea of what went wrong if the test fails. Unit tests are crucial for smart contract development, especially if you need to add new logic to the code.

You can verify the behavior of each function and confirm that it executes as intended. Running a unit test often requires creating assertions—simple, informal statements specifying requirements for a smart contract. Unit testing can then be used to test each assertion and see if it holds true under execution. Examples of contract-related assertions include: i. In integration testing, individual components of the smart contract are tested together.

This approach detects errors arising from interactions between different components of a contract or across multiple contracts. You should use this method if you have a complex contract with multiple functions or one that interfaces with other contracts. Integration testing can be useful for ensuring that things like inheritance and dependency injection work properly. System testing System testing is the final phase of functional testing for smart contracts.

A system evaluates the smart contract as one fully integrated product to see if it performs as specified in the technical requirements. A good way to perform system testing on a smart contract is to deploy it on a production-like environment, such as a testnet or development network. System testing is important because you cannot change code once the contract is deployed in the main EVM environment.

Both techniques, however, use different approaches for finding defects in contract code. Static analysis Static analysis examines the source code or bytecode of a smart contract before execution. This means you can debug contract code without actually running the program. Static analyzers can detect common vulnerabilities in Ethereum smart contracts and aid compliance with best practices.

Dynamic analysis Dynamic analysis techniques require executing the smart contract in a runtime environment to identify issues in your code. Dynamic code analyzers observe contract behaviors during execution and generate a detailed report of identified vulnerabilities and property violations. Fuzzing is an example of a dynamic analysis technique for testing contracts. During fuzz testing, a fuzzer feeds your smart contract with malformed and invalid data and monitors how the contract responds to those inputs.

Like any program, smart contracts rely on inputs provided by users to execute functions. SWC covers a range of 36 vulnerabilities, but 22 of our categories are missing. Both community classifications seem inactive: SWC was last updated in March , and the DASP 10 website with the first iteration of the project is dated For other summaries, differing in breadth and depth, see the surveys Almakhour et al.

We discuss four groups of methods: static code analysis, dynamic code analysis, formal specification and verification, and miscellany. The distinction between static analysis and formal methods is to some extent arbitrary, as the latter are mostly used in a static context. Moreover, methods like symbolic execution regularly use formal methods as a black box. A key difference is the aspiration of formal methods to be rigorous, requiring correctness and striving for completeness.

In this sense abstract interpretation should be rather considered a formal method, but it resembles symbolic execution and therefore is presented there. The analysis starts either from the source or the machine code of the contract. In most cases, the aim is to identify code patterns that indicate vulnerabilities. Some tools also compute input data to trigger the suspected vulnerability and check whether the attack has been effective, thereby eliminating false positives.

To put the various methods into perspective, we take a closer look at the process of compiling a program from a high-level language like Solidity to machine code Aho et al. The sequence of characters first becomes a stream of lexical tokens comprising e. The parser transforms the linear stream of tokens into an abstract syntax tree AST and performs semantic checks. Now several rounds of code analysis, code optimization, and code instrumentation may take place, with the output in each round again in IR.

This last step linearizes any hierarchical structures left, by arranging code fragments into a sequence and by converting control flow dependencies to jump instructions. Such representations are readily available when starting from source code, as AST and IR are by-products of compilation. This approach is fast, but lacks accuracy if a vulnerability cannot be adequately characterized by such patterns. Recovering a control flow graph CFG from machine code is inherently more complex.

Its nodes correspond to the basic blocks of a program. A basic block is a sequence of instructions executed linearly one after the other, ending with the first instruction that potentially alters the flow of control, must notably conditional and unconditional jumps. Nodes are connected by a directed edge if the corresponding basic blocks may be executed one after the other.

The reachability of code is difficult to determine, as indirect jumps retrieve the target address from a register or the stack, where it has been stored by an earlier computation. Backward slicing resolves many situations by tracking down the origins of the jump targets. If this fails, the analysis has the choice between over- and under-approximation, by either treating all blocks as potential successors or by ignoring the undetectable successors.

Some tools go on by transforming the CFG and a specification of the vulnerability to a restricted form of Horn Logic called DataLog, which is not computationally universal, but admits efficient reasoning algorithms see e. Soufle, Starting from the CFG, decompilation attempts to reverse also the other phases of the compilation process, with the aim to obtain source from machine code.

The result is intended for manual inspection by humans, as it usually is not fully functional and does not compile. Any operation on such symbols results in a symbolic expression that is passed to the next operation. In the case of a fork, all branches are explored, but they are annotated with complementary symbolic conditions that restrict the symbols to those values that will lead to the execution of the particular branch.

At intervals, an SMT Satisfiability Modulo Theory solver is invoked to check whether the constraints on the current path are still simultaneously satisfiable. If they are contradictory, the path does not correspond to an actual execution trace and can be skipped. Otherwise, exploration continues. When symbolic execution reaches code that matches a vulnerability pattern, a potential vulnerability is reported.

If, in addition, the SMT solver succeeds in computing a satisfying assignment for the constraints on the path, it can be used to devise an exploit that verifies the existence of the vulnerability. The effectiveness of symbolic execution is limited by several factors. First, the number of paths grows exponentially with depth, so the analysis has to stop at a certain point. Second, some aspects of the machine are difficult to model precisely, like the relationship between storage and memory cells, or complex operations like hash functions.

Third, SMT solvers are limited to certain types of constraints, and even for these, the evaluation may time out instead of detecting un satisfiability. Symbolic execution of the same path then yields formal constraints characterizing the path. After negating some constraint, the SMT solver searches for a satisfying assignment.

Using it as the input for the next cycle leads, by construction, to the exploration of a new path. This way, concolic execution achieves a better coverage of the code. Propagation rules define how tags are transformed by the instructions. Some vulnerabilities can be identified by inspecting the tags arriving at specific code locations. Taint analysis is often used in combination with other methods, like symbolic execution.

They may report vulnerabilities where there are none false positives, unsoundness , and may fail to detect vulnerabilities present in the code false negatives, incompleteness. The first limitation arises from the inability to specify necessary conditions for the presence of vulnerabilities that can be effectively checked. The second one is a consequence of the infeasibly large number of computation paths to explore, and the difficulty to come up with sufficient conditions that can be checked.

Abstract interpretation Cousot and Cousot, aims at completeness by focusing on properties that can be evaluated for all execution traces. As an example, abstract interpretation may split the integer range into the three groups zero, positive, and negative values. Instead of using symbolic expressions to capture the precise result of instructions, abstract interpretation reasons about how the property of belonging to one of the three groups propagates with each instruction.

This way it may be possible to show that the divisors in the code always belong to the positive group, ruling out division by zero, for any input. The challenge is to come up with a property that is strong enough to entail the absence of a particular vulnerability, but weak enough to allow for the exploration of the search space.

Contrary to symbolic execution and most other methods, this approach does not indicate the presence of a vulnerability, but proves that a contract is definitely free from a certain vulnerability safety guarantee. The most common method is testing, where the code is run with selected inputs and its output is compared to the expected result.

Fuzzing is a technique that runs a program with a large number of randomized inputs, in order to provoke crashes or otherwise unexpected behavior. Code instrumentation augments the program with additional instructions that check for abnormal behavior or monitor performance during runtime. An attempt to exploit a vulnerability then may trigger an exception and terminate execution. As an example, a program could be systematically extended by assertions ensuring that arithmetic operations do not cause an overflow.

Machine instrumentation is similar to code instrumentation, but adds the additional checks on machine level, enforcing them for all contracts. Some authors go even further by proposing changes to the transaction semantics or the Ethereum protocol, in order to prevent vulnerabilities. While interesting from a conceptual point of view, such proposals are difficult to realize, as they require a hard fork affecting also the contracts already deployed. Mutation testing is a technique that evaluates the quality of test suites.

The source code of a program is subjected to small syntactic changes, known as mutations, which mimic common errors in software development. For example, a mutation might change a mathematical operator or negate a logical condition. If a test suite is able to detect such artificial mistakes, it is more likely that it also finds real programming errors.

Modeling smart contracts on an even higher level of abstraction offers additional benefits, like formal proofs of contract properties. The core logic of many blockchain applications can be modeled as finite state machines FSMs , with constraints guarding the transitions.

As FSMs are simple formal objects, techniques like model checking can be used to verify properties specified in variants of computation tree logic. Once the model is finished, tools translate the FSM to conventional source code, where additional functionality can be added. The high cost of errors and the small size of blockchain programs makes them a promising target for formal verification approaches.

Unlike testing, which detects the presence of bugs, formal verification aims at proving the absence of bugs and vulnerabilities. As a necessary prerequisite, the execution environment and the semantics of the programming language or the machine need to be formalized. Then functional and security properties can be added, expressed in some specification language.

Finally, automated theorem provers or semi-automatic proof assistants can be used to show that the given program satisfies the properties. Bhargavan et al. From the specification, the K framework is able to generate tools like interpreters and model-checkers, but also deductive program verifiers.

Horn logic is a restricted form of first-order logic, but still computationally universal. It forms the basis of logic-oriented programming and is attractive as a specification language, as Horn formulas can be read as if-then rules. Techniques like long-short term memory LSTM modeling, convolution neural networks or N-gram language models may achieve high test accuracy.

A common challenge is to obtain a labeled training set that is large enough and of sufficient quality. Formal reasoning and constraint solving is most frequently employed, due to the many tools integrating formal methods as a black box, like constraint solvers to prune the search space or Datalog reasoners to check intermediate representations.

Proper formal verification, automated or via proof assistants, is rare, even though smart contracts, due to their limited size and the value at stake, seem to be a promising application domain. This may be due to the specific knowledge required for this approach. Number of analysis tools employing a particular method. Next in popularity are the construction of control flow graphs 46, In the Supplementary Material , we describe the tools and list their functionalities and methods.

Number of analysis tools providing a particular functionality. Code level. More than half of the tools analyze Solidity code 86, More than half of the tools 79, Some tools go the extra length of verifying the vulnerabilities they found by providing exploits or suggesting remedies. Almost a third 41, Analysis Type. The vast majority of tools , The development of new tools has increased rapidly since , with more than half of them published open source.

Over a third of the open source tools 25 received updates in , while 19 tools were updated within the first 7 months of Publication and maintenance of tools. The numbers for include the first 7 months only. Many tools were developed as a proof-of-concept for a method described in a scientific publication, and have not been maintained since their release. While this is common practice in academia, potential users prefer tools that are maintained and where reported issues are addressed in a timely manner.

Table 8 lists twenty tools that have been around for some time, are maintained, and are apparently used. More precisely, we include a tool if it was released in or earlier, shows continuous update activities, and has some filed issues that were addressed by the authors of the tool. We exclude newer tools, since they have not yet a substantial maintenance history.

Tools published in or before that are maintained and in use. For each of them, Table 9 lists the publication, the project name and a link to a repository if available. The number of contracts per test set fourth column varies between 6 and 47 More than half of the projects also include contracts that were manually verified to be true or false positives with respect to some property, in order to serve as a ground truth.

Their number is given in the fifth column. Three collections additionally provide exploits, marked in the last column. The first group in the table refers to collections of vulnerable contracts written in Solidity. The second group in this table comprises projects aimed at the analysis of vulnerabilities, but without accompanying tool. They partially provide Ethereum addresses, Solidity sources, and analysis results.

The third and largest group consists of tools that provide test data. Two tools, VerX and Zeus, offer only analysis results, but neither the bytecode, the source code nor the deployment address of the contracts analyzed, which makes it hard to verify the results. While reentrancy is an early and well analyzed vulnerability, most others have received significantly less attention.

This uneven coverage is also reflected in the tools, which address vulnerabilities in diverse combinations, with reentrancy being the most prominent one. Collaborative efforts like the SWC registry are valuable resources, but as plain collections lack structural information and usability. We find several proposals from the community and from scholars regarding Ethereum-specific taxonomies, none of which can be considered established.

Despite the narrow scope, blockchain and Ethereum, we do not perceive a convergence of taxonomies. In fact, the proposed taxonomies often are complementary rather than extensions or refinements. This makes it difficult to map the different taxonomies to each other and leaves room for discussion.

One reason may be the continued rapid development on all levels, including blockchain protocols and blockchain programming. Another one are the different angles for categorizing vulnerabilities. For detection, it is natural to consider the causes of vulnerabilities, as this is what tools can search for, like storage locations accessible to anyone.

A second dimension are the effects of vulnerabilities, like denial of service or unauthorized withdrawal. Different causes can result in the same effect, while a technical cause may contribute to various effects. A third perspective looks at the motives of a potential attacker, like economic incentives or the demonstration of skill and power, relevant e.

Authors of tools have their own perspective; the employed methods determine how vulnerabilities are defined and related. Taxonomies mixing cause, effect and attacker intentions may be comprehensive, but are difficult to use when the aim is, for instance, to compare tools or to match suitable test sets with tools, as the vulnerabilities cannot be clearly assigned. A hierarchical, multi-level classification without overlaps, on the other hand, may be too strict to cater for multi-faceted vulnerabilities.

Altogether, we see the need for more work on differentiating and systematizing vulnerabilities as well as on assessing their severity. Static and dynamic program analysis are as old as programming, and most methods we found are well-established in program analysis at large. Early on, researchers on program analysis demonstrated that methods like symbolic execution are able to detect vulnerabilities of smart contracts and to generate exploits.

What makes blockchain programs a particularly attractive domain, is their limited size and the drastic consequences bugs may have. The former results in search spaces that are small compared e. Thus, the application of known methods within the specific context of Ethereum may also lead to new insights and refinements outside. Researchers from the blockchain community, on the other hand, occasionally present prototypes for their approaches that disregard the state of the art in program analysis.

This is not always apparent from the publication, where the authors may state in a side note that their algorithm works on control flow graphs or extracts the entry points of the contract as starting point. Only when checking the code it becomes apparent whether the tool is a proof-of-concept with heuristics tied e. Publications surveying the methods used by the tools, classify them along familiar lines, like static vs.

A technical in-depth comparison of detection approaches is still lacking, as it is beyond the scope of pure surveys. It would be desirable 1 to scrutinize which methods are suited to which extent for detecting particular vulnerabilities, or inversely, 2 to determine for each vulnerability, which methods can detect it to which degree or under which conditions. There are some frameworks that combine several tools with a unified interface to harness the power of many.

Claim vs. Each tool advertises a list of vulnerabilities that it purportedly detects. Due to the variety of methods employed, different tools may classify contracts differently, even when they seemingly address the same vulnerability. Moreover, tools may refer to incompatible taxonomies of vulnerabilities or introduce their own definition, which makes it difficult to compare the tools.

Warnings vs.

Analysis ethereum contracts static smart free sure win betting tips

Interesting. Tell how to add paper ethereum to coinbase really

Dynamic code analysis identifies defects after you run a program e. However, some coding errors might not surface during unit testing. So, there are defects that dynamic testing might miss that static code analysis can find. Slither : Slither is a Solidity static analysis framework written in Python 3.

It runs a suite of vulnerability detectors, prints visual information about contract details, and provides an API to easily write custom analyses. Further reading consensys. Your e-mail address won't be shared and will be deleted from our records after the comment is published.

If you don't want your real name to be credited alongside your comment, please specify the name you would like to use. First, Ethereum smart contracts are developed in an ad-hoc language, called Solidity, which resembles JavaScript but features specific transaction-oriented mechanisms and a number of non-standard semantic behaviours, as further described in this paper. Second, smart contracts are uploaded on the blockchain in the form of Ethereum Virtual Machine EVM bytecode, a stack-based low-level code featuring dynamic code creation and invocation and, in general, very little static information, which makes it extremely difficult to analyze.

Our Contributions. This work overviews the existing approaches taken towards formal verification of Ethereum smart contracts and discusses EtherTrust, the first sound static analysis tool for EVM bytecode. Specifically, our contributions are A survey on recent theories and tools for formal verification of Ethereum smart contracts including a systematization of existing work with an overview of the open problems and future challenges in the smart contract realm. An illustrative presentation of the small-step semantics presented by [ 15 ] with special focus on the semantics of the bytecode instructions that allow for the initiation of internal transactions.

The subtleties in the semantics of these transactions have shown to form an integral part of the attack surface in the context of Ethereum smart contracts. A review of an abstraction based on Horn clauses for soundly over-approximating the small-step executions of Ethereum bytecode [ 1 ].

A demonstration of how relevant security properties can be over-approximated and automatically verified using the static analyzer EtherTrust [ 1 ] by the example of the single-entrancy property defined in [ 15 ]. The remainder of this paper is organized as follows. Section 2 briefly overviews the Ethereum architecture, Sect. Similar to Bitcoin, network participants publish transactions to the network that are then grouped into blocks by distinct nodes the so called miners and appended to the blockchain using a proof of work PoW consensus mechanism.

The state of the system — that we will also refer to as global state — consists of the state of the different accounts populating it. Footnote 2 Transactions can alter the state of the system by either creating new contract accounts or by calling an existing account. Calls to external accounts can only transfer Ether to this account, but calls to contract accounts additionally execute the code associated to the contract.

The contract execution might alter the storage of the account or might again perform transactions — in this case we talk about internal transactions. The execution model underlying the execution of contract code is described by a virtual state machine, the Ethereum Virtual Machine EVM.

This is quasi Turing complete as the otherwise Turing complete execution is restricted by the upfront defined resource gas that effectively limits the number of execution steps. The originator of the transaction can specify the maximal gas that should be spent for the contract execution and also determines the gas price the amount of wei to pay for a unit of gas.

Upfront, the originator pays for the gas limit according to the gas price and in case of successful contract execution that did not spend the whole amount of gas dedicated to it, the originator gets reimbursed with gas that is left.

The remaining wei paid for the used gas are given as a fee to a beneficiary address specified by the miner. As the core of the EVM is a stack-based machine, the set of instructions in EVM bytecode consists mainly of standard instructions for stack operations, arithmetics, jumps and local memory access. The classical set of instructions is enriched with an opcode for the SHA3 hash and several opcodes for accessing the environment that the contract was called in.

In addition, there are opcodes for accessing and modifying the storage of the account currently running the code and distinct opcodes for performing internal call and create transactions. The execution of each instruction consumes a positive amount of gas. The sender of the transaction specifies a gas limit and exceeding it results in an exception that reverts the effects of the current transaction on the global state. In the case of nested transactions, the occurrence of an exception only reverts its own effects, but not those of the calling transaction.

We distinguish between verification approaches and design approaches. According to our terminology, the goal of verification approaches is to check smart contracts written in existing languages such as Solidity for their compliance with a security policy or specification.

In contrast, design approaches aim at facilitating the creation of secure smart contracts by providing frameworks for their development: These approaches encompass new languages which are more amenable to verification, provide a clear and simple semantics that is understandable by smart contract developers or allow for a direct encoding of desired security policies. In addition, we count works that aim at providing design patterns for secure smart contracts to this category.

From the current spectrum of analysis tools, we can find solutions in the following clusters: Static Analysis Tools for Automated Bug-Finding. Oyente [ 16 ] is a state-of-the-art static analysis tool for EVM bytecode that relies on symbolic execution.

Oyente supports a variety of pre-defined security properties, such as transaction order dependency, time-stamp dependency, and reentrancy that can be checked automatically. However, Oyente is not striving for soundness nor completeness. This is on the one hand due to the simplified semantics that serves as foundation of the analysis [ 15 ].

On the other hand, the security properties are rather syntactic or pattern based and are lacking a semantic characterization. Recently, Zhou et al. Majan [ 18 ] extends the approach taken in Oyente to trace properties that consider multiple invocations of one smart contract. As Oyente, it relies on symbolic execution that follows a simplified version of the semantics used in Oyente and uses a pattern-based approach for defining the concrete properties to be checked.

The tool covers safety properties such as prodigality and suicidality and liveness properties greediness. In contrast to the aforementioned class of tools, this line of research aims at providing formal guarantees for the analysis results.

A recently published work is the static analysis tool ZEUS [ 19 ] that analyzes smart contracts written in Solidity using symbolic model checking. The analysis proceeds by translating Solidity code to an abstract intermediate language that again is translated to LLVM bitcode. Finally, existing symbolic model checking tools for LLVM bitcode are leveraged for checking generic security properties.

ZEUS consequently only allows for analyzing contracts whose Solidity source code is made available. In addition, the semantics of the intermediate language cannot easily be reconciled with the actual Solidity semantics that is determined by its translation to EVM bytecode.

This is as the semantics of the intermediate language by design does not allow for the revocation of the global system state in the case of a failed call — which however is fundamental feature of Ethereum smart contract execution. Other tools proposed in the realm of automated static analysis for generic properties are Securify [ 20 ], Mythril [ 21 ] and Manticore [ 22 ] for analysing bytecode and SmartCheck [ 23 ] and Solgraph [ 24 ] for analyzing Solidity code.

These tools however are not accompanied by any academic paper so that the concrete analysis goals stay unspecified. This semantics, however, constitutes a sound over-approximation of the original semantics [ 26 ]. Building on top of this work, Amani et al. Hildebrandt et al.

The derived program verifier still requires the user to manually specify loop invariants on the bytecode level. Bhargavan et al. The translation supports only a fragment of the EVM bytecode and does not come with a justifying semantic argument. Dynamic Monitoring for Predefined Security Properties. Grossman et al. They propose an efficient online algorithm for discovering executions violating effectively callback freeness. Implementing a corresponding monitor in the EVM would guarantee the absence of the potentially dangerous smart contract executions, but is not compatible with the current Ethereum version and would require a hard fork.

A dynamic monitoring solution compatible with Ethereum is offered by the tool DappGuard [ 32 ]. The tool actively monitors the incoming transactions to a smart contract and leverages the tool Oyente [ 16 ], an own analysis engine and a simulation of the transaction on the testnet for judging whether the incoming transaction might cause a generic security violation such as transaction order dependency. If a transaction is considered harmful, a counter transaction killing the contract or performing some other fixes is made.

The authors claim that this transaction will be mined with high probability before the problematic one. Due to this uncertainty and the bug-finding tools used for evaluation of incoming transactions, this approach does not provide any guarantees. High-Level Languages. One line of research on high-level smart contract languages concentrates on the facilitation of secure smart contract design by limiting the language expressiveness and enforcing strong static typing discipline.

Simplicity [ 33 ] is a typed functional programming language for smart contracts that disallows loops and recursion. It is a general purpose language for smart contracts and not tailored to the Ethereum setting. Simplicity comes with a denotational semantics specified in Coq that allows for reasoning formally about Simplicity contracts. They extend the existing Idris compiler with a generator for Serpent code a Python-like high-level language for Ethereum smart contracts.

This compiler is a proof of concept and fails in compiling more advanced contracts as it cannot handle recursion. In a preliminary work, Coblenz [ 35 ] propose Obsidian, an object-oriented programming language that pursues the goal of preventing common bugs in smart contracts such as reentrancy. To this end, Obsidian makes states explicit and uses a linear type system for quantities of money. Another line of research focuses on designing languages that allow for encoding security policies that are dynamically enforced at runtime.

A first step in this direction is sketched in the preliminary work on Flint [ 36 ], a type-safe, capabilities-secure, contract-oriented programming language for smart contracts that gets compiled to EVM bytecode. Flint allows for defining caller capabilities restricting the access to security sensitive functions. These capabilities shall be enforced by the EVM bytecode created during compilation.

But so far, there is only an extended abstract available. In addition to these approaches from academia, the Ethereum foundation currently develops the high-level languages Viper [ 37 ] and Bamboo [ 38 ].

Confirm. All ireland v scotland 2022 betting calculator you were

Advice on secure Ethereum programming practices is spread out across blogs, papers, and tutorials. Many sources are outdated due to a rapid pace of development in this field. Automated vulnerability detection tools, which help detect potentially problematic language constructs, are still underdeveloped in this area. We provide a comprehensive classification of code issues in Solidity and implement SmartCheck -- an extensible static analysis tool that detects them. We evaluated our tool on a big dataset of real-world contracts and compared the results with manual audit on three contracts.

Our tool reflects the current state of knowledge on Solidity vulnerabilities and shows significant improvements over alternatives. These tools however are not accompanied by any academic paper so that the concrete analysis goals stay unspecified. This semantics, however, constitutes a sound over-approximation of the original semantics [ 26 ]. Building on top of this work, Amani et al.

Hildebrandt et al. The derived program verifier still requires the user to manually specify loop invariants on the bytecode level. Bhargavan et al. The translation supports only a fragment of the EVM bytecode and does not come with a justifying semantic argument. Dynamic Monitoring for Predefined Security Properties. Grossman et al. They propose an efficient online algorithm for discovering executions violating effectively callback freeness.

Implementing a corresponding monitor in the EVM would guarantee the absence of the potentially dangerous smart contract executions, but is not compatible with the current Ethereum version and would require a hard fork. A dynamic monitoring solution compatible with Ethereum is offered by the tool DappGuard [ 32 ]. The tool actively monitors the incoming transactions to a smart contract and leverages the tool Oyente [ 16 ], an own analysis engine and a simulation of the transaction on the testnet for judging whether the incoming transaction might cause a generic security violation such as transaction order dependency.

If a transaction is considered harmful, a counter transaction killing the contract or performing some other fixes is made. The authors claim that this transaction will be mined with high probability before the problematic one. Due to this uncertainty and the bug-finding tools used for evaluation of incoming transactions, this approach does not provide any guarantees. High-Level Languages.

One line of research on high-level smart contract languages concentrates on the facilitation of secure smart contract design by limiting the language expressiveness and enforcing strong static typing discipline. Simplicity [ 33 ] is a typed functional programming language for smart contracts that disallows loops and recursion. It is a general purpose language for smart contracts and not tailored to the Ethereum setting. Simplicity comes with a denotational semantics specified in Coq that allows for reasoning formally about Simplicity contracts.

They extend the existing Idris compiler with a generator for Serpent code a Python-like high-level language for Ethereum smart contracts. This compiler is a proof of concept and fails in compiling more advanced contracts as it cannot handle recursion. In a preliminary work, Coblenz [ 35 ] propose Obsidian, an object-oriented programming language that pursues the goal of preventing common bugs in smart contracts such as reentrancy.

To this end, Obsidian makes states explicit and uses a linear type system for quantities of money. Another line of research focuses on designing languages that allow for encoding security policies that are dynamically enforced at runtime. A first step in this direction is sketched in the preliminary work on Flint [ 36 ], a type-safe, capabilities-secure, contract-oriented programming language for smart contracts that gets compiled to EVM bytecode.

Flint allows for defining caller capabilities restricting the access to security sensitive functions. These capabilities shall be enforced by the EVM bytecode created during compilation. But so far, there is only an extended abstract available. In addition to these approaches from academia, the Ethereum foundation currently develops the high-level languages Viper [ 37 ] and Bamboo [ 38 ]. Intermediate Languages. The intermediate language Scilla [ 41 ] comes with a semantics formalized in the proof assistant Coq and therefore allows for a mechanized verification of Scilla contracts.

In addition, Scilla makes some interesting design choices that might inspire the development of future high level languages for smart contracts: Scilla provides a strict separation not only between computation and communication, but also between pure and effectful computations.

Security Patterns. These patterns encompass best coding practices such as performing calls at the end of a function, but also off-the-self solutions for common security bugs such as locking a contract for avoiding reentrancy or the integration of a mechanism that allows the contract owner to disable sensitive functionalities in the case of a bug.

Mavridou and Laszka [ 43 ] introduce a framework for designing smart contracts in terms of finite state machines. They provide a tool with a graphical editor for defining contract specifications as automata and give a translation of the constructed finite state machines to Solidity.

In addition, they present some security extensions and patterns that can be used as off-the-shelf solutions for preventing reentrancy and implementing common security challenges such as time constraints and authorization. The approach however is lacking formal foundations as neither the correctness of the translation is proven correct, nor are the security patterns shown to meet the desired security goals.

Secure Compilation of High-Level Languages. Even though there are several proposals made for new high-level languages that facilitate the design of secure smart contracts and that are more amenable to verification, none of them comes so far with a verified compiler to EVM bytecode. Such a secure compilation however is the requirement for the results shown on high-level language programs to carry over to the actual smart contracts published on the blockchain.

Specification Languages for Smart Contracts. So far, all approaches to verifying contract specific properties focus on either ad-hoc specifications in the used verification framework [ 25 , 27 , 28 , 30 ] or the insertion of assertions into existing contract code [ 39 ]. For leveraging the power of existing model checking techniques for program verification, the design of a general-purpose contract specification language would be needed.

Study of Security Policies. There has been no fundamental research made so far on the classes of security policies that might be interesting to enforce in the setting of smart contracts. In particular, it would be compelling to characterize the class of security policies that can be enforced by smart contracts within the existing EVM. Compositional Reasoning About Smart Contracts. Most research on smart contract verification focuses on reasoning about individual contracts or at most a bunch of contracts whose bytecode is fully available.

Even though there has been work observing the similarities between smart contracts and concurrent programs [ 44 ], there has been no rigorous study on compositional reasoning for smart contracts so far. As this semantics serves as a basis for the static analyzer EtherTrust, we will in the following shortly review the general layout and the most important features of the semantics.

Global State. The global state of the Ethereum blockchain is represented as a partial mapping from account addresses to accounts. External accounts carry an empty code which makes their storage inaccessible and hence irrelevant. Small-Step Relation. Transaction Environments. The transaction environment represents the static information of the block that the transaction is executed in and the immutable parameters given to the transaction as the gas prize or the gas limit.

These parameters can be accessed by distinct bytecode instructions and consequently influence the transaction execution. Call Stacks. The individual execution states of the stack represent the states of the uncompleted internal transactions performed during the execution. Semantically, halting states indicate regular halting of an internal transaction, exception states indicate exceptional halting, and regular execution states describe the state of internal transactions in progress.

Halting and exception states can only occur as top elements of the call stack as they represent terminated internal transactions. Execution Environment. The execution environment is determined upon initialization of an internal transaction execution, and it can be accessed, but not altered during the execution. Table 1. The execution of each internal transaction starts in a fresh machine state, with an empty stack, memory initialized to all zeros, and program counter and active words in memory set to zero.

Only the gas is instantiated with the gas value available for the execution. We call execution states with machine states of this form initial. Local Instructions. We use a dot notation, in order to access components of the different state parameters.

We name the components with the variable names introduced for these components in the last section written in sans-serif-style. For deciding upon the correct instruction to execute, the currently executed code that is part of the execution environment is accessed at the position of the current program counter. In this case, the exception state is entered and the execution of the current internal transaction is terminated.

Transaction Initiating Instructions. A class of instructions with a more involved semantics are those instructions initiating internal transactions. We will explain the semantics of those instructions in an intuitive way omitting technical details. In addition, the input to the call is specified by providing the corresponding local memory fragment and analogously a memory fragment for the return value.

When executing a call instruction, the specified amount of wei is transferred to the callee and the code of the callee is executed.