Learn Ethereum in 2024. #7. A transaction-based state machine.
Ethereum functions as a transaction-based state machine. To grasp this concept, it’s essential to understand what constitutes the ‘state’ within Ethereum and how transactions transform this state.
The state
The state, alternatively known as the global state or world state, represents the complete set of information stored within Ethereum at any specific moment. Defining it succinctly can be challenging, but as we delve deeper into this article, you’ll gain a comprehensive understanding of what constitutes the state within Ethereum.
To facilitate comprehension, let’s begin by envisioning Ethereum without smart contracts. In this scenario, the state would encompass the collection of all accounts within the network, along with the balance of each account and the count of transactions originating from each account. To simplify, you can visualize the state of Ethereum as a spreadsheet consisting of three columns: ‘Account,’ ‘Balance,’ and ‘Number of Transactions Sent from the Account’.
As Ethereum incorporates smart contracts, the state encompasses more than just balances and transaction counts. One crucial addition is the inclusion of the code for each smart contract. Consequently, we could introduce a fourth column to our conceptual spreadsheet, which would denote the contract code if the account in question is associated with a smart contract. Furthermore, smart contracts often involve variables that necessitate storage. For instance, a token smart contract must maintain information regarding token ownership. Such data becomes part of Ethereum’s state. Hence, we could introduce a fifth column to encapsulate all pertinent information stored by the contract, provided the account is associated with a contract. This comprehensive spreadsheet, encompassing balances, transaction counts, contract code, and stored contract information, represents the state of Ethereum. The primary divergence between Ethereum’s state and this analogy lies in the storage mechanism; Ethereum’s state is not stored in a spreadsheet but within a data structure known as a modified Patricia Merkle Tree. Quite a fancy name, wouldn’t you agree?
For now, let’s simply grasp the state of Ethereum as the comprehensive body of information contained within the Ethereum network. It embodies the truth of the network. You might ponder: do transactions also reside within this state? Is the ledger included in the state? No, they do not. It’s crucial to recognize that while the ledger and the state are interconnected, they represent distinct entities. The ledger consists of transactions, whereas the primary objective of each transaction is… to alter the state! Let’s illustrate this with an example.
Alice and… bob
Let’s consider an Ethereum scenario with just two accounts: Alice and Bob. Initially, Alice possesses 10 ether, while Bob holds 5 ether. No smart contracts are involved. At this point, Alice has initiated 2 transactions, while Bob hasn’t initiated any. This constitutes the state of Ethereum at this specific moment. Now, when Alice executes a new transaction, transferring 5 ether to Bob, it will inevitably alter the state of Ethereum. Post-transaction, the updated state will reflect Alice with 3 transactions and a remaining balance of 5 ether, while Bob will hold 10 ether and maintain his transaction count at zero.
You should now have a grasp of the transaction-based state machine concept. Ethereum functions as such a state machine, altered by transactions. Transactions are recorded in the ledger, while the state is stored in another database, specifically in a modified Patricia Merkle tree data structure.
Let me illustrate with images from both the Ethereum whitepaper, where Vitalik Buterin first proposed the idea, and the Yellow Paper, Ethereum’s technical document.
In the whitepaper image, we observe a state, denoted as “State,” and a transaction that transitions the old state (State) to the new state (State’).
Meanwhile, the Yellow Paper presents a formula that might appear more complex at first glance. However, it essentially indicates the existence of a current state, represented as σ_t, and a function γ that, when given a transaction T and the current state σ_t, generates the new state σ_(t+1). In essence, the combination of the current state and a transaction yields a new state. This transformative process, from the previous state to the new one, is precisely executed by the Ethereum Virtual Machine (EVM). These illustrations and formulas underscore the transaction-based nature of Ethereum’s state machine model.
The state and the ledger
Before delving further into Ethereum’s state data structure, it’s important to acknowledge that, in certain aspects, the ledger holds more fundamental significance compared to the state. This assertion stems from the fact that the ledger serves as the foundational record from which the state can be reconstructed at any given moment. If this concept isn’t yet clear, allow me to illustrate with an example.
Let’s document this sequence of transactions:
Day 0: Alice has 10 ethers, and Bob has 0 ethers.
Day 1: Alice sends 2 ethers to Bob.
Day 2: Alice sends 3 ethers to Bob.
Day 3: Bob sends 1 ether to Alice.
Day 4: Alice sends 2 ethers to Bob.
Day 5: Alice sends 1 ether to Bob.
This information constitutes the ledger. Now, if you ask how many ethers Alice has on day 3 or how many Bob has on day 5, you can determine the answer by performing the necessary calculations. In essence, you can derive the balances on day 3 or day 5 solely by analyzing the transactions. The state is being derived from the transactions.
This highlights why the ledger holds greater significance; if the state is lost, it can be recovered from the ledger. This is precisely the process Ethereum nodes undertake, or ideally should undertake, upon joining the network. They receive the ledger and subsequently compute the current state from it. While not every node may follow this protocol, it remains the safest and most reliable method of reaching the current state.
The state of a block
Another crucial concept to grasp is that the state is inherently transient. In simpler terms, with each new transaction, a new state is generated. Typically, we are concerned with the state at the conclusion of each block. It’s important to recall that a block encompasses multiple transactions. Therefore, to calculate the state of Ethereum in block 1001 from the state in block 1000, one simply needs to execute all transactions contained within block 1001. It’s worth noting that transactions within a block are ordered and must be executed in the specified sequence.
If two nodes start with the same initial state and execute identical transactions, they must inevitably arrive at the same final state. This principle is absolutely fundamental to the operation of the blockchain: all nodes must consistently agree on the some computed state. Hence, blockchain systems must be entirely deterministic. In other words, transactions cannot generate random numbers or consult external sources such as websites. Introducing randomness would lead to discrepancies in the final state among nodes. For instance, if a transaction generated a random number, the outcome would differ between nodes, resulting in a lack of consensus on the final state.
Trees and tries
Let’s revisit the state structure of Ethereum. As mentioned earlier, it’s not akin to a spreadsheet but rather a modified Patricia Merkle trie. In broad terms, it can be conceptualized as a large map that catalogs accounts along with associated information. While there’s much to discuss regarding Ethereum accounts, for now, it’s essential to understand that there are two primary types: externally owned accounts (EOAs), representing individuals, and contract accounts. Each account is identified by a unique address, typically in the format 0x71C7656EC7ab88b098defB751B7401B5f6d8976F. Externally owned accounts are relatively straightforward, containing only two pieces of information: a balance and a nonce. In contrast, contract accounts are more intricate due to the complexity of contract states.
One might conceive of each contract account as possessing its own private database, accessible exclusively by that contract. This database serves as the repository for what we term “state variables,” representing the permanent variables defined within the contract. Given that Ethereum’s state comprises a mapping of potentially millions of accounts, each potentially housing its own database of specific state variables, a specialized data structure is necessary for efficiently retrieving such information. This is where Patricia trees come into play. Notably, “Patricia” isn’t a person’s name but rather an acronym for “Practical Algorithm To Retrieve Information Coded In Alphanumeric.”
A Merkle tree, named after its creator Ralph Merkle, is a data structure that enables the verification of a specific record’s authenticity using a minimal amount of additional information. While delving into its intricacies is beyond the scope here, it’s essential to note that Merkle trees are ubiquitous in blockchain technology. They empower users to adhere to one of the blockchain’s fundamental principles:
“Don’t trust, verify.”
Of all the concepts covered in this article, grasping the relationship between the ledger and the state is the most important. Every user transaction is recorded in the ledger, and each transaction subsequently modifies the state of the Ethereum, affecting factors such as account balances and smart contract variables. These two fundamental components — the ledger and the state — form the cornerstone of a transaction-based state machine.
