Introduction to Ethereum: Ethereum's data structure

Introduction

The technical basis of the blockchain is a decentralized data consensus. The first problem we face is in what form to organize the data to realize a distributed database. This article analyzes the implementation mechanism of Ethereum.

Network structure

In conventional Internet applications such as Alipay and WeChat, user data and transaction data are stored on the central server of the application provider, and are stored persistently through IOE, MySQL cluster, etc. When ordinary nodes perform transactions, they will be sent to the central node. After sending a request, the central node performs various addition, deletion, modification, and check operations, and returns the result to the user node.

There is no central server in Ethereum. Instead, there are multiple equal nodes connected through the p2p protocol, and all data is stored in many nodes. When a user initiates a transaction, the transaction will be broadcasted through the p2p protocol, and the miner node will verify it, package it, and broadcast it to the entire network. After confirmation in the blockchain, this operation is considered unchangeable.
In articles about blockchain on the Internet, the terms distributed and decentralization are mentioned, sometimes they are slightly different, and sometimes they are mixed. The author believes that if you want to distinguish accurately, the distributed system emphasizes that multiple components work together by sending messages, and the decentralization emphasizes that there is no central node to control the operation of the entire system. Therefore, we believe that Ethereum is both decentralized and distributed, or that it runs a decentralized program on a distributed platform. reference

Blockchain (BlockChain)

In a single node, data is stored in the form of a block chain (BlockChain). The blockchain is composed of blocks that are strung together. Ethereum generates a new block every ten seconds, recording various information during this period of time.

Ethereum is described as a transaction-driven state machine. After receiving some input in a certain state, it will definitely transfer to a new state. Specifically, in the state of an Ethereum, each account has a certain balance and storage information. When a set of transactions is received, the balance and storage information on the affected account will change. Starting from the first genesis block, transactions are received continuously, which can enter a series of new states.

According to this idea, Ethereum packs transaction data and verification information into a block every once in a while, and concatenates them in turn to form a chain. The newer the block, the larger the block number (BlockNumber, or block height).

In the header (verification information) of each block, the header hash value (ParentHash) of the previous block is stored. In this way, the blocks in the blockchain are connected to each other. If we change the content of a previous block, the hash of the parent block of the next block will not correspond to it, and this kind of block will not be recognized by everyone. This ensures that the blockchain data cannot be tampered with.
Block

Each block contains a block header and a transaction. The structure of the block header is shown in the figure below.

The meanings of several key fields are as follows:

ParentHash: The hash value of the parent block
Number: Block number
Timestamp: The timestamp generated by the block
GasUsed: Gas consumed by the transaction
GasLimit: Gas limit
Difficulty: The difficulty value of POW
Beneficiary: the beneficiary of the block packing fee, also known as the miner
Nonce: A random number that makes the hash of the block header meet the POW requirements
It takes some gas to initiate a transaction on the account, which is owned by the miner as a handling fee. In POW mode, miners need to constantly adjust Nonce when packing blocks, so that the hash value of the entire block header meets certain conditions (for example, the first few bits are all 0)

StateRoot: The root hash value of the state tree

TransactionsRoot: the root hash value of the transaction tree
ReceiptsRoot: the root hash value of the receipt tree
When each miner packs transactions into blocks, three trees are organized:
Trading tree, the leaves are trading
Receipt tree, in the leaves are the receipts generated by the transaction
State tree, the leaves are the account states affected by the transaction

To obtain the root hash of the three trees, three fields of StateRoot, TransactionsRoot, and ReceiptsRoot can be obtained in the block header. In this way, the mapping between the transaction and the block header field is established. When other users receive the block, the receipt and status can be calculated based on the transaction in the block, and the three root hashes are calculated and verified with the three fields of the block header to determine whether it is a legal block.