深入了解以太坊的本质

以太坊是比特币的综合改进。 以太坊自 2014 年以来首次进行众筹，其主要卖点是“智能合约”。

因此，“智能合约”是主导以太坊设计架构的核心概念。 从这个核心概念出发，我们很容易理清整个以太坊的设计脉络。

首先，“智能合约”的最终目标是实现去中心化应用（DAPP），因此决定底层建立在传统区块链的基础设施之上，

智能合约和账户类型/账户状态转换 首先，Merkle Tree 的天然属性使得只存储新旧块之间状态子树的变化成为可能，而不是重新存储整个结构。 为了防止恶意数据结构的构建以太坊减产周期，使用Keccake256哈希值作为树的键值以太坊减产周期，这就导致了使用Patricia Tree作为优化的必要性。 于是 Secure MPT 扭曲的数据结构催生了比特币及其变种，使用特殊的账户状态转换模型 UTXO 未花费的交易输出。 整个系统的余额状态信息都保存在所有这些 UTXO 中。 在每笔交易中，都会消耗掉一部分UTXO，然后会产生一些新的UTXO，并将UTXO绑定到用户地址上。 UTXO带来一个问题，智能合约需要一个执行主体。 在 UTXO 模型中，同一个主体可以有多个地址。 对于智能合约，最简单直接的解决方案是使用单一账户模型而不是 UTXO，尤其是在引入 Gas 以限制计算工作量之后。 如果智能合约仍然需要实时计算（并解锁）多个地址中 UTXO 的可用代币数量来判断合约是否可以继续执行，这样的操作过于繁琐且效率低下。 以太坊最终采用了合约账户作为单一的执行主体，而为了配合合约账户，外部账户也采用了单一账户的记账方式。

简化设计。 因为在合约执行的时候，外部账户也需要转Gas来执行合约。 同时，还要考虑节省空间。 UTXO本身占用空间很大，因为同一个用户可能需要引用多个UTXO。 以太坊加入了智能合约，因此必须存储许多其他要存储的元数据（如输入数据、日志）。 寻找节省空间的解决方案。 单账户模式需要引入nonce来防止重放攻击，所以这里也做了防御设计。 引入单账户模型之后，自然而然引入了基于Secure Merkle Patricia Tree设计的整个存储状态的数据结构设计。 智能合约需要图灵完备的解决方案。 灵活的智能合约编程语言当然最好是图灵完备的。 但是图灵完备性需要计算每条指令消耗的计算资源（防止滥用，比如死循环），所以Gas的设计应运而生。 考虑到合约之间调用等各种复杂场景，引入了很多规则来规范Gas消耗的计算。 （整套规则很复杂，比如合约自杀的场景）合约执行会中途失败，需要引入各种日志进行回滚。 同时Gas必须和token挂钩，所以Gas也是有价格的，当然是以ether计算的。

同时，整个区块的大小也不是固定的，而是由区块整体所能包含的Gas量决定的。 用于智能合约执行的虚拟机。 为了执行智能合约，有必要区分全局存储和临时存储。 临时存储的生命周期仅限于虚拟机实例从开始到执行结束的执行过程。 永久存储存在于区块链上，每个账户作为一个划分单元（存储树），并负责检查所有的 Gas 规则。 需要向智能合约编程语言提供所有全局状态量查询结构。 需要提供特定的密码计算接口。 例如，keccak 智能合约的编程语言是在基本功能之外的。 自然地，编程语言需要面向契约。 一个合约当然也应该有一个创建者和一个所有者。 合约应该能够接收转账，以及向其他合约和外部账户的转账。 编程语言需要区分全局存储和临时存储。 编程语言需要方便的外部接口 ABI。 编程语言的设计必须是安全的，合约可以被形式化验证。

综上所述，智能合约的概念影响了以太坊所有关键组件的设计，并渗透到每一个具体的设计中。 只要把握好这个核心概念，勾勒引领，顺藤摸瓜，就会大大加速你对以太坊的理解。 了解车间设计框架。

深入以太坊课程更新完毕，两天后即可完成课程。 请加入“区块极客”知识星球社区进行答疑。 目前已聚集超过1500名区块链开发者。