我們知道，在密碼貨幣世界，私鑰就代表著資產，而私鑰的遺忘或者遭竊，對于任何人來說都是毀滅性的，歷史上有很多人因為遺忘了私鑰而丟失了自己早期投資的密碼貨幣，有的甚至因此而痛失了價值數億的資產。

而關于私鑰安全的解決方案，一種是冷存儲，另一種則是多重簽名技術。

本文則要探討多重簽名技術的應用。一般多簽技術分為兩類，一類是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設備持有的私鑰，他也無法花費這些比特幣資金，而唯一例外情況，就是兩位合伙人是和攻擊者串通好的。