Sui 在设计底层技术时考虑到了密码学的灵活性，这篇文章将对此进行介绍和解读。
Sui 在设计底层技术时考虑到了密码学的灵活性。该系统支持多种密码算法和cryptography primitives（密码原语），并可以在它们之间快速切换。开发人员不仅可以为系统选择同类最佳的best-of-breed cryptography（公开密钥密码体系），还可以实施最新的algorithms（可用算法）。
Sui 在一个统一的类型别名或整个存储库共享的枚举包装器下定义其cryptography primitives（密码学原语），例如公钥、签名、聚合签名和哈希函数。对这些原语进行更改会影响应用程序的所有组件。开发人员可以快速更新应用程序密码并确保统一的安全性。
目前Sui 通过执行交易端点支持以下用户交易签名方案：
1.Pure Ed25519
2.Secp256k1 ECDSA
用户账户密钥对的接口实现
下面是 Sui 中密钥对表示的Demo。扩展到新的签名方案非常简单：
1.把它添加到 enum（枚举类）
2.实现fastcrypto库中定义的 KeyPair trait
用户签名通过扩展一个额外的 1 字节标志来序列化，该标志标识关联的签名方案。尽管Sui团队考虑过使用Multiformats（用于自描述数据的协议），但其可变标志长度的性质使得序列化存在问题。相反，Sui采用了单字节零起始标志模型。签名方案及其对应的标志定义如下：
当用户提交签名交易时，交易执行指定以下参数：
- BSC（Binary Canonical Serialization）序列化transaction bytes 为Base64
- Signature scheme flag（签名方案标识），可以传参为“ed25519”或“secp256k1”
- 公钥的Base64格式
- 其scheme对应的签名的Base64
如下代码是执行已签名的交易，curl 如果成功则返回证书和交易结果。
如下代码展示了 Sui 的全节点如何将 API 请求字段组装成序列化签名flag || signature || pubkey并在执行前进行验证检查。
Sui支持不同的签名方案的缘由剖析
使用 secp256k1 椭圆曲线的 ECDSA 被比特币、以太坊和其他加密货币广泛采用。用户可能更喜欢这种签名方案，因为他们想利用现有的钱包和托管密钥管理工具，例如阈值签名（国内密码学中的 翻译为“门限密码体系的门限签名”）和多签。此外，它与云基础设施和硬件安全模块（常见的如密码机 uk 硬件钱包等）具有更好的兼容性，同时支持从消息和签名负载中恢复公钥。
同时，Ed25519 是一种更现代的签名方案，具有确定性快速签名和简化数学的特点。虽然 Typescript SDK 支持这两种签名方案。但是Sui还是选择 Ed25519 作为推荐的 Sui 钱包算法。
因为Sui 支持不同签名方案，在后面使用secp256r1曲线（也称为 NIST-P256）添加诸如 ECDSA 之类的方案将花费很少的精力，这条曲线目前是原生手机和未来密码学中都要支持的一条曲线，也是目前社区一个普遍要求的功能。
对这种灵活的签名方案支持还使 Sui 系统与不安全的空签名方案进行基准测试。对于像 Sui 这样的快速执行系统，并行设计签名和验证也发生在事务级别，而不仅仅是区块层，加密灵活性让Sui Check出加密操作给系统带来的开销。这些基准测试结果已经能够为Sui提供识别瓶颈和优化方向。
授权密钥对
Authority on Sui（验证者集合）持有三个不同的密钥对：
- Protocol keypair 协议密钥对
- Account keypair 帐户密钥对
- Network keypair 网络密钥对
Protocol keypair 协议密钥对
如果用户签名的交易经过验证，协议密钥对会提供授权签名。当为用户交易提供签名的权力机构的占比超过所需的三分之二门槛时，Sui 将执行交易。目前选择 BLS12381 方案来快速验证给定数量的授权机构的聚合签名。特别是决定使用 minSig BLS 模式，根据该模式，每个单独的公钥为 96 字节，而签名为 48 字节。后者很重要，因为通常验证者在每个纪元开始时注册一次他们的密钥，然后他们不断地签署交易；因此Sui优化了最小签名大小。
注意！使用 BLS 方案，可以聚合独立签名，从而产生单个 BLS 签名有效负载。Sui还将聚合签名与bitmap（位图）一起表示签名的验证器。这有效地将当局的签名大小从(2f + 1) × BLS_sig大小减少到只有一个BLS_sig有效负载，这反过来具有网络开销优势，可以独立于验证器集大小的压缩交易证书。
密钥材料类型别名集中在整个存储库使用的单个位置。事实上，仅通过changing the alias(更改别名)（对聚合签名代码中对的alias参数序列化传参时候修改）就将协议密钥的 Sui 从 Ed25519 切换到了 BLS12381。
为了解决 BLS12381 聚合签名的潜在恶意密钥攻击，在权限注册期间使用密钥知识证明 (KOSK )。当授权机构请求添加到验证器集时，将提交并验证所有权证明。校验协议密钥 kosk || protocol public key || sui address。与大多数标准不同，Sui的知识证明方案也提交到地址，这提供了额外的保护，防止来自另一个恶意验证器的验证器的BLS密钥被恶意重用。
聚合签名在两种情况下很有用：
- 当仲裁驱动程序从多个授权机构返回的SignedTransaction形成CertifiedTransaction时
- 当权限形成SignedCheckpointSummary时，每个权限都会对检查点内容进行签名
Account keypair 帐户密钥对
监管机构用来接收质押奖励付款的账户由账户密钥对保护，使用 Ed25519 作为签名方案。
Network keypair 网络密钥对
私钥用于执行QUIC对Narwhal primary 及其 worker 网络接口所需的TLS握手。公钥用于验证节点 ID，Ed25519 用作签名方案。
哈希和编码灵活性
目前，Sui 的默认哈希函数是 sha3256，正在运行基准测试以与 sha256 和 blake2/blake3 系列进行比较。为了支持编码灵活性，Base64和Hex在fastcrypto中定义了一个编码特性，作为一个包装器base64ct::Base64和 hex 及其定制的序列化和验证。值得注意的是，选择了base64ctcrate 而不是最流行的 base64 Rust crate，因为 a) 它是恒定时间 b) 明确拒绝损坏的编码以防止解码时的延展性攻击。Sui的研究团队成员最近报告了大多数 base64 解码器库中令人惊讶的延展性问题，获得了AsiaCCS 2022 最佳Poster奖，这是密码学和安全领域的重要会议之一。
下面的代码片段显示了如何在fastcrypto中实现包装器结构：
加密灵活性顺应密码学趋势
凭借在密钥对、签名和哈希函数方面的加密的灵活性，Sui 在库选择、基础签名方案、编码和哈希函数方面非常便捷。这不仅允许 Sui 在库有发现漏洞或某种方案有bug的情况下快速升级，还允许根据选择的cryptography primitives（密码学原语）作为参数对整个系统进行基准测试。
