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

二、以太坊

1. 以太坊(ETH)概述

1.1 区块链与以太坊

（1）BTC和ETH为最主要的两种加密货币，BTC称为区块链1.0，以太坊称为区块链2.0。之前文章中提出了比特币设计中存在某些不足，以太坊便对其进行了改进。例如：出块时间、共识机制、mining puzzle（BTC是计算密集型而ETH是memory-hard,对内存要求高，反ASIC芯片使用）。未来，以太坊还将会用权益证明(POS)替代工作量证明(POW)此外，以太坊增加了对智能合约（smart contract）的支持。

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

• 为什么要开发“智能合约”？

  答：BTC本身是一个去中心化的货币，在比特币取得成功之后，很多人就开始思考，除了货币可以去中心化，还有什么可以去中心化？以太坊的一个特性就是增加了对去中心化的合约的支持。如果说比特币系统本身是一个货币应用，以太坊则由于智能合约，升级成为了一个平台，用户可以依据该平台自行开发业务应用。

• 关于BTC和ETH

  答：BTC的发明人为中本聪(疑似日本人)，ETH为Vitalik Buterin收到BTC启发发明出来的““下一代加密货币与去中心化应用平台””。BTC中货币最小单位为“聪”，最少的钱为一聪；ETH中货币最小单位为“Wei”，最少的钱为一Wei。

• 去中心化的合约

  答：首先，讨论去中心化货币。货币本身由政府发行，政府公信力为其背书，BTC通过技术手段取代了政府的职能。现实生活中，我们经常提到“契约”或“合约”。合约的有效性也是需要政府进行维护的，如果产生 纠纷需要针对合法性合同进行判决。ETH的设计目的就是，通过技术手段来实现取代政府对于合约的职能。

• 那么，去中心化的合约有什么好处？

  答：若合同签署方并非一个国家，没有统一的司法部门（如：众筹）。如果可以编写无法修改的合约，所有人只能按照相关参与方执行，无法违约。

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）以太坊系统则采用了基于账户的模型，与现实中银行账户相似。系统中显示记录每个账户以太币的数量，转账是否合法只需要查看转账者账户中以太币是否足够即可，同时也不需要每次全部转账。同时，这也也天然地防范了双花攻击（double spending attack）。当然，以太坊发这种模式也存在缺点，这种模式存在重放攻击(replay attack)的缺陷。A向B转账，过一段时间，B将A的交易重新发布，从而导致A账户被扣钱两次。为了防范重放攻击，给账户交易添加计数器nonce（交易次数编号）记录该账户交易过多少次，转账时候将转账次数计入交易的内容中。系统中全节点维护账户余额和该计数器的交易数，从而防止本地篡改余额或进行重放攻击。

2.2 以太坊账户的设计

（1）以太坊系统中存在两类账户：外部账户（Externally owned account）和合约账户（smart contract account）。

• 外部账户：类似于BTC系统中公私钥对。存在账户余额balance和计数器nonce
• 合约账户：并非通过公私钥对控制。(不能主动发起交易，只能接收到外部账户调用后才能发起交易或调用其他合约账户)其除了balance和nonce之外还有code(代码)、storage(相关状态-存储)。创建合约时候会返回一个地址，就可以对其调用。调用过程中，代码不变但状态会发生改变。

（2）为什么要做以太坊，更换为基于账户的模型而不是沿袭BTC系统？

• 比特币中支持每次更换账户，但以太坊是为了支持智能合约，而合约签订双方是需要明确且较少变化的。尤其是对于合约账户来说，需要保持稳定状态。前一篇文章中有提过，以太坊采用基于账户的模式，系统中显式记录每个账户的余额。而以太坊这样一个大型分布式系统中，是采用的什么样的数据结构来实现对这些数据的管理的？下面我们开始介绍。

3. 以太坊(ETH)状态树

3.1 数据结构的构思

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

• 思路一：
  从直观地来看，其本质上为Key-value键值对，也就是通过给定账户地址找到相应的账户状态，所以直观想法是便用哈希表实现。系统中的全结点维护一个哈希表，每次你生成一个新的账户那么就插入到哈希表中。你要查询账户余额就直接在哈希表中查询。如果不考虑哈希碰撞的话，基本上查询效率是常数时间完成的。而且哈希表中更新也很容易。

  问题：但采用哈希表，难以提供Merkle proof（前面文章有提到过)。比如你要和一个人签合同，希望他证明一下他的账户余额，怎么提供这个证明？我们提供下面两个思路。
  注意：在BTC和以太坊中，交易保存在区块内部，一个区块可以包含多个交易。通过区块构成区块链，而非交易。

• 思路二：
  《1》 我们能否像BTC中，将哈希表中的元素组织为Merkle Tree，然后算出一个根哈希值，这个根哈希值保存在block header 里面，然后公布出去。那么只要根哈希值是正确的就能保证底下的树不被篡改。如果在以太坊中采用这种数据结构，可行吗？

  答：当新区块发布，哈希表内容会改变，再次将其组织为新的Merkle Tree。如果这样，每当产生新区块(ETH中新区块产生时间为10s左右)，都要重新组织Merkle Tree，很明显这是不现实的。

  注意：比特币系统中没有账户概念，交易由区块管理，每发布一个区块，对应一棵Merkel tree，然后这个Merkel tree构建完后不会再更改，下次再发布一个新的区块再构建一棵Merkel tree，而区块包含上限为4000个交易左右，所以Merkle Tree不是无限增大的。而ETH中，Merkle Tree来组织所有的账户信息，很明显其会越来越庞大。就相当于你每发布一个区块，你就要把所有账户遍历一遍，然后构建出一个Merkel tree，下次再有新区块，又得遍历一遍再构建。.在实际中，真正发生变化的账户状态仅仅为很少一部分，因为只有那个新区块中包含了交易的所关联的账户才会发生变化，大多数账户状态是不变的，所以每次重新构建Merkle Tree代价很大。此外Merkel tree 还有一个很重要的作用就是维护各个全节点之间状态的一致性，如果你没有把这个根哈希值发布出来，每个结点就在内部、本地维护一个数据结构，就无法知道你的数据结构状态和别人的数据结构状态