以太坊模型说明

以太坊的本质就是一个基于交易的状态机(transaction-based state machine)。在计算机科学中，一个 状态机 是指可以读取一系列的输入，然后根据这些输入，会转换成一个新的状态出来的东西。

根据以太坊的状态机，我们从创世纪状态(genesis state)开始。这差不多类似于一片空白的石板，在网络中还没有任何交易的产生状态。当交易被执行后，这个创世纪状态就会转变成最终状态。在任何时刻，这个最终状态都代表着以太坊当前的状态。

以太坊的状态有百万个交易。这些交易都被“组团”到一个区块中。一个区块包含了一系列的交易，每个区块都与它的前一个区块链接起来。

为了让一个状态转换成下一个状态，交易必须是有效的。为了让一个交易被认为是有效的，它必须要经过一个验证过程，此过程也就是挖矿。挖矿就是一组节点（即电脑）用它们的计算资源来创建一个包含有效交易的区块出来。

前面，我们定义了区块链就是一个具有共享状态的交易单机。使用这个定义，我们可以知道正确的当前状态是一个全球的真相，所有人都必须要接受它。拥有多个状态（或多个链）会摧毁这个系统，因为它在“哪个是正确状态”的问题上不可能得到统一结果。如果链分叉了，你有可能在一条链上拥有10个币，一条链上拥有20个币，另一条链上拥有40个币。在这种场景下，是没有办法确定哪个链才是最”有效的“。

我们在再深入了地解一下以太坊系统主要组成部分：

1. 账户(accounts)

2. 状态(state)

3. 损耗和费用(gas and fees)

4. 交易(transactions)

5. 区块(blocks)

6. 交易执行(transaction execution)

7. 挖矿(mining)

8. 工作量证明(proof of work)

在开始之前需要注意的是：每当我说某某的hash， 我指的都是KECCAK-256 hash, 以太坊就是使用这个hash算法。

账户

以太坊的全局“共享状态”是由很多小对象（账户）来组成的，这些账户可以通过消息传递架构来与对方进行交互。每个账户都有一个与之关联的状态(state)和一个20字节的地址(address)。

账户类型有两种：

1. 外部拥有的账户，由私钥控制且没有任何代码与之关联。

2. 合约账户，被它们的合约代码控制且有代码与之关联。

外部拥有账户与合约账户的比较

理解外部拥有账户和合约账户的基本区别是很重要的。一个外部拥有账户可以通过创建和用自己的私钥来对交易进行签名，来发送消息给另一个外部拥有账户或合约账户。在两个外部拥有账户之间传送的消息只是一个简单的价值转移。但是从外部拥有账户到合约账户的消息会激活合约账户的代码，允许它执行各种动作。（比如转移代币，写入内部存储，挖出一个新代币，执行一些运算，创建一个新的合约等等）。

不像外部拥有账户，合约账户不可以自己发起一个交易。因此，在以太坊上任何的动作，总是以外部拥有账户所发起的交易来开始。

账户状态

账户状态有四个组成部分，不论账户类型是什么，都存在这四个组成部分：

1. nonce：如果账户是一个外部拥有账户，nonce代表从此账户地址发送的交易序号。如果账户是一个合约账户，nonce代表此账户创建的合约序号。

2. balance： 此地址拥有Wei的数量。1Ether=1018 Wei。

3. storageRoot： Merkle Patricia树的根节点Hash值（我们后面在解释Merkle树）。Merkle树会将此账户存储内容的Hash值进行编码，默认是空值。

4. codeHash：此账户EVM（以太坊虚拟机，后面细说）代码的hash值。对于合约账户，就是被Hash的代码并作为codeHash保存。对于外部拥有账户，codeHash域是一个空字符串的Hash值

世界状态

好了，我们知道了以太坊的全局状态就是由账户地址和账户状态的一个映射组成。这个映射被保存在一个叫做Merkle Patricia树的数据结构中。

Merkle Tree（也被叫做Merkle trie）是一种由一系列节点组成的二叉树，这些节点包括：

1. 在树底的包含了源数据的大量叶子节点。

2. 一系列的中间的节点，这些节点是两个子节点的Hash值。

3. 一个根节点，同样是两个子节点的Hash值，代表着整棵树。

树底的数据是通过分开我们想要保存到chunks的数据产生的，然后将chunks分成buckets，再然后再获取每个bucket的hash值并一直重复直到最后只剩下一个Hash：根Hash。

这棵树要求存在里面的值（value）都有一个对应的key。从树的根节点开始，key会告诉你顺着哪个子节点可以获得对应的值，这个值存在叶子节点。在以太坊中，key/value是地址和与地址相关联的账户之间状态的映射，包括每个账户的balance, nonce, codeHash和storageRoot（storageRoot自己就是一颗树）。

同样的树结构也用来存储交易和收据。更具体的说，每个块都有一个头(header)，保存了三个不同Merkle trie结构的根节点的Hash，包括：

1. 状态树

2. 交易树

3. 收据树

在Merkle tries中存储所有信息的高效性在以太坊中的“轻客户端”和“轻节点”相当的有用。

Gas和费用

在以太坊中一个比较重要的概念就是费用(fees)，由以太坊网络上的每一次交易都会产生费用，因为没有免费的午餐。这个费用是以”gas”来支付。

gas就是用来衡量在一笔交易中要求的手续费用单位。gas price就是你愿意在每个gas上花费Ether的数量，以“gwei”进行衡量。“Wei”是Ether的最小单位，1Ether表示1018 Wei. 1gwei是1,000,000,000 Wei。

对每个交易，发送者设置gas limit和gas price。gas limit和gas price就代表着发送者愿意为执行交易支付的Wei的最大值。

例如，假设发送者设置gas limit为50,000，gas price为20gwei。这就表示发送者愿意最多支付50,000*20gwei = 1,000,000,000,000,000 Wei = 0.001 Ether来执行此交易。

记住gas limit代表用户愿意花费在gas上的钱的最大值。如果在他们的账户余额中有足够的Ether来支付这个最大值费用，那么就没问题。在交易结束时任何未使用的gas都会被返回给发送者，以原始费率兑换。

在发送者没有提供足够的gas来执行交易，那么交易执行就会出现“gas不足”然后被认为是无效的。在这种情况下，交易处理就会被终止以及所有已改变的状态将会被恢复，最后我们就又回到了交易之前的状态—完完全全的之前状态就像这笔交易从来没有发生。因为机器在耗尽gas之前还是为计算做出了努力，
所以理论上，将不会有任何的gas被返回给发送者。

这些gas的钱到底去了哪里？发送者在gas上花费的所有钱都发送给了“受益人”地址，通常情况下就是矿工的地址。因为矿工为了计算和验证交易做出了努力，所以矿工接收gas的费用作为奖励。

通常，发送者愿意支付更高的gas price，矿工从这笔交易总就能获得更多的价值。因此，矿工也就更加愿意选择这笔交易。这样的话，矿工可以自由的选择一笔交易自己愿意验证或忽略。为了引导发送者应该设置gas price为多少，矿工可以选择建议一个最小的gas值他们愿意执行一个交易。

存储也有费用

gas不仅仅是用来支付计算这一步的费用，而且也用来支付存储的费用。存储的总费用与所使用的32位字节的最小倍数成比例。

费用的作用是什么？

以太坊可以运作的一个重要方面就是每个网络执行的操作同时也被全节点所影响。然而，计算的操作在以太坊虚拟机上是非常昂贵的。因此，以太坊智能合约最好是用来执行最简单的任务，比如运行一个简单的业务逻辑或者验证签名和其他密码对象，而不是用于复杂的操作，比如文件存储，电子邮件，或机器学习，这些会给网络造成压力。施加费用防止用户使网络超负荷。

以太坊是一个图灵完备语言（短而言之，图灵机器就是一个可以模拟任何电脑算法的机器。）。这就允许有循环，并使以太坊受到停机问题 的影响，这个问题让你无法确定程序是否无限制的运行。如果没有费用的话，恶意的执行者通过执行一个包含无限循环的交易就可以很容易的让网络瘫痪而不会产生任何反响。因此，费用保护网络不受蓄意攻击。

你也许会想，“为什么我们还需要为存储付费？”其实就像计算一样，以太坊网络上的存储是整个网络都必须要负担的成本。

交易和消息

之前说过以太坊是一个基于交易的状态机。换句话说，在两个不同账户之间发生的交易才让以太坊全球状态从一个状态转换成另一个状态。

最基本的概念，一个交易就是被外部拥有账户生成的加密签名的一段指令，序列化，然后提交给区块链。

有两种类型的交易：消息通信和合约创建(也就是交易产生一个新的以太坊合约)。

不管什么类型的交易，都包含：

1. nonce：发送者发送交易数的计数

2. gasPrice：发送者愿意支付执行交易所需的每个gas的Wei数量

3. gasLimit：发送者愿意为执行交易支付gas数量的最大值。这个数量被设置之后在任何计算完成之前就会被提前扣掉

4. to：接收者的地址。在合约创建交易中，合约账户的地址还没有存在，所以值先空着

5. value：从发送者转移到接收者的Wei数量。在合约创建交易中，value作为新建合约账户的开始余额

6. v,r,s：用于产生标识交易发生着的签名

7. init（只有在合约创建交易中存在）：用来初始化新合约账户的EVM代码片段。init值会执行一次，然后就会被丢弃。当init第一次执行的时候，它返回一个账户代码体，也就是永久与合约账户关联的一段代码。

8. data（可选域，只有在消息通信中存在）：消息通话中的输入数据(也就是参数)。例如，如果智能合约就是一个域名注册服务，那么调用合约可能就会期待输入域例如域名和IP地址

在“账户”这个章节中我们学到交易—消息通信和合约创建交易两者都总是被外部拥有账户触发并提交到区块链的。换种思维思考就是，交易是外部世界和以太坊内部状态的桥梁。

但是这也并不代表一个合约与另一个合约无法通信。在以太坊状态全局范围内的合约可以与在相同范围内的合约进行通信。他们是通过“消息”或者“内部交易”进行通信的。我们可以认为消息或内部交易类似于交易，不过与交易有着最大的不同点—它们不是由外部拥有账户产生的。相反，他们是被合约产生的。它们是虚拟对象，与交易不同，没有被序列化而且只存在与以太坊执行环境。

当一个合约发送一个内部交易给另一个合约，存在于接收者合约账户相关联的代码就会被执行。

一个重要需要注意的事情是内部交易或者消息不包含gasLimit。因为gas limit是由原始交易的外部创建者决定的（也就是外部拥有账户）。外部拥有账户设置的gas limit必须要高到足够将交易完成，包括由于此交易而产生的任何”子执行”，例如合约到合约的消息。如果，在一个交易或者信息链中，其中一个消息执行使gas已不足，那么这个消息的执行会被还原，包括任何被此执行触发的子消息。不过，父执行没必要被还原。

区块头

让我们再回到区块的问题上。我们前面提到每个区块都有一个“区块头”，但这究竟是什么？

区块头是一个区块的一部分，包含了：

1. parentHash：父区块头的Hash值（这也是使得区块变成区块链的原因）

2. ommerHash：当前区块ommers列表的Hash值

3. beneficiary：接收挖此区块费用的账户地址

4. stateRoot：状态树根节点的Hash值（回忆一下我们之前所说的保存在头中的状态树以及它使得轻客户端认证任何关于状态的事情都变得非常简单）

5. transactionsRoot：包含此区块所列的所有交易的树的根节点Hash值

6. receiptsRoot：包含此区块所列的所有交易收据的树的根节点Hash值

7. logsBloom：由日志信息组成的一个Bloom过滤器（数据结构）

8. difficulty： 此区块的难度级别

9. number：当前区块的计数（创世纪块的区块序号为0，对于每个后续区块，区块序号都增加1）

10. gasLimit：每个区块的当前gas limit

11. gasUsed： 此区块中交易所用的总gas量

12. timestamp：此区块成立时的unix的时间戳

13. extraData：与此区块相关的附加数据

14. mixHash：一个Hash值，当与nonce组合时，证明此区块已经执行了足够的计算

15. nonce：一个Hash值，当与mixHash组合时，证明此区块已经执行了足够的计算

注意每个区块是如何包含三个树结构的，三个树结构分别对应：

1. 状态（stateRoot）

2. 交易（transactionsRoot）

3. 收据（receiptsRoot）

这三个树结构就是我们前面讨论的Merkle Patricia树。

另外，上面描述的有几个术语值得说明一下，下面来看一下。

日志

以太坊允许日志可以跟踪各种交易和信息。一个合约可以通过定义“事件”来显示的生成日志。

一个日志的实体包含：

1. 记录器的账户地址

2. 代表本次交易执行的各种事件的一系列主题以及与这些事件相关的任何数据

日志被保存在bloom过滤器 中，过滤器高效的保存了无尽的日志数据。

交易收据

自于被包含在交易收据中的日志信息存储在头中。就像你在商店买东西时收到的收据一样，以太坊为每笔交易都产生一个收据。像你期望的那样，每个收据包含关于交易的特定信息。这些收据包含着：

1. 区块序号

2. 区块Hash

3. 交易Hash

4. 当前交易使用了的gas

5. 在当前交易执行完之后当前块使用的累计gas

6. 执行当前交易时创建的日志

7. 等等

区块难度

区块的难度是被用来在验证区块时加强一致性。创世纪区块的难度是131,072，有一个特殊的公式用来计算之后的每个块的难度。如果某个区块比前一个区块验证的更快，以太坊协议就会增加区块的难度。

区块的难度影响nonce，它是在挖矿时必须要使用proof-of-work算法来计算的一个hash值。

区块难度和nonce之间的关系用数学形式表达就是：

Hd代表的是难度。

找到符合难度阈值的nonce唯一方法就是使用proof-of-work算法来列举所有的可能性。找到解决方案预期时间与难度成正比—难度越高，找到nonce就越困难，因此验证一个区块也就越难，这又相应地增加了验证新块所需的时间。所以，通过调整区块难度，协议可以调整验证区块所需的时间。

另一方面，如果验证时间变的越来越慢，协议就会降低难度。这样的话，验证时间自我调节以保持恒定的速率—平均每15s一个块。

交易执行

我们已经到了以太坊协议最复杂的部分：交易的执行。假设你发送了一笔交易给以太坊网络处理，将以太坊状态转换成包含你的交易这个过程到底发生了什么？

首先，为了可以被执行所有的交易必须都要符合最基础的一系列要求，包括：

• 交易必须是正确格式化的RLP。”RLP”代表Recursive Length Prefix，它是一种数据格式，用来编码二进制数据嵌套数组。以太坊就是使用RLP格式序列化对象。

• 有效的交易签名。

• 有效的交易序号。回忆一下账户中的nonce就是从此账户发送出去交易的计数。如果有效，那么交易序号一定等于发送账户中的nonce。

• 交易的gas limit 一定要等于或者大于交易使用的intrinsic gas，intrinsic gas包括：
  ——-1.执行交易预订费用为21,000gas
  ——-2.随交易发送的数据的gas费用（每字节数据或代码为0的费用为4gas，每个非零字节的数据或代码费用为68gas）
  ——-3.如果交易是合约创建交易，还需要额外的32,000gas

• 发送账户余额必须有足够的Ether来支付”前期”gas费用。前期gas费用的计算比较简单：首先，交易的gas limit乘以交易的gas价格得到最大的gas费用。然后，这个最大gas费用被加到从发送方传送给接收方的总值。

如何交易符合上面所说的所有要求，那么我们进行下面步骤。

第一步，我们从发送者的余额中扣除执行的前期费用，并为当前交易将发送者账户中的nonce增加1。此时，我们可以计算剩余的gas，将交易的总gas减去使用的intrinsic gas。

第二步，开始执行交易。在交易执行的整个过程中，以太坊保持跟踪“子状态”。子状态是记录在交易中生成的信息的一种方式，当交易完成时会立即需要这些信息。具体来说，它包含：

1. 自毁集：在交易完成之后会被丢弃的账户集（如果存在的话）

2. 日志系列：虚拟机的代码执行的归档和可检索的检查点

3. 退款余额：交易完成之后需要退还给发送账户的总额。回忆一下我们之前提到的以太坊中的存储需要付费，发送者要是清理了内存就会有退款。以太坊使用退款计数进行跟踪退款余额。退款计数从0开始并且每当合约删除了一些存储中的东西都会进行增加。

第三步，交易所需的各种计算开始被处理。

当交易所需的步骤全部处理完成，并假设没有无效状态，通过确定退还给发送者的未使用的gas量，最终的状态也被确定。除了未使用的gas，发送者还会得到上面所说的“退款余额”中退还的一些津贴。

一旦发送者得到退款之后：

1. gas的Ether就会矿工

2. 交易使用的gas会被添加到区块的gas计数中（计数一直记录当前区块中所有交易使用的gas总量，这对于验证区块时是非常有用的）

3. 所有在自毁集中的账户（如果存在的话）都会被删除

最后，我们就有了一个新的状态以及交易创建的一系列日志。

现在我们已经介绍了交易执行的基本知识，让我们再看看合约创建交易和消息通信的一些区别。

合约创建(Contract creation)

回忆一下在以太坊中，有两种账户类型：合约账户和外部拥有账户。当我们说一个交易是“合约创建”，是指交易的目的是创建一个新的合约账户。

为了创建一个新的合约账户，我们使用一个特殊的公式来声明新账户的地址。然后我们使用下面的方法来初始化一个账户：

1. 设置nonce为0

2. 如果发送者通过交易发送了一定量的Ether作为value，那么设置账户的余额为value

3. 将存储设置为0

4. 设置合约的codeHash为一个空字符串的Hash值

一旦我们完成了账户的初始化，使用交易发送过来的init code（查看”交易和信息”章节来复习一下init code），实际上就创造了一个账户。init code的执行过程是各种各样的。取决于合约的构造器，可能是更新账户的存储，也可能是创建另一个合约账户，或者发起另一个消息通信等等。

当初始化合约的代码被执行之后，会使用gas。交易不允许使用的gas超过剩余gas。如果它使用的gas超过剩余gas，那么就会发生gas不足异(OOG)常并退出。如果一个交易由于gas不足异常而退出，那么状态会立刻恢复到交易前的一个点。发送者也不会获得在gas用完之前所花费的gas。

不过，如果发送者随着交易发送了Ether，即使合约创建失败Ether也会被退回来。

如果初始化代码成功的执行完成，最后的合约创建的花费会被支付。这些是存储成本，与创建的合约代码大小成正比（再一次，没有免费的午餐）。如果没有足够的剩余gas来支付最后的花费，那么交易就会再次宣布gas不足异常并中断退出。

如果所有的都正常进行没有任何异常出现，那么任何剩余的未使用gas都会被退回给原始的交易发送者，现在改变的状态才被允许永久保存。

消息通信(Message calls)

消息通信的执行与合约创建比较类似，只不过有一点点区别。

由于没有新账户被创建，所以消息通信的执行不包含任何的init code。不过，它可以包含输入数据，如果交易发送者提供了此数据的话。一旦执行，消息通信同样会有一个额外的组件来包含输出数据，如果后续执行需要此数据的话就组件就会被使用。

就像合约创建一样，如果消息通信执行退出是因为gas不足或交易无效（例如栈溢出，无效跳转目的地或无效指令），那么已使用的gas是不会被退回给原始触发者的。相反，所有剩余的未使用gas也会被消耗掉，并且状态会被立刻重置为余额转移之前的那个点。

没有任何方法停止或恢复交易的执行而不让系统消耗你提供的所有gas，直到最新的以太坊更新。例如，假设你编写了一个合约，当调用者没有授权来执行这些交易的时候抛出一个错误。在以太坊的前一个版本中，剩余的gas也会被消耗掉，并且没有任何gas退回给发送者。但是拜占庭更新包括了一个新的“恢复”代码，允许合约停止执行并且恢复状态改变而不消耗剩余的gas，此代码还拥有返回交易失败原因的能力。如果一个交易是由于恢复而退出，那么未使用的gas就会被返回给发送者。