Safeheron合夥人回應Vitalik評MPC:MPC與智能約錢包並非競爭關係
原文作者:Kane Wang, Safeheron 合夥人& 技術VP

近期,以太坊創始人Vitalik 表達對MPC 錢包和智能合約錢包優缺點的觀點,如下圖:

Vitalik 認為基於MPC 的EOA 錢包存在根本的缺陷,因為無法撤銷密鑰,即使重新分片(re-sharing)也無法解決這個問題,重新分片之後老的分片持有者依然可以恢復私鑰,因此智能合約錢包是唯一的選擇。
這也引得社區對MPC 錢包和智能合約錢包再次激烈討論。截止發文前,一些朋友也已詢問我對於Vitalik 的MPC 負面評價的看法。個人而言,這個問題的討論最終演變成了立場討論,不統一應用場景和業務場景前提的討論都沒有對錯之分。
與其走向劍拔弩張,不如先理清此次爭論點:Vitalik 指出的revoke keys 究竟是什麼,適用於什麼場景?MPC 錢包的私鑰分片管理機制與智能合約錢包的私鑰管理機制又有何不同呢?
(1)何為撤銷私鑰(revoke keys)操作

舉個例子,在使用智能合約錢包時,假設錢包地址為Address 1 ,用戶A 使用私鑰SK_A,用戶B 使用SK_B 管理該智能合約錢包,使用錢包轉賬時需要用戶A 和用戶B 同時授權。
如果用戶想要更換錢包的管理權限,比如原本是用戶A、B 管理該錢包,現在想要保持錢包地址不變的前提下,更換為用戶C、D 管理該錢包,並且撤銷用戶A 和B 的管理權限。通過智能合約可以實現撤銷用戶A 和B 對應私鑰SK_A、SK_B 對錢包的管理權限,修改對應的管理權限為用戶C 和D 使用的私鑰SK_C 和SK_D 。
私鑰SK_A 和SK_B 本身作為私鑰依然可以簽名,不可以被撤銷,而是通過智能合約的可編程特性,把驗證轉賬權限的方式從驗證私鑰SK_A 和SK_B 更改為了驗證SK_C 和SK_D。從使用錢包的角度看,我們可以認為私鑰SK_A 和SK_B 管理合約錢包的權限被撤銷了。
(2)何為MPC 的私鑰分片重新分片和私鑰分片刷新
安全多方計算(Secure Multi-Party Computation,MPC/SMPC) 是一類鏈下的密碼學技術,與具體的某個區塊鏈無關,在簽名算法層面MPC 協議可以做到t/n 多簽。通過多方計算的方式,在私鑰生成、使用、刷新、重新分片等過程,保證密鑰的可用但不可見。所以MPC 可以直接管理EOA,也可以結合智能合約錢包管理資產。

通俗來講,通過MPC 管理錢包時,需要先分佈式生成私鑰分片,比如2/2 雙方各自生成私鑰分片KeyShare_A、KeyShare_B,對應的錢包地址Address 2 。

轉賬時使用進行分佈式簽名,使用KeyShare_A 和KeyShare_B 執行簽名協議,授權錢包轉賬。

私鑰分片刷新指在保持錢包地址Address 2 不變的情況下,這一組私鑰分片KeyShare_A 和KeyShare_B 經過分佈式刷新協議後,持有私鑰分片的雙方各自可以分別得到新的一組私鑰分片KeyShare_A' 和KeyShare_B' ,後續可以使用KeyShare_A' 和KeyShare_B' 授權錢包轉賬。但是KeyShare_A 和KeyShare_B 依然也可以使用。

私鑰分片重新分片(re-shareing)類似刷新,與刷新不同的地方在於,重新分片可以修改門限,比如2/2 對應的一組私鑰分片KeyShare_A 和KeyShare_B 執行重新分片協議後,門限修改為了3/3 ,雙方和新參與的一方分別得到了一組新的私鑰分片KeyShare_A' 、 KeyShare_B' 和KeyShare_C',對於新的一組私鑰分片必須三個私鑰分片一起執行分佈式簽名協議才可以進行簽名。但是KeyShare_A 和KeyShare_B 依然也可以按照2/2 門限使用。
值得一提的是,上面四個過程中,背後原始的私鑰只在數學意義上存在,在所有的過程中實際沒有出現過,各方也無法得到其他參與方的私鑰分片。
(3)MPC 錢包在什麼場景下無法撤銷密鑰
首先需要澄清MPC 密碼學協議和MPC 錢包是兩個概念,MPC 錢包通過設計密鑰分片分佈和門限管理機制+ MPC 密碼學協議構建錢包。而智能合約錢包則可以理解為使用可編程智能合約設計私鑰管理機制+ 簽名算法構建錢包。並且,智能合約使用的簽名算法可以是單私鑰的簽名算法,也可以是基於MPC 的門限簽名算法。
針對MPC-TSS 協議,由於密碼學的特性,如第二個問題中解釋重新分片和刷新問題,重新分片和刷新後,原有的私鑰分片KeyShare_A 和KeyShare_B 依然可用,在MPC 協議層面,每一組私鑰分片是無法撤銷的;這和第一個問題中智能合約錢包驗證方式從私鑰SK_A 和SK_B 切換到私鑰SK_C 和SK_D 之後類似,密碼學層面私鑰SK_A 和SK_B 依然可用,無法被撤銷。
那麼什麼情況下MPC 錢包無法撤銷密鑰?比如,MPC 錢包設計的門限是2/2 ,管理方式是用戶A 和用戶B 管理,分別持有KeyShare_A 和KeyShare_B。如果要變更這個錢包的管理權限,通過MPC 刷新/重新分片協議,用戶C 和用戶D 得到KeyShare_A' 和KeyShare_B' 。雖然進行了刷新和重新分片,用戶C 和用戶D 可以管理錢包,但是從使用錢包的角度來看,用戶A 和用戶B 作為曾經的分片持有人,依然可以管理錢包,也就是說,這種MPC 錢包是無法撤銷密鑰的。
(4)MPC 錢包在什麼場景下可以撤銷密鑰

以個人級錢包Zengo 為例,底層的簽名門限為2/2 ,用戶自己持有私鑰分片KeyShare_A,Zengo 持有私鑰分片KeyShare_B。如果客戶懷疑自己的私鑰分片KeyShare_A 被竊取了,理論上講,在保持錢包地址不變的前提下,用戶可以請求和Zengo 進行一次密鑰刷新,雙方各自得到KeyShare_A' 和KeyShare_B' ,刷新成功後Zengo 物理刪除KeyShare_B 以及拒絕使用KeyShare_B 繼續參與後續簽名,只使用KeyShare_B',用戶使用KeyShare_A'。從使用錢包的角度看,由於KeyShare_A 無法和KeyShare_B' 無法計算出正確的簽名,所以此時攻擊者竊取的KeyShare_A 已經被撤銷。

以企業級錢包Safeheron 為例,底層的簽名門限為3/3 ,成員1 參與簽名時,私鑰分片的分佈為成員本地的手機設備中的KeyShare_A、Safeheron 雲端在可信計算環境中的KeyShare_B、可信第三方雲端在可信計算環境中的KeyShare_C。當成員1 懷疑自己的私鑰分片KeyShare_A 被竊取了,在保持錢包地址不變的前提下,成員1 可以請求與雲端進行一次密鑰刷新,類似Zengo 場景,刷新成功後三方各自得到新的私鑰分片KeyShare_A'、KeyShare_B' 和KeyShare_C',雲端可信執行環境中物理刪除KeyShare_B 和KeyShare_C,此時從使用錢包的角度看KeyShare_A 就被撤銷了。
總結總結
總結
理清此次討論的爭議點後,我們再來理解Vitalik 的回答就相對容易。個人認為在上述第三個問題舉的場景中,Vitalik 的觀點是沒有問題的,但是Vitalik 的回答以偏概全。就回答本身而言,並非所有MPC 錢包在使用時都不可以撤銷密鑰,各種MPC 錢包方案也有所差異。 MPC 錢包與智能合約錢包解決問題的側重點也不相同,MPC 錢包更偏向於解決多鏈通用多籤的資產安全管理問題。
而且, MPC 錢包和智能合約錢包並非對立關係,通過結合鏈下MPC 和鏈上智能合約錢包優勢,相信在未來可以看到許多有創新性的MPC + 智能合約產品和解決方案。


