原文作者：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 密鑰被惡意重用。
聚合簽名在兩種情況下很有用：
當Arbitrum驅動程序從多個授權機構返回的 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 中實現盤點器結構：
加密貨幣靈活性順應密碼學趨勢
憑藉在密鑰對、簽名和哈希函數方面的加密的靈活性，Sui 在庫選擇、基礎簽名方案、編碼和哈希函數方面非常便捷。這不僅允許Sui 在庫有發現漏洞或某種方案有 bug 的情況下快速升級，還允許根據選擇的 cryptography primitives（密碼學原語）作為參數對整個系統進行基準測試。
資訊來源：由0x資訊編譯自8BTC。版權歸作者所有，未經許可，不得轉載