詳解 Sui 密碼學中的靈活性

原文作者：SophonLabs

Sui 在設計底層技術時考慮到了密碼學的靈活性。該系統支持多種密碼算法和 cryptography primitives（密碼原語），並可以在它們之間快速切換。開發人員不僅可以為系統選擇同類最佳的 best-of-breed cryptography（公開密鑰密碼體系），還可以實施最新的 algorithms（可用算法）。

Sui 在一個統一的類型別名或整個存儲庫共享的枚舉包裝器下定義其 cryptography primitives（密碼學原語），例如公鑰、簽名、聚合簽名和哈希函數。對這些原語進行更改會影響應用程序的所有組件。開發人員可以快速更新應用程序密碼並確保統一的安全性。

目前 Sui 通過執行交易端點支持以下用戶交易簽名方案：

1.Pure Ed 25519

2.Secp 256 k 1 ECDSA

用戶賬戶密鑰對的接口實現

下面是 Sui 中密鑰對錶示的 Demo。擴展到新的簽名方案非常簡單：

1.把它添加到 enum（枚舉類）

2.實現 fastcrypto 庫中定義的 KeyPair trait

用戶簽名通過擴展一個額外的 1 字節標誌來序列化，該標誌標識關聯的簽名方案。儘管 Sui 團隊考慮過使用 Multiformats（用於自描述數據的協議），但其可變標誌長度的性質使得序列化存在問題。相反，Sui 採用了單字節零起始標誌模型。簽名方案及其對應的標誌定義如下：

當用戶提交簽名交易時，交易執行指定以下參數：

BSC（Binary Canonical Serialization）序列化 transaction bytes 為 Base 64
Signature scheme flag（簽名方案標識），可以傳參為“ed 25519 ”或“secp 256 k 1 ”
公鑰的 Base 64 格式
其 scheme 對應的簽名的 Base 64

如下代碼是執行已簽名的交易，curl 如果成功則返回證書和交易結果。

如下代碼展示了 Sui 的全節點如何將 API 請求字段組裝成序列化簽名 flag || signature || pubkey 並在執行前進行驗證檢查。

Sui 支持不同的簽名方案的緣由剖析

使用 secp 256 k 1 橢圓曲線的 ECDSA 被比特幣、以太坊和其他加密貨幣廣泛採用。用戶可能更喜歡這種簽名方案，因為他們想利用現有的錢包和託管密鑰管理工具，例如閾值簽名（國內密碼學中的翻譯為“門限密碼體系的門限簽名”）和多簽。此外，它與雲基礎設施和硬件安全模塊（常見的如密碼機 uk 硬件錢包等）具有更好的兼容性，同時支持從消息和簽名負載中恢復公鑰。

同時，Ed 25519 是一種更現代的簽名方案，具有確定性快速簽名和簡化數學的特點。雖然 Typescript SDK 支持這兩種簽名方案。但是 Sui 還是選擇 Ed 25519 作為推薦的 Sui 錢包算法。

因為 Sui 支持不同簽名方案，在後面使用 secp 256 r 1 曲線（也稱為 NIST-P 256 ）添加諸如 ECDSA 之類的方案將花費很少的精力，這條曲線目前是原生手機和未來密碼學中都要支持的一條曲線，也是目前社區一個普遍要求的功能。

對這種靈活的簽名方案支持還使 Sui 系統與不安全的空簽名方案進行基準測試。對於像 Sui 這樣的快速執行系統，并行設計簽名和驗證也發生在事務級別，而不僅僅是區塊層，加密靈活性讓 Sui Check 出加密操作給系統帶來的開銷。這些基準測試結果已經能夠為 Sui 提供識別瓶頸和優化方向。

授權密鑰對

Authority on Sui（驗證者集合）持有三個不同的密鑰對：

Protocol keypair 協議密鑰對
Account keypair 帳戶密鑰對
Network keypair 網絡密鑰對

Protocol keypair 協議密鑰對

如果用戶簽名的交易經過驗證，協議密鑰對會提供授權簽名。當為用戶交易提供簽名的權力機構的佔比超過所需的三分之二門檻時，Sui 將執行交易。目前選擇 BLS 12381 方案來快速驗證給定數量的授權機構的聚合簽名。特別是決定使用 minSig BLS 模式，根據該模式，每個單獨的公鑰為 96 字節，而簽名為 48 字節。後者很重要，因為通常驗證者在每個紀元開始時註冊一次他們的密鑰，然後他們不斷地簽署交易；因此 Sui 優化了最小簽名大小。

注意！使用 BLS 方案，可以聚合獨立簽名，從而產生單個 BLS 簽名有效負載。Sui 還將聚合簽名與bitmap（位圖）一起表示簽名的驗證器。這有效地將當局的簽名大小從( 2 f + 1) × BLS_sig 大小減少到只有一個 BLS_sig 有效負載，這反過來具有網絡開銷優勢，可以獨立於驗證器集大小的壓縮交易證書。

密鑰材料類型別名集中在整個存儲庫使用的單個位置。事實上，僅通過 changing the alias(更改別名)（對聚合簽名代碼中對的 alias 參數序列化傳參時候修改）就將協議密鑰的 Sui 從 Ed 25519 切換到了 BLS 12381 。

為了解決 BLS 12381 聚合簽名的潛在惡意密鑰攻擊，在權限註冊期間使用密鑰知識證明 ( KOSK )。當授權機構請求添加到驗證器集時，將提交並驗證所有權證明。校驗協議密鑰 kosk || protocol public key || sui address。與大多數標準不同，Sui 的知識證明方案也提交到地址，這提供了額外的保護，防止來自另一個惡意驗證器的驗證器的 BLS 密鑰被惡意重用。

聚合簽名在兩種情況下很有用：

當仲裁驅動程序從多個授權機構返回的 SignedTransaction 形成 CertifiedTransaction 時

當權限形成 SignedCheckpointSummary 時，每個權限都會對檢查點內容進行簽名

Account keypair 帳戶密鑰對

監管機構用來接收質押獎勵付款的賬戶由賬戶密鑰對保護，使用 Ed 25519 作為簽名方案。

Network keypair 網絡密鑰對

私鑰用於執行 QUIC 對 Narwhal primary 及其 worker 網絡接口所需的 TLS 握手。公鑰用於驗證節點 ID，Ed 25519 用作簽名方案。

哈希和編碼靈活性

目前，Sui 的默認哈希函數是 sha 3256 ，正在運行基準測試以與 sha 256 和 blake 2/blake 3 系列進行比較。為了支持編碼靈活性，Base 64 和 Hex 在 fastcrypto 中定義了一個編碼特性，作為一個包裝器base 64 ct::Base 64 和 hex 及其定製的序列化和驗證。值得注意的是，選擇了base 64 ct crate 而不是最流行的 base 64 Rust crate，因為 a) 它是恆定時間 b) 明確拒絕損壞的編碼以防止解碼時的延展性攻擊。Sui 的研究團隊成員最近報告了大多數 base 64 解碼器庫中令人驚訝的延展性問題，獲得了AsiaCCS 2022 最佳 Poster 獎，這是密碼學和安全領域的重要會議之一。

下面的代碼片段顯示了如何在 fastcrypto 中實現包裝器結構：