区块链学习笔记之以太坊（一）

区块链学习笔记

二、以太坊 一、以太坊（ETH）概述 1.1 区块链与以太坊

(1) BTC和ETH是两种主要的加密货币，BTC被称为区块链1.0，以太坊被称为区块链2.0。 前文指出比特币在设计上存在一些不足，以太坊对其进行了改进。 例如：出块时间、共识机制、挖矿难题（BTC是计算密集型的，而ETH是memory-hard，对内存要求高以太坊数据，是抗ASIC芯片）。 未来，以太坊还将用权益证明（POS）取代工作量证明（POW）。 此外，以太坊还增加了对智能合约的支持。

（二）关于以太坊几个问题的讨论

2. 以太坊（ETH）账户 2.1 从交易型到账户型

(1) BTC系统是一种基于交易的账本。 系统不会显示账户中记录了多少钱，只能通过 UTXO 进行估算。 但在实际使用中，使用起来比较别扭。

例如：A向B转账时，需要说明币种的来源。 实际操作中，只需要省钱说明出处，不需要花钱。 另外，账户里的钱花的时候，一定要一次性花完。 如下图，B收到A的10个BTC，他要给C 3个BTC。 如果按照1中的方法，剩下的7个比特币将以交易手续费的形式分给挖出区块的矿工。 因此，为了避免这种情况，采用2种方式比较有吸引力，转3个BTC给C，剩下的7个BTC转给另一个账户B'。

(2) 以太坊系统采用基于账户的模式，类似于现实中的银行账户。 系统显示并记录每个账户中的以太币数量。 转账是否合法只需要检查转账方账户中是否有足够的Ether，并不需要每次都转完所有的钱。 同时，它也自然地防止了双花攻击。 当然，以太坊的这种模式也有缺点。 这种模式存在重放攻击的缺陷。 A转账给B，过了一段时间，B重新发布了A的交易，导致A的账户被扣了两次。 为了防止重放攻击，在账户交易中加入counter nonce（交易编号）来记录该账户交易了多少次，转账时将转账次数包含在交易内容中。 系统中的全节点维护账户余额和计数器的交易数量，从而防止本地篡改余额或重放攻击。

2.2 以太坊账户设计

(1) 以太坊系统中的账户分为两类：外部拥有账户和智能合约账户。

(2) 为什么做以太坊并用基于账户的模型代替它而不是遵循 BTC 系统？

3. 以太坊（ETH）状态树 3.1 数据结构的概念

(1) 首先，我们需要实现账户地址到账户状态的映射。 在以太坊中，账户地址为 160 位，用 40 个十六进制数表示。 状态包括余额（balance）、交易数量（nonce），合约账户还包括代码（code）和存储（stroge）。 那么设计什么样的数据结构来实现这种映射呢？

3.2 以太坊数据结构MPT

既然没有哈希表和Merkle Trees，那我们就来看看以太坊实际采用的数据结构：MPT（Merkle Patrica tree）。

(1) 先介绍一个简单的数据结构——trie（字典树、前缀树）

下面是一个由5个词组成的trie数据结构（只画出key，不画出value）

(2)帕特里夏树(Patricia tree)，帕特里夏树是一种带有路径压缩的前缀树，有时也称为压缩前缀树。 如下例所示，进行路径压缩后，如下图所示：

(3) 因此，我们可以在以太坊账户管理中使用帕特里夏树的数据结构！ 但实际上，以太坊中使用的并不是简单的PT（Patricia tree），而是MPT（Merkle Patricia tree）。 关于MPT内容：

(4) 改良的MPT（Modified Merkle Patricia tree）

以太坊中正并没有使用原来的MPT，而是对MPT（Merkle Patricia树）进行了修改，但没有做任何本质上的改变。 我们称之为 MPT（修改后的 Merkle Patricia 树）。 下图是以太坊中使用的 MPT 结构示意图。

注意：上面是状态树。 修改后的 MPT 与 MPT 并不完全相同。 它有扩展节点和分支节点。

(5) 每发布一个新区块，状态树中部分节点的状态就会发生变化。 但是改变不是原地修改，而是创建一些分支，保持原来的状态。 如下图所示：

(6) 总结与讨论： 因此，系统中的所有节点并不维护一个MPT，而是在每次发布新区块时创建一个新的MPT。 只是这些状态树中的大部分节点都是共享的，只有少数发生变化的节点需要创建新的分支。

(7) 通过代码看以太坊中的数据结构：

1. 区块头中的数据结构

2. 块状结构

(8) 前面我们说过，键值对存储在树中，键就是地址。 我们介绍了key-value地址的管理方式，那么state这个东西里面的value（账户的状态）是怎么存储的呢？

4. 以太坊（ETH）交易树和收据树 4.1 数据结构设计

(1) 每发布一个区块，这个区块包含的交易就会形成一个Merkle Tree，即交易树。 此外，以太坊还增加了收据树，每笔交易执行后形成一张收据，记录交易相关信息。 也就是说，交易树上的节点和收据树上的节点是一一对应的。

(2) 由于以太坊智能合约的执行比较复杂，通过增加收据树的结构可以方便快速查询执行结果。 交易树和收据树都是M(Merkle) PT，而BTC使用的是普通的MT，即区块中的所有交易形成一棵普通的Merkle Tree。 或许是为了方便，以太坊中的三棵树都使用了相同的数据结构，这样代码比较统一，便于管理。

(3)MPT的优点是支持查找操作，可以通过key值沿着树从上到下查找。 对于状态树，搜索键值为账户地址； 对于交易树和回执树，搜索键值是交易在发布区块中的序号，交易的顺序由发布区块的节点决定。

(4) 交易树和收据树只组织当前发布区块中的交易，而状态树包括所有账户的状态，不管这些账户是否与当前区块中的交易相关。 多个区块状态树共享节点，而交易树和回执树是独立的，不共享节点。 为一个区块和另一个区块发布的交易本身是独立的。

(5) 交易树和收据树的用途：

1. 为轻节点提供Merkle Proof。

2.更复杂的搜索操作

例如：如何查找过去十天内与智能合约相关的所有交易？

(6)布隆过滤器(Bloom filter)，支持更高效地搜索一个元素是否在一个比较大的集合中。 比如有一个集合，里面有很多元素，你想知道某个指定的元素是否在集合中，怎么办？

(6) 知识补充

（七）问题讨论

4.2 代码中的具体数据结构

(1) 交易树和收据树的创建过程

(2) 下面这段代码是处理叔块的，后面讲解Ghost协议的时候会详细介绍，这里做一个大概的介绍。 首先，检查叔叔列表是否为空。 如果是，那么区块头中叔块的哈希值为空哈希值。 否则，通过调用CalcUncleHash()函数计算哈希值，然后循环构造区块中的叔叔数组。

(3)我们看DeriveSha()函数以太坊数据，如下图，前面的NewBlock()函数在创建交易树和收据树时调用了这个函数。 它这里创建的数据结构是一个trie，trie的数据结构是一个MPT。

(4)看收据的数据结构，如下图，每笔交易执行后都会形成一张收据，记录交易的执行结果，这里的Bloom字段就是收据的布隆过滤器. logs的域是一个数组，每个receipt可以包含多条logs，receipt中的Bloom filter就是根据这些logs生成的

(5) 下面是三个相关函数的代码实现，CreateBloom()、LogBloom()、bloom9()，这三个函数的代码实现。

结语

终于把以太坊的入门理论第一部分讲完了，以太坊部分预计分三期发。 下一部分将解释 GHost 协议、挖矿算法、股权证明和智能合约。 最后一部分将重点介绍几个已经在以太坊上线的智能合约项目。 如果看完这篇博客还有不明白的，可以看看北大肖震老师的公开课。 这篇博客是参考这门课程写的。 另外，如果觉得这个博客不错，请给个三连。 更新不易，谢谢。