Exploring Ethereum: Whitepaper[2]
Ethereum was created with a mission to empower developers to create useful applications in the web3 ecosystem. Ethereum achieves this by constructing the foundation which includes a Turing-complete programming language. This allows developers to write smart contracts and create their own rules for ownership, state transition functions, and transaction formats. Thus, we have seen a wave of protocols and platforms built on the Ethereum blockchain such as Polygon which uses a proof-of-stake mechanism, Hyperledger is an open-source project to assist the distributed ledgers, Aave and Uniswap are Defi platforms built on Ethereum.
Ethereum Accounts
Now, let's learn about the Ethereum Accounts and the mechanism behind them. An Ethereum account generally contains four fields:
1- Nonce: A counter generally used to ensure that each transaction is processed once.
2- Balance: The amount of Ether an account holds. 3- Contract Code: If present and available.
4- Storage: Empty(by default).
Accounts can be classified in two categories: Externally owned accounts and contract accounts.
1- Externally owned accounts: controlled by private keys.
2- Contract account: controlled by contract code.
Contracts are not compilable code. They are autonomous agents that live inside the Ethereum blockchain which gets executed on a specific transaction or message.
Transactions
In Ethereum, a transaction is a signed data package. It includes the recipient of the message, a signature identifying the sender, and the amount of ether to be transferred from the sender to the recipient, along with optional data and gas-related fields.
The first three fields are standard in any cryptocurrency transaction, while the data field has no default function. However, a contract can access the data using an opcode. For instance, if a contract functions as an on-blockchain domain registration service, it may interpret the data as containing a domain to register and its corresponding IP address.
The STARTGAS and GASPRICE fields play a vital role in preserving the integrity and security of the Ethereum blockchain. A limit on the quantity of computations steps helps establish necessary guardrails against the hostile or ill-informed takeover of the entire platform. The fundamental unit of computation is "gas," which represents a unit to be spent in each computational step. This is often referred to as the fees that the developers and users of the platform pay to the miners of the blockchain. It is necessary to note that some computational steps cost a little more depending on the computational complexity and the steps involved in the transaction.
The Ethereum blockchain employs several transactional and computational fees. The fee system ensures that an attacker pays proportionately for every resource consumed, including computation, bandwidth, and storage. Consequently, any transaction that increases the network's resource consumption must have gas fees proportional to the increment.
Messages
Smart contracts on the Ethereum blockchain possess the ability to send messages to other smart contracts. Messages are non-serialized virtual objects that exist only in the Ethereum execution environment.
An Ethereum message generally comprises the sender of the message, the recipient of the message, the amount of ether transferred alongside the message, an optional data field, and a start gas value.
Ethereum messages are an important aspect of the Ethereum blockchain, allowing smart contracts to communicate with each other and transfer data between them. Messages are essentially small packets of data that are sent between contracts on the Ethereum network, and they play a critical role in enabling the interoperability of different smart contracts.
Messages can be sent either from an externally owned account (EOA) or from another smart contract. When a message is sent from an EOA, it is referred to as a transaction message, while when it is sent from a contract, it is referred to as an internal message.
One of the primary use cases of messages in Ethereum is to facilitate the transfer of assets between contracts. For example, if a user wants to transfer Ether or any other ERC-20 token from one smart contract to another, they would initiate an internal message between the two contracts, with the appropriate parameters and data.
Another use case for messages is for contract-to-contract communication. Smart contracts often need to interact with other contracts in order to perform complex operations or to access data that is stored in other contracts. Messages allow contracts to communicate with each other in a secure and efficient manner, without the need for any centralized intermediaries.
Messages in Ethereum are also critical for enabling smart contracts to interact with the outside world. For example, a smart contract may need to communicate with an oracle in order to access off-chain data such as stock prices, weather information, or other real-world data. Messages allow the contract to communicate with the oracle and retrieve the necessary data in a secure and decentralized manner.
In conclusion, Ethereum messages are a crucial component of the Ethereum blockchain ecosystem. They allow smart contracts to interact with each other, transfer assets, access off-chain data, and perform other critical functions that make Ethereum a powerful platform for decentralized applications. As Ethereum continues to evolve and expand, messages will remain an important tool for developers and users alike, enabling them to build complex and sophisticated decentralized applications that can interact with the broader Ethereum network.
State Transition Function
The Ethereum state transition function is a crucial aspect of the Ethereum blockchain's operation. It defines how the state of the blockchain changes as a result of transactions and the associated execution of smart contracts.
The state transition function takes as input the current state of the Ethereum blockchain, along with a transaction that is to be executed. The function then computes the effects of the transaction on the state of the blockchain, including any changes to the account balances, contract code execution, and storage. These changes are reflected in the updated state of the blockchain after the transaction has been processed.
A basic example of a smart contract and the Ethereum State Transition Function:
The state transition function involves several steps, including:
Transaction Validation: The function checks that the transaction is valid and has been signed by the correct account.
Gas Calculation: The function calculates the amount of gas required to execute the transaction, based on the computational complexity of the contract code and the gas price specified in the transaction.
Contract Execution: If the transaction involves a contract call, the function executes the contract code and updates the contract's storage.
Gas Refund: If the transaction uses less gas than what was initially specified, the remaining gas is refunded to the sender's account.
Account Balance and Nonce Update: The function updates the account balances and nonces of the sender and receiver based on the transaction.
Block Validation: The function checks that the block containing the transaction is valid, including its timestamp and the validity of the preceding block.
Overall, the Ethereum state transition function ensures that transactions are executed correctly and safely and that the state of the blockchain remains consistent and up-to-date. This enables the Ethereum blockchain to function as a decentralized and secure platform for executing smart contracts and decentralized applications.
pragma solidity ^0.8.0;
contract StringStorage {
string storedString;
function setString(string memory newString) public {
storedString = newString;
}
function getString() public view returns (string memory) {
return storedString;
}
}
Now, let's go through the steps that take place when this smart contract is deployed and used according to the Ethereum State Transition Function:
Contract deployment: The code is compiled and deployed to the Ethereum blockchain, creating a new contract address.
Transaction creation: A user creates a transaction to call the setString function and pass in a new string value.
Transaction validation: The transaction is validated by the Ethereum network to ensure that the user has sufficient funds to cover the gas fee and that the function call is valid.
Gas payment: The user pays a gas fee to the network for executing the transaction.
State change: The setString function is executed, updating the storedString variable with the new value provided by the user.
State transition: The state of the contract is updated to reflect the new value of storedString.
Transaction receipt: The user receives a receipt confirming that the transaction was executed and the new value of storedString has been set.
Query creation: Another user creates a transaction to call the getString function to retrieve the current value of the stored string.
Transaction validation: The transaction is validated by the Ethereum network to ensure that the user has sufficient funds to cover the gas fee and that the function call is valid.
Gas payment: The user pays a gas fee to the network for executing the transaction.
State query: The getString function is executed, returning the current value of storedString to the user.
No state transition: Since the getString function does not modify the state of the contract, no state transition occurs.
Transaction receipt: The user receives a receipt confirming that the transaction was executed and the value of storedString has been retrieved.
These are the basic steps that occur when a smart contract is deployed and used in Ethereum
Code Execution
When you write code for Ethereum contracts, you're using a programming language called "Ethereum virtual machine code" or "EVM code". This language is based on a low-level, stack-based bytecode.. Each byte in the code represents an operation to be executed. When you run the code, it starts at the beginning and carries out each operation in order. This process of executing code is called "code execution".
As the code runs, it can store data in three different ways: the stack, memory, and storage. The stack is like a container that can hold values, and you can add or remove values from the top of the container. Memory is a space that can hold an unlimited amount of data. Finally, storage is where the contract can save data that will persist for a long time.
The code can also get information about the incoming message, like who sent it and what data it contains. It can also return data as an output.
The Ethereum virtual machine executes code in a very simple way. The virtual machine has a "computational state" that keeps track of everything that's happening as the code runs. This state is made up of several pieces of information, like the code being executed, the memory and storage being used, and the current position of the program counter.
The program counter is like a pointer that points to the next operation to be executed. As each operation is carried out, the program counter moves to the next operation in the code. The execution continues until either the end of the code is reached or an error is encountered.
Each operation has a specific effect on the computational state. For example, if an operation takes two values from the stack, adds them together, and puts the result back on the stack, then the computational state will reflect that change.
There are several ways that the Ethereum virtual machine can be optimized to make code execution faster. For example, a technique called "just-in-time compilation" can be used to speed up the execution of frequently used code. But even without these optimizations, writing a basic Ethereum implementation in just a few hundred lines of code is possible.
Blockchain and Mining
Here is a step-wise block validation algorithm in Ethereum:
Check that the block is well-formed, including that it contains a valid header, a list of transactions, and a valid state root.
Verify that the block's timestamp is not more than 15 seconds in the future according to the node's clock.
Validate that the block's difficulty matches the expected difficulty based on the previous block and the block timestamp.
Verify that the block's gas limit is within the acceptable range, which is a function of the parent block's gas limit and the current block's timestamp.
Verify that the block's transactions are all well-formed, meaning they have a valid signature, a valid nonce, and a valid gas price.
Execute each transaction in the block and verify that it does not run out of gas, which would cause the entire block to be invalid.
Validate that the state transition caused by executing the transactions in the block results in a valid state, meaning that all account balances and storage values are non-negative.
Verify that the block's gas used is less than or equal to the block's gas limit.
Verify that the block's hash satisfies the difficulty target specified in the block header.
Validate that the block's parent is a valid block and that its header is correctly included in the current block header as the parent hash.
If all of the above steps pass, then the block is considered valid and can be added to the blockchain.
This block validation algorithm ensures that only valid blocks are added to the blockchain, preventing attackers from creating blocks that would cause the network to behave in unexpected or malicious ways. By validating each block before it is added to the blockchain, Ethereum ensures the integrity of its distributed ledger and ensures that all participants in the network can trust the data stored on the blockchain.
Subscribe to my newsletter
Read articles from Kairav Thakkar directly inside your inbox. Subscribe to the newsletter, and don't miss out.
Written by
Kairav Thakkar
Kairav Thakkar
Currently working as an AI prompt engineer, I possess skills in blockchain engineering, data analysis, generative AI research, and :) you guessed it- prompt engineering. I am passionate about blockchain data analysis and business applications of prompt engineering.