EIP-1153: Transient Storage

[Stebalien]

EIP-1153 is adding support for "transient storage" to the EVM. To maintain compatibility, we'll need to make these opcodes available from the EVM actor (FEVM).

We have two possible paths:

1. Use permanent storage, but record the top-level origin/nonce the same way we do in the SELFDESTRUCT tombstone. That way, we can detect if the values stored are "alive".
2. Introduce some form of real transient storage.

The second option is more interesting and has no obvious solution:

1. We could introduce a second (transient) state-tree per actor. This has the upside of re-using all of our current logic/paradigms, but it also introduces hashing/serializing overheads that aren't really necessary. It'll also be harder to charge less for storage in this case.
2. We could, alternatively, give every actor access to its own "environment", some form of map from 32byte keys to... IPLD blocks and/or arbitrary blobs? This would be more efficient, but also introduces an entirely new concept.

I don't have a real solution here, but we should get this discussion started regardless as the EIP is supposed to land in the next Ethereum network upgrade (Dencun).

[snissn]

Hi @Stebalien, I’ve been exploring ways to implement EIP-1153’s transient storage in the FEVM, focusing on the builtin-actors repository. I’ve drafted a preliminary plan that outlines an approach using a transient_storage field in the System struct, scoped to a single transaction’s execution context and accessible across nested calls.

My plan aims to create a temporary storage structure similar to Memory, which is cleared at the end of each transaction but persists within the transaction’s lifecycle, including across call, delegatecall, and create operations. A key point I’m considering is the lifecycle of the System object to ensure consistent transient_storage access.

Here’s the full proposal for your review: Transient Storage Implementation Plan Proposal

Any feedback would be greatly appreciated!

[Stebalien]

System, and everything inside the actor, is private to that actor (stored in wasm memory). Furthermore, every recursive call back into the same EVM contract gets a new System.

The only shared state that exists at the moment is https://github.com/filecoin-project/builtin-actors/blob/ca31c6099ccb31fc48e1707df19ace6f12e5429b/actors/evm/src/state.rs#L95-L130 and it's shared because it's written to the blockstore.

which is cleared at the end of each transaction but persists within the transaction’s lifecycle

Note: this data needs to be available to this actor for the entire transaction, so there's there's no clear place to clear it.