在 Indy Plenum 中使用 DidSigner 时出现 DID 和 VerKey 长度不一致的问题

Question

我正在与 Indy Plenum 合作开展一个项目，在生成 DID 和验证密钥时遇到了问题。我使用以下函数从 32 字符种子生成它们：

import sys
import argparse
from plenum.common.signer_did import DidSigner

def generate_did_verkey(seed: str):
    """
    Generate DID and verification key using the provided seed.
    
    Args:
        seed (str): A 32-character long seed value.

    Returns:
        tuple: A tuple containing the DID and verification key.
    """
    if len(seed) != 32:
        raise ValueError("The seed must be exactly 32 characters long.")
    
    seed_value = seed.encode()
    signer = DidSigner(seed=seed_value)
    did = signer.identifier
    verkey = signer.verkey

    return did, verkey

即使我传递的种子正好是 32 个字符长，Indy Plenum 中的

DidSigner

类有时会给我一个 22 个字符 长的 DID（这是预期的并且有效），但其他时候它给我21 个字符的 DID，稍后当我尝试将其与 Indy 节点函数一起使用时会导致问题（由于无效 DID 而引发错误长度）。

同样，验证密钥（

verkey

）有时是23个字符（正确），但有时它会给我一个22个字符的verkey，这也会导致问题。

我不知道为什么当输入种子总是 32 个字符时，DID 和 verkey 的长度不一致。我创建了一个小脚本，使用随机种子调用

generate_did_verkey(seed)

10 次，结果如下：

---

测试结果：

root@indy-pool-4-nodes-node-1-79bf89ccd6-b7gt4:/indy_node/indy_network# python3 test_get_did_and_verkey.py 
Seed 1: 6Tzxx5GR3VOqurfEzYhPmhyYgvGgdsPx
DID: GzbU6UywWsndZhov6aLVD9 (Length: 22)
VerKey: ~2TxDRQRCPrXQHiNdSq77Mt (Length: 23)

Seed 2: Jp8WBrwxHXn5YCVL2pNKwKwrJuxoQIjI
DID: 7yMvyQ3tcCYVgsid5ky9Nq (Length: 22)
VerKey: ~QDUxbkNknGdFidzQtPG758 (Length: 23)

Seed 3: zAgaUG7vK7ZFI5J4g4yUkB0rxAXNcNSO
DID: TmGcz2c5fdSjwuhmxpuJRg (Length: 22)
VerKey: ~M8dRGxpfHPpfWPUrkchpui (Length: 23)

Seed 4: 4AG44VWxPNkufirKFJztcjzv4VlgHN6B
DID: 6f8mNreThwNJ7AJ5xsaY73 (Length: 22)
VerKey: ~7MkCDmm5hxcwNd2VnmiB7V (Length: 23)

Seed 5: h01iyHIGs7wGr1TANq5cMOMfv30pRk5C
DID: 7fNPiLQjpmnQjGJ9KyCJc7 (Length: 22)
VerKey: ~7ewe36QjzNMkFAsKVtficY (Length: 23)

Seed 6: ZG6DxtYzVqQDXuNMsUzNAL6cjnTQqwmO
DID: 3vBqosKemC4M16pwQd3BR6 (Length: 22)
VerKey: ~HJvaYU3BtWJxHucaCbG9gK (Length: 23)

Seed 7: ZafyqLLqhENdJMfBOaFsKuz8OFRKpNv1
DID: N8mXH8kXon5P5nJ5KVQK53 (Length: 22)
VerKey: ~2suZ4eyHmVJwQdPmLDvoZs (Length: 23)

Seed 8: ONCWCJvCHO6speTaJU3JkGjEP51PoisD
DID: JdhBRD8B8NqDTBqbArZZ2e (Length: 22)
VerKey: ~3J7Sp26EGGUXbKD2fCCftp (Length: 23)

Seed 9: IXQ1sHoi5w3hLdX4FRJYB3qYdPJ6Cqgw
DID: rbTbLZs69hX1zRJnzHu8Q (Length: 21)
VerKey: ~N2H55kCg8LcTEC4Jqh7dJA (Length: 23)

Seed 10: qjJkRI0iGmqkM6CTgmFwZcrRqTAoWKHQ
DID: FDmCMrGuMFphpafEQopZWz (Length: 22)
VerKey: ~7XuxKGQEDzookBv6wZksxR (Length: 23)

之前有人遇到过

DidSigner

中的

Indy Plenum

这个问题吗？我生成 DID 或使用

DidSigner

的方式有问题吗？

Answer 1

使用您的种子的 DID 生成函数将您的种子转换为 Base58 值；

• Base58 有一些边缘情况，在这些情况下它可以创建额外的字节。

• Base58 删除二进制输入中的前导零。

我遇到了同样的问题，我只是检查字符串长度并重新创建种子，然后重新运行，直到找到正确的长度（我的问题是 ACA-PY 的函数不接受不正确的长度值，您仍然可以使用DID 和 Verkey 的，如果您不使用 ACA-PY，请注意，我还没有对此进行测试。）。

当您致电时：

signer = DidSigner(seed=seed_value)
did = signer.identifier
verkey = signer.verkey

return did, verkey

首先，这被称为 signer_did.py：

 def __init__(self, identifier, verkey=None, rawVerkey=None):
    self.abbreviated = None
    if (verkey is None or verkey == '') and (rawVerkey is None or rawVerkey == ''):
        if identifier:
            self._identifier = identifier
            if (verkey is None and rawVerkey is None):
                self._verkey = None
            else:
                self._verkey = ''
            return

    if not ((verkey or rawVerkey) and not (verkey and rawVerkey)):
        raise ValueError(
            "Both verkey {} and rawVerkey {} can't be specified"
            .format(verkey, rawVerkey)
        )

    if identifier:
        self._identifier = identifier
        if rawVerkey:
            self._verkey = rawToFriendly(rawVerkey)
            self.abbreviated = False
        else:
            if verkey.startswith("~"):
                self._verkey = verkey[1:]
                self.abbreviated = True
            else:
                self._verkey = verkey
                self.abbreviated = False
    else:
        verraw = rawVerkey or friendlyToRaw(verkey)
        self._identifier = rawToFriendly(verraw[:16]) **#The issue comes from here.**
        self._verkey = rawToFriendly(verraw[16:]) **#Also might create an issue here.**
        self.abbreviated = True

从原始到友好（utils.py）

def rawToFriendly(raw):
    return base58.b58encode(raw).decode("utf-8")

我认为问题是由这个函数引起的，你遇到了一些边缘情况。