An ASM-Based Approach for Security Assessment of

Ethereum Smart Contracts

∗

C. Braghin

, E. Riccobene

and Simone Valentini

Department of Computer Science, Universit

a degli Studi di Milano, Italy

Keywords:

Blockchain, Smart-Contracts, Exception, Veriﬁcation, Validation, ASMs, ASMETA.

Abstract:

Blockchain-based smart contracts are gaining widespread adoption due to their potential to automate complex

transactions securely and transparently. However, ensuring the correctness and security of smart contracts re-

mains a challenge. This paper proposes a novel approach to modeling and verifying Ethereum smart contracts’

exception-related vulnerabilities using Abstract State Machines (ASMs). ASMs provide a formal modeling

language that enables the precise representation of system behavior and properties. We developed an ASM

model of a Solidity smart contract and demonstrated its use on Unhandled Exception vulnerability identiﬁ-

cation and check contract correctness. Our approach offers a formal framework for smart contract modeling

and veriﬁcation. It leverages the power of ASM tools to identify vulnerabilities and ensure contract reliability,

contributing to more secure and trustworthy blockchain-based applications.

1 INTRODUCTION

Blockchain was born as a powerful and innovative so-

lution that implements a distributed ledger to man-

age people’s ﬁnances without the need for interme-

diaries or trusted third parties. In late 2013, Vi-

talik Buterin introduced Ethereum, a decentralized,

open-source blockchain platform designed to facil-

itate decentralized, trustless, and programmable in-

teractions on the blockchain through smart contracts

(Wood et al., 2014). The Ethereum Virtual Machine

(EVM) serves as the engine behind Ethereum’s smart

contract execution and transaction processing, ensur-

ing decentralized and deterministic operation across

the network. Operating as a distributed state machine,

Ethereum maintains a uniﬁed state among its decen-

tralized nodes, empowering the execution of smart

https://orcid.org/0000-0002-9756-4675

https://orcid.org/0000-0002-1400-1026

https://orcid.org/0009-0005-5956-3945

∗

This work was supported in part by project SERICS

(PE00000014) under the NRRP MUR program funded by

the EU - NGEU. Views and opinions expressed are how-

ever those of the authors only and do not necessarily reﬂect

those of the European Union or the Italian MUR. Neither

the European Union nor the Italian MUR can be held re-

sponsible for them.

This work was partially supported by the PRIN project

SAFEST (G53D23002770006).

contracts and decentralized applications with veriﬁ-

able outcomes (Ethereum, 2024).

Since smart contracts are also stored on the

blockchain, they cannot be modiﬁed after deploy-

ment. In the past, many attacks on vulnerable smart

contracts proved that a stronger veriﬁcation and val-

idation phase before the contract’s deployment is re-

quired. For instance, the infamous DAO hack drained

$70 million worth of Ether (Siegel, 2016), and also

the popular King of the Ether Throne (KotET) con-

tract (mis, 2016) had a fatal ﬂaw.

In (Braghin et al., 2024), we explored the applica-

tion of Abstract State Machines (ASMs) for specify-

ing and verifying Ethereum smart contracts written in

Solidity. We formalized the EVM and key language

primitives, enabling the validation of functional cor-

rectness through rigorous proofs. Our approach fa-

cilitates veriﬁcation of intra-contract properties and

modeling of inter-contract interactions, allowing as-

sessment of a contract’s robustness against potential

attacks.

In this paper we go one step further: we extend

the work presented in (Braghin et al., 2024) by incor-

porating the exception-handling mechanisms. This

enhancement enables us to identify and evaluate an

additional category of potential vulnerabilities due to

exceptions and errors within smart contracts (e.g., ex-

ception disorder or call-stack overﬂows), thereby en-

hancing the completeness of security assessments.

334

Braghin, C., Riccobene, E. and Valentini, S.

An ASM-Based Approach for Security Assessment of Ethereum Smart Contracts.

DOI: 10.5220/0012858000003767

Paper published under CC license (CC BY-NC-ND 4.0)

In Proceedings of the 21st International Conference on Security and Cryptography (SECRYPT 2024), pages 334-344

ISBN: 978-989-758-709-2; ISSN: 2184-7711

As a proof of concept, we introduce a vulnerable

running example, its corresponding ASM model and

a new attacker model exploiting the exception vul-

nerabilities. Through a comprehensive validation and

veriﬁcation process applied to the contract model, we

demonstrate the efﬁcacy of our proposed approach.

The paper is structured as follows. Section 2 intro-

duces ASMs as a formal method for system engineer-

ing, explaining the fundamental concepts of ASMs,

including states, locations, update rules, and transi-

tion rules. In Section 3, we provide a background

description of the functioning of smart contracts and

exception handling in Ethereum. Section 4 presents

the detailed modeling of the EVM and Solidity lan-

guage primitives using ASMs. We describe the struc-

ture of an ASM model and demonstrate its ability

to capture the behavior of smart contracts for excep-

tion handling. Section 5 introduces the running case

study consisting of a Solidity auction contract. Sec-

tion 6 describes the validation and veriﬁcation pro-

cess. We explain how it is possible to deﬁne both

intra- and inter-contract properties using invariants

and CTL formulas. Section 7 reviews existing tools

for automated analysis and testing of Ethereum smart

contracts. Section 8 concludes the paper.

2 ABSTRACT STATE MACHINES

Abstract State Machines (Borger et al., 2003) (ASMs)

is a state-based approach to system engineering.

ASMs capture a system’s conﬁguration through states

and articulate its behavior via a sequential series

of state transitions. Compared to Finite Automata,

ASMs are more expressive since they replace the con-

cept of unstructured state with the concept of state as

a mathematical algebra, proving a more expressive

formal language.

System data and operations on data are repre-

sented by domains of elements and functions deﬁned

on them.

State memory units are given as a set of locations;

they are pairs of the form ( f (v

, . . . , v

), v), meaning

that the function f interpreted on parameters v

, ..., v

has value v (assigned in the function codomain).

State transitions are given by ﬁring well-formed

transition rules, i.e., rules constructed by a given and

ﬁxed number of rule constructors.

The basic transition rule, which allows for up-

dating locations, is the update rule of the form of

f (v

, ..., v

) := d. By ﬁring this rule, in the next

state, the value of the function f (v

, ...ldots, v

) is

updated to d. Update rules are usually embedded in

more complex transition rules. The rule constructors

used for our modeling are those for guarded updates

(if-then, switch-case), parallel updates (par), and

nondeterministic updates (choose).

Depending on whether transition rules update lo-

cations or not, functions are classiﬁed in static (never

change value) and dynamic (value updated by rules).

Dynamic functions updated by transition rules are

called controlled, those updated by the environment

are called monitored, and those updated by both are

called shared.

An ASM run is a (ﬁnite or inﬁnite) sequence S

, . . . , S

, . . . of states. Starting from the initial state

, in a computation step (run step) from S

to S

n+1

all enabled transition rules are executed in parallel,

leading to simultaneous updates of a number of loca-

tions. In case of an inconsistent update (i.e., the same

location is updated to two different values) or invari-

ant violations (i.e., some property that must be true

in every state is violated), the model execution stops

with error.

Besides different ways to structure the control

ﬂow of functions update (depending on the use of

rule constructors), ASMs can also model different

computational paradigms, ranging from a single agent

executing the whole transition system to distributed

(synchronous or asynchronous) multi-agents working

in parallel, each executing its transition system (or

agent’s program).

2.1 ASMETA Toolset

ASMETA (Gargantini et al., 2008) is an Eclipse-based

set of integrated tools tailored to the ASM formal

method. It offers support across the diverse stages of

system development, from speciﬁcation to analysis.

It provides a textual user-friendly pseudo-code

format to write ASM models, with an editor and a

syntax checker. An ASMETA model has a well-

formed structure as reported in Listing 1: a model is

composed by an import section that allows the im-

port of external libraries and user-deﬁned models that

provide predeﬁned domains, functions, and rules; a

signature section to declare speciﬁc domains and

functions; a definitions section to deﬁne speciﬁc

static domains and functions, transition rules, state in-

variants, and properties to be veriﬁed; it also encom-

passes the main rule, which is the starting point of

the machine computation and that may trigger other

transition rules; in case of multi-agent models, the

main rule can be used to orchestrate the execution of

different agents; ﬁnally, the init section deﬁnes the

values for the model’s initial state.

A core part of the toolset is the AsmetaS simu-

lator (Gargantini et al., 2007), enabling model vali-

An ASM-Based Approach for Security Assessment of Ethereum Smart Contracts

335

2 import ../../Libraries/CTLlibrary

3 import ../../Libraries/StandardLibrary

5 signature:

6 /*DOMAINS DEFINITION*/

7 domain Domain subsetof Integer

8 ...

9 /*LOCATIONS DEFINITION*/

10 controlled location : Domain

11 ...

12 definitions:

13 /*TRANSACTION RULES*/

14 rule r_Rule =

15 ...

16 ...

17 /*INVARIANTS */

18 invariant over locations : term

19 ...

20 /*TEMPORAL LOGIC FORMULAS */

21 CTLSPEC ...

22 ...

23 /*MAIN RULE*/

24 main rule r_Main = ...

26 default init s0:

27 /*INITIAL STATE DEFINITION*/

28 function location = value

29 ...

Listing 1: ASM model schema.

dation by simulating the execution of ASM models

and verifying adherence of the model to the require-

ments. AsmetaS offers a rich set of functionalities, in-

cluding support for a wide range of validation tasks,

from invariant checking, consistent update checking,

random simulation, to interactive simulation modes.

For more powerful scenario-based validation, the As-

metaV (Carioni et al., 2008) tool uses the AsmetaS

simulator along with the AValLa language to express

scenarios as sequences of actor actions and expected

machine reactions, enabling comprehensive valida-

tion of execution scenarios on ASM models.

Formal veriﬁcation of ASM models is handled by

the AsmetaSMV (Arcaini et al., 2010) tool, which

translates ASM models into input for the NuSMV

(Cimatti et al., 1999) model checker. AsmetaSMV

supports specifying and checking both linear tem-

poral logic (LTL) and computation tree logic (CTL)

properties.

3 ETHEREUM AND SMART

CONTRACTS

A blockchain is a decentralized, distributed ledger

technology that records transactions across a network

of computers. It is composed of blocks of data,

each containing a set of transactions, a unique cryp-

tographic hash of the previous block and a times-

tamp, thus creating a chain of blocks. This structure

gives the blockchain the characteristic of immutabil-

ity: once recorded, the content of a block cannot be

altered without changing all subsequent blocks, mak-

ing retroactive data tampering virtually impossible.

Ethereum (Wood et al., 2014) is an open-source

blockchain platform that enables developers to build

and deploy decentralized applications: unlike Bitcoin,

which primarily focuses on peer-to-peer electronic

cash transactions, Ethereum provides the EVM, a de-

centralized runtime environment for executing smart

contracts, which are self-executing contracts with the

terms of the agreement directly written into code.

They are written in high-level languages such as So-

lidity and compiled into bytecode that can be executed

by the EVM.

The EVM runs on every node participating in the

Ethereum network, ensuring that smart contracts are

executed in a decentralized manner. It also maintains

the state of the Ethereum blockchain, which includes

account balances, smart contract code, and storage.

There are two types of accounts that have an Ether

(ETH) balance and can interact with the blockchain

by sending transactions on the chain: externally

owned accounts (EOA) and smart contract accounts.

EOA are humans-managed accounts identiﬁed by a

public key (used as account address) and controlled

by the corresponding private key that is used to sign

transactions to prove ownership and authorization (by

means of elliptic curve digital signature algorithm).

Contract accounts are special accounts that have asso-

ciated code and data storage, a unique address, but not

private keys. When a transaction involving a smart

contract is initiated, the EVM receives the bytecode

associated with the contract and executes it, modify-

ing the state of the blockchain by updating account

balances or storage values. A special global variable

called msg is employed to capture transaction-related

information, including msg.sender representing the

address that initiated the function call.

Gas is the unit used to measure computational ef-

fort in Ethereum: each operation in the EVM con-

sumes a certain amount of gas, and users must pay

gas fees to execute transactions and smart contracts.

In Solidity, exceptions can broadly be categorized

into two types: built-in exceptions and custom excep-

tions. Out-of-Gas Exceptions are built-in exceptions

that occur when a transaction runs out of gas before

completing its execution and cause the transaction

to revert, i.e., the transaction is terminated, and any

changes made to the blockchain state during the trans-

SECRYPT 2024 - 21st International Conference on Security and Cryptography

336

Figure 1: Diagram representing how the two pointers behave in different situations.

action are rolled back, ensuring that the blockchain

remains in a consistent state and preventing incom-

plete or erroneous transactions from being included in

the blockchain. Custom exceptions are user-deﬁned

exceptions that are triggered by require or revert

statements within a smart contract

Solidity provides various functions to transfer

Ether between contracts or to external addresses, dif-

fering in terms of their behavior, gas management,

and error handling mechanisms. For instance, both

the transfer and send functions automatically for-

ward a ﬁxed amount of gas (currently 2300 gas) along

with the transfer operation, typically sufﬁcient for ba-

sic Ether transfers but potentially insufﬁcient for com-

plex recipient contract operations. In contrast, the

call function allows for custom gas limits to be spec-

iﬁed. Regarding error handling, if a transfer fails due

to exceptions thrown by the recipient or an out-of-gas

exception, both call and transfer functions revert

the transaction, undoing any state changes made be-

fore the call. Instead, in case of failure, the send

function does not revert the transaction but forwards

any remaining gas to the recipient and continues ex-

ecution, returning false, thus enabling the contract to

handle the failure gracefully.

4 MODELING ETHEREUM

In (Braghin et al., 2024), we formalized in ASM

the Ethereum virtual machine and Solidity key prim-

itives. We also developed an approach to systemati-

cally translate Solidity smart contracts into ASMETA

models: for each smart contract there is a correspond-

ing ASMETA model that includes the EVM library

and a transition rule for each Solidity function. The

rule is mainly a switch case with as many cases as

the number of instructions in the function.

The EVM library models the execution stack that

keeps track of the active smart contract functions

and of the global state of the blockchain. The stack

frame represents an element of the stack recording

the account address that initiated the transaction, the

receiver, the amount of ether transferred, the run-

ning function, the current instruction being executed

and the smart contract the function belongs to. The

stack pointer, pointing to the stack frame of the

function currently being executed (i.e., at the top

of the stack), is modeled by the controlled function

current

layer.

To manage transactions and the updating of the

stack pointer, two different rules have been devel-

oped: r Transaction, to perform a transaction,

and r Ret, to terminate one. r Transaction rule

models the execution of a transaction by increasing

current layer and storing all the data on the new

execution environment in the stack. It also increments

the caller’s instruction pointer to continue with the

execution left pending once current layer is de-

creased, i.e., when the function returns. r Ret rule

is called when a function ends its execution, the last

stack frame is popped and the stack pointer is decre-

mented. Figure 1 visually illustrates the stack struc-

ture and the dynamics of the r Transaction and

r Ret rules. Speciﬁcally, the top row exempliﬁes a

scenario with an initial function call (i.e., Transac-

tion 1) subsequently invoking another function (i.e.,

Transaction 2). Then, the two functions conclude

(i.e., Return 2 followed by Return 1).

In this paper, we improve the approach and model

exceptions, enabling us to address all potential attacks

stemming from the misuse of exceptions. Indeed, var-

An ASM-Based Approach for Security Assessment of Ethereum Smart Contracts

337

ious attacks exploit vulnerabilities related to excep-

tions, such as exception disorder, a common issue

resulting from Solidity’s inconsistent error handling

during function calls, as well as the call stack overﬂow

vulnerability, which arises when a program allocates

excessive data on the call stack.

In order to emulate the Ethereum exception-

handling mechanism, we needed to implement the

rollback feature. As explained in Section 3, when

an exception is thrown, a rollback process is per-

formed to revert the blockchain global state to the

point before the exception occurred. To this aim,

we leveraged the inherent nature of ASMs as a state-

based system, encompassing the global state of the

blockchain. As a result, we added a new func-

tion global state layer behaving similarly to the

current layer function, pointing to a snapshot of

the appropriate global state right before potential ex-

ception locations. Then, if an exception happens,

the global state can be easily reset by referencing

global state layer to the data of a previous global

state. The snapshot is performed by the r Save rule,

while the r Throw rule mimicks the throwing of an

exception during execution, such as exceeding the

maximum call stack depth. This rule decrements

global state layer to revert to the previously val-

idated state and then triggers the r Ret rule to update

also the current layer.

Figure 1 provides a visual representation of how

the current layer and global state layer func-

tions behave when a transaction ends normally ver-

sus when it throws an exception. The scenario de-

picted in the top row illustrates the case when Trans-

action 2 naturally concludes with a return state-

ment and no exception is thrown. In this case, the

current layer function is decreased to resume the

execution environment of the previous layer, but the

global state layer remains unchanged to record

the changes in the global state performed by Transac-

tion 2. No rollback occurs because the data generated

in the third layer remains valid.

The scenario in the bottom row of Figure 1 illus-

trates the case of an exception raised during the execu-

tion of Transaction 2. This abnormal termination trig-

gers a rollback, resetting the blockchain global state

to the previously validated data (i.e., the global state

reached after the execution of Transaction 1). As a re-

sult, both current layer and global state layer

functions are decremented: current layer moves

back to the second layer to continue the execution of

Transaction 1 since the execution of Transaction 2 has

failed, while the global state reverts to the state be-

fore the execution of Transaction 2. In the end, when

all transactions conclude either successfully or raise

an exception, current layer is equal to 1. At this

point, the values of the two functions are aligned.

Figure 1 also clariﬁes the general behavior of the

two functions: during a sequence of nested func-

tion calls, whenever a function concludes success-

fully with a r Ret rule, only current layer is decre-

mented, while global state layer remains point-

ing to the new global state of the blockchain. How-

ever, in the event of an exception, both are decre-

mented.

5 AUCTION CASE STUDY

In this Section, we introduce a running case study,

serving as a proof of concept for our validation and

veriﬁcation approach concerning vulnerable smart

contracts. The case study is a Solidity Auction con-

tract (Braghin et al., 2020), commonly encountered

in real-world blockchain applications.

1 contract A u c t i o n {

2 address curre n t F r o n trunne r ;

3 uint currentBid ;

5 function bid () payable {

6 require(msg.value > c u r r e n t B i d ) ;

8 if ( cur r e n t F rontru n n e r != 0) {

9 require( c u rrentF r o n t r unner .

send( c u r r e n t B i d ) );

10 }

12 cur r e n t F rontru n n e r = msg.sender;

13 currentBid = msg.value;

14 }

15 }

The contract keeps track of the current highest

bidder (currentFrontrunner) and the highest bid

amount (currentBid). Participants can submit bids

through the bid() function, which takes payment in

Ether. The function requires that (1) the submitted bid

value (msg.value) is greater than the current highest

bid, and (2) that if there is an existing highest bidder

(currentFrontrunner != 0), the contract must re-

fund their bid amount before assigning the new bid.

This contract can reach a Denial of Service (DoS)

state due to an exception disorder vulnerability. In-

deed, a malicious user can design a malicious contract

that (i) proposes the highest bid to become the current

front-runner, and (ii) contains a fallback function

(i.e., the function that is triggered when the address

receiving a transfer does not have a receive func-

tion) containing operations that require more than the

ﬁxed amount of gas of the send function. Then, when

another contract makes a bid higher than the attacker’s

SECRYPT 2024 - 21st International Conference on Security and Cryptography

338

one, the Auction contract tries to refund the bid to the

attacker and an out-of-gas exception is raised, making

the send function returns false (see Section 3). In this

way, also the Auction contract raises an exception

when the require statement receives the false return

value. In this case, the exception triggers a rollback of

the entire bid function execution. As a consequence,

the attacker is able to keep its front-runner position

until the auction is ﬁnished since the Auction con-

tract will not be able to accept any new higher bid.

From the contract code, it is possible to specify

the corresponding model

by following the schema

described in (Braghin et al., 2024). Listing 2 re-

ports the rule r Bid, which is triggered when bid is

the currently executing function in the current layer.

The switch statement of the rule controls the execu-

tion ﬂow based on the value of the instruction pointer

in the current layer. Firstly, (case 0) the rule en-

forces a requirement that the amount speciﬁed in the

current layer must be greater than the current bid

stored in the global state layer; then, (case 1) if

the current front runner for the bid is deﬁned, the in-

struction pointer is incremented to proceed to the next

case; otherwise, it jumps to case 4. In case 2, a trans-

action is initiated sending the current bid to the cur-

rent front runner and calling the fallback function. Af-

ter the transaction is performed, case 3 requires that

the response from the previous transaction is success-

ful. The last cases aim to set the current front runner

with the transaction sender and to update the current

bid with the transaction amount.

6 CONTRACT VERIFICATION

Vulnerabilities in smart contracts can lead to secu-

rity breaches, ﬁnancial losses, and other undesirable

consequences. It is possible to identify two kinds

of vulnerabilities, intra-contract and inter-contract.

Intra-contract vulnerabilities exist within a single

smart contract and can arise from coding errors, de-

sign ﬂaws, or misunderstandings of the underlying

blockchain platform’s functionality. Inter-contract

vulnerabilities are due to unsafe interaction of smart

contracts. They occur when a smart contract inter-

acts with another speciﬁc contract containing func-

tions designed to exploit a vulnerability.

In the following, we discuss how intra/inter-

contract vulnerabilities can be detected in ASM mod-

els of smart contracts by using the ASMETA toolset

for validation and veriﬁcation.

The model is available at https://github.com/

smart-contract-veriﬁcation/ethereum-via-asm

Model validation is possible through the use of

AValLa (ASM Validation Language) scenarios, i.e.,

interaction sequences consisting of actions by exter-

nal actors (users) that can set monitored function val-

ues and check the internal machine state, combined

with actions of the machine that performs steps by

executing the model transition rules.

Model veriﬁcation is possible by using As-

metaSMV, which translates an ASM model into a

NuSMV model and invokes the symbolic model

checker on speciﬁed temporal logic properties. In

case a property is false, a full counterexample, i.e.,

a possible run leading to a state where the property

is false, is provided. Such a run can then be trans-

lated into an AValLa scenario (by exploiting other fea-

tures of the ASMETA toolset (Arcaini and Riccobene,

2019)), which can reproduce the same faulty model

execution.

6.1 Checking Intra-Contract

Vulnerabilities

Examples of intra-contract vulnerabilities include in-

teger overﬂows/underﬂows, where arithmetic opera-

tions can produce unexpected results due to the lim-

ited range of integer data types, and access control is-

sues, where unauthorized parties can manipulate sen-

sitive contract data or functions. One speciﬁc type

of intra-contract vulnerability is the unprotected func-

tion vulnerability. This occurs when a contract ex-

poses sensitive functions without proper access con-

trol mechanisms, allowing unauthorized parties to ex-

ecute them.

In Solidity, a known example of an unprotected

function is the powerful selfdestruct function that

terminates the contract and sends any remaining Ether

in the contract’s balance to a speciﬁed address. Usu-

ally, this function is protected so that only the contract

owner can disable the contract. If this function is not

properly protected, an attacker can potentially call it

and force the contract to self-destruct, leading to a de-

nial of service (DoS) state.

Consider the scenario in which the following

destroy function, which uses the selfdestruct

function in an unprotected way, would be added to

the Auction smart contract:

1 function d e s t r o y () {

2 selfdestruct(msg.sender);

3 }

When translating the Auction contract extended

with the destroy function into an ASMETA model,

the latter is mapped into the r Destroy rule reported

in Listing 3.

An ASM-Based Approach for Security Assessment of Ethereum Smart Contracts

339

1 rule r_Save ($n in StackLayer) =

2 par

3 currentFrontrunner($n) := currentFrontrunner(global_state_layer)

4 currentBid($n) := currentBid(global_state_layer)

5 endpar

7 rule r_Bid =

8 if executing_function(current_layer) = bid then

9 switch instruction_pointer(current_layer)

10 case 0 :

11 r_Require[amount(current_layer) > currentBid(global_state_layer)]

12 case 1 :

13 if isDef(currentFrontrunner(global_state_layer)) then

14 instruction_pointer(current_layer) := instruction_pointer(current_layer) + 1

15 else

16 instruction_pointer(current_layer) := 4

17 endif

18 case 2 :

19 r_Transaction[auction, currentFrontrunner(global_state_layer), currentBid(

global_state_layer), fallback]

20 case 3 :

21 r_Require[call_response(current_layer+1)]

22 case 4 :

23 par

24 currentFrontrunner(global_state_layer) := sender(current_layer)

25 instruction_pointer(current_layer) := instruction_pointer(current_layer) + 1

26 endpar

27 case 5 :

28 par

29 currentBid(global_state_layer) := amount(current_layer)

30 instruction_pointer(current_layer) := instruction_pointer(current_layer) + 1

31 endpar

32 case 6 :

33 r_Ret[]

34 endswitch

35 endif

Listing 2: Model transated from the Auction solidity contract.

1 rule r_Destroy =

2 if executing_function(current_layer) =

destroy then

3 switch instruction_pointer(

current_layer)

4 case 0 :

5 r_Selfdestruct[owner]

6 case 1 :

7 r_Ret[]

8 endswitch

9 endif

Listing 3: The r Destroy rule.

The rule checks if the executing function

is destroy, then, if instruction pointer is 0,

the r Selfdestruct rule is called. The latter

rule (not reported here) behaves like the Solidity

selfdestruct function: it sets to true a predeﬁned

boolean function disabled, deﬁned on the Users do-

main, which speciﬁes whether the provided contract’s

user has been disabled or not.

To ensure that the selfdestruct function is used

securely (i.e., only the contract owner can terminate

the contract), we add the following state invariant into

the contract model that includes the r Destroy rule.

It is speciﬁcally designed to ensure the protected in-

vocation of the r Selfdestruct subrule.

1 invariant over sender :

executing_function(current_layer) =

destroy implies sender(current_layer)

= owner(global_state_layer)

It establishes that, if the executing function

value is destroy, then the transaction sender must be

the contract’s owner. Therefore, the invariant would

be violated if the function’s caller is someone differ-

ent from the contract owner.

The simple model simulation is not enough to re-

veal an invariant violation, and we need to use the

model checker to guarantee that the protected func-

tion property is not violated by the behavior of the

r Selfdestruct rule in any possible computation.

During the transaltion of an ASMETA model into

SECRYPT 2024 - 21st International Conference on Security and Cryptography

340

a NuSMV model, a state invariant is automatically

translated into a CTL AG (i.e., always along all paths)

property to guarantee that the property holds in all

possible runs. In the case of a false property, the As-

metaSMV model checker returns a counterexample,

which can be rented as an Avalla scenario.

The following scenario is, for example, obtained

by the proof of the faulty AG property corresponding

to the invariant.

1 load ../Auction.asm

3 set random_user := auction;

4 set random_amount := 0;

5 set random_function := destroy;

7 step

8 set random_user := auction;

9 set random_amount := 0;

10 set random_function := destroy;

12 step

13 step

Executing this scenario leads to an illegal state

where the invariant is broken, and an Invariant

violation message is reported. This feature allows

the designer to have concrete evidence of the vulner-

ability.

6.2 Checking Inter-Contract

Vulnerabilities

Inter-contract vulnerabilities are more complex and

involve interacting smart contracts. Indeed, to dis-

cover these vulnerabilities, we need an attacker con-

tract able to interact with the vulnerable contract and

to exploit the vulnerability.

In (Braghin et al., 2024), we presented how to

model attackers, i.e., speciﬁc smart contracts en-

dowed with functions tailored to exploit a vulnerabil-

ity, and how to execute a given model of a smart con-

tract in combination with an attacker. We also started

to build a library of attackers, differing in the capa-

bilities they have and based on well-known vulnera-

bilities. However, these attacker models do not ex-

ploit exception disorder vulnerabilities. Instead, the

approach presented here covers cases of attacks deal-

ing with exceptions.

The contract presented in Section 5 encompasses

an exception disorder vulnerability that allows an at-

tacker to bring the auction contract to a denial of ser-

vice (DoS) state, preventing an honest user from be-

coming the new front-runner.

The attacker model speciﬁed to exploit the excep-

tion disorder vulnerability contains two different rules

(see the listing below): the r Attack rule, which al-

lows the attacker to perform a transaction and inter-

act with the contract, and the r Fallback attacker

rule, which is executed when a transaction without

valid information is received, in particular, it only

raises an exception.

1 rule r_Attack =

2 let ($cl = current_layer) in

3 let ($scl = sender($cl)) in

4 if executing_function($cl) =

attack then

5 switch instruction_pointer(

$cl)

6 case 0 :

7 r_Transaction[

attacker,

random_user,

random_amount,

random_function]

8 case 1 :

9 r_Ret[]

10 endswitch

11 endif

12 endlet

13 endlet

15 rule r_Fallback_attacker =

16 let ($cl = current_layer) in

17 if executing_function($cl) !=

attack then

18 switch instruction_pointer($cl

)

19 case 0 :

20 r_Throw[]

21 case 1 :

22 r_Ret[]

23 endswitch

24 endif

25 endlet

Once the model of the Auction smart contract is

combined with the attacker’s model, the following

CTL formula has to be added to the resulting model to

guarantee the absence of the exception disorder vul-

nerability:

1 CTLSPEC AG((sender(current_layer) = user

and executing_function(current_layer)

= bid and instruction_pointer(

current_layer) = 1) implies AF(

currentFrontrunner(global_state_layer)

= user))

In particular, the property checks, for all the possi-

ble model states (AG), that, if the transaction sender is

user, the executing function is bid, and the instruc-

tion pointer is 1, then, in some future state in all the

paths (AF), the user will certainly become the new

front-runner.

The CTL property is proved to be false. By ex-

ploiting the ASMETA feature of building a scenario

An ASM-Based Approach for Security Assessment of Ethereum Smart Contracts

341

from a model checker counterexample, we can recon-

struct the execution leading to the attack.

The following listing reports (some of) the loca-

tion values of the last state returned by the scenario

execution.

1 <State 20 (controlled)>

2 ...

3 call_response(1)=false

4 call_response(2)=false

5 currentFrontrunner(1)=attacker

6 currentFrontrunner(2)=attacker

7 executing_contract(1)=auction

8 executing_contract(2)=attacker

9 executing_function(1)=bid

10 executing_function(2)=fallback

11 global_state_layer=0

12 ...

13 </State 20 (controlled)>

Since each model state stores the whole call stack,

analyzing all the nested transactions’ data is possi-

ble. In particular, in lines 3 and 4, the responses for

the two nested calls are false, which means that an

exception has been raised during the second transac-

tion and, since the bid function propagates the ex-

ception, the ﬁrst transaction returns a negative value

too. Moreover, in lines 5 and 6, the value for the

currentFrontrunner function does not change dur-

ing any of the performed transactions. Lines 7, 8, 9,

and 10 report values of the executing contract and ex-

ecuting function of the transaction. Finally, line 11,

reports the value of global state layer, which is 0

because of the raised exceptions; if no exception had

been raised, the value for the global state layer

would have been 2.

A V&V analysis similar to the one performed on

the running example has been carried out on various

models of smart contracts we developed, in combina-

tion with the different models of attackers available.

So far, we modeled a number of vulnerable/correct

smart contracts taken from the literature. As for the

attackers, we also modeled an inoffensive attacker and

an attacker that exploits the reentrancy attack.

7 RELATED WORK

Several tools have been developed for automated

analysis, testing, and debugging of Ethereum smart

contracts. However, as highlighted in the study by

(Zhang et al., 2023), a large portion of exploitable

bugs in real-world smart contracts (around 80%) are

not effectively identiﬁed by current tools. These bugs

are classiﬁed as “machine unauditable bugs” (MUBs)

due to the lack of appropriate test oracles and the need

for domain-speciﬁc knowledge to detect them. Dif-

ferent surveys and reviews (Zhang et al., 2023)(Al-

makhour et al., 2020)(Bartoletti et al., 2024) have

been viewed and analyzed to extract some of the most

popular and effective tools for analyzing Ethereum

smart contracts. In particular, most of the litera-

ture categorizes the tools depending on the methodol-

ogy. Among the most popular methodologies, model

checking and theorem proving are mostly used to

check contract correctness, while fuzzing and sym-

bolic execution are mostly used for vulnerability iden-

tiﬁcation.

Correctness. Tools facing smart contract’s correct-

ness or at least used to ensure that a smart contract ad-

heres to the expected behavior, involve formal meth-

ods, theorem proving, model checking, and runtime

veriﬁcation techniques.

Tools following the approach presented in (Bhar-

gavan et al., 2016), e.g., Solidity* and EVM*, typ-

ically translate Solidity contracts into F* programs,

and call an F* runtime library for all Ethereum oper-

ations. Speciﬁcally, Solidity* compiles Solidity con-

tracts into F* for source-level correctness veriﬁcation;

EVM* decompiles EVM bytecode into F* code to an-

alyze low-level properties.

The work in (Sotnichek, 2019) exploits the K-

Framework (S¸tef

anescu et al., 2016), which enables

veriﬁcation of smart contracts through runtime veri-

ﬁcation of bytecode instead of Solidity, as bytecode

language can be used for any high-level contract lan-

guage (used to specify the contract model).

Finally, the work in (Amani et al., 2018) uses Is-

abelle/HOL to verify the EVM bytecode of smart con-

tracts. This is done by splitting the contracts into ba-

sic blocks, and program correctness of each block is

proved by using Hoare triples. The entire veriﬁca-

tion procedure has been successfully applied to a case

study.

In general, all the above-mentioned approaches

require a strong mathematical and logical background

and use complex mathematical notations; this often

prevents practitioners from using them. Instead, the

ASM models can be read as high-level programs, and

have a simple notation and very basic control ﬂow

constructors. Moreover, since they are executable,

ASM models are suitable for simulation and other

validation techniques that are much more lighter than

complex veriﬁcation approaches, at least to have im-

mediate feedback regarding model reliability before

checking for correctness. In addition, whereas other

approaches cover only few vulnerability classes, we

provide both intra- and inter-contract analysis of se-

curity properties. In particular, having one or more at-

tacker models running in parallel with the smart con-

tract to be validated allows us to detect many more

SECRYPT 2024 - 21st International Conference on Security and Cryptography

342

unsafe interactions than those detected by the ap-

proaches that only search a speciﬁc instructions pat-

tern in the code.

Vulnerability Detection. These types of tools aim to

improve the security of smart contracts by detecting

vulnerabilities and verifying contracts against known

vulnerability patterns.

SolCMC and Certora are two leading formal ver-

iﬁcation tools for Solidity contracts. SolCMC (Alt

et al., 2022) is a symbolic model checker integrated

into the Solidity compiler since 2019. Developers

specify properties as assert statements within the con-

tract code, which are treated as veriﬁcation targets.

SolCMC transforms the instrumented contract into

Constrained Horn Clauses (CHCs) and uses CHC sat-

isﬁability solvers like Spacer (integrated into Z3) or

Eldarica to check if any assert can fail, producing a

trace witnessing the violation.

Certora (Jackson et al., ), on the other hand,

decouples property speciﬁcations from the contract

code. Properties are written in the Certora Veriﬁca-

tion Language (CVL), an extension of Solidity with

metaprogramming primitives. Certora compiles the

contract and associated properties into a logical for-

mula and sends it to an SMT solver. Unlike SolCMC,

veriﬁcation in Certora is done remotely on a cloud

service.

Among the other tools, Mythril (Smashing

Ethereum Smart Contracts for Fun and ACTUAL

Proﬁt, 2018) employs concolic analysis, taint analy-

sis, and control ﬂow checking of the Ethereum Vir-

tual Machine (EVM) bytecode to identify vulnerabil-

ities. Its approach involves pruning the search space

and identifying values that allow exploiting vulnera-

bilities in the smart contract.

Another promising tool is Slither (Feist et al.,

2019), developed by TrailOfBits. Slither is a

static analysis framework that converts Solidity smart

contracts into an intermediate representation called

SlithIR and applies program analysis techniques like

dataﬂow and taint tracking to extract and reﬁne vul-

nerability information. Notably, the combination of

Mythril and Slither was found to be notably effective

(Kushwaha et al., 2022).

Securify (Tsankov et al., 2018), developed by

ETH Zurich, also demonstrated good performance. It

statically analyzes EVM bytecode to infer semantic

information about the contract using the Soufﬂe Dat-

alog solver. It then checks compliance and violation

patterns that capture sufﬁcient conditions for proving

if a property holds or not.

While the above-mentioned tools effectively de-

tect common vulnerabilities, they exhibit several lim-

itations. Most do not support identifying attacks in-

volving exception handling or complex interactions

between contracts. The majority of tools do not

even facilitate behavioral analysis (Almakhour et al.,

2020)(Zhang et al., 2023). Furthermore, attack pre-

vention is not the sole consideration during smart con-

tract design and development; contract correctness is

equally crucial to ensure appropriate behavior. Many

tools focus solely on attack identiﬁcation and do not

verify contract correctness.

Our proposed approach aims to address both de-

sign correctness and vulnerability detection. It can

deal with complete and complex Solidity contracts,

also using exceptions. It allows for providing the user

with a library of malicious contracts that can be used

to check the robustness of a smart contract against

given types of vulnerability.

8 CONCLUSIONS

This paper presents a novel approach to modeling and

verifying Solidity smart contracts using the Abstract

State Machine formal method. It exploits the speci-

ﬁcation and analysis capabilities, as well as the wide

range of tools for model validation and veriﬁcation,

of the ASMs to improve the security and reliability

of smart contracts. Since we model the exception-

handling mechanism, the proposed method can deal

with all features and characteristics of complex So-

lidity smart contracts.

We use a vulnerable version of the Solidity auc-

tion contract, commonly used in blockchain ap-

plications, to show our approach’s modeling and

vulnerability-checking mechanism. In particular, we

face the veriﬁcation of intra- and inter-contract prop-

erties, allowing us to identify vulnerabilities and en-

sure contract reliability.

Our approach offers several advantages:

• Formal foundation: ASMs provide a formal foun-

dation for modeling and verifying smart contracts,

ensuring mathematical rigor and precision.

• Modular design: The ASM model is modular, al-

lowing the analysis of individual contracts and the

investigation of interactions between contracts.

• Tool support: ASMETA provides a suite of tools

for model development, simulation, validation,

and veriﬁcation, and they can represent efﬁcient

support to practitioners in the tool-drive analysis

of smart contracts.

In future work, we plan to extend our modeling

capabilities to address more complex smart contract

scenarios, developing automated tools for model gen-

eration from Solidity code, and investigating the ap-

An ASM-Based Approach for Security Assessment of Ethereum Smart Contracts

343

plication of machine learning techniques to enhance

vulnerability detection.

We believe that our approach can contribute to the

development of more effective and complete model-

checking methods to improve smart contracts’ secu-

rity and reliability, fostering wider adoption and inno-

vation in blockchain-based applications.

REFERENCES

(2016). King of the Ether Throne - Post-Mortem Investi-

gation. https://www.kingoftheether.com/postmortem.

html.

Almakhour, M., Sliman, L., Samhat, A. E., and Mellouk,

A. (2020). Veriﬁcation of smart contracts: A survey.

Pervasive and Mobile Computing, 67:101227.

Alt, L., Blicha, M., Hyv

arinen, A. E., and Sharygina, N.

(2022). SolCMC: Solidity compiler’s model checker.

In International Conference on Computer Aided Veri-

ﬁcation, pages 325–338. Springer.

Amani, S., B

egel, M., Bortin, M., and Staples, M. (2018).

Towards verifying Ethereum smart contract bytecode

in Isabelle/HOL. In Proceedings of the 7th ACM SIG-

PLAN international conference on certiﬁed programs

and proofs, pages 66–77.

Arcaini, P., Gargantini, A., and Riccobene, E. (2010). As-

metaSMV: a way to link high-level ASM models to

low-level NuSMV speciﬁcations. In Abstract State

Machines, Alloy, B and Z: Second International Con-

ference, ABZ 2010, Orford, QC, Canada, February

22-25, 2010. Proceedings 2, pages 61–74. Springer.

Arcaini, P. and Riccobene, E. (2019). Automatic Reﬁne-

ment of ASM Abstract Test Cases. In 2019 IEEE In-

ternational Conference on Software Testing, Veriﬁca-

tion and Validation Workshops (ICSTW), pages 1–10.

Bartoletti, M., Fioravanti, F., Matricardi, G., Pettinau,

R., and Sainas, F. (2024). Towards benchmark-

ing of Solidity veriﬁcation tools. arXiv preprint

arXiv:2402.10750.

Bhargavan, K., Delignat-Lavaud, A., Fournet, C., Golla-

mudi, A., Gonthier, G., Kobeissi, N., Kulatova, N.,

Rastogi, A., Sibut-Pinote, T., Swamy, N., et al. (2016).

Formal veriﬁcation of smart contracts: Short paper. In

Proceedings of the 2016 ACM workshop on program-

ming languages and analysis for security, pages 91–

96.

Borger, E., Stark, R., and Borger, E. (2003). Abstract state

machines: a method for high-level system design and

analysis / Egon Borger, Robert Stark. Springer, Berlin.

Braghin, C., Cimato, S., Damiani, E., and Baronchelli,

M. (2020). Designing smart-contract based auctions.

In Yang, C.-N., Peng, S.-L., and Jain, L. C., edi-

tors, Security with Intelligent Computing and Big-data

Services, pages 54–64, Cham. Springer International

Publishing.

Braghin, C., Riccobene, E., and Valentini, S. (2024). Mod-

eling and veriﬁcation of smart contracts, with Abstract

State Machines. In Proceedings of ACM SAC Confer-

ence (SAC’24).Accepted to 39th ACM/SIGAPP Sym-

posium on Applied Computing.

Carioni, A., Gargantini, A., Riccobene, E., and Scandurra,

P. (2008). A scenario-based validation language for

ASMs. In Abstract State Machines, B and Z: First

International Conference, ABZ 2008, London, UK,

September 16-18, 2008. Proceedings 1, pages 71–84.

Springer.

Cimatti, A., Clarke, E., Giunchiglia, F., and Roveri, M.

(1999). NuSMV: A new symbolic model veriﬁer. In

Computer Aided Veriﬁcation: 11th International Con-

ference, CAV’99 Trento, Italy, July 6–10, 1999 Pro-

ceedings 11, pages 495–499. Springer.

S¸tef

anescu, A., Park, D., Yuwen, S., Li, Y., and Ros¸u, G.

(2016). Semantics-based program veriﬁers for all lan-

guages. In Proceedings of the 31th Conference on

Object-Oriented Programming, Systems, Languages,

and Applications (OOPSLA’16), pages 74–91. ACM.

Ethereum (2024). Ethereum Virtual Machine (EVM). https:

//ethereum.org/en/developers/docs/evm/.

Feist, J., Greico, G., and Groce, A. (2019). Slither: a static

analysis framework for smart contracts. In Proceed-

ings of the 2nd International Workshop on Emerging

Trends in Software Engineering for Blockchain, WET-

SEB ’19, page 8–15. IEEE Press.

Gargantini, A., Riccobene, E., and Scandurra, P. (2008).

Model-driven language engineering: The ASMETA

case study. In 2008 The Third International Confer-

ence on Software Engineering Advances, pages 373–

378. IEEE.

Gargantini, A., Riccobene, E., Scandurra, P., et al. (2007).

A metamodel-based simulator for ASMs. In Proc. of

the 14th Intl. Abstract State Machines Workshop.

Jackson, D., Nandi, C., and Sagiv, M. Certora technology

white paper. https://docs.certora.com/en/latest/docs/

whitepaper/index.html.

Kushwaha, S. S., Joshi, S., Singh, D., Kaur, M., and Lee,

H.-N. (2022). Ethereum smart contract analysis tools:

A systematic review. IEEE Access, 10:57037–57062.

Siegel, D. (2016). Understanding The DAO

Attack. https://www.coindesk.com/learn/

understanding-the-dao-attack/.

Smashing Ethereum Smart Contracts for Fun and ACTUAL

Proﬁt (2018). Smashing Ethereum Smart Contracts

for Fun and ACTUAL Proﬁt. HITBSecConf. https:

//github.com/Consensys/mythril.

Sotnichek, M. (2019). Formal veriﬁcation

of smart contracts with the K frame-

work. https://www.apriorit.com/dev-blog/

592-formal-veriﬁcation-with-k-framework.

Tsankov, P., Dan, A., Drachsler-Cohen, D., Gervais, A.,

unzli, F., and Vechev, M. (2018). Securify: Practical

security analysis of smart contracts. In Proceedings

of the 2018 ACM SIGSAC Conference on Computer

and Communications Security, CCS ’18, page 67–82,

New York, NY, USA. Association for Computing Ma-

chinery.

Wood, G. et al. (2014). Ethereum: A secure decentralised

generalised transaction ledger. Ethereum project yel-

low paper, 151(2014):1–32.

Zhang, Z., Zhang, B., Xu, W., and Lin, Z. (2023). De-

mystifying exploitable bugs in smart contracts. In

2023 IEEE/ACM 45th International Conference on

Software Engineering (ICSE), pages 615–627. IEEE.

SECRYPT 2024 - 21st International Conference on Security and Cryptography

344