Module-I Blockchain 101

Bitcoin
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.
 Bitcoin with a capital B is used to refer to the Bitcoin protocol/System
 bitcoin with a lowercase b is used to refer to bitcoin, the currency.

Private key Generation in bitcoin

 Important step in generating keys is to find a secure source of entropy, or randomness.
 Creating a bitcoin key is essentially the same as "Pick a number between 1 and 2256.
 The exact method you use to pick that number does not matter as long as it is not predictable or repeatable.
 Bitcoin software uses the underlying operating system’s random number generators to produce 256 bits
of entropy
 More precisely, the private key can be any number between 0 and n - 1 inclusive, where n is a constant
(n = 1.1578 * 1077, slightly less than 2256) defined as the order of the elliptic curve used in bitcoin Private
Key is simply a number, picked at random.
 To create such a key, we randomly pick a 256-bit number and check that it is less than n.
 If the result is less than n, we have a suitable private key. Otherwise, we simply try again with another
random number.
 Private Key is used to create signatures that are required to spend bitcoin by proving ownership of funds
used in a transaction.
 Private Key must also be backed up and protected from accidental loss because if it’s lost it cannot be
recovered.
 Private keys are basically 256-bit numbers chosen in the range specified by the SECP256K1 ECDSA
recommendation.
 FFFF FFFF FFFF FFFF FFFF FFFE BAAE DCE6 AF48 A03B BFD2 5E8C D036 4140 is a valid private
key.
 Private keys (ECDSA Key) are usually encoded using Wallet Import Format (WIF) in order to make
them easier to copy and use.

Public key Generation in bitcoin

 Public key is calculated from the private key using elliptic curve multiplication, which is irreversible:
 K = k * G, where k is the private key, G is a constant point called the generator point, and K is the
resulting public key.
 The reverse operation, known as "finding the discrete logarithm"—calculating k if you know K—is
as difficult as trying all possible values of k, i.e., a brute-force search.
 Public keys are basically x and y coordinates on an elliptic curve and in an uncompressed format and
are presented with a prefix of 04 in a hexadecimal format.
 Public key K is defined as a point K = (x,y)
 X and Y coordinates are both 32- bit in length.
 Public keys can be presented in an uncompressed or compressed format.
 In total, the compressed public key is 33 bytes long as compared to 65 bytes in the uncompressed
format.
 The compressed version of public keys basically includes only the X part, since the Y part can be
derived from it.
 Keys are identified by various prefixes, described as follows:
 Uncompressed public keys used 0x04 as the prefix.
 Compressed public key starts with 0x03 if the y 32-bit part of the public key is odd.
 Compressed public key starts with 0x02 if the y 32-bit part of the public key is even.

ABHISHEK K L Assistant Professor Department of AIML

Module-I Blockchain 101

Addresses in Bitcoin
 The bitcoin address is created by taking the corresponding public key of a private key and hashing it
twice:First with the SHA256 algorithm and then with RIPEMD160.
 The resultant 160-bit hash is then prefixed with a version number and finally encoded with a
Base58Check encoding scheme.
 The bitcoin addresses are 26-35 characters long and begin with digit 1 or 3. A typical bitcoin address
looks like a string shown here: 1ANAguGG8bikEv2fYsTBnRUmx7QUcK58wt
 This is also commonly encoded in a QR code for easy sharing. The QR code of the preceding address is
shown in the following image:

QR code of a bitcoin address 1ANAguGG8bikEv2fYsTBnRUmx7QUcK58wt

 Currently, there are two types of addresses, the commonly used P2PKH and another P2SH type, starting
with 1 and 3, respectively.

Base58Check encoding
 This encoding is used to limit the confusion between various characters, such as 0OIl as they can look
the same in different fonts.
 The encoding basically takes the binary byte arrays and converts them into human-readable strings. This
string is composed by utlilizing a set of 58 alphanumeric symbols.
 More explanation and logic can be found in the base58.h source file in the bitcoin source code.

ABHISHEK K L Assistant Professor Department of AIML

Module-I Blockchain 101

Vanity addresses
A vanity address in Bitcoin is a type of cryptocurrency address that is customized to include a specific pattern
of characters. These addresses are created by using special software that allows users to
generate addresses containing their desired letters or numbers, like "Abhishek" or
"1GoodLuck".
Example: if Bitcoin address is 1ANAguGG8bikEv2fYsTBnRUmx7QUcK58wt
Vanity address for the above bitcoin: 1ABHISHEKEikEv2fYsTBnRUmx7QUcK58wt

Transactions
 Transactions can be as simple as just sending some bitcoins to a bitcoin address, or it can be quite complex
depending on the requirements.
 Each transaction is composed of at least one input and output.
 Inputs can be thought of as coins being spent that have been created in a previous transaction and outputs
as coins being created.
 If a transaction is minting new coins, then there is no input and therefore no signature is needed.
 If a transaction is to sends coins to some other user (a bitcoin address), then it needs to be signed by the
sender with their private key and a reference is also required to the previous transaction in order to show
the origin of the coins.

The transaction life cycle

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 include this transaction in the next block to be mined.
5. Mining starts once a miner who solves the Proof of Work problem broadcasts the newly mined block
to the network.
6. The nodes verify the block and propagate the block further, and confirmation starts to generate.
7. Finally, the confirmations start to appear in the receiver's wallet and after approximately six
confirmations, the transaction is considered finalized and confirmed.

The transaction structure

A transaction at a high level contains metadata, inputs, and outputs. Transactions are combined to create
a block.
Field Size Description
Used to specify rules to be used by the miners and nodes for transaction
Version number 4 bytes
processing (Used for upgrading the transaction rules)
1-9
Input counter The number (positive integer) of inputs included in the transaction.
bytes
 Each input is composed of several fields, including previous transaction
hash, Previous Txout-index, Txin-script length, Txin-script, and optional
List of inputs Variable sequence number.
 The first transaction in a block is also called a coinbase transaction. It
specifies one or more transaction inputs.
1-9
Output counter A positive integer representing the number of outputs.
bytes
List of outputs Variable Outputs included in the transaction.
This defines the earliest time when a transaction becomes valid. It is either
Lock time 4 bytes
a Unix timestamp or a block number.

ABHISHEK K L Assistant Professor Department of AIML

Module-I Blockchain 101

 MetaData: This part of the transaction contains some values such as the size of the transaction, the
number of inputs and outputs, the hash of the transaction, and a lock_time field. Every transaction has a
prefix specifying the version number.
 Inputs: Generally, each input spends a previous output. Each output is considered an Unspent
Transaction Output (UTXO) until an input consumes it.
 Outputs: Outputs have only two fields, and they contain instructions for the sending of bitcoins. The
first field contains the amount of Satoshis, whereas the second field is a locking script that contains the
conditions that need to be met in order for the output to be spent. More information on transaction
spending using locking and unlocking scripts and producing outputs is discussed later in this section.
 Verification: Verification is performed using bitcoin's scripting language.

The script language

 Bitcoin uses a simple stack-based language called script to describe how bitcoins can be spent and
transferred. It is not Turing complete and has no loops to avoid any undesirable effects of long
running/hung scripts on the bitcoin network.
 This scripting language is based on a Forth-like syntax and uses a reverse polish notation in which every
operand is followed by its operators. It is evaluated from the left to the right using a Last in First Out
(LIFO) stack.
 Scripts use various Opcodes or instructions to define their operation. Opcodes are also known as words,
commands, or functions. Earlier versions of the bitcoin node had a few Opcodes that are no longer used
due to bugs discovered in their design.

A description of the most commonly used Opcodes is listed here.

This takes a public key and signature and validates the signature of the hash of
OP_CHECKSIG the transaction. If it matches, then TRUE is pushed onto the stack; otherwise,
FALSE is pushed.
OP_EQUAL This returns 1 if the inputs are exactly equal; otherwise, 0 is returned.
OP_DUP This duplicates the top item in the stack.
OP_HASH160 The input is hashed twice, first with SHA-256 and then with RIPEMD-160.
OP_VERIFY This marks the transaction as invalid if the top stack value is not true.
OP_EQUALVERIFY This is the same as OP_EQUAL, but it runs OP_VERIFY afterwards.
This takes the first signature and compares it against each public key until a
match is found and repeats this process until all signatures are checked. If all
OP_CHECKMULTISIG
signatures turn out to be valid, then a value of 1 is returned as a result;
otherwise, 0 is returned.

Types of transactions
1. Pay to Public Key Hash (P2PKH): P2PKH is the most commonly used transaction type and is used to
send transactions to the bitcoin addresses. The format of the transaction is shown as follows:
ScriptPubKey: OP_DUP OP_HASH160 <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG
ScriptSig: <sig> <pubKey>

The ScriptPubKey and ScriptSig parameters are concatenated together and executed. An example will follow
shortly in this section, where this is explained in more detail.

ABHISHEK K L Assistant Professor Department of AIML

Module-I Blockchain 101

2. Pay to Script Hash (P2SH): P2SH is used in order to send transactions to a script hash (that is, the
addresses starting with 3) and was standardized in BIP16. In addition to passing the script, the redeem
script is also evaluated and must be valid. The template is shown as follows:
ScriptPubKey: OP_HASH160 <redeemScriptHash> OP_EQUAL
ScriptSig: [<sig>...<sign>] <redeemScript>

3. MultiSig (Pay to MultiSig): M-of-N MultiSig transaction script is a complex type of script where it is
possible to construct a script that required multiple signatures to be valid in order to redeem a transaction.
Various complex transactions such as escrow and deposits can be built using this script. The template is
shown here:
ScriptPubKey: <m> <pubKey> [<pubKey> . . . ] <n> OP_CHECKMULTISIG
ScriptSig: 0 [<sig > . . . <sign>]

Raw multisig is obsolete, and multisig is usually part of the P2SH redeem script, mentioned in the previous
bullet point.

4. Pay to Pubkey: This script is a very simple script that is commonly used in coinbase transactions. It is
now obsolete and was used in an old version of bitcoin. The public key is stored within the script in this
case, and the unlocking script is required to sign the transaction with the private key. The template is
shown as follows:
<PubKey> OP_CHECKSIG

5. Null data/OP_RETURN: This script is used to store arbitrary data on the blockchain for a fee. The limit
of the message is 40 bytes. The output of this script is unredeemable because OP_RETURN will fail the
validation in any case. ScriptSig is not required in this case. The template is very simple and is shown as
follows:
OP_RETURN <data>

A P2PKH script execution is shown in the following diagram:

ABHISHEK K L Assistant Professor Department of AIML

Module-I Blockchain 101

Example of a Bitcoin script:

<sig>
<pubKey>
OP DUP
OP HASH160
<pubKeyHash?>
OP EQUALVERIFY
OP CHECKSIG

In this example,
 The first two instructions of the script are the signature and public key used to verify that signature.
 Then we duplicate the instruction with OP DUP where we simply push a copy of the public key onto
the stack data structure.
 This instructions is followed by OP HASH160 which basically pops the top value and computes the
cryptographic hash and then pushes the result onto the stack.
 OP_EQUAL---This returns 1 if the inputs are exactly equal; otherwise, 0 is returned.
 OP_VERIFY--This marks the transaction as invalid if the top stack value is not true.
 OP_CHECKSIG----This takes a public key and signature and validates the signature of the hash of
the transaction. If it matches, then TRUE is pushed onto the stack; otherwise, FALSE is pushed.

Coinbase transactions
A coinbase transaction or generation transaction is always created by a miner and is the first transaction in a
block. It is used to create new coins. It includes a special field, also called coinbase, which acts as an input
to the coinbase transaction. This transaction also allows up to 100 bytes of arbitrary data that can be used to
store arbitrary data.

What is UTXO?
Unspent Transaction Output (UTXO) is an unspent transaction output that can be spent as an input to a new
transaction. Other concepts related to transactions in bitcoin are described below.

Transaction verification
This verification process is performed by bitcoin nodes. The following is described in the bitcoin developer
guide:
1. Check the syntax and ensure that the syntax of the transaction is correct.
2. Verify that inputs and outputs are not empty.
3. Check whether the size in bytes is less than the maximum block size, which is 1 MB currently.
4. The output value must be in the allowed money range (0 to 21 million BTC).
5. All inputs must have a specified previous output, except for coinbase transactions, which should not be
relayed.
6. Verify that nLockTime must not exceed 31-bits. For a transaction to be valid, it should not be less than
100 bytes. Also, the number of signature operands in a standard signature should be less than or not more
than 2.
7. Reject nonstandard transactions; for example, ScriptSig is allowed to only push numbers on the stack.
ScriptPubkey not passing the isStandard() checks.
6. A transaction is rejected if there is already a matching transaction in the pool or in a block in the main
branch.
7. The transaction will be rejected if the referenced output for each input exists in any other transaction in
the pool.
8. For each input, there must exist a referenced output transaction. This is searched in the main branch and
the transaction pool to find whether the output transaction is missing for any input, and this will be

ABHISHEK K L Assistant Professor Department of AIML

Module-I Blockchain 101

considered an orphan transaction. It will be added to the orphan transactions pool if a matching
transaction is not in the pool already.
9. For each input, if the referenced output transaction is the coinbase, it must have at least 100
confirmations; otherwise, the transaction will be rejected.
10. For each input, if the referenced output does not exist or has been spent already, the transaction will be
rejected.
11. Using the referenced output transactions to get input values, verify that each input value, as well as the
sum, is in the allowed range of 0-21 million BTC.
12. Reject the transaction if the sum of input values is less than the sum of output values.
13. Reject the transaction if the transaction fee would be too low to get into an empty block.

The structure of a bitcoin block

Bytes Name Description
80 Block header This includes fields from the block header described in the next section.
Variable Transaction The field contains the total number of transactions in the block, including the
counter coinbase transaction.
Variable Transaction All transactions in the block.

The structure of a bitcoin block header

Bytes Name Description
4 Version The block version number that dictates the block validation rules to follow.
Previous block
32 This is a double SHA256 hash of the previous block's header.
header hash
This is a double SHA256 hash of the merkle tree of all transactions included
32 merkle root hash
in the block.
This field contains the approximate creation time of the block in the Unix
epoch time format. More precisely, this
4 Timestamp
is the time when the miner has started hashing the header (the time from
the miner's point of view).
4 Difficulty target This is the difficulty target of the block.
This is an arbitrary number that miners change repeatedly in order to
4 Nonce
produce a hash that fulfills the difficulty target threshold.

As shown in the below diagram, blockchain is a chain of blocks where each block is linked to its previous
block by referencing the previous block header's hash. This linking makes sure that no transaction can be
modified unless the block that records it and all blocks that follow it are also modified. The first block is not
linked to any previous block and is known as the genesis block. Each block contains transactions and block
headers which are further magnified on the right-hand side. On the top, first, block header is expanded to
show various elements within the block header. Then on the right-hand side the Merkle root element of the
block header is shown in magnified view which shows that how Merkle root is calculated. We have discussed
Merkle trees in detail previously, Further down transactions are also magnified to show the structure of a
transaction and the elements that it contains. Also, note that transactions are then further elaborated by
showing that what locking and unlocking scripts look like.

ABHISHEK K L Assistant Professor Department of AIML

Module-I Blockchain 101

A visualization of blockchain, block, block header, transaction and script

ABHISHEK K L Assistant Professor Department of AIML

Module-I Blockchain 101

Mining
 Mining is a resource-intensive process by which new blocks are added to the blockchain. Blocks contain
transactions that are validated via the mining process by mining nodes and are added to the blockchain.
 This process is resource-intensive in order to ensure that the required resources have been spent by miners
in order for a block to be accepted. New coins are minted by the miners by spending the required
computing resources. This also secures the system against frauds and double spending attacks while
adding more virtual currency to the bitcoin ecosystem.
 Roughly one new block is created (mined) every 10 minute. Miners are rewarded with new coins if and
when they create new blocks and are paid transaction fees in return of including transactions in their
blocks.
 New blocks are created at an approximate fixed rate. Also, the rate of creation of newbitcoins decreases
by 50%, every 210,000 blocks, roughly every 4 years. When bitcoin was initially introduced, the block
reward was 50 bitcoins; then in 2012, this was reduced to 25 bitcoins. In July
 2016, this was further reduced to 12.5 coins (12 coins) and the next reduction is estimated to be on July
4, 2020. This will reduce the coin reward further down to approximately six coins. Approximately 144
blocks, that is, 1,728 bitcoins are generated per day. The number of actual coins can vary per day;
however, the number of blocks remains at 144 per day.
 Bitcoin supply is also limited and in 2140, almost 21 million bitcoins will be finally created and no new
bitcoins can be created after that. Bitcoin miners, however, will still be able to profit from the ecosystem
by charging transaction fees.

Task of miners
Once a node connects with 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 only for a miner.
2. Transaction validation: Transactions broadcasted 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 broadcasted on the network
after validating them.
5. Perform Proof of Work: 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, 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 due to a clash with another block found at roughly the same time, but once accepted, the
miner is rewarded with 12.5 bitcoins (as of 2016) and any associated transaction fees.

ABHISHEK K L Assistant Professor Department of AIML

Module-I Blockchain 101

Proof of Work
This is a proof that enough computational resources have been spent in order to build a valid block. Proof of
Work (PoW) is based on the idea that a random node is selected every time to create a new block. In this
model, nodes compete with each other in order to be selected in proportion to their computing capacity. The
following equation sums up the Proof of Work requirement in bitcoin:
H ( N || P_hash || Tx || Tx || . . . Tx) < Target
Where N is a nonce, P_hash is a hash of the previous block, Tx represents transactions in the block, and
Target is the target network difficulty value. This means that the hash of the previously mentioned
concatenated fields should be less than the target hash value. The only way to find this nonce is the brute
force method. Once a certain pattern of a certain number of zeroes is met by a miner, the block is immediately
broadcasted and accepted by other miners.

The mining algorithm

The mining algorithm consists of the following steps.
1. The previous hash block is retrieved from the bitcoin network.
2. Assemble a set of potential transactions broadcasted on the network into a block.
3. Compute the double hash of the block header with a nonce and the previous hash using the SHA256
algorithm.
4. If the resultant hash is lower than the current difficulty level (target), then stop the process.
5. If the resultant hash is greater than the current difficulty level (target), then repeat the process by
incrementing the nonce. As the hash rate of the bitcoin network increased, the total amount of 32- bit
nonces was exhausted too quickly. In order to address this issue, the extra nonce solution was
implemented, whereby the coinbase transaction is used as a source of extra nonce to provide a larger
range of nonces to be searched by the miners.
6. Mining difficulty increased over time and bitcoins that could be mined by single CPU laptop computers
now require dedicated mining centers to solve the hash puzzle. The current difficulty level can be queried
using the bitcoin command line interface using the following command:

$ bitcoin-cli getdifficulty

Flowchart for mining algorithm

ABHISHEK K L Assistant Professor Department of AIML

Module-I Blockchain 101

Mining rewards
When Bitcoin started in 2009 the mining reward used to be 50 bitcoins. After every 210,000 blocks, the block
reward halves. In November 2012 it halved down to 25 bitcoins. Currently, it is 12.5 BTC per block since
July 2016. Next halving is on Friday, 12 June 2020 after which the block reward will be reduced down to
6.25 BTC per block. This mechanism is hardcoded in Bitcoin to regulate, control inflation and limit the
supply of bitcoins.

Mining systems
Over time, bitcoin miners have used various methods to mine bitcoins. As the core principle behind mining
is based on the double SHA256 algorithm, overtime miners have developed sophisticated systems to
calculate the hash faster and faster. The following is a review of the different types of mining methods used
in bitcoin and how they evolved with time.

1. CPU
 CPU mining was the first type of mining available in the original bitcoin client. Users could even
use laptop or desktop computers to mine bitcoins.
 CPU mining is no longer profitable and now more advanced mining methods such as ASIC-based
mining are used.

2. GPU
 Due to the increased difficulty of the bitcoin network and general tendency of finding faster methods
to mine, miners started to use GPUs or graphics cards available in PCs to perform mining.
 GPUs support faster and parallelized calculations that are usually programmed using the OpenCL
language. This turned out to be a faster option as compared to CPUs.
 Users also used techniques such as overclocking to gain maximum benefit of the GPU power. Also,
the possibility of using multiple graphics cards increased the popularity of graphics cards' usage for
bitcoin mining. GPU mining, however, has some limitations, such as overheating and the
requirement for specialized motherboards and extra hardware to house multiple graphics cards.

3. FPGA
 Even GPU mining did not last long, and soon miners found another way to perform mining using
FPGAs. Field Programmable Gate Array (FPGA) is basically an integrated circuit that can be
programmed to perform specific operations.
 FPGAs are usually programmed in hardware description languages (HDLs), such as Verilog and
VHDL. Double SHA256 quickly became an attractive programming task for FPGA programmers
and several open source projects started too.
 FPGA offered much better performance as compared to GPUs; however, issues such as accessibility,
programming difficulty, and the requirement for specialized knowledge to program and configure
FPGAs resulted in a short life of the FPGA era for bitcoin mining.
 Also, the arrival of ASICs resulted in quickly phased out FPGA-based systems for mining.

4. ASICs
 Application Specific Integrated Circuit (ASIC) was designed to perform the SHA-256 operation.
These special chips were sold by various manufacturers and offered a very high hashing rate. This
worked for some time, but due to the quickly increasing mining difficulty level, single-unit ASICs
are no longer profitable.
 Currently, mining is out of the reach of individuals and now professional mining centers using
thousands of ASIC units in parallel are offering mining contracts to users to perform mining on
their behalf. There is no technical limitation, that's why a single user cannot run thousands of
ASICs in parallel, but it will require dedicated data centers and hardware and cost for a single
individual can become prohibitive.

ABHISHEK K L Assistant Professor Department of AIML

Module-I Blockchain 101

Mining pools
 A mining pool forms when group miners work together to mine a block.
 The Pool manager receives the coinbase transaction if the block is successfully mined, which is then
responsible for distributing the reward to the group of miners who invested resources to mine the block.
 There are various models that a mining pool manager can use to pay to the miners, such as the pay-per-
share model and the proportional model.
 In the pay per share model, the mining pool manager pays a flat fee to all miners who participated in the
mining exercise.
 Whereas in the proportional model, the share is calculated based on the amount of computing resources
spent to solve the hash puzzle. Many commercial pools now exist and provide mining service contracts
via the cloud and easy-to-use web interfaces.
 The most commonly used ones are AntPool, F2Pool, and [Link]. A

Wallets
 The wallet software is used to store private or public keys and Bitcoin address. It performs various
functions, such as receiving and sending bitcoins.
 Private keys are generated by randomly choosing a 256-bit number by wallet software. Private keys are
used by wallets to sign the outgoing transactions.
 Wallets do not store any coins, and there is no concept of wallets storing balance or coins for a user. In
fact, in the Bitcoin network, coins do not exist; instead, only transaction information is stored on the
blockchain (more precisely, UTXO, unspent outputs), which are then used to calculate the number of
bitcoins.

Types of Wallets
In bitcoin, there are different types of wallets that can be used to store private keys. As a software
program, they also provide some functions to the users to manage and carry out transactions on the bitcoin
network.
1. Non-deterministic wallets
 These wallets contain randomly generated private keys and are also called Just a Bunch of Key
wallets.
 The bitcoin core client generates some keys when first started and generates keys as and when
required. Managing a large number of keys is very difficult and an error-prone process can lead to
theft and loss of coins.
 Moreover, there is a need to create regular backups of the keys and protect them appropriately in
order to prevent theft or loss.
2. Deterministic wallets
 In this type of wallet, keys are derived out of a seed value via hash functions.
 This seed number is generated randomly and is commonly represented by human-readable
mnemonic code words. Mnemonic code words are defined in BIP39.
 This phrase can be used to recover all keys and makes private key management comparatively easier.
3. Hierarchical deterministic wallets
 Defined in BIP32 and BIP44, HD wallets store keys in a tree structure derived from a seed. The seed
generates the parent key (master key), which is used to generate child keys and, subsequently,
grandchild keys. Key generation in HD wallets does not generate keys directly; instead, it produces
some information (private key generation information) that can be used to generate a sequence of
private keys.

ABHISHEK K L Assistant Professor Department of AIML

Module-I Blockchain 101

 The complete hierarchy of private keys in an HD wallet is easily recoverable if the master private
key is known. It is because of this property that HD wallets are very easy to maintain and are highly
portable.
4. Brain wallets
 The master private key can also be derived from the hash of passwords that are memorized.
 The key idea is that this passphrase is used to derive the private key and if used in HD wallets, this
can result in a full HD wallet that is derived from a single memorized password. This is known as
brain wallet.
 This method is prone to password guessing and brute force attacks but techniques such as key
stretching can be used to slow down the progress made by the attacker.
5. Paper wallets
 As the name implies, this is a paper-based wallet with the required key material printed on it.
 It requires physical security to be stored. Paper wallets can be generated online from various service
providers, such as [Link] or [Link]
6. Hardware wallets
 Another method is to use a tamper-resistant device to store keys. This tamper-resistant device can
be custom-built or with the advent of NFC-enabled phones, this can also be a secure element (SE)
in NFC phones.
 Trezor and Ledger wallets (various types) are the most commonly used bitcoin hardware wallets.
7. Online wallets
 Online wallets, as the name implies, are stored entirely online and are provided as a service usually
via cloud.
 They provide a web interface to the users to manage their wallets and perform various functions such
as making and receiving payments. They are easy to use but imply that the user trust the online wallet
service provider.
8. Mobile wallets
 Mobile wallets, as the name suggests, are installed on mobile devices. They can provide various
methods to make payments, most notably the ability to use smart phone cameras to scan QR codes
quickly and make payments.
 Mobile wallets are available for the Android platform and iOS, for example, bread wallet, copay,
and Jaxx. Jaxx Mobile

Bitcoin improvement proposals (BIPs)

These documents are used to propose or inform the bitcoin community about the improvements
suggested, the design issues, or information about some aspects of the bitcoin ecosystem. There are three
types of bitcoin improvement proposals, abbreviated as BIPs:
 Standard BIP: Used to describe the major changes that have a major impact on the bitcoin system,
for example, block size changes, network protocol changes, or transaction verification changes.
 Process BIP: A major difference between standard and process BIPs is that standard BIPs cover
protocol changes, whereas process BIPs usually deal with proposing a change in a process that is
outside the core Bitcoin protocol. These are implemented only after a consensus among bitcoin users.
 Informational BIP: These are usually used to just advise or record some information about the
bitcoin ecosystem, such as design issues.

ABHISHEK K L Assistant Professor Department of AIML

Module-I Blockchain 101

Current market cap (as of March, 2018) of the top 10 coins is shown as follows:

Difficulty adjustment and retargeting algorithms

In bitcoin a difficulty target is calculated simply by the following equation; however other coins have either
developed their own algorithms or implemented modified versions of the bitcoin difficulty algorithm:

T = Time previous * time actual / 2016 * 10 min

 The idea behind difficulty regulation in bitcoin is that a generation of 2016 blocks should take roughly
around 2 weeks (inter-block time should be around 10 minutes).
 If it takes longer than 2 weeks to mine 2016 blocks then the difficulty is decreased and if it takes less
than two weeks to mine 2016 blocks then the difficulty is increased.

ABHISHEK K L Assistant Professor Department of AIML

Module-I Blockchain 101

 When ASICs were introduced due to a high block generation rate the difficulty increased exponentially
and that is one drawback of PoW algorithms that are not ASIC resistant. This leads to mining power
centralization. This also poses another problem; if a new coin starts now with the same Proof of Work
based on SHA256 as bitcoin uses, then it would be easy for a malicious user to just simply use an ASIC
miner and control the entire network.
 multipools pose a greater threat where a group of miners can automatically switch to the currency that is
becoming profitable. This phenomenon is known as pool hopping and can adversely affect a blockchain,
and consequently the growth of the altcoin.
 Pool hopping impacts the network adversely because pool hoppers join the network only when the
difficulty is low and they can gain quick rewards; the moment difficulty goes up (or is readjusted) they
hop off and then come back again when the difficulty is adjusted back.

For example if a multipool consumes its resources in quickly mining a new coin, the difficulty will
increase very quickly; when the multipool leaves the currency network; it becomes almost unusable
because of the fact that now the difficulty has increased to such a level that it is no longer profitable for
solo miners and can no longer be maintained. The only fix for this problem is to initiate a hard fork which
is usually undesirable for the community.

Difficulty algorithms being used in various altcoins.

1. Kimoto Gravity Well
 This algorithm is used in various altcoins to regulate difficulty. This was first introduced in Megacoin
and used to adaptively adjust difficulty of the network every block. The logic of the algorithm is shown
as follows:
KGW = 1 + (0.7084 * pow((double(PastBlocksMass)/double(144)), -1.228))
 Basically, the algorithm runs in a loop that goes through a set of predetermined blocks (PastBlockMass)
and calculates a new readjustment value.
 The core idea behind this algorithm is to develop an adaptive difficulty regulation mechanism that can
readjust the difficulty in response to rapid spikes in hash rates.
 Kimoto Gravity Well (KGW) ensures that the time between blocks remains approximately the same. In
bitcoin the difficulty is adjusted every 2016 blocks but in KGW the difficulty is adjusted at every block.
 This algorithm is vulnerable to time warp attacks, which allow an attacker to temporarily enjoy less
difficulty in creating new blocks. This attack allows a time window where the difficulty becomes low
and the attacker can easily generate many coins at a fast rate.

2. Dark Gravity Wave

 Dark Gravity Wave (DGW) is a new algorithm designed to address certain flaws such as the time warp
attack in the KGW algorithm. This concept was first introduced in Dash, previously known as Darkcoin.
 It makes use of multiple exponential moving averages and simple move averages to achieve a smoother
readjustment mechanism. The formula is shown as follows:
2222222/ (((Difficulty+2600)/9)^2)
 This formula is implemented in Dash coin, Bitcoin SegWit2X and various other altcoins as a mechanism
to readjust difficulty.
 DGW version 3.0 is the latest implementation of DGW algorithm and allows improved difficulty
retargeting as compared to KGW.

ABHISHEK K L Assistant Professor Department of AIML

 Module-I Blockchain 101

3. DigiShield
 This is another difficulty retargeting algorithm that has recently been used in Zcash with slight
variations and after adequate experimentation.
 This algorithm works by going through a fixed number of previous blocks to calculate the time they
took to be generated and then readjusts the difficulty to the difficulty of the previous block by dividing
the actual time span by averaging the target time.
 In this scheme, the retargeting is calculated much more rapidly, and also the recovery from a sudden
increase or decrease in hash rate is quick.
 This algorithm protects against multipools, which can result in rapid hash rate increases.
 The network difficulty is readjusted every block or every minute depending on the implementation. The
key innovation is faster readjusting times as compared to KGW.
 Zcash uses DigiShield v3.0 which uses the following formula for difficulty adjustment:
(New difficulty) = (previous difficulty) x SQRT [ (150 seconds) / (last solve time)

4. MIDAS
 Multi-Interval Difficulty Adjustment System (MIDAS) is an algorithm that is comparatively more
complex than the algorithms discussed previously due to number of parameters it uses.
 This method responds much more rapidly to abrupt changes in hash rates. This algorithm also protects
against time warp attacks.

Bitcoin limitations
The most prominent and widely discussed limitation is the lack of anonymity in bitcoin.

Privacy and anonymity

 As the blockchain is a public ledger of all transactions and is openly available it becomes trivial to
analyse it. Combined with traffic analyses, transactions can be linked back to their source IP addresses,
thus possibly revealing a transaction's originator. This is a big concern from a privacy point of view.
 Even though in bitcoin it is a recommended and common practice to generate a new address for every
transaction, thus allowing some level of unlinkability, this is not enough and various techniques have
been developed and successfully used to trace the flow of transactions throughout the network and link
them back to their originator.

 Various methods to analyse blockchains such as transaction graphs, address graphs, and entity graphs
have been used by researchers to link users to the transactions, thus raising privacy concerns. The afore
mentioned analysis techniques can be further enriched by using publicly available information about
transactions and linking them to the actual users.

Various proposals have been made to address the privacy issue in bitcoin. These proposals fall into three
categories: mixing protocols, third-party mixing networks, and inherent anonymity.

i. Mixing protocols
 These schemes are used to provide anonymity to bitcoin transactions. In this model, a mixing service
provider (an intermediary or a shared wallet) is used.
 Users send coins to this shared wallet as a deposit and the shared wallet then can send some other coins
(of the same value deposited by some other users) to the destination.
 Users can also receive coins that were sent by others via this intermediary. This way the link between
outputs and inputs is no longer there and transaction graph analysis will not be able to reveal the true
relationship between senders and receivers.

ABHISHEK K L Assistant Professor Department of AIML

 Module-I Blockchain 101

 CoinJoin is one example of mixing protocols, where two transactions are joined together to form a
single transaction while keeping the inputs and outputs unchanged. The core idea behind CoinJoin is to
build a shared transaction that is signed by all participants. This technique improves privacy for all
participants involved in the transactions:

CoinJoin transaction with three users joining their transaction into a single larger CoinJoin transaction

ii. Third-party mixing protocols

 These are centralized services (often called "tumblers") that mix Bitcoin on behalf of users by pooling
and redistributing funds.
 Operated by a single entity or organization that manages the mixing process.
 Users send their Bitcoin to the service, and the service redistributes "mixed" coins from its reserves.
 Users must trust the service provider to mix the funds honestly and return them.
 Various services, with varying degrees of complexity, such as CoinShuffle, Coinmux, and dark send in
Dash (coin) are available that are based on the idea of CoinJoin (mixing) transactions.

iii. Inherent anonymity

 Inherent anonymity refers to the built-in privacy features of Bitcoin that arise from its design, where
users interact through pseudonymous addresses (public keys) without revealing personal information
directly. However, these features are limited by Bitcoin’s transparent and public ledger.
 A user can generate as many addresses as they wish, creating a separation between transactions.
 The most popular is Zcash, which is discussed in detail later in the chapter. Other examples include
Monero, which makes use of ring signatures to provide anonymous services.

Alternative Coins
Since the initial success of bitcoin, many alternative currency projects have been launched. Bitcoin was
released in 2009 and the first alternative coin project (named Namecoin) was introduced in 2011. In 2013
and 2014, the altcoin market grew exponentially and many different types of alternative coin project were
started.

There are various factors and new concepts introduced with alternative coins. Many concepts were invented
even before bitcoin but with bitcoin not only were new concepts, such as a solution to the Byzantine Generals'
problem, introduced for the first time but also previous concepts such as hashcash and Proof of Work were
used in an ingenious way and came into the limelight. Altcoins must be able to attract new users, trades, and
miners otherwise the currency will have no value.

ABHISHEK K L Assistant Professor Department of AIML

Module-I Blockchain 101

Current market cap (as of Oct 2016) of the top 10 coins is shown as follows:

Litecoin
Litecoin is a fork of the bitcoin source code released in 2011. It uses Scrypt as PoW, originally introduced in
the Tenebrix coin. Litecoin allows for faster transactions as compared to bitcoin due to its faster block
generation time of 2.5 minutes. Also difficulty readjustment is achieved every 3.5 days roughly due to faster
block generation time. The total coin supply is 84 million.

Scrypt is a sequentially memory hard function that is the first alternative to the SHA-256-based PoW
algorithm. It was originally proposed as a password-based key derivation function PBKDF. Scrypt uses the
following parameters to generate a derived key (Kd):
 Passphrase: This is a string of characters to hash
 Salt: This is a random string that is provided to Scrypt functions (generally all hash functions) in order
to provide a defence against brute-force dictionary attacks using rainbow tables
 N: This is a memory/CPU cost parameter that must be a power of 2 > 1
 P: The parallelization parameter
 R: The block size parameter
 dkLen: The intended length of the derived key in bytes.
 Formally, this function can be written as follows:
Kd = scrypt (P, S, N, P, R, dkLen)

 Before applying the core Scrypt function, the algorithm takes P and S as input and applies PBKDF2
and SHA-256-based HMAC. Then the output is fed to an algorithm called ROMix, which internally
uses the Blockmix algorithm utilizing the Salsa20/8 core stream cipher to fill up the memory which
requires large memory to operate, thus enforcing the sequentially memory hard property.

ABHISHEK K L Assistant Professor Department of AIML

Module-I Blockchain 101

 The output from this step of the algorithm is finally fed to the PBKDF2 function again in order to produce
a derived key. This process is shown in the following diagram:

ABHISHEK K L Assistant Professor Department of AIML

Module-I Blockchain 101

Smart Contracts
“A smart contract is a secure and unstoppable computer program representing an agreement that is
automatically executable and enforceable.”

Dissecting this definition further reveals that

 A smart contract is in fact 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 key idea is that
smart contracts are automatically executed when certain conditions are met.
 They are enforceable, which means that all contractual terms are executed as defined and expected, even
in the presence of adversaries.
 they are secure and unstoppable, which means that these computer programmes are required to be
designed in such a fashion that they are fault tolerant and executable in reasonable amount of time.

In summary, a smart contract has the following four properties:

 Automatically executable
 Enforceable
 Semantically sound
 Secure and unstoppable.

The first two properties are required as a minimum, whereas the latter two may not be required or
implementable in certain scenarios and can be relaxed.

Ricardian Contract
“A Ricardian Contract is a digital document designed to act as a legally enforceable agreement between
parties, combining human-readable legal text and machine-readable metadata. It is used to bridge the gap
between legal agreements and their execution in software systems, particularly in blockchain and smart
contract ecosystems.”

The key idea is to write a document which is understandable and acceptable by both a court of law and
computer software. Ricardian contract is a document that has several of the following properties:
 A contract offered by an issuer to holders
 A valuable right held by holders, and managed by the issuer
 Easily readable by people (like a contract on paper)
 Readable by programs (parseable, like a database)
 Digitally signed
 Carries the keys and server information
 Allied with a unique and secure identifier

Ricardian contracts, bowtie Model

 Document is digitally signed by the issuer using their private key.
 Document is then hashed using a message digest function to produce a hash by which the document
can be identified.
 Hash is then further used and signed by parties during the performance of the contract in order to link
each transaction, with the identifier hash thus serving as evidence of intent.
 This is called as bowtie model.
 The diagram below shows the World of Law on the left hand side from where the document originates.
It is then hashed and the resultant message digest is used as an indentifier throughout the World of
Accountancy.

ABHISHEK K L Assistant Professor Department of AIML

Module-I Blockchain 101

 The World of Accountancy can basically represent any or multiple accounting, trading and information
systems that are being used in a business to perform various business operations.
 The idea behind this flow is that the message digest generated by hashing the document is first used in a
so called genesis transaction, or first transaction, and then used in every transaction as an indentifier
throughout the operational execution of the contract.
 This way, a secure link is created between the original written contract and every transaction in the World
of Accounting.

 Ricardian contract is different from a smart contract

 Smart contract does not include any contractual document and is focused purely on the
execution of the contract.
 Ricardian contract is more concerned with the semantic richness and production of a
document that contains contractual legal prose.

 Semantics of a contract can be divided into two types:

 Operational semantics
 Defines the actual execution, correctness and safety of the contract,
 Denotational semantics.
 Concerned with the real-world meaning of the full contract.

 legal semantics vs operational performance

Oracles
 Oracles can be used to provide external data to smart contracts.
 Oracles are an important component of the smart contract ecosystem. The limitation with smart contracts
is that they cannot access external data which might be required to control the execution of the business
logic;
 for example, the stock price of a security that is required by the contract to release the dividend payments.
 An Oracle is an interface that delivers data from an external source to smart contracts. Depending on the
industry and requirements, Oracles can deliver different types of data ranging from weather reports,
realworld news, and corporate actions to data coming from Internet of Things (IoT) devices.
 Oracles are trusted entities that use a secure channel to transfer data to a smart contract.

ABHISHEK K L Assistant Professor Department of AIML

Module-I Blockchain 101

 Oracles are also capable of digitally signing the data proving that the source of the data is authentic.
 Smart contracts can subscribe to the Oracles, Smart contracts can either pull the data, or Oracles can push
the data to the smart contracts.
 Oracles should not be able to manipulate the data they provide and must be able to provide authentic
data.
 Oracles can be built based on distributed mechanism. Oracles can themselves source data from another
blockchain which is driven by distributed consensus thus ensuring the authenticity of data.
 Hardware Oracles is also introduced by researchers where real-world data from physical devices is
required. For example, this can be used in telemetry and IoT.
 There are platforms available now to enable a smart contract to get external data using an Oracle.
 In order to prove the authenticity of the data retrieved by the Oracles from external sources,
 Mechanisms like TLSnotary can be used which produce proof of communication between the data
source and the oracle.
 This ensures that the data fed back to the smart contract is definitely retrieved from the source.
 The following diagram shows a generic model of an oracle and smart contract ecosystem:

Fig: A simplified model of an oracle interacting with smart contract on blockchain

Deploying smart contracts on a blockchain

 Smart contracts may or may not be deployed on a blockchain but it makes sense to deploy them on a
blockchain due to the distributed consensus mechanism provided by blockchain.
 Ethereum is an example of a blockchain that natively supports the development and deployment of smart
contracts.
 Smart contracts on Ethereum blockchain are usually part of a larger application such as Decentralized
Autonomous organization (DAOs).
 In bitcoin blockchain the lock_time field in the bitcoin transaction can be seen as an enabler of a basic
version of a smart contract.
 lock_time field enables a transaction to be locked until a specified time or after a number of blocks, thus
enforcing a basic contract that a certain transaction can only be unlocked if certain conditions (elapsed
time or number of blocks) is met Can be viewed as basic smart contract.
 Bitcoin scripting language, though limited, can be used to construct basic smart contracts.

ABHISHEK K L Assistant Professor Department of AIML

Module-I Blockchain 101

Decentralized Autonomous organization (DAOs).

 DAO is one of the highest crowdfunded projects, and started in April 2016.
 Set of smart contracts written in order to provide a platform for investment.
 Due to a bug in the code this was hacked in June 2016 and an equivalent of 50 million dollars was
siphoned out of the DAO into another account.
 Resulted in a hard fork on Ethereum in order to recover from the attack.
 It should be noted that the notion of code is law, or unstoppable smart contracts
 Ethereum foundation was able to stop and change the execution of The DAO by introducing a hard
fork.
 Hard fork goes against the true spirit of decentralization and the notion of code is law.
 Resistance against this hard fork
 Some miners who decided to keep mining on the original chain resulted in the creation of
Ethereum Classic.
 This is the original, non-forked Ethereum blockchain where code is still law.

ABHISHEK K L Assistant Professor Department of AIML

Module-I Blockchain 101

Ethereum 101- I
In Ethereum, the world state is a key concept that represents the current state of the entire Ethereum
blockchain at any given point. It includes all accounts and their associated data. The world state is dynamic
and changes with each block as transactions are executed.

The Ethereum stack

The Ethereum stack consists of various components.
 At the core, there is the Ethereum blockchain running on the P2P 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.
 Various Ethereum clients have been developed using different languages and currently most
popular are go-Ethereum and parity.
 go-Ethereum was developed using Golang, whereas parity was built using Rust. There are other
clients available too, but usually, the go-Ethereum client known as geth is sufficient for all
purposes.
 Mist is a user-friendly Graphical User Interface (GUI) wallet that runs geth in the background to
sync with the network. More details on this will be provided later in the chapter, in the installation
and mining section.
 The local copy of the blockchain is synchronized regularly with the network. Another component is the
[Link] library that allows interaction with geth via the Remote Procedure Call (RPC) interface.
 The first release of Ethereum was known as Frontier, and the current release of Ethereum is called
homestead release.
 The next version is named metropolis and it focuses on protocol simplification and performance
improvement.
 The final release is named serenity, which is envisaged to have a Proof of Stake algorithm (Casper)
implemented with it. Other areas of research targeted with serenity include scalability, privacy, and
Ethereum virtual machine (EVM) upgrade.

The Ethereum stack showing various components

ABHISHEK K L Assistant Professor Department of AIML

Module-I Blockchain 101

Ethereum Gas
 All transactions on the Ethereum blockchain are required to cover the cost of computation they are
performing. The cost is covered by something called gas or crypto fuel, which is a new concept
introduced by Ethereum.
 This gas as execution fee is paid upfront by the transaction originators. The fuel is consumed with each
operation. Each operation has a predefined amount of gas associated with it.
 Each transaction specifies the amount of gas it is willing to consume for its execution. If it runs out of
gas before the execution is completed, any operation performed by the transaction up to that point is
rolled back. If the transaction is successfully executed, then any remaining gas is refunded to the
transaction originator. This concept should not be confused with mining fee, which is a different concept
that is used to pay gas as a fee to the miners.

The Ethereum consensus mechanism

The consensus mechanism in Ethereum is based on the GHOST protocol originally proposed by Zohar and
Sompolinsky.
Ethereum uses a simpler version of this protocol, where the chain that has most computational effort spent
on it in order to build it is identified as the definite version. Another way of looking at it is to find the longest
chain, as the longest chain must have been built by consuming adequate mining effort. Greedy Heaviest
Observed Subtree (GHOST) was first introduced as a mechanism to alleviate the issues arising out of fast
block generation times that led to stale or orphan blocks. In GHOST, stale blocks are added in calculations
to figure out the longest and heaviest chain of blocks. Stale blocks are called Uncles or Ommers in Ethereum.

The following diagram shows a quick comparison between the longest and heaviest chain:

ABHISHEK K L Assistant Professor Department of AIML

Module-I Blockchain 101

World State
This mapping is a data structure that is serialized using Recursive Length Prefix (RLP). RLP is a specially
developed encoding scheme that is used in Ethereum to serialize binary data for storage or transmission over
the network and also to save the state in a Patricia tree.

Accounts trie (storage contents of account), account tuple, world state trie, and state root hash and their relationship

The world state and its relationship with accounts trie, accounts, and block header can be visualized in the
above diagram. It shows the account data structure in the middle of the diagram, which contains a storage
root hash derived from the root node of the account storage trie shown on the left. The account data structure
is then used in the world state trie, which is a mapping between addresses and account states. Finally, the
root node of the world state trie is hashed using the Keccak 256-bit algorithm and made part of the block
header data structure.

1. Accounts
 The world state is essentially a mapping of Ethereum addresses to their respective account data.
There are two types of accounts in Ethereum:
i. Externally Owned Accounts (EOAs): Controlled by private keys and primarily used by
users.
ii. Contract Accounts: Controlled by the code they contain (smart contracts).
 Account Fields: Each account in the world state contains the following fields:
o Nonce: A counter that tracks the number of transactions sent from the account. For contract
accounts, it tracks the number of contracts created by the account.
o Balance: The amount of Ether (ETH) owned by the account, stored in Wei (the smallest unit of
Ether).
o StorageRoot: A 256-bit hash pointing to the root of another Merkle Patricia Trie, which
contains the account's storage data. This field is relevant only for smart contract accounts. For
EOAs, this is typically empty.
o CodeHash: A 256-bit hash of the bytecode for smart contracts. For EOAs, this is the hash of an
empty string since they do not have associated code. The code itself is stored separately in the
Ethereum state database and referenced by this hash.
o
2. Account Trie (Storage Trie)
 Accounts trie is basically a Merkle Patricia tree used to encode the storage contents of an account. The
contents are stored as a mapping between keccak 256-bit hashes of 256-bit integer keys to the RLP-
encoded 256-bit integer values.
 The Account Trie in Ethereum, also known as the storage trie, is a Merkle Patricia Trie used to store the
data associated with smart contract accounts. Each smart contract has its own storage trie, and the root
of this trie is stored in the contract's account data in the World State Trie.
 The structure of the Account Trie is quite similar to the general structure of a Merkle Patricia Trie (MPT)
used for Ethereum's World State.

ABHISHEK K L Assistant Professor Department of AIML

Module-I Blockchain 101

3. World State Trie

The world state trie is a Merkle Patricia Trie (MPT) that represents the entire Ethereum world state
at any given block. It maps Ethereum account addresses (keys) to their corresponding account data
(values).

 Key: The Ethereum account address (160-bit hash).

 Value: The account data, which includes fields such as nonce, balance, storageRoot, and
codeHash.

4. State Root Hash

The root hash of the world state trie, called the state root, is stored in the block header, ensuring the
integrity of the block chain’s state.

Transactions
A transaction in Ethereum is a digitally signed data packet using a private key that contains the instructions
that, when completed, either result in a message call or contract creation. Transactions can be divided into
two types based on the output they produce:
1. Message call transactions: This transaction simply produces a message call that is used to pass messages
from one account to another. message call requires several parameters for execution, which are listed as
follows:
 Sender
 The transaction originator
 Recipient
 The account whose code is to be executed
 Available gas
 Value
 Gas price
 Arbitrary length byte array
 Input data of the call
 Current depth of the message call/contract creation stack

 Message calls result in state transition. Message calls also produce output data, which is not used if
transactions are executed. In cases where message calls are triggered by VM code, the output produced
by the transaction execution is used.

2. Contract creation transactions: As the name suggests, these transactions result in the creation of a new
contract. This means that when this transaction is executed successfully, it creates an account with the
associated code. There are a few essential parameters that are required when creating an account. These
parameters are listed as follows:
 Sender
 Original transactor
 Available gas
 Gas price
 Endowment, which is the amount of ether allocated initially
 A byte array of arbitrary length
 Initialization EVM code
 Current depth of the message call/contract-creation stack (current depth means the number of items
that are already there in the stack)
 Addresses generated as a result of contract creation transaction are 160-bit in length.
 The account is initialized when the EVM code (Initialization EVM code) is executed. In the case of
any exception during code execution, such as not having enough gas, the state does not change.

ABHISHEK K L Assistant Professor Department of AIML

Module-I Blockchain 101

 If the execution is successful, then the account is created after the payment of appropriate gas costs.
The current version of Ethereum (homestead) specifies that the result of contract transaction is either
a new contract with its balance, or no new contract is created with no transfer of value.

In the following diagram, the segregation between two types of transaction is shown:

Both of these transactions are composed of a number of common fields, which are described here.
Nonce
Nonce is a number that is incremented by one every time a transaction is sent by the sender. It must be equal
to the number of transactions sent and is used as a unique identifier for the transaction. A nonce value can
only be used once.
gasPrice
The gasPrice field represents the amount of Wei required in order to execute the transaction.
gasLimit
The gasLimit field contains the value that represents the maximum amount of gas that can be consumed in
order to execute the transaction. The concept of gas and gas limit will be covered later in the chapter in more
detail. For now, it is sufficient to say that this is the amount of fee in Ether that a user (for example, the
sender of the transaction) is willing to pay for computation.
To
As the name suggests, the to field is a value that represents the address of the recipient of the transaction.
Value
Value represents the total number of Wei to be transferred to the recipient; in the case of a contract account,
this represents the balance that the contract will hold.
Signature
Signature is composed of three fields, namely v, r, and s. These values represent the digital signature (R, S)
and some information that can be used to recover the public key (V). Also of the transaction from which the
sender of the transaction can also be determined. The signature is based on ECDSA scheme and makes use
of the SECP256k1 curve. The equation is as follows:
ECDSASIGN (Message, Private Key) = (V, R, S)

Init
The Init field is used only in transactions that are intended to create contracts. This represents a byte array of
unlimited length that specifies the EVM code to be used in the account initialization process. The code
contained in this field is executed only once, when the account is created for the first time, and gets destroyed
immediately after that. Init also returns another code section called body, which persists and runs in response
to message calls that the contract account may receive. These message calls may be sent via a transaction or
an internal code execution.

ABHISHEK K L Assistant Professor Department of AIML

Module-I Blockchain 101

Data
If the transaction is a message call, then the data field is used instead of init, which represents the input data
of the message call. It is also unlimited in size and is organized as a byte array. This can be visualized in the
following diagram, where a transaction is a tuple of the fields mentioned earlier, which is then included in a
transaction trie (a modified Merkle-Patricia tree) composed of the transactions to be included. Finally, the
root node of transaction trie is hashed using a Keccak 256-bit algorithm and is included in the block header
along with a list of transactions in the block.

Transactions can be found in either transaction pools or blocks. When a mining node starts its operation of
verifying blocks, it starts with the highest paying transactions in the transaction pool and executes them one
by one. When the gas limit is reached or no more transactions are left to be processed in the transaction pool,
the mining starts. In this process, the block is repeatedly hashed until a valid nonce is found that, once hashed
with the block, results in a value less than the difficulty target. Once the block is successfully mined, it will
be broadcasted immediately to the network, claiming success, and will be verified and accepted by the
network. This process is similar to Bitcoin's mining process discussed in the previous chapter. The only
difference is that Ethereum's Proof of Work algorithm is ASIC-resistant, known as Ethash, where finding a
nonce requires large memory.

Fig: Relationship between transaction, transaction trie and block header

ABHISHEK K L Assistant Professor Department of AIML

Module-I Blockchain 101

Ethereum virtual machine (EVM)

 EVM is a simple stack-based execution machine that runs bytecode instructions in order to transform
the system state from one state to another.
 The word size of the virtual machine is set to 256-bit. The stack size is limited to 1024 elements and
is based on the LIFO (Last in First Out) queue.
 EVM is a Turing-complete machine but is limited by the amount of gas that is required to run any
instruction.
 EVM also supports exception handling in case exceptions occur, such as not having enough gas or
invalid instructions, in which case the machine would immediately halt and return the error to the
executing agent.

EVM operation
 EVM is a fully 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.
 There are two types of storage available to contracts and EVM. The first one is called memory, which
is a byte array. When a contract finishes the code execution, the memory is cleared. It is akin to the
concept of RAM. The other type, called storage, is permanently stored on the blockchain. It is a key
value store.
 The storage associated with the virtual machine is a word addressable word array that is nonvolatile
and is maintained as part of the system state.
 Keys and value are 32 bytes in size and storage. The program code is stored in a virtual readonly
memory (virtual ROM) that is accessible using the CODECOPY instruction. The CODECOPY
instruction is used to copy the program code into the main memory. Initially, all storage and memory
is set to zero in the EVM.
 The following diagram shows the design of the EVM where the virtual ROM stores the program code
that is copied into main memory using CODECOPY.
 The main memory is then read by the EVM by referring to the program counter and executes
instructions step by step. The program counter and EVM stack are updated accordingly with each
instruction execution.

 EVM optimization is an active area of research and recent research has suggested that EVM can be
optimized and tuned to a very fine degree in order to achieve high performance. Research into the
possibility of using Web assembly (WASM) is underway already.
 The aim of WASM is to be able to run machine code in the browser that will result in execution at
native speed. Similarly, the aim of EVM 2.0 is to be able to run the EVM instruction set (Opcodes)
natively in CPUs, thus making it faster and efficient.

ABHISHEK K L Assistant Professor Department of AIML

Module-I Blockchain 101

Execution environment
There are some key elements that are required by the execution environment in order to execute the code.
The key parameters are provided by the execution agent, for example, a transaction. These are listed as
follows:
1. The address of the account that owns the executing code.
2. The address of the sender of the transaction and the originating address of this execution.
3. The gas price in the transaction that initiated the execution.
4. Input data or transaction data depending on the type of executing agent. This is a byte array; in the
case of a message call, if the execution agent is a transaction, then the transaction data is included as
input data.
5. The address of the account that initiated the code execution or transaction sender. This is the address
of the sender in case the code execution is initiated by a transaction; otherwise, it's the address of the
account.
6. The value or transaction value. This is the amount in Wei. If the execution agent is a transaction, then
it is the transaction value.
7. The code to be executed presented as a byte array that the iterator function picks up in each execution
cycle.
8. The block header of the current block
9. The number of message calls or contract creation transactions currently in execution. In other words,
this is the number of CALLs or CREATEs currently in execution.

The execution environment can be visualized as a tuple of nine elements, as follows:

ABHISHEK K L Assistant Professor Department of AIML

Module-I Blockchain 101

Machine state
 Machine state is also maintained internally by the EVM.
 Machine state is updated after each execution cycle of EVM.
 Iterator function runs in the virtual machine, which outputs the results of a single cycle of the state
machine.
 Machine state is a tuple that consist of the following elements:
 Available gas
 Program counter, which is a positive integer up to 256
 Memory contents
 Active number of words in memory
 Contents of the stack
 EVM is designed to handle exceptions and will halt (stop execution) in case any of the following
exceptions occur:
 Not having enough gas required for execution
 Invalid instructions
 Insufficient stack items
 Invalid destination of jump op codes
 Invalid stack size (greater than 1024)

The iterator function

 Iterator function performs various important functions that are used to set the next state of the machine
and eventually the world state.
 These functions include the following:
 It fetches the next instruction from a byte array where the machine code is stored in the execution
environment.
 It adds/removes (PUSH/POP) items from the stack accordingly.
 Gas is reduced according to the gas cost of the instructions/Opcodes.
 It increments the program counter (PC).

Machine state can be viewed as a tuple

ABHISHEK K L Assistant Professor Department of AIML

Module-I Blockchain 101

Practice Questions
1. Define Transaction in Bitcoin. Elaborate Bitcoin Transaction life cycle.
2. Illustrate the working of Ethereum virtual machine with diagram.
3. What is mining with reference to blockchain? List the tasks of miners and discuss the steps of mining
algorithm with the help of a flowchart.
4. Describe the process of generating Bitcoin addresses using cryptography and hashing.
5. Define Smart Contract. Enumerate the properties of smart contract.
6. Discuss the bowtie model which is used to illustrate the flow of Ricardian contracts from the world of law
to the world of accounting.
7. What are the two types of transactions in Ethereum? Explain the common fields and parameters composed by
both of these transactions.

ABHISHEK K L Assistant Professor Department of AIML