BLS算法在加密货币上的应用：秘钥共享与阈值签名

将BLS应用于加密货币

 

BLS最明显的用途是加密货币中m-n的多重交易，比如比特币。用户可以向他的钱包询问m-of-n地址，然后获得单个地址和密钥共享列表。之后，它会把“密钥分享”分配到不同的地方(电脑或硬件钱包)。钱包不会存储这些“密钥共享”，否则所有这些都将毫无意义。

生成的地址在内部只是原始密钥的公钥（并不再为人所知）。此外，该地址与普通的1-1BLS地址没有任何区别，这意味着任何人都不可能知道这实际上是一个m-n多重签名，也不知道涉及多少密钥或需要多少共享才能恢复密钥。

如此一来，对于m-n多重交易就不需要特殊的处理，因为在内部，验证一个简单的签名交易需要完全相同的验证（例如CHECKBLSSIG）。

目前，基于ECDSA的m-n预算需要有m个公钥和m个签名作为交易的一部分，这很容易导致在链上产生几个kB，从进而损坏其延展性。

此外，ECDSA还泄露了用于签署交易的密钥的相关信息。但如果使用基于BLS的阈值签名，预算的大小是固定的(例如32字节)，其独立于值m和n，也没有任何隐私泄漏。

 

使其分布式且去信任化（免信任）

 

 

上述方案本身已经很好了，但它有一个缺点，只有当创造者（交易商）是秘密共享的接收者的时候，它才会生效。因此，只有当你想要分发自己的密钥以避免安全问题时，它才会很好地工作。

如果涉及多方当事人需要签署交易的时候，则该方案存在问题。这需要对单一交易商的绝对信任。如果交易商不值得信任或妥协，原始密钥则可能被滥用或泄露。

幸运的是，由于BLS的特性，这个问题会很容易被修复。

我们可以让每个参与者都成为一个交易商，然后把多方的结果汇总起来，这样密钥就可以在没有任何人知道的情况下达成一致。

当然，它需要每方参与者进行一次验证，以确保其他各方都是诚实的。如果遇到不诚实的一方，整个过程必须中止。

这个过程需要对Shamir的秘密共享进行补充，所以我们首先要更详细地解释Shamir的秘密共享，然后讨论我们需要执行的添加选项。这些添加需要交换一些加密数据，因此每一方必须做的第一件事就是声明一个BLS公钥。

在Shamir的秘密共享中，创建了一个度数为n-1次的多项式S(x)。该多项式的第一个值(自由系数)是原始密钥，其余的n-1个系数是随机生成的密钥。多项式内部可以表示为一个简单的密钥向量。多项式中的参数“x”是一个唯一编号，用来标识参与的各方。

例如，它可以是每个参与方基于1的索引，但也可以是任何其他的公知值（例如公钥或哈希值）。为每一方计算这个多项式给出了每一方的密钥共享。

如果任何人知道这些秘密共享的“m”，则可以使用多项式插值来恢复原始密钥，这就是Shamir秘密分享的基础。

如果我们创建一个相同度数的新多项式P(x)，并将所有系数设置为第一个多项式中使用密钥的公钥，我们就可以使用这个新多项式生成与密钥共享对应的公钥共享。

这是由于BLS原语的属性，其中对两个对应的BLS原语（例如秘密和公钥）执行相同的操作将生成一个相应BLS原语的新元组。

这个多项式可以公开共享，并且不会泄露任何关于密钥的信息。它可以用来验证接收到的密钥共享实际上是在不知道多项式的情况下对多项式S(x)求值的结果。这只需要用P(x)计算公钥共享，并将结果与从接收的密钥共享所计算的公钥进行比较即可。

现在，为了使其分布式且去信任化，我们让每一方都创建自己的多项式S(x)和P(x)。然后每一方都公布P(x)以便让所有方都清楚存在的P(x)。

然后，每一方都将为另一方计算S(x)，并使用之前公布的公钥加密结果(密钥共享)。随后，每一方将加密的秘密共享发送给相应的其他方。在进行所有这些操作时，每一方还必须为自己执行的S(x)进行评估。

在此之后，每一方都应该接收到精确的“n”加密密钥共享，这意味着每一方都应该从另一方接收到一个密钥共享。如果缺少任何密钥共享或多项式P(x)，则整个过程中止。

当各方收到加密的秘密共享时，他们将首先解密并验证这些共享。验证是通过计算P(x)来执行的，其中x是自己的标识符（参与方列表中的索引）。如果计算的结果(公钥共享)与所接收密钥共享的计算公钥不匹配，则整个过程中止。

在这个阶段，每一方都应该有“n”个多项式P(x)和“n”个经过验证的秘密共享。记住，秘密共享使用的多项式S(x)的自由系数（第一个值）与原始密钥相同。这又意味着P(x)的自由系数是原密钥的对应公钥。

现在我们将所有多项式P(x)聚合成一个最终多项式FP(x)。由于BLS原语的属性，FP(x)的自由系数与最终密钥的公钥匹配。

然而，最终密钥是未知的，因为所有各方只知道各自的多项式S(x)，因此没有人能够聚合系数。FP(x)的自由系数（第一个值）是最后一个m-n公钥，并在随后用作支付地址。

我们还将所有接收到的密钥共享聚合为最终密钥共享。同样，由于BLS原语属性，最终得到的密钥共享与FS(x)的多项式求值结果相匹配。然而，FS(x)也是未知的，因为它还需要聚合所有单方多项式S(x)。

由于各个参与方可能已经决定在此阶段中止进程，所以在考虑使用m-n公钥进行任何支付之前，所有参与方必须首先宣布进程成功，这一点很重要。否则，即使某些其他方稍后无法提供签名共享，也可能会欺骗单方使用公钥。

因此，为了表示成功（协议），各方必须发布某种协议消息，并使用之前公布的公钥的密钥（不是密钥共享，而是最开始的那个）进行签署。

此外，协议消息必须包含本地聚合的m-n公钥，以便其他各方可以验证其与聚合的公钥相同。只有当一方遵守所有“n”所期望的协议时，它才会被认为m-n公钥是一个好的公钥。

从现在开始，我们将回到简单的Shamir秘密共享计划。每一方都有自己的密钥共享，并且能够创建签名共享。如果收集m-n签名共享，则可以使用多项式插值来恢复最终的签名。

这个签名还是普通的BLS签名，它针对m-n公钥进行验证，m-n公钥是FP(x)的自由系数。正如你可能猜到的那也，不需要对这些m-n地址和签名进行特殊处理，一个通用的CHECKBLSSIG就足够了。

整个过程听起来可能涉及很多交互性和沟通。然而，这可以简化为需要交换的几个消息。

每一方都可以将P(x)和所有单独加密的密钥共享打包成一条消息，从而将所需的通信减少到每一方3条消息，即公钥公告、共享分配和协议。

然而，这将允许观察者查看哪一个公钥已经达成一致（密钥仍然不为任何人所知）。

如果需要更多隐私，则每一方都应将每个P(x)和秘密共享单独加密发送给所有其他成员。

为了使其更加可用，可以使用中央服务（其中存在多个服务，可以选择一个）作为代理/调度程序，同时仍然保留单独的加密。

不管解决方案是什么，它都可以集成到钱包中，这样就可以隐藏所有的内部结构。最后，每一方只需选择其他方，并点击“生成m-n地址”即可。

 

更加去中心化和自动化

 

前面描述的过程可以完全去中心化和自动化。这涉及到一个多阶段的网络协议，该协议能够处理和容忍进程中的故障。容忍失败（故障）意味着协议能够从分布式密钥生成中踢出各个参与方，而不是中止整个过程。

 

BLS的表现

 

此前Stepan在其文中提到过，BLS 签名验证的复杂度要比 ECDSA 高上一个数量级。 在验证区块中 1000 笔交易的聚合签名时，仍需要进行 1000 次配对计算，这可能比使用 ECDSA 时（对 1000 个单独签名进行验证）还要慢。唯一的好处在于，可以在区块中放更多笔的交易，毕竟聚合签名只占 32 字节。

与 BLS 不同，Schnorr 验证算法的效率很高，它可以把签名放一起验证，效率是 ECDSA 算法的三倍。这样，问题来了，效率和安全哪个对我们更重要？

实际上，BLS 签名算法已经足够出色。它能将区块中的签名聚合成单一签名；能进行密钥聚合和 m-n多重签名（无需额外通信）；能避免使用随机数生成器。

这些优点使BLS显得如此简单优雅。当然，它仍有改进空间，标准化和优化也尚需时日。但我希望有朝一日，它能变得足够好，可以被纳入比特币协议中。这样的话，我们不但能获得它出色的功能，还可享受体积更小、聚合度更强的签名算法带来的好处。