We want, and maybe need to fully deprecate the legacy transaction types. This is motivated, or potentially required under state expiry. One common objection to this is that there may be transactions that were signed by cold wallets and then put into cold storage to be broadcast at some later time. Similarly, there are hardware wallets that support the current transaction type which may not be updated.
One route to deprecating these legacy transaction types at the consensus protocol level while still retaining support for them would be a precompile. Suppose you have some legacy transaction L. The idea would be that you would wrap it up in one of the new supported transaction types, and then within the EVM send it to the precompile which would handle dispatching the transaction at the EVM level.
This needs to be investigated to see whether it is viable, determine roughly how it would work, and understand any trade-offs that it might have.
We want, and maybe need to fully deprecate the legacy transaction types. This is motivated, or potentially required under state expiry. One common objection to this is that there may be transactions that were signed by cold wallets and then put into cold storage to be broadcast at some later time. Similarly, there are hardware wallets that support the current transaction type which may not be updated.
One route to deprecating these legacy transaction types at the consensus protocol level while still retaining support for them would be a precompile. Suppose you have some legacy transaction
L
. The idea would be that you would wrap it up in one of the new supported transaction types, and then within the EVM send it to the precompile which would handle dispatching the transaction at the EVM level.This needs to be investigated to see whether it is viable, determine roughly how it would work, and understand any trade-offs that it might have.