Ethereum设计基础理论(一)

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协议设计过程遵循以下原则:

  1. 三明治复杂模型:我们认为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_taxhttp://baike.baidu.com/view/139800.htm。根据污染所造成的危害程度对排污者征税,用税收来弥补排污者生产的私人成本社会成本之间的差距,使两者相等。

原文:https://github.com/ethereum/wiki/wiki/Design-Rationale

最后编辑于
©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 222,183评论 6 516
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 94,850评论 3 399
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 168,766评论 0 361
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 59,854评论 1 299
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 68,871评论 6 398
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 52,457评论 1 311
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 40,999评论 3 422
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 39,914评论 0 277
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 46,465评论 1 319
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 38,543评论 3 342
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 40,675评论 1 353
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 36,354评论 5 351
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 42,029评论 3 335
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 32,514评论 0 25
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 33,616评论 1 274
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 49,091评论 3 378
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 45,685评论 2 360

推荐阅读更多精彩内容