Introduction to Blockchain

Blockchain technology was born with the invention of Bitcoin—a new form of peer-to-peer (P2P) electronic cash—back in 2008. The Bitcoin white paper was released on October 31, 2008 and the first release of Bitcoin came on January 3, 2009. The blockchain space is still a toddler in terms of adoption and the tools available. It has some unique properties that did not exist before in any of the previous systems or software applications. The most important property of blockchain is establishing trust between two or multiple parties without needing any intermediaries, which opens a new era in programming.

Ethereum is one of the implementations of blockchain. Ethereum is an open source, public, and distributed computing platform. On Ethereum, developers can deploy smart contracts written in the Solidity language and build a decentralized application—also called dApp, Ðapp, Dapp, or DApp.

Smart contracts are small programs where developers can define the rules of the trust that they intended to code. One of the mind-boggling properties of smart contracts is immutability—once they are deployed on the blockchain, their code cannot be changed. This immutable property makes it very hard to program smart contracts and predict errors/bugs beforehand.

In this chapter, we will learn more about blockchain technology, and when and where blockchains should be used. We will also introduce Ethereum and smart contracts.

The following topics will be covered in this chapter:

• Introduction to blockchain
• Properties of a blockchain
• What is Ethereum?
• Introduction to smart contracts
• Why smart contracts are different from traditional software programs

Understanding blockchain

A blockchain is a timestamped series of immutable transactions that is managed by a cluster of computers using special computer algorithms. These immutable records are not owned by any single entity. A blockchain is a decentralized P2P network of nodes. Each node in a blockchain shares the same copy of data, also called the digital ledger. Each node present in the network uses the same algorithm to reach a consensus.

A blockchain, by design, is resistant to the modification of data. The ledger can record transactions between two parties in a verifiable and permanent way. Whenever there is a change in the ledger using transactions, changes are distributed to all the nodes, to verify and update their own copy of the ledger. Once a transaction is stored and verified by all the nodes in the network, then it is not feasible to change the transaction without altering all the subsequent and previous blocks. That's why blockchain transactions are irreversible, as blockchain transactions and their data are append only. 

Each computer that participates in this P2P network is called a node. Each node maintains the records of transactions in multiple consecutive blocks. The P2P network is also used in torrents such as BitTorrent; however, torrent networks are not like blockchains, as they are designed to shares files only.

Blockchain technology is also called Decentralized Ledger Technology (DLT), as each node in the network keeps the same copy of the ledger. Please have a look at the following diagram:

Chain of connected blocks

In the preceding diagram, each block is connected with a link (also known as a chain). The chain is usually recognized as the chain of all the blocks. The link between two blocks is implemented by having a record of the cryptographic hash of the previous block in each block, so that you can visit the chain in reverse chronological order.

One question that may arise in your mind is, what is the difference between a traditional software application that processes the transaction and a blockchain that also processes the transaction? Then, why you would need blockchain technology? Well, blockchain technology solved one of the hard problems of computer science—the double-spending problem. Let's understand what is the double-spending problem..

It is extremely hard to reverse a blockchain transaction. However, there have been cases when a 51% attack allowed an attacker to double-spend coins. One such example is when Ethereum Classic (symbol: ETC) was attacked with a 51% attack, in which approximately $1.1 million worth of ETC was lost.

Blockchain solves the double-spending problem

As we know, we can share documents and pictures over the internet with someone. When we share those documents or pictures with another person, we actually share a copy of the file. Once that copy is sent to another person, you and the other person have the same copy of that document.

However, things such as money, bonds, and shares must not be shared as copies, like we do for documents/pictures when we need to transfer them over the internet. If you try to send money P2P, without using any intermediaries, then both parties end up having the same copies of the money. This is called the double-spending problem.

For example, if Alice gives a $10 bill to Bob, then Alice must not hold a copy of the $10 bill, as it's given to Bob. These are called value transfers. To transfer those items that have values over the internet, we need to depend upon Trusted Third Parties (TTPs). Banks and stock exchanges are the TTP on which we rely for transferring values (money and shares) from person A to B. For value transfers between two parties over the internet, they both have to depend upon a trusted middle party (centralized) to process the transactions and ensure the safety of transactions.

Blockchain solved this double-spending problem. Now, for value transfers between two parties, neither of them have to depend upon a middleman (trusted party). They both can do safe transactions directly. Blockchain's decentralized network and consensus algorithm ensures the safety of transactions and prevents the double-spending problem.

Properties of blockchain

Blockchain has properties of both decentralized and distributed networks. Using those types of networks along with cryptography adds more properties. We are covering properties related to the Ethereum blockchain rather than other blockchain implementation properties. The other blockchain implementations might have different properties. Let's discuss those properties.

Distributed ledger

Multiple nodes make up a distributed blockchain network. All nodes share a common ledger, where records of transactions are kept.

Fault tolerance 

A blockchain network is distributed and each node maintains the same record of the ledger. Even if some nodes in the network are corrupted or go down, it can continue operating safely up to a certain limit, as well as processing transactions with running nodes.

Attack resistance

A blockchain network does not have centralized control. The network's resistance to attacks is maintained by the miners who are putting their processing power (using nodes)  into use to guard against malicious attacks. These miners earn some incentives to keep the network safe by behaving honestly. This is done by using the distributed network and cryptographic techniques.

Remove intermediaries

Blockchain technology removes the dependence on TTP/middle parties/intermediaries. Using blockchain technology, a transaction can be done directly between two entities/systems. In place of intermediaries, we can place blockchain systems.

Consensus protocol

This is a protocol that ensures that all nodes participating in the network ensure the safety of the network. All nodes use a consensus protocol (a specific algorithm) to reach a consensus and discard the blocks generated by the attacker/bad node, to avoid catastrophic system failure. For example, Bitcoin and the Ethereum blockchain, at the time of writing, work on the Proof-of-Work (PoW) consensus protocol. Ethereum uses the Ethash PoW consensus algorithm, which is Application Specific Integrated Circuit (ASIC) resistance. In the future, Ethereum will switch its consensus algorithm from PoW to Proof-of-Stake (PoS).

The PoW protocol is a consensus algorithm in which nodes compete with other nodes to solve a cryptographic puzzle. The node that solves the puzzle first adds a new block to the blockchain (called mining). By doing this, they also earn some block reward in the blockchain's native coin.

The PoS protocol is a consensus algorithm in which a person has to put the native blockchain coin up for stake (lock). The protocol selects a miner randomly or according to coinage. The miner is rewarded when the block added is valid, otherwise they may lose their stake.

Faster settlement

Traditional banking systems can be slow in some cases, as they need additional time for processing a transaction; for example, cross-border payments.. However, with blockchain technology, there are no intermediaries; therefore, the transaction happens directly between entities and the settlement is much faster, compared to traditional systems. 

Lower transaction fees

Using the traditional banking system, doing a cross-border payments is costly. The intermediaries take their commission to process the transaction between two parties. But by using blockchain technology, the cost of doing transactions is significantly lower because we can remove the intermediaries and perform the transactions directly.

Transparency

Some blockchain systems maintain transparency. Ethereum is a public blockchain network. All the transactions of the Ethereum blockchain are public and transparent. Anyone can see the balance and transaction history of any wallet at any time, just by accessing the Ethereum public blockchain via a block explorer. However, some work toward having privacy on the Ethereum blockchain is being done; for example, using the AZTEC protocol.

Immutability

Every transaction that happens on the Ethereum blockchain is immutable. Smart contracts on the Ethereum blockchain are also immutable. Once the smart contract code is deployed, it cannot be changed. Smart contract code will remain on the blockchain forever. Anyone can see any deployed smart contract any time in the future as well, just by putting its contract address on the block explorers. Data that is being stored in smart contract variables is also immutable, unless there are data removal techniques that have not been exposed by the contract code.

Irreversible transactions

Once a transaction is executed on a blockchain and it receives sufficient confirmation, the transaction becomes irreversible. The irreversible transaction ensures the safety of the value transfer. The higher the number of confirmations received for a transaction, the harder it becomes to reverse the transaction from the attacker. 

Trust in the network

As of today, we are using the existing TTP systems of bank servers or stock exchange trade servers. These are centralized and are continuously being attacked. If an attacker takes control of the database server of a trade server, it can make changes in the database and put in fake entries.

However, the immutability and irreversibility of transactions makes blockchain technology more trusted. It becomes very hard for an attacker to change any entries in the blockchain transactions. This makes blockchain more trusted in terms of maintaining pure immutability and irreversible transactions. You can trust the Ethereum public mainnet; however, you cannot trust testnet completely (this may change, but at the moment, testnet is only used for testing).

I am going to define two types of trust here—artificial trust and trustless systems.

Artificial trust

When replacing trusted middle parties (intermediaries) with blockchain technology, I call it artificial trust. Blockchain technology will be trusted while doing P2P transactions. A person only has to trust the blockchain technology that is going to execute their transaction.

Trustless systems

Two people, without knowing each other, can do transactions using blockchain technology. They do not have to trust each other, they only have to trust blockchain technology. For both persons, it is a trustless system.

Availability

Centralized systems sometimes have to go through regular maintenance and downtime, resulting in inconvenience to the users. The blockchain is decentralized, so even if some nodes go down/are corrupted, the network will continue to function and will be available to process transactions 24/7.

Empower individuals

Each individual entity/person has their own wallet's public and private keys on the blockchain network. Using those wallets, they are in full control of their assets and the privileges available for those wallets. Blockchain assures that the ownership of a person's data is in their hands.

However, an individual can only maintain full control over their cryptocurrency or data when they own the private keys of their wallet. When the private keys of their wallet is maintained by another entity, such as centralized exchanges, they may not have full control.

Wallet: A wallet is software that keeps one or more cryptographic private and public keys. Using these keys, you can interact with different blockchains and are allowed to send and receive digital currencies. You can also interact with smart contracts using any of the accounts present in your wallet.

Chronological order of transactions

Blockchains keep their transactions in blocks. Multiple transactions are coupled together and stored in a new block. Next, that new block is appended to the chain of previous blocks. This keeps all the blockchain transactions maintained in chronological order.

Timestamped

Every transaction on the blockchain is stamped with the current time. This enables the blockchain to maintain all the transaction histories of an account. Also, this can be used to prove whether or not a transaction happened on a certain date and at a certain time.

Sealed with cryptography

Asymmetric cryptography is used for wallet generation and transaction signing using the Elliptic Curve Digital Signature Algorithm (ECDSA). All transactions are packed together using the Merkle tree and SHA-256 cryptographic algorithms. This makes blockchains secure and reliable to use.

When to use blockchain

As we have looked into the double-spending problem, blockchain technology solves this problem and opens new opportunities to create programs/systems where we can remove the trusted parties and make value transfers between two people directly.

The first implementation of blockchain is the Bitcoin blockchain. The Bitcoin blockchain solves the problem of making value transfers. A person can transfer bitcoins (these have some value) to another person without needing a middle party to process the transaction. Because trust is now transferred from middle parties (TTP) to the blockchain decentralized network, which uses a consensus algorithm called PoW to ensure the trust and safety of transactions.

The Ethereum blockchain, on the other hand, is a generic blockchain, on which you can write smart contracts and define the rules of the trust. In a way, if you can define trust in a code language, you can write smart contracts.

When not to use blockchain

Use blockchain technology as a tool for the development of specific scenarios. As we have seen in previous sections, blockchain technology can solve some problems where you want to replace an intermediary/middleman/TTP and do P2P value transfer transactions. This also includes problems where it is possible to replace existing trust with software-defined trust, using smart contracts. 

You should not use Blockchain to replace your existing database. If your specification requirements can be solved with other software tools and techniques, then you should use those only. If there is no requirement for blockchain in your system architecture, avoid using it. For example, you do not need blockchain when building very high throughput, latency-critical transaction processing systems. However, when blockchain technology improves in terms of high throughput in the future, and you need some of the previously discussed properties of blockchain in your system, it would be a wise decision to use it.

Blockchain is slow

At the time of writing, the implementation of the Ethereum blockchain is slow and cannot handle high transaction throughput. There are some Ethereum upgrades scheduled to improve transaction throughput. Experiments and developments in improving transaction throughput for different blockchain implementations are still going on.

Let's compare the current situation of Ethereum with improvements planned for the future:

• As of now, Ethereum is like a single-threaded computer. It can process one transaction at a time.
• Sharding of blockchain would improve it and make it like a multithreaded computer. It would be able to process more transactions in parallel. 
• The PoS consensus algorithm would help increase the reliability of the chain when a new block is generated in the blockchain.
• Layer 2 solutions, such as plasma and state channels, would enable off-chain transactions to process in near real time, and these transactions would be sent to the main chain periodically. 

Considering the slowness and limited storage of Ethereum, it is not advisable to use Ethereum for pure database usage or for high processing power requirements. Storage on the blockchain is costly, so we should ensure that we know what we are trying to develop and whether it really requires the blockchain to be involved in its application architecture.

Blockchain depends on off-chain oracles

On their own, a blockchain is a separate network. It uses P2P networking over the internet to keep sharing transactions between nodes, but it does not have a way to get the data from outside (such as any data present on the internet, other than blockchain data) of the blockchain network, also known as off-chain data.

For example, the Ethereum blockchain cannot fetch any data from the internet on its own. There are some third-party developed Oracle services; by using them, you can fetch the data from the internet to the blockchain and do your transactions.

If your application is highly dependent upon third-party data available on the internet, then you should not use blockchain. If your off-chain data requirement is small enough, then you can use Oracle services and do your transactions on the Ethereum network. For example, when you just need currency version rates from the internet, you can use Oracle services.

When you are building a decentralized application on a public Ethereum blockchain and require off-chain data, you can use Oracle services such as Oraclize or ChainLink. 

When you are building private applications using a private Ethereum blockchain and require off-chain data, you can write your own Oracle service application to read the data from off-chain. You can write your own Oracle to read some private data (such as data that's internal to the company) as well.

You can set up your own private Ethereum blockchain on your private network. This private blockchain will not be connected to a public blockchain. You can customize your private blockchain according to your needs. However, applications deployed on a private blockchain would not be treated as purely decentralized applications.

Existing implementations of blockchain

There are many industries where blockchain technology can solve some problems. Let's take some examples and existing solutions that use blockchain technology to solve some bigger issues.

Cross-border payments

Cross-border payments are processed by multiple banks and take some time to process money transfers. Using blockchain, these banks can do cross-border payment transactions fast and almost instantly. Companies such as Ripple and Stellar are solving cross-border payments along with multiple banks. For example, in the year 2018 itself, HSBC bank moved $250 billion using DLT. 

Decentralized cloud storage

You might be keeping your important files/pictures on centralized cloud storage such as Google Drive and DropBox. This centralized cloud storage is prone to attacks and these companies have full control over your files. By using decentralized data storage such as 3Box, you can store your public or private data on the blockchain.

Decentralized computing

If you have CPU resources available when you are not using your laptop or PC, then you can rent out your CPU power to a decentralized blockchain network. Someone who is in need of higher CPU usage would take your machine's CPU resources over the internet and, in return, pay you a small fee. For example, projects like Golem and iExec.

Introduction to Ethereum

Ethereum was proposed in 2013 by Vitalik Buterin, a cryptocurrency researcher and programmer. The first production release launched in 2015. Ethereum is an implementation of blockchain, and is an open source, public, and decentralized computing platform. Ethereum gained popularity because of its smart contract's features. Developers can program their smart contracts and execute them on the blockchain platform so that the full potential of the blockchain's different properties can be used.

Ethereum is for writing decentralized applications

As discussed before, Bitcoin uses blockchain technology for payments using bitcoins as a currency. Bitcoin also supports a scripting language, with which you can write small scripts. Bitcoin scripts have limited functionalities and it is difficult to write complex scripts on it. Its scripting language is also not Turing-complete (it does not support loops). Bitcoin transactions are slow; normally, it gets processed in 10 minutes or more.

With Ethereum, writing complex smart contracts and utilizing other properties of blockchain becomes easy. Any programmer who knows Java, JavaScript, and other programming languages can easily learn to code in the Solidity language. Solidity is a Turing-complete language. Transactions on Ethereum are processed much faster as compared to Bitcoin transactions. Using all of these potentials, you can write decentralized applications that would run on the Ethereum blockchain.

Ethereum architecture

Ethereum architecture consists of multiple entities that make its blockchain network. An Ethereum network has all the nodes connected to each other using the P2P network protocol; each node keeps the latest copy of the Ethereum blockchain ledger. A user can interact with the Ethereum network via the Ethereum client. The Ethereum client can be a desktop/mobile/web page:

Ethereum high-level architecture

Let's discuss these entities.

P2P networks

In a P2P network, two or more computers are connected to share their resources without going to a centralized server or machine. Nodes connected in a P2P network can share or consume network resources.

Nodes

Nodes are devices in the blockchain network, which make the mesh of the blockchain network. Nodes can perform various types of tasks, such as being an active computer, cell phone, or disk drive as long as they are connected to the internet, and they participate in a blockchain network.

A node keeps the latest copy of the blockchain data (ledger) and, in some cases, processes the transactions as well. Miners put nodes on the network and willingly share their computing power or disk space. Nodes can be of two types—full nodes or light nodes.

Full nodes

A full node in a blockchain network maintains the complete data structure of the blockchain ledger and participates in the blockchain network by verifying every block and transaction using their consensus rules. Full nodes always keep the latest copy of the ledger.

Lightweight nodes

A light node does not maintain the full copy of the blockchain ledger. It verifies the transaction using a method called Simple Payment Verification (SPV). SPV allows a node to verify whether a transaction has been included in the blockchain or not. This is verified without the need to download the entire blockchain on a machine. A light node just downloads the header information of the blocks, hence lower storage space is required in running light nodes.

Miners

Owners of the nodes willingly contribute their computing resources or hard disk space to store and validate transactions; in return, they collect block reward and transaction fees from the transactions. The nodes that perform transaction execution and verification are called miners.

Blocks

The blockchain maintains a series of blocks. Each block is linked together with the last generated block. A block contains multiple transactions. At the time of writing this book, blocks are generated using a PoW consensus algorithm called Ethash in Ethereum. In future it is planned to change to PoS.

Miners share their processing power with the Ethereum blockchain network to process all pending transactions and generate a new block. Each block is generated in approximately 15 seconds. At the time of writing, a miner who generates the block is rewarded with 3 ETH in their wallet. It is proposed that, in the future, it will be reduced from 3 ETH to 2 ETH per block. It may change in future as well.

Each block has a defined gas limit: as of now, it is 8 million gas per block. This means that the total gas consumed by the transactions included in the block cannot exceed the 8 million gas limit per block.

A block contains a block header and transactions. A block can contain at least one transaction. A new block is added to the blockchain and linked to the previous block. The very first block in the blockchain is called the genesis block:

Chain of connected blocks

The block header contains metadata about the block and the previous block. It contains multiple fields, but it's only necessary to understand a few to have an idea of block generation:

Block header and transactions root

The Parent Hash always points to the parent block of the newly generated block. This child-to-parent link goes on until the genesis block.

The Nonce is the number that is found by the miner to solve the cryptographic puzzle.

The Receipts Root is the Keccak 256-bit hash of the root node of the tree structure, which is populated with the receipts of each transaction.

The Timestamp is the time when the block is found and added to the blockchain.

The Transactions Root is the Keccak 256-bit hash of the root node of the tree structure, which is populated with each transaction.

The State Root is the Keccak 256-bit hash of the root node of the state tree, after all transactions are executed.

You should know how hash functions work and what the properties of the hash functions are. Also, you should have a basic knowledge of asymmetric cryptography.

Ethereum Virtual Machine (EVM)

EVM is the runtime environment for smart contracts. Ethereum supports multiple scripting languages for writing smart contracts. These smart contracts are then compiled and converted into EVM bytecodes. Bytecodes are then executed by EVM to perform operations on smart contracts.

Ether currency

Ethereum has its own cryptocurrency called ether (symbol: ETH). Ether is a fungible coin, which means that a coin can be subdivided into smaller units. For example, 1 ETH can be subdivided into a maximum of 18 decimal places; the smallest value is called wei. Ether is a crypto fuel for the Ethereum network.

For any transaction you perform on the Ethereum network, some gas is consumed to execute that transaction, and the gas is to be paid in ether only. This transaction fee that you pay to process your transaction goes to the miners.

Ether is publicly traded on many centralized and decentralized exchanges. Some decentralized exchanges are also built upon the Ethereum blockchain itself using Solidity smart contracts.

Smallest unit – wei

The smallest unit of ether is denoted as wei. The conversion table for ether and wei is as follows:

Unit	Wei value	Wei	Ether value	Ether
Wei	1 wei	1	10-18 ether	0.000000000000000001
Kwei (KiloWei/babbage)	103 wei	1,000	10-15 ether	0.000000000000001
Mwei (MegaWei/lovelace)	106 wei	1,000,000	10-12 ether	0.000000000001
Gwei (GigaWei/shannon)	109 wei	1,000,000,000	10-9 ether	0.000000001
microether (szabo)	1012 wei	1,000,000,000,000	10-6 ether	0.000001
milliether (finney)	1015 wei	1,000,000,000,000,000	10-3 ether	0.001
ether	1018 wei	1,000,000,000,000,000,000	1 ether	1

 

The most commonly used terms are ether, gwei, and wei. These units are used in many places in the Ethereum ecosystem, such as when creating a new transaction, or when setting the gas price for a transaction. These units can also be used in the Solidity language, hence Solidity supports wei, finney, szabo, and ether units.

Gas

Gas is the fuel of the Ethereum blockchain network. Gas is always paid in ether. Gas is the transaction fee paid to miners for executing and adding your transaction into the Ethereum blockchain.

For every transaction, you have to specify the value of the gas price and gas limit you want to set. Based on these values, the network calculates how much of a fee you are willing to pay for a transaction.

Every bytecode operation in EVM has fixed gas units assigned. When that operation is executed by EVM, fixed quantity of gas is consumed by the transaction.

Gas limit

The gas limit is the maximum unit of gas your transaction may take, in order to be executed on the Ethereum blockchain. If your transaction takes less gas, then the extra gas that you have provided will be refunded back to your wallet. If your transaction consumes all the gas and requires more gas to be executed, your transaction will fail, and gas will be consumed as part of the transaction fees.

Gas price

The gas price is the price per gas unit you are willing to pay for executing your transaction. The unit of gas price is always defined in gwei. According to your gas price, miners decide to process your transaction. If the transaction has a higher gas price, there is a chance that your transaction will be processed early. If your gas price is low, then your transaction might be processed after a delay or when the blockchain is free to process low gas price transactions.

Formulas

The following are some formulas to calculate the gas usage and transaction fee per transaction:

Example

Let's take an example of a transaction where you want to transfer 0.1 ETH to your friend. The following are the values for the transaction fields you would have to fill while creating a transaction:

Field name	Value
From	0xff899af34214b0d777bcd3c230ef637b763f0b01
To	0xc4fe5518f0168da7bbafe375cd84d30f64cda491
Value	0.1 ether
Gas limit	30,000
Gas price	0.000000021 ether (21 gwei)

 

You can also refer to Chapter 4, Learning MetaMask and Remix, where we have demonstrated how to use MetaMask to initiate transactions. 

Once the transaction is sent and confirmed on blockchain, you can see its status on block explorer (etherscan.io) as follows:

Screenshot from etherscan.io of the transaction

Let's calculate the values using these formulas: 

• TxFee_Max = 30,000 * 0.000000021 = 0.00063 ether
• TxFee_Paid = 21,000 * 0.000000021 = 0.000441 ether
• TxFee_Returned = 0.00063 - 0.000441 = 0.000189 ether
• Gas_Unused = 30,000 - 21,000 = 9,000 units of gas
• BalanceRequiredAtTransactionInitiation = 0.1 + 0.00063 = 0.10063 ether

Let's go through the preceding calculations. When you initiate the preceding ether transfer transaction, it must have a balance of 0.10063 ether. If the balance in your wallet is lower than 0.10063 ether, then you will not be allowed to initiate transactions and this will be rejected by the client itself as it's an invalid transaction.

If you have sufficient balance and the transaction is initiated, then, along with your transaction, the BalanceRequiredAtTransactionInitiation amount will be locked. So, in this example, 0.10063 ether is locked.

Now, your transaction is processed, 21,000 gas has been consumed in order to execute the transaction on the EVM, and the transaction executed successfully. As it consumed only 21,000 gas, it refunds 9,000 units of gas. This means 0.000189 ether will be refunded back to your wallet and you have paid 0.000441 ether for your transaction processing.

You can remember this Gas_Limit and Gas_Price with a car and fuel example. Let's say you want to go from city A to city B and the distance between these two cities is 500 km. Your car fuel average is 20 km/liter (Gas_Required). There is no fuel station on the way when you travel, so you would have to get it filled before you start. You need 500/20 = 25 liters (TxFee_Required) of fuel to reach city B. If you filled your car fuel tank with 30 liters (TxFee_Max), then you would successfully reach city B and you will still have 5 liters (Gas_Unused) left with you that you can use later on. However, if you had filled it with 20 liters when you started the journey, then you would have stopped at 400 km and you couldn't have done anything. This would be called a failed transaction and your gas/fuel is consumed so there's no gas refund.

An ether transfer requires a fixed 21,000 gas limit per transaction. If you also include data along with the ether value, it may require a greater gas limit to execute the transaction.

Ethereum accounts

On the Ethereum platform, you can have two types of accounts:

• Externally Owned Accounts (EOA)
• Contract accounts

Both of these accounts can hold balances of ETH; however, there are some differences between these accounts, which we will cover in the following sections. Both account addresses are in hexadecimal, which starts with the 0x prefix. The Ethereum public address of an EOA and a contract is always a 20 bytes (160 bits) address represented in hexadecimal form:

Ethereum account/contract public address format

You need these accounts to perform transactions on the Ethereum network.

Externally owned accounts

An Ethereum wallet can hold one or more EOA. Wallets can be created by anyone via wallet creation websites, browser plugins such as MetaMask, or mobile apps. These wallet creation services generate a new private key using a specific account creation algorithm. Using this private key, the public key is derived. The combination of a private key and a public key is called an account or EOA. A public key can be shared with anyone to receive ETH/ERC20 tokens. However, the private key must be kept secret by the user. For the creation of wallets using MetaMask, you can refer to Chapter 4, Learning MetaMask and Remix.

An EOA is controlled by its private key to initiate any transaction with it. An EOA owner can send ETH/ERC20 tokens to other EOA or contract addresses. They can also initiate a transaction on a deployed contract with EOA:

User interacting with Ethereum network using the EOA present in their wallet

As shown in the preceding diagram, the user can interact with the Ethereum network via one of the EOA accounts present in his wallet. A user holds a wallet that can have one or more EOA accounts. Each EOA account has a private key, which the user must use so they can sign the transaction data and send it to the Ethereum network to be executed. The user can also check their account balance from the Ethereum network using their public key.

New wallets are created off-chain using wallet generation algorithms used by MetaMask or other available websites. They are not created on-chain; however, smart contracts and their addresses are created on-chain when a contract is deployed on the blockchain.

Contract accounts

This type of account is also known as a contract. Contracts only have a public address, and their code logic controls the flow of the funds and other states of the contract. Contracts do not have any private keys associated. You need an EOA account to create a new contract or to interact with an existing contract. Contract accounts have a Solidity code that defines their behavior.

Any Solidity code you deploy creates new contract accounts or contracts:

A user accessing a contract account via their EOA account

As shown in the preceding diagram, the user has their own EOA account. Using this EOA account, the user can interact with any deployed contract accounts (smart contracts) present on the Ethereum blockchain. The user can interact by initiating transactions. Also, with an EOA account, the user can deploy a new contract.

Contract accounts can only be created on-chain and their contract bytecode is included in the block when they are deployed successfully. Contract accounts are not created off-chain, just like EOA accounts.

The difference between an EOA and a contract

There are some differences between an EOA and a contract account. The following table distinguishes between an EOA and a contract:

	EOA (account)	Contract account (smart contract)
Creation	A new account can be created at any time, using a wallet generation utility such as MetaMask or with https://www.myetherwallet.com/.	A new contract can only be created from an EOA or from an existing deployed contract.
Public address	An EOA account's public address is derived from its private key.	A contract's public address is created by the combination of a public address of creating account + nonce.
Private keys	An EOA can only be controlled using its private key.	A contract which do not has a private key can be controlled using other EOA or contract. They respond to transactions initiated from an EOA.
Control	Whoever owns a private key can control the funds of an EOA.	Control is defined by the code stored with it. An EOA or another contract may have control over a deployed contract.
Code	An EOA does not have any associated Solidity code.	A contract always has Solidity code associated with it, which is stored together with it.
Access	Using the private key of an EOA, we can make transactions via different wallet software such as MetaMask and Ethereum wallet.	Using Abstract Binary Interfaces (ABIs) of a contract, an EOA can access the functions of the contract via Remix, Truffle, and others tools.
Transaction initiation	Using the private key, one can directly access the funds of EOA and initiate any transactions. So, direct access to funds is allowed.	A contract cannot initiate a transaction on its own. An EOA need to initiate the transaction first, then only contracts can initiate other transactions.

 

As we have discussed the basic differences between an EOA and a contract, let's discuss Ethereum transactions.

Ethereum transaction

A transaction on an Ethereum blockchain is required to transfer ETH from EOA or for smart contracts to change state, perform an action, or read a state of a contract. A transaction can only be initiated from an EOA and it can further initiate other internal transactions.

For example, an EOA wallet initiates a transaction to call a function of contract A, and this contract calls another function of contract B. In this case, a transaction is initiated from an EOA to contract A and then an internal transaction is initiated from contract A to contract B.

Transaction fields

A user first fills the required fields for creating a new transaction. Then, they sign the transaction with their EOA's private key. This signed transaction data is then broadcast to the Ethereum blockchain network via any Ethereum client. The Ethereum client also first verifies that the transaction is valid and signed using the EOA's private key only, the address of which is in the from field.

From

From is always the public address of the EOA that initiated the transaction. In Ethereum, only an EOA account can initiate a transaction. Contract accounts cannot initiate a transaction on their own. The transactions further initiated by contracts are called internal transactions (on etherscan.io) in general terms; however, as per the Ethereum's yellow paper, these transactions are called message calls.

To

To is always the public address of an EOA or a contract. When To is an EOA address, then this transaction is initiated to send some ETH. When To is a contract address, then this transaction is initiated to call a method of a contract or to send ETH to contract..

Value

A transaction can have either zero or nonzero for the value field. Normally, the value field is nonzero when sending ETH to an EOA. However, when initiating a transaction to a contract, the value field either has a zero or nonzero value based on the contract function.

Gas limit

The gas limit is the maximum limit of gas units that will be required by the EVM to execute the transaction. We discussed this in detail earlier in this chapter.

Gas price

The gas price is the cost per gas unit you are willing to pay. We discussed this in detail earlier in this chapter.

Nonce

The nonce field in a transaction always starts with 0 (zero) for an EOA that initiates the transaction. The nonce keeps increasing by one for every transaction an EOA initiates. The nonce also specifies the execution order of the transactions initiated from an EOA. When multiple transactions initiated from an EOA are in the pending state, then the EVM executes a transaction that has a lower nonce value for that EOA.

Data

Data represents the hexadecimal data that you want to transfer along with a transaction. This data field is required to call a method of a contract.

When transferring ETH from one EOA to another EOA, the data field is empty, which means the value of the data field will be 0x. However, when we want to execute a method of a contract, the data field will hold the hexadecimal value of the method and its arguments:

Transaction data in hexadecimal from etherscan.io

The preceding hexadecimal transaction data, once decoded, represents the transfer() method call (called on an ERC20 contract) with the _to and _value parameters passed in. As you can see, 0xa9059cbb (four bytes data) is the hex code for the transfer() method, and the following method parameters are passed in:

Hexadecimal transaction data decoded on etherscan.io

Once the previous transaction data is decoded on the etherscan.io website, it shows the first four bytes of the function signature and the parameters passed to the function. 

Transaction hash

A user doesn't have to set the transaction hash field. A transaction hash is assigned to every transaction when it contains valid transaction fields and is broadcast to the Ethereum blockchain. The transaction ID is the SHA-256 hash of the signed transaction data. Using this transaction ID, we can track the status of the transaction and can cancel or drop the transaction before it gets executed.

Transaction status

The transaction status lets the user know the status of a transaction. Transaction change or dropping a transaction is allowed in different states. A transaction can be in any of the following three statuses:

Transaction status diagram

As shown in the preceding diagram, transactions are always initiated by an EOA. Let's go through each of the statuses.

Pending status

When a transaction is submitted to the Ethereum network, it first goes into the pending status, waiting to be executed by the nodes. A transaction can be in the pending state for a longer duration if the gas price is set very low in the transaction and the nodes are busy processing other higher gas price transactions.

During the pending state, the transaction initiator is allowed to change the transaction fields at any time. They can do so by sending another transaction with the same nonce. 

Success status

A transaction that is executed successfully without any failure is called a successful transaction. A successful transaction means the intended operation is executed successfully by the Ethereum blockchain and verified by other nodes present in the Ethereum blockchain network:

A successful transaction on etherscan.io

Fail status

A transaction is executed and, during the execution, it may fail due to an error in the contract method execution. Transaction failure also depends on the contract definition. Transaction execution failure could also occur in case of a low gas limit, and transactions will fail with the OutOfGasException error:

Failed transaction on etherscan.io

Dropped status

A transaction is sometimes dropped from the Ethereum network for several reasons:

• If the transaction was in the pending state for a very long duration
• It has a very low gas price as compared to other pending transactions
• The maximum number of pending transactions the Ethereum blockchain can handle are in the pending transaction pool

Once a transaction is dropped, all  the gas and ETH is returned to the originating wallet:

Transaction dropped on etherscan.io

The dropped transaction is not included in any block on the blockchain, as if it didn't happen or wasn't initiated. There is no trace of those transactions on the blockchain; you can only see these dropped transactions on etherscan.io (block explorer) for some time. Later, they may be removed from etherscan.io as they are not part of the blockchain. However, successful and failed transactions are included in the block of the Ethereum blockchain and their status can be checked from any blockchain client.

Transaction operations

Two types of operations are allowed on an already initiated transaction. To do either of these operations, a transaction must be in the pending status.

Replace/update

If a user wants to change some transaction fields they have initiated, they can do so by changing the values and keeping the same nonce in the new transaction. A replace transaction is mostly used when a transaction is in the pending status for a longer duration because of the low gas price, and just increasing the gas price of the same transaction could increase the likelihood of it getting executed by the Ethereum network.

Cancel

A transaction can be canceled by the same EOA that initiated the same transaction. If a user feels that they have initiated a wrong transaction accidentally, they can cancel that transaction by initiating another transaction having the same nonce and changing the To fields to their own EOA address. This new transaction must have a higher gas price. A higher gas price is set to ensure that the new transaction will be given priority over the older transaction and can cancel the transaction as soon as possible. This type of transaction is called a self transaction. 

Testnets

There are multiple testnets available where you can deploy and test your contract's functionality. These testnets are the replica of the mainnet (production) Ethereum blockchain, so these testnets also behave the same. If your contracts are working on testnets, then they will work perfectly on the mainnet as well.

However, to deploy and test your contracts on these testnets, you need to have some testnet ethers for that testnet. You can get those testnet ethers from a faucet for free from the following locations:

Testnet	Faucet link	Block explorer
Kovan	https://faucet.kovan.network/	https://kovan.etherscan.io/
Rinkeby	https://faucet.rinkeby.io/	https://rinkeby.etherscan.io/
Ropsten	https://faucet.metamask.io/	https://ropsten.etherscan.io/

 

If you want to test your contracts locally, then you can either install and set up your private testnet or you can use the Ganache tool.

Smart contracts

Nick Szabo coined the term smart contract in 1994. Smart contracts are self-executing contracts. They eliminate intermediaries and allow direct P2P transactions. A smart contract has the power to automatically enforce some obligations. One of the best examples of this is a vending machine: when you need an item from a vending machine, you pay into it and it gives you that item without needing any middleman.

Smart contracts are very different from traditional software programs. Smart contract code is immutable once deployed on the blockchain. Because of this immutable property, we have to think twice before deploying it; otherwise, it could end up with critical flaws in production. A different mindset is required for writing smart contracts. Some smart contracts present in decentralized applications handle the flow of ETH or other ERC20 tokens, which have real monetary value. If something goes wrong in the production, any attacker can steal ETH or ERC20 tokens from your smart contracts.

Immutable code

Once you deploy your smart contract on Ethereum blockchain, either on the testnet or the mainnet, you cannot modify the code of the smart contract files that you have deployed. All code that is deployed becomes immutable. Not even an attacker/hacker can change the deployed code.

If your code is deployed on the testnet for testing purposes, then you can fix any issues in your smart contract files present on your local machine, and redeploy your code on the testnet again to check whether the functionality is working or not. But if you have deployed your contract on the mainnet (production) and other people, entities, or contracts started using that contract code, then you cannot change that contract code. If those entities are still not using that freshly deployed code, then you still have a chance to fix any issues/errors and redeploy. There is another way to create an upgradable contract in Solidity; for more details, you can refer to Chapter 11, Upgradable Contracts Using ZeppelinOS.

You cannot change the code of smart contracts, but you can change the different states/variables of the smart contracts—those are handled with smart contract code. Based on the different states/variables, your smart contract code behavior changes.

Irreversible transactions

Once the smart contracts are deployed on Ethereum network, their code becomes immutable. No one can change the code of the deployed smart contract. It's the same as when some transaction on the Ethereum network is done, and there is no way to reverse that transaction. For example, if person A sends 1 ETH to person B and the transaction is successfully executed, then there is no way for person A to reverse that transaction and to get that 1 ETH sent back to their wallet. 

For smart contracts as well, if you have done a particular transaction on a smart contract that has changed the state of the contract, then there is no way to reverse that transaction. There might be some other functions available in the smart contract to get the same state again, but, in terms of transactions, it is not possible to reverse the transaction that was executed.

Think twice before deploying

I am serious—think twice before deploying smart contracts on production!

Before deploying smart contracts on the mainnet (production), you must ensure that all of the unit tests and other test cases that you have for the smart contract are passing. Your code is reviewed by some other developer to ensure that the logic of the contract is correct and is going to behave as per your expectations in production. Ensure that the code coverage reports are reviewed, and the maximum possible coverage of the code is ensured.

You might be wondering why I am mentioning these normal things—as a developer, you would think that these are the processes we follow on a daily basis during software development, so what's new and special about this? 

To date, as a software developer, you have been writing software/applications and following best practices to ensure that no errors/bugs are in the system. But, at the back of your mind, you also think that if something goes wrong with the script/code, we can apply a patch and re-deploy the software/application again, with no issues. Since the beginning of software development, this has been the practice. 

Now, as a software developer, you need to understand that smart contracts are not like your existing software/applications, where you can apply a patch and change the code at any time. As smart contract code becomes immutable once deployed, only states/variables can be changed via allowed methods that are present in smart contracts. As a developer, you need to mentally prepare yourself for the fact that the smart contracts you are writing cannot ever be changed once deployed on the Ethereum blockchain. If you have experience of writing device drivers for hardware, then you can understand this easily as device drivers have limited changeability/upgradability.

If you are planning to upgrade smart contracts in the future, then you need to be prepared for it when deploying the first version of the contracts. For example, you should be able to stop an existing version of a smart contract and move on to the new upgraded version. You also need to think about how existing users will migrate to a new upgraded version of contracts.

There are some design patterns available to provide upgradability to smart contracts. We will cover those in Chapter 11, Upgradable Contracts Using ZeppelinOS.

The preceding summary is not intended to threaten you about how smart contracts could go wrong, but to inform you about the consequences it could cause if the code is not well tested and reviewed with multiple iterations.

Limited storage

When your smart contract stores some variables/states, it has to be stored on the blockchain's ledger. The storage space of smart contracts is limited and costly. As the gas limit per block is limited, so is the execution of a transaction. The Ethereum blockchain should not be used as data storage or a replacement database. The blockchain is a kind of decentralized database; however, at the moment, the Ethereum blockchain cannot handle the processing of loads of data in a transaction. Blockchain technology is still evolving; in the future, it might be possible to even store large amounts of data and processes in a single transaction.

If you want to store big files or data on decentralized blockchains, you should look for Swarm, IPFS, StorJ, or Filecoin, according to your needs. 

Every transaction consumes gas in ether

The gas consumption that we are going to talk about is with respect to the Ethereum blockchain. We are not going to talk about how other types of blockchain treat their smart contract executions.

On the Ethereum blockchain, every transaction that sends ether consumes gas; in the same way, to execute a smart contract's logic, the transaction initiator has to pay gas in ether. As a developer, you must ensure that the logic of your smart contract is not complex and consumes optimal gas. You might need to re-design your logic to ensure that gas consumption is not very high.

Playing with ether or tokens

As we saw previously, the main currency of the public Ethereum blockchain is ETH. There are some other currencies also present on the Ethereum blockchain itself; these follow ERC20 standards and are called tokens. ETH and some of the ERC20 tokens are being traded on some cryptocurrency exchanges.

You can write some smart contracts that involve ETH and ERC20 tokens in your contracts; for example, if you are writing a decentralized exchange on the Ethereum blockchain. To name a few, some existing decentralized exchanges include EtherDelta, IDEX, and KyberNetwork.

When using ETH/ERC20 tokens in your smart contract, you need to ensure the safety of funds. The following are some examples that have led to multimillion dollar hacking of smart contracts on the Ethereum blockchain itself. One of the famous attacks was the DAO Smart Contract hack, in which attackers were able to spawn new child contracts and were able to steal ETH from the main contract. Another famous attack was the Parity multi-signature wallet hack, in which attackers were able to steal ETH from all of the contracts that were using the Solidity code of the Parity multisignature wallet. To prevent this attack, white hat hackers have to hack all other existing Parity multi-signature wallets, as there was no other solution and no way to change the contract code.

Not all smart contracts deal with ETH/ERC20 tokens, but if they are dealing with ETH/ERC20 tokens, then extra care must be taken before deployment.

Summary

Blockchain has some unique properties that make it powerful. It uses all the benefits of decentralized systems. Blockchains can replace the TTP (the middleman) and provide the required trust. The irreversibility of transactions makes blockchain secure and attack-proof.

Ethereum is one of the implementations of blockchain. Bitcoin blockchain has its scripting language, but it is not Turing-complete. Ethereum supports the Turing-complete Solidity language, which we can use to write smart contracts. At the moment, Ethereum transaction processing is slow. In the future, it is going to have some upgrades, which could improve the transaction processing speed of the overall Ethereum blockchain network.

Blockchain makes smart contracts immutable, which opens up a new way of programming in the new paradigm. Smart contracts can cause problems if deployed on production without due diligence and testing.

In the next chapter, we will learn about the most popular smart contract language, Solidity. We will go through contract structures, data types, global variables, and more.

Questions

1. Why do we need blockchain?
2. Can blockchain replace existing database technologies?
3. Can we use blockchain to solve every problem that can we do with coding?
4. Why do we need to remove intermediaries?
5. What are the limitations of Ethereum?
6. Why are the gas limit and gas price required in a transaction?
7. What are the benefits of having immutable code and irreversible transactions?
8. Why are smart contracts different from traditional programs?
9. Why is the testing of smart contracts a must?