Add a new transaction Type that allows adding optional capabilities without defining the new tx type. Composable tx is based on EIP-1559 transaction.
Introduces a signature type so a new signature can be extended from it.
First example of a capability specified in EIP is the paymaster, where someone else can pay for sender fee.
EIP link: https://eips.ethereum.org/EIPS/eip-8175
(Link does not work yet)
Merging it soon™ , until that here is PR Add EIP: Composable Transaction by rakita · Pull Request #11355 · ethereum/EIPs · GitHub
Is cleaning up old signature schemes feasible with this transaction format? At the very least, we must ensure users have a safe exit path to new signature schemes before eliminating weaker schemes like ECDSA but still ensure that client-side removal does not cause enforcement conflicts on the network.
I dont totally understand you here, can you clarify more simply what do you mean by safe exit path, and client side removal does not cause enforcement conflicts?
You can have new sig type it can be anything you want.
What I mean is that these new signature schemes must have corresponding code added to the client for authentication, such as ED25519. The question is whether its code can be easily removed after most users have switched to a new signature schemes; otherwise, it will remain permanently in the client codebase, increasing the long-term maintenance burden, similar to CALLCODE. EIP-8141 may be more complex in initial implementation, but in the long term, we won’t be creating additional burdens in the client code because we may not need to add new signature schemes.
@Helkomine you could deprecate a particular signature type, simple as that.
EIP-8141 introduces unnecessary complexity.
I have a lot of experience maintaining clients. Long term maintenance burden is a lot smaller on something simpler than on something complex and more abstract.
@rakita, may I ask you to say a few words on EIP-8175 in Post Quantum migrations, Crypto-agility and how to prevent EIP-7932 from failing.
I am aiming for EIP-7932 to be the native registry for signature algorithms so EIPs such as EIP-8175 can plug into the registry without having to deal with signature formatting, malleability concerns (e.g. EIP-2 and low s) nor dealing with quirks of certain algorithms.
I am soliciting feedback from other developers / EIP authors on how to ensure that EIP-7932 is as flexible as possible to make integration with proposals like this seamless.
But we need to consider the legality of removing signatures from the protocol level and the post-quantum risks in the reverse direction.
@Helkomine sure, but i dont really follow you here, it feels that this discussion is out of scope of this EIP.
If you give me how you want to do it, impl with signature type is flexible enough to have simple implementation of it, that is main point of composable transaction.
For example. If signature type 0 is disabled (current signature), we can introduce new type 3 sig that is going to have transition from current signature to some version of pg sig. So concrete protocol is needed but this is out of scope for both composable and frame tx.
Each Ethereum upgrade has introduced new transaction types for new capabilities: EIP-1559 for priority fees, EIP-4844 for blobs, and EIP-7702 for authorizations. Both EIP-4844 and EIP-7702 extend and reuse mostly the fields from EIP-1559, yet each required an entirely new transaction type. This leads to combinatorial growth: new features cannot be combined across types. This EIP proposes a single extensible transaction format where new capabilities are added as typed capabilities, allowing future enhancements without new transaction types.
I don’t think we should call this “combinatorial growth”: Ethereum has always added 1 transaction type at a time, so it is linear growth. Combinatorial suggests that the factorial operator is at play.
The current practice here is that each new transaction type has all the fields of the previous one, and it’s trivial to set them to a neutral value in order to disable the functionality. The one exception is EIP-4844 transactions, which branch off from EIP-1559 because blob posters are highly specialized entities that won’t need to post delegations or get sponsorship. (my interpretation)
By contrast, code that implements capabilities according to this EIP could exhibit state explosion since any combination of capabilities could be present, meaning a lot of branching and variables are required to track what’s actually in the transaction. As such I think this argument is misplaced and a simpler, dumber design would actually be safer.
Transaction sponsorship — where a third party pays gas on behalf of the sender — has been a long-sought feature. EIP-8141 proposes a powerful but complex solution using execution frames, new opcodes (
APPROVE,TXPARAMLOAD), and per-frame gas budgets. This complexity raises the implementation burden on all clients and increases the attack surface.
If we are talking solely about an EOA serving as the sponsor, this EIP successfully provides gas sponsorship. However, in EIP-8141 and ERC-4337, the sponsor should be able to be a paymaster contract that e.g. swaps tokens for ETH on demand. See 💰 Paymasters - ERC-4337 Documentation. It’s not clear that this EIP helps a lot with implementing such flows.
Let’s say we are the sponsor and we want to get reimbursed atomically onchain: we should examine transactions that senders submit to us and sign them only if we expect them to reimburse us when executed. However, since there’s presumably only one “frame” in the transaction which is a call from the sender to their intended smart contract, senders can’t really build their transactions in such a way that we also get paid. By contrast, ERC-4337, possibly combined with EIP-7702, already enable this flow in production today. So does EIP-8141.
Let’s say instead we don’t require atomic payment because the user paid in advance. In that case, we could use EIP-7702 to upgrade the user’s EOA, and then have the sponsor account initiate the transaction directly. This is something AA providers already do today without this EIP.
Could it be that the real benefit of this EIP to enable native support for different signature types, with Ed25519 as a first example? I don’t want to assume your intentions but that seems like that’s the best argument for adopting it.