This article will examine the history behind smart contracts, give a basic understanding of how they work, and go into some of the risks and limitations that occur when using them.

 

Setting the Stage (Skip if you don’t like reading about the background)

The year is 1994: Bill Clinton is in the White House, Nelson Mandela wins the presidency in South Africa, and a little company called Cadabra is born which a man named Jeff Bezos would later rename “Amazon”. Only 0.0446% of the world was using the internet at that time (compared to 49.723% in 2017), and people would have to wait over two decades for Ethereum’s release in 2015 to work with smart contracts.

Or so one might think.

Unbeknownst to many people, a first-generation Hungarian-American by the name of Nick Szabo had written an essay entitled, “Smart Contracts” that very same year. In it, he describes the need for a “computerized transaction protocol that executes the terms of a contract.” An example that Szabo gives of what smart contracts can be used for, is property. For instance, “if a loan was taken out to buy [a] car, and the owner failed to make payments, the smart contract could automatically invoke a lien, which returns control of the car keys to the bank…Smart property may be a ways off, but digital cash and synthetic assets are here today, and more smart contract mechanisms are being designed.” This kind of forward thinking would lead Szabo to create a type of digital currency which he called “Bit Gold” in 1998, which he would fully describe in a 2005 blog post, footnoted here. 

Alongside Wei Dai, another creator of an early digital currency called “b-money”, and Adam Back, creator of what we now call the proof-of-work consensus protocol through his currency called “Hashcash”, Szabo was part of a loose collective of cryptographers, programmers, and privacy activists called Cypherpunks, which was paving the way for Bitcoin’s creation before even the dot-com bubble burst at the turn of the century (in Satoshi Nakamoto’s original paper on Bitcoin, he references both Dai and Back and calls Bitcoin an “implementation of Szabo’s Bitgold proposal” in a 2010 forum post on Bitcointalk.org). On the Cypherpunk public mailing list (as well as on a closed mailing list with Dai), Szabo was an active member, and laid out what he believed were some of the most important goals for the group. In an August 1993 email to the Cypherpunks with the subject header “Cypherpunk trends & visions”, Szabo writes, “My own vision of cypherpunks evolution runs along the following lines…Digital cash: accumulating credits/debits for use of on-line services…eventually paid for by some ‘real’ currency.” He then goes on to list several other opportunities such as online-markets including betting, which he calls “investments” before joking, “Hey, if Clinton can call government spending ‘investment’ I can do the same for wagers on his reelection!” 

Clearly underlying Szabo’s emails is a spirit that wants a minimal amount of government or third-party control, and the same spirit that many feel within Bitcoin. In a tweet about blockchain, Szabo writes, “Blockchain governance generally comes in only three varieties: (1) Lord of the Flies, (2) lawyers, or (3) ruthlessly minimized.” Another Twitter user asked, “Why ruthless?” to which Szabo responded, “Otherwise the children or the lawyers will win.” The spirit of both Szabo’s writings and Bitcoin are so similar that in fact he is among the top suspects of Satoshi Nakamoto’s true identity. The Centre for Forensic Linguistics at Aston University in the UK completed an analysis in 2014 comparing Szabo’s writings to that of Nakamoto’s original work. Of the 11 top candidates including Szabo that were analyzed, the team from Aston University was “pretty confident” that Nick Szabo is the main author of Nakamoto’s paper, citing a number of similarities such as the use of certain phrases (i.e. “trusted third parties”, “for our purposes”, “need for”, “as long as”), punctuation, and fragmented sentences following colons and reflexive pronouns.

Whatever the truth may be, the introduction of smart contracts by Szabo long before Bitcoin was a key step that would change the course of cryptocurrency through its implementation in Ethereum. As we live in a world where “trusted third parties are security holes” as Szabo puts it, smart contracts have stepped in to fill that hole, and brought adopters like Ethereum far from being just another cryptocurrency to becoming a platform where many types of contracts between two parties can be executed and enforced.

 

Into the Ether

Let us first answer the most basic question: What is a smart contract? Quite simply, it is a piece of code that runs on a blockchain. Here is an example that may help illustrate a potential use.

Let’s say Anne has 0.5 Bitcoins and wants to borrow 1 Bitcoin from Bill (and let’s ignore interest because Bill is a nice guy and wants to keep it simple). Either Anne or Bill can write up a smart contract code that takes Anne’s 0.5 Bitcoins and keeps it in a smart contract account, effectively holding it in escrow without a third party, and then transferring Bill’s 1 Bitcoin to Anne once the smart contract account has received the 0.5 Bitcoins. If Anne does not pay Bill back within a certain amount of time, the smart contract account will automatically transfer Anne’s locked up 0.5 Bitcoins to Bill, and if Anne does pay Bill back 1 Bitcoin, then the smart contract account will give Anne back her 0.5 Bitcoins.

What is important to understand here is that once the contract is executed and recorded on the Blockchain, neither Anne nor Bill will be able to prematurely take out the 0.5 Bitcoins that have been locked up, or alter the contract in any way. That means if one of them wants to back out of the deal or otherwise cheat in any way, it would not be possible. But that also means, any code written and recorded on the blockchain is permanent – including any bugs or security vulnerabilities (which will be covered later in an example).

While this is just one example of a simple loan, Solidity, the coding language that the Ethereum blockchain uses to write smart contracts, is Turing complete, meaning that given enough time, a machine (such as a Turing Machine) can solve any logical problem using the Solidity language. 

Disclaimer: It is important to note that Ethereum is not the only blockchain platform capable of creating smart contracts. There is some controversy over whether the Bitcoin scripting language is or isn’t Turing complete (i.e. an absence of “loop” functions in Bitcoin’s script), but for certain purposes like multi-signature addressing (allows multiple users to digitally sign a single document), Bitcoin can be used. However Bitcoin is rarely on the list of coding languages that are best at writing smart contracts, while Solidity is almost always cited. In this article, we will be focusing on Solidity as it is generally regarded as the most popular programming language for developers on the blockchain. A 2019 study done by The Next Web’s Hard Fork using data from StackOverflow found that out of 2724 questions tagged “blockchain”, Solidity was the leader in terms of frequency at a total of 259 appearances. By comparison, the next most frequent languages, JavaScript, Java, and Python, made 130, 71, and 66 appearances respectively.

 

The Ethereum Virtual Machine

The Ethereum Virtual Machine, or EVM for short, is what executes the Solidity code. Each full node of the Ethereum network (i.e. computers that fully verify transactions) also runs the EVM, and this virtually separates the node’s computer from the code that is being executed. The advantage of this is that since every full node in the Ethereum network is executing the smart contract’s code, the EVM allows for all the nodes to agree on and execute the same instructions.

Below is an example of what the Solidity code may look like:

 

Sample Solidity Code

 

Gas – More Than Just For Your Car

As mentioned above, each full node on the Ethereum network is responsible for executing the code in a smart contract. But running all the code from everyone’s smart contracts is computationally expensive, which is on top of a node’s other job which is to validate transactions on the blockchain (i.e. running the Proof of Work consensus algorithm and eventually Proof of Stake on Ethereum), so who’s paying for running smart contracts?

This brings us to the concept of gas. Gas is what nodes get for any type of transaction, whether it is just sending Ether from one address to another, or executing any type of smart contract. For simple address to address transactions, the concept is the same as Bitcoin; senders can add on different amounts of transaction fees and miners pick which ones they want to add to their block, thus usually a higher transaction fee will result in a transaction being recorded on the blockchain faster.

Gas is measured in Gwei (one of several denominations of Ether), and there are 10⁹ Gwei in 1 Ether (i.e. 1 billion Gwei per Ether). A good place to check current gas prices for transactions is Ethgasstation.info, and the recommended gas prices for one to one transfers as of August 12^th 2020 are below:

For standard transactions, the gas limit is 21,000 as can be seen in a picture below from Ethereum’s yellow paper. To see what the recommended cost in USD would be for a fast transaction time, let us assume an Ether price of USD $350 for illustration purposes. For a fast transaction, each gas should be around 200 Gwei for a total of 4,200,000 Gwei (200 Gwei per gas x 21,000 gas limit). Since each Gwei is 1 billionth of an Ether, 4,200,000 Gwei would be 0.0042 Ether. At USD $350 per Ether, 0.0042 Ether would be a $1.47 transaction cost.

 

Excerpt from Table of Gas Prices:

 

However, smart contracts are more complex than one to one transfers, and therefore require more gas to compensate the nodes for increased computing power (and ultimately energy). The sample Solidity code above is in a human readable/writable format, but we needed to compile the human-readable code into something a computer can read. As part of this process, the code gets transformed into operational code, or op code for short. Each one of these op codes are basic commands such as inserting a new number onto the computing stack (which is a layered data structure that operates on a Last In First Out basis a.k.a. new numbers are put on top of the stack) or adding numbers in the stack together. Each op code has a designated amount of gas associated with it like in the picture above.

This means you can approximately calculate how much gas your contract will be using once you have compiled your code into op codes. We use the word approximately here because there can always be errors in the code which use up more gas than anticipated.

Because of this, smart contracts have a gas limit which the contract writer can designate so that if there is in fact an error, gas will not be used indefinitely. If the chosen gas number is lower than the minimum amount of gas needed to execute the code (according to the above chart), then the transaction will fail (i.e. a gas limit of 100,000 for a contract that requires 300,000). However if the transaction succeeds, the remaining gas will be refunded (i.e. 100,000 gas will be refunded for a transaction that has a gas limit of 300,000 and requires 200,000). Keep in mind however, if you decide to set a very high gas limit, let’s say 3 million, just to make sure your transaction succeeds, if the contract fails for any reason, you will lose all 3 million gas.

Besides gas limit, a smart contract writer needs to also decide how much each gas is worth, a.k.a. the gas price. Much like the gas prices used for single transactions, gas prices can depend on how fast you want nodes to add you to their block so that your contract can be executed by the whole network. Once again, Ethgasstation.info can be a good place to start when looking at what the market rates are.

Gas also serves one more important function in addition to paying nodes for their computational power: preventing a malicious party from overloading the system. If it was free to create and execute smart contracts, someone trying to crash the network could create tons and tons of “fake” smart contracts, essentially contracts that do nothing, just to waste the nodes’ energy and likely impacting price. The theory is similar to a DDoS (Distributed Denial of Service) attack on any server, in which an attacker, who sometimes uses a bot net (a network of malware infected computers which the attacker has at least some control over) to spam a particular server with requests, resulting in either a system crash or extremely slow performance. Gas makes some of these types of attacks economically unviable, although to this day, there remains a discussion on how to optimally structure gas costs to both mitigate attacks and keep smart contracts as easily usable as possible. A recent publication addressing current issues of Ethereum’s gas “metering” is footnoted here.

If the concept of gas is still a bit unclear, it may also help to picture gas as a metaphor: a car. So to get most cars to move (in this case a metaphor for executing a smart contract), they require real, physical gas. But let’s say you only need to get from point A to point B one way and therefore only want rent a car at point A and return it at point B and buy just enough gas to barely get you there from an empty tank. The gas limit would be how much you decide to buy, for instance 10 gallons which should just about get you there, assuming your trip does not take detours of any kind. But this method is a bit risky isn’t it? Often times car trips do in fact have detours, whether it’s due to construction, rest stops, or just plain getting lost. So it would be better for you to buy a bit more gas, say 11 or 12 gallons, which should cover any troubles you encounter along the way. You would probably not want to buy too much, say 20 gallons, because once you get to point B, you will be returning the car, and all the remaining gas will be wasted. When you get to the gas station however, you see that there is a line, full of people waiting to pay $3 per gallon. Now you happen to be in a hurry, so instead of waiting for your turn and saving a few bucks, you decide to go to the gas station manager and say “Hey, I’m willing to pay $5 per gallon.” That becomes the gas price, and as soon as other people see what you are doing, they all decide to come up with the maximum price they are willing to pay for faster service. The gas price is thus based on the market, and can fluctuate due to a number of factors from time to time. Putting these two concepts of gas limit and gas price together, you manage to safely arrive at your destination, and hopefully have a better understanding of how gas is used in smart contracts in the process.

 

A Bug’s Life – The DAO Hack

Now that we understand that smart contracts are simply code that executes on the blockchain, we can look at how that may be a double-edged sword. Whether it is on Ethereum’s blockchain or in any other program/application, code can have errors in it, often referred to as bugs. However, once a smart contract’s code gets uploaded to the blockchain, it cannot be changed, including any bugs it might have. This means contracts that do contain bugs can result in accidental errors or be exploited purposefully.

On April 30^th 2016, a Decentralized Autonomous Organization (a.k.a. DAO, which is essentially a set of programs designed to run autonomously that can both raise money through crowdfunded token sales, and spend money based on consensus) called “The DAO” began raising money which would lead to one of the largest crowdfundings in history at over USD $150 million by the time end of the 28-day funding period. One of The DAO’s creators, Stephan Tual, then announced on June 12^th 2016 that a “recursive call bug” had been found in the code, although he assured investors that “No DAO funds are at risk”.

Since the contract was already live and the network was well into the phase of deciding what to do with the raised funds, the bug was not patched in time, and on June 17^th 2016, a hacker began using the “recursive call bug” to withdraw Ether from the contract (To go deeper into how the attack worked, an article is footnoted here, but is beyond the scope of this article). By June 18^th 2016 over 3.6 million Ether was transferred from The DAO, to a separate DAO that was structurally the same as The DAO. This meant that the attacker was not able to move the funds from the separate “child DAO” for 28 days, and gave the community time to decide on how to handle the attack.

Interestingly, the attacker sent a message to the community after the attack occurred (which can be read here), asserting that the attack was legal and was deserved full ownership of the Ether as the “law” of what is allowed in smart contracts is what is written in code. In the end, Ethereum did a hard fork on June 20^th 2016 (which essentially creates a side chain from the original blockchain and thus two separate currencies) as some of the community wanted to return the money lost from the hack, and others viewed that such an action would compromise the integrity of the network by allowing transactions to be reversed. To this day, we have the Ethereum Classic cryptocurrency, which includes the hack’s effects, and the Ethereum cryptocurrency, which allowed investors to recoup their locked-up Ether.

Along with debate on the legality of stealing from a contract that does not take place in any jurisdiction, the hack on The DAO highlighted the need to be absolutely sure about your code before running it live on the Blockchain, especially with more complicated smart contracts which can have a wider surface area of attack.

 

Smart Contracts And Their Limitations

While smart contracts combined with blockchain technology do have many use cases, it is important to understand that there are limitations. In an opinion piece from Coindesk, Founder and CEO of Coin Sciences, Dr. Gideon Greenspan, cites three smart contract use cases that they have been pitched before that either simply cannot be done, or need workarounds.

First is the ability for smart contracts to take in outside data and execute their code based on the data. A potential example might be a smart contract that takes in weather data to execute some type of agricultural contract (i.e. insurance policy). If you recall, a smart contract is executed by every node on the blockchain, so the problem with this is that each node would need to have the same input data to reach a consensus on the outcome, otherwise the smart contract will fail. Even if a particular source of weather news was designated for all nodes to access, it is not a guarantee that there won’t be an error, perhaps due to latency or a faulty API. The solution to this problem is to assign “oracles” which act as trusted parties to take the external data and disperse that same data to all the nodes to ensure unanimous data. This solution is still being developed however, as Deloitte puts it in their report entitled “Getting Smart About Smart Contracts,” they say, “Because smart contracts can reference only information on the blockchain, trustworthy data services – known as ‘oracles’ – that can push information to the blockchain will be needed. Approaches for creating oracles are still emerging.”

The second problem Dr. Greenspan brings up is the use of smart contracts to enforce on-chain payments. The idea is that if a borrower wants to borrow using a smart contract, they must lock up their collateral in the smart contract, making the loan useless (since the collateral is almost always greater than the amount loaned, the borrower could have just used their collateral. And if the collateral is not locked up in the smart contract, then there is no way to guarantee payment to the lender.

The third problem he describes is hiding confidential data. Dr. Gideon gives the example that within a hypothetical blockchain of 10 banks, 2 banks conduct a transaction which is immediately seen by all other 8 banks. He continues by saying, “Some people think that smart contracts can solve this problem. They start with the fact that each smart contract contains its own miniature database, over which it has full control. All read and write operations on this database are mediated by the contract’s code, making it impossible for one contract to read another’s data directly…Even if one smart contract can’t read another’s data, that data is still stored on every single node in the chain. For each blockchain participant, it’s in the memory or disk of a system which that participant completely controls. And there’s nothing to stop them reading the information from their own system, if and when they choose to do so.” 

 

Key Takeaways

Smart contracts have come a long way from Szabo’s original proposal in 1994. Although smart contracts are not a new technology, there are still many applications of smart contracts which have not yet been fully explored. It is important to understand the fundamentals of what smart contracts are so that there are no unrealistic expectations of what they can do: they are pieces of code that run on each node of a blockchain, nothing more, nothing less. In the same way, one could look at the internet and say, it’s just a bunch of connections between computers, nothing more, nothing less, which in itself is true. But decades ago, we would never have anticipated the pervasiveness the internet has in our lives, as company after company in every industry built on top of it, using the internet to improve efficiency and lower costs. And such a destiny may be the fate of smart contracts, as it remains to be seen.

 

References

1、https://www.inc.com/bill-murphy-jr/amazon-cadabra-jeff-bezos-25-year-anniversary-1994.html

2、https://data.worldbank.org/indicator/IT.NET.USER.ZS

3、https://www.nytimes.com/2015/05/17/business/decoding-the-enigma-of-satoshi-nakamoto-and-the-birth-of-bitcoin.html

4、http://www.fon.hum.uva.nl/rob/Courses/InformationInSpeech/CDROM/Literature/LOTwinterschool2006/szabo.best.vwh.net/smart.contracts.html

5、http://www.fon.hum.uva.nl/rob/Courses/InformationInSpeech/CDROM/Literature/LOTwinterschool2006/szabo.best.vwh.net/smart.contracts.html

6、https://unenumerated.blogspot.com/2005/12/bit-gold.html

7、https://bitcoinmagazine.com/articles/genesis-files-bit-gold-szabo-was-inches-away-inventing-bitcoin

8、https://bitcoin.org/bitcoin.pdf

9、https://bitcointalk.org/index.php?topic=342.msg4508#msg4508

10、https://bitcoinmagazine.com/articles/genesis-files-bit-gold-szabo-was-inches-away-inventing-bitcoin

11、http://cypherpunks.venona.com/date/1993/08/msg00426.html

12、https://cypherpunks.venona.com/date/1993/08/msg00426.html

13、https://www.newyorker.com/magazine/2018/10/22/the-prophets-of-cryptocurrency-survey-the-boom-and-bust

14、https://www.newyorker.com/magazine/2018/10/22/the-prophets-of-cryptocurrency-survey-the-boom-and-bust

15、https://cointelegraph.com/news/what_s_in_a_name_linguistic_study_identifies_nick_szabo_as_the_real_satoshi_nakamoto

16、http://www.fon.hum.uva.nl/rob/Courses/InformationInSpeech/CDROM/Literature/LOTwinterschool2006/szabo.best.vwh.net/ttps.html

17、https://hackernoon.com/turing-completeness-and-the-ethereum-blockchain-c5a93b865c1a

18、https://medium.com/@craig_10243/a-proof-of-turing-completeness-in-bitcoin-script-3cf5aa7aeb83

19、https://www.binance.vision/glossary/turing-complete

20、https://coinjournal.net/debunking-the-bitcoin-cannot-do-smart-contracts-myth/

21、https://www.blockchain-council.org/blockchain/best-programming-languages-to-build-smart-contracts/

22、https://media.consensys.net/solidity-is-twice-as-popular-as-the-next-blockchain-coding-language-9330af9aeaa3

23、https://media.consensys.net/solidity-is-twice-as-popular-as-the-next-blockchain-coding-language-9330af9aeaa3

24、https://www.bitrates.com/guides/ethereum/what-is-the-unstoppable-world-computer

25、https://legacy.mycrypto.com/helpers.html

26、https://ethgasstation.info/

27、https://ethereum.github.io/yellowpaper/paper.pdf

28、https://techterms.com/definition/stack

29、https://support.mycrypto.com/general-knowledge/ethereum-blockchain/what-is-gas

30、https://arxiv.org/pdf/1909.07220.pdf

31、https://medium.com/@pullnews/understanding-the-dao-hack-for-journalists-2312dd43e993#.kw0ufw25q

32、https://blog.slock.it/no-dao-funds-at-risk-following-the-ethereum-smart-contract-recursive-call-bug-discovery-29f482d348b

33、https://etherchain.org/account/0x304a554a310c7e546dfe434669c62820b7d83490#history

34、https://medium.com/@MyPaoG/explaining-the-dao-exploit-for-beginners-in-solidity-80ee84f0d470

35、https://medium.com/@pullnews/understanding-the-dao-hack-for-journalists-2312dd43e993#.kw0ufw25q

36、https://pastebin.com/CcGUBgDG

37、https://blog.ethereum.org/2016/07/20/hard-fork-completed/

38、https://www.coindesk.com/three-smart-contract-misconceptions

39、https://www2.deloitte.com/tr/en/pages/finance/articles/cfo-insights-getting-smart-contracts.html

40、https://www.coindesk.com/three-smart-contract-misconceptions