區塊鏈技術7：比特幣的機制（1）

在之前的課程中我們從較高的層次討論比特幣，它為什麼會出現，它的正確性的保障，從這一節開始，我們會討論比特幣的細節。

比特幣的共識機制生成了一個append-only的賬本，一旦交易在賬本中，再也不能更改。礦工——也即一些有較高計算力的節點，生成區塊，並且驗證交易是正確的（簽名是正確的、幣沒有重複花費）等。賬本和區塊鏈網路使得比特幣成為一種貨幣。在本文中，將介紹一些細節。

1. 交易

區塊鏈實際上就是一個賬本，賬本就是要記賬，賬實際就是一筆筆的交易。那首先看一下，使用下面的記賬形式效果如何。

第一個交易是形成區塊的獎勵25個比特幣。Alice將17個幣轉給Bob，Bob轉8個給Carol，Carol轉5個給Alice，然後Alice轉15個給David。這種記賬方式非常符合我們的直覺，因為現實生活中，支付寶、微信、銀聯都是這麼做的。但是這種做法的優缺點是什麼？

上面的例子中，前面的幾筆交易我們可能都看的很順，因為根據之前交易的情況，我們很容易判斷出交易能夠順利進行。但是看到最後一筆交易的時候就得想一下，Alice有這麼多錢支付給David嗎？

這種形式的賬本也叫作account-based賬本，這種記賬方式的問題是：必須對每個賬戶的餘額進行查詢，才能確定一筆交易是否有效。譬如在最後一個交易的時候，得去查一下Alice的賬戶，總共還有多少幣剩餘。像上面的例子中，如果沒有全域性的資料結構維護使用者的餘額，那麼可能得一路追蹤回去到起始交易，看看Alice到底剩多少錢。如果想要快一點，那就得額外地維護資料結構，譬如有一個全域性的資料結構，在每次交易後更新賬戶餘額。

由於這樣的問題，比特幣並沒有使用這樣account-based的記賬方法。比特幣的記賬方式是類似於這樣的：

每一筆交易指明瞭輸入和輸出，每一筆交易有唯一的識別符號，每一筆交易可以有多個輸入和多個輸出。上面的例子做了簡化，使得可以方便地使用序號來指代交易。

第一個交易中沒有輸入，因為它是區塊的第一個交易，創造了新的幣，Alice作為礦工獲得了幣，這25個幣也是交易1的唯一一個輸出，在之後使用1[0]來指代Alice擁有的25個幣。在第二個交易中，輸入是1[0]，25個幣，然後產生了兩個輸出，2[0]是支付給Bob的17個幣，2[1]是剩下的8個幣，也形成了一個輸出，接收方是Alice自己。在第三個交易中輸入是2[0]，也即Bob的17個幣，輸出是3[0]，付給Carol的8個幣，以及3[1]，付給Bob的9個幣。在第四個交易中，輸入是2[1]，也即Alice的8個幣，分別支付給David和Alice。

使用這樣的記賬方式的好處是可以方便地驗證交易的正確性。在驗證一個交易時，我們首先找到輸入所指向的交易的輸出，同時為了確保它並沒有被花掉，所以我們需要掃描所指向的交易區塊和最新區塊之間所有的區塊，而不需要找到創世區塊。

因為一個交易可以包括多個輸入和多個輸出，所以可以方便地實現各種目的。譬如，Bob接收到Alice的8個幣，收到Carol的2個幣，那麼Bob可以將建立一個新的交易，將兩個交易中的輸出作為輸入，從而將零錢合併為整錢。

如果Bob和Carol要同時支付給David，那麼在同一個交易中的輸入可以包含Bob和Carol的幣。在這種情況下， 交易生效的條件同時需要Bob和Carol兩人的簽名。

2. 交易的語法

上面從概念上簡單介紹了交易。接下來看一些細節——下面的圖雖然一眼看上去有點複雜，但是已經是經過翻譯之後的友好版本，畢竟所有在網路上傳輸的資料都是01串。

如上圖所示，交易由三部分構成：元資料、輸入（多個）和輸出（多個）。

元資料：顧名思義，元資料記錄交易的基本資訊，如交易的大小，交易的輸入個數Vinsz，交易的輸出個數Voutsz，以及整個交易的雜湊值作為交易的唯一的ID。如果看的仔細，還能發現有一個lock_time，鎖定時間，在後面會有具體的例子來介紹它的用法。

輸入：交易的輸入構成一個數組，多個輸入中每一個結構都一樣。因為它指定了之前的一個交易的輸出，所以需要包含之前的交易的雜湊值（雜湊指標），同時指出該輸入是之前交易的第幾個輸出。除此之外，每個輸入還必須包括一個簽名（scriptSig），這個簽名就是一個憑證，證明交易的建立者確實有使用這個輸出的權利。

輸出：輸出同樣構成一個數組。每個輸出有兩個部分，value值和scriptPubkey。所有輸出的value的和不能大於所有輸入值的和。如果所有輸出的和小於所有輸入和，那麼差值部分就成為礦工的交易費用。

現在可能有個疑問，本來是簽名和公鑰地址的位置出現的是scriptSig和scriptPubKey，而不是簡單的Signature和PubKey。而且在scriptPubkey的地方，有一些奇怪的符號如OP_DUP，OP_Hash等。這就是接下來要介紹的比特幣指令碼，Bitcoin script。

3. 比特幣指令碼

如上小節所見，在交易中出現了一些如OP_DUP的符號，這實際上是一種指令碼。本小節將介紹比特幣指令碼語言，以及為何需要使用比特幣指令碼。

比特幣指令碼是基於棧的語言。棧允許兩類操作：入棧和出棧。入棧是在棧頂部增加一個專案，出棧則是從棧頂部移除一個專案。指令碼語言通過從左至右地處理每個專案的方式執行指令碼。數字指令直接入棧，操作指令向堆疊推送（或移除）一個或多個引數，對它們進行處理，或者可以將結果入棧。例如，OP_ADD將從堆疊移除兩個專案，將二者相加，然後再將二者相加之和推送到堆疊。

指令碼的一個重要作用就是判斷是否滿足條件，譬如OP_EQUAL判斷棧中的兩個值是否相等，如果相等則將棧上的兩個值出棧，入棧TRUE。如果最後棧的結果為TRUE，則條件滿足。舉一個非常簡單的例子，譬如Alice將自己的10個幣寫在一個交易中，然後輸出的條件是

3 OP_ADD 5 OP_EQUAL

之後如果有人能夠給出滿足這個條件的結果，也即最後的OP_EQUAL返回的結果是TRUE，那麼則可以使用這10個幣。

那麼大家看一下，以上問題的結果應該是什麼？

最常見的一種比特幣交易應該就是通過簽名獲取之前交易的比特幣輸出。也即輸出中應該指明“這一筆輸出應該由這個公鑰址所對應的私鑰的擁有者使用。”但是回想一下，比特幣中，交易地址實際上是公鑰的雜湊，而不是真正的公鑰。因此，礦工並不知道公鑰，從而也無法來驗證簽名。為了進行驗證，每一個輸出實際上指明的是“這一筆輸出可以由雜湊為x的公鑰，以及公鑰對應的私鑰的所有者使用。”

為了表達這個含義，來看一下交易中的輸出：

Pay-to-PubkeyHash指令碼的例子

顧名思義，OP_DUP是duplicate複製，OPHASH160是進行雜湊，69e0....串是指定的地址，OP_EQUALVERIFY是驗證是否相等，以及OP_CHECKSIG是進行簽名驗證。

那現在的問題是，第一個OP_DUP是用來複制什麼呢？

答案就是，每一個交易的輸入部分的scriptSig也是指令碼。為了成功地使用之前交易的輸出，我們需要將新交易的輸入與之前交易的輸出進行合併，然後執行合併之後的指令碼，如果驗證成功，則該交易是合法的；否則，這個交易就是無效的。

新交易的輸入簽名+之前所引用交易的輸出

比特幣指令碼簡稱就是Script，它是一種簡單的基於棧的程式語言。基於棧意味著每個指令以線性的方式僅僅執行一遍。特別地，比特幣指令碼中沒有迴圈。因此，指令碼的指令的數量就暗示了執行指令碼的時間和所用的記憶體的上限。該語言不是圖靈完備的，也即不能執行任意複雜的操作。這也是合理的，因為礦工需要驗證交易，也即礦工需要執行這些指令碼，如果指令碼中出現了死迴圈，礦工就被坑了。

交易的執行結果要麼就是成功的，也即交易是合法的，可以被包括在區塊鏈中；要麼就是失敗，也即交易是無效的，不能被包括在區塊鏈中。

比特幣指令碼語言非常小，總共只有256個指令，因為每個指令使用一個位元組來表示。其中，有15個指令現在已經禁用；75個預留的，有可能將來新增。大部分的指令是在普通的程式語言中見到的，有一些是和密碼學相關的，如雜湊，簽名驗證等。

下面使用一個例子來講述如何執行指令碼。

首先來具體看一下scriptSig的樣子。下面是一個例子。

8c4930460221009e0339f72c793a89e664a8a932df073962a3f84eda0bd9e02084a6a9567f75aa022100bd9cbaca2e5ec195751efdfac164b76250b1e21302e51ca86dd7ebd7020cdc0601410450863ad64a87ae8a2fe83c1af1a8403cb53f53e486d8511dad8a04887e5b23522cd470243453a299fa9e77237716103abc11a1df38855ed6f2ee187e9c582ba6

它實際上是由四（五）個部分構成：

<One-byte script OPCODE containing the length of the DER-encoded signature plus 1 (the length of the one-byte hash code type)>|< The actual DER-encoded signature plus the one-byte hash code type>|< One-byte script OPCODE containing the length of the public key>|<The actual public key>

8c：一個位元組指示整個簽名（scriptSig）的長度，共120位元組

49：一個位元組指示實際簽名（DER-encoded）的長度（本例中72）加上一個位元組的雜湊型別SIGHASH_ALL（0x01），共73位元組；73=72+1

簽名：30460221009e0339f72c793a89e664a8a932df073962a3f84eda0bd9e02084a6a9567f75aa022100bd9cbaca2e5ec195751efdfac164b76250b1e21302e51ca86dd7ebd7020cdc06（72位元組），然後緊跟著01，sighash型別

41：一個位元組指示公鑰的長度，共65位元組

公鑰：0450863ad64a87ae8a2fe83c1af1a8403cb53f53e486d8511dad8a04887e5b23522cd470243453a299fa9e77237716103abc11a1df38855ed6f2ee187e9c582ba6（65位元組）

也即，從新交易的scriptSig中可以獲得對應著下圖中的第一部分和第二部分。

下圖實際上是從左向右逐步執行指令碼中每一個指令的過程。上部是棧的變化，下部分是執行的具體指令。

sig和pubKey是兩條資料指令，當遇到資料指令時，直接入棧；所以將新交易的輸入中的scriptSig部分中的簽名部分和公鑰部分入棧。後面五條指令中除pubKeyHash外都是操作指令，基於棧的語言從棧頂獲得輸入，然後將結果入棧。所以第一條Dup複製指令直接把pubkey複製了一份；Hash160指令對pubkey進行雜湊，將結果入棧；然後然後接下來是資料指令將新交易所引用的交易的輸出中的公鑰雜湊入棧，然後是比較指令，比較棧頂的兩個元素是否相等，如果相等彈出，如果不等則報錯。最後是checksig，使用public key來驗證簽名。如果驗證成功，那麼棧頂的兩個元素出棧，然後結果True入棧。

現在我們用一個例子再詳細地過一遍這個過程。之前的交易Tx1，也即新交易中的輸入的來源，我們假設是Alice支付給Bob的交易；新交易Tx2，也即Bob需要使用他在Tx1中獲得的幣。

為了驗證這個交易的合法性，礦工要能夠驗證Bob確實可以使用Tx1中的輸出。如何證明呢？首先就是因為Alice在Tx1交易中的scriptPubKey中，明確指定了一個雜湊地址，這個雜湊地址就是Bob的公鑰的雜湊。Bob為了證明自己就是這筆輸出的合法主人，他必須提供身份資訊，也即，在Tx2的輸入部分的scriptSig中他提供了簽名和完整的公鑰，簽名是使用私鑰對交易的簽名。

然後礦工開始執行驗證過程。礦工將Tx2的scriptSig部分和Tx1的scriptPubKey部分簡單的拼在一起，然後執行每一條指令。

首先是<sig>指令，這是資料指令，是來自於Bob的簽名，也即Tx2的中scriptSig的第一部分，入棧。

接下來是<pubkey>，同樣是資料指令，是來自於Bob的完整公鑰，也即Tx2的中scriptSig的第二部分，入棧。

第三條指令是OP_DUP，這是來自Tx1的Alice的輸出的scriptPubKey，OP_DUP新增到堆疊，因為是複製，所以用下面的資料把自己替換掉，這樣把BOB提供的公鑰複製了一份。

第四個指令是OP_HASH160，入棧，對下面的資料，也即Bob的公鑰進行兩次雜湊（SHA-256以及RIPEMD-160），把自己替換掉。這樣就獲得了Bob公鑰的雜湊值。

第五條指令是資料指令，<pubkeyhash>，同樣來自於交易Tx1，Alice指定的的輸出地址，入棧。這樣棧頂就有兩份雜湊值了。

下一條指令稍微複雜點，OP_EQUALVERIFY，入棧，相當於展開成EQUAL和VERIFY兩個操作。EQUAL的操作是檢查它下面的兩個值是否相等，這裡，也即檢查Alice指定的地址（棧頂）和Bob提供的完整公鑰生成的雜湊（棧頂第二個）是否相等。EQUAL會得到0(false)或者1(true)，然後使用這個值把替換自己。VERIFY檢查EQUAL的返回值，如果是false，則交易非法，如果是true，則將自己和true出棧。這裡，是為true的情況。

最後一條指令是OP_CHECKSIG入棧，對棧中的兩個元素進行檢查，當前棧中的資料實際就是Bob的輸入中提供的完整公鑰和對應私鑰的簽名，如果驗證通過則True入棧。

以上就是一個正確的Pay-to-PubKeyHash（P2PKH）的例子。

另外要注意一點細節就是如何使用公鑰來驗證簽名。也即，這個簽名是怎麼產生的？簽名是對什麼的簽名？我們知道簽名實際上就是使用私鑰對一段明文進行加密，那這裡的明文是什麼？這裡的問題是，首先，這段明文是礦工能夠訪問的，不然無法驗證；其次，這段明文必須是唯一的，不然Bob之前的簽名可能被攻擊者複製進行重放。

這裡答案就是整個交易Tx2。

確切地說，就是交易Tx2的除了簽名部分之外的內容（可以通過標誌位對進行簽名的交易內容進行簡化，在這個例子中，使用pubkey Script替代Signature做填充）。上圖共有三個部分，中間是Signed Data，也即被簽名的資料。上部是Tx1和Bob自己的資料，下部分是Bob最終形成的Tx2。從上部分和中間部分形成了下部。（簽名的另一個好處是，Tx2的明文部分也不能被攻擊者隨意篡改）

更多細節可以參考How to redeem a basic Tx?

以及OP_CHECKSIG - Bitcoin Wiki

最後，有兩個個問題可以討論一下：

1. 在驗證過程中，最後一步OP_CHECKSIG的輸入實際上就是在新交易中Bob提供的scriptSig的兩個部分，最後一步的驗證也就是在驗證Bob的私鑰。那中間還有那麼多步驟能不能省略呢？

2. 在引入比特幣地址（公鑰的雜湊）之前，早期的比特幣版本支援p2pk形式的交易，也即pay-to-public-key。這種交易的缺點是需要提前知道公鑰，而且針對攻擊的保護性較差。問題是：這種交易的scriptSig和scriptPubKey應該怎麼寫？