How does Ethereum work? (I)

Editor's note: This article comes from Lanhu Notes (ID: lanhubiji), original author: Preethi Kasireddy, translated by Leo.

Preface: This article mainly explains the specific operating principles of Ethereum at present, which helps us understand the various concepts and operations behind Ethereum and is suitable for beginners to read.

introduce

Whether you know what it is or not, you’ve probably heard of the Ethereum blockchain. It’s been in the news a lot. If you don’t have a basic understanding of Ethereum, this article might be a little confusing. So what exactly is Ethereum? It’s essentially a public database that keeps a permanent record of digital transactions. Importantly, this database doesn’t require any central authority to maintain and secure it. Instead, it operates as a “trustless” transaction system, a framework in which individuals can conduct peer-to-peer transactions without having to trust any third party or each other.

Still confused? That's where this article comes in handy. My goal is to explain how Ethereum works from a technical level, without complicated math or scary formulas. Even if you're not a programmer, I hope you'll at least get something out of this. It's okay if some parts are too technical and too confusing. You don't need to understand all the details. I recommend just understanding it at a high level.

The topics mentioned in this article are all concepts from the Ethereum Yellow Paper. I added my own explanations and diagrams to make it easier to understand. If you are interested in the technical challenges, you can also read the Yellow Paper directly.

Definition of blockchain

A blockchain is a “cryptographically secure singleton transaction machine with a shared state.” Let’s break it down.

"Cryptographic security" means that the digital currency created is secured by complex mathematical algorithms that are difficult to crack. Think of firewalls. It is almost impossible to cheat the system, such as creating false transactions, deleting transaction records, etc.

"Singleton of transactions" means there is a single canonical instance that is responsible for all transactions created in the system. In other words, there is a single global truth that everyone believes in.

"Having a shared state" means that the state stored on this machine is shared and available to everyone.

Ethereum implements this blockchain paradigm.

Paradigm Explanation of Ethereum Blockchain

The Ethereum blockchain is essentially a transaction-based state machine. In computer science, a state machine is something that reads a series of inputs and, based on those inputs, transitions to new states.

With Ethereum's state machine, we start from the "genesis state". This is similar to a blank slate, with no transactions ever occurring on the network. As transactions are executed, the genesis state transitions to some final state. At any point in time, the final state represents the current state of Ethereum.

The state of Ethereum consists of millions of transactions. These transactions are grouped into blocks. A block contains a series of transactions, and each block is linked to its previous block.

For one state to transition to the next, the transaction must be valid. For a transaction to be recognized as valid, it must go through a verification process called mining. A group of nodes (computers) spend their computing resources to create blocks containing valid transactions, which is mining.

Any node on the network can declare itself to be a miner node and can attempt to create and verify blocks. There are many miners around the world trying to create and verify blocks at the same time. When submitting a block to the blockchain, each miner provides a mathematical "proof" that serves as a guarantee: if the proof exists, the block must be valid.

For a block to be added to the main chain, miners must prove it faster than their competitors. The process of verifying each block by having miners provide mathematical proof is called "proof of work."

Miners who validate new blocks are rewarded with a certain amount of value as an incentive for doing this work. What kind of value? The Ethereum blockchain uses a native digital token called "Ether". Every time a miner proves a block, new Ether tokens are generated and rewarded to the miner.

You might be wondering: what guarantees that everyone is on the same chain? How can we be sure that a subset of miners won’t decide to create their own chain?

As mentioned above, we define a blockchain as a single transaction machine with a shared state. Using this definition, we can understand that the correct current state is a single global fact that everyone must accept. Having multiple states (or multiple chains) will ruin the entire system because it is impossible to agree on which state is the correct state. If there are multiple chains, you may have 10 tokens on one chain, 20 tokens on another, and 40 tokens on another. In this case, there is no way to determine which chain is the most "valid".

Whenever there are multiple paths, there is a “fork.” We generally want to avoid forks because they corrupt the system and force people to choose which chain to trust.

In order to decide which path is the most efficient and prevent multiple chains from being created, Ethereum uses a mechanism called the "GHOST protocol". "GHOST" = "Greedy Heaviest Observed Subtree"

In simple terms, the GHOST protocol says that we must pick the path that takes the most computational effort. One way to decide that path is to use the block number of the latest block (the "leaf block"), which represents the total number of blocks that are currently on that path (excluding the genesis block). The higher the block number, the longer the path, and the more mining effort is required to reach the "leaf block". Using this method of reasoning, we are able to agree on a canonical version of the current state.

Now that you have a basic understanding of blockchain, let’s take a closer look at the main components of the Ethereum system:

Account

Status

Gas and fees

Trading

Block

Transaction execution

Mining

PoW

One thing to note before we begin: when this article refers to the “hash” of X, it usually refers to the KECCAK-256 hash used by Ethereum.

Account

Ethereum's global "shared state" is made up of many small objects (accounts) that interact with each other through a message passing framework. Each account has a state associated with it and a 20-byte address. An address in Ethereum is a 160-bit identifier that identifies any account.

There are two types of accounts:

External accounts, controlled by private keys, have no code associated with them.

l Contract accounts, which are controlled by contract code and have codes associated with them.

External Accounts Vs. Contract Accounts

It is very important to understand the fundamental difference between external accounts and contract accounts. An external account can send messages to other external accounts or other contract accounts by creating and signing a transaction with its private key. Messages between two external accounts are simply value transfers. But messages sent from an external account to a contract account can activate the contract account's code, allowing it to perform various actions (e.g., transfer tokens, write to internal storage, issue new coins, perform calculations, create new contracts, etc.)

Unlike external accounts, contract accounts cannot initiate new transactions on their own. Instead, contract accounts can only trigger their own transactions in response to other transactions they receive. For example, transactions from external accounts or from other contract accounts. We will learn more about contract-to-contract requests in the "Transactions and Messages" section.

Therefore, any operation that occurs on the Ethereum blockchain is always initiated by a transaction triggered by an external account.

Account Status

The account status consists of four parts, which exist regardless of the account type:

Nonce: If the account is an external account, this number represents the number of transactions sent from this account address. If the account is a contract account, the nonce is the number of contracts created by the account.

Balance: The number of Wei owned by this address. Each Ether has 1e+18 Wei.

StorageRoot: The hash value of the root node of the Merkle Patricia tree (Merkle tree will be explained later). The Merkle tree encodes the hash of the storage content of the account and is empty by default.

CodeHash: The hash of the EVM code for this account. For contract accounts, this is the code that is hashed and stored as CodeHash. For external accounts, the codehash field is the hash of an empty string.

World State

We know that the global state of Ethereum includes the mapping between account addresses and account states. This mapping is stored in the data structure of the Merkle Patricia tree.

A Merkle tree is a binary tree consisting of a set of nodes, where:

The large number of leaf nodes at the bottom of the tree contain the underlying data

A set of intermediate nodes, where each node is the hash of two child nodes

A root node, also formed by the hash of two child nodes, represents the top of the tree

The data at the bottom of the tree is generated by splitting the data we want to store into blocks, then splitting the blocks into buckets, then taking the hash of each bucket and repeating the same process until the total number of hashes remaining is only one: the root hash.

Merkle trees require that each value stored in them has a key. Starting from the root node of the tree, the key should tell you which child node to follow to get the corresponding value, which is stored on the leaf node. In the case of Ethereum, the key/value mapping of the state tree is between addresses and their associated accounts, including the balance, nonce, codeHash, and StorageRoot of each account (where StorageRoot itself is a tree).

(Source: Ethereum White Paper)

The same trie structure is also used to store transactions and receipts. More specifically, each block has a "block header" that stores the root node hash of three different Merkle trie structures, including:

l State trie

Transaction trie

l Receipt trie

The ability to store all of this information efficiently in Merkle tries is very useful in Ethereum because we have "light clients" and "light nodes". Remember, the blockchain is maintained by a bunch of nodes. Broadly speaking, there are two types of nodes: full nodes and light nodes.

A full node syncs the blockchain by downloading the entire chain data, from the genesis block to the current block, executing all transactions contained in it. Usually, miners store full archive nodes because they must perform this operation to mine. It is possible to download a full node without performing any operation. In any case, any full node includes all chains.

However, unless a node needs to execute every transaction or query historical data, there is no need to store the entire chain data. This is also the origin of the concept of light nodes. Instead of downloading and storing the data of the entire chain and executing all transactions, light nodes only download the chain header, from the genesis block to the block header of the current block, without executing any transactions or retrieving any related status. Since light nodes can access the block header, which contains the hash of three tries, they can still easily generate and receive verifiable answers, such as about transactions, events, balances, etc.

The reason this works is that hashes in a Merkle tree propagate upwards - if a malicious user tries to place a false transaction at the bottom of the Merkle tree, that change will cause the hash of the node above to change, which will then change the hash of the node above that, and so on, eventually changing the hash of the root of the tree.

Any node that wants to verify data can use a "Merkle proof" to do so. A Merkle proof consists of:

l A bunch of data to be proved and its hash

The root hash of the tree

“Branches” (all partner hashes going up the path from the block to the root)

Anyone reading the proof can verify that the branch hashes are consistent all the way up the tree, and therefore a given block is actually at that location in the tree.

In summary, the benefit of using a Merkle Patricia tree is that the root of the structure is cryptographically dependent on the data stored in the tree, so the root hash can be used to securely identify that data. Since the block header contains the root hash of the state, transaction, and receipt trees, any node can verify a small portion of the Ethereum state without having to store all of it, which would make a full node very large.

--To be continued---