比特幣為什么要采用UTXO模型

本期漏洞專題是比特幣漏洞CVE-2010-5141，這個(gè)漏洞可以導(dǎo)致攻擊者盜取任何人的比特幣，危害十分嚴(yán)重。萬(wàn)幸的是該漏洞并沒有被利用過，而且修復(fù)速度極快。該漏洞與比特幣的腳本引擎有關(guān)，對(duì)公鏈開發(fā)者具有參考意義；從當(dāng)下市場(chǎng)上的公鏈來(lái)看，大多數(shù)都內(nèi)置了虛擬機(jī)或腳本引擎，以此來(lái)打造DApp生態(tài)，同時(shí)也是區(qū)塊鏈的大趨勢(shì)之一。

一、比特幣當(dāng)中的UTXO模型是什么？

Tips：在漏洞代碼片段中會(huì)涉及一些UTXO的相關(guān)知識(shí)、概念，所以對(duì)該漏洞進(jìn)行理論分析之前需要先了解一下這些知識(shí)點(diǎn)，已經(jīng)了解的可以直接跳過。

Ⅰ、賬戶模型與UTXO模型

我們?cè)诳碪TXO模型之前先說說常見的賬戶模型，什么是賬戶模型？賬戶模型的數(shù)據(jù)結(jié)構(gòu)簡(jiǎn)單可以理解為“賬號(hào)=》余額”，每個(gè)賬號(hào)都對(duì)應(yīng)一個(gè)余額。舉個(gè)例子：若賬號(hào)A向賬號(hào)B轉(zhuǎn)賬200，在賬戶模型中完成這個(gè)轉(zhuǎn)賬操作只需要A-200然后B+200；目前大部分軟件都采用的是賬戶模型，比如銀行系統(tǒng)、以太坊等等。

而比特幣卻使用了自行研發(fā)的UTXO模型，UTXO中是沒有“賬號(hào)=》余額”這樣的數(shù)據(jù)結(jié)構(gòu)的，那怎么進(jìn)行轉(zhuǎn)賬？

Ⅱ、比特幣如何操作轉(zhuǎn)賬

以上面A向B轉(zhuǎn)賬為例，在UTXO中完成這個(gè)轉(zhuǎn)賬需要以下操作：

1. 找到A賬號(hào)下200余額的來(lái)源，也就是意味著要找到A收款200的這筆交易x

2. 以x交易為輸入，以向B轉(zhuǎn)賬200的交易y為輸出，x與y對(duì)應(yīng)且x與y的轉(zhuǎn)賬金額必須相等

3. x交易被標(biāo)記為已花費(fèi)，y交易被標(biāo)記為未花費(fèi)

兩筆交易的轉(zhuǎn)賬金額必須相等，簡(jiǎn)單解釋就是收到多少就只能轉(zhuǎn)出多少，實(shí)際上確實(shí)是這樣。

但是又必須只給別人轉(zhuǎn)一部分的時(shí)候怎么辦？答案是只向他人轉(zhuǎn)一部分，然后剩下的一部分轉(zhuǎn)給自己另外一個(gè)號(hào)。

Ⅲ、引用兩張來(lái)自網(wǎng)絡(luò)的圖文：

在本文當(dāng)中比特幣為什么采用UTXO模型不是重點(diǎn)，我們了解UTXO的原理即可。

二、比特幣的腳本引擎

比特幣腳本是非圖靈完備的。比特幣使用自行定義的一種腳本進(jìn)行交易和其他的操作，為比特幣提供有限的靈活性。實(shí)現(xiàn)諸如多重簽名、凍結(jié)資金等簡(jiǎn)單功能，但更多的就不行了。

比特幣這么做的原因是犧牲一定的完備性來(lái)保障安全性。比特幣腳本的原理是先定義了一堆操作碼，然后腳本引擎基于堆棧來(lái)逐個(gè)執(zhí)行每個(gè)操作碼。

堆棧很好理解，隊(duì)列是先進(jìn)后出，而堆棧正好相反，是先進(jìn)先出，將一個(gè)元素壓入（push）堆棧后該元素會(huì)被最先彈出（pop）。

在比特幣早期的版本中發(fā)送一筆標(biāo)準(zhǔn)轉(zhuǎn)賬（pay-to-pubkey）交易需要腳本簽名（scriptSig）和公鑰驗(yàn)證腳本（scriptPubKey），具體處理流程如下：

先填入要執(zhí)行的腳本（Script），然后簽名（sig）和公鑰（pubKey）被壓入堆棧，然后操作碼OP_CHECKSIG會(huì)去驗(yàn)證簽名等，若驗(yàn)證通過就將true壓入堆棧，否則就將false壓入堆棧。

三、CVE-2010-5141漏洞分析

了解以上知識(shí)后就可以開始分析CVE-2010-5141漏洞了。筆者下載了存在漏洞的版本0.3.3，下載地址在github的bitcoin倉(cāng)庫(kù)中找release.

script.cpp代碼片段VerifySignature函數(shù)：

執(zhí)行每個(gè)交易都會(huì)調(diào)用VerifySignature函數(shù)，該函數(shù)用于執(zhí)行腳本以及驗(yàn)證簽名，然后給交易標(biāo)注是否被花費(fèi)。

首先txFrom參數(shù)是上一筆交易，txTo是正在處理的這筆交易，如果理解了上面的章節(jié)中講解過的UTXO模型，這里就不難理解了。重點(diǎn)看1125行代碼，調(diào)用了EvalScript函數(shù)，第一個(gè)參數(shù)是txin.scriptSig（包含簽名信息）+分隔操作碼OP_CODESEPARATOR+ txout.scriptPunKey（包含公鑰信息、OP_CHECKSIG指令），這些就是EvalScript函數(shù)要執(zhí)行的腳本，后面的參數(shù)可以暫時(shí)不用管，只要EvalScript函數(shù)返回true那么這筆驗(yàn)證簽名就通過了。EvalScript函數(shù)如何才能返回true？

首先堆棧不能是空的，然后棧頂強(qiáng)轉(zhuǎn)bool后必須是true。筆者簡(jiǎn)單解讀為必須要有棧頂而且值不能是0。

然后再看關(guān)鍵的OP_CHECKSIG操作碼

（注：由于操作碼太多，本文針對(duì)OP_CHECKSIG操作碼）

上面代碼不難理解，調(diào)用Checksig函數(shù)來(lái)驗(yàn)證簽名，然后返回給FSuccess變量，如果為真就壓一個(gè)vchTrue（非0）進(jìn)棧，否則就壓一個(gè)vchFalse（0）進(jìn)棧；如果opcode是OP_CHECKSIGVERIFY而不是OP_CHECKSIG的話就讓vchTrue出棧，并開始執(zhí)行后面的操作碼。

按照OP_CHECKSIG的正常邏輯，驗(yàn)證簽名不成功的話一定會(huì)有一個(gè)vchFalse留在棧頂，雖然堆棧不為空，但是棧頂?shù)闹凳?，還是會(huì)返回false。

回到之前的代碼，EvalScript函數(shù)執(zhí)行的腳本主要由以下變量組成：

1. txin.scriptSig

2. OP_CODESEPARATOR

3. txout.scriptPubKey

第一個(gè)簽名信息可控，第二個(gè)不用管只是一個(gè)分割符，會(huì)被刪掉，第三個(gè)不可控，因?yàn)槭莵?lái)自上一個(gè)交易。

第一個(gè)變量可控，而且是作為腳本執(zhí)行，所以這個(gè)變量可以不僅僅是簽名信息，還能是opcode，這就好辦了，下面需要引用一個(gè)神奇的操作碼 OP_PUSHDATA4，我們看看比特幣0.3.3是怎么處理這個(gè)操作碼的：

首先獲取操作碼。如果操作碼的值小于或者等于OP_PUSHDATA4的值就把vchPushValue全壓入堆棧，再跟進(jìn)GetOp函數(shù)

經(jīng)翻閱源碼，發(fā)現(xiàn)OP_PUSHDATA4指令被定義為78，所以當(dāng)函數(shù)遇到OP_PUSHDATA4時(shí)，指針會(huì)向又移78+4=82位，其中78位數(shù)據(jù)會(huì)被壓入棧，所以只要在txin.scriptSig中注入一個(gè)OP_PUSHDATA4操作碼，后面的公鑰信息以及OP_CHECKSIG指令都會(huì)被”吃掉”并作為參數(shù)入棧，當(dāng)指針走到最后時(shí)，進(jìn)行最后的判斷：

1. 堆棧是否為空？不是

2. 棧頂元素是否為0？不是

于是滿足條件EvalScript函數(shù)返回true，然后VerifySignature函數(shù)也返回true，既然簽名驗(yàn)證都繞過了，那別人的比特幣便可以任意花費(fèi)了。

四、CVE-2010-5141漏洞修復(fù)方案

筆者下載了比特幣版本0.3.8，直接看關(guān)鍵部分代碼

修復(fù)方案也很明確，把scriptSig和scriptPubkey分開執(zhí)行，無(wú)論你scriptSig里面有什么也不會(huì)影響到后面的scriptPubkey執(zhí)行。

寫在最后：

因?yàn)楸忍貛怕┒捶治鍪菑腄VP第一期漏洞專題開始連載的，目前素材來(lái)自2010年，目前漏洞分析主要存在以下難點(diǎn)：

1. 漏洞相關(guān)資料非常少，大多數(shù)漏洞都只有一個(gè)CVE編號(hào)和簡(jiǎn)介，不查閱大量資料無(wú)從入手。

2. 環(huán)境搭建難，難在編譯、私鏈搭建（早期的比特幣甚至沒有私鏈這個(gè)概念）等，比特幣早期的源碼編譯需要的依賴現(xiàn)在很多都已經(jīng)不維護(hù)并下線了。

基于這些原因，所以筆者僅做了理論研究，并未進(jìn)行實(shí)踐驗(yàn)證，如有錯(cuò)誤之處還請(qǐng)指正。