## 6 Industrial Efforts to Blockchain-Based Supply Chain Management: Tools
### Efforts against Computational Attacks
#### 6.2.2 Security to Smart Contracts and Their Execution Environment  
In addition to providing security to crypto-currency transactions and operations, industries also developed tools to identify vulnerabilities in smart contracts and their underlying virtual execution environment. These vulnerabilities include (but not limited to) short address stack, delegate call, blockchain ingestion, wallet theft, double-spending, cryptojacking, default visibilities, and transaction ordering dependence. In order to identify such vulnerabilities, the developed tools [86; 87; 88; 89; 90; 91] perform static analysis on source code and byte code of smart contracts, dynamic analysis of the contract execution, symbolic analysis of the contract code and execution, and verification-based analysis of smart contracts. One of the popular tool that supports identification of security vulnerabilities is SlithIR [91]. Slither translates smart contracts developed in Solidity to an intermediate representation 'SlithIR' to enable high-precision analysis via a simple API. The translation supports taint and value tracking to enable detection of complex patterns. The intermediate language includes extra details about the program when it is parsed. For example, a compiler creates a parse tree of a written-program, represents its functionality. The compiler enriches this tree with information, such as taint information, source location, and other items that could have impacted an item from control flow (e.g., resources). Furthermore, languages such as Solidity supports inheritance property, which enables functions and methods to be defined outside the scope of a given contract. An IR linearizes these methods, allowing additional transformations and processing of the contract's source code. By translating Solidity into an IR, Slither normalizes many of these quirks to better analyze the contract. For Example, contract's grammar defines an array-push as a function call to the array, and representation of this semantic would be indistinguishable from a normal function call. Slither, in contrast, treats array pushes as a specific operation, allowing further analysis of the accesses to arrays and their impact to the security of a program. Furthermore, the operators in SlithIR have a hierarchy, which enable anyone to track all the operators that write to a variable, making it trivial to write precise taint analysis. Slither also supports non-trivial variable tracking by default as identifiable by IR. This builds richer representations of contracts that allow deeper analysis of potential security vulnerabilities. For Instance, investigating a question like \"can a user control a variable\" is central to uncovering more complex vulnerabilities from a static position. Slither propagates information from function parameters to program state in an iterative way, which captures the control flow information across potentially multiple transactions. Based on the propagation, Slither enriches information and statically provide a stronger assurance to contracts for identifying existence of standard vulnerabilities that are reachable under certain suspicious conditions [91]. Ethereum graph debugger (EGD) [88] is a graphical debugger for identifying security vulnerabilities in the smart contract-based transactions and their execution environment. In contrast to typical debuggers, EGD debugger shows the whole program control flow graph and the actual execution of the transaction highlighted in red, which helps developer to see the whole execution flow and jump anywhere in a quick and graphical way. There are several key features of the debugger, e.g.,  
* Control flow graph: the CFG can be built without debugging a transaction. * Disassembler: just disassembled opcodes can be seen, from runtime and constructor. * Source mapping: snippet of code related to the selected instruction is highlighted in the editor left panel. * Debug transaction: a transaction can be debugged using the contract's CFG and the execution trace.