Skip to main content

签名

当用户提交一个已签名的交易时，会提交一个序列化的签名和一个序列化的交易数据。序列化的交易数据是结构体 TransactionData 的BCS序列化字节，而序列化的签名被定义为 flag || sig || pk 字节的串联。

flag 是一个1字节的表示，对应于签名者选择的签名方案。以下表列出了每个签名方案及其对应的标志：

SchemeFlag
Ed25519 Pure0x00
ECDSA Secp256k10x01
ECDSA Secp256r10x02
multisig0x03

sig 字节是签名的压缩字节表示，而不是DER编码。以下表列出了每种格式的预期大小：

SchemeSignature
Pure Ed25519Compressed, 64 bytes
ECDSA Secp256k1Non-recoverable, compressed, 64 bytes
ECDSA Secp256r1Non-recoverable, compressed, 64 bytes
multisigBCS serialized all signatures, size varies

The pk bytes are the bytes representation of the public key corresponding to the signature.

SchemePublic key
Pure Ed25519Compressed, 32 bytes
ECDSA Secp256k1Compressed, 33 bytes
ECDSA Secp256r1Compressed, 33 bytes
multisigBCS serialized all participating public keys, size varies

签名要求​

签名必须与交易数据的意图消息的哈希相对应，你可以通过在BCS序列化交易数据之前附加3字节的意图来构造这个消息。要了解有关意图是什么以及如何构造意图消息的更多信息，请参见Sui意图签名。

在调用签名API时，必须首先对交易数据的意图消息进行哈希处理，使用Blake2b将其哈希为32字节。此外部哈希与签名API内部执行的哈希处理是不同的。为了与现有标准和硬件安全模块（HSMs）兼容，签名算法在内部执行额外的哈希处理。对于ECDSA Secp256k1和Secp256r1，必须使用SHA-2 SHA256作为内部哈希函数。对于纯Ed25519，必须使用SHA-512。

接受的ECDSA secp256k1和secp256r1签名必须遵循：

  1. ECDSA使用的内部哈希必须是SHA256 SHA-2 对交易数据的哈希。Sui使用SHA256，因为它得到了Apple、HSMs和cloud的支持，并且被Bitcoin广泛采用。
  2. 签名必须以 [r, s] 的形式，长度为64字节，其中前32字节是 r，后32字节是 s。
  3. r 的值可以介于 0x1 和 0xFFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFE BAAEDCE6 AF48A03B BFD25E8C D0364140（含）之间。
  4. s 的值必须在曲线顺序的下半部分。如果签名太高，请按照 BIP-0062 使用 order - s 将其转换为较低的 s。对于secp256k1，曲线顺序是 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFEBAAEDCE6AF48A03BBFD25E8CD0364141。对于secp256r1，曲线顺序是在 Standards for Efficient Cryptography 中定义的 0xFFFFFFFF00000000FFFFFFFFFFFFFFFFBCE6FAADA7179E84F3B9CAC2FC632551。
  5. 理想情况下，签名必须是使用确定性nonce生成的，根据RFC6979。

接受的纯Ed25519签名必须遵循：

  1. 签名必须根据RFC 8032生成。内部使用的哈希是SHA-512。
  2. 签名必须根据ZIP215有效。

在Offline Signing主题中查看使用CLI进行离线签名的具体示例。

权威签名​

Sui上的权威（验证者集合）持有三个独特的密钥对：

  1. 协议密钥对
  2. 账户密钥对
  3. 网络密钥对

协议密钥对​

协议密钥对在验证用户签署的交易时提供权威签名，如果验证通过，当提供签署用户交易的权威的股份超过所需的三分之二阈值时，Sui执行交易。Sui使用BLS12381方案对给定数量的权威的聚合签名进行快速验证。特别是，Sui使用minSig BLS模式，其中每个单独的公钥为96字节，而签名为48字节。后者很重要，因为通常验证者在每个时期的开始时注册他们的密钥一次，然后他们不断地签署交易；因此，我们在最小签名大小上进行了优化。

与BLS方案一样，你可以聚合独立的签名，从而得到单个的BLS签名负载。Sui还将聚合签名与一个位图一起发送，以表示哪些验证者进行了签署。这有效地将权威的签名大小从(2f + 1) × BLS_sig大小减少到仅一个 BLS_sig负载，从而在验证者集大小上独立压缩交易证书，从而带来了显著的网络成本优势。

为了对抗BLS12381聚合签名的潜在的恶意密钥攻击，在权威注册期间使用了秘密密钥的知识证明（KOSK）。当一个权威请求添加到验证器集时，会提交并验证所有权威都会提供的所有权证明。请参阅Intent Signing以了解如何创建所有权证明。与大多数标准不同，Sui的知识证明方案还承诺了地址，这提供了额外的保护，防止对来自另一个恶意验证器的验证者的BLS密钥的敌对重用。

账户密钥对​

权威用于接收在权益奖励上的支付的账户由账户密钥对保护。Sui使用纯Ed25519作为签名方案。

网络密钥对​

私钥用于执行QUIC所需的TLS握手，用于Narwhal主节点及其工作网络接口。公钥用于验证器对等标识。纯Ed25519用作签名方案。

在验证器工具中查看更多权威密钥工具。