《区块链技术与应用》北京大学肖臻老师公开课 笔记
建立：2019.3.19
第2讲：比特币中的密码学原理
用到的主要功能：1.哈希函数 2.签名
密码学中的哈希被称为cryptographic hash function
密码学中的哈希被称为cryptographic hash function
哈希主要性质：
1.哈希碰撞(collision resistance)
假如有一个256位的哈希，其输入最多有2^256种，但输入有无限种，所以肯定会发生碰撞。
1.哈希碰撞(collision resistance)
假如有一个256位的哈希，其输入最多有2^256种，但输入有无限种，所以肯定会发生碰撞。
2.Hiding：计算过程不可逆，根据计算结果无法推算出原数据
成立条件（不容易被破解）：1.输入空间足够大，很难使用brute-force破解2.输入取值分布均匀
成立条件（不容易被破解）：1.输入空间足够大，很难使用brute-force破解2.输入取值分布均匀
以上两者结合在一起，可以实现digital commitment（有时也称为digital equivalent of a sealed envelope）
实际中操作：（输入空间不足够大）在输入添加一个随机数，一起取哈希，保证了输入随机、取值分布均匀。
比特币中用到的哈希函数还有第三个性质：puzzle friendly
提前无法预算结果，若想要值落入某个范围只能一个个试
提前无法预算结果，若想要值落入某个范围只能一个个试
建立：2019.3.19
第14讲：ETH-以太坊概述
比特币出块时间：10分钟
以太坊出块时间：十几秒
以太坊为了适应新的出块时间设计了一套GHOST协议的共识机制
以太坊出块时间：十几秒
以太坊为了适应新的出块时间设计了一套GHOST协议的共识机制
第二个改进：mining puzzle
比特币：计算密集型，比拼哈希计算速度。所以需要专业挖矿设备。使用ASIC芯片
比特币：计算密集型，比拼哈希计算速度。所以需要专业挖矿设备。使用ASIC芯片
以太坊(memory hard mining puzzle)：需要大量内存。在一定程度限制ASIC使用，ASIC resistance
[proof of work（工作量证明）+proof of stake 混合共识机制]
(BTC的共识机制PoW可能导致 51%攻击)
[proof of work（工作量证明）+proof of stake 混合共识机制]
(BTC的共识机制PoW可能导致 51%攻击)
三：支持smart contract（智能合约）
(BTC)BitCoin:decentralized currency
(ETH)Ethereum:decentrialized contract
(BTC)BitCoin:decentralized currency
(ETH)Ethereum:decentrialized contract
建立：2019.3.20
第15讲：以太坊的账户
一、
1.比特币：transaction based measure
系统不显示记录账户上多少钱，利用UTXO推算。
好处：每笔交易记录了钱的来源，隐私保护好
问题：（使用别扭）等号两边必须相等，必须说明来源，必须花完所有钱
面临主要挑战：double spending attack （双花攻击）花出去的钱又花了一次
具体：1）51%攻击：
http://baijiahao.baidu.com/s?id=1601520668493386036&wfr=spider&for=pc
https://www.jianshu.com/p/d6be6637edc1
2）时间窗口：https://www.chainnode.com/post/176206
1.比特币：transaction based measure
系统不显示记录账户上多少钱，利用UTXO推算。
好处：每笔交易记录了钱的来源，隐私保护好
问题：（使用别扭）等号两边必须相等，必须说明来源，必须花完所有钱
面临主要挑战：double spending attack （双花攻击）花出去的钱又花了一次
具体：1）51%攻击：
http://baijiahao.baidu.com/s?id=1601520668493386036&wfr=spider&for=pc
https://www.jianshu.com/p/d6be6637edc1
2）时间窗口：https://www.chainnode.com/post/176206
2.以太币：account-based ledger
系统显式记录系统上有多少以太币
交易时只检查钱是否够，不检查钱的来源
好处：以太坊的交易模式 有效防御了double spending attack
不会引发 有人篡改自己的余额数据 的数据，(状态树)因为系统全节点维护的状态中保存了余额信息
面临挑战：replay attack （重放攻击）放了两次交易
e.g:A给B转账10 ETH，将这个交易放到网络上，过了一段时间交易被写到了区块链上，B又将这个交易重新广播了一遍，结果A向B转账了两次。
解决：以太坊加了一个计数器nonce计算一个用户有史以来的交易次数。转账时，当前交易次数(每次新的交易+1)成为交易内容的一部分，都受着发布交易者签名的保护。
[系统中每个节点维护一个账户，不仅要维护它的balance（余额），还要维护其nonuce。]
如果有人重放这个交易，看其nonce值，若nonce与之前的重复，说明这个交易已经进行过了，就不会再执行一遍。
系统显式记录系统上有多少以太币
交易时只检查钱是否够，不检查钱的来源
好处：以太坊的交易模式 有效防御了double spending attack
不会引发 有人篡改自己的余额数据 的数据，(状态树)因为系统全节点维护的状态中保存了余额信息
面临挑战：replay attack （重放攻击）放了两次交易
e.g:A给B转账10 ETH，将这个交易放到网络上，过了一段时间交易被写到了区块链上，B又将这个交易重新广播了一遍，结果A向B转账了两次。
解决：以太坊加了一个计数器nonce计算一个用户有史以来的交易次数。转账时，当前交易次数(每次新的交易+1)成为交易内容的一部分，都受着发布交易者签名的保护。
[系统中每个节点维护一个账户，不仅要维护它的balance（余额），还要维护其nonuce。]
如果有人重放这个交易，看其nonce值，若nonce与之前的重复，说明这个交易已经进行过了，就不会再执行一遍。
二、以太坊中的两类账户
1.外部账户（普通账户）：有balance和nonce
利用公私钥（类似比特币），有私钥的一方有控制权
只有外部账户能发起交易
2.合约账户：有balance，nonce ，code，storage(包括每个变量的取值）
不能自己发起交易，但可以：外部账户向合约账户A发起一个交易，然后A调用合约账户B
如何被调用：创建一个合约时会返回一个合约的地址
调用过程中，状态会发生变化（存储会变）
1.外部账户（普通账户）：有balance和nonce
利用公私钥（类似比特币），有私钥的一方有控制权
只有外部账户能发起交易
2.合约账户：有balance，nonce ，code，storage(包括每个变量的取值）
不能自己发起交易，但可以：外部账户向合约账户A发起一个交易，然后A调用合约账户B
如何被调用：创建一个合约时会返回一个合约的地址
调用过程中，状态会发生变化（存储会变）
建立：2019.3.20
第16讲：以太坊中的状态树（部分，未完）
状态是外部账户和合约账户的状态
实现 账户地址到账户状态的映射
实现 账户地址到账户状态的映射
以太坊中用的addr是160 bits的，一般表示为40个十六进制数。
1.将哈希表的内容组成一棵Merkle Tree?
不可行。
如果用Merkle Tree，每有一个新交易、增加一个区块，就要重新生成一棵Merkle Tree。
（比特币中Merkle Tree是把区块里包含的交易变成一棵树，区块里的交易每发布一个新的区块对应生成一棵树，构建完后不会更改。
每个交易大概250MB，区块里最多4000个交易（上限），最后把这几百个、几千个交易构建成一个Merkle Tree）？？？
若以太坊将所有的以太账户遍历一遍构建成一个Merkle Tree，代价太大了
不可行。
如果用Merkle Tree，每有一个新交易、增加一个区块，就要重新生成一棵Merkle Tree。
（比特币中Merkle Tree是把区块里包含的交易变成一棵树，区块里的交易每发布一个新的区块对应生成一棵树，构建完后不会更改。
每个交易大概250MB，区块里最多4000个交易（上限），最后把这几百个、几千个交易构建成一个Merkle Tree）？？？
若以太坊将所有的以太账户遍历一遍构建成一个Merkle Tree，代价太大了
Merkle Tree除了 提供Merkle Proof 证明账户上有多少钱 以外，
还有 维护各个全节点间状态的一致性（每个全节点在本地维护一个哈希表，不放出根哈希值，无法知道自己的数据结构状态和别人的是否一致；对当前区块有哪些交易，全节点要有共识）。
（方法不可行，每次构建Merkle Tree的代价太大 ：每个全节点在本地维护一个哈希表，需要构建Merkle Tree时再将 根哈希值发到Merkle Tree里）
还有 维护各个全节点间状态的一致性（每个全节点在本地维护一个哈希表，不放出根哈希值，无法知道自己的数据结构状态和别人的是否一致；对当前区块有哪些交易，全节点要有共识）。
（方法不可行，每次构建Merkle Tree的代价太大 ：每个全节点在本地维护一个哈希表，需要构建Merkle Tree时再将 根哈希值发到Merkle Tree里）
2.不用哈希表，直接把所有账户放进Merkle Tree
不可行。
1.Merkle Tree不提供高效的查找、更新的方法。
2.要不要排序（Sorted Merkle Tree）
1）不排序：
（1）查找速度慢
（2）如果不规定账户在叶节点出现顺序，构建出来的Merkle Tree不是唯一的，算出的根哈希值也是不一样的
【在比特币中交易顺序也是不一样的，但有一个区别：每个节点在本地组装一个候选区块，自己决定哪些交易以什么顺序被打包到区块里；挖矿后获得记账权的那个节点发布自己的区块，决定顺序】
在以太坊中不适用：每个全节点自己决定怎么把账户组织成一个Merkle Tree，算出哈希值，挖矿后，发布到区块里，但发布的是所有账户的状态，而不是区块里包含的交易。比特币中发布交易只有几百个、几千个，一个区块里的交易只能改很少的账户，大多数账户状态不变，而以太坊若要发布账户状态不是一个数量级的。
2）排序：
新增一个账户，地址是随机的，可能是插在中间的，那么后面的那些树的结构都要变，代价太大。
不可行。
1.Merkle Tree不提供高效的查找、更新的方法。
2.要不要排序（Sorted Merkle Tree）
1）不排序：
（1）查找速度慢
（2）如果不规定账户在叶节点出现顺序，构建出来的Merkle Tree不是唯一的，算出的根哈希值也是不一样的
【在比特币中交易顺序也是不一样的，但有一个区别：每个节点在本地组装一个候选区块，自己决定哪些交易以什么顺序被打包到区块里；挖矿后获得记账权的那个节点发布自己的区块，决定顺序】
在以太坊中不适用：每个全节点自己决定怎么把账户组织成一个Merkle Tree，算出哈希值，挖矿后，发布到区块里，但发布的是所有账户的状态，而不是区块里包含的交易。比特币中发布交易只有几百个、几千个，一个区块里的交易只能改很少的账户，大多数账户状态不变，而以太坊若要发布账户状态不是一个数量级的。
2）排序：
新增一个账户，地址是随机的，可能是插在中间的，那么后面的那些树的结构都要变，代价太大。
3.以太坊采用MPT结构（Merkle ）
前提补充：Trie树（从“retrieval信息检索（前缀树，字典树）”来的）
前提补充：Trie树（从“retrieval信息检索（前缀树，字典树）”来的）
