Chapter 6. Solidity in Depth

This chapter is all about the Turing-complete solidity language on the Ethereum blockchain. We will start by peeking into the design decisions and why we really need a new language such as solidity at all. The next sections will cover the nuances of the solidity language and basic syntax used in it. Specifically, we will cover the contract-oriented features, functions, events, inheritance, libraries, expressions, control structures, units, and variables. Then we will peek into the optimizer and debugging options. We will conclude this chapter by analyzing the code flaw that led to the recent Parity wallet hack in the Ethereum blockchain that stole around $30 million worth of ethers.

After studying this chapter, you will be able to:

• Appreciate the need for solidity over other high-level languages
• Understand the nuances, syntax, and features of solidity
• Peek into the solidity optimizer and debugging options
• Analyze the flaw behind the $30 million Parity wallet hack

Need for solidity

Let me tell you a dirty secret about programmers. We are the laziest lot of technicians in the entire community of engineering. We work really hard to remain lazy. We abide by the oath:

"If necessity is the mother of all inventions, laziness is their father."

No wonder we love the open source movement so much. Reusing another lazy programmer's code is what we fantasize about. And to add a little sprinkle of hypocrisy, we never ever forget to complain or criticize how messy the original code was, and how heroically we drove away the bugs and documented it to make it 2.0 or higher. It is just in our blood.

But, sometimes, in this land of lazy nerds, there comes an outlier, one who writes something entirely original from scratch. The entire lazy community then laughs at this scratchy code. Slowly this outlier removes the bugs from the new stuff, and starts getting traction. Still, we keep ignoring it. By now the outlier has already moved out to do yet another new thing and some...

Nuances, syntax, and features of solidity

The most striking feature of solidity lies in its resemblance to ECMA Script standards (ES6 Harmony). To begin with, a solidity source file layout contains an arbitrary number of contract definitions along with pragma directives and optional imports at a global scope along with comments.

Pragma, import, and comments

A pragma directive of solidity always has versions in the form 0.x.0 or x .0.0, as shown in Figure 6.1. This ensures that any future version of the solidity compiler is ignored that might introduce incompatibility:

Figure 6.1: Pragma directives

Although solidity does not have the ability to export or spool-out results yet, it supports import statements, which are very similar to JavaScript. This keyword is used at contract compile time in our local build environment. Once a contract gets deployed on a blockchain using EVM, it can neither read nor write files. Figure 6.2, lists down a few uses of the import statement at the global scope:

Figure...

Optimizer and debugging options

In the previous chapter, we studied how gas-costly coding patterns are classified into two categories in terms of smart contract optimization. In this section, we will try to understand how the internal optimizer of the solidity compiler works. The sole aim of this optimizer is to generate assembly opcodes and, subsequently, machine code from high-level programming constructs in a way that reduces the gas cost during runtime.

We will go through a high-level view of the optimizer, take on a simple contract, and see how our assembly opcodes are generated in the presence and absence of an optimizer. This will also serve as an option to debugging a solidity smart contract for better performance in terms of gas-cost.

So what happens in a solidity optimizer when it is fed with a piece of code? It basically splits the sequence of instructions into blocks of atomic instructions at JUMPs and JUMPDESTs opcodes. It operates on the assembly so that it can be used by other...

Parity hack demystified

Parity (https://parity.io/) is a UK-based, venture capitalist-funded, tech start-up company. They provide an Ethereum client, also called Parity, which has an extensive Ethereum wallet and DApp environment for contract deployment. The entire application is written and compiled in the RUST language. The wallets are multi-sig. Multi-sig wallets, in simple words, are wallets that require at least two separate agreements to spend a token from the wallet. These wallets are supposed to be more secure than normal single-sig wallets.

Unfortunately, on July 19, 2017, three multi-sig wallets were exploited from a total of 596 wallets with similar vulnerabilities. Figure 6.10 shows these compromised accounts in Etherscan, the public Ethereum block explorer. When the Parity team got alerted of this hack, they tackled this situation by forming a "White Hat Group" and used the same vulnerability to siphon all the tokens from the remaining 593 wallets into a safe repository so that...

Summary

Solidity is a work-in-progress yet well-documented language, being gradually developed as users face various problems while implementing smart contracts on the blockchain. In this chapter, we have covered a few fundamental aspects of this new language. We started off with praising JavaScript and how it has evolved as a robust language for web development. Solidity has been chosen for the blockchain on this legacy. Then we moved on to see various nuances this language has to offer us with its new concept of contract-oriented programming. We then nose-dived into the solidity optimizer's inner workings, and explored debugging options using events and bare-bone assembly opcodes. We closed the chapter by discussing and analyzing the Parity wallet hack, which helped in gaining deeper insights into how libraries and fallback functions play a crucial yet vulnerable role in ensuring the future of the smart contract industry. To be honest, it is just the beginning and we have barely scratched...