Rostislav Yavorskiy, PhD Head of research at Exactpro VERIFICATION OF SMART CONTRACTS ON THE ETHEREUM BLOCKCHAIN Lecture #3 Formal verification of Solidity contracts 18 April 2022

Due to the openness of Ethereum, both programs and users can call into the public methods of other programs, leading to potentially dangerous compositions of trusted and untrusted code 2 https://www.omnisecu.com/ Ethereum is a distributed computing platform where anyone can run code (theirs and others) by paying for the associated gas charges

Ethereum currently runs smart contracts that manage millions of dollars, making their security highly sensitive The goal is to analyze and verify both the runtime safety and the functional correctness of Ethereum contracts. 3

Example: Stack overflow error Initially the call stack of the EVM had a maximum size of 1024 frames which, once reached, would cause the next function call to fail along with its subcalls An attacker could exploit such a limitation by generating a number of calls to the vulnerable contract as to almost fill the stack, counting on the targeted contract to mishandle (or not handle at all) the incurred full stack failure, and use the next function call to exploit this pitfall The changes introduced in Ethereum’s hardfork in October 2016 make this call stack limit practically unreachable 4

Example: Stack overflow error 5 https://medium.com/swlh/in-depth-introduction-to-call-stack-in-javascript-a07b8513bcc3

Example: Arithmetic bugs Errors such as overflows and underflows may occur due to the violation of value limitations of integer data types. 6 https://docs.soliditylang.org/

Tools for smart contracts analysis 7

Oyente ● Oyente released in 2016 by researchers from National University of Singapore ● It is implemented in Python, uses Z3 as a backend SMT solver ● It is based on symbolic execution and functions over the bytecode which needs to be provided as input along with Ethereum’s global state ● The tool targets four bugs by checking for specific conditions: transaction order dependence, timestamp dependence, mishandled exceptions and reentrancy https://github.com/enzymefinance/oyente 8

❏ CFGBuilder: Builds a Control Flow Graph (CFG) of the bytecode ❏ Explorer: simulates the behaviour of EVM instructions and makes use of Z3 to decide on path conditions ❏ CoreAnalysis: it comprises 4 components to detect the 4 types of bugs, which work by checking specific conditions when analyzing the symbolic traces ❏ Validator: this step is added to reduce the rate of false positives Oyente components 9

All smart contract source code are compiled into two formats, by the Ethereum Virtual Machine (EVM): ● Application Binary Interface (ABI): a communication layer between solidity and Javascript, in JSON format ● Bytecode: the low level machine language that gets executed by the the EVM 10

11 https://hackernoon.com/

EVM bytecode is not human-readable but readable for the machine 080604052348015600f57600080fd5b5060878061001e6000396 000f3fe6080604052348015600f57600080fd5b5060043610602 8576003560e01c8063037a417c14602d575b600080fd5b603360 49565b6040518082815260200191505060405180910390f35b56 Note: For verification it is favorable to obtain both Solidity source code and EVM bytecode for a given smart contract, but only less that 1% contracts have their source code available 12

13 Control flow graph (CFG) Albert, E & Arenas, Puri & Genaim, S & Puebla, Germán & Zanardini, Damiano. (2007). Cost Analysis of Java Bytecode. Lecture Notes in Computer Science. 4421. 157-172.

14 Symbolic execution tree Ciortea, Liviu & Zamfir, Cristian & Bucur, Stefan & Chipounov, Vitaly & Candea, George. (2009). Cloud9: A Software Testing Service. Operating Systems Review. 43. 5-10.

❏ CFGBuilder: Builds a Control Flow Graph (CFG) of the bytecode ❏ Explorer: simulates the behaviour of EVM instructions and makes use of Z3 to decide on path conditions ❏ CoreAnalysis: it comprises 4 components to detect the 4 types of bugs, which work by checking specific conditions when analyzing the symbolic traces ❏ Validator: this step is added to reduce the rate of false positives Oyente components 15

OSIRIS Osiris is based on Oyente and looks for integer bugs: ● arithmetic bugs like integer underflows/overflows and bugs caused by divisions where the denominator is zero ● truncation bugs which can happen when converting a value into a new type with a shorter range than that of its initial type and ● signedness bugs that can occur when converting a signed integer typed value into an unsigned integer type (or the opposite). https://github.com/christoftorres/Osiris 16

References ● Garfatta, Ikram, Kais Klai, Walid Gaaloul, and Mohamed Graiet. "A survey on formal verification for solidity smart contracts." In 2021 Australasian Computer Science Week Multiconference, pp. 1-10. 2021. ● Bhargavan, Karthikeyan, Antoine Delignat-Lavaud, Cédric Fournet, Anitha Gollamudi, Georges Gonthier, Nadim Kobeissi, Natalia Kulatova et al. "Formal verification of smart contracts: Short paper." In Proceedings of the 2016 ACM workshop on programming languages and analysis for security, pp. 91-96. 2016. ● Luu, Loi, Duc-Hiep Chu, Hrishi Olickel, Prateek Saxena, and Aquinas Hobor. "Making smart contracts smarter." In Proceedings of the 2016 ACM SIGSAC conference on computer and communications security, pp. 254-269. 2016. ● Torres, Christof Ferreira, Julian Schütte, and Radu State. "Osiris: Hunting for integer bugs in ethereum smart contracts." In Proceedings of the 34th Annual Computer Security Applications Conference, pp. 664-676. 2018. 17

Test https://forms.gle/fNirTZ2AqXd43FAk9 18