Formalising and verifying smart contracts with Solidifier: a bounded model checker for Solidity

Abstract

The exploitation of smart-contract vulnerabilities can have catastrophic consequences such as the loss of millions of pounds worth of crypto assets. Formal verification can be a useful tool in identifying vulnerabilities and proving that they have been fixed. In this paper, we present a formalisation of Solidity and the Ethereum blockchain using the Solid language and its blockchain; a Solid program is obtained by explicating/desugaring a Solidity program. We make some abstractions that over-approximate the way in which Solidity/Ethereum behave. Based on this formalisation, we create Solidifier: a bounded model checker for Solidity. It translates Solid into Boogie, an intermediate verification language, that is later verified using Corral, a bounded model checker for Boogie. Unlike much of the work in this area, we do not try to find specific behavioural/code patterns that might lead to vulnerabilities. Instead, we provide a tool to find errors/bad states, i.e. program states that do not conform with the intent of the developer. Such a bad state, be it a vulnerability or not, might be reached through the execution of specific known code patterns or through behaviours that have not been anticipated.

Pre-deployment Analysis of Smart Contracts -- A Survey

“…To formally verify smart contracts, such framing conditions are provided with formal specifications of contracts. D Functional Annotations are functional pre-and post-conditions that specify what conditions must hold before and after a function executes [17,89,177]. Such annotations are defined with each function according to its specific functionality.…”

“…In exchange for this expressive power, more work is typically needed to address useability issues, such as error messages that may come up if a property is not satisfied or the method is unable to establish the property even though it holds. bound 𝑘 where 𝑘 is the number of transitions taken from some initial state for violations of a given property [17]. If a certain property holds for the model within that bound, that is reported; if not, a counterexample is reported to help the user identify the mistake and correct bugs.…”

Declarative smart contracts

“…However, when it comes to contract-level properties, where an invariant needs to hold across an infinite sequence of transactions, these approaches suffer from low efficiency due to state explosion issues. Some solutions [21,16] trade soundness for efficiency, verifying properties up to a certain number of transactions.…”