Partnered With:

The Design Concept of Ethereum (1)

Read this article in 33 Minutes

原文标题：《Design Rationale》

Original article by: Vitalik Buterin

原文编译： kim & 阿剑，以太坊爱好者

Although many of Ethereum's ideas have been used and tested for five years on earlier cryptographic currencies such as Bitcoin, there are still many differences in the way certain protocol functions are handled. Moreover, Ethereum can be used to develop entirely new economic tools because it has many features that other systems do not. This article will describe in detail all of Ethereum's potential benefits, as well as some of the controversial aspects of building the Ethereum protocol. In addition, we will also point out the potential risks of our solutions and alternatives.

The principle of

The Ethereum protocol is designed according to the following principles:

1. Sandwich complex model (also known as "layered complexity model") :We believe that Ethereum's underlying protocol should be as simple as possible and that the interface design should be easy to understand (whether it's a high-level programming language interface for developers or a user interface). Inevitably complex parts should be placed in the middle layer. The middle tier, which is not part of the core consensus and is not visible to the end user, includes: high-level language compilers, parameter serialization and deserialization scripts, storage data structure models, LevelDB storage interfaces, and networking protocols. Of course, the lines of demarcation are not absolutely clear and sometimes need to be adjusted as appropriate.

2.Freedom:Users should not be restricted from using Ethereum protocols, nor should they attempt to favor or disfavor certain Ethereum contracts or transactions. This is similar to the guiding principle behind the concept of "net neutrality". The Bitcoin exchange protocol is &NBSP; There is no & have spent Follow this principle: The Bitcoin Exchange Protocol does not encourage the blockchain's "off-labal purpose" (e.g., data storage, meta-protocol). "Unconventional use"); Also, there are sometimes quasi-protocol layer changes (such as limiting the length of the OP_RETURN field to 40 bytes) to attack applications that use the blockchain in an "unauthorized" way. Therefore, at eTheSquare, we strongly support the use of transaction fees alone to achieve gross incentive compatibility -- the more resources a user consumes across the network, the higher the cost it will have to pay, even if they bear the cost themselves (i.e., Pigoudian taxes).

3. Generalize:The Ethereum protocol's features and opcodes should maximise low-level concepts (like elementary particles) so that they can be combined at will, including things that seem useless today but may be useful in the future. Furthermore, low-level concepts can be more efficient by stripping away functionality that is not needed. An example of following this principle is when we choose the LOG opcode as the way to provide information to the dApp, rather than logging all transactions and messages as we did before. In the early days, the concept of "message" was completely a collection of concepts, including "function call" and "event of interest to an external observer," and the two could be completely separated.

4. The absence of features is the greatest feature:For the sake of generalization, we refuse to embed those high-level use cases as part of the protocol, even those that are frequently used. If people really want to implement these use cases, they can create sub-protocols within contracts (e.g., etherium-based sub-currencies, Bitcoin/Litecoin/Dogecoin side chains, etc.). In Ethereum, for example, there is a lack of a "time lock" like in Bitcoin. However, this functionality can be simulated by the following protocol: the user sends a signed packet to a specific contract for processing, and if the packet is valid in the specific contract, the corresponding function is executed.

5. Not Risk Aaverse:We are willing to take higher risks if the increased risk brings significant benefits (for example, generic state transitions, 50-fold reduction in block time, consensus efficiency, etc.). These principles guided the development of Ethereum, but they were not absolute; In some cases, reducing development time or not wanting to make too many changes at once also led us to delay making changes and save them for a future release.

Blockchain Layer Protocol

This section describes the changes to the blockchain layer protocol in Ethereum, including how blocks and transactions work, how data is serialized and stored, and the mechanisms behind accounts.

An account, not a UTX&&Nb&&Nb&Nb; 1

Bitcoin, and many of its variants, stores the user's balance information in a UTXO structure in which the entire state of the system consists of a series of "unspent outputs" (think of these "unspent outputs" as coins). (Proofread note: a better metaphor might be a "check.") . Each UTXO has an owner and its own value attribute. A transaction that consumes several UTXOs also generates several new UTXOs; The transaction is subject to the following validity requirements:

1. Each referenced input must be valid and unused;

2. The signature of the transaction must match the owner signature of each input;

3. The total value of inputs must be equal to or greater than the total value of outputs.

Thus, in the Bitcoin system, the user's "balance" is the sum of all UTXOs that the user's private key can effectively sign. The following diagram shows the transaction input and output process in the Bitcoin system:

- The tripartite accounting system used in Bitcoin -

However, Ethereum ditched the UTXO scheme in favor of a simpler approach: the concept of state for storing a series of accounts, each with its own balance, and Etherium-specific data (code and internal storage). If the transaction is valid if the balance in the initiator's account is sufficient to cover the transaction costs, the amount is deducted from the initiator's account and credited to the receiving account. In some cases, when the receiving account has code that needs to be executed and the transaction triggers the execution of that code, the account's internal storage may change and additional messages may even be created to be sent to other accounts, causing new transactions to occur.

Although Ethereum does not adopt the concept of UTXO, UTXO does have some advantages:

1. High degree of privacy protection:If users use a new address for each transaction, it becomes difficult to correlate accounts to each other. This works for security-intensive currency systems, but is not appropriate for any dApp. Because dApps often need to keep track of the user's complex binding state, the state of a dApp can't be divided as easily as the state in a currency system.

2. Potential scalability:In theory, UTXO fits well with some types of scalability paradies, since all that is needed is for the holder to have a Merkel proof of his or her monetary ownership, even if everyone else (including him or herself) forgets the data, and the person suffers, the others are not affected. In the Ethereum account system, if everyone loses the merkle tree part of an account, that account will not be able to process any messages that affect it, including messages sent to it, nor will it. However, it's not just UTXO that can be extensible, and there are ways to extend it without relying on UTXO.

The benefits of an account are as follows:

1. Save a lot of space:If an account has five UTXOs, switching from UTXO mode to account mode reduces the space required from 300 bytes to 30 bytes. The calculation is as follows: 300 = (20+32+8) * 5 (20 is the number of address bytes, 32 is the number of TX ID bytes, 8 is the number of denomination bytes); 30 = 20 + 8 + 2 (20 is the number of bytes of address, 8 is the number of bytes of account balance value, 2 is nonce 2 Number of bytes); But the actual savings are not so great because the account needs to be stored in the Patricia tree. In addition, transactions in Ethereum are smaller than those in Bitcoin (100 bytes in Ethereum versus 200-250 bytes in Bitcoin) because each transaction only needs to generate one reference, one signature, and one output.

2. Better interchangeability:The UTXO structure does not have the concept of a blockchain layer, so it is not practical, either technically or legally, to create a red list/blacklist and distinguish these "valid outputs" based on their source.

3. Simple:Ethereum coding is simpler and easier to understand, especially when complex scripts are involved. Although any decentralized application can be (grudgely) implemented in UTXO, this approach essentially gives scripts the ability to limit the types of UTXOs that a given UTXO can output and the conditions under which it can be used (such as the need to include Merkle tree proofs to help the application of the script change the state root). As a result, the UTXO implementation is much more complex than the way Ethereum uses accounts.

4. Light Client:The light client can access all the data associated with the account at any time by scanning the state tree in a specified direction. In the UTXO paradigm, each transaction requires a different reference, which can be burdensome for a long-running dApp that uses the UTXO root state propagation mechanism mentioned above.

We believe that the benefits of accounts greatly outweigh the alternatives, especially for the dApp applications that we want to support that can contain arbitrary state and code. In addition, in line with the guiding principle of "no feature is the greatest feature", we believe that if users really care about privacy, they can set up an encrypted "mixer and coinjoin" to confuse the payment path through the signed packet protocol in the contract.

One weakness of the account approach is that in order to prevent replay attacks, each trade must have a "nonce". Therefore, each account should have a real-time updated nonce value, and each new transaction increments the account's nonce value by 1 as its own nonce (and updates the account's nonce value by this value after the transaction is processed). In account mode, if transactions are not accompanied by such consumable identifiers, transactions can be processed repeatedly, so that the receiving account can be collected over and over again without paying any cost, while the issuing account is sucked dry. The Ethereum account's nonce increases as the initiated transaction is processed, solving this problem). This means that even accounts that are no longer in use cannot be removed from the account status. A simple way around this problem is to have transactions contain a block number so that they cannot be replayed after a certain period of time, and to reset the nonce every once in a while.

To delete an account from the state (such as one that has not been used for a long time), they must be "pinged" first, and a full scan of the blockchain protocol is expensive. We did not implement this mechanism in 1.0 and may use it in 1.1 and above.

Proofread note: This is the technical reason for Ethereum's future "state explosion" problem: all state data must be kept intact and an account cannot be reasonably deleted. As a blockchain protocol, Ethereum's nodes have to agree not only on the order of transactions (transactions), but also on the global state (in the form of the state root that needs to be included in the block head). Therefore, if you want to delete the status, also need the consensus of the whole network, otherwise it will fall into a split.

Proofread Note: This practice of marking the order of account transactions with a nonce also forces the user's transactions to be executed sequentially, so that if one transaction cannot be processed, subsequent transactions using a nonce cannot be processed. For "expediting" the process of uploading transactions that have been sent, seeThis article.

Merkle Patrish Tree (MPT)

The Merkle Patricia Tree/Trie, conceived by Alan Reiner and implemented in the Ripple protocol, is Ethereum's primary data structure, used to store all account states, as well as transaction and receipt data within each block. MPT is a combination of a Merkle tree and a Patricia tree. Combining these two trees creates a structure with the following properties:

1. The root hash value of any key-value pair is unique, and attempts to claim the existence of a key-value pair in a tree are guaranteed to be detected (unless the attacker has a computing power of about 2^128).

2. The time complexity of adding, deleting, and changing a key-value pair is logarithmic.

MPT provides us with an efficient, easily updatable "fingerprint" that represents the entire state tree. Described in greater detail about the MPT: https://github.com/ethereum/wiki/wiki/Patricia-Tree.

The specific design decisions of MPT are as follows:

1. There are two types of nodes:KV nodes and discrete nodes. The presence of KV nodes increases efficiency, because if the tree is sparse in a certain area, the KV nodes can be used as a "shortcut" to compress the height of the tree (read the MPT's details for more details).

Discrete nodes are hexadecimal, not binary:This makes the lookup more efficient, and we now realize that this choice is not ideal because the lookup efficiency of a hexadecimal tree can be simulated in binary by batch storage nodes. However, the implementation of the MPT tree structure was very error-prone and ended up with at least a state root mismatch, so we decided to put the changes on hold until version 1.1.

3. There is no difference between empty value and non-membership:To simplify the logic, the value (balance) of an unenabled account in Ethereum defaults to 0, and empty strings are also represented by 0. However, it is important to emphasize that this is not optimal at the expense of some versatility.

What is the difference between the terminating node and the non-terminating node?Technically, identifies a node "is eventually node" is unnecessary, because all the trees were used to store in the etheric fang fixed length data (i.e., the length of the key), but in order to increase the versatility, we will add this logo, to expect the etheric lane way of the realization of the MPT can be adopted by other cryptography currency intact.

5. Use SHA3(K) as the key in the "security tree" (state tree and account storage tree) :With SHA3(k), you want to generate as many accounts as possible (accounts up to 64 levels of state tree!) And repeatedly calling the SLOAD and SSTORE opcodes to make a DoS attack much more difficult. Note that this also makes enumerating trees more difficult; If you want your client to have enumeration capability, the easiest way to do this is to maintain a map. sha3(k) -> k 's database.

Proofreading note: Here mean, if you use the key k as Angela merkel tree stored data, the distribution may be very sparse, and the attacker can easily planning need deep tree path to store account, and access to these accounts repeated calls to state operations, to create nodes in a network of overload operation, however, the result of the hash function is a random distribution, Sha3 (k) as a key can make the distribution of keys more uniform, and the tree height will be shorter).

There are trade-offs to this feature, which on the one hand means that DoS attacks are more difficult, and on the other hand, it makes the state tree access paths for transactions within a block very rarely overlap, so each search is the worst-case scenario.

In addition, this makes it difficult for the MPT to achieve "statelessness" (the block itself carries the data needed for validation, and the verifier does not have to have a global state), because the paths to state access do not overlap, and the spatial efficiency of the evidence is the worst case. Of course, it can also be said that the spatial efficiency of Merkel tree evidence itself is not high enough

RLP

RLP (recursive length prefix) : Recursive length prefix

RLP encoding is the primary serialization format in Ethereum, and it's used everywhere: blocks, transactions, account status, and network protocol messages. See the official description of RLP: & NBSP; https://github.com/ethereum/wiki/wiki/RLP

RLP is intended to be a highly simplified serialization format whose sole purpose is to store nested byte arrays. 3. Unlike & have spent Protobuf, BSON RLP does not define any specified data types, such as Boolean, Float, Double, or Integer. It simply stores the structure as a nested array, and the protocol determines the meaning of the array. RLP also has no explicit support for Map collections; the semi-official recommendation is to use [[k1, v1], [k2, v2], ...] A nested array representing a collection of key-value pairs, K1, K2... Sort by the standard string.

The scheme with the same functionality as RLP is PROTOBUF or BSON, which is the algorithm used all the time. In Ethereum, however, we prefer to use RLP because :(1) it's easy to implement; (2) Absolute guarantee of byte consistency.

Many languages have no explicit ordering of their key-value collections, and floating point formats have many special cases that can result in different encodings and different hashes for the same data. Through internal development protocols, we can ensure that it is designed with these goals in mind (this is a general principle that also applies to other parts of the code, such as virtual machines). Bencode, the encoding method used by BitTorrent, may replace RLP. However, it uses the decimal encoding mode, compared with the use of binary RLP, a little inferior.

Compression algorithm

Both the network protocol and the database use a custom compression algorithm to store data. The algorithm can be described as follows: using stroke coding & NBSP for 0; 4 While preserving other values (except in special cases such as Sha3 (' ') & NBSP;) , the examples are as follows:

> > > compress('horse')

'horse'

> > > compress('donkey dragon 1231231243')'

donkey dragon 1231231243'

> > > compress('\xf8\xaf\xf8\xab\xa0\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x 00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x 00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x 00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x 00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x 00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\xbe{b\xd5\xcd\x8d\x87\x97')'

\xf8\xaf\xf8\xab\xa0\xfe\x9e\xbe{b\xd5\xcd\x8d\x87\x97'

> > > compress("\xc5\xd2F\x01\x86\xf7#< \x92~}\xb2\xdc\xc7\x03\xc0\xe5\x00\xb6S\xca\x82'; {\xfa\xd8\x04]\x85\xa4p")

"\ xfe \ x01 '

Before compression algorithms existed, there were some special cases in many places of the Ethereum protocol. For example, SHA3 was often redefined to make Sha3 (" ")= "", which eliminates the need to store code in the account and saves 64 bytes. Recently, however, all of these special cases that made Ethereum's data structure bloated have been removed, and instead data preservation functions have been added to layers outside the blockchain protocol, that is, into the network protocol and plugged into the user database implementation. This increases modularity, simplifies the consensus layer, and makes it relatively easy to deploy continuous updates to the compression algorithm (e.g., it can be distinguished and deployed by the network protocol version number).

Use of trees (TRIE)

Note: Understanding this part of the knowledge requires the reader to understand the Bloon filter. 5 The principle of. Brief introduction:

http://en.wikipedia.org/wiki/Bloom_filter

Each block header in the Ethereum blockchain contains Pointers to three trees: the state tree, the transaction tree, and the receipt tree.

• 状态树代表处理完该区块后的整个状态；

• 交易树代表区块中所有交易，这些交易由 index 索引作为 key；（例如，k0：第一个执行的交易，k1：第二个执行的交易）

• 收据树代表每笔交易相应的收据。

The receipt for the transaction is an RLP-encoded data structure:

[ medstate, gas_used, logbloom, logs ]

Among them:

• medstate：交易处理后，状态树的根；

• gas_used：交易处理后，gas 的使用量；

• logs：是许多 [address, [topic1, topic2...], data] 元素的列表。这些元素由交易执行期间调用的操作码 LOG0 ... LOG4 生成（包含主调用和子调用）；address 是生成日志的合约的地址；topics 是最多 4 个 32 字节的值；data 是任意大小的字节数组；

• logbloom：交易中所有 logs 的 address 和 topics 组成的布隆过滤器。

There is also a Bloon filter in the block header, which is the OR result of all Bloon filters for transactions in the block. This configuration makes the Ethereum protocol as friendly to light clients as possible.

Note:

"Outputs of transactions have not been quoted by any transaction as input," the author said. It is the data structure used in the Bitcoin protocol to store value (ownership) information. -- proofread note

2.Nonce, Number used once or the abbreviation of Number once. In cryptography, Nonce is an arbitrary or non-repeated random value that is only used once, which plays an important role in the initial vector and encryption hash function in encryption technology. Ensure that authentication information is not reused in communication applications of various authentication protocols to counter Replay attacks. -

3. Nested Arrays: Create an array and populate it with other arrays. PETS:

var cats : String[] = ["Cat","Beansprout", "Pumpkin", "Max"];var dogs : String[] = ["Dog","Oly","Sib"];
var pets : String = [cats, dogs];

4. Run-Length Encoding: A statistical encoding. The main technique is to detect repeated sequences of bits or characters and replace them with the number of occurrences. (Translator's Note

5. Bloon filter: Binary vector data structure proposed by Howard Bloom in 1970, which has good spatial and temporal efficiency, is used to detect whether an element is a member of a set or not. (Baidu Baike) -- Translator & NBSP;