ERC20: Correctness via Linearizability and Interference Freedom of the

Underlying Smart Contract

Rudrapatna K. Shyamasundar

∗

Department of Computer Science and Engineering, Indian Institute of Technology Bombay, Powai, Mumbai 400076, India

Keywords:

Distributed Programs, ERC20 Tokens, Smart Contract, Linearization, Consensus, Interference Free.

Abstract:

ERC20 is a standard for the creation of a speciﬁc type of tokens called ERC20 tokens, one of the most widely

adopted tokens on Ethereum. ERC20 tokens are transferred through dedicated transactions among Ethereum

addresses, and managed by smart contracts. Nondeterministic behaviour has been observed on the smart

contracts that manage ERC20 tokens resulting in owners losing signiﬁcant amounts while using it. In this

paper, we ﬁrst discuss issues of nondeterministic behaviour in the ERC20 smart contract, and the standard

general remedies that have been proposed in the literature to avoid nondeterministic behaviour in ERC20.

Then, through the notion of linearizability, it is shown that as ERC20 permits unbounded concurrency, the

linearizability of the ERC20 smart contract is undecidable - thus, demonstrating the subtle complexity of

ERC20 and the strong synchronization requirements of ERC20. Finally, treating ERC20 smart contract as a

set of asynchronous interacting processes executing on a blockchain, we describe an approach that is common

in classical programming language speciﬁcation, and show how a set of constraints on the traces of ERC20

executions based on interference freedom property for concurrent execution on the blockchain overcomes the

nondeterministic behaviour; we shall further sketch how such an execution can be implemented in Solidity.

Furthermore, we discuss how the two approaches of linerarization and interference freedom mutually beneﬁt

each other and assist in arriving at constraints that leads to wait-free implementation of smart contracts.

1 INTRODUCTION

Blockchain platforms, need their own currency, a sort

of tradable tokens, for interoperable services. Tokens

are blockchain-based assets which can be exchanged

across users of a blockchain platform. Tokens typ-

ically need to follow a standard so that it is possi-

ble to write tools, such as liquidity pools and wal-

lets, that work with tradable tokens. For instance,

in the Ethereum platform, tokens can represent vir-

tually anything such as (i) ﬁnancial assets (shares in a

company), (ii) ﬁat currency (eg., INR), (iii) standard

unit of gold, (iv) reputation points in an online plat-

form, (v) lottery tickets etc. Naturally, such a power-

ful feature must be handled through a robust standard.

Ethereum Request for Comment (ERC)20 deﬁnes a

standard for the creation of a speciﬁc type, called

ERC20 tokens, one of the most widely adopted tokens

on Ethereum. ERC20 tokens are transferred through

dedicated transactions among Ethereum addresses,

and are managed by smart contracts. It is a standard

∗

The work was carried out in the Centre for

Blockchain Research sponsored by Ripple Labs.

for fungible tokens. That is, they satisfy a property

that makes each token to be exactly the same (in type

and value) as another token - that is, tokens are mutu-

ally exchangeable. Thus, ERC20 is a standard way to

implement basic features of all tokens making them

compatible with common Ethereum software such as

Ethereum Wallets etc. In this paper, we shall ﬁrst

discuss issues, and attack scenarios on ERC20 smart

contracts, and provide a brief overview of existing

mitigation techniques to forbid unwanted behaviours

of ERC20. Secondly, we shall demonstrate the sub-

tle difﬁculties of ERC20 smart contract by showing

that linearization of ERC20 methods as it stands is

undecidable; this result shows the subtle strong syn-

chronization requirements of ERC20. Finally, we en-

visage a novel way of realizing robustness of ERC20

smart contract using techniques of interference free-

dom used concurrent program veriﬁcation. An inter-

pretation of linearization and interference freedom as-

sists in arriving at appropriate constraints so that the

smart contracts when executed on a blockchain is able

Shyamasundar, R.

ERC20: Correctness via Linearizability and Interference Freedom of the Underlying Smart Contract.

DOI: 10.5220/0012145800003555

In Proceedings of the 20th International Conference on Security and Cryptography (SECRYPT 2023), pages 557-566

ISBN: 978-989-758-666-8; ISSN: 2184-7711

 2023 by SCITEPRESS – Science and Technology Publications, Lda. Under CC license (CC BY-NC-ND 4.0)

557

to realize the intended sequential behaviour

Rest of the paper is organized as follows: Section

2 highlights the ERC20 standard with descriptions of

its interface, attack scenarios of ERC20 in Section

3. In Section 4, we discuss informal and formal ap-

proaches to mitigate attacks in the use of ERC20. Sec-

tion 5 shows that the linearization of ERC20 is unde-

cidable. Finally, we discuss how establishing inter-

ference freedom of concurrent procedures will lead to

arriving at the intended sequential behaviour without

resorting to locks in Section 6 followed by conclu-

sions in Section 7.

2 ERC20 TOKEN STANDARD

A large number of Ethereum development standards

focus on token interfaces that help in ensuring com-

posable nature of smart contracts. ERC20 is the ear-

liest token standard by Ethereum. We shall brieﬂy

describe the interface

below.

As pointed out already, the purpose of token stan-

dards like ERC20 is to allow a spectrum of token im-

plementations that are inter-operable across applica-

tions, like wallets, decentralized exchanges etc. For

this purpose, an interface (similar to that in Java), is

deﬁned so that any code that needs to use the token

contract can use the same deﬁnitions as in the inter-

face and remain compatible with all the token con-

tracts that use it, whether it is a wallet, a Dapp, or a

different contract such as a liquidity pool. A brief on

the main interface functions are given below

1. function totalSupply() external view

returns (uint256): Returns the amount of

tokens in existence.

• This is an external function, i.e., it can be called

only from outside the contract. It returns the

total supply of tokens in the contract using the

unsigned 256 bits - the native word size of the

EVM. It is a view function, and hence, does not

change the state; thus, it can be executed on a

single node. As the function does not generate

The importance of analysing ERC20 like smart

contracts can be seen by the very recent tweet: Scam Sniffer

(@realScamSniffer) tweeted at 3:41 am on Mon, May 01,

2023: someone lost $2.28m worth of USDC by ERC20 Per-

mit phishing 6 hours ago https://t.co/x17Gw8w1Bw

https://t.co/ 4jmyeVT1Ym (https://twitter.com/

realScamSniffer/status/ 1652797793587851264?t=

k7NtBkmdxiJjDYjIYq7OhQ&s=03)

https://ethereum.org/en/developers/docs/standards/

tokens/erc-20/

https://ethereum.org/en/developers/tutorials/

erc20-annotated-code/

a transaction, it does not consume gas. Note

that anyone can view anyone’s account balance

(there are no secrets on the blockchain).

• A question may arise as to what if the contract

creator returns a smaller total supply count than

the real value, making each token appear more

valuable than it actually is. This is not possi-

ble as a characteristic of the blockchain is that

anything that happens on the blockchain can be

veriﬁed by every node. To conﬁrm this, ev-

ery contract’s source code and storage must be

available on every node. While it is not manda-

tory to publish the Solidity code for the con-

tract, nobody would take the contract seriously

unless the source code and the object code on

which it was compiled is published; assuming

the code has been published, we can rule out

the possible cheating as mentioned above.

2. function balanceOf(address account)

external view returns (uint256);

balanceOf returns the balance of an account.

• Note that Ethereum accounts are identiﬁed in

Solidity using the address type, which holds

160 bits. Similar to totalSupply(), this is

also an external function in view only mode and

thus, can be used by anyone.

3. function transfer(address recipient,

uint256 amount) external returns

(bool); transfer transfers the speciﬁed

number of tokens from the caller-user to a

different receiver-user (and reduces its balance of

tokens by that quantity) if available. transfer

function is called to transfer tokens from the

sender’s account to an account of another user;

it returns a boolean value, that is always true.

The call transfer fails, for instance, when there

are not enough tokens, and in such a case the

contract reverts the call. Note that the owner

(sender) is transferring tokens to another address

(user/customer). The execution involves a change

of state, creating a transaction and thus, costs

gas. It also emits an event, transfer, to inform

everybody on the blockchain that the event

transfer has happened.

• transfer has two types of outputs depending

on the type of callers:

(a) Users that call the function directly from a

user interface: Here, user submits a transac-

tion and does not wait for a response, which

could take an indeﬁnite amount of time. The

user can ascertain execution of the transaction

by looking for the transaction receipt (which

is identiﬁed by the corresponding transaction

SECRYPT 2023 - 20th International Conference on Security and Cryptography

558

hash) or by looking for the transfer event.

(b) Other contracts which call the function as part

of the overall transaction: Such contracts get

the result immediately, as they are running in

the same transaction, and thus, can use the

function return value.

4. function allowance(address owner,

address spender) external view returns

(uint256);

• Using allowance, anybody can query to see

what is the allowance that one address (owner)

lets another address (spender) spend.

5. function approve(address spender,

uint256 amount) external returns

(bool); approve creates an allowance for

another user. Note that there is no need that

the sender must have those very many tokens

approved by him at that time (or even later).

• approve is the function that makes the stan-

dard quite complex and enables users to mis-

use/abuse intentionally or unknowingly. Note

that in an asynchronous system, the owner of a

resource can control the order of his own trans-

actions but not control the order of transaction

of other users. Thus, the method call can be

interpreted as an account (or variable) that can

be modiﬁed by multiple accounts/users. The is-

sue with such complex operations will become

clear in the sequel.

6. event Transfer(address indexed from,

address indexed to, uint256 value);

• Emitted when ‘value‘ tokens are moved from

one account (‘from‘) to another (‘to‘); note that

the value could be zero. Further, the respective

event is emitted when the state of the ERC20

contract changes.

7. function transferFrom(address sender,

address recipient, uint256 amount)

external returns (bool); the call

transferFrom is used by the spender to spend

the allowance that has been earlier approved

(granted) by other user/owner for it.

• Functionally, the operation (i) transfers an

amount less than or equal to the allowance that

has been approved by some other owner/user,

(ii) reduces the allowance by that amount, and

(iii) the operation fails if the amount to be trans-

ferred is greater than the approved allowance (if

that happens, it reverts).

• One of the main differences between transfer

and transferFrom is that in the former the

owner decrements the number of tokens when

he sends the tokens to some other user, whereas

in the latter the grantee decrements the number

of tokens he uses to send it to some other user.

In a sense, it is like there are multiple owners

for the address.

8. event Approval(address indexed owner,

address indexed spender, uint256

value);

• Emitted when the allowance of a ‘spender‘ for

an ‘owner‘ is set by a call to approve. ‘value‘

is the new allowance. Again note that the emis-

sion of the event transfer takes place when

the state of the ERC20 contract changes.

9. There are other user interface functions that are

needed for the actual usage but are not relevant

for our discussion here.

3 ATTACKS AND THEIR

MITIGATION

In this section, we shall analyze issues of the possible

attack scenarios and their mitigation using the above

described interface speciﬁcation, from a programmer

perspective as well as from the synchronization re-

quirement of the smart contract.

3.1 Basic Attack Scenario

Consider a scenario of users (say owners of accounts)

, · ·· ,U

}. Let A

i j

∀i 6= j be the Allowance ap-

proved by U

to user U

, ∀i 6= j. It is to be noted that

users {U

, · ·· ,U

} are essentially asynchronous

processes. Possible attack scenarios on ERC20 have

been highlighted by several authors

and are illus-

trated below:

1. U

approves 80 tokens to U

(i.e., A

is 80)

2. U

realises that he made a mistake and wants to

revise the approval to only 50 tokens.

3. To correct the mistake, U

sends out an approval

using Approve for 50 tokens to U

4. Now there are two possibilities:

(a) It is possible U

has already withdrawn x to-

kens, 0 ≤ x ≤ 80, using transferFrom . In

such a case, U

will get an additional 50 tokens

over and above x.

https://docs.google.com/document/d/

1YLPtQxZu1UAvO9cZ1O2RPXBbT0mooh4DYKjA\

jp-RLM/edit\#.)

ERC20: Correctness via Linearizability and Interference Freedom of the Underlying Smart Contract

559

(b) If U

has not transferred the approved tokens

from U

then the allowance A

will get set to

50 tokens as wanted by U

could have used anywhere between x

+ 50 to 80+50 tokens

The basic reason for such an anomalous behaviour

is that users/processes {U

, · ·· ,U

} are asyn-

chronous and hence, leads to nondeterminism as the

program does not use either locking or a synchro-

nization construct. A naive programmer understands

that the execution on blockchains like Ethereum using

smart contracts is sequential (as intended in Solidity)

and thus, does not realize the underlying nondeter-

minism due to interleaving. The authors of (Sergey

and Hobor, 2017) capture this through the following

analogy of the underlying artifacts:

Accounts using smart contracts on a

blockchain are like threads using concurrent

objects in shared memory with correspon-

dences of artifacts as below: contract state to

object state, call/send to context switching,

Reentrancy to (Un)cooperative multitasking,

Invariants to Atomicity and Nondeterminism

to Data races.

Before we look at possible approaches of making

ERC20 deployment robust, let us understand the com-

plexity of the problem from the illustrated attack sce-

nario.

While one could have illustrated the attack using

only two users, we introduced n users to understand a

general scenario to expose the underlying complexity.

From the above discussions, the following facts can

be observed about the ERC20 interface speciﬁcation:

1. transfer can be interpreted as follows: An user,

say U

(the owner-the token creator), transfers

to other user accounts U

, j 6= i some number

of his tokens from his total supply recorded in

TotalSupply. Looking at the function in an iso-

lated manner, the semantic action corresponds to

(owner) decreasing its TotalSupply

by x ev-

ery time he sends out x tokens; note that except for

nobody else can write into its TotalSupply.

That is, the only writer of TotalSupply is its owner.

2. transferFrom can be interpreted as follows:

Here, user U

, takes x number of tokens that are

≤ A

(allowed by Owner U

to U

), and transfers

to some other user U

, i, k 6= j. Thus, U

writes

into the storage, TotalSupply owned by U

to set

its count after usage.

For the sake of simplicity let us assume TotalSupply

also denotes the total number of tokens it has.

3. Looking at (1)-(2) above, we can see the storage

of U

need to be written by all the other users. If

we treat each of the accounts U

as assets, one can

see that each account in principle can be written

by other accounts/users who are not its’ owners.

4. Overlaying the use of Approve as highlighted

along with (1)-(3) provides a complete picture of

the execution of ERC 20 usage in a given de-

ployed context.

Thus, to establish the intended sequential speci-

ﬁcation of ERC20 deployment, we not only have to

show that the attack scenario relative to Approve is

not possible but also show that execution traces aris-

ing from (1)-(2) above also do not introduce any new

attack scenarios.

4 OVERCOMING ATTACKS

NAIVELY

Here, we brieﬂy provide an overview of efforts in the

literature for a robust ERC20 deployment.

4.1 Naive Programming Tricks to

Achieve Robustness

Some of the tricks a programmer (a clairvoyant!) can

do to overcome data races/nondeterminism are:

1. Restrict token transfers to only smart contracts (or

trusted account holders!) whose source code and

object code are public from which one can assure

that the logic needed for the transfers shown in the

attack scenario are not possible.

2. Set the Allowance to zero after every

transferFrom. Note that such a constraint

imposes the following restrictions: (a) Forbids

the possibility of several transfers of the approved

tokens up to the limit of approve, and (b) Either

one uses the tokens approved at once or loses

those that have not been used. It is easy to see

that it changes the interface itself.

3. In

additional interface functions

increaseAllowance(address spender,

uint256 addedValue) − > bool and

decreaseAllowance(address spender,

uint256 subtractedValue) − > bool

are introduced, where the latter is interpreted

as follows: Atomically decrease the allowance

granted to the spender by the caller. Even

https://docs.openzeppelin.com/contracts/4.x/api/

token/erc20#ERC20-decreaseAllowance-address-uint256.

SECRYPT 2023 - 20th International Conference on Security and Cryptography

560

with an enhancement, the same nondeter-

minism persists as one can see from the

command sequence: Approve(80, ...);

decreaseAllowance(40, ...); the number of

tokens utilized could vary from 40 (when the user

has not used any of the tokens given as allowance)

and 80 (when the user has already utilized 80

tokens) assuming decreaseAllowance() does

not do anything when the number is already zero.

Thus, ambiguity persists in spite of atomicity

being enforced on these two new functions. This

is due to strong synchronization requirements as

discussed in Section 5.

Assuming that the blockchain platform is a public

ledger and supports viewing of the source codes, if the

strategies (i.e., assumptions/commitments) indicated

are indeed possible, it shall not have the attack vector

indicated above.

4.2 Approaches Using Formal Analysis

In this section, we shall brieﬂy describe two of the

formal approaches that have been used to tackle such

scenarios.

One of the very interesting attempts has been a

proposal for adaptation of the classic proof-carrying

code (pcc) (Dickerson et al., 2018) to overcome the

property of immutability of the smart contract on the

blockchain through the speciﬁcation invariant spec-

iﬁcation of the methods used in the smart contract.

Referring the adaptation as proof-carrying smart con-

tract (pcsc), the authors illustrate a part of ERC20

speciﬁcation in terms of the invariants of the meth-

ods of ERC20. The basic ideas of their proposal is

briefed below:

• The ﬁrst idea is that of setting the Allowance

to zero after every transferFrom as already dis-

cussed in the previous subsection.

• The second modiﬁcation can be understood in two

phases: the ﬁrst is to show how the data races

could be overcome and the second phase is to

mimic the functionality of load-linked (LL) and

store-conditional (SC) instructions. LL loads a

value from memory, and SC writes new value to

the same location, if and only if it has not been

written since the matching LL.

One of the aims of the proposal is to ﬁnd ways

to overcome the issue of immutability of smart con-

tracts once it is on the blockchain. One of their pro-

posals is to specify through invariants so that imple-

mentational changes can be catered to keeping the

speciﬁcation invariant. In summary, the proposal con-

sists of modifying the program after exploring an ab-

stract speciﬁcation of ERC20, and proposes a speci-

ﬁcation/implementation using notione like lineariza-

tion, etc., (Herlihy and Shavit, 2012). Note that the

suggested ideas change in some sense the intended

behaviour of ERC20 itself. While such an analysis is

extremely useful for smart contract programmers, it is

difﬁcult to say how such approaches can be adopted in

practice as it involves an understanding of rich mathe-

matical formalism of derivation of invariant formally.

We shall revert to the use of notions like lineralizabil-

ity (Herlihy and Shavit, 2012)) that can be applied to

analyse smart contracts to assure the preservation of

sequential speciﬁcation of smart contracts in the se-

quel.

5 LINEARIZATION AND ERC20

Subtle correctness criteria for concurrent systems

is adherence to established sequential speciﬁcations.

This demands that each concurrent execution of op-

erations corresponds to some serial sequence of the

same operations permitted by the speciﬁcation at the

level of abstraction described by the speciﬁcation of

the operations. In the context of distributed programs,

the concept of linearization proposed in (Herlihy and

Shavit, 2012) has been the foundation for such a cri-

teria. This is briefed below.

The standard correctness requirement for con-

current implementations of abstract data structures

packaged into a concurrent library is the concept of

linearizability (Herlihy and Shavit, 2012; Bouajjani

et al., 2013), that requires every method or operation

to be atomic (behave as if it were executed in one in-

divisible step) for establishing the sequential speciﬁ-

cation of each of the methods under concurrent exe-

cution. The notion of linearizability identiﬁes the so-

called linearization points of each operation. These

are program points where the entire effect of a method

call logically takes place. However, these lineariza-

tion points are quite complicated as they often depend

on a non-local boolean conditions and plausibly even

reside in other concurrently executing threads. This

makes a brute force search for the linearization points

infeasible. A little more formal deﬁnition is given be-

low.

Deﬁnition 1: Linearizability (Herlihy and Shavit,

2012; Bouajjani et al., 2013) is a formalisation of the

concept of atomicity. It demands that every execution

history consisting of calls to the methods is equiva-

lent (up to reordering of events) to a legal, sequential

history that preserves the order of non-overlapping

methods in the original history. We say that a his-

tory is sequential if none of its methods overlap in

ERC20: Correctness via Linearizability and Interference Freedom of the Underlying Smart Contract

561

time; moreover, it is legal if each method satisﬁes its

speciﬁcation

Before we see whether the general ERC20 is lin-

earizable, let us see the general possible execution

traces from the ERC20 functional speciﬁcation.

5.1 General Trace Behaviour of ERC20

From the discussion of the ERC20 functional speciﬁ-

cation given in section 2, it can be seen that functions

like transfer or transferFrom revert when there

are not enough tokens for the transaction. In view of

this, we can see that the execution traces are nothing

but a regular expression over all the calls speciﬁed

in ERC20. Based upon the parameters, we can dis-

tinguish calls like transfer(i,j), transferFrom

(i,j,k) and so on. Thus, we can say

1. The execution is just a regular expression over

the method signatures with parameters as given

above.

2. While the contract is on the blockchain, there is

no restriction on the number of instances of the

different methods including parallel invocation.

3. Also all the methods described in ERC20 keeping

in view the sequential execution are realizable as

loop-free programs.

From the above possible execution traces, let

us ask the following questions about the usage of

methods that lead to transactions like Approve,

Allowance, transfer, and transferFrom in a

concurrent way:

1. If a method Approve () is called (in a sense over-

lapping call) while one call is pending or execut-

ing still, what should be the execution semantics?

2. It is possible to have a scenario of having user U

trying to utilize A

i j

through an appropriate method

call to transferFrom(), corresponding to writ-

ing by U

to record the balance of allowance in

(i.e., the balance in A

i j

). Further, user U

, say

k, i 6= j could also be sending some coins to U

using a method call transferFrom. This corre-

sponds to overlapping writes by distinct users to

the same locations.

3. Apart from other symmetrical combinations of

scenario depicted in (2), scenarios corresponding

to combinations of transfer and transferFrom

from the users are possible, reﬂecting multiple

users attempting to write into the same location.

Informally, in the context of linearization, a begin-call

and end-call of a method can be treated to be happening at

some time point between the beginning and the end of the

method call.

From the deﬁnition of transferFrom, it should

be clear that nondeterminism arises as multiple

writers concurrently write onto the same locations.

The illustrations shown above depict overlapping

executions–that is the crux of its nondeterministic be-

haviour. As already mentioned, linearization is one

of the main techniques that is used to realize deter-

ministic implementation of distributed programs. We

shall discuss such an application on ERC20 below and

analyse its subtle features.

5.2 Is ERC20 Linearizable?

If it is possible to show that ERC20 is linearizable,

then we would have arrived at an implementation that

would not have nondeterministic behaviour or races

as we can realize an implementation using wait-free

programs and CAS (compare and swap) registers.

That is, we could have a spectrum implementations

for programs that satisfy linearization, that are race-

free and free of nondeterministic behaviour.

From (Bouajjani et al., 2013), we have the follow-

ing theorem:

Theorem 1: The linearizability problem for un-

bounded concurrent computations with regular speci-

ﬁcations is undecidable (cf. (Bouajjani et al., 2013)).

From this theorem we can conclude,

Theorem 2: The linearizability of ERC20 is undecid-

able.

Proof: The proof follows from trace characteristics

given in section 5.1 noting that there no a priori bound

on the number of threads. Note that the full simula-

tion used in (Bouajjani et al., 2013) follows easily.

Now the question is: Is it possible to enforce a set

of constraints (perhaps minimal in a qualitative sense)

without deviating too much from the intended speci-

ﬁcation of ERC20 that makes it linearizable.

The above question has been answered afﬁrma-

tively in (Guerraoui et al., 2019) while assessing

the consensus number (Herlihy and Shavit, 2012) of

crypto-currency. As it is quite interesting, we shall

provide a brief discussion the notion of consensus and

consensus number below.

Deﬁnition 2: Consider an object, each provided with

a thread with one method, say DECIDE(T value).

Now N threads operating on the object concurrently

have to return a value such that:

Consistent: all threads decide the same value, and

Valid: the common decision is some thread’s input.

We say that a class of objects C solves N-thread con-

sensus if there exists a consensus protocol using any

number of objects of class C and any number of

atomic registers.

SECRYPT 2023 - 20th International Conference on Security and Cryptography

562

Deﬁnition 3: Consensus number of a class C is the

largest N for which N-thread consensus is solvable.

If no such n exists, consensus number is said to be

inﬁnite.

Note: In a system with N or more concurrent threads

it is impossible to construct a wait-free or lock-free

implementation of an object with consensus number

N from an object with a lower consensus number (Fis-

cher et al., 1985). A register with CompareAndSet()

and get() methods has an inﬁnite consensus number.

The authors of (Guerraoui et al., 2019) have

carved out a k-shared asset transfer problem (very

informally, it allows multiple reading and writing

from shared accounts each of which have a bounded

set of owners – see the informal interpretation of

transferFrom given earlier) from ERC20 and pro-

vide a wait-free implementation for the same; the

main restriction placed by the authors is that of stat-

ically ﬁxing the set of owners for each account and

hence, bounding the number of threads that can be

there at run time a priori. The wait free implementa-

tion provided in (Guerraoui et al., 2019) result corre-

lates with the results in (Bouajjani et al., 2013) that

shows that linearization with a ﬁxed set of threads is

solvable. Another interesting aspect of this study has

been the carrying out, a subtle analysis of strong syn-

chronization requirement of ERC20 in (Alpos et al.,

2021). It is useful to recall the classic result from Fis-

cher, Lynch, and Paterson (Fischer et al., 1985) that

establishes the impossibility of wait-free implementa-

tion of consensus from atomic registers. That is, con-

sensus requires a higher level of synchronization than

atomic registers and the consensus object is univer-

sal, in the sense that any shared object described by a

sequential speciﬁcation can be wait-free implemented

from consensus objects and atomic registers (Herlihy

and Shavit, 2012). Thus, it follows that consensus

plays a crucial role to reason about the synchroniza-

tion power of all shared objects (which admit a se-

quential speciﬁcation) among a number of processes.

Such a role is captured through the concept of con-

sensus number to express the synchronization power

of shared objects. Returning to (Alpos et al., 2021),

the authors show that ERC20 supports a richer set of

methods compared to standard cryptocurrencies, and

thus, results in strictly stronger synchronization re-

quirements. Informally speaking, the authors estab-

lish dependency of the lower bound and the upper

bound on the consensus number of the stakeholders

, · ··U

, on the object’s state that can be modiﬁed by

method invocations; this is interpreted as that number

of threads cannot be bounded a priori.

In fact, the result captured in our Theorem 2

above, demonstrates the same in a succinct straight

forward manner.

In distributed/concurrent program analysis, an-

other general approach to establish correctness is the

notion of interference freedom. We shall show the ap-

plication of this concept for ERC20.

6 ERC20 AND INTERFERENCE

FREEDOM

The notion of interference freedom in the concur-

rent execution of programs (Owicki and Gries, 1976)

plays a vital role in the establishment of correctness in

concurrent/distributed programs. We shall deﬁne the

notions in a semi-formal way below.

Deﬁnition 4: Let P be the pre-condition, Q be the

post-condition and and S be the program. Then the

triple {P} S {Q} denotes the well-known Hoare’s

triple with the interpretaion: If P is true before exe-

cution of program S, then Q holds if and when execu-

tion of S terminates. The triple represents the partial-

correctness of S relative to P and Q.

Deﬁnition 5: Given {P} S {Q} and another statement

T with pre-condition pre(T), the statement T is said to

be non-interfering with {P} S {Q} if the following

two conditions holds:

• {Q ∧ pre(T)} T {Q}, and

• {pre(S’) ∧ pre(T)} T {pre(S’)}, where S’ is an

await or assignment statement within S but not

within an await block.

Continuing with our earlier discussion, it is quite

clear that to realize a robust deterministic speciﬁ-

cation for ERC20, we need to ensure interference-

freedom as deﬁned in Deﬁnition 5 for the vari-

ous methods that are deﬁned in ERC20. For in-

stance, execution scenarios like (a) overlapping of

calls Approve(50) and Approve (40), or (b) an

Approve call in lieu of the earlier Approve. That is,

interpretation of combining concurrent/overlapping

Approve operations

must be unambiguous; scenario

(b) corresponds to withdrawal (preemption) of the

ﬁrst Approve when the second is issued. Such a

preemptive operation is not realizable in an asyn-

chronous setting as shown in (Berry et al., 1993) as

preemption is essentially a non-monotonic operation.

Thus, for correctness purposes, it is necessary to en-

force constraints on the underlying read/write oper-

ations (which is indeed the approach highlighted in

(Dickerson et al., 2018)). From the results in (Alpos

et al., 2021), we can see that simple atomicity at the

In the ERC20 standard, this is left unspeciﬁed.

ERC20: Correctness via Linearizability and Interference Freedom of the Underlying Smart Contract

563

In the following, we shall articulate conditions un-

der which the depicted nondeterminism scenario can

be overcome via techniques used in classical concur-

rent programming language speciﬁcation and discuss

how they can be enforced in languages like Solidity.

6.1 Deriving Required Constraints for

Non-Interference

Concurrent programming languages have been de-

signed emphasizing on correctness in particular non-

interference. For instance, one of the early well de-

signed languages, Ada, was quite disciplined from

a concurrent perspective; here integrity was real-

ized through mutuallly exclusive access of shared re-

sources. For this reason, Ada rendezvous was consid-

ered inefﬁcient as it did not permit concurrency even

when the operations were non-interfering. There have

been lot of research to realize efﬁciency/performance

without foregoing correctness. For instance (Shya-

masundar and Thatcher, 1989) explored a language

structure to realize data integrity without unnecessary

mutual exclusion. Thus, in the context ERC20 spec-

iﬁcation that assume a sequential speciﬁcation, we

shall approach the technique explored in (Shyamasun-

dar and Thatcher, 1989): permit methods to operate in

parallel, multiple incarnations or overlapping only if

they do not interfere. In the following, we apply the

following restrictions using that approach and arrive

at the following set of restrictions:

1. Consider the restriction: user U

cannot make a

call to method Approve for U

unless A

i j

is zero.

That is, the user to whom U

has given an al-

lowance awaits full utilization by it before issuing

another approval for allowance. Note that utiliza-

tion may happen through several calls and thus,

does not restrict the allowance usage through one

call only and thus, there is no issue of under-

utilizing the approved number of tokens. It is

to further note that the full utilization of the al-

lowance is observable on the blockchain. Note

that the described semantics is valid for Solidity.

2. Method calls of form either transfer or

transferFrom for each user is expected to

happen in a non-interfering manner. As

transferFrom semantically corresponds to mul-

tiple processes reading and writing into other lo-

cations of other processes. Thus for avoiding data

races/nondeterminism, it is necessary to permit

only multiple reads or writes that do not interfere

with each other. Some of the interference cases

due to multiple writings and reading/writing are

given below:

(a) Approve

(k, x) and Approve

(n, y) interfere

when i = n (this is the illustrated case above).

(b) Trans f er

( j, x), Trans f er

( j, y) interfere as-

suming i and k are distinct as i and k are writing

into the common location of j.

( j, k, x), trans f erFrom

(m, n, y)

interfere when k = n or j = m

(d) Trans f er

( j, x) and trans f erFrom

(k, m, y) in-

terfere when k = j.

(e) other combinations of constraints not given for

lack of space.

3. It must be pointed out that several non-

conﬂicting concurrent operations like transfer

or transferFrom are still permitted and thus,

constraints are general than mutual exclusion.

Realizing Constraints in Solidity: The above con-

straints can be realized in the programming language

Solidity by transforming the original method calls to

guarded execution of method calls where the guard is

nothing but the constraints to be enforced. Guards sat-

isfying the constraints can be realized using require,

assert and revert constructs of Solidity; in fact,

this is the underlying principle used in the imple-

mentation of exceptions as well as safeMath library

in a robust manner in Solidity. Such a technique

has been the basis in the work explored in (Shya-

masundar, 2022) to derive run-time monitors for a

spectrum of vulnerabilities of Solidity through classi-

cal declarations (that enforces certain constraints for

the compiler) in Solidity, where language Solidity

with declarations is referred to as Solidity

. Using

the constraints of the methods, highlighted above, as

guards, we can implement ERC20 in an interference-

free manner – thus overcoming its nondeterministic

behaviour. We shall not go into further details for lack

of space.

6.2 Discussion

The approach of interference-freedom highlighted

above allows us to see how the constraints overcome

concurrent execution of interfering programs. In fact,

some of the approaches of mitigation as highlighted

in section 4, and 4.2 follow from the analysis given

in section 6.1. In other words, by placing restric-

tions, we shall ﬁnd a way of bounding concurrency

and hence, derive a wait-free implementation of the

methods. This shall not only capture the sequential

speciﬁcation intended in Solidity but also enables one

to arrive at an efﬁcient implementation that do not use

locks. We are of the opinion that such a methodology

will provide further directions in analysing smart con-

tracts and arriving at proof carrying smart contracts.

SECRYPT 2023 - 20th International Conference on Security and Cryptography

564

Applications to Revisions of ERC20: Some of the

most popular revisions of token standards are:

1. ERC-721: is a standard interface for non-fungible

tokens, like a deed for an artwork or a song,

2. ERC-777: allows people to build extra function-

ality on top of tokens such as a mixer contract for

improved transaction privacy or an emergency re-

cover function to bail you out if you lose your pri-

vate keys,

3. ERC-1155: allows for more efﬁcient trades and

bundling of transactions – thus saving costs. This

token standard allows for creating both utility to-

kens (such as $BNB or $BAT) and Non-Fungible

Tokens like CryptoPunks, and

4. ERC-4626 - A tokenized vault standard designed

to optimize and unify the technical parameters of

yield-bearing vaults.

ERC777 is a reﬁnement of ERC20 and provides a new

feature called hooks, to simplify the sending process

offering a single channel for sending tokens to any

recipient. One of the main differences with respect

to ERC20 is the mechanism of allowing processes

to manage tokens on behalf of others. In ERC20,

the approve method lets an account owner p deﬁne

an amount of tokens that some process p

can spend

from the account of p. In contrast, the operator in

ERC777 allows process p

that has been approved by

p to spend all the tokens owned by the approving pro-

cess p.

It is clear that standards like ERC777, ERC721

etc., need to be further analyzed for robustness with

respect to the intended interpretation. Our methods

discussed above provide a sound approach for fur-

ther investigation of the revisions and assist in arriv-

ing at robust deterministic behaviour of correspond-

ing smart contracts.

7 CONCLUSIONS

We have discussed the issues of nondeterminism in

ERC20, and analysed the complexity of synchroniza-

tion requirements of ERC20. Using the approach of

linearization , we have shown how the general ERC20

smart contract is not linearizable demonstrating the

strong synchronization requirements of ERC20 in

comparison to just simple smart contracts for cryp-

tocurrency operations. Further, we have demonstrated

through the approach of interference-freedom, how

constraints can be derived for enforcing a determin-

istic behaviour on ERC20. We discussed a sketch

of the implementation in Solidity using guarded

execution of method calls - that is all the meth-

ods are preceded by appropriate guards (as in Dijk-

stra’s guarded commands). In a sense, our applica-

tion of linearization and the approach of interference-

freedom have highlighted how overlapping execution

of interfering programs leads to nondeterministic be-

haviour. The approach of interference-freedom high-

lighted allows us to see how appropriate constraints

can be placed to overcome concurrent overlapped ex-

ecution of interfering programs. As illustrated in 6.2,

the approach provides assistance in arriving at con-

straints for which efﬁcient wait-free implementations

can be realized without loosing the intuition of the So-

lidity sequential speciﬁcation of smart contracts. The

approach further assists in analysing a plethora of to-

ken standards as most of the revisions are backward

compatible and have additional features along with

powerful methods.

In summary, the paper has analysed the complex-

ity of ERC20 from different perspectives and the tech-

niques proposed are also of general interest to smart

contract designers to visualize deterministic execu-

tion of smart contracts on blockchain platforms.

REFERENCES

Alpos, O., Cachin, C., Marson, G., and Zanolini, L. (2021).

On the synchronization power of token smart con-

tracts. In 2021 IEEE 41st ICDCS, pages 640–651.

Berry, G., Ramesh, S., and Shyamasundar, R. K. (1993).

Communicating reactive processes. In Proc. of the

20th ACM POPL, page 85–98.

Bouajjani, A., Emmi, M., Enea, C., and Hamza, J.

(2013). Verifying concurrent programs against se-

quential speciﬁcations. volume LNCS, 7792, pages

290–309. Springer Berlin Heidelberg.

Dickerson, T., Gazzillo, P., Herlihy, M., Saraph, V., and

Koskinen, E. (2018). Proof-carrying smart contracts.

In Financial Cryptography and Data Security: FC

2018, page 325–338. Springer-Verlag.

Fischer, M. J., Lynch, N. A., and Paterson, M. S. (1985).

Impossibility of distributed consensus with one faulty

process. J. ACM, 32(2):374–382.

Guerraoui, R., Kuznetsov, P., Monti, M., Pavlovi

c, M., and

Seredinschi, D.-A. (2019). The consensus number of

a cryptocurrency. In Proc. 2019 ACM PODS, page

307–316, New York, NY, USA.

Herlihy, M. and Shavit, N. (2012). The Art of Multipro-

cessor Programming, Revised Reprint. Morgan Kauf-

mann Publishers Inc., San Francisco, CA, USA, 1st

edition.

Owicki, S. and Gries, D. (1976). An axiomatic proof

technique for parallel programs i. Acta informatica,

6(4):319–340.

Sergey, I. and Hobor, A. (2017). A concurrent perspective

ERC20: Correctness via Linearizability and Interference Freedom of the Underlying Smart Contract

565

on smart contracts. In Financial Cryptography and

Data Security, pages 478–493. Springer.

Shyamasundar, R. K. (2022). A framework of runtime mon-

itoring for correct execution of smart contracts. In Int.

Conf. on Blockchains, LNCS (ICBC2022)), pages 92–

116. Springer Nature.

Shyamasundar, R. K. and Thatcher, J. W. (1989). Language

constructs for specifying concurrency in cdl. IEEE

Trans. Software Engineering, 15(8):977–993.

SECRYPT 2023 - 20th International Conference on Security and Cryptography

566