0% found this document useful (0 votes)
10 views62 pages

Module 5 Miss

The document provides an overview of Ethereum, detailing its blockchain structure, state transition functions, and the role of Ether as its cryptocurrency. It explains the user perspective on transactions, the Ethereum network's components, and the distinction between Externally Owned Accounts and Contract Accounts. Additionally, it covers the Ethereum Virtual Machine (EVM) and its function in executing smart contracts and managing blockchain state.

Uploaded by

777amru
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
10 views62 pages

Module 5 Miss

The document provides an overview of Ethereum, detailing its blockchain structure, state transition functions, and the role of Ether as its cryptocurrency. It explains the user perspective on transactions, the Ethereum network's components, and the distinction between Externally Owned Accounts and Contract Accounts. Additionally, it covers the Ethereum Virtual Machine (EVM) and its function in executing smart contracts and managing blockchain state.

Uploaded by

777amru
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd
You are on page 1/ 62

Module 5

Ethereum
Major upgrades of Ethereum
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.
Ethereum state transition function

• In the preceding example, a transfer of two ether from address 4718bf7a to


address 741f7a2 is initiated.
• The initial state represents the state before the transaction execution, and the final
state is what the morphed state looks like.
• The state is stored on the Ethereum network as the world state.
• This is the global state of the Ethereum blockchain.
Ethereum
• Ethereum is a decentralized blockchain platform that establishes a
peer-to-peer network that securely executes and verifies application
code, called smart contracts.
• Ether:
• A cryptocurrency is a medium of exchange secured by a blockchain-
based ledger.
• The first cryptocurrency was Bitcoin, created by Satoshi Nakamoto
• Ether (ETH) is the cryptocurrency used in Ethereum network
Ether cryptocurrency/tokens (ETC and ETH)
• As an incentive to the miners, Ethereum rewards its own native currency called
ether (abbreviated as ETH).
• There are now two Ethereum blockchains: one is called Ethereum Classic, and its
currency is represented by ETC, whereas the hard-forked version is ETH, which
continues to grow and on which active development is being carried out.
• Ether is minted by miners as a currency reward for the computational effort they
spend to secure the network by verifying transactions and blocks.
• Ether is used within the Ethereum blockchain to pay for the execution of contracts
on the EVM.
• Ether is used to purchase gas as crypto fuel, which is required to perform
computation on the Ethereum blockchain.
Ethereum – a user's perspective
• The most common use case of fund transfer is presented step-by-step:
1. First, either a user requests money by sending the request to the sender, or the sender
decides to send money to the receiver.
2. Jaxx Ethereum wallet software on iOS – can be used : https://jaxx.io.
3. The request can be sent by sending the receiver's Ethereum address to the sender.
4. For example, there are two users, A and B.
5. If B requests money from A, then she can send a request to A by using a QR code.
6. Once A receives this request he will either scan the QR code or manually type in B’s
Ethereum address and send the ether to B's address.
7. This request is encoded as a QR code, shown in the following screenshot, that can be
shared via email, text, or any other communication method:
Ethereum – a user's perspective
2. Once A receives this request he will either scan this QR code or copy the Ethereum
address in the Ethereum wallet software and initiate a transaction.
• This process is shown in the following screenshot, where Jaxx is used to send money
to B.
• The following screenshot shows that the sender has entered both the amount and the
destination address to send the ether to receiver.
• Just before sending the ether, the final step is to confirm the transaction.
Confirmation of funds sent in the Jaxx
wallet from A
Ethereum – a user's perspective
3. Once the request (transaction) for money to be sent is constructed in the wallet
software, it is then broadcasted to the Ethereum network.
• The transaction is digitally signed by the sender as proof that he is the owner of
the ether.
4. This transaction is then picked up by nodes called miners on the Ethereum
network for verification and inclusion in the block. At this stage, the transaction is
still unconfirmed.
5. Once it is verified and included in the block, the PoW process starts.
6. Once a miner finds the answer to the PoW problem by repeatedly hashing the
block with a new nonce, this block is immediately broadcasted to the rest of the
nodes, which then verifies the block and PoW.
Ethereum – a user's perspective
7. If all the checks pass then this block is added to the blockchain, and miners are
paid rewards accordingly.
8. Finally, B gets the ether, and it is shown in her wallet software.

The transaction received in B's blockchain


wallet
Ethereum – a user's perspective
• The details of this transaction can be visualized on the block explorer at
https://etherscan.io/, as shown in the following screenshot:
The Ethereum network
• The Ethereum network is a peer-to-peer network where nodes participate in order
to maintain the blockchain and contribute to the consensus mechanism.
• Networks can be divided into three types, based on the requirements and usage.
• These types are described in the following subsections.
• The mainnet
• The mainnet is the current live network of Ethereum.
• Testnets
• There is a number of testnets available for Ethereum testing.
• The aim of these test blockchains is to provide a testing environment for smart
contracts and DApps before being deployed to the production live blockchain.
• Ropsten, Kovan and Rinkeby
The Ethereum network
• Private nets
• As the name suggests, these are private networks that can be created by generating
a new genesis block.
• This is usually the case in private blockchain networks, where a private group of
entities start their blockchain network and use it as a permissioned or consortium
blockchain.
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.
Components of the Ethereum ecosystem
• 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
Keys and addresses
• Keys and addresses are used in the Ethereum blockchain to represent ownership
and transfer ether.
• The keys used are made up of pairs of private and public parts.
• The private key is generated randomly and is kept secret, whereas a public key is
derived from the private key.
• Addresses are derived from public keys and are 20-byte codes used to identify
accounts.
Keys and addresses
• The process of key generation and address derivation is as follows:
1. First, a private key is randomly chosen (a 256-bit positive integer) under the rules
defined by the elliptic curve secp256k1 specification (in the range [ 1 , secp256k1n −1 ]).
2. The public key is then derived from this private key using the Elliptic Curve Digital
Signature Algorithm (ECDSA) recovery function.
3. An address is derived from the public key, specifically, from the rightmost 160 bits of
the Keccak hash of the public key.
• An example of how keys and addresses look in Ethereum is shown as follows:
• A private key:
b51928c22782e97cca95c490eb958b06fab7a70b9512c38c36974f47b954ffc4
• A public key:
3aa5b8eefd12bdc2d26f1ae348e5f383480877bda6f9e1a47f6a4afb35cf998ab847
f1e3948b1173622dafc6b4ac198c97b18fe1d79f90c9093ab2ff9ad99260
• An address:
0x77b4b5699827c5c49f73bd16fd5ce3d828c36f32
Accounts
• Accounts are one of the main building blocks of the Ethereum blockchain.
• They are defined by pairs of private and public keys.
• Accounts are used by users to interact with the blockchain via transactions.
• A transaction is digitally signed by an account before submitting it to the network
via a node.
• Ethereum, being a transaction-driven state machine, the state is created or
updated as a result of the interaction between accounts and transaction executions.
• All accounts have a state that, when combined together, represents the state of the
Ethereum network.
• With every new block, the state of the Ethereum network is updated.
• Operations performed between and on the accounts represent state transitions.
Accounts

• The state transition is achieved using what's called the Ethereum state transition function,
which works as follows:
1. Confirm the transaction validity by checking the syntax, signature validity, and nonce.
2. The transaction fee is calculated, and the sending address is resolved using the signature.
Furthermore, the sender's account balance is checked and subtracted accordingly, and the
nonce is incremented. An error is returned if the account balance is insufficient.
3. Provide enough ETH (the gas price) to cover the cost of the transaction. This is charged per
byte and is incrementally proportional to the size of the transaction. In this step, the actual
transfer of value occurs. The flow is from the sender's account to the receiver’s account.
The account is created automatically if the destination account specified in the transaction
does not exist yet. Moreover, if the destination account is a contract, then the contract code is
executed. This also depends on the amount of gas available. If enough gas is available, then
the contract code will be executed fully; otherwise, it will run up to the point where it runs out
of gas.
Accounts
4. In cases of transaction failure due to insufficient account balance or gas, all state
changes are rolled back except for the fee payment, which is paid to the miners.
5. Finally, the remainder (if any) of the fee is sent back to the sender as change and
the fee is paid to the miners accordingly. At this point, the function returns the
resulting state, which is also stored on the blockchain.
Types of accounts

• Two kinds of accounts exist in Ethereum:


• Externally Owned Accounts (EOAs)
• Contract Accounts (CAs)
• The first type is EOAs, and the other is CAs.
• EOAs are similar to accounts that are controlled by a private key in Bitcoin.
• CAs are the accounts that have code associated with them along with the private
key.
EOA’s
• They have a state.
• They are associated with a human user, hence are also called user accounts.
• EOAs have an ether balance.
• They are capable of sending transactions.
• They have no associated code.
• They are controlled by private keys.
• EOAs cannot initiate a call message.
• Accounts contain a key-value store.
• EOAs can initiate transaction messages.
CAs

• They have a state.


• They are not intrinsically associated with any user or actor on the
blockchain. CAs have an ether balance.
• They have associated code that is kept in memory/storage on the
blockchain. They have access to storage.
• They can get triggered and execute code in response to a transaction or
a message from other contracts. It is worth noting that due to the
Turing-completeness property of the Ethereum blockchain, the code
within CAs can be of any level of complexity.
CAs
• The code is executed by the EVM by each mining node on the
Ethereum network.
• Also, CAs can maintain their permanent states and can call other
contracts.
• CAs cannot start transaction messages.
• CAs can initiate a call message.
• CAs contain a key-value store.
• CAs' addresses are generated when they are deployed. This address of
the contract is used to identify its location on the blockchain.
Transactions and messages

• 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:
• Message call transactions: This transaction simply produces a message call that
is used to pass messages from one CA to another.
• Contract creation transactions: As the name suggests, these transactions result
in the creation of a new CA. This means that when this transaction is executed
successfully, it creates an account with the associated code.
Transactions and messages
• Field inside the transaction:
• Nonce: The 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. This is used for replay protection on the network.
• Gas price: The gas price field represents the amount of Wei required to execute
the transaction. In other words, this is the amount of Wei we are willing to pay for
this transaction. This is charged per unit of gas for all computation costs incurred
as a result of the execution of this transaction.
• Gas limit: The gas limit field contains the value that represents the maximum
amount of gas that can be consumed to execute the transaction.
• To: As the name suggests, the To field is a value that represents the address of the
recipient of the transaction. This is a 20 byte value.
Transactions and messages
• Value: Value represents the total number of Wei to be transferred to the recipient
• Signature: The 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).
• Init: The Init field is used only in transactions that are intended to create
contracts, that is, contract creation transactions. 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, it (init) gets destroyed immediately after
that. Init also returns another code section called the body, which persists and runs
in response to message calls that the CA may receive.
• Data: If the transaction is a message call, then the Data field is used instead of
init, and represents the input data of the message call. It is also unlimited in size
and is organized as a byte array.
Transactions and messages
• A transaction is a tuple of the fields mentioned earlier, which is then included in a
transaction trie (a modified Merkle-Patricia tree (MPT)) composed of the
transactions to be included.
• Finally, the root node of the 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
• A block is a data structure that contains batches of transactions.
• Transactions can be found in either transaction pools or blocks.
• In transaction pools, they wait for verification by a node, and in blocks, they are
added after successful verification.
• 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.
Transactions and messages
• In this process, the block is repeatedly hashed until a valid nonce is found, such
that once hashed with the block, it 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.
The Ethereum Virtual Machine (EVM)
• The Ethereum Virtual Machine (EVM) is a core piece of Ethereum that helps
power the blockchain and smart contracts. It is vital in assisting Ethereum to
achieve user adoption and decentralization.
• The Ethereum Virtual Machine (EVM) is the computation engine for Ethereum
that manages the state of the blockchain and enables smart contract functionality.
• EVM is contained within the client software
• The EVM participates in block creation and transaction execution. In block
creation, the EVM sets standards for managing the state from block to block.
These states are stored in a Merkle Patricia Trie
• The EVM is a simple stack-based execution machine that runs bytecode
instructions to transform the system state from one state to another.
• 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.
The Ethereum Virtual Machine (EVM)
• 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.
• Storage: The other type is called storage, which is a key-value store and is
permanently persisted on the blockchain
• Stack: EVM is a stack-based machine, and thus performs all computations in a
data area called the stack.
The Ethereum Virtual Machine (EVM)
• Diagram shows an EVM stack on the left side showing that elements are pushed
and popped from the stack.
• It also shows that a program counter is maintained, and is incremented with
instructions being read from the main memory.
• The main memory gets the program code from the virtual ROM/storage via the
CODECOPY instruction
Execution environment

• There are some key elements that are required by the execution environment to
execute the code.
• These are listed as follows:
• The system state.
• The remaining gas for execution.
• The address of the account that owns the executing code.
• The address of the sender of the transaction. This is the originating address of this
execution (it can be different from the sender).
• The gas price of the transaction that initiated the execution.
• 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.
Execution environment

• 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 is the address of the account.
• The value or transaction value. This is the amount in
Wei. If the execution agent is a transaction, then it is the
transaction value.
• The code to be executed presented as a byte array that
the iterator function picks up in each execution cycle.
• The block header of the current block.
• The number of message calls or contract creation
transactions (CALLs, CREATEs or CREATE2s) currently in
execution.
The machine state
• The machine state is a tuple that consists of the following elements:
• Available gas
• The program counter, which is a positive integer of up to 256
• The contents of the memory (a series of zeroes of size 2256)
• The active number of words in memory (counting continuously from position 0)
• The contents of the stack
• The EVM is designed to handle exceptions and will halt (stop execution) if any of
the following exceptions should occur:
• Not having enough gas required for execution
• Invalid instructions
• Insufficient stack items
• Invalid destination of jump opcodes
• Invalid stack size (greater than 1,024)
The iterator function

• The iterator function mentioned earlier performs various vital 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).
• The EVM is also able to halt in normal conditions if STOP , SUICIDE , or
RETURN opcodes are encountered during the execution cycle.
Blocks and 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
Blocks and blockchain
• 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.
Blocks and blockchain
• 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.
• 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.
• 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.
Blocks and blockchain
• Timestamp: The timestamp is the epoch Unix time of the time of
block initialization.
• 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, that adequate computational
effort (PoW) has been spent in order to create this block.
Blocks and blockchain
• The genesis block
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).
The block validation mechanism

• 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
Block finalization
• Block finalization is a process that is run by miners to validate the contents of the block and apply
rewards. It results in four steps being executed.
• These steps are described here in detail:
1. Ommers validation. In the case of mining, determine ommers. The validation process of the
headers of stale blocks checks whether the header is valid and whether the relationship between
the uncle and the current block satisfies the maximum depth of six blocks. A block can contain a
maximum of two uncles.
2. Transaction validation. In the case of mining, determine transactions. This process involves
checking whether the total gas used in the block is equal to the final gas consumption after the
final transaction, in other words, the cumulative gas used by the transactions included in the
block.
3. Reward application. Apply rewards, which means updating the beneficiary's account with a
reward balance.
4. State and nonce validation. Verify the state and block nonce. In the case of mining, compute a
valid state and block nonce.
Block finalization
We will also see how it is updated in the local blockchain:
1. When an Ethereum full node receives a newly mined block, the header and the
body of the block are detached from each other.
2. A new MPT is constructed that comprises all transactions from the block.
3. All transactions from this new MPT are executed one by one in a sequence. This
execution occurs locally on the node within the Ethereum Virtual Machine
(EVM). As a result of this execution, new transaction receipts are
generated that are organized in a new receipts MPT. Also, the
global state is modified accordingly, which updates the state
MPT (trie).
Block finalization
4. The root nodes of each respective trie, in other words, the state
root, transaction root, and receipts root are compared with the
header of the block that was split in the first step. If both the roots
of the newly constructed tries and the trie roots that already exist
in the header are equal, then the block is verified and valid.
5. Once the block is validated, new transaction, receipt, and state
tries are written into the local blockchain database.
Block difficulty mechanism
• Block difficulty is increased if the time between two blocks decreases, whereas it
decreases if the block time between two blocks increases.
• This is required to maintain a roughly consistent block generation time.
• The difficulty adjustment algorithm in Ethereum's Homestead release is as
follows:
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.
Gas

• 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.
Fee schedule
• Gas is charged in three scenarios as a prerequisite to the execution of
an operation:
• The computation of an operation
• For contract creation or message calls
• An increase in the use of memory
Tutorial
• Etherscan
• Difference between bitcoin and Ethereum

You might also like