Module 3

Bitcoin definition
The transaction lifecycle

• Bitcoin can be defined in various ways; it's a protocol, a digital currency, and a platform. It is
a combination of peer-to-peer network, protocols, and software that facilitate the creation and
usage of the digital currency named bitcoin.
• the transaction lifecycle of a bitcoin
The steps of the process are as follows:
1. A user/sender sends a transaction using wallet software or some other interface.
2. The wallet software signs the transaction using the sender's private key.
3. The transaction is broadcasted to the Bitcoin network using a flooding algorithm.
4. Mining nodes (miners) who are listening for the transactions verify and include this transaction in
the next block to be mined. Just before the transactions are placed in the block, they are placed in a
special memory buffer called the transaction pool. The purpose of the transaction pool is explained
in the next section.
5. Next, the mining starts, which is the process through which the blockchain is secured and new
coins are generated as a reward for the miners who spend appropriate computational resources.
Once a miner solves the PoW problem, it broadcasts the newly mined block to the network. PoW is
explained in detail in the Mining section. The nodes verify the block and propagate the block further,
and confirmations start to generate.
6. Finally, the confirmations start to appear in the receiver's wallet and after approximately three
confirmations, the transaction is considered finalized and confirmed.

The transaction data structure

A transaction at a high level contains metadata, inputs, and outputs. Transactions are combined
to create a block's body.
The transaction data structure is shown in the following table

Transaction validation
This verification process is performed by Bitcoin nodes. There are three main things that nodes
check when verifying a transaction:
1. That transaction inputs are previously unspent. This validation step prevents double
spending by verifying that the transaction inputs have not already been spent by
someone else.
2. That the sum of the transaction outputs is not more than the total sum of the transaction
inputs. However, both input and output sums can be the same, or the sum of the input
(total value) could be more than the total value of the outputs. This check ensures that
no new bitcoins are created out of thin air.
3. That the digital signatures are valid, which ensures that the script is valid.
Even though transaction construction and validation are generally a secure and sound
process, some vulnerabilities exist in Bitcoin. We will now introduce some Bitcoin's infamous
shortcomings.
Transaction bugs
The following are two major Bitcoin vulnerabilities that have been infamously exploited.
Transaction malleability
Transaction malleability is a Bitcoin attack that was introduced due to a bug in the Bitcoin
implementation. Due to this bug, it became possible for an adversary to change the transaction
ID of a transaction, thus resulting in a scenario where it would appear that a certain transaction
has not been executed.
structure of a Bitcoin block
A visualization of blockchain, block, block header, transactions, and scripts(diagram)
The data structure of a Bitcoin block is shown in the following table:
Tasks of the miners
Once a node connects to the Bitcoin network, there are several tasks that a Bitcoin miner
performs:
1. Synching up with the network: Once a new node joins the Bitcoin network, it
downloads the blockchain by requesting historical blocks from other nodes. This
is mentioned here in the context of the Bitcoin miner; however, this not necessarily a
task that only concerns miners.
2. Transaction validation: Transactions broadcast on the network are validated by full
nodes by verifying and validating signatures and outputs.
3. Block validation: Miners and full nodes can start validating blocks received by them by
evaluating them against certain rules. This includes the verification of each transaction
in the block along with verification of the nonce value.
4. Create a new block: Miners propose a new block by combining transactions broadcast
on the network after validating them.
Chapter 6
[ 221 ]
5. Perform PoW: This task is the core of the mining process and this is where miners find a
valid block by solving a computational puzzle. The block header contains a 32-bit nonce
field and miners are required to repeatedly vary the nonce until the resultant hash is less
than a predetermined target.
6. Fetch reward: Once a node solves the hash puzzle (PoW), it immediately broadcasts
the results, and other nodes verify it and accept the block. There is a slight chance that
the newly minted block will not be accepted by other miners on the network due to a
clash with another block found at roughly the same time, but once accepted, the miner is
rewarded with 12.5 bitcoins and any associated transaction fees.
We've discussed the tasks—let's now consider the rewards for performing them.

Smart Contracts Definition

There are many definitions of smart contracts. An online search reveals many definitions.
However, while the definitions provided online at various sources are correct and useful, in
my opinion, they are not complete. It is crucial to properly and completely define what a smart
contract is. The following is my attempt to provide a comprehensive generalized definition of
a smart contract:
A smart contract is a secure and unstoppable computer program representing an agreement that is
automatically executable and enforceable.
Dissecting this definition reveals that a smart contract is, fundamentally, a computer program
that is written in a language that a computer or target machine can understand. Also, it
encompasses agreements between parties in the form of business logic. Another fundamental
idea is that smart contracts are automatically executed according to the instruction that is coded
in, for example, when certain conditions satisfy. They are enforceable, which means that all
contractual terms perform as specified and expected, even in the presence of adversaries.
Enforcement is a broader term that encompasses traditional enforcement in the form of a law,
along with the implementation of specific measures and controls that make it possible to execute
contract terms without requiring any intervention.

Ricardian contracts
Ricardian contracts were initially proposed in the paper, Financial Cryptography in 7 Layers,
by
Ian Grigg, in the late 1990s.
This paper is available at https://iang.org/papers/fc7.html.
Ricardian contracts were initially used in a bond trading and payment system called Ricardo.
The fundamental idea behind this contract is to write a document that is understood and
accepted by both a court of law and computer software. Ricardian contracts address the
challenge of the issuance of value over the internet. A Ricardian contract identifies the
issuer and captures all the terms and clauses of the contract in a document to make it
acceptable as a legally binding contract.

A Ricardian contract is a document that has several of the following properties:

• It is a contract offered by an issuer to holders
• It is a valuable right held by holders and managed by the issuer
• It can be easily read by people (like a contract on paper)
• It can be read by programs (parsable, like a database)
• It is digitally signed
• It carries the keys and server information
• It is allied with a unique and secure identifier

The Ricardian Contract bowtie diagram

Types of blockchain oracles

There are various types of blockchain oracles, ranging from simple software oracles to complex
hardware assisted and decentralized oracles. Broadly speaking, we can categorize oracles into
two categories: inbound oracles and outbound oracles. The following section will examine some
of these in more detail.
Inbound oracles
This class represents oracles that receive incoming data from external services, and feed it into
the smart contract. We will shortly discuss software, hardware, and several other types of
inbound oracle.
Software oracles
These oracles are responsible for acquiring information from online services on the Internet. This
type of oracle is usually used to source data such as weather information, financial data (stock
prices, for example), travel information and other types of data from third-party providers.
The data source can also be an internal enterprise system, which may provide some enterprises
pecific data. These types of oracle can also be called standard or simple oracles.
Deploying smart contracts

Hardware oracles
This type of oracle is used to source data from hardware sources such as IoT devices or sensors.
This is useful in use cases such as insurance-related smart contracts where telemetry sensors
provide certain information, for example, vehicle speed and location. This information can be
fed into the smart contract dealing with insurance claims and payouts to decide whether to
accept a claim or not. Based on the information received from the source hardware sensors, the
smart contract can decide whether to accept or reject the claim.
These oracles are useful in any situation where real-world data from physical devices is
required. However, this approach requires a mechanism in which hardware devices are tamperproof
or tamper-resistant. This level of security can be achieved by providing cryptographic
evidence (non-repudiation and integrity) of IoT device's data and an anti-tampering mechanism
on the IoT device, which renders the device useless in case of tampering attempts.
Computation oracles
These oracles allow computing-intensive calculations to be performed off-chain. As blockchain
is not suitable for performing compute-intensive operations, a blockchain (that is, a smart
contract on a blockchain) can request computations to be performed on off-chain high performance
computing infrastructure and get the verified results back via an oracle. The use of
oracle, in this case, provides data integrity and authenticity guarantees.
An example of such an oracle is Truebit (https://truebit.io). It allows a smart contract to
submit computation tasks to oracles, which are eventually completed by miners in return for an
incentive.
Aggregation based
In this scenario, a single value is sourced from many different feeds. As an example, this single
value can be the price of a financial instrument, and it can be risky to rely upon only one feed.
To mitigate this problem, multiple data providers can be used where all of these feeds are
inspected, and finally, the price value that is reported by most of the feeds can be picked up.
The assumption here is that if the majority of the sources reports the same price value, then it is
likely to be correct. The collation mechanism depends on the use case: sometimes it's merely an
average of multiple values, sometimes a median is taken of all the values, and sometimes it is
the maximum value. Regardless of the aggregation mechanism, the essential requirement here is
to get the value that is valid and authentic, which eventually feeds into the system.

Module 4

The Ethereum blockchain

Ethereum, just like any other blockchain, can be visualized as a transaction-based state machine.
This definition is mentioned in the Ethereum yellow paper written by Dr. Gavin Wood.
The core idea is that in the Ethereum blockchain, a genesis state is transformed into a final
state by executing transactions incrementally. The final transformation is then accepted as the
absolute undisputed version of the state. In the following diagram, the Ethereum state transition
function is shown, where a transaction execution has resulted in a state transition:
Components of the Ethereum ecosystem
The Ethereum blockchain stack consists of various components. At the core, there is the
Ethereum blockchain running on the peer-to-peer Ethereum network. Secondly, there's
an Ethereum client (usually Geth) that runs on the nodes and connects to the peer-to-peer
Ethereum network from where blockchain is downloaded and stored locally. It provides
various functions, such as mining and account management. The local copy of the blockchain is
synchronized regularly with the network. Another component is the web3.js library that allows
interaction with the geth client via the Remote Procedure Call (RPC) interface.
The overall Ethereum ecosystem architecture is visualized in the following diagram

A list of elements present in the Ethereum blockchain is presented here:

• Keys and addresses
• Accounts
• Transactions and messages
• Ether cryptocurrency/tokens
• The EVM
• Smart contracts and native contracts
In the following sections, we will discuss each of these one by one. Other components such
wallets, clients, development tools, and environments will be discussed in the upcoming chapters.
We will also discuss relevant technical concepts related to a high-level element within that
section. First, let's have a look at keys and addresses.
Page 320 Read all elements

The Ethereum Virtual Machine (EVM)

The EVM is a simple stack-based execution machine that runs bytecode instructions to
transform the system state from one state to another. The word size of the EVM is set to 256-bit.
The stack size is limited to 1,024 elements and is based on the Last In, First Out (LIFO) queue.
The EVM is a Turing-complete machine but is limited by the amount of gas that is required to
run any instruction. This means that infinite loops that can result in denial-of-service attacks
are not possible due to gas requirements. The EVM also supports exception handling should
exceptions occur, such as not having enough gas or providing invalid instructions, in which case
the machine would immediately halt and return the error to the executing agent.
The EVM is an entirely isolated and sandboxed runtime environment. The code that runs on the
EVM does not have access to any external resources such as a network or filesystem. This results
in increased security, deterministic execution, and allows untrusted code (code that can be run
by anyone) to be executed on Ethereum blockchain
There are three main types of storage available for contracts and the EVM:
• Memory: The first type is called memory or volatile memory, which is a word-addressed
byte array. When a contract finishes its code execution, the memory is cleared. It is akin
to the concept of RAM. write operations to the memory can be of 8 or 256 bits, whereas
read operations are limited to 256-bit words. Memory is unlimited but constrained by
gas fee requirements.
• Storage: The other type is called storage, which is a key-value store and is permanently
persisted on the blockchain. Keys and values are each 256 bits wide. It is allocated to all
accounts on the blockchain. As a security measure, storage is only accessible by its own
respective CAs. It can be thought of as hard disk storage.
• Stack: EVM is a stack-based machine, and thus performs all computations in a data area
called the stack. All in-memory values are also stored in the stack. It has a maximum
depth of 1024 elements and supports the word size of 256 bits.
Blocks and blockchain
Blocks are the main building structure of a blockchain. Ethereum blocks consist of various
elements, which are described as follows:
• The block header
• The transactions list
• The list of headers of ommers or uncles
The transaction list is simply a list of all transactions included in the block. Also, the list of
headers of uncles is also included in the block.
Block header: Block headers are the most critical and detailed components of an Ethereum
block. The header contains various elements, which are described in detail here:
• Parent hash: This is the Keccak 256-bit hash of the parent (previous) block's header.
• Ommers hash: This is the Keccak 256-bit hash of the list of ommers (or uncles) blocks
included in the block.
• The beneficiary: The beneficiary field contains the 160-bit address of the recipient that
will receive the mining reward once the block is successfully mined.
• State root: The state root field contains the Keccak 256-bit hash of the root node of the
state trie. It is calculated once all transactions have been processed and finalized.
• Transactions root: The transaction root is the Keccak 256-bit hash of the root node of the
transaction trie. The transaction trie represents the list of transactions included in the
block.
• Receipts root: The receipts root is the Keccak 256-bit hash of the root node of the
transaction receipt trie. This trie is composed of receipts of all transactions included in
the block. Transaction receipts are generated after each transaction is processed and
contain useful post-transaction information. More details on transaction receipts are
provided in the next section.
• Logs bloom: The logs bloom is a bloom filter that is composed of the logger address and
log topics from the log entry of each transaction receipt of the included transaction list in
the block. Logging is explained in detail in the next section.
• Difficulty: The difficulty level of the current block.
• Number: The total number of all previous blocks; the genesis block is block zero.
• Gas limit: This field contains the value that represents the limit set on the gas
consumption per block.
• Gas used: This field contains the total gas consumed by the transactions included in the
block.
• Timestamp: The timestamp is the epoch Unix time of the time of block initialization.
An uncle block is a block that is the child of a parent but does not have
any child block. Ommers or uncles are valid, but stale, blocks that are
not part of the main chain but contribute to security of the chain. They
also earn a reward for their participation but do not become part of the
canonical truth.
Chapter 12
[ 343 ]
• Extra data: The extra data field can be used to store arbitrary data related to the block.
Only up to 32 bytes are allowed in this field.
• Mixhash: The mixhash field contains a 256-bit hash that, once combined with the nonce,
is used to prove that adequate computational effort (Proof of Work, or PoW) has been
spent in order to create this block.
• Nonce: Nonce is a 64-bit hash (a number) that is used to prove, in combination with the
mixhash field,
The genesis blocks
The genesis block is the first block in a blockchain network. It varies slightly from normal
blocks due to the data it contains and the way it has been created. It contains 15 items that are
described here.
The block validation mechanism

The block validation mechanism

An Ethereum block is considered valid if it passes the following checks:
• If it is consistent with uncles and transactions. This means that all ommers satisfy the
property that they are indeed uncles and also if the PoW for uncles is valid.
• If the previous block (parent) exists and is valid.
• If the timestamp of the block is valid. This means that the current block's timestamp
must be higher than the parent block's timestamp. Also, it should be less than 15
minutes into the future. All block times are calculated in epoch time (Unix time).
• If any of these checks fails, the block will be rejected. A list of errors for which the block
can be rejected is presented here:
• The timestamp is older than the parent
• There are too many uncles
• There is a duplicate uncle
• The uncle is an ancestor
• The uncle's parent is not an ancestor
• There is non-positive difficulty
• There is an invalid mix digest
• There is an invalid PoW

Gas
Gas is required to be paid for every operation performed on the Ethereum blockchain. This is a
mechanism that ensures that infinite loops cannot cause the whole blockchain to stall due to the
Turing-complete nature of the EVM. A transaction fee is charged as an amount of Ether and is
taken from the account balance of the transaction originator.
A fee is paid for transactions to be included by miners for mining. If this fee is too low, the
transaction may never be picked up; the more the fee, the higher are the chances that the
transactions will be picked up by the miners for inclusion in the block. Conversely, if the
transaction that has an appropriate fee paid is included in the block by miners but has too
many complex operations to perform, it can result in an out-of-gas exception if the gas cost is
not enough. In this case, the transaction will fail but will still be made part of the block, and the
transaction originator will not get any refund.
Transaction costs can be estimated using the following formula:
Total cost = gasUsed * gasPrice
Here, gasUsed is the total gas that is supposed to be used by the transaction during the
execution, and gasPrice is specified by the transaction originator as an incentive to the miners to
include the transaction in the next block. This is specified in ETH. Each EVM opcode has a fee
assigned to it. It is an estimate because the gas used can be more or less than the value specified
by the transaction originator originally. For example, if computation takes too long or the
behavior of the smart contract changes in response to some other factors, then the transaction
execution may perform more or fewer operations than intended initially and can result in
consuming more or less gas. If the execution runs out of gas, everything is immediately rolled
back; otherwise, if the execution is successful and some gas remains, then it is returned to the
transaction originator.

Wallets
A wallet is a generic program that can store private keys and, based on the addresses stored
within it, it can compute the existing balance of ether associated with the addresses by querying
the blockchain. It can also be used to deploy smart contracts. In this chapter, we will introduce
the MetaMask wallet, which has become the tool of choice for developers.
Having discussed the role of wallets within Ethereum, let's now discuss a number of common
clients. The following is a non-exhaustive list of the client software and wallets that are available
with Ethereum.
Geth
This is the official Go implementation of the Ethereum client.
Eth
This is the C++ implementation of the Ethereum client.
Parity
This implementation is built using Rust and developed by Parity technologies.
Trinity
Trinity is the implementation of the Ethereum protocol. It is written in Python.