Public Blockchain

Rupesh Mishra
Introduction to Blockchain

1. Test-networks
1. Public Blockchain 2. Metamask, Mist Wallet,
2. Ethereum and its Components 3. Ethereum frameworks
3. Ethereum Virtual Machine 4. Study of
4. Transaction, Accounts a. Ganache
5. Architecture and Workflow b. etherscan.io
6. Bitcoin and Ethereum c. ether
5. block structure

2 rupeshmishra@sfit.ac.in
Public blockchain

● Permissionless ● Ethereum - The World Computer

✓ Transection ✓ Virtual Machine
✓ Mining ■ Globally accessible singleton
● Anonymity state
✓ Executes Smart Contract
● Transparency
✓ Blockchain
● Auditable ■ Store and Synchronise the
● Immutable change of state
● Neutral ✓ Execution resource utilisation
● Low Scalability cost is measured with Ether
● Decentralised ✓ Build DApp
■ Censorship Resistance
■ Counterparty Risk

3 rupeshmishra@sfit.ac.in
Ethereum Component
● P2P Network ● State Machine
✓ Ethereum Main Network ✓ Virtual Machine
✓ TCP port 3030 ✓ Stack Based
✓ DEVp2p Protocol ✓ Smart contract in HLL
● Consensus Rule ✓ Executes Bytecode
● Transection (3) ● Data Structure
✓ Sender ✓ LevelDB
✓ Receiver ✓ Merkle Tree
✓ Value ● Client
✓ Data ✓ Geth

4 rupeshmishra@sfit.ac.in
 LoremAccount
Ipsum

● Two types
● Same for EVM
EOA
Lorem Ipsum CA
Lorem Ipsum ● Account Balance
✓ Modified by
● Owned by Code Transections
● Owned by User
Stored ● Storage
Private Key
Not Free ✓ key-value store
● Free ●
mapping
● Tx activated by user ● Tx activated by EOA
✓ 256-bit words to
● Call EOA and CA ● Call other CA
256-bit words
● Private Key requires ● Private Key not used

5 rupeshmishra@sfit.ac.in
Wallet - A Generic Program

20 Deploy
Byte Smart
Contract

Address

256
bit

Ke vate s
i e
Pr tor
Query Blockchain to

S
compute Account

y
Balance

6 rupeshmishra@sfit.ac.in
Ethereum Architecture and Ecosystem

Level
Internet
Local Blockchain Storage
DApp user Block Data - Contract Code DB
Node1 Node2

Eth Client
user JSON Ethereum Syncing with other node
Web 3 Node3 Node4
RPC Client

Eth Smart
Contract Node ● Node Runs EVM
User ● Mining
● Executes transaction for
validation

Wallet User

7 rupeshmishra@sfit.ac.in
 Ethereum Architecture
Users

Level
Internet
Local Blockchain Storage
DApp user Block Data - Contract Code DB
Node1 Node2

Eth Client
user JSON Ethereum Syncing with other node
Web 3 Node3 Node4
RPC Client

Eth Smart
Contract Node ● Node Runs EVM
User ● Mining
● Executes transaction for
validation

Wallet User

8 rupeshmishra@sfit.ac.in
 Nonce Transaction
Gas Price

Gas Limit Tx Pool

Block
To

Value Transaction Validation

V, R, S
✓ RLP - Encoded
Init or Data
✓ Valid Digital Signature
1. Tx Created by the user and sent to tx Pool ✓ Tx Nonce = sender's account
2. Waiting for Verification in Tx Pool current nonce
3. Mining Node pick highest paying tx from the
pool and execute ✓ Gas limit > gas consumed by
4. After successful verification add into block the transection
and mine new block
5. Broadcast it to the network ✓ Sufficient balance (sender's
6. Verified and Accepted by network account) to cover the cost
9 rupeshmishra@sfit.ac.in
 ● Block Validation
✓ Timestamp older than parent
✓ Too many uncle (max 2)
✓ Duplicate uncle
✓ Uncle is ancestor
✓ Uncles parent is not an ancestor
✓ Non positive difficulty
✓ Invalid mix digest
✓ Invalid PoW
● Block Finalization
✓ Ommers Validation
✓ Transaction Validation
✓ Reward Application
✓ State and Nonce validation

10 rupeshmishra@sfit.ac.in
 1. New Block Received by node
2. New MPT Constructed
a. All Transaction from the block
is executed
b. New Tx receipt generated and
organised in MPT
c. Global state is modified
accordingly
3. If New MPT roots match with
the received Block is Valid
a. New Tx, Receipt, State tries
Genesis
Block are included in the local
blockchain

11 rupeshmishra@sfit.ac.in
● A message that is sent from one ● Target Contract Account
account to another account ✓ Code is executed
● Include data and Ether ✓ Payload provided as input data
● Signature
● New contract
✓ secp256k1 curve
✓ Target Account null
✓ ECDSA Sign(message, Private Key) =
(V,R,S) ✓ The payload of a contract creation

✓ V : To recover Pub Key from Pr Key, transaction executed by EVM

Depict the size and sign of the elliptic ✓ The output data of execution is permanently
curve point
stored as the contract code
✓ Signature (R,S) : S is calculated by
● Modified Merkle-Patricia Tree (MPT)
multiplying R with the Pr Key and adding
it into the hash and divide using random ✓ Transaction Tries
number selected to calculate R
● Keccak256 to compute Tx Root Hash

12 rupeshmishra@sfit.ac.in
Gas
● Contract creation transaction is charged with a amount of gas
✓ To limit the amount of work that is needed to execute the transaction
✓ To pay for execution
● EVM executes the transaction → the gas is gradually depleted
● The gas price value set by the creator of the transaction
● Sending account to pay → gas_price * gas
● Gas Limit
✓ An out-of-gas exception
✓ Reverts all modifications made to the state in the current call frame
● Remaining gas after execution is refunded to the creator

13 rupeshmishra@sfit.ac.in
EVM
● Ethereum Virtual Machine ● Storage
✓ Runtime Environment for ✓ Persistent between function call
Ethereum Smart Contract ✓ Key Value Pair
✓ sandboxed and completely ✓ Costly (Read, Write, Initialize)
isolated ✓ Contract access for R/W only its
✓ Limited access to another own storage
Smart Contracts ● Memory
✓ RLP Encoding ✓ Fresh instance each call
● Stack(256*1024) ✓ Linear
✓ Stack not Register Machine ✓ Addressed at Byte Level
✓ Computation performed on ✓ Read(256) Write(8 to 256) bits
stack data ✓ Expanded by Word(256)
■ Copy one of top 16 element ✓ Cost increases with increase in
Swap top with bellow 16
■
size (scales quadratically)
■ Operation top 2 (2nd Optional)

15 rupeshmishra@sfit.ac.in
Machine State
Available Gas

Prog Counter

Memory Content

Number of Words

Stack Content

16 rupeshmishra@sfit.ac.in
 Add Code Owner

Execution Environment Sender Address

Gas Price

Input Data

Initiator Address

Value

Bytecode

Block Header

Message call depth

Permission

17 rupeshmishra@sfit.ac.in
● Instruction Set
✓ Minimal set of Instruction to avoid inconsistency which may lead to
consensus problem
✓ Operates on data type, 256 bit words and memory slice
✓ Arithmetic, bit, logical, comparison operations
✓ Contracts can access relevant properties of the current block
■ Block number
■ Timestamp, etc
✓ Conditional and Unconditional Jump
● Message Calls
✓ Message calls are similar to transactions
■ Sender
■ A target,
■ Data payload,
■ Ether
■ gas price and limit
■ return data.

18 rupeshmishra@sfit.ac.in
● Message Calls
✓ Contracts can call other contracts
✓ Send Ether to non-contract accounts
✓ A contract can decide its remaining gas should be sent with the inner
message call and how much to retain
✓ Exception in the inner call signaled by an error value from the stack.
✓ Only the gas sent with the call is used up
✓ The called contract receive a freshly cleared instance of memory
✓ It has access to the call payload from calldata
✓ It can return data to the caller
✓ Fully synchronous.
✓ Calls are limited to a depth of 1024,
■ loops should be preferred over recursive calls

19 rupeshmishra@sfit.ac.in
● Delegatecall
✓ Special Message Call
✓ Code executed at the target address in the context of the calling contract
✓ No change in the value of msg.sender and msg.value
✓ Contract can dynamically load code from a different address at runtime
✓ Storage, current address and balance still refer to the calling contract,
✓ Only the code is taken from the called address
✓ Library Feature
✓ Reusable library code that can be applied to a contract’s storage

20 rupeshmishra@sfit.ac.in
● Log ● Create
✓ Indexed data structure ✓ Contracts can create other contracts
✓ Store data maps up to the ✓ The payload data is executed and
block level the result stored as code
✓ Used to implement events ✓ The caller / creator receives the
address of the new contract
✓ Contracts cannot access log
● Deactivate and Self-destruct
data
✓ To remove code from the blockchain
✓ Accessed from outside the
✓ self destruct operation
blockchain.
■ Ether stored at that address is
✓ Some part of the log data is
sent to a designated target
stored in bloom filters, for
■ The storage and code is
efficient and cryptographically removed from the state
secure searching ✓ Ether sent to removed contracts is
✓ light clients” find these logs. forever lost.

21 rupeshmishra@sfit.ac.in
Nodes and Miners
● Nodes ● PoS Algorithm → Casper with
✓ Wallet the release of Serenity
✓ Light Client ✓ Node → Bonding Validator
✓ Full Node ● Consensus Mechanism
● Mining Node ✓ Greedy Heaviest Observed
✓ Ether in reward for validation Subtree (GHOST) Protocol
✓ Heaviest Chain
and verification of blocks
● Supporting Protocol
made up of transactions
✓ Whisper
✓ Determine ommer block and ■ Decentralised Messaging
include them in the chain ✓ Swarm
● PoW Algorithm → Ethash ■ Decentralised Storage

22 rupeshmishra@sfit.ac.in
Ganache
 ● Ganache is available in
two varieties:
○ UI : A desktop
application
○ CLI : Command-line
tool (previously
known as the
TestRPC)
● Work with Ethereum.
● Available for Windows,
Linux, and Mac.

24 rupeshmishra@sfit.ac.in
Introduction ● Features
✓ Transactions are “mined”
● Personal Blockchain instantly.
✓ No transaction cost
● Development of Ethereum
✓ Accounts can be recycled, reset
applications
and instantiated with a fixed
● To build, test and deploy
amount of Ether
dApps in a secure and ✓ no need for faucets or mining
predictable environment ✓ Gas price and mining speed can
● Ganache is used to make a be modified.
personal Ethereum Blockchain ✓ A convenient GUI gives overview
for testing Solidity contracts of test chain events

25 rupeshmishra@sfit.ac.in
Ethereum 2.0
Introduction
● Ethereum 1.0 ● Trilemma
● World Computer ✓ Decentralisation
■ Anyone can join, access and use
✓ Decentralised
the network
✓ Censorship resistant ✓ Scalability
● Problem for Mass Adoption ■ High Performance
■ Efficiency
✓ Scalability ■ Flexibility
✓ Security ✓ Security
✓ Performance ■ Consistency
■ Resilience to nw partition

27 rupeshmishra@sfit.ac.in
Ethereum 2.0 ● Solution
✓ Proof of Stake
■ Validator and Staking

✓ Sharding
■ Side chain
■ Privacy
■ Shard chain - Beacon node -
Beacon chain

✓ Ewasm
■ Efficient EVM
■ Improved performance
■ Fast Execution

28 rupeshmishra@sfit.ac.in
● Beacon Chain ● Functions
✓ Core System chain ✓ Select Block Proposer and
Attestation committee
✓ Backbone of entire Ethereum
✓ Rules and Provision of Attestation
2.0 chain system
■ Availability of votes in a shard chain
● Operate with main chain in ■ Adequate number of attestation for a
shard block will create cross link
parallel before merge ■ Provide confirmation for shard block in
the beacon chain
● Casper PoS consensus
✓ Validator and stake management
● Includes Registry of Validators ✓ Provision of validator set for
● Shard write their states to voting on proposed block
✓ Provision of consensus, reward
enable cross shard transaction
and penalty

29 rupeshmishra@sfit.ac.in
● Beacon Node ● Validator Node
● Synchronise beacon chain with ✓ Participate in consensus
mechanism
other peers
✓ 32 Ether stake
● Listen to Deposit Event ■ Receive reward if attestation accepted

● Random validator assignment ■ Penalise for inactivity and slashed for

dishonest act
● Create and manage validator set ✓ Function
● Attestation of Block ■ Connect with beacon chain
■ Propose new block
✓ Provide critical information to ■ Block attestation
validator regarding attestation of ■ Attestation aggregation
■ Shard chain synchronisation with beacon
assigned block
chain

30 rupeshmishra@sfit.ac.in
 Vestibulum
Activated
congue

Vestibulum Vestibulum
Pending Slashed
congue congue
Deposited

Vestibulum Vestibulum
Exited
congue
Withdrawable congue

31 rupeshmishra@sfit.ac.in
Whistleblowing Validator
● Reports for penalization and slashing
● Slashin
✓ Validator attest two different version of chain
✓ Confusion in the system that which chain is actually supported by
validator
■ Sign two different blocks in same epoch
■ Sign two different conflicting attestation
■ Sign attestation surrounds another attestation
● Penalization
✓ Inactivity in the network

32 rupeshmishra@sfit.ac.in
● Shard Chain ● Deposit contract created in
✓ Scalability Ethereum 1.0 used to deposit
✓ 64 chain
ether on beacon chain
● Crosslink
● Event emitted every time
✓ Set of attestation signatures
from set of validator of block deposit is done
on shard chain ● LMD GHOST for fork handling
✓ State of shard chain is ✓ Chain with most attestation
periodically written in beacon and stake
chain
● Casper FFG
✓ State is combined data merkle
✓ Maintain chain integrity
root of shard chain
✓ Block on shard chain is also ● Merging
considered as final for cross ✓ Ethereum 1.0 chain will be
shard transaction merged into Ethereum 2.0

33 rupeshmishra@sfit.ac.in