In the last module, we learned about the use of public key cryptography and hashing for validation of transactions and blocks. After this module, you will be able to define elements of trust in a blockchain, security, validation, verification, and consensus; discuss consensus protocol, an algorithmic approach to add a new block and to secure the chain; explain trust and the robustness of the main chain; illustrate trust in managing exceptional situations such as hard fork and soft fork. Let us understand trust using a common everyday scenario in a centralized system such as an airport system. Say, you want to fly out of the Buffalo airport. The airport authority would have pre-established a secure environment for people to arrive and depart. This establishes the base trust. Then there is additional trust once you enter and your passport and travel documents are verified, validated, and your baggage is screened. Even more trust in you is established when the airline staff checks your boarding pass at the gate and you enter the aircraft to fly. Now, let's consider a decentralized system. There is nobody checking your credentials and certifying that you are trustworthy. Then, how do you do it? You do it by using algorithms and techniques discussed in the last module. Let's examine how these will help address the trust issues in a blockchain. Similar to our airport scenario, trust in a decentralized blockchain is also about securing, validating, verifying, and making sure resources needed for transaction execution are available. This is accomplished by securing the chain using specific protocols, validating the transaction and blocks for tamper proofing, verifying the availability of resources for transactions, and executing and confirming the transactions. The Trust Trail is defined by these operations: validate transaction, verify gas and resources, gather transactions, execute transaction to get a new state, form the block, work towards consensus, finalize the block by the bidder, and everyone add the block to their chain and confirm the transactions. We will examine each of these steps. Steps one and two are validate transaction and check resources. In the case of a Bitcoin, there are about 20 criteria that have to be checked before a transaction is validated, as discussed in module one, similarly in the case of Ethereum transaction. The syntax, the transaction signature, time stamp, nonce, gas limit, and sender account balance are validated before execution. The fuel, or gas points, and other resources available for smart contract execution, are also validated. Transaction signatures and hash are also verified. Step number three is execute transactions. Merkle tree hash of the validated transactions is computed. This is in Ethereum. This is the transaction root of the block header. All miners execute the transaction for either transfer, as well as for execution of smart contracts. The state resulting from transaction execution are used in computing the Merkle tree hash of the states, the state root of the block header. The receipt root of the block header is also computed. In the next lesson, we'll continue to talk about the next step in trust trail, the consensus process.