这是比特币领域自学成才的教育家和面向技术的比特币播客主持人 Shinobi 的评论社论。
我建议，在阅读本文之前，您先阅读 我写的前一篇文章解释了 Nostr 是什么以及它如何在高层次上工作. 那时您应该对系统的核心设计有一个很好的了解，所以现在让我们来看看随着采用率的增长可能会出现的问题。 随着平台 成为比特币社区的热门人选，这些问题是需要注意的。
正如我在之前的文章中讨论的那样，用户公钥/私钥对是 Nostr 作为协议工作方式不可或缺的一部分。 没有用户名或中继服务器控制的任何类型的标识符与个人用户相关联。 只是那些用户的密钥完全在他们的控制之下。
这起到了实际用户与其他人如何识别他们之间的紧密绑定的作用，以防止任何中继服务器解除这两件事的绑定，即，将某人的标识符提供给另一个用户。 这解决了用于人与人之间交流的平台最大的基本问题之一：缺乏对用户自身身份的控制。 但它也引入了拥有私钥的人遇到的所有密钥管理问题。 密钥可能会丢失，密钥可能会受到损害，如果发生此类事件，用户将无法寻求帮助，就像比特币一样。 没有客户支持来恢复任何东西。 你输了，就是这样。
这将不可避免地需要一种方案，让用户以一种可验证和可发现的方式从一个密钥对轮换到另一个密钥对，这些用户通过协议与之交互。 整个协议基于证明事件来自特定用户（身份密钥），因此一旦某人的密钥被泄露，所有这些保证都会失效。
你怎么处理的？ 只是去查看他们的 Twitter 帐户？ 好吧，那不是一个非常去中心化的系统，最终，如果你需要使用一个中心化的平台，在这个平台上，他们无法控制他们的身份来验证他们的 Nostr 身份。
其他用户是否证明了新密钥的合法性？ 这并没有解决诸如大量密钥泄露或不了解与他们亲近的人足以相信他们的证明等情况。
Nostr 需要一个实际的密码方案，将一个密钥的轮换与另一个密钥联系起来。 有一个 开发商 fiatjaf 的提议 对于可能解决此问题的基本方案。 基本思想是采用从单个主种子派生的一长串地址，并创建一组“调整后的”密钥，类似于 Taproot 树如何提交给比特币密钥。 Taproot 获取 Taproot 树的 Merkle 树根并将其“添加”到公钥以创建新的公钥。 这可以通过将该 Merkle 树根添加到私钥来复制，以获得与新公钥匹配的私钥。 Fiatjaf 的想法是将承诺从末尾向后链接到开始，这样每个经过调整的密钥实际上都会包含下一个经过调整的密钥用于创建它的证明。
所以，想象一下从键 Z 开始，链中的最后一个。 你可以用一些东西来调整它，然后返回并使用调整后的 Z 键 (Z’ + Y = Y’) 创建键 Y 的调整版本。 从这里您可以获取 Y’，然后用它来调整 X (Y’ + X = X’)。 你会一直这样做回到密钥 A，得到 A’，然后从那里开始使用该密钥。 当它被破坏时，用户可以广播一个包含未调整密钥 A 和调整密钥 B’ 的事件。 这将包含显示 B’ 用于生成 A’ 所需的所有数据，并且用户可以立即停止关注 A’ 并转而关注 B’。 他们会明确地知道 B’ 是该用户的下一个密钥，并改为遵循该密钥。
不过，这个提议仍然存在一些问题。 首先，您必须提前生成您将要使用的所有密钥，并且无法轮换到一组全新的密钥。 这可以通过在这个方案中提交一个可以公证这种轮换的主密钥来解决，或者简单地从一开始就生成一组非常大的密钥。 任何一条路径都是可行的，但最终需要保持根密钥或密钥材料的安全，并且只向 Nostr 客户端公开单个热键。
然而，该方案不会保护用户或提供在根密钥材料丢失或本身受到损害的情况下进行身份恢复的机制。 现在，这并不是说 fiatjaf 的方案没有好处，绝对有好处，但重要的是要指出没有解决方案可以解决所有问题。
为了在这里对潜在的解决方案进行一些讨论，想象一下，而不是像他建议的那样，将一个密钥调整为一个主冷密钥，该主冷密钥还必须用于签署从一个密钥到另一个密钥的事件轮换。 您有密钥 A’，它是通过添加 A 和 M（主密钥）派生的，轮换事件将是 A、M 和 B’（通过添加 B 和 M 生成）以及 M 的签名。M 可以是多重签名阈值密钥——三分之二、五分之三等。这可能会增加冗余以防丢失，并为密钥轮换提供安全机制。 这也打开了使用服务来帮助恢复或将其中一些密钥传播给可信赖的朋友的大门。 它提供了与比特币本身的多重签名相同的灵活性。
NIP26 也是一个可能对处理这个问题非常有用的建议。 这指定了事件的协议扩展，允许来自一个密钥的签名授权另一个密钥代表它发布事件。 然后，“令牌”或委托的签名证明将包含在第二个公钥代表第一个公钥发布的所有事件中。 它甚至可以是有时间限制的，因此委托令牌会自动过期并且必须更新。
最终，不管怎样解决，这个问题 拥有 从长远来看，要为 Nostr 解决。 如果不能为用户保护和维护这些身份的完整性，则完全基于用作身份的公钥/私钥对的协议将无法获得牵引力和采用。 这最终将归结为必须不断使用带外和集中式平台来验证新密钥，并在某些东西丢失或受到损害时协调人们跟随你的新身份，而在这一点上，那些其他平台成为散播混乱的一种手段并进行审查。
密钥管理和安全问题是一个非常大的问题，具有非常大的设计空间，充满权衡和痛点，但这些问题必须在 Nostr 的上下文中解决才能发挥作用。 在我的下一篇文章中，我将总结一些我认为在中继服务器架构和扩展问题方面突然出现的问题，考虑到 Nostr 所基于的基本数据结构，Nostr 开发人员将不得不面对这些问题。
对于任何阅读并想知道为什么我没有提到去中心化标识符 (DID) 的人：是的，这是对这些问题的潜在解决方案，在我看来，它是非常全面的。 然而，Nostr 开发人员似乎非常犹豫是否将 DID 集成到协议或客户端中，因为它会在 Nostr 协议之外创建外部依赖关系。 如果您不熟悉 DID 在技术层面上的工作原理并且感兴趣， 这篇文章来自 39 级 是对它们如何工作的很好的书面总结。
这是 Shinobi 的客座帖子。 表达的观点完全是他们自己的，不一定反映 BTC Inc 或比特币杂志的观点。
