When a user performs a transaction on a traditional system, there is a trusted third party involved who takes care of transaction processing, transaction logging, maintaining the ledgers and balances, and, in return, charge a transaction fee. With a DLT such as blockchain (for example, Ethereum), every participating full node has a copy of the ledger (blockchain). The trust is on the system itself as there is no party involved. Users initiate transactions, which are validated and grouped (in a block) and, based on consensus, the block is added to the ledger (blockchain).

This section is dedicated to the structure of block headers, transactions, adding transactions to a block, and finally, adding blocks to the blockchain. We have discussed blockchain and, in particular, Ethereum, in this section. However, we will be delving into DLTs such as Hyperledger in detail in subsequent chapters. There, we will walk through the structure, transaction flow, participants, and algorithms that are specific to Hyperledger Fabric. Visit Chapter 3, Delving into Hyperledger Fabric, for details about Hyperledger Fabric.

The Ethereum blockchain is a transaction-based state machine that starts with a genesis state. A transaction will then lead to a change of state, where the recent state is termed the current state. Hence, a transaction is a representation of a valid sequence flow between two states; the blockchain should contain only valid state transactions that occur because of a valid transaction.

Transactions are grouped into blocks. A block is chained to a previous block with a cryptographic hash, representing a chain of blocks called a blockchain. Here, the cryptographic hash is used as a reference. Blocks themselves are the journals, and the blockchain is the ledger where blocks record one or more transactions. Incentives are offered to miners, and incentivization occurs at the state transition. A blockchain that offers incentives to miners needs to have a consensus to transmit value to the miner. For example, Ethereum considers Ether as the value in the Ethereum blockchain, and it's used to offer incentives to the miner. The smallest unit of value, Wei, is used for incentivization in Ethereum.

Mining is a process where various nodes solve a puzzle to validate a transaction so that more transactions can be added as a block within the blockchain. This process of validating transactions is known as mining. Many miners act at the same time to validate the transaction and, once done, they submit a proof of their work, which is mathematical proof. Miners not only have to solve the puzzle – they need to solve it way before other miners to be able to add their block to the blockchain. This is the process of miners solving a puzzle and submitting a PoW. The winning miner is rewarded with some form of value. If it's Ethereum, then a certain amount of Ether is offered as a reward to the miner.

As Ethereum is decentralized, every node has equity and can participate in creating new blocks. There could be malicious participants as well who might propose a new path. Hence, the system makes sure to reach a consensus that follows on from the genesis block to the current block. Ethereum uses the GHOST (which stands for Greedy Heaviest Observed Subtree) protocol to check the creation of multiple branches in the blockchain and to follow the best valid path.

Mapping between account addresses (160-bit unique identifier) and the account state is termed the world state, which is maintained in the Merkle tree (Trie). The Trie is maintained in the state database. Since the root node is dependent cryptographically on all of the internal nodes' data, the root node's hash can be used as a global secure identity for the blockchain network.

Small objects constitute the shared global state of Ethereum. These objects interact via message-passing framework. These objects are termed as accounts. A state is associated with each account and each account has a 20-byte address, where accounts are identified by a 160-bit identifier. Ethereum has two kinds of accounts, where externally owned accounts have no codes associated and they can initiate new transactions. However, contract accounts have contract codes attached to them, along with a unique address, and they cannot initiate new transactions. Contract accounts can only perform contract-to-contract messaging. Remember, external accounts initiate transactions by signing them with their private keys and sending those transactions to another external account or to a contract account. If the transaction is sent to a contract account, this will result in the execution of the business logic of the contract account (smart contract's account).

Both of these accounts have an account state that is represented by four components: nonce, balance, storage root, and code hash. For an externally owned account, the nonce highlights the transactions initiated from account's address, while for a contract account, it represents the contracts that have been created by that contract account. Balance shows the base unit of the Ether (in the Ethereum blockchain). The storage root holds the hash of the root node of the Merkle tree, while the code hash contains the hash of the code on the contract account, which is deployed on EVM.

A block is comprised of a block header (BH), transaction set (BT), and the other block's headers for the current block's ommers (BU), as shown in the following code:

B = (BH, BT, BU)

Ommers are those miners whose blocks were orphaned and didn't make it to the blockchain. However, they were successful in mining the block, but their block was added in time. Ethereum offers a low incentive to those miners as well.

Ethereum block headers contain the following components:

• Parent Hash: Hash of the parent block's header
• Ommers Hash: Hash of the ommer's list portion of the current block
• Beneficiary: Miner's account address, who is entitled to the incentive
• State Root: Hash of the Trie's root node
• Transactions Root: Trie's root node's hash that has the transaction list portion of the block
• Receipts Root: Trie's root node's hash that has the receipts for each transaction that is listed in the block
• Logs Bloom: Log information such as logger address and log topics
• Difficulty: Value representing the difficulty level of the block
• Number: Number showcasing the value of ancestor blocks; for example, for the genesis block, this number is zero
• Gas Limit: Value that shows the gas limit per block
• Gas Used: Value showing the gas used for the transactions in the block
• Timestamp: Time at the block's inception; essentially, it's the system time
• Extra Data: Array containing the block data; it's just 32 bytes and should contain relevant data only
• mixHash: A hash value that, when mixed with the nonce, will prove the sufficiency of the computations performed on the block
• Nonce: A hash value that, when mixed with the mixHash, will prove the sufficiency of the computations performed on the block

The receipt of each transaction comprises cumulative gas prices of the block in which the transaction resides, the set of logs created for the transaction, the bloom filter from the transaction log, and the transaction's status code.

A transaction is signed and created by external accounts. These transactions result in messages being sent between contract accounts and the creation of a contract account. Each transaction has the following fields:

• Nonce: Enlists the number of transactions initiated by the sender
• Gas Price: Value (price) paid in Wei for the cost of computation to execute the transaction
• Gas Limit: Maximum gas limit for the given transaction; the given transaction should not cost more than this limit
• To: Address of the recipient of the message or transaction
• Value: The transacted value to be transferred to the recipient
• V, r, s: Signature of the sender of the transaction
• Init: Usually associated with a contract creation transaction, which specifies the EVM code for the initialization of the account; it's executed once at the time of creation of the account and is discarded afterwards
• Data: Message call's input data

The following diagram shows the transaction, block, and inclusion of the block to the blockchain, which are discussed in detail in this section. Please refer to this diagram while reading about the transaction components, block header components, blockchain, and transaction flow. It also shows the inclusion of consensus in the entire process:

Transactions are executed in the EVM. When a transaction is executed, it passes through initial validation:

1. The validity of the signature of the initiator
2. Validity of the transaction's nonce (must match the sender's current nonce)
3. Check the gas limit (it should be more than the intrinsic gas used by the transaction)
4. Well-formedness of the transaction
5. The sender's account should have sufficient funds for the upfront payment

Once the transaction has been validated successfully, the following steps are performed:

1. The cost of the transaction is deducted upfront from the sender's account balance.
2. The nonce value of the sender's account is incremented by one.
3. The transaction is executed, and during transaction execution, the logic of the transaction in the contract (smart contract) is executed.
4. While the transaction is executing, various sub-state information is collected, such as log series and refund balance. In addition, the remaining gas (total gas limit minus intrinsic gas used) is calculated.
5. Once the transaction is used to create a valid state, unused gas is refunded to the sender, the miner is incentivized, and gas that was used for the transaction is added to a gas counter, which tracks the total gas used by all of the transactions that are part of the block.
6. Finally, the state is changed and logs are created for the transaction.

Now, we know that transactions are executed in the EVM and that they have to go through various validation and processing steps.

In this section, we will walk through the steps for adding a transaction to the block, which are as follows:

1. Validate ommer: Within the blockchain header, each ommer block must be a valid header
2. Validate transactions: The gas that's used for the block should be equal to or less than the gas that's used for all of the transactions to be listed on the block
3. Apply the rewards, also known as incentives: Miners are awarded
4. Verify the state and block nonce: Apply state changes to each transaction and define the new block

Now, we understand how transactions are added to a block. In this section, we'll look at how a block is added to the blockchain. We already know that the block header contains mixHash and nonce, which prove the sufficiency of the computations performed on the block. This sufficiency of computation is defined as the total difficulty a miner had to go through to create a new block. The algorithm for total difficulty or the block difficulty is called the PoW algorithm (also known as Ethash in Ethereum). A block is only valid if it contains PoW of a given difficulty (maybe soon to be replaced with PoS).

A seed is calculated for each block by scanning the header of the block until that point in time. From the seed, a pseudo-random cache is computed and, from the cache, a dataset is generated. Full clients and miners need to store this dataset. Miners will randomly pick a few slices of the dataset and will hash them together into mixHash. Each miner will continue to repeat this set of generating mixHashes, until the mixHash matches the nonce. When the mixHash matches the nonce, the nonce is considered valid and hence the block is considered valid and can be added to the blockchain. Transactions that are part of this block are also considered to be confirmed.

Remember, there are many miners on the network, and they get to hear about the transaction at different times. Hence, each miner is mining different transactions (this could also be based on the transaction fee associated with each transaction), and so is generating its own block. Since each miner is building its own block with its own set of transactions in it, how does the block that gets mined and validated come to a common agreement? They reach a common agreement based on the consensus.

It is evident that miners perform validation of the transaction and build their own block of transactions. Once they solve the puzzle and create a new valid block, they broadcast it to the blockchain network. This is where the consensus algorithm of the blockchain appears, which will ensure that the blockchain network reaches a consensus about the ordering of the transactions and about whose valid block needs to be added to the blockchain. Remember, the decision about whose block to be considered as the next block on the blockchain also determines the reward to the miner. This is taken care of by consensus algorithms such as PoW or PoS.

Ethereum uses PoW and will move to PoS soon. With PoS being the consensus algorithm for the blockchain network, any miner who solves the problem first and broadcasts the valid block will be considered the winner. With PoS, the creator of a new block is chosen in a deterministic way, depending on its wealth, which is also defined as its stake. Interestingly, there are no block rewards in PoS and so the miners will be offered transaction fees. This is the reason why miners are forgers in PoS and not miners. The following table lists the differences between PoW and PoS:

The following outlines some of the consensus methods in detail:

• PoW: This is the pioneer consensus algorithm. It is used in Bitcoin and other cryptocurrencies. Consensus is an algorithm that processes blocks of transactions and adds them to blockchain when an agreement is reached between the nodes. Hence, for a network that follows PoW consensus, that network is following the PoW rules to establish various processing blocks of transactions and add them to blockchain. The process of generating PoW and to allow a node to add a block to the blockchain is known as mining, and nodes that participate in mining are called miners. Before a miner adds a block to blockchain, PoW requires miners to solve a complex business problem (also known as a puzzle). In exchange for solving the business problem (puzzle), miners are rewarded. In a currency-based blockchain like Bitcoin or Ethereum, they are awarded with cryptocurrency. Essentially, miners compete with other miners to find a correct hash for each hash function. As soon as a miner reaches the solution and finds the correct hash, it propagates it to all the other nodes in the P2P network. Other nodes verify the hash before adding the block (set of transactions) to the blockchain. To maintain block time, the difficulty level of the problem (puzzle) is dynamically changed by the network. In the event of multiple miners solving the problem at the same time, then the longest chain is considered the winner, as the longest chain is the most trustworthy chain.
  It solves the double spending problem, but is slow and costly from an energy and fee perspective, and not considered scalable.
• PoS: This is an alternative to PoW, suggested in 2011, and was first implemented by Peercoin (2012). In PoS, the miner’s probability to mine depends on the stake (coins) the miners own in the system. For example, a miner with 15% of the stake (coins) has a 15% probability of mining the next block. It is expensive to attack a blockchain network based on PoS consensus, and it is energy efficient as well. Hence, in PoS, the probability of creating a block and being rewarded is determined by the stake in the network. Essentially, the probability of creating a block is directly proportional to the stake in the underlying cryptocurrency.
  But doesn't this mean the rich get richer? To prevent this, PoS follows randomization, that is, checking centralization, which may arise when a rich node gets richer and finally takes over the entire network. An attacker loses its stake for every attempt it makes to attach the blockchain network based on PoS. The problem with PoS is the nothing at stake problem, where a block generator can vote for multiple blockchain(s), also known as forks, and so, they can block the system from achieving consensus.
  

• Proof of Elapsed Time (PoET): Introduced by Intel in 2016, the PoET consensus algorithm suits permissioned blockchain networks such as Hyperledger sawtooth. The PoET algorithm is based on wait time, where the participating nodes (known as validators) wait for a randomly selected period. Essentially, validators generate a random wait time and sleep for that time. The first one that wakes up (also known as the one with the shortest wake time) will get the chance to commit a new block to the blockchain and propagate that information to all the nodes in the P2P network. With this random wait time, each node has a fair and similar probability to add blocks to the network. The PoET algorithm needs to take care of two tasks—firstly, it needs to ensure that participating nodes have really selected a random sleep time (not the shortest sleep time), and secondly, that the node has reached the sleep time and not woke up in the middle of the sleep time. PoET is cost-effective and offers equal opportunity to all participants. However, it is not suited for permissionless public blockchain networks.
  PoET results in a leader selection, where leadership is randomly distributed to the validators in the entire network. As the cost of the participation of the validators is low, it enlarges the population of validators, and therefore, enhances the robustness of the consensus algorithm.
• Byzantine Fault Tolerance (BFT): This is not from the family of Proof algorithms. Its name is derived from the classic Byzantine general’s problem. An army, along with their Byzantine generals, surrounded a fort city. Generals are scattered around the fort city and, for an attack to succeed, they need to attack in unison. If all the generals do not attack in unison, they will lose the war. Now, they need to communicate with each other to reach a consensus so that they attack at the same time.
  In technical terms, it needs a system with several peer nodes to reach a consensus, even if there are few attackers and malicious nodes trying to influence the nodes. The Practical Byzantine Fault Tolerance algorithm can help solve the BFT.

• Practical Byzantine Fault Tolerance (PBFT): Hyperledger Fabric uses this consensus mechanism. PBFT offers a Byzantine state machine replication that is designed to tolerate malicious nodes (Byzantine faults). All the nodes are sequentially ordered, where one node is declared as the leader node (primary node) and other nodes are known as follower nodes (secondary/backup nodes). Any node will become a leader by transitioning from follower node to leader node, mostly via a round-robin algorithm. All nodes communicate and need to perform two tasks—firstly, they need to verify that the message came from a specific peer node, and secondly, they need to verify and ensure that the message was not modified during its communication. All nodes will reach a consensus, irrespective of the state of the network, using majority rule. The entire network is based on the assumption that no more than one-third of the network nodes are malicious. The more nodes, the more secure the network will be. It has the following phases:

1. A client sends a request to a leader node
2. Leader node propagates this message to all the follower (secondary) nodes
3. All the nodes (leader and follower) will perform a task, as requested by the client, and send a response back to the client
4. The client will verify the responses and ensure that the request (attack or retreat) is served successfully when it receives n + 1 replies with the same result, where n is the max number of malicious nodes

This is also based on the fact that the nodes are deterministic. The final result is attained when all honest nodes reach an agreement on the order and collectively accept or reject the order.