Safeheron合夥人回應Vitalik評MPC：MPC與智能約錢包並非競爭關系

2023-07-01 00:07:29

原文作者：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 就被撤銷了。

如果企業在管理過程中，需要將成員 1 更換為成員 2 來共同管理資產，此時雲端可信執行環境會刪除成員 1 對應的兩個私鑰分片 KeyShare_B 和 KeyShare_C ，添加成員 2 後團隊創建者為成員 2 激活一組新的私鑰分片 KeyShare_A 2、KeyShare_B 2 和 KeyShare_C 2 ，成員 2 的私鑰分布方式和成員 1 相同。 此時從使用錢包的角度看撤銷了成員 1 的 KeyShare_A，新增了成員 2 使用 KeyShare_A 2 參與團隊資產管理。

總結

理清此次討論的爭議點後，我們再來理解 Vitalik 的回答就相對容易。個人認為 在上述第三個問題舉的場景中，Vitalik 的觀點是沒有問題的，但是 Vitalik 的回答以偏概全。 就回答本身而言，並非所有 MPC 錢包在使用時都不可以撤銷密鑰，各種 MPC 錢包方案也有所差異。MPC 錢包與智能合約錢包解決問題的側重點也不相同，MPC 錢包更偏向於解決多鏈通用多籤的資產安全管理問題。

而且， MPC 錢包和智能合約錢包並非對立關系，通過結合鏈下 MPC 和鏈上智能合約錢包優勢，相信在未來可以看到許多有創新性的 MPC + 智能合約產品和解決方案。