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 best practices. 5, 17

Conclusion

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.

 

References

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/ research/commits/master/papers/casper-basics/ casper_basics.pdf.

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.
coindesk.com/ethereum-executes-blockchain-hard-
fork-return-dao-investor-funds/.

7. Dwork, C. and Naor, M. Pricing via Processing or Combatting Junk Mail. Springer Berlin Heidelberg, 1993, 139–147.

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) 51–68.

11. Hansen, P. B. Operating System Principles. Prentice-Hall, Inc., 1973.

12. Hearn, M. The resolution of the Bitcoin experiment, (2016); https://blog.plan99.net/the-resolution-of-the- bitcoin-experiment-dabb30201f7.

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), 549–557.

16. Marr, B. Blockchain implications every insurance company needs to consider now.

Forbes, (2017); https://www.forbes.com/sites/ bernardmarr/2017/10/31/ blockchain-implications-every-insurance-company-needs-to-consider- now/2#982922468825.

17. Maurelian. Beyond Smart Contract Best Practices for UX and Interoperability; https://medium.com/@ maurelian/beyond-smart-contract-best-practices-for- ux-and-interoperability-6d94d27c1e0f.

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:// eprint.iacr.org/2016/454.

21. Poon, J. and Dryja, T. The Bitcoin Lightning Network: Scalable Off-Chain Instant Payments, (2016); https:// lightning.network/lightning-network-paper.pdf.

22. Popper, N. A venture fund with plenty of virtual capital, but no capitalist. New York Times (May 22, 2016); https://www.nytimes.com/2016/05/22/business/ dealbook/ crypto-ether-bitcoin-currency.html.

23. Prisco, G. Smart Contracts and the Future of Banking, (2017); https://www.nasdaq.com/article/smart- contracts-and-the-future-of-banking-cm849118.

24. Sergey, I. and Hobor, A. A Concurrent Perspective on Smart Contracts. CoRR abs/1702.05511 (2017). arXiv:1702.05511; http://arxiv.org/abs/1702.05511

25. Sompolinsky, Y., Lewenberg, Y. and Zohar, A. SPECTRE: A Fast and Scalable Cryptocurrency Protocol. Cryptology ePrint Archive, Report 2016/1159; http://eprint.iacr.org/2016/1159.pdf

26. Tapscott, D. and Tapscott, A. Blockchain could help artists profit more from their creative works. HBR, (2017); https://hbr.org/2017/03/blockchain-could-help- artists-profit-more-from-their-creative-works.

27. Vigna, P. Chiefless Company rakes in more than

$100 million. WSJ, (2016); https://www.wsj.com/ articles/ chiefless-company-rakes-in-more-than-100- million-1463399393.

28. Vogelsteller, F. and Buterin, V. ERC- 20 Token Standard; https: // github.com/ethereum/EIPs/blob/master/ EIPS/ eip-20.md.

29. Wikipedia. Signalling Theory; https://en.wikipedia.org/ wiki/Signalling_theory.

 

Maurice Herlihy ( [e-mail]) 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 Communications video. https://cacm.acm.org/videos/ blockchains-from-a-distributed-computing-perspective