經(jīng)過第五章的學(xué)習(xí)，其實對區(qū)塊鏈有一個更深的了解，就是，不僅區(qū)塊前后相連，而且交易和交易之間也是相連，一個普通交易的輸入部分總是前面某個交易的輸出UTXO。在《比特幣 (1)：傳統(tǒng)貨幣和比特幣的區(qū)別》中看到的相連，就是普通交易之間的相互連接；在《比特幣 (2)：區(qū)塊鏈的大致結(jié)構(gòu)》中看到的相連，是區(qū)塊之間的相互連接。

假設(shè)你已經(jīng)閱讀完第五章，對于為啥需要腳本也比較清楚了。首先明確一下，交易輸入其實是之前某個交易的某個輸出UTXO，是按照之前那個交易的Hash值加上對應(yīng)輸出在該交易中的位置標記的。一旦UTXO被選中，錢包會為每個UTXO生成包含簽名的解鎖腳本，換句話說，每個解鎖腳本都對應(yīng)的是一個之前某個輸出的某個UTXO。

對于解鎖腳本加上鎖定腳本拼在一起，按照棧的方式運算，這個書中第五章已經(jīng)說得很明確了，最重要的是棧操作的最后一步：

棧內(nèi)是操作符是CHECKSIG

其實CHECKSIG很簡單，就是基于一定的規(guī)則，看看之前錢包生成的正不正確。CHECKSIG的步驟肯定和生成的過程相同。我們來看看CHECKSIG的過程，其實也就知道了生成的過程。如下圖：

正如前面所述，正在檢查的這個解鎖腳本，是放在該交易下面的該輸入中，會對應(yīng)一個之前某個交易的某個輸出UTXO，那么假設(shè)，之前這個交易叫 TxPrev，而當前包含這個解鎖腳本的交易叫TxNew(即TxNew的某個輸入是該UTXO)。按照上圖中說明的CHECKSIG的步驟(根據(jù)簽名類型SIGHASH_ALL對整個交易進行驗證)：

1. 在棧中pop出和

2. TxPrev中該UTXO對應(yīng)的輸出腳本，也即鎖定腳本，會有很多的操作系列，每個操作系列之間使用OP_CODESEPARATOR分隔。取這個腳本最后一個操作系列，也就是倒數(shù)第一個OP_CODESEPARATOR和腳本結(jié)束之間的部分(上圖與該邏輯不符合)，取出來即為Subscript，注意該Subscript對應(yīng)的是TxPrev下面的一個輸出UTXO。

(3. 在Subscript中去掉簽名)

4. 在Subscript中移除OP_CODESEPARATORS

5. 之前從棧中彈出的，最后一個字節(jié)代表的是簽名類型，1是指SIGHASH_ALL，對整個交易進行驗證。一個字節(jié)沒有所謂的大小端問題。

6. 復(fù)制TxNew為TxCopy

7. 將交易TxCopy中的所有輸入中的解鎖腳本置為空(因為上面說過，CHECKSIG是和生成的過程對應(yīng)，生成的時候，該部分都沒有，所以驗證的時候該部分肯定得去掉)

8. TxCopy中正在檢查的解鎖腳本位置，替換為經(jīng)過步驟4處理完的Subscript

9. 序列化TxCopy，添加4字節(jié)的簽名類型，即在步驟5中提到的簽名類型，因為在5中是1個字節(jié)，現(xiàn)在變成4個字節(jié)，這時候才會涉及大小端問題，存為小端模式。得到的最終信息假設(shè)叫verifyThisStr。

10. 之前是個人錢包使用私鑰對SHA256(SHA256(verifyThisStr))進行ECDSA加密的結(jié)果，現(xiàn)在已經(jīng)重新計算出來了verifyThisStr，其他人驗證的時候，利用對應(yīng)的公開的公鑰，對進行ECDSA解密，看是否與SHA256(SHA256(verifyThisStr))相同即可??！(反過來也是一樣的)

至此，交易腳本的驗證過程結(jié)束。

這里面最重要的是：

1. 生成verifyThisStr的過程，確保了每次進行加密解密的內(nèi)容都不一樣

2. 個人錢包使用用戶的私鑰進行加密，其他人利用用戶公開的公鑰進行解密