Image by Ideogram
Elliptic curve cryptography (“ECC”) will likely be made obsolete within the next decade because of the expected advancements in quantum computing (or possibly through advancements in artificial intelligence).
Most blockchains will need to fork their code since the use of ECC is integral to their inner workings. Hard forks are anathema to most blockchain purists and developers, to the point where entirely new chains have been created as a result (Ethereum Classic, Bitcoin Satoshi’s Vision, Bitcoin Cash to name a few).
But with the quantum risk, there is really no choice but to hard fork. Some may choose to stay with the original fork, especially if they do not believe that the threat is real. There could even be multiple forks if consensus cannot be reached on what cryptography should be used to replace ECC. But there will certainly be forks in the coming years.
Hard forks are disruptive and difficult to execute; for these reasons they are heavily avoided. But cryptography does not last forever. Weaknesses can be found and mathematical assumptions can change.
Replacing the cryptography used in blockchains will unfortunately become the new normal, although it wouldn’t be that frequent, perhaps every few decades.
EIP-8141, also known as “Frame Transactions”, will reduce that need to regularly replace the cryptography since it removes the system-defined cryptography and instead introduces user-defined cryptography.
Frame transactions will allow you the user to decide who can authorise a transaction and how it is validated. It will be a new transaction type that includes a “frame” which defines the authorisation, validation, and execution. It decouples signature verification from execution, allows custom validation rules, and enables delegation of authority.
In short, frame transactions will allow an account owner to choose their preferred cryptography.
As I have written in the past, there are a few options available for post-quantum cryptography. With Ethereum, Dilithium (ML-DSA) is the favourite but there are still some that prefer Falcon (FN-DSA) because it has slightly smaller keys and signatures and it is possible to extract the public key from a Falcon signature. There are also some hash-based approaches still in consideration even though their signature sizes are still very large.
With Frame transactions, it will be up to the account holder to decide which method to use. They may even decide to hedge the risk by holding multiple accounts that each use different cryptographic algorithms. That way, if a weakness is found in one algorithm, they could quickly migrate assets to a different account.
Frame transactions will also allow batching of transactions which means for DeFi transactions a user can submit any required approval with a DeFi transaction in one frame.
Ultimately, frame transactions will introduce native account abstraction to Ethereum.
To understand how, we need to take a step back and review how ERC-4337, otherwise known as account abstraction works.
With account abstraction, there is an entry point contract, a smart account contract, a bundler service, and an optional paymaster contract. The method of transaction validation is defined in the smart contract and can only be executed by the entry point. This is why post-quantum cryptography can be introduced in Ethereum now without any forking.
The bundler service is how a transaction gets accepted into an Ethereum block. The bundler service receives user operations which are instructions from the account owner for executing a transaction in the smart account.
Image by Ideogram
Bundlers will validate the user operation and then wrap it in a signed transaction that is submitted to the mempool for a validator to accept into a block. User operations do not have their own mempool in Ethereum, some chains do have a user operation mempool; well, there is technically a mempool for user operations but that is still in early stages and is managed by a consortium of bundler services.
The paymaster, if defined, refunds the bundler for the cost of the submitted transaction (where an additional amount may be paid to the bundler to cover the cost of validating the user operation prior to submission).
While account abstraction enables quantum-resistant accounts today, the bundlers are still using ECC when they submit the transaction; this means that there is still an exposed vulnerability (although the worst an attacker could do is drain the bundler of ether and inhibit the ability of an account owner from submitting their instructions).
Frame transactions remove the need for the bundler service. The account owner can submit their instructions directly wrapped in a frame that indicates the validation method to be used (such as Falcon signatures). The frame can also include paymaster details so that accounts using this model can be gasless just like with account abstraction.
By removing the bundler service and allowing account owners to submit their instructions directly to the mempool, frame transactions will introduce the equivalent of native account abstraction. I say equivalent because it will be better. Most implementations of native account abstraction use a dedicated mempool for user operations, frame transactions extends the ability into the existing transaction mempool.
An account owner will also be able to change their validation method. So they can start with Dilithium or Falcon but then replace the validation in the future if a stronger algorithm is published or if a vulnerability is discovered in any of the post-quantum cryptographic algorithms.
That means all accounts will have the ability to be cryptoagile. Frame transactions can even be used to update existing externally owned accounts to user-defined validation. This means that you can keep your existing wallet’s address while updating the validation to something much stronger.
Unfortunately, this is not really true for any existing account abstraction implementations since they are designed for bundlers and entry points; they cannot be migrated because the validation is coded into the smart account so a migration would result in double validation (first the frame, then internally in the smart account transaction) which is a waste of gas. Presumably the use of ECC to sign transactions will be removed by 2029 and replaced with a PQC method so bundler services will continue to be available and will have to adapt.
There is no timeline on when frame transactions will be introduced to Ethereum, the best estimate is by the end of this year. The details are still being finalised and any working implementation is probably still 2 to 3 years away at least.
What this means is that anyone who wants a quantum-resistant wallet now must use account abstraction with a bundler service. When frame transactions become available, they would then have to decide to either create a new smart account that is frame compliant, or continue to use a bundler service. Bundler services represent a potential centralisation risk but it is also possible to “self-bundle” (but that is a topic for another day).
With the introduction of frame transactions, native account abstraction will be possible on Ethereum which removes the only point of centralisation with account abstraction, the bundler service.
More importantly, frame transactions means that the validation used for accounts can evolve over time and reduce the need for future forks.
Frame Transactions will Introduce Cryptoagility to Ethereum was originally published in Coinmonks on Medium, where people are continuing the conversation by highlighting and responding to this story.