To execute the instructions given in this chapter, you can use a machine with any operating system (Mac, Windows, or Linux) with a browser installed on it. Code for this chapter can be found on GitHub at https://github.com/PacktPublishing/Solidity-Programming-Essentials-Second-Edition/tree/main/Chapter01.

A blockchain is essentially a decentralized, distributed database or ledger, as follows:

• Decentralization: In simple terms, this means that the application or service continues to be available and usable even if a server or a group of servers on a network crashes or is not available. The service or application is deployed on a network in a way that no server has absolute control over data and execution; rather, each server has a current copy of data and execution logic.
• Distributed: This means that any server or node on a network is connected to every other node on the network. Rather than having one-to-one or one-to-many connectivity between servers, servers have many-to-many connections with other servers.
• Database: This refers to the location for storing durable data that can be accessed at any point in time. A database allows the storage and retrieval of data as functionality and also provides management functionalities to manage data efficiently, such as exporting, importing, backup, and restoration.
• Ledger: This is an accounting term. Think of it as specialized storage and retrieval of data. Think of ledgers that are available to banks – for example, when a transaction is executed with a bank. Let's say that Tom deposits USD 100 in his account; the bank enters this information in a ledger as credit. At some point in the future, Tom withdraws USD 25. The bank does not modify the existing entry and stored data from 100 to 75. Instead, it adds another entry in the same ledger as a debit of USD 25. This is because a ledger is a specialized database that does not allow modification of existing data. It allows you to create and append a new transaction to modify the current balance in the ledger. The blockchain is a database that has the same characteristics as a ledger. It allows newer transactions to be stored in an append-only pattern without any scope to modify past transactions. It is important here to understand that existing data can be modified by using a new transaction, but past transactions cannot be modified. A balance of USD 100 can be modified at any time by executing a new debit or credit transaction, but previous transactions cannot be modified. Take a look at the following diagram for a better understanding:

Figure 1.1 – A blockchain is essentially a chain of blocks

Blockchain means a chain of blocks – that is, having multiple blocks chained together, with each block storing transactions in such a way that it is not possible to change these transactions. We will discuss this in later sections when we talk about the storage of transactions and how immutability is achieved in a blockchain.

Because they are decentralized and distributed, blockchain solutions are stable, robust, durable, and highly available. There is no single point of failure. No single node or server is the owner of the data and solution, and everyone participates as a stakeholder.

Not being able to change and modify past transactions makes blockchain solutions highly trustworthy, transparent, and incorruptible.

The main objective of blockchain is to accept transactions from accounts, update the current state, and maintain this state till another transaction updates it again. This entire process can be divided into two phases in blockchain. There is a decoupling in between when a transaction is accepted by Ethereum and when the transaction is executed and written to the ledger. This decoupling is quite important for decentralization and distributed architecture to work as expected.

Blockchain helps primarily in the following three different ways:

• Trust: Blockchain helps in creating applications that are decentralized and collectively owned by multiple people. Nobody within this group has the power to change or delete previous transactions. Even if someone tries to do so, it will not be accepted by other stakeholders.
• Autonomy: There is no single owner for blockchain-based applications. No one controls the blockchain, but everyone participates in its activities. This helps in creating solutions that cannot be manipulated or corrupted.
• Intermediaries: Blockchain-based applications can help remove intermediaries from existing processes. Generally, there is a central body, such as vehicle registration and license issuing, that acts as a registrar for registering vehicles as well as issuing driver licenses. Without blockchain-based systems, there is no central body, and if a license is issued or a vehicle is registered after a blockchain mining process, that will remain a fact for an epoch (an epoch is a period of time – say, 5 seconds) without the need of any central authority vouching for it.

Blockchain is heavily dependent on cryptography technologies, as we will discuss in the following section.

Cryptography is the science of converting plain, simple text into secret, hidden, and meaningful text, and vice versa. It also helps in transmitting and storing data that cannot be easily deciphered using owned keys.

There are two types of cryptography in computing:

• Symmetric cryptography: This refers to the process of using a single key for both encryption and decryption. It means the same key should be available for multiple people if they want to exchange messages using this form of cryptography.
• Asymmetric cryptography: This refers to the process of using two keys for encryption and decryption. Any key can be used to encrypt and decrypt. Messages encrypted with a public key can be decrypted using a private key, and messages encrypted by a private key can be decrypted using a public key. Let's understand this with the help of an example. Tom uses Alice's public key to encrypt messages and sends it to Alice. Alice can use her private key to decrypt the message and extract its content. Messages encrypted with Alice's public key can only be decrypted by Alice, as only she holds her private key and no one else. This is the general use case of asymmetric keys. There is another use that we will see in the Digital signatures section.

Hashing

Hashing is the process of transforming any input data into fixed-length random character data, and it is not possible to regenerate or identify the original data from the resultant hash. Hashes are also known as fingerprints of input data. It is next to impossible to derive input data based on its hash value. Hashing ensures that even a slight change in input data will completely change the output data, and no one can ascertain the change in the original data.

Another important property of hashing is that no matter the size of input string data, the length of its output is always fixed. For example, using the SHA-256 hashing algorithm and function with any length of input will always generate 256-bit output data. This can especially become useful when large amounts of data can be stored as 256-bit output data. Ethereum uses the hashing technique quite extensively. It hashes every transaction, hashes the hash of two transactions at a time, and ultimately generates a single root transaction hash for every transaction within a block.

Another important property of hashing is that it is not mathematically feasible to identify two different input strings that will output the same hash. Similarly, it is not possible to find the input computationally and mathematically from the hash itself.

Ethereum uses Keccak256 as its hashing algorithm. The following screenshot shows an example of hashing. The Ritesh Modi input generates a hash, as shown in the following screenshot:

Figure 1.2 – A hashing example using the SHA-256 algorithm

Even a small modification of input generates a completely different hash, as shown in the following screenshot:

Figure 1.3 – A completely different hash output based on a small change in the original input

Digital signatures

Earlier, we discussed cryptography using asymmetric keys. One of the important uses for asymmetric keys is in the creation and verification of a digital signature. Digital signatures are very similar to a signature done by an individual on a piece of paper. Similar to a paper signature, a digital signature helps in identifying an individual. It also helps in ensuring that messages are not tampered with while in transit. Let's understand digital signatures with the help of an example.

Alice wants to send a message to Tom. How can Tom identify and ensure that the message has come from Alice only and that the message has not been changed or tampered with in transit? Instead of sending a raw message/transaction, Alice creates a hash of the entire payload and encrypts the hash with her private key. She appends the resultant digital signature to the hash and transmits it to Tom. When the transaction reaches Tom, he extracts the digital signature and decrypts it using Alice's public key to find the original hash. He also extracts the original hash from the rest of the message and compares both the hashes. If the hashes match, it means that it actually originated from Alice and that it has not been tampered with.

Digital signatures are used to sign transaction data by the owner of the asset or cryptocurrency, such as Ether. With a basic understanding of cryptography, it's time to introduce Ethereum and blockchain at a high level.

Reviewing blockchain and Ethereum architecture

Blockchain is an architecture comprising multiple components, and what makes blockchain unique is the way these components function and interact with each other. Ethereum allows you to extend its functionality with the help of smart contracts. (Smart contracts will be addressed in detail throughout this book.)

Some of the important Ethereum components are the Ethereum Virtual Machine (EVM), miner, block, transaction, consensus algorithm, account, smart contract, mining, Ether, and gas. We are going to discuss each of these components in this chapter.

A blockchain network consists of multiple nodes belonging to miners and some nodes that do not mine but help in the execution of smart contracts and transactions. These are known as EVMs. Each node is connected to another node on the network. These nodes use a peer-to-peer protocol to talk to each other. They, by default, use port 30303 to talk among themselves.

Each miner maintains an instance of a ledger. A ledger contains all blocks in the chain. With multiple miners, it is quite possible that each miner's ledger instance might have different blocks to another. The miners synchronize their blocks on an ongoing basis to ensure that every miner's ledger instance is the same as the other. Details about ledgers, blocks, and transactions are discussed in detail in subsequent sections in this chapter.

The EVM executes smart contracts and helps bring about changes to the global state. Smart contracts help in extending Ethereum by writing custom business functionality into it. These smart contracts can be executed as part of a transaction, and it follows the process of mining as discussed earlier.

A person with an account on a network can send a message for the transfer of Ether from their account to another or can send a message to invoke a function within a contract. Ethereum does not distinguish them as far as transactions are considered. The transaction must be digitally signed with an account holder's private key. This is to ensure that the identity of the sender can be established while verifying the transaction and changing the balances of multiple accounts. Let's take a look at the components of Ethereum in the following diagram:

Figure 1.4 – The relationship between blockchain and mining

The previous diagram illustrates some of the important components in Ethereum. The externally owned accounts are responsible for initiating transactions on Ethereum. The transactions that are executed within the Ethereum nodes are finally written as blocks on the blockchain. These blocks have header sections that help in chaining the blocks.

Relationship between blocks

In blockchain and Ethereum, every block is related to another block. There is a parent-child relationship between two blocks. There can be only one child to a parent and a child can have a single parent. This helps in forming a chain in blockchain, as shown. Blocks will be explained in a later section in this chapter:

Figure 1.5 – The relationship between blocks using a block hash

In this diagram, we can see three blocks apart from the Genesis Block – Block 1, Block 2, and Block 3. Block 1 is the parent of Block 2, and Block 2 is the parent of Block 3. The relationship is established by storing the parent block's hash in a child's block header. Block 2 stores the hash of Block 1 in its header and Block 3 stores the hash of Block 2 in its header. So, the question arises – who is the parent of the first block? Ethereum has a concept of the genesis block, also known as the first block. This block is created automatically when the chain is first initiated. You can say that a chain is initiated with the first block, the genesis block, and the formation of this block is driven through the genesis.json file.

The next chapter will show you how to use the genesis.json file to create the first block while initializing the blockchain.

How transactions and blocks are related to each other

Now that we know that blocks are related to each other, you will be interested in knowing how transactions are related to blocks. Ethereum stores transactions within blocks. Each block has an upper gas limit, and each transaction needs a certain amount of gas to be consumed as part of its execution. The cumulative gas from all transactions that are not yet written in a ledger cannot surpass the block gas limit. This ensures that all transactions do not get stored within a single block. As soon as the gas limit is reached, other transactions are removed from the block and mining begins thereafter. The gas concept will be covered in a subsequent section in this chapter. This section should be revisited after reading about gas.

The transactions are hashed and stored in the block. The hashes of two transactions are taken and hashed further to generate another hash. This process eventually provides a single hash from all transactions stored within the block. This hash is known as the transaction Merkle root hash and is stored in a block's header.

A change in any transaction will result in a change in its hash and, eventually, a change in the root transaction hash. It will have a cumulative effect because the hash of the block will change, and the child block has to change its hash because it stores its parent hash. This helps in making transactions immutable. This is also shown in the following diagram:

Figure 1.6 – The Merkle root representing all transaction hashes

Blocks and transactions are core to blockchain, but the question remains about the process of adding them to the chain. A generated block should be agreed upon and acceptable to all the nodes within a network. The process of coming to an agreement on a block and subsequently either adding it to the chain or rejecting it is based on the process known as consensus.

Consensus is one of the most important concepts in the world of blockchain. As we know, a blockchain comprises multiple nodes that are running the same software and storing the same data. There should be some agreement between the nodes to accept a given state as a known agreeable state. With thousands of nodes running together, intertwined using a Peer-to-Peer (P2P) network, they should agree on what is stored historically on the blocks and what should be included as transactions on the new block. It is quite possible that a node goes rogue and adds transactions that are not valid. The consensus mechanism or agreements among nodes would ensure that those transactions are not accepted by other ones. A rogue actor has to minimally control a majority of the nodes to make everyone agree on the dubious transactions.

There are various ways to implement and achieve consensus among nodes. Bitcoin is implemented using the Proof-of-Work (PoW) consensus algorithm. Ethereum also implements the PoW consensus algorithm as part of Ethereum 1.0. The new upcoming Ethereum 2.0 is changing its consensus algorithm to the Proof-of-Stake (PoS) consensus algorithm.

One of the main drawbacks of the PoW consensus algorithm is that is it quite costly to generate and agree on blocks due to its mining process, which will be explained later. Mining involves heavy usage of electricity and that has negative consequences toward environmental hazards and cost. Both PoW and PoS will be explained in the next subsections.

Proof of work

A miner is responsible for writing transactions to the Ethereum chain. A miner's job is very similar to that of an accountant. An accountant is responsible for writing and maintaining a ledger; similarly, a miner is solely responsible for writing a transaction to an Ethereum ledger. A miner is interested in writing transactions to a ledger because of the reward associated with it. Miners get two types of reward – a reward for writing a block to the chain and cumulative gas fees from all transactions in the block. There are generally many miners available within a blockchain network, each trying and competing to write transactions. However, only one miner can write the block to the ledger, and the rest will not be able to write the current block.

The miner responsible for writing the block is determined by way of a puzzle. The challenge is given to every miner, and they try to solve the puzzle using their computing power. The miner who solves the puzzle first writes the block containing transactions to their own ledger and sends the block and nonce value to other miners for verification. Once verified and accepted, the new block is written to all ledgers belonging to miners. In this process, the winning miner also receives Ether as a reward. Every mining node maintains its own instance of the Ethereum ledger, and the ledger is ultimately the same across all miners. It is the miner's job to ensure that their ledger is updated with the latest blocks. The following are the three important functions performed by miners or mining nodes:

• Mine or create a new block with a transaction and write this to the Ethereum ledger.
• Advertise and send a newly mined block to other miners.
• Accept new blocks mined by other miners and keep their own ledger instance up to date.

Mining nodes refer to nodes that belong to miners. These nodes are part of the same network where the EVM is hosted. At some point in time, miners will create a new block, collect all transactions from the transaction pool, and add them to the newly created block. Finally, this block is added to the chain. There are additional concepts such as consensus and the solving of a target puzzle before writing the block, which will be explained in the following section.

Miners are always looking forward to mining new blocks and are also listening actively to receive new blocks from other miners. They are listening for new transactions stored in the transaction pool. Miners also broadcast the new transactions to other connected nodes after validation. A miner collects all transactions available within the transaction pool, subject to constraints such as block size and block gas limits, and creates a block with them. This activity is done by all miners.

The miner constructs a new block and adds all transactions to it. Before adding these transactions, it will check whether any of the transactions are not already written in a block that it might receive from other miners. If so, it will discard those transactions.

The miner will add its own coinbase transaction for getting rewards for mining the block.

The next task for a miner is to generate the block header and perform the following tasks:

1. The miner takes hashes of two transactions at a time to generate a new hash till they get a single hash from all transactions. The hash is referred to as a root transaction hash or Merkle root transaction hash. This hash is added to the block header.
2. The miner also identifies the hash of the previous block. The previous block will become a parent to the current block, and its hash will also be added to the block header.
3. The miner calculates the state and receipts of the transaction root hashes and adds them to the block header.
4. A nonce and timestamp are also added to the block header.
5. A block hash consisting of both a block header and body is generated.
6. The mining process starts where the miner keeps changing the nonce value and tries to find a hash that will satisfy as an answer to the given puzzle. Keep in mind that everything mentioned here is executed by every miner in the network.
7. Eventually, one of the miners will be able to solve the puzzle and advertise the result to other miners in the network. The other miners will verify the answer and, if found correct, further verify every transaction, accept the block, and append it to their ledger instance.

This entire process is also known as PoW wherein a miner provides proof that they have worked on computing the final answer that is satisfactory as a solution to the puzzle. The header block and its content are shown in the following diagram:

Figure 1.7 – PoW generating a Merkle root and using transactions

Let's now discuss the next mechanism.

Proof of stake

Ethereum 2.0 will launch a new consensus mechanism known as PoS. It is another algorithm to reach consensus within a distributed network architecture. While PoW is computationally heavy, PoS does not perform any compute-heavy activities. Under this mechanism, interested stakeholders can stake their Ether (a minimum of 32 ETH) with the network. Once the Ethers are staked, they are locked, and these stakeholders become validators. These validators have their nodes running, and their job is to attest to new blocks for their validity. Attestation here means that the validator is vouching for the correctness of the block and its constituent transactions.

After a minimum number of validators attest, the block is finalized and becomes a permanent part of the chain. The network will at random also choose a validator to create a new block for every epoch. The validators are not competing with each other anymore as in the case of the PoW consensus mechanism. This makes PoS more environmentally friendly by being energy efficient and also anyone with 32 Ethers can potentially become a validator. Now that we understand the different consensus mechanisms, it's time to visit the different types of nodes supported by Ethereum.

Nodes represent the computers that are connected using a P2P protocol to form an Ethereum network. There are the following three types of nodes in Ethereum:

• The EVM
• Mining nodes (Ethereum 1.0)
• Validators (Ethereum 2.0)

Please note that this distinction is made to clarify concepts of Ethereum. In most scenarios, there is no dedicated EVM. Instead, all nodes act as miners as well as EVM nodes.

EVM

Think of an EVM as the execution runtime for smart contracts. EVMs are primarily responsible for providing a runtime that can execute code written in smart contracts. It can access accounts, both contract and externally owned, and its own storage data. It does not have access to the overall ledger but does have limited information about the current transaction.

EVMs are the execution components in Ethereum. The purpose of an EVM is to execute code in a smart contract line by line. However, when a transaction is submitted, the transaction is not executed immediately. Instead, it is added to a transaction pool. These transactions are not yet written to the Ethereum ledger.

Mining nodes

The mining nodes are responsible for generating, validating, and adding blocks to the chain. Mining nodes can be a full node, a light node, or an archive node. A full node has all the blocks (headers and transactions) since the genesis block and complete global state and can participate in generating and validating the blocks. Light nodes have blocks with headers only and are dependent on connected full nodes for any information they need. They require more bandwidth because of their chatty nature with full nodes but need less computing and storage. They are also faster while synchronizing blocks from full nodes. Archival nodes are again full nodes, but their usage is more for querying a node for historical information and reporting.

Ethereum validators

Validator nodes are again nodes responsible for generating new blocks for the chain. They do not run any mining process, and they collect all available transactions from the transaction pool and create a block. They broadcast the blocks to other validators for attestation. As part of the attestation process, validators execute each transaction and modify their state while adding a block to their chain.

Accounts are the main building blocks for the Ethereum ecosystem. It is an interaction between accounts that Ethereum wants to store as transactions in its ledger. There are two types of accounts available in Ethereum – externally owned accounts and contract accounts. Each account, by default, has a property named balance that helps in querying the current balance of Ether.

Externally owned accounts

Externally owned accounts are accounts that are owned by people on Ethereum. Accounts are not referred to by name in Ethereum. When an externally owned account is created on Ethereum by an individual, a public/private key is generated. The private key is kept safe with the individual while the public key becomes the identity of this externally owned account. This public key is generally of 256 characters; however, Ethereum uses the first 160 characters to represent the identity of an account.

If Bob, for example, creates an account on an Ethereum network, whether private or public, he will have his private key available to himself while the first 160 characters of his public key will become his identity. Other accounts on the network can then send Ether or other cryptocurrencies based on Ether to this account.

An account on Ethereum looks like the one shown in the following screenshot:

Figure 1.8 – An externally owned account identifier

An externally owned account can hold Ether in its balance and does not have any code associated with it. It can execute transactions with other externally owned accounts, and it can also execute transactions by invoking functions within contracts.

Contract accounts

Contract accounts are very similar to externally owned accounts. They are identified using their public address. They do not have a private key. They can hold Ether similar to externally owned accounts; however, they contain code for smart contracts consisting of functions and state variables.

Externally owned accounts are responsible for initiating transactions and each transaction in Ethereum requires gas, which is the cost of the transaction to be provided by the sender of the transaction. Gas has a relationship to its currency known as Ether. The next section will discuss the concepts related to Ether, gas, and transactions.

Ether, gas, and transactions

Ether is the currency of Ethereum. Every activity on Ethereum that modifies its state charges Ether as a fee. And miners who are successful in generating and writing a block in a chain are also rewarded Ether. Ether can easily be converted to dollars or other currencies through crypto exchanges.

Ethereum has a metric system of denominations known as units of Ether. The smallest denomination or base unit of Ether is called wei. The following is a list of the named denominations and their value in wei, which is available at https://github.com/ethereum/web3.js/blob/0.15.0/lib/utils/utils.js#L40:

var unitMap = {
   'wei' : '1'
   'kwei': '1000',
   'ada': '1000',
   'femtoether': '1000',
   'mwei': '1000000',
   'babbage': '1000000',
   'picoether': '1000000',
   'gwei': '1000000000',
   'shannon': '1000000000',
   'nanoether': '1000000000',
   'nano': '1000000000',
   'szabo': '1000000000000',
   'microether': '1000000000000',
   'micro': '1000000000000',
   'finney': '1000000000000000',
   'milliether': '1000000000000000',
   'milli': '1000000000000000',
   'ether': '1000000000000000000',
   'kether': '1000000000000000000000',
   'grand': '1000000000000000000000',
   'einstein': '1000000000000000000000',
   'mether': '1000000000000000000000000',
   'gether': '1000000000000000000000000000',
   'tether': '1000000000000000000000000000000'
};

Gas

In the previous section, it was mentioned that fees are paid using Ether for any transaction execution that leads to a state change in Ethereum. Ether is traded on public exchanges, and its price fluctuates daily. If Ether is used for paying fees, then the cost of using the same service can be high on a certain day while being low on other days. People will wait for the price of Ether to fall to execute their transactions. This is not ideal for a platform such as Ethereum. Gas helps in alleviating this problem. This is the internal currency of Ethereum. The execution and resource utilization costs are predetermined in Ethereum in terms of gas units. For each unit of gas, a price can be ascribed, known as the gas price. For example, for each unit of gas, a price of 10 gwei can be assigned. When both the number of gas units and gas price are multiplied together, it results in the gas cost. The gas price can be adjusted to a lower price when the price of Ether increases and a higher price when the price of Ether decreases.

Transactions

A transaction is an agreement between a buyer and a seller, a supplier and a consumer, or a provider and a consumer that there will be an exchange of assets, products, or services for currency, cryptocurrency, or some other asset, either in the present or in the future. Ethereum helps in executing the transaction. The following are the three types of transactions that can be executed in Ethereum:

• The transfer of Ether from one account to another: The accounts can be externally owned accounts or contract accounts. The following are the possible cases:
  • An externally owned account sending Ether to another externally owned account in a transaction
  • An externally owned account sending Ether to a contract account in a transaction
  • A contract account sending Ether to another contract account in a transaction
  • A contract account sending Ether to an externally owned account in a transaction
• Deployment of a smart contract: An externally owned account can deploy a contract using a transaction in an EVM.
• Using or invoking a function within a contract: Executing a function in a contract that changes state is considered a transaction in Ethereum. If executing a function does not change a state, it does not require a transaction.

A transaction has some of the following important properties related to it:

• The from account property denotes the account that originates the transaction and represents an account that is ready to send some gas or Ether. Both gas and Ether concepts were discussed earlier in this chapter. The from account can be externally owned or a contract account.
• The to account property refers to an account that is receiving Ether or benefits in lieu of an exchange. For transactions related to the deployment of the contract, the to field is empty. It can be externally owned or a contract account.
• The value account property refers to the amount of Ether that is transferred from one account to another.
• The input account property refers to the compiled contract bytecode and is used during contract deployment in an EVM. It is also used for storing data related to smart contract function calls along with their parameters. A typical transaction in Ethereum where a contract function is invoked is shown here. In the following screenshot, note the input field containing the function call to contract, along with its parameters:

Figure 1.9 – The transaction properties in a block

• The blockHash account property refers to the hash of the block to which this transaction belongs.
• The blockNumber account property is the block to which this transaction belongs.
• The gas account property refers to the amount of gas supplied by the sender who is executing this transaction.
• The gasPrice account property refers to the price per gas the sender was willing to pay in wei (we learned about wei in the Ether section earlier in this chapter). Total gas is computed at gas units x gas price.
• The hash account property refers to the hash of the transaction.
• The nonce account property refers to the number of transactions made by the sender prior to the current transaction.
• The transactionIndex account property refers to the serial number of the current transactions in the block.
• The value account property refers to the amount of Ether transferred in wei.
• The v, r, and s account properties relate to digital signatures and the signing of the transaction.

A typical transaction in Ethereum, where an externally owned account sends some Ether to another externally owned account, is shown here. Note that the input field is not used here. Since two Ethers were sent in the transaction, the value field is showing the value accordingly in wei, as shown in the following screenshot:

Figure 1.10 – Block properties in a block

One method to send Ether from an externally owned account to another externally owned account is shown in the following code snippet using the web3 JavaScript framework, which will be covered later in this book:

web.eth.sendTransaction({from: web.eth.accounts[0], to: "0x9d2a327b320da739ed6b0da33
c3809946cc8cf6a", value: web.
toWei(2, 'ether')})

A typical transaction in Ethereum where a contract is deployed is shown in the following screenshot. In the following screenshot, note the input field containing the bytecode of the contract:

Figure 1.11 – A sample transaction in a block

Blocks are an important concept in Ethereum. They are containers for a transaction. A block contains multiple transactions. Each block has a different number of transactions based on the gas limit and block size. The gas limit will be explained in detail in later sections. The blocks are chained together to form a blockchain. Each block has a parent block, and it stores the hash of the parent block in its header. Only the first block, known as the genesis block, does not have a parent.

A typical block in Ethereum is shown in the following screenshot:

Figure 1.12 – A typical block in Ethereum

There are a lot of properties associated with a block, providing insights and metadata about it, and the following are some of the important properties along with their descriptions:

• The difficulty property determines the complexity of the puzzle/challenge given to miners for this block.
• The gasLimit property determines the maximum gas allowed. This helps in determining how many transactions can be part of the block.
• The gasUsed property refers to the actual gas used for this block for executing all transactions in it.
• The hash property refers to the hash of the block.
• The nonce property refers to the number that helps in solving the challenge.
• The miner property is the account identifier of the miner, also known as coinbase or etherbase.
• The number property is the sequential number of this block on the chain.
• The parentHash property refers to the parent block's hash.
• The receiptsRoot, stateRoot, and transactionsRoot properties refer to the Merkle trees discussed during the mining process.
• The transactions property refers to an array of transactions that are part of this block.
• The totalDifficulty property refers to the total difficulty of the chain.

Armed with the understanding of the foundational concepts of blockchain and Ethereum, it's time to see a complete end-to-end transaction and how it flows through multiple components and gets stored in the ledger.

In this example, Sam wants to send a digital asset (for example, dollars) to Mark. Sam generates a transaction message containing the from, to, and value fields and sends it across to the Ethereum network. The transaction is not written to the ledger immediately and instead is placed in a transaction pool.

The mining node creates a new block and takes all transactions from the pool honoring the gas limit criteria and adds them to the block. This activity is done by all miners on the network. Sam's transaction will also be a part of this process.

The miners compete, trying to solve the challenge thrown at them. The winner is the miner who can solve the challenge first. After a period (of seconds), one of the miners will advertise that they have found the solution to the challenge and that they are the winner and should write the block to the chain. The winner sends the solution of the challenge, along with the new block, to all other miners. The rest of the miners validate and verify the solution, and once satisfied that the solution is indeed correct and that the original miner has cracked the challenge, they accept the new block containing Sam's transaction to append in their instance of the ledger. This generates a new block on the chain that is persisted across time and space. During this time, the accounts of both parties are updated with the new balance. Finally, the block is replicated across every node in the network.

The preceding example can be well understood with the following diagram:

Figure 1.13 – The transaction flow in Ethereum

This is the time to introduce smart contracts after understanding some of the important concepts related to Ethereum. Smart contracts are one of the unique value propositions of Ethereum, and this book will delve deeper into smart contracts in subsequent chapters.

A contract is a legal document that binds two or more parties who agree to execute a transaction immediately or in the future. Since contracts are legal documents, they are enforced and implemented by law.

Examples of contracts are an individual entering into a contract with an insurance company for covering their health insurance, an individual buying a piece of land from another individual, or a company selling its shares to another company.

A smart contract is a custom logic and code deployed and executed within an Ethereum virtual environment. Smart contracts are digitized and codified rules of the transaction between accounts. Smart contracts help in transferring digital assets between accounts as an atomic transaction. Smart contracts can store data. The data stored can be used to record information, facts, associations, balances, and any other information needed to implement the logic for real-world contracts. Smart contracts are very similar to object-oriented classes. A smart contract can call another smart contract just as an object-oriented object can create and use objects of another class. Think of smart contracts as a small program consisting of functions. You can create an instance of the contract and invoke functions to view and update contact data along with the execution of some logic.

Writing smart contracts

There are multiple smart contract authoring tools, including Visual Studio. However, the easiest and fastest way to develop smart contracts is to use a browser-based tool known as Remix. This is available at http://remix.ethereum.org. Remix is a new name and was earlier known as browser-solidity.

Remix provides a rich integrated development environment in a browser for authoring, developing, deploying, and troubleshooting contracts written using the Solidity language. All contract management-related activities such as authoring, deploying, and troubleshooting can be performed from the same environment without using other tools and utilities.

Not everyone is comfortable using the online version of Remix to author their smart contracts. Remix is an open source tool that can be downloaded from https://github.com/ethereum/browser-Solidity and compiled to run a private version on a local computer.

Another advantage of running Remix locally is that it can connect to local private chain networks directly; otherwise, users will first have to author the contract online and then copy it to a file, compile it, and deploy it manually to a private network. Let's explore Remix by performing the following steps:

1. Navigate to remix.ethereum.org. The site will open in a browser with a default contract, as shown in the following screenshot. If you do not need this contract, it can be deleted:

Figure 1.14 – The default Ballot contract in Remix

2. The first thing we need to do is to create a new contract by selecting + from Remix's left menu bar.
3. Then, provide a name for a new Solidity file that has a .sol extension. Name the contract HelloWorld and hit Enter on the keyboard to create a new Solidity file, as shown in the following screenshot. This will create a blank file:

Figure 1.15 – The HelloWorld.sol file in Remix

4. Type the following code in the empty authoring pane to create your first contract. This contract will be explained in detail in Chapter 3, Solidity Development. For now, it is sufficient to understand that the contract is created using the contract keyword. You can declare global state variables and functions, and contracts are saved with the .sol file extension. In the following code snippet, the HelloWorld contract returns the Hello World literal value when the GetHelloWorld function is executed:

   pragma solidity >=0.7.0 <0.9.0;
   contract HelloWorld
   {
       string private stateVariable = "Hello World";
       function GetHelloWorld() public view returns ( string 
         memory)
       {
           return stateVariable;
       }
   }

The extreme left of Remix has a wunderbar comprising multiple tabs. The FILE EXPLORERS tab helps in managing workspace along with project folder hierarchy and organization. Contract files are also managed using this tab. It has good integration with GitHub and helps in pushing changes to repositories.

The next is the SOLIDITY COMPILER tab. This tab helps in choosing an appropriate compiler version that helps in compiling the contracts. The SOLIDITY R COMPILER tab compiles the contract into bytecode – code that is understood by Ethereum. It displays warnings and errors as you author and edit the contract. These warnings and errors should be taken seriously, and they really help in creating robust contracts.

The third tab, DEPLOY AND RUN TRANSACTIONS, helps in deploying and executing the smart contracts to an environment. There are out-of-the-box JavaScript VMs (London and Berlin) in-built within the Remix page, and each represents a unique environment. This tab helps in connecting to any of the available VMs. It is also possible to connect to a custom Ethereum network using the injected web3 and web3 provider environment options. Remix comes bundled with the Ethereum runtime within the browser. This tab allows you to deploy the contract to this runtime using the JavaScript VM environment in the Environment option. The Injected Web3 environment is used along with tools such as Mist and MetaMask, which will be covered in the next chapter. Web3 provider can be used when using Remix in a local environment connecting to a private network. In our case for this chapter, the default, JavaScript VM, is sufficient. The rest of the options will be discussed later in Chapter 3, Introducing Solidity.

The Solidity static analysis tab helps in providing alerts related to implementing best practices within smart contracts. It provides a set of rules that are evaluated during compile time, and the user is notified of any rule not getting satisfied. There is also a Solidity unit testing tab that helps in executing unit tests against the smart contracts.

The previously mentioned tabs are available by default with Remix. They can be removed, and more features can be added using PLUGIN MANAGER, which is the last tab available with Remix.

5. Once a smart contract like the one shown in the next screenshot is authored using Remix, it can be deployed directed to the target environment (JavaScript VMs) using the DEPLOY & RUN TRANSACTIONS tab. This tab provides a Deploy button that will deploy the contract. It is always better to compile the contract before deploying, as it helps in identifying any issues with the contract. Deploying a contract will internally first compile it:

Figure 1.16 – The HelloWorld Smart contract

6. Click on the Deploy button (after selecting an appropriate contract) to deploy the contract to Ethereum JavaScript VM (either London or Berlin), and this will display the deployed contract along with its associated functions. Since we only had a single function, GetHelloWorld, the same function is displayed, as shown in the following screenshot:

Figure 1.17 – Deploying the HelloWorld smart contract in Remix

7. Click on the GetHelloWorld button to invoke and execute the function. The results of execution are shown in the following screenshot:

Figure 1.18 – Executing the GetHelloWorld function in Remix

Congratulations! You have created, deployed, and also executed a function on your first contract. The code for the HelloWorld contract is found in this chapter's GitHub repository and can be used in Remix if you are not interested in typing the contract.

Remix makes the deployment of contracts a breeze; however, it performs a lot of steps behind the scenes. It is always useful to understand the process of deploying contracts to have finer control over the deployment process.

The first step is the compilation of contracts. The compilation is done using the Solidity compiler. The next chapter will show you how to download and compile a contract using the Solidity compiler.

The compiler generates the following two major artifacts:

• The Application Binary Interface (ABI) definition
• Contracts bytecode

Think of the ABI as an interface consisting of all external and public function declarations along with their parameters and return types. The ABI defines the contract, and any caller wanting to invoke any contract function can use the ABI to do so.

The bytecode represents the low-level instruction set for the contract, and it is deployed in the Ethereum ecosystem. The bytecode is required during deployment, and the ABI is needed for invoking functions in a contract.

A new instance of a contract is created using the ABI definition.

Deploying a contract itself is a transaction. A transaction is created for deploying the contract on Ethereum. The bytecode and ABI are necessary inputs for deploying a contract.

As any transaction execution costs gas in Ethereum, an appropriate quantity of gas should be supplied while deploying the contract. As and when the transaction is mined, the contract will be available for interaction through the contract address.

Using the newly generated address, callers can invoke functions within the contract.

This chapter was an introduction to blockchains and, more specifically, to Ethereum. Having a good understanding of the big picture of how blockchains and Ethereum work will go a long way in writing robust, secure, and cost-effective smart contracts using Solidity.

This chapter covered the basics of blockchain, explained what blockchains are, why they are important, and how they help in building decentralized and distributed applications. The architecture of Ethereum was discussed in brief along with some of the important concepts, such as transactions, blocks, gas, Ether, accounts, cryptography, and mining.

This chapter also touched briefly on the topic of smart contracts and how to use Remix to author and execute them. I've kept this chapter brief, since the rest of the book will explain these concepts further and help you to quickly develop Solidity-based smart contracts.

You'll notice that this chapter does not contain any mention of Ethereum tools and utilities. This is what we will cover in the next chapter, by diving straight in and installing Ethereum and its toolset. The Ethereum ecosystem is quite rich, and there are lots of tools. We will cover important ones, such as web3.js, TestRPC, Geth, Mist, and MetaMask.

1. What are the two consensus mechanisms supported by Ethereum, although not together?
2. What two important artifacts are generated as part of compiling Solidity smart contracts?

The Ethereum documentation is a great place to get started with basic concepts: https://ethereum.org/en/developers/docs/.