Although Ethereum borrows many ideas that have already been tried and tested for half a decade in older cryptocurrencies like Bitcoin, there are a number of places in which Ethereum diverges from the most common way of handling certain protocol features, and there are also many situations in which Ethereum has been forced to develop completely new economic approaches because it offers functionality that is not offered by other existing systems. The purpose of this document will be to detail all of the finer potentially nonobvious or in some cases controversial decisions that were made in the process of building the Ethereum protocol, as well as showing the risks involved in both our approach and possible alternatives.
尽管Ethereum采用了很多设计方法，这些方法已经被Bitcoin那样的加密数字货币试用和测试了超过五年之久，但是在处理某些特定协议功能时，Ethereum仍然采用了不同于其他加密货币的方法，并且在有些情况下Ethereum被迫开发了一种全新的经济学方法，因为它提供了一些其它现有系统不曾实现的功能。这个文档的目的是详细的阐述所有这些出色的潜在的特性，并且在Ethereum协议的构建过程中有时候会存在各种争议，同时我们的方法和可能的替代方法也伴随着一定的风险。
Principles
The Ethereum protocol design process follows a number of principles:
Sandwich complexity model: we believe that the bottom level architecture of Ethereum should be as simple as possible, and the interfaces to Ethereum (including high level programming languages for developers and the user interface for users) should be as easy to understand as possible. Where complexity is inevitable, it should be pushed into the "middle layers" of the protocol, that are not part of the core consensus but are also not seen by end users - high-level-language compilers, argument serialization and deserialization scripts, storage data structure models, the leveldb storage interface and the wire protocol, etc. However, this preference is not absolute.
原则
Ethereum协议设计过程遵循以下原则：
- 三明治复杂模型：我们认为Ethereum的底层架构应该尽可能的简单，Ethereum的接口（包括针对开发者的高级编程语言和用户的接口）应该尽可能的容易被理解。不可避免的复杂性，应该被放到协议的“中间层”，那里不涉及核心的共识协议，同时对终端用户也不可见 － 高级语言编译器，参数序列化和反序列化脚本，storage data构造模型，leveldb的存储接口和wire protocal等等。尽管如此，这些偏好也不是绝对的。
Freedom: users should not be restricted in what they use the Ethereum protocol for, and we should not attempt to preferentially favor or disfavor certain kinds of Ethereum contracts or transactions based on the nature of their purpose. This is similar to the guiding principle behind the concept of "net neutrality". One example of this principlenot being followed is the situation in the Bitcoin transaction protocol where use of the blockchain for "off-label" purposes (eg. data storage, meta-protocols) is discouraged, and in some cases explicit quasi-protocol changes (eg. OP_RETURN restriction to 40 bytes) are made to attempt to attack applications using the blockchain in "unauthorized" ways. In Ethereum, we instead strongly favor the approach of setting up transaction fees in such a way as to be roughly incentive-compatible, such that users that use the blockchain in bloat-producing ways internalize the cost of their activities (ie. Pigovian taxation).
自由：我们不能限制用户使用Ethereum协议来做什么，也不能尝试去预先喜好或者厌恶某些Ethereum合约或者交易，根据他们的目的的特点。这有点像“网络中立”背后的行为指导原则。一个这样的准则的例子是，不要效仿Bitcoin交易协议使用区块链的“off-label”目的（例如，数据存储，元协议），在某些情况下类似协议（例如OP_RETURN限制到40字节）的更改，可能会使用区块链的“未授权”方式攻击应用。在Ethereum中，我们强烈偏好于设置交易费用的方式作为一种激励相容，这样用户可以使用区块链在膨胀生产方式使他们活跃的成本内在化（也就是说：Pigovian taxation）。
Generalization: protocol features and opcodes in Ethereum should embody maximally low-level concepts, so that they can be combined in arbitrary ways including ways that may not seem useful today but which may become useful later, and so that a bundle of low-level concepts can be made more efficient by stripping out some of its functionality when it is not necessary. An example of this principle being followed is our choice of a LOG opcode as a way of feeding information to (particularly light client) dapps, as opposed to simply logging all transactions and messages as was internally suggested earlier - the concept of "message" is really the agglomeration of multiple concepts, including "function call" and "event interesting to outside watchers", and it is worth separating the two.
概括：Ethereum中的协议特性和操作码应该最大限度的体现底层概念，因此他们能以任意方式结合，包括那些现在可能看起来不是很有用但是将来可能会有用的方式，因此很多底层概念可以被设计的很高效，当它们不需要时再剔除掉。一个例子是，我们曾经遵循的我们的LOG操作码，作为为（尤其是轻客户端）dapp提取数据的方式，因为它违反了简单的记录所有的交易和消息的内部早期建议 －“消息“的概念是聚集了很多概念，包括”函数调用“和”外部观察者感兴趣的事件“，它值得分割成两个。
We Have No Features: as a corollary to generalization, we often refuse to build in even very common high-level use cases as intrinsic parts of the protocol, with the understanding that if people really want to do it they can always create a sub-protocol (eg. ether-backed subcurrency, bitcoin/litecoin/dogecoin sidechain, etc) inside of a contract. An example of this is the lack of a Bitcoin-like "locktime" feature in Ethereum, as such a feature can be simulated via a protocol where users send "signed data packets" and those data packets can be fed into a specialized contract that processes them and performs some corresponding function if the data packet is in some contract-specific sense valid.
无特性：作为概括的一个直接结果，我们经常拒绝内建常见的高阶的用例作为协议内在的部分，这意味着如果有人真的想要实现它，总是可以通过创建子协议（例如ether-backed子协议，bitcoin/litecoin/dogecoin sidechain等等）在合约内部。一个这样的例子是，在Ethereum中缺少Bitcoin那样的“locktime”特性，因为这样的特性可以通过协议去模拟，用户发送"签名的数据包"，然后这些数据包注入到一个特殊的合约来处理它们，执行相应的函数，如果这些数据包符合合约定义的规格时。
Non-risk-aversion: we are okay with higher degrees of risk if a risk-increasing change provides very substantial benefits (eg. generalized state transitions, 50x faster block times, consensus efficiency, etc)
非厌恶风险：我们接受高风险度，如果风险增加的改变能提供巨大的性能时（例如：普遍的状态转换，50倍的打包速度，共识效率等等）。
These principles are all involved in guiding Ethereum development, but they are not absolute; in some cases, desire to reduce development time or not to try too many radical things at once has led us to delay certain changes, even some that are obviously beneficial, to a future release (eg. Ethereum 1.1).
这些原则都被采纳到Eethereum开发中，但是它们并不是绝对的；在某些情况下，为了减少开发时间或者不要一次尝试太多激进的事情，会使我们延期某些特定改变，即便它们是明显有益的，而选择在未来发布（例如Ethereum1.1）。
译者注：
激励相容(incentive-compatible)：https://en.wikipedia.org/wiki/Incentive_compatibility，个人理解是每一个参与者为了达到最大收益，选择相对优势策略，而达到的一种纳什均衡状态。
Pigovian taxation：https://en.wikipedia.org/wiki/Pigovian_tax，http://baike.baidu.com/view/139800.htm。根据污染所造成的危害程度对排污者征税，用税收来弥补排污者生产的私人成本和社会成本之间的差距，使两者相等。
原文：https://github.com/ethereum/wiki/wiki/Design-Rationale