Components of 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.

 

This Ethereum blockchain architecture can be visualized in the following diagram:

 

A formal list of all high-level elements present in the Ethereum blockchain are:

• 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 types.

 

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.
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.

 

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.

 

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 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.
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 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)

 

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.

 

Various properties of each type of accounts are described here:

 

EOAs

• 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

 

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
• Also, CAs can maintain their permanent state and can call other contracts
• 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 below:

• Nonce: Nonce is a number that is incremented by one every time a transaction is sent by the sender. 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.

 

• 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.

 

• 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).

 

• 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.

 

• 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.

 

Contract Creation Transaction

There are a few essential parameters that are required when creating an account.

 

These parameters are listed as follows:

• 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 transactions are 160-bit in length.

 

The new account is initialized when the EVM code is executed.

 

In the case of any exception during code execution, such as not having enough gas, the state does not change.

 

If the execution is successful, then the account is created after the payment of appropriate gas costs.

 

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.

 

Messages

Messages are the data and value that are passed between two accounts.

 

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

 

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.

 

Calls are executed locally on a node VM and do not result in any state change because they are never mined.

 

Transaction Validation and Execution

Transactions are executed after verifying the transactions for validity by performing the following tests:

• A transaction must be well-formed and RLP-encoded without any additional trailing bytes
• The digital signature used to sign the transaction is valid or not
• Transaction 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

 

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 (described later in this chapter), 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.

 

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.

 

Ethereum Virtual Machine (EVM)

EVM is a simple stack-based execution machine that runs bytecode instructions to transform the system state from one state to another.

 

The word size of the virtual machine is set to 256-bit.

 

The stack size is limited to 1024 elements and is based on the Last In, First Out (LIFO) queue.

 

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 is an entirely isolated and sandboxed runtime environment.

 

The code that runs on the EVM does not have access to any external resources, such as a network or filesystem.

 

This results in increased security, deterministic execution and allows untrusted code (anyone can run code) to be run on Ethereum blockchain.

 

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 is called storage which is permanently stored on the blockchain.

 

It is a key value store and can be thought of like a hard disk storage.

 

The program code is stored in a virtual read-only memory (virtual ROM).

 

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.

 

Smart Contracts

Smart contracts were first theorized by Nick Szabo in the late 1990s in an article named Formalizing and Securing Relationships on Public Networks.

 

Smart contracts are described by Szabo as follows:

A smart contract is an electronic transaction protocol that executes the terms of a contract. The general objectives are to satisfy common contractual conditions (such as payment terms, liens, confidentiality, and even enforcement), minimize exceptions both malicious and accidental, and minimize the need for trusted intermediaries. Related economic goals include lowering fraud loss, arbitrations and enforcement costs, and other transaction costs.

 

There is no consensus on a standard definition of smart contracts.

 

It is essential to define what a smart contract is, and the following is a generalized definition of a smart contract:

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

 

A smart contract is a computer program that is written in a language that a computer or target machine can understand.

 

Also, it encompasses agreements between parties in the form of business logic.

 

Another fundamental idea is that smart contracts are automatically executed 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.

 

Smart contracts are secure and unstoppable, which means that these computer programs are required to be designed in such a fashion that they are fault-tolerant and executable in a 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 some scenarios and can be relaxed.