Safeheron partner responds to Vitalik's evaluation of MPC: MPC and smart contract wallets are not competing with each other.
Original Author: Kane Wang, Safeheron Partner & Technical VP
Recently, Ethereum founder Vitalik expressed his views on the advantages and disadvantages of MPC wallets and smart contract wallets, as shown in the figure below:
Vitalik believes that MPC-based EOA wallets have inherent deficiencies because the keys cannot be revoked. Even if re-sharing is performed, this problem cannot be solved as the old shard holders can still recover the private keys. Therefore, smart contract wallets are the only choice.
This has sparked intense discussions within the community about MPC wallets and smart contract wallets. As of the time of writing, some friends have asked for my opinion on Vitalik's negative assessment of MPC. Personally, this discussion has turned into a discussion of positions, and there is no right or wrong without a unified application scenario and business premise.
Instead of escalating tensions, it is better to clarify the points of contention in this debate: What exactly is the "revoke keys" operation pointed out by Vitalik, and under what scenarios is it applicable? How does the private key shard management mechanism of MPC wallets differ from the private key management mechanism of smart contract wallets?
(1) What is the "revoke keys" operation?
For example, when using a smart contract wallet, let's assume the wallet address is Address 1 and user A uses private key SK_A while user B uses SK_B to manage the smart contract wallet. When making transfers with the wallet, both user A and user B need to authorize the transaction.
If a user wants to change the management authority of the wallet, for instance, from user A and B managing the wallet to user C and D, while keeping the wallet address unchanged, and revoking the management authority of user A and B. Through the smart contract, the revocation of user A and B's management authority for the wallet can be achieved by modifying the corresponding management authority to the private keys SK_C and SK_D used by user C and D.
The private keys SK_A and SK_B themselves can still sign and cannot be revoked, but the way to verify the transfer authorization has been changed from verifying the private keys SK_A and SK_B to verifying SK_C and SK_D through the programmable feature of the smart contract. From the perspective of using a wallet, we can consider that the permission of managing the contract wallet by the private keys SK_A and SK_B has been revoked.
(2) What is MPC's private key sharding and private key sharding refreshing
Secure Multi-Party Computation (MPC/SMPC) is a type of off-chain cryptographic technology that is independent of a specific blockchain and at the signature algorithm level, the MPC protocol can achieve t/n multi-signature. Through multi-party computation, the key can be available but not visible in the processes of key generation, usage, refreshing, and resharding. So MPC can directly manage EOA and can also manage assets in smart contract wallets.
In simple terms, when managing a wallet through MPC, it is necessary to first distribute the generation of private key shards. For example, in a 2/2 situation, each party generates their own private key shard KeyShare_A and KeyShare_B, corresponding to the wallet address Address 2.
When making a transfer, distributed signing is used. The signing protocol is executed using KeyShare_A and KeyShare_B, authorizing the wallet to make the transfer.
Private key sharding refreshing refers to the situation where, while keeping the wallet address Address 2 unchanged, after going through a distributed refreshing protocol, the two parties holding the private key shards KeyShare_A and KeyShare_B respectively can obtain a new set of private key shards KeyShare_A’ and KeyShare_B’. Subsequently, KeyShare_A and KeyShare_B can still be used.
Private key sharding re-sharding (re-sharing) is similar to refreshing, with the difference being that re-sharding can modify the threshold. For example, after executing the re-sharding protocol for a group of private key sharding KeyShare_A and KeyShare_B corresponding to 2/2, the threshold is modified to 3/3. The two parties and the newly participating party each obtain a new group of private key sharding KeyShare_A’, KeyShare_B’, and KeyShare_C’. For the new group of private key sharding, all three private key shards must be used together to execute the distributed signing protocol in order to perform signing. However, KeyShare_A and KeyShare_B can still be used with a 2/2 threshold.
It is worth mentioning that in the above four processes, the original private key exists only in a mathematical sense and has not actually appeared in any process. The parties also cannot obtain the private key shards of other participants.
(3) In what scenarios can an MPC wallet not revoke a key?
Firstly, it is necessary to clarify that MPC cryptographic protocols and MPC wallets are two different concepts. An MPC wallet is constructed through the design of key shard distribution, threshold management mechanism, and MPC cryptographic protocol. On the other hand, a smart contract wallet can be understood as a wallet constructed using a programmable smart contract, private key management mechanism, and signature algorithm. Furthermore, the signature algorithm used in smart contracts can be a single private key signature algorithm or an MPC-based threshold signature algorithm.
Regarding the MPC-TSS protocol, due to the cryptographic characteristics, as explained in the second question regarding re-sharding and refreshing, after re-sharding and refreshing, the original private key shards KeyShare_A and KeyShare_B are still usable. At the MPC protocol level, each group of private key shards cannot be revoked. This is similar to the first question where, in the smart contract wallet verification process, switching from private keys SK_A and SK_B to private keys SK_C and SK_D, at the cryptographic level, private keys SK_A and SK_B are still usable and cannot be revoked.
Under what circumstances can the MPC wallet not revoke keys? For example, the MPC wallet is designed with a threshold of 2/2, managed by User A and User B, who respectively hold KeyShare_A and KeyShare_B. If the management permissions of this wallet need to be changed, through MPC refresh/re-sharding protocol, User C and User D obtain KeyShare_A' and KeyShare_B'. Although the refresh and re-sharding have been performed, User C and User D can manage the wallet. However, from the perspective of using the wallet, User A and User B, as the former shard owners, can still manage the wallet, which means that this kind of MPC wallet cannot revoke keys.
(4) Under what scenarios can the MPC wallet revoke keys
Take the individual-level wallet Zengo as an example. The underlying signature threshold is 2/2, and the user holds the private key shard KeyShare_A, while Zengo holds the private key shard KeyShare_B. If the user suspects that their private key shard KeyShare_A has been stolen, theoretically, while keeping the wallet address unchanged, the user can request a key refresh with Zengo. Both parties obtain KeyShare_A' and KeyShare_B' respectively. After a successful refresh, Zengo physically deletes KeyShare_B and refuses to use KeyShare_B for subsequent signatures, only using KeyShare_B', while the user uses KeyShare_A'. From the perspective of using the wallet, since KeyShare_A cannot calculate the correct signature with KeyShare_B', the KeyShare_A stolen by the attacker has been revoked.
Take the enterprise-level wallet Safeheron as an example. The underlying signature threshold is 3/3, and when member 1 participates in the signature, the distribution of private key shards is Member A's KeyShare_A on the local mobile device, Safeheron's KeyShare_B in the trusted computing environment, and the trusted third-party cloud's KeyShare_C in the trusted computing environment. When member 1 suspects that their private key shard KeyShare_A 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 each obtain new private key shards KeyShare_A', KeyShare_B', and KeyShare_C'. The trusted cloud execution environment physically deletes KeyShare_B and KeyShare_C, which means that from the perspective of using the wallet, KeyShare_A has been revoked.
If in the management process, the enterprise needs to replace member 1 with member 2 to jointly manage assets, the trusted cloud execution environment will delete the two private key shards KeyShare_B and KeyShare_C corresponding to member 1. After adding member 2, the team creator activates a new set of private key shards KeyShare_A2, KeyShare_B2, and KeyShare_C2. Member 2's private key distribution is the same as member 1's. From the perspective of using the wallet, member 1's KeyShare_A is revoked, and member 2's KeyShare_A2 is added to participate in team asset management.
Summary
After clarifying the points of controversy discussed this time, it is relatively easy to understand Vitalik's response. Personally, I think in the scenario mentioned in the third question, Vitalik's perspective is valid, but his answer is biased. In terms of the answer itself, not all MPC wallets cannot revoke keys when used. There are also differences in various MPC wallet solutions. MPC wallets and smart contract wallets also focus on different issues. MPC wallets are more inclined to solve the security management of multi-chain universal multi-signature assets.
Moreover, MPC wallets and smart contract wallets are not mutually exclusive. By combining the advantages of off-chain MPC and on-chain smart contract wallets, it is believed that many innovative MPC + smart contract products and solutions will be seen in the future.
