《區塊鏈技術與應用》北京大學肖臻老師公開課 筆記

創建：2019.3.19

第2講：比特幣中的密碼學原理

 

用到的主要功能：1.哈希函數 2.簽名
 
密碼學中的哈希被稱爲cryptographic hash function

哈希主要性質：
1.哈希碰撞(collision resistance) 
假若有一個256位的哈希，其輸入最多有2^256種，但輸入有無限種，因此確定會發生碰撞。

2.Hiding：計算過程不可逆，根據計算結果沒法推算出原數據
成立條件（不容易被破解）：1.輸入空間足夠大，很難使用brute-force破解2.輸入取值分佈均勻

以上二者結合在一塊兒，能夠實現digital commitment（有時也稱爲digital equivalent of a sealed envelope）

實際中操做：（輸入空間不足夠大）在輸入添加一個隨機數，一塊兒取哈希，保證了輸入隨機、取值分佈均勻。

比特幣中用到的哈希函數還有第三個性質：puzzle friendly
提早沒法預算結果，若想要值落入某個範圍只能一個個試

 

創建：2019.3.19

第14講：ETH-以太坊概述

比特幣出塊時間：10分鐘
以太坊出塊時間：十幾秒
以太坊爲了適應新的出塊時間設計了一套GHOST協議的共識機制

第二個改進：mining puzzle
比特幣：計算密集型，比拼哈希計算速度。因此須要專業挖礦設備。使用ASIC芯片

以太坊(memory hard mining puzzle)：須要大量內存。在必定程度限制ASIC使用，ASIC resistance
[proof of work（工做量證實）+proof of stake 混合共識機制]
(BTC的共識機制PoW可能致使 51%攻擊)

三：支持smart contract（智能合約）
(BTC)BitCoin:decentralized currency
(ETH)Ethereum:decentrialized contract

 

創建：2019.3.20

第15講：以太坊的帳戶

1、
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與以前的重複，說明這個交易已經進行過了，就不會再執行一遍。

2、以太坊中的兩類帳戶
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 Proof 證實帳戶上有多少錢 之外，
還有 維護各個全節點間狀態的一致性（每一個全節點在本地維護一個哈希表，不放出根哈希值，沒法知道本身的數據結構狀態和別人的是否一致；對當前區塊有哪些交易，全節點要有共識）。
（方法不可行，每次構建Merkle Tree的代價太大 ：每一個全節點在本地維護一個哈希表，須要構建Merkle Tree時再將 根哈希值發到Merkle Tree裏）

2.不用哈希表，直接把全部帳戶放進Merkle Tree
不可行。
1.Merkle Tree不提供高效的查找、更新的方法。
2.要不要排序（Sorted Merkle Tree）
1）不排序：
（1）查找速度慢
（2）若是不規定帳戶在葉節點出現順序，構建出來的Merkle Tree不是惟一的，算出的根哈希值也是不同的
【在比特幣中交易順序也是不同的，但有一個區別：每一個節點在本地組裝一個候選區塊，本身決定哪些交易以什麼順序被打包到區塊裏；挖礦後得到記帳權的那個節點發布本身的區塊，決定順序】
在以太坊中不適用：每一個全節點本身決定怎麼把帳戶組織成一個Merkle Tree，算出哈希值，挖礦後，發佈到區塊裏，但發佈的是全部帳戶的狀態，而不是區塊裏包含的交易。比特幣中發佈交易只有幾百個、幾千個，一個區塊裏的交易只能改不多的帳戶，大多數帳戶狀態不變，而以太坊若要發佈帳戶狀態不是一個數量級的。
2）排序：
新增一個帳戶，地址是隨機的，多是插在中間的，那麼後面的那些樹的結構都要變，代價太大。

3.以太坊採用MPT結構（Merkle ） 前提補充：Trie樹（從「retrieval信息檢索（前綴樹，字典樹）」來的）