Vitalik comments on MPC: Can MPC wallet keys really be revoked?

Author: Kane Wang, Partner & Technical VP at Safeheron

Recently, Ethereum founder Vitalik expressed his views on the pros and cons of MPC wallets and smart contract wallets, as shown in the image below:

Vitalik believes that MPC-based EOA wallets have fundamental flaws because keys cannot be revoked. Even re-sharing cannot solve this problem; after re-sharing, the old shard holders can still recover the private key. Therefore, smart contract wallets are the only option.

This has led to a renewed heated discussion in the community regarding MPC wallets and smart contract wallets. Before this article was published, some friends had already asked me about my views on Vitalik's negative comments on MPC. Personally, I believe that the discussion on this issue has ultimately evolved into a matter of positions. Discussions that do not unify application scenarios and business scenarios have no right or wrong.

Instead of escalating tensions, it is better to clarify the points of contention: What exactly is the revoke keys that Vitalik pointed out, and what scenarios does it apply to? How does the private key shard management mechanism of the MPC wallet differ from that of the smart contract wallet?

(1) What is the revoke keys operation?

For example, when using a smart contract wallet, suppose the wallet address is Address1, user A uses private key SKA, and user B uses SKB to manage the smart contract wallet. When transferring funds using the wallet, both user A and user B need to authorize the transaction simultaneously.

If the users want to change the management permissions of the wallet, for instance, originally managed by users A and B, they now want to keep the wallet address unchanged while changing the management to users C and D, and revoke the management permissions of users A and B. This can be achieved through a smart contract that revokes the management permissions of users A and B corresponding to private keys SKA and SKB, modifying the management permissions to the private keys SKC and SKD used by users C and D.

Private keys SKA and SKB can still sign as private keys and cannot be revoked; instead, through the programmable features of the smart contract, the method of verifying transfer permissions is changed from verifying private keys SKA and SKB to verifying SKC and SKD. From the perspective of using the wallet, we can consider that the management permissions of private keys SKA and SKB for the contract wallet have been revoked.

(2) What are the re-sharing and refreshing of private key shards in MPC?

Secure Multi-Party Computation (MPC/SMPC) is a type of off-chain cryptographic technology that is independent of any specific blockchain. At the signature algorithm level, the MPC protocol can achieve t/n multi-signature. Through multi-party computation, during the processes of private key generation, usage, refreshing, and re-sharing, the keys are kept usable but invisible. Therefore, MPC can directly manage EOA or combine with smart contract wallets to manage assets.

In simple terms, when managing a wallet through MPC, private key shards need to be generated in a distributed manner. For example, in a 2/2 scheme, both parties generate their private key shards KeyShareA and KeyShareB, corresponding to wallet address Address2.

When transferring funds, distributed signing is performed using KeyShareA and KeyShareB to execute the signing protocol and authorize the wallet transfer.

Private key shard refreshing refers to the process where, while keeping wallet address Address2 unchanged, this set of private key shards KeyShareA and KeyShareB undergoes a distributed refresh protocol, allowing both parties holding the private key shards to obtain a new set of private key shards KeyShareA' and KeyShareB'. Subsequently, they can use KeyShareA' and KeyShareB' to authorize wallet transfers. However, KeyShareA and KeyShareB can still be used.

Private key shard re-sharing is similar to refreshing, but differs in that re-sharing can modify the threshold. For example, a set of private key shards KeyShareA and KeyShareB corresponding to a 2/2 scheme, after executing the re-sharing protocol, can have the threshold modified to 3/3. The parties and a new participant will each obtain a new set of private key shards KeyShareA', KeyShareB', and KeyShareC'. For the new set of private key shards, all three must participate in the distributed signing protocol to sign. However, KeyShareA and KeyShare_B can still be used under the 2/2 threshold.

It is worth mentioning that in the above four processes, the original private key only exists in a mathematical sense and has never actually appeared in any of the processes, and no party can obtain the private key shards of other participants.

(3) In what scenarios can MPC wallets not revoke keys?

First, it is important to clarify that the MPC cryptographic protocol and the MPC wallet are two different concepts. The MPC wallet is constructed through the design of key shard distribution and threshold management mechanisms + MPC cryptographic protocol. In contrast, the smart contract wallet can be understood as using programmable smart contracts to design private key management mechanisms + signature algorithms to construct the wallet. Additionally, the signature algorithms used in smart contracts can be either single private key signature algorithms or threshold signature algorithms based on MPC.

Regarding the MPC-TSS protocol, due to the characteristics of cryptography, as explained in the second question regarding re-sharing and refreshing, after re-sharing and refreshing, the original private key shards KeyShareA and KeyShareB remain usable. At the MPC protocol level, each set of private key shards cannot be revoked; this is similar to the first question where the verification method of the smart contract wallet switches from private keys SKA and SKB to private keys SKC and SKD, where the private keys SKA and SKB remain usable and cannot be revoked.

So, in what situations can MPC wallets not revoke keys? For example, if the MPC wallet is designed with a threshold of 2/2, managed by users A and B holding KeyShareA and KeyShareB respectively. If the management permissions of this wallet need to be changed, through the MPC refresh/re-sharing protocol, users C and D obtain KeyShareA' and KeyShareB'. Although refreshing and re-sharing have occurred, users C and D can manage the wallet, from the perspective of using the wallet, users A and B, as former shard holders, can still manage the wallet, meaning that this type of MPC wallet cannot revoke keys.

(4) In what scenarios can MPC wallets revoke keys?

Taking the personal wallet Zengo as an example, the underlying signature threshold is 2/2, where the user holds the private key shard KeyShareA, and Zengo holds the private key shard KeyShareB. If the customer suspects that their private key shard KeyShareA has been stolen, theoretically, while keeping the wallet address unchanged, the user can request a key refresh with Zengo, and both parties will obtain KeyShareA' and KeyShareB'. After a successful refresh, Zengo physically deletes KeyShareB and refuses to use KeyShareB for subsequent signatures, only using KeyShareB', while the user uses KeyShareA'. From the perspective of using the wallet, since KeyShareA cannot compute a correct signature with KeyShareB', the stolen KeyShareA has been revoked.

Taking the enterprise wallet Safeheron as an example, the underlying signature threshold is 3/3. When member 1 participates in signing, the distribution of private key shards includes KeyShareA on the member's local mobile device, KeyShareB in a trusted computing environment in the Safeheron cloud, and KeyShareC in a trusted third-party cloud environment. If member 1 suspects that their private key shard KeyShareA has been stolen, while keeping the wallet address unchanged, member 1 can request a key refresh with the cloud. Similar to the Zengo scenario, after a successful refresh, the three parties will each obtain new private key shards KeyShareA', KeyShareB', and KeyShareC', and the cloud's trusted execution environment will physically delete KeyShareB and KeyShareC. At this point, from the perspective of using the wallet, KeyShareA has been revoked.

If the enterprise needs to replace member 1 with member 2 to jointly manage the assets, the cloud's trusted execution environment will delete the two private key shards KeyShareB and KeyShareC corresponding to member 1. After adding member 2, the team creator activates a new set of private key shards KeyShareA2, KeyShareB2, and KeyShareC2 for member 2, with the same private key distribution method as member 1. At this point, from the perspective of using the wallet, member 1's KeyShareA has been revoked, and member 2 has been added to use KeyShare_A2 to participate in team asset management.

Conclusion

After clarifying the points of contention in this discussion, it becomes relatively easy to understand Vitalik's response. Personally, I believe that in the scenarios mentioned in the third question, Vitalik's viewpoint is valid, but his response is somewhat one-sided. In terms of the response itself, not all MPC wallets cannot revoke keys during use, and various MPC wallet solutions differ. The focus of MPC wallets and smart contract wallets in solving problems is also different, with MPC wallets leaning more towards solving the asset security management issues of multi-chain universal multi-signatures.

Moreover, MPC wallets and smart contract wallets are not in opposition; by combining the advantages of off-chain MPC and on-chain smart contract wallets, I believe we will see many innovative MPC + smart contract products and solutions in the future.