## 6 Results of the Blockchain Survey
### Application Layer
#### 6.3.3 Contract-Programming Vulnerabilities  
Smart contracts are programmed either in a domain-specific programming language (DSL), such as Ethereum's Solidity, or in high-level languages, such as Go, Java, and Node.js. The latter has the advantage of reducing the developer's learning cost, as pointed out by [PERSON] et al. [99]. [PERSON] [117] outlines vulnerabilities due to features of the EVM, such as immutability, missing orphan proof, vulnerabilities due to immutable bugs or mistakes, and Ether lost in the transfer. [PERSON] et al. [90] highlight programming issues. [PERSON] et al. [93] detail this by logical issues, centralization, volatile code, coding style, cost optimization, language-specific, control flow, math operations, inconsistency, data flow, and misconfiguration. [PERSON] et al. [117] additionally add uncontrolled resource consumption, external dependence, malleable entropy sources, insufficient authorization, improper validation, useless and repeated code, variable-sized parameters, improper access control, hash collision, unprotected Ether withdrawal, floating pragma, and delegate call. In the following, we briefly explain vulnerabilities found during our survey. _Delegated call injection:_ This vulnerability was first observed during an attack against the Parity wallet. In order to facilitate code reuse, the EVM provides operation code (opcode, i.e., delegatecall) for inserting a callee contract's bytecode into the bytecode of the caller contract. As described by [90; 116; 120], malicious callee contracts can directly modify the state variables of the caller contracts. Similarly, fault injection might be possible, according to [PERSON] et al. [128] and [PERSON] et al. [80]. [PERSON] et al. [80] additionally add code injection and structured query language (SQL) injection. _Erroneous visibility:_ If the function's visibility is not properly specified, it can provide unauthorized access [90; 116; 117; 119; 120; 122]. This was first observed in an attack against the Parity wallet. As a countermeasure, Solidity makes it mandatory to specify function visibility starting with version 0.5.0 [135]. Similarly, [PERSON] et al. [125] describe shadowing. _Authentication through tx.origin:_ tx.origin is a variable in Solidity and refers to the externally owned account (EOA) that initiated the transaction. It can be misused if it is applied to a contract and compromised by a phishing attack [90; 117; 120; 126; 90]. Hence, the authors of Solidity recommend not to use tx.origin for authorization [136]. _Manipulated balance:_ This vulnerability can also be called forcing Ether to contracts, according to [PERSON] et al. [90]. It occurs if a control-flow decision relies on the value of this.balance or address(this).balance, which can be used by an attacker to obtain the money. As a countermeasure, balance should not be used. _Unchecked call return values:_ This vulnerability is also called mishandled exceptions [90; 114; 126]. According to [PERSON] et al. [90], it has two variants: gasless send and unchecked send. Similarly, [PERSON] et al. [117] outline improper exception handling and mishandling, and [PERSON] et al. [101] and [PERSON] [102] unhandled exceptions. _Uninitialized storage pointer:_ This vulnerability was caused by Solidity's treatment of uninitialized compound local variables (overwriting from slot 0) and is eliminated by version 0.5.0 [135], according to [PERSON] et al. [90]. _Call to unknown:_ This vulnerability occurs if a function that does not exist in the target contract is called. Calling a non-existent function triggers the fallback function, posing a reentrancy attack risk, as described by [PERSON] et al. [117] and [PERSON] et al. [90]. This was used in the Parity multi-signature wallet attacks [90; 117; 120; 126; 101]. [PERSON] et al. [117] generally describe fallback functions as a possible vulnerability. The erroneous constructor name vulnerability existed in Solidity until version 0.4.22.