1 以太坊和比特币工作机制的区别
- 出块时间：以太坊出块时间短，比特币出块时间大约是10min而以太坊的出块时间大约是15s。
- Mining Puzzle：以太坊是Memory hard以及是ASIC Resistance，目前以太坊和比特币都是proof of work 都是以工作量作为证明，而以太坊往后想转为权益证明proof of stake，因此也预留了难度炸弹，用于顺利过渡。
- 以太坊支持智能合约，是去中心化的合约，但还是比特币是去中心化的货币。
- 以太坊是基于账户的。
2 以太坊是基于账户
2.1 Replay Attack
既然是基于账户那么就有天然的抵御Double Spending Attack的作用，花两次钱就扣两次的款，余额是可以修改。但是在这一种情况下是可以防止一笔钱花两次，但是对于收钱的人来说一笔钱就有可能收两次了，因为收钱方可以对外广播这一笔交易，这就是Replay Attack。
2.2 Replay Attack的解决方法
可以通过nonce值记录交易的次数，而且要有花钱人的签名，例如一笔交易：
梁→曾（1eth）【梁给曾转了一个以太币】
nonce=1
signed 梁【梁给这一笔交易签名】
当梁签名后这一笔交易就变得不可篡改，除非曾知道梁的私钥。
3 以太坊的用户类型
3.1 外部账户
3.1.1 外部账户（Externally Owned Account）定义
外部账户也是指普通的用户，和比特币一样谁持有私钥就拥有了账户，当有了账户以后是不需要广播让全部结点都知道，只有在你的账户涉及到交易的时候才可以机会让所有结点知道。外部账户可以主动的发起交易并且调用合约账户。
3.1.2 主要属性
- balance 余额
- nonce 记录第几次交易（类似于计数器）
3.2 合约账户
3.2.1 合约账户的定义
合约账户可以通过按照只能合约的code内容来执行，合约账户和外部账户最大的区别是：
- 不通过公私钥对来控制，通过该智能合约代码控制
- 它不可以主动发起交易
3.2.2 主要属性
- balance
- nonce一个合约账户调用另外一个合约账户也是用来计数的
- code
- storage
3.2.3 合约调用过程
创建合约→返回地址→调用合约（代码内容不变但是存储会改变）
4 以太坊的基本数据结构
假设单纯用一个Hash表记录所有的信息，就要考虑这笔交易是否已经包含在特定的区块中、目前交易账户余额、这个账户是否存在等问题这就是Merkle proof的问题，那么是不是可以建一棵Merkle tree把所有交易都放到里面？但是考虑到Merkle Tree的更新代价太大了，每一次新增一个交易都需要进行更新，用《比特币的Merkle Tree》的图，可以知道当在最后面插入一个数据的时候半棵树都要更新，最后新生成一个Merkle Root。 但是比特币的Merkle Tree却不会有这种烦恼，因为每一个区块会有4000个左右的交易，而且这棵树是生成以后就不需要改变了，他的Merkle Root就放在了区块的块头，只是单纯地用于鉴别数据是否被篡改。
MerkleTree除了检测数据是否被篡改还有一个作用就是让全结点保持数据的一致性。
假如只是单纯的用Merkle Tree作为数据结构的话却不利于插入更新操作，此外当接收到的数据顺序不是一致的话产生不一样的Merkle Tree ，还是上面的图，假如第一个Data Block的hash值和第三个Data Block的Hash值合在一起这样合起来在算一次hash值和第一个Data Block的Hash值和第二个Data Block的hash值再合起来算一次Hash值，两个Hash值必然不一样。但比特币的Merkle Tree一个区块只有固定的一棵，那棵树是什么结构，掌握在记账矿工的手上。
那么把所有的Data Block进行排序形成一棵排序的Merkle tree，不就可以解决掉树结构不一致的问题？但是对于插入和更新数据依然是代价很大。所以就要寻找一种数据结构结合Hash表和树的性质，这就是引入字典树Trie tree。
4. 1 Trie树
4.1.1 字典树的定义
Trie树是一种基于树的数据结构，又称单词查找树、前缀树，是一种哈希树的变种。应用于字符串的统计与排序，经常被搜索引擎系统用于文本词频统计。用于存储字符串以便支持快速模式匹配，主要应用在信息检索中，Trie支持的主要查询操作是模式匹配和前缀匹配。把luck luxury launch light生成一棵字典树：
以上面这一课字典树为例子：
- 每个结点最多有26种不同的结点，在以太坊中地址有160bits用40个十六进制数表示，所以最多有0~F即16种不同的结点。
- 即使结点的顺序不一样，但是生成的树的结构还是一样的。
- 局部更新有着优良的特性。
4.1.2 字典树的缺点
浪费内存，正如单词fantasy浪费了大量的内存，所以有没有一种数据结构可以减少内存的应用呢？
4.2 压缩前缀树
它能保证Trie中的每个内部结点至少有两个字结点。通过把单子结点链压缩进各条边中来执行这个规则。
只要键分布得越是稀疏压缩的效果就会越好例如fantasy。还差一点，就是把Hash后的地址值结合压缩前缀树就完美了。
4.3 MPT（Merkle Patricia Tree）
把Hash后的地址值结合压缩前缀树。
- 根节点Hash值不可篡改。
- 满足了Merkle Proof通过查询value值就可以知道有多少钱。
- 有较高的查询速率和插入效率。
- 查询一个不存在的用户的效率也很高。
图源：《深入浅出以太坊MPT（Merkle Patricia Tree）》第四点
解析一下图：
第一部分：四个账户keys记录的是Hash后的地址（地址是公钥的Hash）
第二部：有压缩就会有一个shared nibbles
5 以太坊的三棵树
5.1 状态树
需要状态树的原因每10s会产生一个区块，当有分支的时候要进行回滚不合法分支的交易，直接修改账户状态将会导致永久性丢失用户数据不能回滚。对于交易树来说查找一个账户就是查找这一个账户的地址，状态树记录所有账户的状态（不包含没有发生过交易的用户）。另外一种情况假如没有状态树，此时B是一个新的账户，在当前区块找不到对应的信息只好往前面的区块找，发现也不存在B的信息直到找完创始区块也没有B的信息，才知道B是一个新用户，这样时间复杂度很高。
5.2 交易树
每次发布一个交易的时候就可以形成一棵交易树，提供Merkel Proof，向轻节点证明某个交易是打包在区块中的。
5.3 收据树
每个交易完成后会形成一棵收据树，记录每一笔交易，交易树和收据树是一一对应的，交易树和收据树查找的都是每一笔交易的序号，向轻节点证明某个交易的执行结果。
5.4 交易的条件查询
5.4.1 布隆过滤器bloom filter
布隆过滤器是一种空间效率很高的随机数据结构，判断一个元素是否属于这个集合中，但是该过滤器只是支持查询操作，不支持删除操作。
5.4.2 布隆过滤器的过滤步骤
- 初始化时，需要一个长度为n比特的数组barr，每个比特位初始化为0；
- 首先需要k个hash函数，每个函数可以把key散列成为1个整数；
- 某个key加入集合时，用k个hash函数计算出k个散列值，映射到barr的某一个位置中，并把数组中对应的比特位置为1；
- 判断某个key是否在集合时，用k个hash函数计算出k个散列值，并查询数组中对应的比特位，如果所有的比特位都是1，认为在集合中。
当所有元素都处理完后得到一个摘要。
5.4.3 布隆过滤器查询
- 取该值的Hash值，散列成1个整数n
- 对应barr的下标n对应的值，假如是1那么该值存在于集合中，假如值为0则该值不存在。
注意：可能产生Hash冲突映射到同一个元素，所以布隆过滤器不保证查找的元素一定正确。
6 以太坊处理分叉问题
6.1 孤儿区块
分叉后不能成为最长合法链上的区块。孤儿区块假如经常出现会导致交易经常要回滚，本来得到的区块奖励就没有了，重挫矿工的挖矿积极性，时长有分叉也会导致矿工的算力被分散。
6.2 叔叔区块
6.2.1 叔叔区块的定义
孤儿区块变成叔叔区块，叔叔的交易不会被执行，但他可以分取一部分的挖矿奖励，改区块奖励的7/8,他也会被记录到下一个区块中。叔叔的个数是0~2个剩。
6.2.2 总有人想当侄子
假如产生了两个以上的分支，剩下的叔叔区块就没有机会再被侄子记录了，有点结点就是宁愿不记录叔叔区块，他本身得到的收益减少但是和叔叔作对比，叔叔区块反而会更亏。所以在大部分都是善意结点的情况下，会让侄子的儿子记录叔叔区块的信息。蓝色的两个区块就是解决是叔叔的问题。所以侄子和叔叔的关系可能和jojo一样，叔叔不一定是跟父亲同辈，乔瑟夫也应该喊乔鲁诺舅舅。
6.2.3 叔叔的儿子没价值
有恶意的结点偏要在叔叔链后面挖会导致更长的链更多的交易被回滚，为了杜绝这种情况，分叉链只有第一个结点能收到奖励。
6.2.4 叔叔区块的分配问题
当叔叔区块都会有奖励，那么会不会有结点就专门做分叉？如下图：
随着越往前叔叔区块的钱会越来越少了到了2/8后叔叔就不会再分得奖励。
