蓑衣网多重签名+瘫痪证明技术，你的比特币将神圣不可侵犯
译者前言：我们知道，在加密货币的世界里，私钥代表着资产，私钥的遗忘或被盗对任何人来说都是毁灭性的。历史上有很多人因为忘记了自己的私钥而丢失了早期的加密货币，有的人甚至损失了上亿的资产。
关于私钥安全的解决方案，一个是冷存储，一个是多重签名技术。
本文将讨论多重签名技术的应用。一般多签名技术分为两类，一类是N-of-N，即所有私钥持有者都需要签名才能使交易生效，这是黑客最头疼的问题，因为他需要同时破解所有私钥才能控制资产。常用的N/N多符号方案是2/2、3/3。
而另一类方案是N-of-M(其中N小于M)，即如果M个私钥中至少有N个私钥被签名，则交易可以生效。这种方案也是货币公司常用的，最常用的方案是3选2。
然而，与此同时，这些多重签名方案也会引入很大的风险。比如私钥丢失(某个持有人发生意外)，或者某个私钥持有人贪得无厌，威胁其他持有人，那么相关资产就会有丢失的危险。我们可以把这种资产无法使用的情况统称为瘫痪。
既要防御黑客攻击，又要防止资产无法使用，这似乎是一个悖论。
那么有解决办法吗？
来自康奈尔大学的计算机科学教授阿里尤尔斯(工作量证明机制的支持者之一)、康奈尔大学博士后伊多本托夫、康奈尔大学计算机科学博士生张帆和康奈尔大学计算机科学博士生菲尔黛安共同提出了一项名为麻痹证明的技术，使多重签名方案成为一种新的可能。
(图片来自：pexels.com)
？
从《金银岛》中埋藏的黄金宝藏，到七枚失踪的法贝热彩蛋，丢失和被盗的宝藏，一直都是一件传奇的事情。然而在比特币的世界里，没有公主，没有龙，没有海盗，这里没有太多的浪漫。财富的损失往往只是因为笔记本电脑上的私钥丢失，或者自己打印或复印的带有私钥的纸张丢失，或者被黑客洗劫一空。
密钥管理在任何加密系统中都至关重要。比特币、以太坊这样的加密货币也不例外。私钥的丢失或被盗可能是灾难性的，并且很难处理好私钥。用户需要保护自己的私钥不被狡猾的黑客窃取，同时也要妥善保护，防止资产丢失。密钥管理在商业环境中尤其具有挑战性，通常没有人会信任完全受控的资源。
一般来说，我们会使用多重签名(multisig)技术来管理加密货币的私钥。这是一个强有力的方法。简单来说就是让多个用户分别保管一个私钥，进行交易，需要几个人签名。这种密钥分发方法也称为秘密共享。
我们发表了一篇论文，解决了一般秘密共享方案存在的严重问题(特别是在加密货币领域)。我们称这个问题为瘫痪。
秘密共享如何导致瘫痪？
几个月前，一个熟人问了我们一个简单但非常有趣的问题，它也是现实世界密钥分发挑战的一个很好的例子。
这个朋友(此处别名里奇)和他的两个商业伙伴共同拥有大量比特币的所有权。他们自然不希望其中任何一个人偷偷拿走这些比特币。他们想确保这些比特币只有在所有人同意的情况下才能使用。有一个简单的解决方法，对吗？他们可以使用3 of 3多重签名方案，然后三个人都需要签名才能使用这些比特币。 问题好像解决了！但真的是这样吗？
显然，故事并没有到此结束。当然，里奇和他的伙伴们也会担心其中一个人丢失了他的私人钥匙。比如存储密钥的设备可能坏了，密钥可能被误删了，或者有人遇到了一些非常不幸的情况(比如车祸)，那么其中一个伙伴的私钥就会丢失。最后的结果就是所有的比特币全部赔光！
这不是唯一的糟糕情况。里奇和他的合伙人可能也对如何花这笔钱有不同的看法，他们无法达成协议。更糟糕的是，如果其中一个合伙人恶意或贪婪，她可能会通过扣留她的关键部分来勒索其他人(以换取资金)。在这种情况下，比特币也可能暂时或永久丢失。
这里用的“瘫痪”一词，指的是任何无法消费比特币的尴尬情况。不幸的是，N对N多重签名方案不能解决瘫痪问题。事实上，它会使问题变得更糟，因为丢失任何一把钥匙都将是致命的。
(图片：里奇和他的商业伙伴，来自hackingdistributed.com)
为此，我们需要满足里奇和它的伙伴的目标，同时避免瘫痪，也就是说，我们需要让所有人都同意花这些比特币，这似乎是不可能的！假设我们有一个N-of-N多重签名方案，要完成一个交易，显然需要所有的伙伴都同意签名。如果(N-1)个伙伴在一个伙伴的密钥丢失时可以通过某种方式获得比特币，他们可以简单地假装其中一个密钥丢失了，自己获取资金。换句话说，我们实际上开始实现-N的(N-1)的多重签名方案，这就造成了一个矛盾。
里奇的问题似乎让我们陷入了瘫痪……
解决悖论
得益于两种强大技术(区块链和可信硬件)的出现，尤其是英特尔SGX，事实证明我们其实可以解决这个悖论。我们可以在一般环境下有效地做到这一点，据我们所知，这是有史以来的第一次。为此，我们引入了一种新技术，称为防瘫痪系统
。正如你所看到的，在以太坊平台中，我们可以相对容易地实现这个防瘫痪系统，我们只需要使用一个智能合约，而不是英特尔SGX。本文提供了一个以太坊契约的例子。然而，比特币中存在脚本约束，这使得必须使用SGX设备，并且还会引入一些技术挑战。
理解防瘫痪系统
的一般原理是相当简单的。保管所有密钥的可信第三方。如果一方或多方不能或不愿意签署交易，就会导致上述的瘫痪，而另一方会出具瘫痪证明，表明是这种情况。鉴于这一证据，第三方使用其持有的密钥来授权交易。
然而，如果我们引入一个可信的第三方，显然，我们无法实现里奇和他的朋友们提出的安全目标。因为一方可以控制所有的私钥！
这就是SGX发挥作用的地方。Sg应用程序，其行为基本上类似于具有预定约束的可信第三方的行为。例如，可以对其进行编程，以便仅在提供有效证书时才能对交易进行签名。(从这个意义上说，SGX应用程序的行为与智能合约非常相似。多亏了SGX，当可验证的瘫痪发生时，我们可以确保大多数私钥持有者能够访问比特币资产。
一些技术细节
当然，即使考虑到SGX的这个魔力，我们还是需要保证麻痹证明的生成是合法的。我们不希望里奇的合伙人“指控”他，谎称他已经死了，比如对运行SGX应用的主机发起eclipse攻击。 令人高兴的是，区块链本身提供了一种强大的方式来传输消息，并让某一方知道发送者仍然活着。为了在比特币网络上实现防瘫痪系统，我们利用了这个事实和一些技巧。为了简单起见，我们将把重点放在不可访问的键的问题上，暂时把其他形式的瘫痪放在一边。
会构造一个瘫痪证书，证明某个P方没有及时响应(无法签署交易)。系统会发出挑战，“被控”方必须对我们所说的“生命迹象”做出反应。如果在预定的时间段(例如，24小时)内没有对该挑战做出反应的生命信号，则这种缺失构成麻痹的证据。
对于比特币来说，P方的生命信号可以采取数量可以忽略不计的比特币UTXO的形式(如0.00001 BTC)，可以由P方发出(从而证明她仍然存在)，也可以通过pk_SGX发出(但只能在延迟一段时间后才能发出)。请注意，只有SGX应用程序知道sk_SGX。
再以三个合伙人为例。假设他们每个人都有一个密钥对(sk_i，pk_i)。首先，他们会把自己的比特币资金(假设5000 BTC)托管到UXTO_0，一个可消费的输出。当三个人都同意，或者通过pk_SGX，就可以使用了。现在，假设p2和P3决定对P1充电。收到两个人的请求后，SGX应用会准备以下两个事务并发送给P_2和P _ 3: [X] T _ 1(事务1)创建一个0.00001 BTC的生命信号UTXO_1，pk_1可以立即使用，或者超时后(比如144块，大约24小时)可以由pk_SGX发送T_2(事务2)会花掉UTXO_0和UTXO_1，然后发送到一个可以由pk_2和
在法律指控的情况下，P1不能与t1交易，而一旦T2交易被网络确认，p2和P3将获得比特币的使用权。这确保了BTC资金的可用性。但在恶意指责的情况下，上述方案保证了蓑衣网小编2022P1可以在144块内申诉。为此，P1可以使用只有她自己知道的密钥来消费UTXO_1。因为t_2同时以UTXO_0和UTXO_1作为输入，所以t_1的代价会使t_2成为无效交易。
安全论证生命信号的安全性源于t_1中CheckSequenceVerify的使用。详细来说，t_2只有在每次输入的验证部分(比特币中称为脚本签名-ScriptSig)正确的情况下才会有效。SgEnclave X设备花托管基金产生的验证部分会立即生效，但只有在t_1交易计入比特币区块链(144块要等，因CSV条件)后，花费t_1的验证部分才会生效。因此，将超时参数设置为较大的值有两个目的：(1)给P1足够的响应时间，(2)确保攻击者无法通过制造自己的链来取代比特币区块链。以太坊平台上的应用上面提到的例子都是关于比特币的，但是防瘫痪系统实际上可以应用到比特币以外的地方。对于以太坊这样的智能合约平台，其实现会更简单，我们可以通过合约来替代对可信SGX硬件的需求。 我们给出的参考实现代码只有117行，以下是主要逻辑：function spend(uint 256 proposal _ id)public {//去掉任何paralized key holders prune _ paralized _ key holders()；require(is _ key holder(msg . sender))；require(proposal _ id
now))；//创建并插入一个瘫痪声明palisation _ claims[被告]=ParalysisClaim(现为delta，false)；NewAccusation(被告，现为delta)；//通知被控}函数respond() public { require(麻痹_claims[msg.sender])。现在到期)；麻痹_索赔[msg.sender]蓑衣网小编2022。responded=true}< 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 = 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 >完整合同代码，读者可访问：https://github.com/pdaian/paralysis_proofs查看其他应用除了加密货币应用，防瘫痪技术也可应用于证书解密。您可以使用麻痹证书来创建用于发布文件的证书，允许一个人或一组人解密它。以下是一些应用示例。这些策略可以通过区块链(审查阻力频道)和SGX的组合来实现：每日消费限额：它可以确保24小时内可以从公共池中花费的金额不会超过预先约定的金额(比如0.5 BTC，作者在原论文中讨论了一些实际限制)。事件驱动的访问控制：使用oracle，如Town Crier系统(例如，通过提供汇率数据反馈，每日消费限额可能以美元而不是BTC为单位)。人们甚至可以在原则上使用自然语言来处理响应现实世界的事件。例如，如果一份泄露信息的文件的作者被美国联邦政府起诉，那么记者可以解密该文件。升级门槛要求：如果预设的参与者数量一致，则可以在访问结构中添加和删除参与者，即改变关于授权参与者数量的规则。例如，可以将k-of-N的多重签名方案改为(k-1)-of-(N-1)的签名方案。在传统的秘密共享方案中，升级是不可能的，因为一组授权的参与者总是可以重建他们的私钥。然而，如果SGX应用程序控制解密密钥，它可以监视区块链以确定参与者是否投票升级。如果它们被记录在区块链上，投票将不会被压制。
现有的安全隐患和未来的改进工作当然，可信SGX硬件的引入也会引入(侧信道攻击)的风险，这也是本方案会遇到的主要问题。在未来的工作中，我们将探索减轻这种攻击的技术。例如，在允许N-of-N多重符号的方案中，它可以降级为(N？1)n个中的系统多重签名方案使得SGX飞地应用能够存储和有条件地释放单个私钥，而不是控制主私钥。这将限制侧信道攻击造成的危害。我们还可以在多个SGX enclave设备中存储密钥，这有助于降低节点故障的风险，同时有助于恢复节点故障。这是另一个需要研究的工作。附录在本文中，我们讨论了许多有趣的扩展，这里列出了两点：圣约人提出的麻痹证明如上所述，由于比特币的脚本约束，需要SGX设备在这个网络上应用麻痹证明。事实上，我们还提出了一种“效率略低”的方法，这种方法不需要可信硬件，需要一种叫做契约的方法。（契约）的提议比特币功能。然而，使用这种方法的复杂性，明显会高于SGX可信硬件方法（无论是概念还是链上复杂性方面），因此我们并不推荐。另一种更好的方案在前面提到的例子当中，资金可以由pk_SGX单独使用，但重要的是，这不是唯一的选择。事实上，人们可以在安全性和瘫痪容忍度之间进行权衡，以最好地满足他们的需求。例如，如果三位合伙人只希望容忍最多一个缺失的私钥，他们可以做的，是把资金转移到一个3-of-4 的多签地址当中，其中第四个参与者就是SGX飞地设备。如果所有人都活着，那么他们可以在不需要SGX的情况下使用比特币资金。如果其中有一位合伙人出现了意外，他无法进行签名，如果剩下的两名合伙人能够展示瘫痪证明，则SGX飞地设备将释放出它的私钥。因此，即使攻击者通过侧信道攻击攻破了SGX设备持有的私钥，他也无法花费这些比特币资金，而唯一例外情况，就是两位合伙人是和攻击者串通好的。这也是我们打算进一步研究的一个有趣方向。注：更多数学论证内容，读者可访问原论文：https://www.initc3.org/files/pp.pdf