建立：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信息檢索（前綴樹，字典樹）”來的）