比特幣MAST方案分享

本次分享以下幾個內容：

1、 MAST方案的實現背景

2、 MAST的具體實現方案

3、 方案的收益

4、 可行性分析

四個方面的內容

實現背景：

主要是比特幣安全性方面的原因，我們知道所有的比特幣交易都是公開，可追溯的，並且永久性地儲存在比特幣網路中。在美劇《網路犯罪調查》第二季中，有一段比特幣大盜抓捕過程，完整地展示了比特幣交易可追溯性的意義（視訊），原理就是通過比特幣交易的時間和金額來鎖定了地址，只要比特幣大盜挪動比特幣，或者在交易平臺賣出，他的IP甚至實名資訊就可能被追查出來。

針對這個可追溯問題，人們提出了幾種方案，但是無法徹底解決

1、 使用新地址收款

每次接收新的付款你都應該使用一個新的比特幣地址。此外，你可以使用多個錢包滿足不同的需求。這樣做可以將你的每筆交易都隔離開以使它們無法被關聯起來。付款給你的人不會看到你其它的比特幣地址，也不會知道你如何使用它們。

2、 儘可能不要公開比特幣地址

如果你從這個地址向你其他的地址傳送了任何資金，這些地址的隱私性也會由於你的公共地址的歷史記錄而被破壞

3、 Coinjoin 混合交易

混合交易就是把許多人的交易放一起簽名，這樣就不容易判斷具體誰和誰發生了交易，舉個例子：

有兩個交易，使用者Blob轉賬給Ted 15BTC，找零5BTC；使用者Alice轉賬給Carol 8BTC，找零2BTC，我們把兩個交易合併為一個，輸入和輸出不變，使用者Bob只需要對他的輸入簽名，然後交給使用者Alice，使用者Alice只對她的輸入簽名。簽名完成後就可以釋出廣播。

從本質上講，CoinJoin允許多個使用者將來自多個事務的所有輸入和輸出合併為一個大事務。 這樣一個交易將會由不同地址的比特幣輸入和不同地址的輸出構成，他們之間沒有任何聯絡，我們無法通過一個傳送地址找到對應的接收地址。

（這可以和一群把現金放在一起購物的人比較，只要每個人確保自己花自己的錢買自己的東西，其他人卻無法知道每個人花了多少錢買了多少東西）

目前我們在遊戲上用了這種模式，使用場景是使用者a給使用者b轉了一個貓，轉賬的手續費由平臺c來出，這實際是兩個交易，我們合併為一個交易，既能夠保證交易相互關聯，也不需要讓平臺給使用者發幣，導致交易過程複雜化。

這幾個方案能夠帶來一定的隱私性，但是交易一旦上鍊，還是有辦法鎖定交易雙方。而MAST方案可以做到即使交易上鍊，交易雙方的資訊，你可能只知道一方。

實現方案

MAST方案由三部分構成，分別是支付給指令碼hash(P2SH)，抽象語法樹（AST）和merkle樹

支付給指令碼hash(P2SH)

比特幣有兩種常見指令碼的格式

P2PKH（支付到公鑰地址模式）：

輸出指令碼：OP_DUP OP_HASH160 （0×14） [一個20位元組的雜湊值] OP_EQUALVERIFY OP_CHECKSIG

輸入指令碼：[簽名的位元組數]［簽名］0×01 [公鑰的位元組數] [公鑰]

P2SH（支付到指令碼模式，使用多重簽名就需要用到這種模式）：

輸出指令碼：OP_HASH160 （0×14)  [一個20位元組的雜湊值] OP_EQUAL “簽名指令碼”：(輸入指令碼）

輸入指令碼：0×00  [位元組數]  [簽名1] 0×01 …［位元組數] [簽名m] 0×01 [支付合同指令碼的位元組數]  [m]  [位元組數]［公鑰1］… [位元組數]［公鑰n］[n] OP_CHECKSIGVERIFY

這兩個最大的區別是在輸出指令碼里面放公鑰hash還是放指令碼hash，如果放公鑰hash，其實就是地址，那麼交易地址就是暴露的，如果放指令碼hash，就無法知道轉賬給哪個地址了。這一步已經做到了隱藏地址，但是還需要隱藏指令碼。

抽象語法樹（AST）

我們來看一個例子：

Alice希望能夠隨時使用比特幣，但如果她的比特幣在三個月內沒有用完（可能是因為她已經死了或 無能為力），她希望她的兄弟姐妹鮑勃和查理能夠使用她的比特幣。

這個指令碼不僅包括Alice的公鑰（需要從她的私鑰中驗證簽名），還包括超時邏輯以及Bob和Charlie的公鑰。

在當前的比特幣協議中，當愛麗絲的比特幣被花費時，上述所有資料都必須被新增到塊鏈中。 但是沒有使用的花費條件，例如Bob's和Charlie的公鑰，會增加交易規模，也會因為公開披露更多資訊而暴露了更多隱私，MAST試圖通過消除在塊鏈中直接包含未使用的指令碼部分的需求來改善這種情況。

抽象語法樹（AST）是一種通過將程式分解成各個部分來描述程式的方式，這可以使分析和優化變得更加容易。 要生成一個AST，可以將每個函式連線到它的依賴關係，直到所有的依賴關係都被對映出來為止。

通過抽象語法樹我們把一個複雜規則分解成一個個獨立的簡單條件，如果是alice花費了這筆錢，就把alice這部分條件上鍊；如果是她的兄弟花了這筆錢，就上鍊他的兄弟這個條件，這樣即減少了上鍊的手續費，也隱藏了沒有使用的資訊。但是指令碼變化了，指令碼hash就不同了，為了確保指令碼hash可以驗證這種可以分拆的指令碼，就需要用到Merkle樹的概念。

抽象語法樹有現成的工具來幫我們分解指令碼，具體見http://n.bitcoin.ninja/mast

抽象語法樹可以把指令碼分解成部分，但是如何確保校驗通過呢？畢竟花費條件是已經上鍊，不可更改的。這就需要用到merkle

merkle樹

大家知道merkle樹是一種特殊的二叉樹，其特徵是頁子節點都是資料，而其他非頁子節點都是hash值，Merkle Tree 的明顯的一個好處是可以單獨拿出一個分支來（也就是驗證路徑）對部分資料進行校驗。

因此我們通過抽象語法樹，把一個程式分解成不同的部分，然後通過Merkle樹使我們能夠在不存在整個程式的情況下驗證屬於一個完整程式的各個部分。

我們繼續看上面的例子，我們轉換為merkle樹就是這個樣子

下面這個就是merkle的兩個分支樹，如果是alice花費了這筆錢就用左邊的樹，如果是她的兄弟花了這筆錢就用右邊的樹，而驗證的時候只需要證明merkle root hash相等就可以了。

收益

1、 更多的隱私保護

在這個例子中，只有alice知道誰可以使用這筆資金，並且使用資金有啥限制條件，即使這邊資金被花費了，你也只能知道其中一個花費條件，無法知道全貌，當然alice也可以假裝她有很多花費條件，實際就只能她花費。

在上面的比特幣大盜的視訊裡面，如果黑客把錢轉給了一個merkle root hash，那麼只要他還沒有花費這筆錢，警察不可能查到這筆錢被誰偷走了。

缺點是如果是兩個商家的交易就可能存在信任危機，因為只有轉賬的商家完全知道花費條件，而收款的商家可能只知道一部分條件。

2、 較小的交易

使用mast後，程式碼被分割為幾個指令碼，當指令碼超過2個部分後，程式碼量明顯的減少，從而交易費用也會減少。

3、 更大的智慧合約

比特幣指令碼的位元組大小是有限制的，一般指令碼是1w位元組，而P2SH限制為520位元組。但是我們用mast把指令碼分解成小的指令碼，每個指令碼雖然受到了1w位元組的限制，但是總體可以做的很複雜

可行性分析

1、 何時可以上線

這個無法回答，因為比特幣沒有上線，雖然mast只需要軟分叉就可以上線，但是隔離見證就搞了兩年，最近才上線，比特幣的開發都忙著抄幣去了，核心技術發展比較慢。

2、 應用場景有待發掘

當然你可以把目前的P2PKH都改成mast方式，但是比特幣指令碼用來開發一個複雜場景的合約還是比較難，比如如何釋出個以太貓？大家習慣視覺化開發了，現在用類似彙編的語言開發確實很難。

3、 完整的指令碼儲存到哪裡

我們在轉賬的時候用的上個merkle root hash，這個是由完整的指令碼生成的，只有花費的時候才用到指令碼的一部分，這中間有個時間差，完整的指令碼放哪裡比較安全就是個問題了，萬一搞丟了誰也用不了。