多重签名技术很好的解决了因私钥丢失而导致数字资产丢失的问题

我们知道，在密码货币世界，私钥就代表着资产，而私钥的遗忘或者遭窃，对于任何人来说都是毁灭性的，历史上有很多人因为遗忘了私钥而丢失了自己早期投资的密码货币，有的甚至因此而痛失了价值数亿的资产。

而关于私钥安全的解决方案，一种是冷存储，另一种则是多重签名技术。

本文则要探讨多重签名技术的应用。一般多签技术分为两类，一类是N-of-N，即需要所有私钥持有者进行签名才能使交易生效，这是令黑客最头疼的，因为他需要同时攻破所有人的私钥才能够控制资产。而常用的N-of-N多签方案有2-of-2，3-of-3。

而另一类方案则是N-of-M （其中N小于M），即M个私钥当中，至少有N个私钥进行签名，则交易可生效。这种方案也是币圈公司常用的一类方案，最为常用的方案有2-of-3。

然而，这些多签方案同时这也会引入很大的风险，例如其中某个私钥丢失（某个持有者发生意外），或者某个私钥持有者心生贪念而向其他持有者发出威胁时，那么相关资产就会处于丢失危险，我们可以把这类无法动用资产的情况统一称为瘫痪。

而既要很好地防御黑客的攻击，又要预防无法动用资产的情况，这似乎成为了一个悖论。

那到底有没有解决办法呢？

来自康奈尔大学的计算机科学教授Ari Juels（工作量证明机制提出者之一），康奈尔大学博士后Iddo Bentov， 康奈尔大学计算机科学博士生Fan Zhang，康奈尔大学计算机科学博士生Phil Daian共同提出了一种称为瘫痪证明（Paralysis Proofs）的技术，这使得多重签名方案又有了新的可能。

以下为整合译文（注：其中的“我们”，指康奈尔大学的研究者）：

从埋藏于“金银岛”的黄金宝藏，到七枚失踪的法贝热彩蛋，丢失和被盗的宝藏，一直是传说中的事情。然而，在比特币的世界，这里没有公主、恶龙或者海盗，这里也没有太多的浪漫。财富的丢失，往往只是因为笔记本电脑上的私钥遗失了，或者弄丢了自己打印或抄写的带有私钥的纸条，又或者是遭到了黑客的洗劫。

密钥管理在任何密码系统中都是至关重要的。像比特币和以太坊这样的密码货币也不例外。私钥的丢失或被盗，可能是灾难性的，而要很好地处理私钥也是一件非常困难的事情。用户需要保护他们的私钥，以免受狡猾黑客的窃取，同时又要妥善地保护它们以防资产丢失。密钥管理在商业情景下尤其具有挑战性，通常没有人会信任完全被控制的资源。

一般而言，我们会使用多重签名（multisig）技术来管理密码货币的私钥，这是一种强大的方法，简单说就是让多个用户分别保管一个私钥，而要进行交易，就需要其中几个私钥进行签名。这种密钥分发的方式，也被称为秘密共享。

我们则发布了一篇论文，解决了一般秘密共享方案（尤其在密码货币领域）存在的严重问题。我们将这个问题称为瘫痪问题。

秘密分享如何导致瘫痪问题的发生？

几个月前，一位熟人向我们提出了一个简单，但非常有趣的问题，而它也是现实世界密钥分发挑战的一个很好的例子。

这位朋友（这里化名为Richie）和他的两位商业伙伴共享了大量比特币的所有权。而他们自然不希望当中有任何一个人能够把这些比特币偷偷拿走。他们希望确保这些比特币只有在所有人的同意下才能够使用。有一个简单的解决方案，对吧？他们可以使用3 of 3的多重签名方案，然后三个人都需要签名才能够使用这些比特币。问题似乎解决了！但真的是这样吗？

很显然，故事到这里并没有结束。当然，Richie和他的合作伙伴也会担心其中有人把私钥给弄丢的情况。例如存储密钥的设备可能会坏掉，密钥也有可能被错误删除，或者有人遭遇了一些非常不幸的情况（例如车祸），那么其中一名合伙人的私钥就会丢失。则最终的结果是所有的比特币就完全丢失了！

这并不是唯一糟糕的场景，Richie和他的合作伙伴也可能对如何花这些钱有着不同的看法，而且也无法达成协议。更糟糕的是，假设其中有一位合伙人是恶意或贪婪的，她可能通过扣留她的密钥部分，来勒索其他人（换取资金）。在这种情况下，比特币也可能会暂时或永久性地丢失。

这里使用了“瘫痪”这个术语，以表示任何不能花费比特币的尴尬情况。不幸的是，N-of-N的多重签名方案无法解决瘫痪问题。事实上，它会使问题变得更糟，因为丢失任何一个密钥都会是致命的。

出于这个原因，我们需要在满足Richie及其合作伙伴目标的同时，也要避免掉瘫痪的情况，即需要让所有人都同意花费这些比特币，这似乎是不可能的！假设我们有一个N-of-N 的多重签名方案，而要完成一笔交易，我们显然需要让所有合伙人同意签署才可以做到。如果（N-1）位合伙人可以在某位合伙人的密钥丢失的情况下，以某种方式获得对比特币的访问权限，他们可简单地假装其中一份密钥已经丢失，并自行获取资金。换句话说，我们实际上一开始实施的就是（N-1）of-N的多重签名方案，这就产生了矛盾。

Richie的问题，似乎让我们处在了瘫痪的状态。..。..

解决悖论

由于两种强大技术的出现（区块链和可信硬件），特别是英特尔SGX，事实证明我们实际上是可以解决这种悖论的。我们可以有效地在一般环境中做到这一点，据我们所知，这是有史以来第一次。为此，我们引入了一种称为瘫痪证明（Paralysis Proof）系统的新技术

正如你会看到的，在以太坊平台当中，我们可以相对容易地实施这种瘫痪证明系统，我们只需要用到一个智能合约，而不需要英特尔SGX。我们在论文中提供了以太坊合约的例子。然而，比特币中存在的脚本约束，这使得它需要用到SGX设备，并且还会引入一些技术挑战。

简单了解瘫痪证明系统

总体原理是相当简单的。受信任的第三方，将所有的密钥都保存在托管处。如果一方或多方不能或不愿签署交易，则会导致上述的瘫痪情况，其他人则产生一个瘫痪证明，表明情况就是这样的。鉴于此证明，第三方使用其持有的密钥来授权交易。

但是，如果我们引入了一个可信的第三方，显然，我们没法实现Richie和他的朋友们提出的安全目标。因为有一方可以控制所有的私钥！

而这就是SGX发挥作用的地方了。SGX应用，其行为基本类似于具有预定约束的可信第三方。例如，它可被编程，以便只有在提供有效证明时才能够签署交易。（从这个意义上讲，SGX应用的行为与智能合约非常相似。）感谢SGX，我们可以确保在可证实的瘫痪情况发生时，让多数私钥持有者能够访问到比特币资产。

一些技术细节

当然，即使考虑到SGX的这种魔力，我们仍然需要确保瘫痪证明（Paralysis Proof）的生成是合法的。我们不希望Richie的合作伙伴能够“指控”他，错误地声称他已经死亡，比如说对运行SGX应用的主机发起日食攻击（ eclipse attack）。令人高兴的是，区块链本身提供了一种强有力的方式来传输消息，并让某方知道传输者还活着。为了在比特币网络上实施瘫痪证明系统，我们利用了这个事实以及一些技巧。为了简单起见，我们将重点关注无法访问的密钥的问题，而暂时搁置其他形式的瘫痪情况。

一个瘫痪证明会被构建，证明某P方不及时响应（无法签署交易）。该系统会发出一个挑战（challenge），“被控”方必须对我们所谓的“生命信号”作出回应。如果在一段预定的时间内（例如24小时）没有生命信号响应这一挑战，则这种缺席便构成了瘫痪证明。

而对于比特币而言，P方的生命信号，可以采用可忽略不计数量（例如0.00001 BTC）的比特币UTXO形式，它可以是由P方发出（从而证明她还存在），或者通过pk_SGX发出（但需要等延迟过后才可以进行）。请注意，sk_SGX仅是被SGX应用所知的。

让我们再拿三个合伙人作为例子。假设他们每个人都拥有一个密钥对 （sk_i， pk_i）。首先，他们会托管自己的比特币资金（假设有5000 BTC）到UXTO_0这个可花费的输出，当三人都同意的情况，或者通过pk_SGX，就可以对其进行使用。现在，假设P_2和P_3决定指控P_1。SGX应用在收到两人的请求之后，会准备以下两笔交易，并将其发送给P_2 和 P_3：

· t_1（交易1）创建了0.00001 BTC 的生命信号UTXO_1 ，对此pk_1可以立即使用它，或者在超时后（例如144个区块，约24小时）可由pk_SGX使用；

· t_2 （交易2）会花费UTXO_0以及生命信号UTXO_1，然后将它们发送到一个可由pk_2和pk_3控制的地址（或者，如果他们想要留在瘫痪证明系统当中，pk_SGX也是可选的）。

因此，指控P_1的合伙人应该向比特币网络广播t_1，等待t_1被添加到区块链后，再等待接下来的144个区块，然后将t_2广播到比特币网络。而在这期间，会出现两种可能的结果：

· 在合法指控的情况下，P_1确实是无法使用t_1交易的，而一旦t_2交易被网络确认，则P_2和P_3将获得比特币的访问权。这确保了BTC基金的可用性。

· 然而，在发生恶意指控的情况下，上述方案确保P_1在144个区块时间内可提出上诉。为此，P_1可使用那个仅为她所知的密钥，来花费UTXO_1。由于t_2将UTXO_0和UTXO_1都作为输入，因此花费t_1，会使得t_2成为一笔无效交易。

安全论证

生命信号的安全性，源于在t_1中使用了CheckSequenceVerify。详细地讲，只有当每个输入的验证部分（比特币当中被称为脚本签名-ScriptSig）都是正确的时候，t_2才会有效。SGX飞地设备为花费托管基金而而生产的验证部分会立即生效，但只有在t_1交易被纳入比特币区块链之后（需等待144个区块，由于CSV条件），花费t_1的验证部分才会有效。因此，将超时参数设置为较大值有两个目的：（1）给予P1足够的响应时间，以及（2）确保攻击者无法通过制造自己的链取代比特币区块链。

在以太坊平台上的应用

以上提到的都是关于比特币的例子，但瘫痪证明系统其实不仅仅可以应用于比特币，对于像以太坊这样的智能合约平台，其实现会更为简单，我们可通过合约替换掉对可信SGX硬件的需求。

我们给出的参考实现代码只有117行，以下为其中的主要逻辑：

funcTIon spend（uint256 proposal_id） public {

// Get rid of any paralyzed keyholders

prune_paralyzed_keyholders（）;

require（is_keyholder（msg.sender））;

require（proposal_id 《 proposals.length）;

// add sender‘s signature to approval

proposal_sigs［proposal_id］［msg.sender］ = true;

// if enough proposers approved， send money

uint num_signatures = 0;

for （uint256 i = 0; i 《 keyholders.length; i++） { if （！paralyzed［keyholders［i］］） { if （proposal_sigs［proposal_id］［keyholders［i］］） { num_signatures++; } } } if （（num_signatures） 》= required_sigs） {

if （！proposals［proposal_id］.filled） {

proposals［proposal_id］.filled = true;

proposals［proposal_id］.to.transfer（proposals［proposal_id］.amount）;

}

}

}

funcTIon remove（address accused） public {

// Get rid of any paralyzed keyholders （prevent paralyzed requester）

prune_paralyzed_keyholders（）;

// both requester and accused must be keyholders

require（is_keyholder（msg.sender））;

require（is_keyholder（accused））;

// There shouldn’t be any outstanding claims against accused

require（！（paralysis_claims［accused］.expiry 》 now））;

// Create and insert an Paralysis Claim

paralysis_claims［accused］ = ParalysisClaim（now+delta， false）;

NewAccusaTIon（accused， now + delta）; // NoTIfy the accused

}

function respond（） public {

require（paralysis_claims［msg.sender］.expiry 》 now）;

paralysis_claims［msg.sender］.responded = true;

}

完整的合约代码，读者可访问：https://github.com/pdaian/paralysis_proofs 查看

其它的应用

而除了密码货币应用，瘫痪证明技术还可以应用于凭证解密。你可以使用瘫痪证明来创建一个用于释放文件的证明，允许一个人或一组人对其进行解密。以下是一些应用示例，这些策略可以通过区块链（审查阻力通道）和SGX的组合来实现：

· 每日支出限额：可确保在24小时内，从一个公共池中能够花费的资金，不会超过一个预先商定的金额（比如说0.5 BTC，作者们在原论文中讨论了一些实际限制）

· 事件驱动的访问控制：使用一个oracle，例如Town Crier系统（实际上是第一个面向公众的SGX应用），这可以在现实世界的事件中对访问控制策略进行条件化。例如，通过提供汇率数据反馈，每日支出限额可能以美元而非BTC计价。人们甚至可原则上使用自然语言处理响应现实世界的事件。例如，如果因为一份具有泄露信息的文件，其作者被美国联邦政府起诉，那么某个记者就可以对这份文件进行解密。

· 升级阈值要求：如果预先设定数量的参与者同意，就可以在访问结构中添加和删除参与者，即更改关于授权参与者数量的规则。例如，可以把k-of-N的多重签名方案更改为（k+1）-of-（N+1）的签名方案。在常规的秘密共享方案当中，这是不可能进行升级的，因为一组授权参与者总是可以重建他们持有的私钥。但是，如果SGX应用控制了解密密钥，它就可以监视区块链，以确定参与者是否已投票进行升级，如果它们被记录到了区块链上，则投票不会受到抑制。

存在的安全隐患以及未来的改进工作

当然，在引入可信SGX硬件的同时，也会引入侧信道攻击（（side channel attack）的风险，这也是这个方案主要会遇到的问题。而在未来的工作当中，我们将探索减轻这种攻击的技术。例如，在一个允许N-of-N多签方案可被降级为 （N − 1）-of-N多签方案的系统，有可能让一个SGX飞地应用存储和有条件地释放单个私钥，而不是控制一个主私钥。这将限制侧信道攻击带来的危害。我们也可以在多个SGX飞地设备存储密钥，这有助于减轻节点的失效风险，同时也有助于恢复节点故障，这是另一个需要去研究的工作。

附录

在论文当中，我们讨论了很多有趣的扩展部分内容，以下是其中列出的两点：

利用契约（covenants）提议的瘫痪证明

如上所述，由于比特币存在脚本约束，想要在该网络上应用瘫痪证明，就需要使用SGX设备。实际上，我们还提出了一种不需要用到可信硬件，但“效率稍低”的方法，这就需要用到一种称为covenants（契约）的提议比特币功能。然而，使用这种方法的复杂性，明显会高于SGX可信硬件方法（无论是概念还是链上复杂性方面），因此我们并不推荐。

另一种更好的方案

在前面提到的例子当中，资金可以由pk_SGX单独使用，但重要的是，这不是唯一的选择。事实上，人们可以在安全性和瘫痪容忍度之间进行权衡，以最好地满足他们的需求。

例如，如果三位合伙人只希望容忍最多一个缺失的私钥，他们可以做的，是把资金转移到一个3-of-4 的多签地址当中，其中第四个参与者就是SGX飞地设备。如果所有人都活着，那么他们可以在不需要SGX的情况下使用比特币资金。如果其中有一位合伙人出现了意外，他无法进行签名，如果剩下的两名合伙人能够展示瘫痪证明，则SGX飞地设备将释放出它的私钥。因此，即使攻击者通过侧信道攻击攻破了SGX设备持有的私钥，他也无法花费这些比特币资金，而唯一例外情况，就是两位合伙人是和攻击者串通好的。