Note: This blog post was written by a guest author. We’re featuring this article as part of a new “Research” category on the Secret Network blog, which will explore topics relating to cryptography, privacy, and general blockchain technology. These topics all tie into the research being done for Secret 2.0. If you’re interested in having your own article featured, contact us. You can also join in on the Secret 2.0 discussion on the Secret Discord and Telegram.
If you’re interested in more from this author, the original article can be found here.
Have you ever seen Vitalik angry? it looks like this topic gets him emotional:
If a fifth of the effort that has gone into these incredibly mathematically clever MPC workarounds had instead gone into protocol-level account abstraction, we would be at wallet security utopia by now. 😡
— vitalik.eth (@VitalikButerin) May 19, 2022
NOTE: In the following I use Ethereum Improvement Proposal (EIP) as equivalent to Ethereum Request for Comments (ERC). These terms are different, but the difference is not relevant to this post.
Background
Ethereum Improvement Proposal (EIP) number 4337 has been deployed on the mainnet, with the main objective of establishing a standard for a smart contract that can function as a private wallet and gradually replace the need for Externally Owned Accounts (EOA). Although it was possible to deploy such a contract before EIP 4337, a formal deployment of an Entry Point contract by Ethereum was awaited to fully leverage the smart-contract-wallet concept. These changes have now been implemented on the mainnet, enabling features such as transaction compression, signature aggregation, flexible authentication, sponsored transactions, and pre-approved transactions (see Vitalik’s original post). The highly anticipated deployment has been receiving widespread praise on the internet, which has caused some confusion in the web3 community regarding its relationship with another abstraction technique known as MPC-wallets. Several posts, including Vitalik Buterin’s tweet above, suggest that EIP 4337 can replace MPC-based wallets entirely, which is far from being true. Therefore, it’s necessary to provide a comprehensive explanation of both the EIP 4337 standard and the MPC concept and answer the question: Can Account Abstraction (EIP 4337) replace MPC-wallets?
Short answer:
While account abstraction (EIP 4337) offers attractive features and introduces a high level of payment flexibility to the blockchain, it falls short in other crucial metrics. These include costs, security, privacy, multi-chain compatibility, and complexity. Additionally, it introduces another layer of information asymmetry to the market, which I refer to as “bundler extractable value” (BEV). Validators may team up with bundlers in the future to enhance their MEV and BEV optimization.
As a result, both smart-contract-wallets and MPC-wallets are expected to coexist and be integrated into holistic wallet solutions to take advantage of the benefits offered by both technologies. Continue reading if you want to learn more about these concepts and the benefits each has to offer.
The big picture: What users of financial systems want?
Two, somewhat colliding, concerns of cryptocurrencies’ users (or holders) are ownership and utility:
- Ownership refers to the desire to minimize the trust one puts in others to the minimum possible, and that the owner will never be censored (prevented) from using its assets.
- Utility mainly refers to two concerns: (1) responsibility — the desire to minimize the chances that funds will get lost (by mistake, key theft, natural disaster, etc.), and (2) tradability — maximizing capital efficiency (i.e., easy trade and investment with low fees).
In the classical world, one would exercise ownership by storing cash or a gold bullion at home, while utility (responsibility and tradability) can be achieved by storing the funds at the bank or another financial institute. In the cryptocurrency world everything is digital in the first place, but practices are not so different.
The two properties, ownership and responsibility are “conflicting” in the sense that users are typically not responsible or too vulnerable. Even responsible users tend to lose important things (like keys, password and documents) all the time, they are prone to social engineering and phishing attacks and sometime are an easy target for thieves. Therefore, it is difficult to have full ownership and yet protect yourself from all these threats. One may choose only responsibility, by moving funds to the bank, however in times of crisis its ownership claims may be at risk (unfortunately there are abundant examples, recent ones include FTX and SVB). While Metamask, Trust wallet, and other self-custodial solutions mainly focus on ownership, other solutions like Binance, coinbase.com, crypto.com and other exchanges focus on utility.
Semi custodial wallets (sometime also knwon as “non-custodial”)
Bridging the above gap between ownership and utility can be done by two other concepts — smart-contract-wallets and MPC-wallets. Namely, solutions based on these concepts address both ownership and responsibility. They enable users to have full control of their assets and resist censorship, while offering responsibility, namely, providing mechanisms in which users may recover their lost key in case of a disaster or limit the loss of funds in the case of a theft/phishing attack. These solutions can be called “semi-custodial wallets”, which implicitly means they are not exactly self-custodial in the natural way, but not custodial neither (the user does not delegate custody of the funds to a third party).
In terms of responsibility, smart-contract-wallets may support any authentication mechanisms; you can think of the usual ECDSA signature, but you can imagine an authentication by providing a zero-knowledge proof that you own some email-address. Recovery is supported as well, so if the user has lost its private ECDSA key, it can still access its wallet by providing a proof that it owns that email address. In addition, one may program its smart contract wallet with any access structure. For example, it is possible to open a “business wallet” that allows any two out of the three business owners to spend money, and in addition for any employee to spend some monthly allowance. MPC wallets support similar features (recovery and access structre) , but the techniques used in each technology are completely different and have different implications on the user (like user experience and costs).
Both concepts of MPC wallet and smart contract wallet were conceived at around the same time in years 2016–2018. Vitalik Buterin’s first proposed the idea of wallets implemented as smart contracts (EIP 086) in 2017, and shortly after, Unbound (now Coinbase) (followed by ZenGo) took steps toward what we know as MPC-wallets. Since then, the market of semi-custodial wallets was dominated by MPC-wallets (ZenGo, Fireblocks, Copper), however, in the past year the market was somewhat shook with the penetration of smart-contract-wallets like Gnosis safe, Argent, Braavos and others.
In the rest of this post I will briefly cover the key mechanisms by which smart contract wallets and MPC wallets combine ownership and responsibility, and explain the strengths and weaknesses implied by these mechanisms.
Externally owned accounts and contracts
The architecture of smart-contract-enabled blockchains consists of two types of accounts: the externally owned account (EOA) and the smart contract account (simply “contract” from now on).
The conceptual distinctions between an EOA and a contract is that a contract typically represents a publicly owned account (e.g., a liquidity pool that is owned by many liquidity providers, or a token balance sheet) whereas an EOA represents a privately owned account (i.e., an account of an individual). In addition, a contract may transfer funds only upon the occurrence of a predefined event that all stake holders agreed on, whereas an EOA may transfer funds spontaneously, at will of its (individual) owner.
Smart-contract-wallets (i.e., the instantiation of Account Abstraction, or EIP 4337) and MPC-wallets challenge the above distinctions from two opposite directions:
- The concept of a smart-contract-wallet establishes that the way users manage their private funds is not by granting an exclusive power to some private key (an EOA). Rather, the user’s funds are now owned by a contract, which in turn is owned by the user; the user can express the way these funds can be managed. For example, one may specify a monthly allowance budget to her daughter, without the need to provide her daughter the private key in full. As another example, a user may grant another entity (contract or EOA) permission to transfer funds up to some amount and for some limited amount of time. The last feature finds applications in blockchain based billing mechanisms for games. This suggests that a contract is flexible enough to support the management of private accounts as well.
- An MPC-wallet, on the other hand, establishes that publicly owned funds can be managed through an externally owned account (EOA). That is, through a single private key , rather than a multi-sig contract. For instance, a corporate may wish to manage its funds through a single EOA account in order to simplify operation processes and key management, at the same time, managers require that transfers are sent to the blockchain only upon consensus. This is a feature in the power of MPC wallets.
Thus, the borders between what we knew as privately-owned and publicly-owned accounts are largely blurred.
In the following, a 1000 feet overview on contract-wallets and MPC-wallets is given, followed by a list of features and use-cases that each of them supports. You can find a summary in the end of the post.
EIP 4337: Account Abstraction (AA) and smart contract wallets
Traditionally, a wallet consists of a public key and a private (signing) key, where the wallet’s address is derived from the public key, and transactions of funds out of that wallet must be signed using the private key. That is, until very recently, a wallet was (almost exclusively) a synonym to an externally owned account (EOA).
Contract-based wallets, on the other hand, are used to represent some type of a state machine, that can be triggered by anyone who satisfies the conditions programmed in it. These conditions are specified by the contract writer on behalf of the account owner. The contract is general enough, so its owner may change some important parameters at any moment, e.g., it can change the signature scheme, or the access structure that the contract-wallet must comply to.
A standardization of the concept of account abstraction was proposed in the end of 2021 (EIP 4337) and by now multiple projects are taking parts in order to instantiate that standard and extend it. Leading this effort are Argent and Gnosis Safe, who have recently announced a list of new features in ethTLV.
The main modification this standard specifies is the ability to infiltrate invalid transactions to the blockchain. That is, a user with a smart-contract-wallet does not need to authenticate itself to the blockchain anymore (i.e., it does not need to associate with the transaction a signature that will be verified by the blockchain’s validators). Instead, it has to authenticate itself directly to the contract. That means that the blockchain has to support a special type of transactions that can get on-chain without validating a signature first, this type of transactions is called “user-operation” (see figure above). (In other contexts, such as in the gas-station-network (GSN), such operations are called “meta-transactions”, however, we will stick to the Ethereum’s terminology and call them user-operations).
According to EIP 4337, user-operations are bundled into a single big transaction, and are infiltrated to the blockchain through a designated, singleton Entry Point contract. This means that the blockchain’s validation mechanism is changed such that transactions directed to the Entry Point contract do not have to pass through the usual signature verification process, rather, they are passed to the contract as is. (Ethereum has deployed an Entry Point contract on multiple chains, you can inspect one of these contracts here). Then, this contract unbundles that big transaction to obtain many user-operations and relays each of them to the contract-wallet that is owned by the corresponding user. This opens a market for “bundlers” who offer bundling services and help you infiltrate your user-operation to the blockchain. Several bundlers already exist, the first to fully comply to the standard is stackup.
Key Features of smart contract wallets
- Better throughput (number of transactions per block) — passing user-operations directly to a contract allows performing some operations on the user-operation before executing it. Specifically, the user-operation can be compressed before sending it, and decompressed in the contract. Compression here refers to the classical interpretation: simply making a message shorter. As an example, the first compression step in this diagram simply removes zero-bytes from the message. Furthermore, when many users pick an aggregateable signature scheme (like Schnorr or BLS) as their wallet’s authentication mechanism, the bundler may aggregate all signatures off-chain, and post only a single signature on-chain. These two features , hereby, reduce the effective number of bytes a transaction occupies on-chain and therefore saving storage costs.
- Easy MFA — you can easily configure multi-factor authentication by programming your contract to execute transactions only if they are associated with multiple signatures, each signature is possibly generated with a different device (e.g., a smart watch). Alternatively, you can specify authentication mechanisms different than a signature, e.g., a proof that you own an email address.
- Sponsored transactions — a user-operation can define a sponsor, who can pay the gas fee on behalf of the user. This allows dApps to subsidies their users, or enable users to pay in the dApp’s native token rather than in ETH.
- Pre-approve transaction — a user may pre-approve payments satisfying some conditions. For example, an online game user may pre-approve payments to the game operator, within the next hour, as long as their sum does not exceed 20$.
Key Issues of smart contract wallets
- Security1: signature aggregation as an attack vector — cryptography is tricky, and advanced features like signature aggregation are even trickier. One attack on signature aggregation is called Rogue Key Attack,. Such attacks causes the bundler to add a user-operation that is associated with a signature; if that signature is aggregateable, an attacker may specify a public key (against which a singature is verified) that depends on other public keys in the same bundle, and may cause the aggregated signature to be successfully verified even if the attacker doesn’t know the corresponding secret (signing key). Such an attack allows the attacker to pass user-operations to any contract-wallet, which is a critical issue. It is possible to avoid such attacks by performing extra checks on the individual and aggregated signatures/keys, however, it is prone to errors. For more details read this explanation about the Rogue Key Attack implemented for the BLS signature scheme.
This demonstrates the lack in wallet separation, that is, a bug in the bundler’s code (e.g., bad aggregation) is disastrous to many contract-wallets. Another point related to that issue is discussed below. - Security2: different wallets with common code-base — the account abstraction architecture introduces new complex objects that relates to many wallets. One example is the signature aggregation above, but the whole bundler’s code as well as the Entry Point contract consist of code that is accessible to many users, and in which exploited vulnerabilities may cause a disaster to many wallets.
- Limitation to one blockchain — since the contract “lives” on one blockchain, it can manage funds living on that specific blockchain only, whereas a user who owns funds on other blockchains has to find a way to mange those funds as well.
- Introducing a new value-extraction layer — like miners (or block proposers), bundlers have the ability to order user-operations, which may lead to a new market of “bundler extractable value” (BEV). This may add another financial threat to De-Fi users.
MPC wallets
MPC-wallet is a different type of abstraction, specifically, it takes the ownership of the EOA’s private key and “virtualizes” it. Specifically, MPC allows a group of users to collaboratively exercise ownership of an EOA. This is done by secret-sharing the private-key in a way that each user holds only part of it. Using only one part of the private key, one cannot sign a transaction, however, when all group members agree on a transaction and engage in an interactive signing protocol they are able to produce a signature. In most instantiations (see Zengo, Web3Auth, Coinbase and others), this collaborative signing is implemented by two parties only , but more complex structures are possible. For instance, it is possible to secret share the private key to five parts (also called “shards”), hand each group member one of them, and decide that three group members are sufficient to produce signatures (through an interactive cryptographic protocol) without the need of the other two. Such access structre is called “three-out-of-five threshold signature scheme”.
MPC stands for (Secure) Multi-Party Computation. It is a problem in computer science that is undergone researched for about 40 years. Breakthroughs in the field in the past 10 years led to efficient solution of many problems including threshold signature protocols that are related to wallets. Arguably, the use case of distributed storage and management of cryptographic assets became the most prevalent one, or the “killer app” if you will.
Key features of MPC wallets
- Multi/threshold signature for any signature scheme — the signature is generated using a cryptographic protocol that runs between the signatories, hence, any signature scheme can be supported.
- Multi-chain — the above enables the same group of signatories to access funds on any blockchain, even if the blockchain does not support a rich contract language, like Bitcoin, Zcash, and others.
- Security (also) by obscurity — a multi-sig mechanism implemented at the contract-level may be considered more vulnerable to attacks. In contrast, an MPC wallet reduces the attack surface by moving the logic off-chain, making it less likely and more difficult to be attacked. Logical attacks on contracts are not rare, and there have already been incidents of this happening, such as the multi-sig contract of Parity.
- Signatory’s privacy & anonymity — the signatories behind an MPC-wallet should not be publicly identified, only the public address has to be publicly known. Furthermore, in a threshold scheme, say 5 signatories out of 10 are sufficient to produce a signature, even if the group of 10 signatories are publicly known, it is typically not possible to tell which signatory has participated in the production of a signature on a certain transaction.
- Off-chain policy enforcement — the signatories’ access structure and the policy to which transactions must comply can be managed and modified without any interaction with the blockchain, these are simply agreed upon by the signatories (however, changing access structure usually requires running a complex cryptographic protocol).
- Protection against related nonce attacks — most signature schemes use a nonce (sometimes referred as an ephemeral private key), it is highly important that this nonce is generated by a high quality random number generator (RNG), otherwise the signer may be exposed to a related nonce attack (cf. Macchetti 2023). Namely, an attack that exploits correlations between nonces of different signatures in order to extract the secret (signing) key. In MPC wallets the nonce is generated by multiple parties, and it is typically sufficient that at least one of them is equipped with a high quality RNG, which reduce the probability that such an attack will occur.
Key issues of MPC wallets
- Complexity — signature generation in the MPC model typically requires an interaction between the signatories, as well as performing complex mathematical operations
- Security — as mentioned above, cryptography is tricky; sometime a small mistake may lead to a devastating results. Cryptographic protocols may be insecure (even when published and peer reviewed). For example, see the attack by Drijvers et al. on threshold Schnorr signatures, which allows the attacker to forge a signature on any message given the result of multiple presign procedures that are run simultaneously.
Summary Comparison: Contract vs. MPC
- Throughput (number of transactions per block) — both contract-wallets and MPC-wallet may decrease the space occupied on-chain for transaction authentication (i.e., signature part), but in different ways. When a signature is required from a group of signatories (e.g., multi-sig) then an MPC allows that compression (using an MPC protocol) for any signature schemes (e.g., ECDSA or EdDSA), whereas contract-wallets (or bundlers) support that for aggregateable signature schemes only (like Schnorr or BLS). On the other hand, the concept of bundlers in the account abstraction standard allows aggregation of signatures for different accounts, which is not supported in MPC wallet. My conclusion is that a combination of both features would be most beneficial for the throughput.
- Multichain support — while MPC-wallets allows access to funds on any blockchain, contract-wallets, not surprisingly, allows access only to the funds on the blockchain over which the contract is deployed. A multichain support is theoretically possible on all EVM-based blockchain by having the use using the same address in all of them,; this, however, requires further exploration on the usability and seucirty implication.
- Wallet separation — contract-wallets are prone to attacks even without their owners being hacked, whereas in MPC wallets one has to gain access to the user’s secret key in order to steal its funds.
- Communication model — while MPC-wallets typically require some p2p interaction between the signatories, contract-wallets aims at removing this and instruct all signatories to interact directly with the blockchain (or, in fact, with the bundlers).
- Signatory’s privacy & anonymity — while MPC-wallets hide the signatories’ identities, contract-wallets operate as a voting box, and have to receive each signatory’s “vote” (signature) individually.
- Modification of signatories’ access structure and policy — these can be done off-chain with MPC-wallets, but with contract-wallets they require an interaction with the blockchain. This point may extend to cyber-security layers: MPC-wallets may designate one party as the one who runs the analytics and make sure that the transaction is not suspicious (e.g., transfer funds to an unrecognized dApp); contract-wallets on the other hand may support it in an inferior way, by which a user-operation is signed and exist in the public realm (the mempool), waiting for an additional signature from the designated party (who runs the analytics). Having a public signed suspicious user-operation may have unexpected ramification.
- Protecting secret key from related nonce attacks — MPC-wallets provide a natural protection from such attacks, by having multiple parties collaboratively generate the nonce of the signature. Contract wallets on the other hand do not offer that level of protection.
- Subsidising transactions, pre-approving transactions — these are features offered exclusively by contract-wallets
Conclusion
As stated above, I believe that both contract-wallets and MPC-wallet should co-exists and be integrated into a holistic wallet solution.
In the next post I will draw some examples of how such integrated contract & MPC solution can be designed.
Stay tuned
Follow on Twitter and Linkedin to get notified in the future!
References
- Ethereum announcement about mainnet deployment of EIP 4337 https://twitter.com/erc4337/status/1631087958949531648?s=46&t=cBE9aOGUq9O_K8jKX4gSsA
- Transaction compression https://twitter.com/johnrising_/status/1631978680754003970?s=46&t=B8EHaPzg_bl-Cig70f79Vg
- Rogue Key Attack implemented for the BLS signature scheme https://medium.com/asecuritysite-when-bob-met-alice/smart-wallet-vulnerabily-using-the-rogue-public-key-attack-56d218f6a31d
- Drijvers attack on presign-supported threshold Schnorr protocols https://eprint.iacr.org/2018/417.pdf
- Marco Macchetti, “A Novel Related Nonce Attack for ECDSA” https://eprint.iacr.org/2023/305.pdf
- Summary of benefits of account abstraction https://twitter.com/hypebymister/status/1632111794528419840?s=46&t=MUHA5kKtoQkfo0FVgX657g
- Vitalik’s first contract-based wallet proposal — EIP 086 https://eips.ethereum.org/EIPS/eip-86
- Account Abstraction standard — EIP 4337 https://eips.ethereum.org/EIPS/eip-4337
Note: This blog post was written by a guest author. We’re featuring this article as part of a new “Research” category on the Secret Network blog, which will explore topics relating to cryptography, privacy, and general blockchain technology. These topics all tie into the research being done for Secret 2.0. If you’re interested in having your own article featured, contact us. You can also join in on the Secret 2.0 discussion on the Secret Discord and Telegram.
If you’re interested in more from this author, the original article can be found here.
Onwards and upwards!
