Web3.0安全开發實踐：9個sCrypt智能合約开發的最佳實踐

2024-12-25 16:12:52

sCrypt是一種基於TypeScript的嵌入式領域特定語言（eDSL），專為在比特幣鏈上編寫智能合約而設計。sCrypt智能合約使用比特幣支持的操作碼，可以編譯成Bitcoin Script。由此生成的類似匯編的腳本可用作交易中的鎖定腳本。

本文將探討sCrypt智能合約背後的概念，以及使用sCrypt編程的一些最佳實踐和安全檢查清單。

使用sCrypt編寫編寫智能合約：一個簡單示例

比特幣上的智能合約使用UTXO模型，每筆比特幣交易由輸入和輸出組成，每筆比特幣交易由輸入和輸出組成：

輸出包含：

比特幣的數量
字節碼（稱為locking script，“鎖定腳本”）

輸入包含：

對上一筆筆交易輸出的引用
字節碼（unlocking script，“解鎖腳本”）

未花費交易輸出（UTXO）是指在任何交易中尚未被消耗消耗的輸出。低級字節碼/操作碼，稱為Bitcoin Script[1]，由比特幣虛擬機（BVM）[2]解釋執行。

比特幣支持的操作碼可以編譯為Bitcoin Script。生成的類似匯編的腳本用作交易中的鎖定腳本。

如上圖展示的兩個交易，每個交易都有一個輸入（綠色）和一個輸出（紅色）。右側的交易使用了左側交易的輸出。鎖定腳本可以視為一個布爾函數f(x)，它定義了花費UTXO中比特幣的條件，起到“鎖”的作用（因此稱為“鎖定”）。解鎖腳本則提供了使f(x)結果為true的函數參數，充當“鑰匙”（也稱為見證）來解鎖它。只有當輸入中的“鑰匙”與先前輸出的“鎖”匹配時，才能花費該輸出中包含的比特幣。

在標准的比特幣支付中，鎖定腳本是“Pay To Pubkey Hash”（P2PKH）。它用於驗證付款人是否擁有與地址對應的正確私鑰，從而使他們能夠在解鎖腳本中生成有效的籤名。sCrypt語言使得鎖定腳本可以指定比簡單的P2PKH更加復雜的花費條件，即P2TR/P2SH交易中的比特幣智能合約。

sCrypt的智能合約在概念上類似於面向對象編程中的類。每個包都為特定類型的合約（例如P2PKH或多籤名）提供了模板，可以實例化為具體的可執行合約對象。

部署和調用sCrypt智能合約

sCrypt使用支付到見證腳本哈希（Pay-to-Witness-Script-Hash，P2WSH）來部署合約。部署過程包括將智能合約代碼編譯成腳本，對該腳本進行哈希處理，然後將哈希值放入一個P2WSH交易(Tx0)，並將其廣播到網絡。

當有人要調用已部署的合約時，他們會將完整的合約腳本和被調用方法的輸入作為見證數據嵌入到花費Tx0的後續事務(Tx1)中。

部署和交易調用：左側表示輸入，右側表示輸出

已知的sCrypt局限性

sCrypt可以在任何支持Bitcoin Script的區塊鏈上運行，包括比特幣分叉鏈和基於比特幣的鏈，如Litecoin和Dogecoin。

比特幣禁用了許多腳本操作碼，如OP_CAT和OP_MUL，這極大地限制了sCrypt能表述的智能合約類型。比特幣社區正在積極討論重新啓用這些操作碼並引入新的操作碼。如果變更的提議得到採納，sCrypt在比特幣上的功能將比現在更強大。

與此同時，有些區塊鏈具備完整的腳本操作碼，例如比特幣SV和MVC。如今，sCrypt在這些鏈上已達到滿負荷運行。

回溯至創世問題（Back-to-Genesis）

使用sCrypt的智能合約實現同質化代幣（FT）和非同質化代幣（NFT）時，會引發回溯至創世（Back-to-Genesis，B2G）問題，這是一個極大的安全挑战。該問題涉及在基於UTXO的區塊鏈中追蹤代幣的創建交易。在比特幣等區塊鏈上，通過sCrypt創建的代幣以UTXO形式存在，並可能被頻繁轉移。B2G問題的關鍵在於，當試圖追蹤或驗證代幣的完整歷史記錄時，需要找到其創世交易，以確認代幣的來源和真實性。

從各種角度上來說，這一點很重要。包括：

來源和真實性： 了解代幣的完整歷史可以讓用戶驗證其真實性和來源。用戶可能希望確保代幣有一個合法且可追溯的來源。
智能合約邏輯： 智能合約或去中心化應用可能會依賴於代幣的歷史。了解代幣的來源對於某些智能合約功能至關重要。

下圖展示了僞造基於sCrypt的FT和NFT的兩種方法。每個框代表一個交易，左側是輸入，右側是輸出。箭頭指向表示從一個交易到另一個交易的流轉過程。具有相同輸出顏色的交易使用相同的合約代碼。

Back-to-Genesis問題可能會引發代幣協議中的兩個問題：

重放攻擊（Replay Attack）： 攻擊者可能會重新發行相同的代幣。
中間人攻擊（Man-in-the-Middle Attack）： 攻擊者可以從一個不相關的UTXO开始，並復制一個代幣交易鏈。他們可以復制交易的輸出（如第1行所示），並將其逐字粘貼到另一個交易中（如第3行所示）。這種情況之所以可能發生，是因為鎖定腳本僅在解鎖時進行評估，而不是在部署時進行評估。從那時起，交易就可以用來創建一個並行的虛假代幣鏈。

解決方案

在這些場景中，交易因為滿足Layer-1的驗證而被礦工接受。被紅色圓圈標記的最後幾筆交易看起來完全相同。驗證代幣交易合法性的唯一方法是追溯到其發行交易（即創世交易）。

為了解決重放攻擊，我們建議實施一個全局唯一的ID，“GenesisID”，它代表發行交易的交易ID（txid）。當發行UTXO被消費時，該ID會被復制，並作為代幣ID保留在所有後續代幣傳輸UTXO中。

使用發行交易的TXID作為唯一的TokenID

為了減少中間人攻擊，我們建議开發者在當前交易之前回溯兩步，驗證父交易及其前一交易。

以下是一個簡單的示例，用於說明回溯驗證以及提前兩步驗證的重要性：

提前兩步驗證

當僞造的UTXO（UTXO1）被花費到另一個代幣UTXO（UTXO2）時，由於代幣合約並未被激活（UTXO的鎖定腳本僅在解鎖時執行），所以它會通過礦工驗證。然而，在我們建議的實現中，嘗試將UTXO2存入UTXO3需要同時驗證UTXO1和UTXO2。這樣，中間人攻擊就失敗了，因UTXO1不包含與UTXO2和UTXO3相同的解鎖合約，交易將因此被拒絕。

sCrypt安全提示與檢查清單

以下是CertiK在完成對一個基於sCrypt的FT/NFT項目審計後總結的安全提示和檢查清單：

1.驗證代幣的回溯是否准確，當前UTXO的鎖定腳本代碼段是否與前一個UTXO的匹配

sCrypt團隊提供了一個示例，可以幫助开發者設計回溯驗證流程：

2. 確保協議不會受到僞造創世ID的攻擊

這可以通過在回溯過程中驗證創世ID來實現，如下例所示：

檢查應確認當前的genesisTxid是否與創世交易的ID或前一個交易的ID匹配。

3. 確認UTXO輸入證明真實合法，而非僞造

必須驗證以下參數：

tokenTxHeader
prevTokenInputIndex
tokenTxInputProof
prevTokenTxProof

我們建議开發者在驗證UTXO輸入證明時遵循此流程圖。

4.確保代幣解鎖過程已得到適當授權

代幣可以由代幣所有者直接解鎖，也可以通過代幣鎖定合約進行解鎖。代幣所有者必須通過有效的籤名驗證其所有權，以解鎖代幣。如果通過智能合約解鎖代幣，必須遵守合約中規定的任何條款或限制。請注意，禁止解鎖被燒毀的代幣。

5.確保代幣轉移UTXO中的代幣數量保持一致，以防止雙花攻擊

已解鎖的代幣可以轉移到一個或多個接收錢包。重要的是確保作為輸入的代幣總量等於作為輸出的代幣總量。換句話說，正在轉移的代幣必須與可用的代幣相匹配，以保持平衡。通過強制執行這一要求，合約能夠防止雙花攻擊的可能性。

6.驗證是否選擇了適當的SigHash類型，明確指定交易的哪些部分被籤名

SigHash[3]標志決定了加密籤名涵蓋比特幣交易中哪些部分。默認情況下，使用SIGHASH_ALL標志，確保籤名涵蓋所有輸入和輸出。然而，選擇不同的SigHash類型時需要謹慎。例如，SIGHASH_NONE標志不會籤署任何輸出，這就可能引入安全漏洞。應用籤名後可更改的輸出可能會導致欺詐或操縱。

7.驗證合約完整性

在比特幣的UTXO模型中，智能合約通常是一次性且無狀態的。這是因為包含合約的UTXO一旦用完就會被銷毀，且不會在區塊鏈上留下痕跡。盡管這種設計簡單高效，但也存在安全風險，因為合約可能會被篡改。為此，需要驗證合約腳本代碼的哈希值，這包括將腳本的哈希值嵌入到腳本數據中。在交易過程中，將嵌入的哈希值與腳本的實際哈希值進行比較，即可確認腳本的完整性。

為了應對挑战，一種方法是驗證合約腳本代碼的哈希值。這種方法需要將腳本的哈希值作為數據的一部分保存在腳本內部。在執行涉及智能合約的交易時，可以將腳本代碼的哈希值與存儲的值進行比對。如果哈希值匹配，則確認合約腳本未發生變化，未被篡改。

8.驗證交易完整性

sCrypt提供了一個強大的庫叫做Tx，除了鎖定腳本和解鎖腳本外，還能檢查包含合約本身的整個交易。sCrypt通過這一全面的交易檢查功能，使合約能夠驗證輸入數據。

主要驗證步驟之一是將解鎖腳本的輸入與從交易預映像中提取的數據進行匹配。此外，還需要驗證txPreimage是否為當前交易的預映像。

9. 驗證數據完整性

在輸出的鎖定腳本中，智能合約被分為兩個部分：代碼和狀態。合約的狀態存儲在鎖定腳本的數據部分。在協議本身管理數據部分的場景中，必須特別注意數據字段的處理。至關重要的是，必須要驗證存儲在鎖定腳本數據部分的數據字段是否在正確的位置索引上進行訪問和存儲。