Chapter 5. Deep-Diving into Smart Contracts

In this chapter, we take a deep-dive into smart contract designs. We start by understanding the textbook definition of a smart contract. Then we move on to understanding different smart contract models and the role of code in a smart contract. We then go through the basic anatomy of a smart contract and see how a smart contract works. Then we shift our focus to some advanced topics, such as smart contract optimization, auditing, and ERC20 compliance. We conclude the chapter with a hands-on drill of building a voting DApp.

After studying this chapter, you will be able to:

• Define a smart contract and understand various design models
• Appreciate the role of code in a smart contract
• Visualize the basic anatomy of a smart contract
• Understand smart contract optimization, auditing, and compliance
• Understand the design of a voting DApp using smart contracts

What makes a contract "smart"?

Long before blockchains and the internet, in the analog era, we had mechanical devices that basically executed smart contracts. These were vending machines, as depicted in Figure 5.1. Once you pay a certain amount in a certain currency, you get to choose the product code. Once the code is confirmed, then the product comes out of the machine. If you do not pay, the product does not come out. If you delay more than the waiting-time threshold after paying, or there is any mechanical malfunction and your session expires, the product does not come out:

Figure 5.1: Vending machine

We can see that the concept of smart contracts existed way before blockchains and the internet. So, even before defining a smart contract, we must address the myths surrounding it. The myth that tops the list is whether a smart contract is intelligent. The answer is no, it is smart and dumb, but not intelligent. To understand this subtle concept, let us use the analogy of a smartphone. Does...

Basic anatomy of a smart contract design

Blockchain technology has become the jet fuel for propelling the concept of the smart contract in the world of business transactions. Large corporate institutions are rapidly adopting this concept to remain ahead of their competitors. This has led to a call for an industry-wide initiative for formalizing the design framework of a smart contract. One of the big four auditing firms, Deloitte, teamed up with the advisory board of the Digital Chambers of Commerce, has come up with a six-point anatomy to formalize a smart contract design, which has been summarized in Figure 5.4:

Figure 5.4: Six-point anatomy of smart contract design, Source: Digital Chamber of Commerce, Nov 2016

Smart contract optimization

In Chapter 2, Grokking Ethereum, we discussed the concept of ether and gas (recall the buffet and car-fuel analogy). Smart contracts that are under-optimized consume more gas than necessary. The creator and user of such smart contracts will always be over...

Designing a voting DApp

Decentralized voting on a blockchain has many perks. It is extremely hard to tamper with once a candidate is voted for. In this section, we try to design a simple voting DApp using both the private blockchain (also known as a private testnet) and remix platform that was introduced in Chapter 3, Hello World of Smart Contracts.

At this point, it will be good to recap the difference between an EthereumJS-based testrpc and Geth-based testnet from Chapter 2, Grokking Ethereum . A test RPC is a third-party client implementation used for testing. It is basically a Node.js-based Ethereum client. It simulates a full client. Whereas Geth-based testnet is an official full client implementation in the Go language, having a command-line interface, which can be used to connect to the real blockchain or on public testnet blockchains, such as Ropsten, or on a private testnet blockchain like ours.

The voting DApp we will develop has three basic functions:

• It initializes a list of candidates...

Summary

We started this chapter by busting the myths about smart contracts. We realized that smart contracts cannot make decisions on their own and need an algorithmic trigger to accomplish such a feat. We also studied the original definition of a smart contract and realized the smart contract models lie on a spectrum ranging from encoded natural language to full automation. We learned that the role of code in a smart contract consists of a judicious mix of optimization, auditing, and adhering to compliance. We discussed gas-costly code patterns that remained unoptimized by the solidity compiler and categorized them into useless code and expensive loops. Then, we took a quick look at how oraaclization is used to feed authentic data and how an issue on the GitHub archive gave rise to the ERC20 standard. We concluded the chapter by deploying a decentralized voting application on a private blockchain. In Chapter 6, Solidity in Depth, we will look into the Turing complete solidity programming...