Although Ethereum has adopted many design methods that have been tried and tested by cryptocurrencies like Bitcoin for more than five years, Ethereum still takes a different approach from other cryptocurrencies when it comes to handling certain protocol features, and in some cases Ethereum has been forced to develop a completely new approach to economics because it provides some features that other existing systems have not implemented. The purpose of this document is to elaborate on all of the great potential features and sometimes controversial aspects of building the Ethereum protocol, and the risks associated with our approach and possible alternatives.
in principle
The Ethereum protocol design process follows the following principles:
Sandwich complexity model: We believe that Ethereum’s underlying architecture should be as simple as possible, and Ethereum’s interfaces (including high-level programming languages and user interfaces for developers) should be as easy to understand as possible. The unavoidable complexity should be placed in the "middle layer" of the protocol, which does not involve the core consensus protocol and is not visible to end users - high-level language compilers, parameter serialization and deserialization scripts, storage data construction models, leveldb storage interfaces and wire protocols, etc. Still, these preferences are not absolute.
Freedom: We cannot restrict what users can do with the Ethereum protocol, nor can we try to pre-favor or dislike certain Ethereum contracts or transactions based on the characteristics of their purpose. This is a bit like the behavioral guiding principles behind "net neutrality." An example of such a criterion is, No To emulate the Bitcoin transaction protocol's use of the blockchain for "off-label" purposes (e.g., data storage, meta-protocol), changes to similar protocols (e.g., OP_RETURN limited to 40 bytes) in some cases may allow an application to be attacked using "unauthorized" ways of the blockchain. In Ethereum, we have a strong preference for setting transaction fees as an incentive-compatible approach so that users can use the blockchain to internalize the cost of their activity in a way that inflates production (i.e.: Pigovian taxation).
Summary: Protocol features and opcodes in Ethereum should reflect the underlying concepts to the maximum extent, so they can be combined in any way, including ways that may not seem very useful now but may be useful in the future. Therefore, many underlying concepts can be designed to be very efficient, and then eliminated when they are no longer needed. One example is that we used to follow our LOG opcode as a way to extract data for (especially light client) dapps, because it went against the internal early advice of simply logging all transactions and messages - the concept of a "message" is an aggregation of many concepts, including "function calls" and "events of interest to external observers", and it deserves to be split into two.
No features: As a direct result of generalization, we often refuse to build common higher-order use cases as intrinsic parts of the protocol, which means that if someone really wants to implement it, it can always be done by creating sub-protocols (e.g. ether-backed sub-protocols, bitcoin/litecoin/dogecoin sidechains, etc.) inside the contract. One such example is the lack of "locktime" features like Bitcoin's in Ethereum, because such features can be simulated through the protocol, where users send "signed packets" and then inject these packets into a special contract to process them and execute the corresponding functions if these packets meet the specifications defined by the contract.
non risk averse : We accept high risk if the risk-increasing changes can provide huge performance (for example: generalized state transition, 50 times packaging speed, consensus efficiency, etc.).
These principles have been adopted into Eethereum development, but they are not absolute； In some cases, the desire to reduce development time or not try too many radical things at once will lead us to delay certain changes, even if they are clearly beneficial, and choose to release them in the future (e.g. Ethereum 1.1).
Original text: https://github.com/ethereum/wiki/wiki/Design-Rationale
Translator's note:
Incentive-compatible:
https://en.wikipedia.org/wiki/Incentive_compatibility，
Personal understanding is a Nash equilibrium state reached by each participant in order to achieve maximum benefits and choose a relatively advantageous strategy.
Pigovian taxation：
https://en.wikipedia.org/wiki/Pigovian_tax
http://baike.baidu.com/view/139800.htm
Tax polluters according to the degree of harm caused by pollution, and use taxes to make up for the gap between the private costs and social costs of polluters' production, making them equal.
|
English
