從安全角度看Move 語言特性與可能存在的漏洞

圖片來源：由無界版圖AI工俱生成

此前，Beosin 宣布了全新升級的安全審計服務，而現在，Beosin 安全團隊正式宣布推出針對Move 智能合約的安全審計服務，旨在提前發現並協助項目方修復項目中的安全風險，保障用戶與項目方的資產安全。

1、基礎概念

Move 語言最初是由Facebook 團隊為Diem（原名Libra）區塊鏈而設計開發的一門新語言。而Libra 的使命是打造一個簡單的全球貨幣和金融基礎設施，為數十億人提供支持。 Move 語言旨在提供一個安全、可編程的基礎，可以在此基礎上構建這一願景。 Move 必須能夠以精確、可理解和可驗證的方式表達Diem 貨幣和治理規則。從長遠來看，Move 必須能夠對構成金融基礎設施的各種資產和相應的業務邏輯進行編碼。

那麼，如何實現這一願景呢？在Move 的白皮書中提出了設計時考慮的四個關鍵目標：first-class 資產、靈活性、安全性和可驗證性。其中first-class 資產是實現這一願景的基礎。要理解first-class 資產，我們先來介紹Move 語言中的幾個比較重要的基礎概念。

1.1 結構體

和其他很多語言一樣，Move 語言中的結構體也是使用struct 定義。它是自定義類型，也是Move 中創建自定義類型的唯一方法。結構體可以包含複雜數據，也可以不包含任何數據，但不允許定義遞歸結構體。結構體由字段組成，可以簡單地理解成「key-value」存儲，其中key 是字段的名稱，而value 是存儲的內容。

1.2 能力

Move 的類型系統非常靈活，每種類型都可以被四種限制符所修飾。這四種限制符我們稱之為abilities，它們的功能分別是：

• Copy – 被修飾的值可以被複製。

• Drop – 被修飾的值在作用域結束時可以被丟棄。

• Key – 被修飾的值可以作為鍵值對全局狀態進行訪問。

• Store – 被修飾的值可以被存儲到全局狀態。

而Move 的基本類型缺省具有store, copy 和drop 限制，自定義類型缺省情況下結構體不帶任何限制符。

1.3 資源

介紹完了結構體和能力，接下來就是Move 語言中的核心概念：資源（resource）。

如果定義的結構體（struct）不能複制（copy）也不能丟棄（drop），我們就將它們稱為資源。默認情況下，結構體是線性和短暫的。它們不能複制，不能丟棄，不能存儲在全局存儲中。這意味著所有值都必須擁有被轉移的所有權，並且值必須在程序執行結束時處理。我們可以通過賦予結構體能力（abilities）來簡化這種行為，允許值被複製或刪除，以及存儲在全局存儲中或定義全局存儲的模式。

Move 語言中的這個屬性對於現實世界中資源（例如貨幣）的建模非常有用，因為貨幣在理論上是不希望在流通過程中被複製或丟失的。

1.4 模塊

Move 語言中，代碼都是以模塊（module）的形式進行組織的。如何理解模塊呢？抽象的理解，Move 語言中的模塊（module）/ 資源（resource）/ 方法（function）之間的交互與傳統的面向對象語言中的類（class）/ 對象（object）/ 方法（function）之間的關係非常相似。

而與其他區塊鏈語言相比，Move 中的模塊類似於其他區塊鏈中的智能合約。開發者在模塊中聲明資源類型和方法，這些類型和方法定義了創建、銷毀和更新已聲明資源的規則。

1.5 泛型

Move 因為是靜態語言，所以為了保證擴展性，Move 選擇了泛型編程的範式。

以Aptos 為例，只要查看你持有的資產是0x1::coin::CoinStore 這樣的類型，就可以知道該資產是由標準模組0x1::coin 所定義。比如說Aptos 的原生幣AptosCoin 的類型是0x1::aptos_coin::AptosCoin ，意思是0x1 帳號之下的aptos_coin 模塊所定義的AptosCoin 類型，不過這個類型並沒有賦予key 能力，所以不能成為資源，他只提供一個種類，而這個類型可以作為泛型來使用，像是被0x1::coin::CoinStore 使用。

那麼，0x1::coin::CoinStore 就是0x1 帳號下coin 模塊所定義的CoinStore 類型，記錄地址下某種coin 的資產狀態。所以你的地址下任何0x1::coin::CoinStore 的資產都通用相同邏輯、有一樣的行為，都是定義在0x1::coin 這個模塊裡。

2. 安全性

2.1 設計安全

Move 在白皮書中明確表示，Move 必須拒絕不滿足關鍵屬性的程序，例如Resource 安全、類型安全和內存安全。我們如何選擇一個可執行的表示，以確保在區塊鏈上執行的每個程序都滿足這些屬性？兩種可能的方法是：

(a) 使用帶有檢查這些屬性的編譯器的高級編程語言

(b) 使用低級無類型彙編並在運行時執行這些安全檢查。

Move 採取了介於這兩個極端之間的方法。 Move 的可執行格式是一種類型化的字節碼，它比彙編高級，但比源語言低。字節碼由字節碼驗證器在鏈上檢查Resource、類型和內存安全性，然後由字節碼解釋器直接執行。這種選擇允許Move 提供通常與源語言相關的安全保證，但無需將源編譯器添加到受信任的計算庫或將編譯成本添加到交易執行的關鍵路徑中。

除此之外，Move 在設計時內置了很多安全特性，例如算數溢出、默認可見性導致的權限洩露等等。

2.2 底層安全

2.2.1 資源

在現實社會中，資產有兩個屬性難以用數字表示：

1）稀缺性。必須控制系統中資產發行的數量。必須禁止複制現有資產，而創建新資產是一項特權操作。

2）訪問控制。系統參與者必須能夠使用訪問控制策略保護資產。

因此，Move 引入了資源來表示資產。而在區塊鏈應用中，代幣就是一種資源，資源必須要存儲在賬戶下面，且在交易過程中，資產必須要流向一個地方，要么轉移到另一個地址，要么被銷毀，代幣不可被複製或被使用多次或被「懸掛（dangling）」。此處可以把資源的操作類比成c++ 中的唯一指針。

2.2.2 先字節驗證，後合約執行

Move 在設計時就設計為一種可執行的字節碼語言，其具有內置的安全算法和字節碼驗證器（Bytecode verifier），可以防止許多常見錯誤。即Move 中的合約代碼要能被執行，必須先被驗證，這使得合約可以免受編譯器的潛在故障和可能遭遇到的攻擊。 Krešimir Klas 在其《Smart Contract Development — Move vs. Rust》中表示：「Move 的顯著特徵是可執行的字節碼表示，為所有程序提供了資源安全保證。考慮到合約的開放部署模型，這一點至關重要——回想一下，任何合約都必須容忍與不可信代碼進行任意交互。如果源碼級線性可以被可執行級別上不受信任的代碼違反，那麼其價值就很有限。」

2.2.3 靜態調用

在區塊鏈中，合約的調用方式可以分為靜態調用和動態調用。若程序調用必須在運行時才能確定被調用的目標，則稱該調用為動態調用；反之，在運行前即可確定被調用目標，且在運行時無法變更該目標，則稱該調用為靜態調用。

Move 採用靜態調用方式。即Move 實現的合約在部署時，其執行邏輯已經被確定。那麼我們可以通過靜態分析字節碼，得到合約所有可能路徑上操作的狀態，在區塊瀏覽器或錢包裡提示給用戶。

因此，錢包提供商可以在錢包設計中，在預執行合約時把合約執行後的狀態變更提示給用戶，讓用戶可以知道這個交易操作了自己的哪些重要資產，以及執行後的結果。如下圖，在StarMask 中的實現效果：

圖源自jolestar.eth

3. Move 與Solidity 的比較

3.1 賬戶模型

Solidity：

在大多數以太坊ERC-20 合約中，每個地址的餘額都存儲在一個類型的狀態變量mapping(address => uint256) 中，該狀態變量存儲在特定智能合約的全局存儲中。其結構如下圖所示：

圖源：https://github.com/move-language/move/tree/main/language/documentation/tutorial

Move：

Move 中，類比solidity 智能合約的模塊瑟吉歐沒有自己存儲空間的。相反，Move 的「全局存儲」是由地址索引的，每個地址下存儲了Move 模塊和Move 資源，而資源存儲是類型到值的映射。其結構如下圖所示：

圖源：https://github.com/move-language/move/tree/main/language/documentation/tutorial

3.2 代碼存儲

Solidity：

在基於EVM 的鏈中，所有智能合約都有一個獨特的地址，稱為「合約擁有地址」。合約賬戶與部署者賬戶（EOA）存在於在同一級別，代碼hash 存儲在合約賬戶地址中，合約部署後不與部署者地址綁定。

Move：

在基於MoveVM 的鏈中，代碼存儲在Account resource 的code module 裡面。

3.3 安全隔離

Solidity：

智能合約的運行環境是鏈的節點給構造出的沙箱環境，多個合約程序是運行在同一個進程內的不同的虛擬機沙箱。智能合約之間的調用是同一個進程內不同的智能合約虛擬機之間的調用，安全完全依賴於智能合約虛擬機之間的隔離。

Move：

Move 的做法則是通過MoveVM 讓採用Move 語言的區塊鏈具備確定性，將合約調用放在同一個虛擬機沙盒中，通過編程語言內部的安全性對智能合約的狀態進行隔離，而非依賴虛擬機進行隔離。

3.4 合約升級

Solidity：

EVM 中合約升級的方法是將合約數據和邏輯分析：代理合約（Proxy）負責轉發交易到邏輯合約，並保存合約數據；邏輯合約（Logic）負責實現功能邏輯。升級時，只需要重新部署新版本的邏輯合約，並將代理合約中的邏輯合約實例指向新版本邏輯合約實例即可。此時，邏輯合約升級並不會影響合約原來已有的數據。

如下圖，代碼存儲字段指定的是代理能合約被調用時做delegate call 的合約代碼，合約升級本質上是部署一個新的邏輯合約，並改變code 字段以重定向delegate call。

Move：

Move 語言中對於合約升級，其實現是在系統模塊code.move 中執行升級邏輯，在代碼部署前檢查升級策略和兼容性。在兼容性檢查後，寫在resource 中的代碼通過一個原生函數調用被替換，並將執行新的邏輯。

圖片截取自：https://github.com/aptos-labs/aptos-core/blob/main/aptos-move/framework/aptos-framework/sources/code.move#L132

4. Move 程序可能出現的漏洞點

1） 開發者在使用Aptos、Sui，或者其他基於Move 的blockchain 中獨特的Framework 進行開發時，應保持一定程度的安全意識，確保供應鏈安全。

2） 函數權限問題。對於一些函數調用的權限要仔細劃分，因為一些關鍵函數會涉及到治理，嚴重的會影響到資金安全，針對這種函數調用需要對調用者進行鑑權。

3） 業務邏輯在設計和代碼實現時，均需注意其中的邏輯問題。

4） 關於Move 系項目，在模塊升級時需要注意的點：

• 根據合約升級政策，代碼的所有者對升級權限有完全的控制權。

• 代碼的owner 在初始部署後是不可改變的。

• 部署者的地址在部署後永遠擁有升級權限。

原文標題：《Beosin | 正式推出針對Move 智能合約的安全審計服務，從安全角度看Move 語言（上、下）》

撰文：Beosin

來源：DeFi之道