3 Components of The Ethereum Ecosystem

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.
Prepared By Dr.Saranya K G
• 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.
Architecture
A formal list of all high-level elements present
in the Ethereum blockchain is presented here:
•Keys and addresses

•Accounts
•Transactions and messages
•Ether cryptocurrency/tokens
•The EVM
•Smart contracts
Keys and addresses
• Keys and addresses are used in Ethereum
blockchain mainly to represent ownership and
transfer of Ether.
• Keys are used in pairs of private and public type.
• The private key is generated randomly and is
kept secret whereas a
• public key is derived from the private key.
• Addresses are derived from the public keys
which are a 20-bytes code used to identify
accounts.
The process of key generation and address derivation is
described here:
1. First, a private key is randomly chosen (256 bits positive
integer) under the rules defined by elliptic curve
secp256k1 specification (in the range [1, secp256k1n − 1]).
2. The public key is then derived from this private key using
ECDSA recovery function.
3. An address is derived from the public key which is the

right most 160 bits of the Keccak hash of the public
key. Prepared By Dr.Saranya K G
An example of how keys and addresses look like in
Ethereum is shown here:
1. Private key:
b51928c22782e97cca95c490eb958b06fab7a70b95
12c38c36974f47b954ffc4
2. Public key:
3aa5b8eefd12bdc2d26f1ae348e5f383480877bda6f
9e1a47f6a4afb35cf998ab847f1e3948b1173622dafc
6b4ac198c97b18fe1d79f90c9093ab2ff9ad99260
3. Address:
0x77b4b5699827c5c49f73bd16fd5ce3d828c36f32
Accounts
• Accounts are one of the main building blocks of
the Ethereum blockchain.
• Ethereum, being a transaction driven state
machine, the state is created or updated as a
result of the interaction between accounts and
transaction execution.
• Operations performed between and on the
accounts, represent state transitions.
Ethereum state transition function, 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, sender's account balance is checked and
subtracted accordingly, and nonce is incremented.
An error is returned if the account balance is not enough.
3. Provide enough Ether (gas price) to cover the cost of the
transaction. This is charged per byte 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 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.
4. In cases of transaction failure due to insufficient
account balance or gas, all state changes are rolled
back except for 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 fee are 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)
• 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.
Properties of EOs:
• EOAs has ether balance

• They are capable of sending transactions
• They have no associated code
• They are controlled by private keys
• Accounts contain a key-value store
• They are associated with a human user
Properties of CAs:
• CAs have Ether balance.
• They have associated code that is kept in
memory/storage on the blockchain.
• 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 contract accounts can be
of any level of complexity.
• The code is executed by Ethereum Virtual Machine
(EVM) by each mining node on the Ethereum
network.
• Also, CAs can maintain their permanent state
and can call other contracts. It is envisaged
that in the serenity release, the distinction
between externally owned accounts and
contract accounts may be eliminated.
• They are not intrinsically associated with any
user or actor on the blockchain.
• CAs contain a key-value store.
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 contract account to
another.
• Contract creation transactions: As the name
suggests, these transactions result in the
creation of a new contract account.
• This means that when this transaction is executed
successfully, it creates an account with the
associated code.
Both of these transactions are composed of some standard 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. 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 you 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
• Wei is the smallest denomination of ether;
therefore, it is used to count ether.
• Gas limit: The gas limit field contains the value
that represents the maximum amount of gas
that can be consumed to execute the
transaction.
• 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. This is a 20-byte
value.
• 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, the sender of the
transaction can also be determined from
these values.
• The signature is based on ECDSA scheme and
makes use of the secp256k1 curve.
• In this section, ECDSA will be presented in the
context of its usage in Ethereum.
• ECDSASIGN (Message, Private Key) = (V, R, S)
• V is a single byte value that depicts the size and sign of
the elliptic curve point and can be either 27 or 28.
• V is used in the ECDSA recovery contract as a recovery
ID. This value is used to recover (derive) the public key
from the private key.
• In secp256k1, the recovery ID is expected to be either 0

or 1. In Ethereum, this is offset by 27.
• R is derived from a calculated point on the
curve. First, a random number is picked up,
which is multiplied by the generator of the
curve to calculate a point on the curve.
• The x coordinate part of this point is R.
• R is encoded as a 32-byte sequence.
• R must be greater than 0 and less than the
secp256k1n limit
(115792089237316195423570985008687907
8528375642790749043826051631415181614
94337).
• S is calculated by multiplying R with the
private key and adding it into the hash of the
message to be signed and by finally dividing it
by the random number chosen to calculate R.
• S is also a 32-byte sequence.
• R and S together represent the signature.
To sign a transaction,
the ECDSASIGN function is used, which takes
the message to be signed and the private key
as an input and produces V, a single byte value;
R, a 32-byte value, and S, another 32-byte
value.
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 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.
• 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.
The relationship between transaction,
transaction trie and block header
Refer Book
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. 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.
• 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 only difference is that Ethereum's PoW
algorithm is ASIC-resistant, known as Ethash,
where finding a nonce requires large memory.
Contract creation transaction
There are a few essential parameters that are required
when creating an account.
•Sender
•Original transactor (transaction originator)
•Available gas
•Gas price
•Endowment, which is the amount of ether allocated
•A byte array of an 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
Precisely, as defined in the yellow paper, they are
the rightmost 160-bits of the Keccak hash of the
RLP encoding of the structure containing only the
sender and the nonce.
• Initially, the nonce in the account is set to zero.
• The balance of the account is set to the value
passed to the contract.
• Storage is also set to empty.
• Code hash is Keccak 256-bit hash of the empty
string.
• The new account is initialized when the EVM code
(the Initialization EVM code, mentioned earlier) is
executed.
• In the case of any exception during code execution,
such as not having enough gas (running Out Of Gas,
OOG), the state does not change.
• If the execution is successful, then the account is
created after the payment of appropriate gas costs.
• Since the Ethereum (Homestead) is the result of a
contract creation transaction is either a new
contract with its balance or no new contract is
created with no transfer of value.
• This is in contrast to versions prior to Homestead,
where the contract would be created regardless of
the contract code deployment being successful or
not due to an out-of-gas exception.
Message call transaction
A message call requires several parameters for execution, which
are listed as follows:
•The sender
•The transaction originator
•Recipient
•The account whose code is to be executed (usually same as the
recipient)
•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 a state transition.
• The 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.
• As defined in the yellow paper, message call is the

act of passing a message from one account to
another.
• If the destination account has an associated EVM code, then
the virtual machine will start, upon the receipt of the
message to perform the required operations.
• If the message sender is an autonomous object (external
actor), then the call passes back any data returned from the
EVM operation.
• The state is altered by transactions.
• These are created by external factors and are signed and
then broadcasted to the Ethereum network.
• Messages are passed using message calls.

Messages
• Messages, as defined in the yellow paper, are the data and
value that are passed between two accounts.
• A message is a data packet passed between two accounts.
• This data packet contains data and value (amount of
ether).
• It can either be sent via a smart contract (autonomous

object) or from an external actor (externally owned
account) in the form of a transaction that has been digitally
signed by the sender.
• Contracts can send messages to other contracts.
Messages only exist in the execution environment and
are never stored.
• Messages are similar to transactions;
• however, the main difference is that they are produced

by the contracts, whereas transactions are produced by
entities external (externally owned accounts) to the
Ethereum environment.
A message consists of the components mentioned
here:
•The sender of the message
•Recipient of the message
•Amount of Wei to transfer and message to the contract

address
•Optional data field (Input data for the contract)

•The maximum amount of gas (startgas) that can be
consumed Prepared By Dr.Saranya K G
• Messages are generated when CALL or
DELEGATECALL opcodes are executed by the
code in execution by the contracts.
Types of transactions, required parameters for execution
The preceding diagram shows transaction types, which are divided into
two types
contract creation and
Message call.
Each of these transactions have fields that are shown with each type.
Calls
• A call does not broadcast anything to the
blockchain; instead, it is a local call to a contract
function and runs locally on the node.
• It is almost like a local function call.
• It does not consume any gas as it is a read-only
operation.
• It is akin to a dry run or a simulated run.
• Calls are executed locally on a node VM and do
not result in any state change because they are
never mined.
• Do not confuse a call this with a message call
transaction, which in fact results in a state
change.
• Call basically runs message call transactions

in simulated mode and is available in the
web3.js JavaScript API.
Transaction validation and execution
• Transactions are executed after verifying the
transactions for validity.
Initial tests are listed as follows:
• A transaction must be well-formed and
RLP-encoded without any additional trailing
bytes
• The digital signature used to sign the transaction
is valid
• Transaction nonce must be equal to the sender's
account's current nonce gas limit must not be
less than the gas used by the transaction
• The sender's account contains enough balance

to cover the execution cost.
The transaction substate
• A transaction substate is created during the
execution of the transaction that is processed
immediately after the execution completes.
• This transaction substate is a tuple that is

composed of four items.
• Suicide set or self-destruct set: This element contains the
list of accounts (if any) that are disposed of after the
transaction executes.
• Log series: This is an indexed series of checkpoints that
allow the monitoring and notification of contract calls to
the entities external to the Ethereum environment, such
as application frontends.
• It works like a trigger mechanism that is executed every
time a specific function is invoked, or a specific event
occurs.
• Logs are created in response to events occurring in the
smart contract.
• It can also be used as a cheaper form of storage
Refund balance: This is the total price of gas in the
transaction that initiated the execution.
Refunds are not immediately executed; instead, they
are used to offset the total execution cost partially.
Touched accounts: This is the set of touched accounts
from which empty ones are deleted at the end of the
transaction
State storage in the Ethereum blockchain
• At a fundamental level, Ethereum blockchain is a
transaction and consensus-driven state machine.
• The state needs to be stored permanently in the
blockchain.
• For this purpose, world state, transactions, and

transaction receipts are stored on the blockchain in
blocks.
The world state
• It is a mapping between Ethereum addresses and
account states.
• The addresses are 20 bytes (160 bits) long.
• 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 on storage media.
• The RLP function takes an item as an input, which
can be a string or a list of items and produces raw
bytes that are suitable for storage and transmission
over the network.
• RLP does not encode data; instead, its primary

purpose is to encode structures.
The account state
• The account state consists of four fields:

• nonce,
• balance,
• storage root and
• code hash
Nonce: This is a value that is incremented every
time a transaction is sent from the address.
•In case of contract accounts, it represents the
number of contracts created by the account.
•Contract accounts are one of the two types of
accounts that exist in Ethereum;
• Balance: This value represents the number of
Weis which is the smallest unit of the
currency (Ether) in Ethereum held by the
address.
• Storage root: This field represents the root
node of a Merkle Patricia tree that encodes
the storage contents of the account.
• Code hash: This is an immutable field that
contains the hash of the smart contract code that
is associated with the account.
• In the case of normal accounts, this field contains

the Keccak 256-bit hash of an empty string.
• This code is invoked via a message call.
Accounts trie (storage contents of account), account tuple,
world state trie, and state root hash and their relationship
• 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.
• Accounts trie is 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.
• 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,
which is shown on the right-hand side of the
diagram as state root hash.
Transaction receipts
• Transaction receipts are used as a mechanism to store the
state after a transaction has been executed.
• In other words, these structures are used to record the
outcome of the transaction execution.
• It is produced after the execution of each transaction.
• All receipts are stored in an index-keyed trie.
• The hash (Keccak 256-bit) of the root of this trie is placed

in the block header as the receipts root.
• The post-transaction state: This item is a trie structure
that holds the state after the transaction has been
executed.
• It is encoded as a byte array.
• Gas used: This item represents the total amount of gas

used in the block that contains the transaction receipt.
• The value is taken immediately after the transaction

execution is completed.
• The total gas used is expected to be a non-negative
integer. Prepared By Dr.Saranya K G
Set of logs: This field shows the set of log entries created as
a result of transaction execution.
Log entry contain the logger's address, a series of log topics,
and the log data.
The bloom filter: A bloom filter is created from the
information contained in the set of logs discussed
earlier.
A log entry is reduced to a hash of 256 bytes, which is then
embedded in the header of the block a the logs bloom.
Log entry is composed of the logger's address, log topics,
and log data.
Log topics are encoded as a series of 32-byte data
structures.
Log data is made up of a few bytes of data.
• With the release of Byzantium, an additional
field returning the success (1) or failure (0) of
the transaction is also available.
Transaction receipts and logs bloom
• As the result of transaction execution
process, the state morphs from an initial
state to a target state.
• This state needs to be stored and made
available globally in the blockchain.
Ether cryptocurrency / tokens (ETC and ETH)
• As an incentive to the miners, Ethereum also rewards its
own native currency called Ether, abbreviated as ETH.
• After the DAO hack, a hard fork was proposed in order to
mitigate the issue;
• therefore, 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.
• ETC, however, has its following with a dedicated
community that is further developing ETC, which is the
unforked original version of Ethereum.
• ETH, is the currently the most active and
official Ethereum blockchain.
• Ether is minted by miners as a currency
reward for the computational effort they
spend to secure the network by verifying and
with validation 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.
The denomination table is shown as follows:
Refer Book
Fees are charged for each computation performed by the EVM on the blockchain.

3 Components of The Ethereum Ecosystem

Uploaded by

Copyright:

Available Formats

3 Components of The Ethereum Ecosystem

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

3 Components of The Ethereum Ecosystem

Uploaded by

Copyright:

Available Formats

Components of the Ethereum ecosystem

• The Ethereum blockchain stack consists of

•Keys and addresses

secp256k1 specification (in the range [1, secp256k1n − 1]).

3. An address is derived from the public key which is the

2. The transaction fee is calculated, and the sending

An error is returned if the account balance is not enough.

• EOAs has ether balance

• Nonce: Nonce is a number that is incremented by one

• In secp256k1, the recovery ID is expected to be either 0

• As defined in the yellow paper, message call is the

• Messages are passed using message calls.

• It can either be sent via a smart contract (autonomous

• however, the main difference is that they are produced

•Amount of Wei to transfer and message to the contract

•Optional data field (Input data for the contract)

• Call basically runs message call transactions

• The sender's account contains enough balance

• This transaction substate is a tuple that is

• For this purpose, world state, transactions, and

• RLP is a specially developed encoding scheme that is

• RLP does not encode data; instead, its primary

• The account state consists of four fields:

• In the case of normal accounts, this field contains

• It is produced after the execution of each transaction.

• All receipts are stored in an index-keyed trie.

• The hash (Keccak 256-bit) of the root of this trie is placed

• Gas used: This item represents the total amount of gas

• The value is taken immediately after the transaction

You might also like