Already precedented by EIP-7702; pattern was discouraged
Technical Readiness
Aspect
Status
Transaction format
Complete
New opcodes (APPROVE, TXPARAM*)
Complete
Gas accounting
Complete
Mempool rules
Defined in ERC-7562
Reference implementation
Not started
Test vectors
Not started
Security & Open Questions
Known Risks
Mempool DoS: Mass invalidation via shared state. This is mitigated by validation restrictions from ERC-7562.
Open Questions
Paymaster support: paymasters are established under ERC-4337. While this EIP aims to be compatible with them via same mempool rules, it is open question to see that materialize. It will require working through the design with existing bundlers.
One question - does this imply that the plan is to continue down the path of 4337-Bundler-Style restrictions to state access. As I see the DoS mitigation is approached via ERC-7562 and MAX_VALIDATION_GAS.
Is full state access being considered anymore or is it out of scope?
I would say it’s important to make the distinction between what does the protocol allow and what is allowed in public transaction pool. Our aim is to make the protocol maximally flexible, but start small and carefully expand what the public tx pool will allow.
Concretely to your question: full state access before the payer is approved in this proposal, however, you will need to find a builder who will include such a transaction. Our goal is to support self-sponsored transactions in the beginning and over time allow sponsor transactions (or other variants that gain popularity).
4337 already supports full state access via the paymaster mechanism.
A paymaster also serves as a de-facto custom mempool acceptance rule, and the protocol acts as a sort of “meta-mempool-acceptance-rule” where anyone can stake ETH to add their mempool acceptance rule to the list, and if too many transactions pass that rule but do not get included onchain, then it gets throttled and then delisted (as a subjective decision by mempool nodes).
Since 8141 is a modification on 7701, and 7701 is itself an onchain version of 4337, this design can be applied as-is to make a mempool for 8141 transactions.
I will then look into expanding the “paymaster-esque” spec to include a use-case of accessing quite complex arbitrary state for a use-case very important to us commercially. Will open a separate thread for these efforts.
I was wondering about the migrating to a quantum-resistant signature scheme. Can users decide for each transaction with which signature scheme they sign the transaction or can they do a one-way upgrade to a quantum-resistant signature scheme? I was wondering about this because if it is the former, and if there were a quantum adversary, they could choose to sign a transaction with the quantum-vulnerable signature scheme.
Next to that, I was wondering to what extent this proposal hardens existing use cases or creates new ones. For example, what is the impact on users using ERC-4337 paymasters? I’m asking because I’m admittedly not very familiar with what other account abstraction proposals unlock exactly and what the bottlenecks are to increasing their adoption.
Complete
Not started