Ethereum设计基础理论(一)

张亚宁   |     |   2106 次阅读

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


尽管Ethereum采用了很多设计方法,这些方法已经被Bitcoin那样的加密数字货币试用和测试了超过五年之久,但是在处理某些特定协议功能时,Ethereum仍然采用了不同于其他加密货币的方法,并且在有些情况下Ethereum被迫开发了一种全新的经济学方法,因为它提供了一些其它现有系统不曾实现的功能。这个文档的目的是详细的阐述所有这些出色的潜在的特性,并且在Ethereum协议的构建过程中有时候会存在各种争议,同时我们的方法和可能的替代方法也伴随着一定的风险。

原则

Ethereum协议设计过程遵循以下原则:

  1. 三明治复杂模型:我们认为Ethereum的底层架构应该尽可能的简单,Ethereum的接口(包括针对开发者的高级编程语言和用户的接口)应该尽可能的容易被理解。不可避免的复杂性,应该被放到协议的“中间层”,那里不涉及核心的共识协议,同时对终端用户也不可见 - 高级语言编译器,参数序列化和反序列化脚本,storage data构造模型,leveldb的存储接口和wire protocal等等。尽管如此,这些偏好也不是绝对的。

  2. 自由:我们不能限制用户使用Ethereum协议来做什么,也不能尝试去预先喜好或者厌恶某些Ethereum合约或者交易,根据他们的目的的特点。这有点像“网络中立”背后的行为指导原则。一个这样的准则的例子是,要效仿Bitcoin交易协议使用区块链的“off-label”目的(例如,数据存储,元协议),在某些情况下类似协议(例如OP_RETURN限制到40字节)的更改,可能会使用区块链的“未授权”方式攻击应用。在Ethereum中,我们强烈偏好于设置交易费用的方式作为一种激励相容,这样用户可以使用区块链在膨胀生产方式使他们活跃的成本内在化(也就是说:Pigovian taxation)。

  3. 概括:Ethereum中的协议特性和操作码应该最大限度的体现底层概念,因此他们能以任意方式结合,包括那些现在可能看起来不是很有用但是将来可能会有用的方式,因此很多底层概念可以被设计的很高效,当它们不需要时再剔除掉。一个例子是,我们曾经遵循的我们的LOG操作码,作为为(尤其是轻客户端)dapp提取数据的方式,因为它违反了简单的记录所有的交易和消息的内部早期建议 -“消息“的概念是聚集了很多概念,包括”函数调用“和”外部观察者感兴趣的事件“,它值得分割成两个。

  4. 无特性:作为概括的一个直接结果,我们经常拒绝内建常见的高阶的用例作为协议内在的部分,这意味着如果有人真的想要实现它,总是可以通过创建子协议(例如ether-backed子协议,bitcoin/litecoin/dogecoin sidechain等等)在合约内部。一个这样的例子是,在Ethereum中缺少Bitcoin那样的“locktime”特性,因为这样的特性可以通过协议去模拟,用户发送"签名的数据包",然后这些数据包注入到一个特殊的合约来处理它们,执行相应的函数,如果这些数据包符合合约定义的规格时。

  5. 非厌恶风险:我们接受高风险度,如果风险增加的改变能提供巨大的性能时(例如:广义的状态转换,50倍的打包速度,共识效率等等)。

这些原则都被采纳到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
根据污染所造成的危害程度对排污者征税,用税收来弥补排污者生产的私人成本社会成本之间的差距,使两者相等。

 
2 人喜欢