jakiro
背景
前段時間，我們在初識 TON：帳號、Token、交易與資產安全中討論了 TON 的特點及用戶資產安全問題。今天，我們一起來學習另一個新興的高性能區塊鏈平臺 —— Sui，它具備多項創新技術和獨特特性，吸引了開發者和研究人員的關注。Sui 專注於提供快速、安全的交易體驗，適合各種應用場景。本篇文章將通過講解 Sui 的帳號模型、代幣管理、交易機制和資產安全等內容，幫助讀者認識 Sui。
帳號模型
地址
Sui 遵循加密貨幣行業中廣泛接受的錢包規範，包括 BIP-32（及其變種 SLIP-0010）、BIP-44 和 BIP-39，以便為用戶提供密鑰管理。
為了派生一個 32 字節的 Sui 地址，Sui 使用 BLAKE2b（256 位輸出）哈希函數將籤名方案標誌（1 字節）與公鑰字節連接起來。Sui 地址當前支持純 Ed25519、Secp256k1、Secp256r1 和 MultiSig，對應的標誌字節分別為 0x00、0x01、0x02 和 0x03。
餘額
在 Sui 上，一切都是對象，用戶的餘額也是對象。在轉帳過程中，如果對象中包含的餘額不等於需要的數值，則需要將對象拆分或合併。例如，你有一個包含 100 SUI 的對象，但你只想轉帳 30 SUI，那麼系統會將這個對象拆分為兩個對象：一個包含 30 SUI，另一個包含 70 SUI。你可以轉移包含 30 SUI 的對象，而保留剩下的對象。反之，如果需要更大的數額，你也可以將多個餘額對象合併，形成一個更大的數額對象。
代幣管理
Sui 官方實現了 Coin 的標準代碼，開發者在發行 Coin 時只需要在合約裡調用 `use sui::coin;` 就可以使用這個標準庫的所有功能。
由於使用了 Move 語言，與其他區塊鏈常用的程式語言（如 Solidity）有所不同，開發者在使用時需要了解並注意一些獨特的功能或特性，我們來看一段代碼：
這是一個完整的 Coin 發行合約，Sui 上的智能合約設計與以太坊或 Solana 等區塊鏈平臺有所不同，我們在原始碼中看不到權限的管理。使用該函數創建 Coin 時(coin::create_regulated_currency)，合約的創建者會收到一個 TreasuryCap 對象，該對象是鑄造新 Coin 或銷毀現有 Coin 所必需的。只有有權訪問此對象的地址才能維護 Coin 發行。
對於收到 Coin 的用戶來說，他的帳號控制了這些代幣的所有權，在調用智能合約使用這些代幣時，也需要傳入這些對象，並對交易進行籤名。
交易機制
交易是基本的區塊鏈世界中的概念，它是與區塊鏈交互的一種方式。交易用於更改區塊鏈的狀態，並且是唯一的方法。在 Sui 使用的 Move 程式語言中，交易用於調用包中的函數、部署新包以及升級現有包。
在構建交易時需要注意，每筆交易要明確地指定其操作的對象！這點和 Solana 的交易需要傳入帳號有一些相似。
交易包含的內容：
-
發送方 — 籤署交易的帳戶
-
指令列表（或指令鏈）– 要執行的操作
-
命令輸入 — 命令的參數：純文本 — 簡單的值，如數字或字符串，或對象 — 交易將訪問的對象
-
Gas 對象 — 用於支付交易的 Coin 對象
-
Gas 價格和預算 — 交易成本
合約安全
Sui 使用 Move 做為智能合約的程式語言，在一定程度上能解決 Solidity 高發的漏洞問題，如重入攻擊、整數溢出、雙花、DoS 攻擊和編譯器問題，但避免不了開發者在代碼中引入錯誤，因此安全審計依舊是必要的。以下是開發者在開發過程中需要注意的一些事項：
1. 權限檢查： 分析對外函數所接收的對象類型，對於涉及敏感操作的特權函數，需要確保傳入的對象是具有特權的對象。如果函數接收並使用了特權對象，那麼函數調用者必須是該對象的合法擁有者。
2. 對外函數檢查： 有些函數本身不應該被外部直接調用，如果有不應該外放的函數接口，開發者要提出該函數不宜公開。
3. 對象分析檢查： 由於 Sui 裡面的對象可以被轉成公共對象(Shared Object)，因此，開發者要整理出所有用到的對象的類型，確認它們是靜態的還是公共的，以及是否存在錯誤。如果把應該私有化的對象轉換成了公共對象，那麼任何人都可以使用這個對象，這就存在安全風險。
4. Coin 消耗檢查： Sui 的代幣模型與其他鏈的有所不同，其設計允許代幣對象可以被其他對象包含和持有，還可以進行拆分，由此衍生出了幾種代幣消耗模式：
-
直接將代幣對象轉移給另一個對象；
-
將代幣對象進行結構調整後生成一個新的對象，再轉移給目標對象；
-
將代幣對象拆分，並將拆分出來的部分轉移給新對象。
因此，在代幣消耗的情況下，開發者需要檢查以下幾點：
-
消耗的金額是否正確；
-
對象是否已經轉移；
-
如果有拆分，拆分的數額對不對。
5. 預言機價格操縱攻擊： 如果 Sui 上的合約使用預言機來獲取價格，那麼也需要注意價格被操縱的可能性。開發者可以通過引入多個數據源和共識機制，以防範單一數據源被操縱的風險。此外，還可以使用時間加權平均價格來防範預言機操縱風險。
6. 治理攻擊： 在 Sui 上的合約中，如果治理代幣的投票權設計不合理，也存在遭遇治理攻擊的風險，這方面可以參考一些成熟的去中心化組織的社區治理邏輯。
7. 套利攻擊： 如果邏輯設計不合理，Sui 上的 DeFi 合約也存在套利攻擊的風險。開發者在開發的時候應仔細審查合約中的邏輯，避免被攻擊者利用。
8. 假充值攻擊： 交易所或開發者在處理 Sui 代幣充值時，還需要注意檢查交易的狀態是否成功，代幣的 Package ID 是否正確，防範假充值攻擊。
總結
在本文中，我們簡單探討了 Sui 的設計特點，包括其帳號模型、代幣管理、交易機制以及合約安全性。利用 Move 程式語言，Sui 在確保高性能與低延遲的同時，還引入了創新的數據模型和對象存儲方法，顯著提升了安全性和靈活性。相比其他區塊鏈平臺，Move 語言在防止常見的智能合約漏洞（如溢出、重入攻擊等）方面表現出色，這使得 Sui 在技術層面上更加穩健和可靠。然而，開發者仍需關注業務邏輯層面的安全性，特別是在權限管理、對象類型的使用以及代幣消耗方面，謹防由於代碼中的錯誤或不當設計而導致資產損失。
參考連結：
https://docs.sui.io/
https://docs.sui.io/standards/coin
https://move-book.com/
