As the blockchain ecosystem matures, better and more diversified ways of authenticating for blockchain transactions have emerged. This can be quite overwhelming to newcomers, and so this post aims to put order in the following terms:
- EOA
- MPC
- Account abstraction
- Paymaster
- Relay
- Key abstraction
EOA
EOA stands for Externally Owner Account. This is typically the simplest and original form of authentication: An end user creates a unique, secret, private key which can be held in an app (such as Metamask) or better secured on a hardware wallet (such as Ledger). With that private key the user derives or creates an account on the blockchain. All transactions submitted to the that blockchain account, must be signed with the private key.
EOA private keys are often stored as a “seed phrase”: A series of words from which the private key can be derived.
EOA authentication is the only built-in authentication mechanism which most blockchains (including Ethereum) recognize. All the other methods detailed below build on top or around the EOA method in order to provide additional benefits.
.png)
MPC
MPC stands for Multi Party Computation. It is a technology that allows a private key to be split up into parts (shards) such that the holders of several shards can together produce a valid signature of the private key, regardless of which shards are being used. For example, a private key could be split into 5 shards such that any 2 shards could sign a transaction. This would be annotated a 2/5 scheme - 2 signers needed out of a total of 5. Any 2 shards could be used to sign a transaction with the private key.
MPC has many uses - in this article we will consider the case that a private key is sharded and used to control an EOA. This can be very useful for a variety of cases:
- The account is owned by more than one person (e.g. a company) and every transaction needs to be validated by several people
- A user is worried about losing access to their account; they could store additional shards as backups, such that even if one shard is compromised, it will not risk the account being compromised
- One or more of the signing shards would be owned by an automated service that would enforce policies on the account. For example, if an account has $1m in assets, the policy could prevent sending all of that amount, instead allowing only $10k to be sent out on any given day
Examples of MPC-based platforms include Fireblocks, a wallet infrastructure service, and Zengo, a non-custodial wallet.
While MPC is very useful for securing accounts, it still requires all related users to hold a shard with a very specific and technically involved signing scheme. For instance, each of these shards would likely require a “seed phrase” to be memorized and input into an app, in order to sign payloads.
.png)
Account Abstraction
The best user experience for authentication should resemble the one users are already accustomed to. Users typically use usernames and passwords, sign in with Google/Apple, have 2FA (2-factor authentication) methods set up, and more recently leverage passkeys. Account abstraction aims to allow users to continue using all of these options.
Instead of using an EOA account that must use a specific signature, the user could deploy a smart contract that would serve as their account. The smart contract is set up to validate a given authentication, such as sign-in with Google.
Sign-in with Google (and all the other authentication methods) can be used to sign transactions. The smart contract will accept any transaction, verify its signature, and if valid - will execute it.
This greatly improves authentication experience for end-users. However, blockchains like Ethereum do not have a concept of calling externally into a smart contract. There always needs to be an initial signed transaction from an EOA. That EOA also needs to pay the computation fee (”gas”) of the transaction - so account abstraction transactions cannot be submitted from outside the blockchain.
To solve that, we need some service to submit these transactions on our behalf, which we call a relay.
Relay & Paymaster
A relay accepts a transaction and executes it on behalf of another party. Typically, relays will ask for a small fee for that service. The relay usually also want to claim back gas fees, which can be paid back to them by the user, or the user might have a service they top up with gas to be used by the relay for the execution, called a Paymaster.
Two important notes about the operation of relays:
- A relay cannot change the user’s transaction. There is very little risk giving the transaction to the relay, since it is signed by the user. Any attempt to change the transaction will invalidate the signature, and the relay is not able to authenticate with the user’s credentials in order to re-sign the transaction. The only risk a relay can pose is by not submitting the transaction (often called censoring the user).
- A relay can use any EOA to submit this transaction. The EOA itself does not need to be known to the user’s account abstraction contract. That smart contract will accept a call from anyone, as long as a signed payload is provided.
.png)
Key abstraction
A lesser-known concept, but important to understand, is key abstraction. It is an alternative to account abstraction.
While account abstraction is an immense improvement in the UX, it is not very efficient because more processing happens onchain, consuming more gas. Furthermore, some on-chain services, especially on Ethereum, do not work well with account abstraction contracts for technical reasons.
It would have been nice if there was a way to use sign-in with Google (or any other auth method) in order to operate an EOA account. Some newer blockchains actually allow that, but even for the existing ones, there is a solution in the form of key abstraction platforms.
A key abstraction platform will securely store an EOA private key, and only allow access to it via another authentication method (such as sign-in with Google). This means the user authenticates the way they want, and under the hood that signature could be replaced with an EOA-compatible signature in order to submit the transaction.
But how can the a platform “securely store” the EOA private key without risking it falling in the wrong hands?
One way to do that is to use TEE (trusted execution environments). These are containers hosted in a very specific way (such as Amazon Nitro containers) that verify that they match exactly some pre-vetted container image and cannot be changed. The user can then push a private key into such a container as well as whichever other authentication methods they wish to use, and the container, if set up correctly, will perform this service for them, without leaking any other data outside.
Such platforms already exist - such as Turnkey.
Side note: key abstraction is closely related to the terms embedded wallet and wallet as a service. We plan to explore these terms and clarify them in a future post.
.png)
Final word
We hope this article helped clarify the different components from which a blockchain account system could be built. Do notice that these are not “either-or” solutions. In some cases different components can be used together in one solution.
For instance, MPC and key abstraction can be combined in different ways to create different types of products. The shards of an MPC can each be stored in a key abstraction platform, so that the result is an MPC account, but the authentication is done in whatever method the users want. This can be desirable when operating a shared wallet, or when operating a single-user wallet but not wanting to trust a single TEE with a full signing key.
This space keeps evolving and blockchains are building better authentication primitives to allow for better solutions. We will continue to follow the trends and update you!