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倍的打包速度，共识效率等等）。