The transferFrom() function
(Lines 17–23) transfers tokens from
one account to another, and decreases the allowance by a corresponding
amount. This function assumes the recipient has sufficient allowance for the
transfer to occur.
Here is how this specification can
lead to undesired behavior. Alice calls
approve() to authorize Bob to transfer as many as 1,000 tokens from her
account to his. Alice has a change of
heart, and issues a transaction to reduce Bob’s allowance to a mere 100
tokens. Bob learns of this change,
and before Alice’s transaction makes
it onto the blockchain, Bob issues a
transferFrom() call for 1,000 tokens to a friendly miner, who ensures
Bob’s transaction precedes Alice’s in
the next block. In this way, Bob successfully withdraws his old allowance
of 1,000 tokens, setting his authorization to zero, and then, just to spite
Alice, he withdraws his new allowance
of 100 tokens. In the end, Alice’s attempt to reduce Bob’s allowance from
1,000 to 10 made it possible for Bob
to withdraw 1, 100 tokens, which was
not her intent.
In practice, ERC20 token implementations often employ ad-hoc work-arounds to avoid this vulnerability, the
most common being to redefine the
meaning of allow() so that it will reset
an allowance from a positive value to
zero, and in a later call, from zero to the
new positive value, but will fail if asked
to reset an allowance from one positive
value to another.
The problem is that approve()
blindly overwrites the old allowance
with the new allowance, regardless
of whether the old allowance has
changed. This practice is analogous to
trying to implement an atomic decre-
ment as shown in Figure 4. Here, the
decrement method reads the shared
counter state into a local variable
(Line 4), increments the local variable
(Line 5), and stores the result back in
the shared state (Line 6). It is not dif-
ficult to see that this method is incor-
rect if it can be called by concurrent
threads, because the shared counter
state can change between when it was
read at Line 4 and when it was written
at Line 6. When explained in terms of
elementary concurrent programming,
the ERC20 concurrency flaw is obvi-
ous, but when expressed in terms of
smart contracts that ostensibly do not
need a concurrency model, the same
design flaw was immortalized in a to-
ken standard with a valuation estimat-
ed in billions of dollars.
Discussion. We have seen the notion that smart contracts do not need
a concurrency model because execution is single-threaded is a dangerous
illusion. Sergey and Hobor24 give an
excellent survey of pitfalls and common bugs in smart contracts, explaining how they are disguised versions of
familiar concurrency pitfalls and bugs.
Atzei et al. provide a comprehensive
survey of vulnerabilities in Ethereum’s
smart contract design. Some of today’s
languages’ pitfalls and traps can be
avoided by carefully following codes of
Radical innovation often emerges
more readily from outside an established research community than from
inside. Would Nakamoto’s original Bitcoin paper have been accepted to one
of the principal distributed conferences back in 2008? We will never know, of
course, but the paper’s lack of a formal
model, absence of rigorous proofs, and
lack of performance numbers would
have been a severe handicap.
Today, blockchain research is one
of the more vibrant areas of computer science, with the potential of
revolutionizing how our society deals
with trust. The observation that many
blockchain constructs have under-acknowledged doppelgängers (or at
least, precursors) is not a criticism of
either research community, but rather
an appeal to each side to pay more attention to the other.
1. Attiya, H. and Welch, J. Distributed Computing:
Fundamentals, Simulations and Advanced Topics.
John Wiley & Sons, 2004.
2. Buterin, V. and Griffith, V. Casper the Friendly Finality
Gadget, (2017); https://github.com/ethereum/
3. Cachinm, C. and Vukolic, M. Blockchain consensus
protocols in the wild (Keynote Talk). In Proceedings
of the 31st International Symposium on Distributed
Computing. Andréa W. Richa, ed. (2017), 1:1–1: 16.
4. Castro, M. and Liskov, B. Practical Byzantine fault
tolerance and proactive recovery. ACM Trans. Comput.
Syst. 20, 4, (2002) 398–461.
5. Consensys, Inc. Ethereum Smart Contract Security
Best Practices; https://consensys.github.io/smart-contract-best-practices/
6. del Castillo, M. Ethereum Executes Blockchain Hard
Fork to Return DAO Funds, (2016); https://www.
7. Dwork, C. and Naor, M. Pricing via Processing or
Combatting Junk Mail. Springer Berlin Heidelberg,
8. Ethereum; https://github.com/ethereum/.
9. Garay, J., Kiayias, A., and Leonardos, N. The Bitcoin
Backbone Protocol: Analysis and Applications. Springer
Berlin, Heidelberg, 2015, 281–310.
10. Gilad, Y., Hemo, R., Micali, S., Vlachos, G., and
Zeldovich, N. Algorand: Scaling Byzantine agreements
for cryptocurrencies. In Proceedings of the 26th
Symposium on Operating Systems Principles, (2017)
11. Hansen, P. B. Operating System Principles.
Prentice-Hall, Inc., 1973.
12. Hearn, M. The resolution of the Bitcoin experiment,
13. Herlihy, M. Wait-free synchronization. ACM Trans.
Program. Lang. Syst. 13, 1 (1991) 124–149.
14. Herlihy, M. and Shavit, N. The Art of Multiprocessor
Programming. Morgan Kaufmann Publishers, Inc., 2008.
15. Hoare, C.A.R. Monitors: An operating system
structuring concept. Commun. ACM 17, 10 (Oct. 1974),
16. Marr, B. Blockchain implications every
insurance company needs to consider now.
Forbes, (2017); https://www.forbes.com/sites/
17. Maurelian. Beyond Smart Contract Best Practices
for UX and Interoperability; https://medium.com/@
18. Nakamoto, S. Bitcoin: A Peer-to-Peer Electronic Cash
System, (2009); http://www.bitcoin.org/bitcoin.pdf.
19. O’Byrne, R. How Blockchain Can Transform the Supply
Chain, (2017); https://www.logisticsbureau.com/how-blockchain-can-transform-the-supply-chain/.
20. Pass, R., Seeman, L., and Shelat, A. Analysis of the
Blockchain Protocol in Asynchronous Networks.
Cryptology ePrint Archive Report 2016/454; https://
21. Poon, J. and Dryja, T. The Bitcoin Lightning Network:
Scalable Off-Chain Instant Payments, (2016); https://
22. Popper, N. A venture fund with plenty of virtual capital,
but no capitalist. New York Times (May 22, 2016);
23. Prisco, G. Smart Contracts and the Future of Banking,
24. Sergey, I. and Hobor, A. A Concurrent Perspective
on Smart Contracts. CoRR abs/1702.05511 (2017).
25. Sompolinsky, Y., Lewenberg, Y. and Zohar, A.
SPECTRE: A Fast and Scalable Cryptocurrency
Protocol. Cryptology ePrint Archive, Report
26. Tapscott, D. and Tapscott, A. Blockchain could help
artists profit more from their creative works. HBR,
27. Vigna, P. Chiefless Company rakes in more than
$100 million. WSJ, (2016); https://www.wsj.com/
28. Vogelsteller, F. and Buterin, V. ERC- 20 Token Standard;
https: // github.com/ethereum/EIPs/blob/master/
29. Wikipedia. Signalling Theory; https://en.wikipedia.org/
Maurice Herlihy ( firstname.lastname@example.org) is the
An Wang Professor of Computer Science at Brown
University, Providence, RI, USA.
© 2019 ACM 0001-0782/19/2 $15.00
Watch the authors discuss
this work in the exclusive