Source-linked AI summary

Slither: A Static Analysis Framework For Smart Contracts

Josselin Feist, Gustavo Grieco, Alex Groce

arXiv:1908.09878v1cs.SEcs.CR

TL;DR

Smart-contract deployments often contain exploitable vulnerabilities, while Solidity lacks features needed for practical static analysis. Slither converts Solidity into SlithIR and applies dataflow and taint analyses, outperforming other tools on reentrancy detection in performance, robustness, and accuracy. Its primary experiment remains limited to reentrancy detection on a limited contract set.

  • Problem

    Smart-contract deployments often contain exploitable vulnerabilities, while Solidity lacks the compiler analysis features needed for a practical static-analysis framework.

  • Method

    Slither converts Solidity ASTs into SlithIR in SSA form and applies static analyses such as dataflow and taint tracking.

  • Results

    Slither outperforms other tools in performance, robustness, and accuracy when detecting reentrancy bugs.

  • Takeaways & Limitations

    Slither supports vulnerability detection, optimization detection, code understanding, review, and extensibility through third-party tools.

  • Takeaways & Limitations

    The primary experiment is limited to reentrancy detection on a limited contract set, and its transaction-based sampling measure is not community-standardized.

Abstract

from arXiv · show

This paper describes Slither, a static analysis framework designed to provide rich information about Ethereum smart contracts. It works by converting Solidity smart contracts into an intermediate representation called SlithIR. SlithIR uses Static Single Assignment (SSA) form and a reduced instruction set to ease implementation of analyses while preserving semantic information that would be lost in transforming Solidity to bytecode. Slither allows for the application of commonly used program analysis techniques like dataflow and taint tracking. Our framework has four main use cases: (1) automated detection of vulnerabilities, (2) automated detection of code optimization opportunities, (3) improvement of the user's understanding of the contracts, and (4) assistance with code review. In this paper, we present an overview of Slither, detail the design of its intermediate representation, and evaluate its capabilities on real-world contracts. We show that Slither's bug detection is fast, accurate, and outperforms other static analysis tools at finding issues in Ethereum smart contracts in terms of speed, robustness, and balance of detection and false positives. We compared tools using a large dataset of smart contracts and manually reviewed results for 1000 of the most used contracts.

I. INTRODUCTION

Ethereum smart contracts are increasingly used but often contain exploitable vulnerabilities, creating a need for robust and practical analysis frameworks. Slither addresses this need with a Solidity-focused intermediate representation and analyses supporting security, optimization, understanding, and review.

  • Smart contracts support trustless computation across industries, but insecure deployed code has caused exploitation, financial damage, and reputational harm.
  • Existing Ethereum analysis tools use static or dynamic techniques including fuzzing, symbolic execution, taint tracking, and static analysis.
  • A suitable static-analysis framework must balance abstraction, robustness, performance, and accuracy while supporting real-world Solidity code.
  • Slither introduces SlithIR and applies dataflow and taint tracking to provide rich contract information for vulnerability detection, optimization, code understanding, and review.
  • The paper details SlithIR and its analyzers, then evaluates Slither's performance, robustness, and accuracy on a large set of actively used contracts.

A. Static Analysis

Ethereum analysis tools differ in whether they execute contracts and in how they represent and inspect code. Slither provides a static-analysis framework used for vulnerability detection, optimization detection, code understanding, and review through a multistage Solidity pipeline.

  • A. Static Analysis: Static tools analyze contracts without execution, while dynamic tools use symbolic execution, taint tracking, or fuzzing to discover vulnerabilities.
  • A. Static Analysis: GASPER and GasReduce target dead-code and loop optimizations, whereas Slither discusses patterns such as variables that could be declared constant.
  • A. Static Analysis: Slither's framework supports automated vulnerability detection, compiler-missed optimization detection, contract summaries, and API-assisted code review.
  • A. Static Analysis: Slither begins with the Solidity compiler's AST, recovers inheritance and control-flow information, and transforms the contract into SlithIR.

A. Built-in Code Analyses

Slither's built-in analyses expose variable behavior, authorization patterns, dependencies, and security issues. These analyses support detectors for vulnerabilities and costly code patterns.

  • A. Built-in Code Analyses: Slither identifies variables read and written by contracts, functions, and control-flow nodes, supporting uninitialized-variable and reentrancy detectors.
  • A. Built-in Code Analyses: Protected-function modeling checks ownership-related access patterns to reduce false positives when detecting unprotected functions.
  • A. Built-in Code Analyses: SSA-based data-dependency analysis computes intra-function and multi-transaction dependencies, classifies user-controlled tainted variables, and incorporates privilege levels.
  • B. Automated Vulnerability Detection: Slither includes more than twenty open-source bug detectors covering issues such as shadowing, uninitialized variables, reentrancy, locked ether, and arbitrary ether transfers.
  • B. Automated Vulnerability Detection: Optimization detectors identify variables that should be constant and functions that should be external because these declarations can enable compiler optimization.

D. Code Understanding

Slither's printers expose structural, behavioral, and quality information to help users understand contracts. Its API and internals also support custom analyses and third-party tools.

  • D. Code Understanding: Slither printers export inheritance, control-flow, and call-graph representations for contract inspection.
  • D. Code Understanding: Printers provide human-readable summaries containing issue counts, cyclomatic complexity, and selected contract-specific information.
  • D. Code Understanding: Slither summarizes authorization accesses and variables that can be changed by the contract owner.
  • D. Code Understanding: Users can build custom scripts through the Slither Python API, while third-party tools can perform advanced analyses or translate SlithIR to another representation.

F. Implementation

SlithIR is Slither’s hybrid intermediate representation for Solidity, using a compact instruction set attached to the control-flow graph to support analysis while preserving source semantics.

  • SlithIR represents each control-flow-graph node with up to one Solidity expression converted into a set of instructions.
  • SlithIR uses fewer than 40 instructions and relies on Slither’s control-flow graph rather than encoding internal control flow.
  • Variables in SlithIR are represented as left-values when assigned and right-values when read, including Solidity and temporary variables.
  • 3) Mappings and Arrays: SlithIR includes reference variables for dereferencing mappings and arrays.
  • 5) Calls: Slither provides distinct call instructions for low-level, high-level, built-in, internal, dynamic, library, event, and transfer calls.

7) Example:

The example shows how Solidity is translated into SlithIR and why SSA supports dependency analysis, including state-variable updates across control-flow paths and external re-entry.

  • Figure 3 presents the SlithIR representation of the Solidity code shown in Figure 2.
  • SSA: SSA assigns each variable once and defines it before use, enabling straightforward computation of def-use chains.
  • SSA: SlithIR’s SSA representation and graph-based control flow can support future bounded model checking using SAT/SMT.
  • SSA: Slither stores SlithIR both with and without SSA.
  • SSA: State variables require φ functions because their values may reflect initialization, prior function executions, or changes caused by external re-entry.

1) State Variables:

Slither handles storage references and evaluates its analyses on real-world contracts, while the paper notes representation limitations and defines the evaluation scope.

  • 1) State Variables: Alias analysis identifies all possible state-variable targets of storage references so the SSA engine can place φ functions correctly.
  • Discussion: SlithIR lacks formal semantics and is too high-level to accurately represent low-level information such as gas computation.
  • Evaluation: The evaluation covers vulnerability detection, missing optimization detection, and source-code exploration using real-world contracts.
  • Experiments: The vulnerability comparison focuses on reentrancy detectors in Slither, Securify, SmartCheck, and Solhint.
  • Experiments: The study excludes dynamic-analysis tools because the authors describe them as having scalability issues and not directly competing with static-analysis tools.

2) Metrics:

The evaluation measures speed, failure frequency, and detection quality for reentrancy analysis, including whether tools identify historically exploited vulnerabilities without treating benign warnings as valid findings.

  • 2) Metrics: Performance measures how fast a tool analyzes each contract, including compilation time when compilation is required.
  • 2) Metrics: Robustness measures how often a tool fails to parse, decompile, or analyze a contract.
  • 2) Metrics: Accuracy measures both the number of contracts flagged and the number of correct findings.
  • 1) Reentrancy: Reentrancy occurs when an external call can re-enter the calling function, potentially enabling exploitation when state changes follow that call.
  • 1) Reentrancy: Benign reentrancy warnings are counted as false positives when the apparent exploit has the same effect as two successive calls.
  • 4) Experiment 1: Slither is the only evaluated tool reported as finding the actual reentrancy used in both the DAO and SpankChain exploits.

5) Experiment 2:

Experiment 2 evaluated Slither and other tools on reentrancy detection across 1000 contracts, finding Slither fastest, most robust, and most accurate while also identifying optimization opportunities.

  • 1000 contracts were analyzed using only reentrancy detectors with a 120-second timeout.
  • Slither was the fastest tool and was typically as fast as a simple linter.
  • Slither failed for only 0.1% of contracts, compared with around 1.2% for Solhint, 10.22% for SmartCheck, and 11.20% for Securify.
  • Slither had the lowest false-positive rate at 10.9%, versus 25% for Securify, 73.6% for SmartCheck, and 91.3% for Solhint.
  • Slither outperformed the other analyzers for reentrancy detection while maintaining a low false-positive rate.
  • 54% of 1000 contracts and 56% of 35,000 contracts contained variables that could have been declared constant.
  • Detecting constant variables shows that Slither can efficiently identify practical code optimizations.

C. Code Understanding Comparison

Slither's printers support contract understanding through visual and semantic outputs, extending comparable syntactic features with information about variables, bugs, complexity, and context.

  • Code Understanding Comparison: Slither printers provide visual outputs intended to help users understand contract behavior and structure.
  • Code Understanding Comparison: Slither and Surya provide similar features, but Surya outputs AST and call-trace representations while Slither reports variables read and written.
  • Code Understanding Comparison: Slither reports bugs found, cyclomatic complexity, and high-level context information in addition to shared reporting features.
  • Code Understanding Comparison: Slither includes Surya's information and integrates more advanced information through an in-depth understanding of the codebase.
  • Threats to Validity: The primary evaluation was limited to reentrancy detection over a limited set of contracts, and some recently proposed frameworks were omitted.
  • Conclusions and Future Work: The framework is presented as fast, robust, accurate, rich in contract information, and usable for bugs, optimizations, understanding, and third-party tools.
Loading 1908.09878v1…