在看区块链安全的论文过程中还是有些提到了以太坊。所以还是决定继续把这套课程刷完。
14.以太坊概述
15.以太坊的账户
16.以太坊中的状态树
17.以太坊中的交易树和收据树
18.GHOST协议
14.以太坊概述
比特币，区块链1.0
以太坊，区块链2.0，创始人 vitalik
以太坊改进了比特币的一些问题：
1.出块时间，十分钟改为了十几秒。
2.基于ghost协议的共识机制
3.挖矿使用的mining puzzle。比特币比拼算力，以太坊对内存要求高，memory hard mining puzzle。一定程度限制ASIC芯片的使用。ASIC resistance。
4.用权益证明替代工作量证明 ，proof of work--->proof of stake
5.对智能合约的支持 smart contact
BTC比特币Bitcoin，decentralized currency，单位1 Satoshi聪
ETH以太坊Ethereum，decentralized contract ，单位1 wei
15.以太坊的账户
比特币系统，基于交易，没有账户。钱一次性必须全部转出去，余额转到自己的另一个账户中。
Account -based ledger
A转10个以太币给B，只要查询A的余额够不够就行，没必要查询钱的来源。
这种模式天然防御双花攻击。
弱点，重放攻击。收钱的人不诚实。防范：加一个nonce，交易次数。
以太坊的两类账户
1.外部账户externally owned account
Balance余额，这里的nonce其实是计数器。
2.合约账户 smart contract account
合约账户不能发起交易。Codestorage
金融衍生品，financialderivative
以太坊需要保证账户的稳定性。
16.以太坊中的状态树
账户地址到账户状态的映射。
以太坊账户地址是160位的，20字节，表示为40个16进制的数。
状态包括余额、交易次数、代码、存储。
可以创建很多地址。并不知道这些地址是属于同一个人的。
方案假设：以太坊使用哈希表实现映射，全节点维护一个哈希表，每有新的插入到哈希表中，查询账户余额直接在哈希表中查询，基本上效率是常数级别的。更新也容易。
问题：需要提供merlel proof怎么办，需要证明账户余额怎么办
改进：把这个哈希表的内容组织成一棵merkle tree
问题：有一个新节点怎么办？
-哈希表内容变化，merkle tree需要重构。
问题：比特币咋就能这么整呢？
-比特币每出一个新的区块，也是要重新构建一棵merkle tree， 但是构建完后是不会再改的。区块里大概包含四千个交易。
-如果使用哈希表的方法实现映射，这里是要把所有的以太坊账户一起构建成一棵markel tree，数据太多了。这棵树除了证明账户余额外，还能维护全节点状态的一致性。 但是，每次都要产生一棵merkle tree，实际每个区块只更新一小部分账户，代价太大。
问题：以太坊不排序的merkle tree是不行的
-merkle tree没有提供快速更新和查找的方法。如果不给merkletree排序，算出来的值是乱的，根节点哈希不同，查找也比较困难。
问题：比特币中也不排序咋就能行呢？
-比特币中merkle tree的顺序是发布这个区块的节点决定的。每个节点在本地组装一个候选区块，自己定顺序，但是最后只有获得记账权的节点说了算。以太坊中发布的是所有账户的状态，不是账户包含的交易。差好几个数量级。
问题：以太坊，使用排序的merkle tree也是不行的
-新增一个账户怎么办， 代价太大。插入代价太大。一般不删。
先讲一个简单的数据结构，trie。
来自retrieval信息检索。
General
Genesis
God
Go
Good
单词有可能在这个trie结构的中间节点结束。
特点1：trie中每个节点的分枝数目取决于这个key值里每个元素的取值范围。分叉数目branching factor，加一个结束符号，0-f，17个
特点2：trie的查找效率，取决于key的长度。
特点3：哈希表存在碰撞的可能性，trie不存在碰撞
特点4：输入顺序不影响树的结构，还是同一棵树
特点5：更新操作的局部性。
缺点：存储浪费。
引入，patricia tree/trie压缩前缀树。 路径压缩，效率提高了。
新插入值，原来压缩的路径可能会再扩展开。
Misunderstanding
Decentralization
Disintermediation去中间商（intermediaries中间商）
这三个长单词插入到普通trie中，效率很低。
使用patricia tree后，效果很明显。
所以键值分布比较稀疏的时候，patricia tree效果好。
以太坊中地址，非常稀疏
MPT ，merkle patricial tree
Merkle tree
Binary tree
把普通指针换成了哈希指针。
以太坊的block header 里只有三个根希值，现在讲的是账户状态树。
这个根哈希值，防篡改、证明账户余额是多少。账户所在分支自底向上作为merkleproof 发给轻节点。轻节点可以验证余额多少钱。不能证明一笔交易。能证明一个账户不存在（证明一个MPT中某个键值不存在）。
以太坊中用的是modified MPT
有extension node 有branch node，根节点取哈希值要写在块头里
只有发生改变的账户才需要建新的节点。合约账户的存储也是用的MPT。
系统中每个全节点需要维护的不是一棵MPT，而是每次出现一个区块都要新建一个MPT，只不过这些状态树中，大部分节点是共享的。只有少数发生变化的节点要新建分支。
问题：为什么要保留历史状态？
一个是为了审计。
临时出现分叉。上面的胜出了，下面的回滚。靠这些历史记录。
以太坊智能合约很强，要想回滚必须保持历史状态。
uncle可能比parent大几个辈分。
状态树、交易数、收据树
Root\TxHash\ReceiptHash
bloom 是个filter，提供一种高效的查询符合某种交易的执行结果。
Gas，智能合约要消耗汽油费。
发布的区块
（key,value）
RLP（Recursive lengthprefix）序列化，越简单越好，之后再存储。
Protocol buffer （protobuf） 一个很有名的做序列化的库
RLP只支持一种类型，Nestedarray of bytes字节数组，实现RLP比实现Protocol buffer容易得多。以太坊中的所有数据类型最后都要变成这个Nested array of bytes字节数组
17.以太坊中的交易树和收据树
智能合约比较复杂，使用收据树方便我们快速查询结果。
交易树和收据树只包含这个交易。状态树包含整个系统中所有账户的状态。
Bloom filter 查找某个元素是否在某个比较大的集合里面。
大集合计算出一个摘要。
把每一个元素都取哈希，找到向量中的对应位置，改成1 。所有元素都处理完得到的向量就是原来集合的一个摘要。
有可能出现false positive，不会出现false negative。
可能误报，不会漏报。
如果从这个集合中删除一个元素，怎么操作？没法操作。不支持删除。
好处，快速过滤掉无关的区块。根据轻节点块头就能过滤到很多节点了。
Transaction-driven state machine
交易驱动的状态机。
可否设计成状态树也只包含这个交易涉及的账户的状态而不是全部账户的状态？
-出现一致性问题。A转账给B10个以太币，要查A的余额，如果没有全部账户的状态，如果A很久没转账了，得往前推很多次才能找到A的账户状态。如果B是新创建的账户，你要查询B的余额，要倒退扫描到创世纪块发现没有这个账户……才知道原来是个新建的账户
18.GHOST协议
以太坊出块时间短，同时出现分叉情况多。
在比特币中，没有成为最长合法链的区块就白挖了，叫做orphan block或者staleblock
对个体矿工不公平。
大矿池挖出最长合法链可能性更大。造成mining centralization。Centralization bias。
以太坊采用基于GHOST协议。在这个上做了修改。不是他发明的。
这个作废的区块叫做uncle block
挖到矿最后没有被认可，也能得到一定的好处，当前最长区块包含这个叔父区块，它可以得到7/8×3个奖励。现在出块奖励是3个。
最长区块如果包含叔父区块，可以获得1/32×3额外的出块奖励。
一个区块最多可以包括两个叔父区块。
八分之七的奖励实际上是很高的，这样做有利于出现分支后尽快合并。
以上是GHOST协议最初的版本。
缺陷，有矿池损人不利己，故意不包含叔父。
爷爷辈也可以认孙子做叔父区块。可以隔代。
你不包含别人包含。下一个区块未必还是你挖的。
当代叔父7/8的奖励，隔两代6/8….1/32是固定的。
到2/8就不叔父了。7代以内。递减。鼓励尽快合并。
以上这个只是临时性的分叉。
对于协议改动的分叉。不能用这种方法。
交易费叫做动态奖励，出块奖励叫做静态奖励。
以太坊里的交易费叫做汽油费gas fee。叔父奖励没有gas fee。
以太坊没有人为制造出块奖励定期减半机制。
检查这个叔父区块是否符合挖矿难度要求的。不检查交易是否合法。
如果分叉后还跟着一串怎么办？
forKing attack，分叉攻击
如果把一长串都给奖励的话，分叉攻击的代价就太小了。分叉攻击你，失败了也有奖励。所以这么做是不合适的。
所以以太坊规定只有分叉后的第一个区块可以获得叔父奖励。