对于我在这个帖子中提到的项目，我正在构建一个节点网络，这些节点将通过gRPC相互通信。我将使用SSL/TLS（实际上是mTLS）不仅用于加密，更重要的是用于身份验证，以便每个节点确切地知道它正在与哪个节点通信，或者更确切地说，知道对等方的公钥/钱包地址。当然，一个完全去中心化的项目不能有任何中心化组件，因此不会涉及任何认证机构，所有SSL证书都将是自签名的。
现在，问题来了。原则上，自签名证书证明了私钥的所有权，所以我可以简单地对钱包和自签名证书使用相同的密钥对，这样对等方就能确切地知道它正在与哪个钱包通信，即使证书是自签名的。然而，我几乎肯定会在我的钱包中使用Pallas曲线上的Schnorr签名方案（欢迎询问原因），但不幸的是，SSL不支持。
可能的解决方案
正如你在同一个帖子中看到的，我最近开始学习椭圆曲线密码学和Schnorr方案。我了解到密钥推导独立于签名方案，它只取决于特定的曲线。所以这给了我一个想法：我能否对钱包和自签名证书使用相同的私钥标量，然后以某种方式证明两个生成的公钥（证书的Ed25519公钥和钱包的Pallas公钥）是相关的，并共享相同的私钥？
看起来我可以接近这一点。我将不得不实现相当多的自定义密码学，这可能存在风险，但我认为仍然值得追求。
除了通常的字段外，我的mTLS证书还将包含：
- 节点钱包的公共Pallas密钥，
- 零知识证明，以说服对等方Ed25519公钥和Pallas公钥是相关的，而不泄露私钥。
后者基本上是在两条曲线（25519和Pallas）上计算的"双重"Schnorr风格签名。如果签名在两条曲线和两个公钥上都通过验证，则对等方会信服。
需要注意的一个方面是，私钥标量必须在两条曲线的域中有效，因此必须严格小于min(n_{25519}, n_{Pallas})min(n25519,nPallas)，其中n_CnC是曲线CC的标量域阶（不要与基础域阶混淆）。这似乎不是问题，因为两条曲线的标量域阶都在2^{25something}225something附近（2^{252}2252用于25519，2^{255}2255用于Pallas，看起来是这样）。
