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.

[rvagg]

How does this work for recursive contract calls? Does the state get flushed at the end with the KAMT of the outer one, and do the inner ones get their own, isolated storage?

[rvagg]

I think this is where my lack of experience with Solidity is showing - do recursive calls count as reentrant in EVM execution such that the same state exists for a contract during its whole lifecycle during message execution? So you don't get a fresh stack when the contract is called again either by itself or another contract within the same message execution?
i.e. when I look at the code, I see it unique by actor and nonce, not anything about the execution frame; is that appropriate for how the EVM works and how this EIP is supposed to work? I can't find any explicit call-outs about it other than the reentrancy lock potential of it so I'm assuming there's just an implicit execution model here that everyone understands.

[snissn]

Thanks for the advice, @Stebalien. I'm revisiting this work after stepping away to focus on other priorities. I’d like to pursue the approach I believe you’re suggesting: using permanent storage along with a top-level origin/nonce tombstone to maintain feature parity with EIP-1153, even though it might not be the most gas-efficient solution.

Proposed Benefits

This approach would allow us to achieve compatibility with Ethereum contracts that rely on transient storage. Additionally, it would provide a path to iterate in the future: if transient storage becomes highly utilized or demanded, we could take on the more challenging task of implementing a more gas-efficient solution.

Technical Details

The proposed changes would involve modifying State to include:

1. Persistent Transient Data
   A Cid variable representing transient data stored on disk. While this implementation persists data (unlike EIP-1153’s ephemeral storage), it maps conceptually to the same transient storage functionality.

   Example:

   Transient Data: cid
   

2. Lifecycle Tracking
   A tombstone-like structure to track the lifespan of transient data, keyed by the transaction identifier.

   Example:

   Transient Data Lifespan Tombstone: {
       Transaction Identifier (origin: ActorID, nonce: u64)
   }
   

The State struct would include these two new variables to support the feature.

Operations

The new operations would include:

• TLOAD (get_transient_storage)
• TSTORE (set_transient_storage)
• clear_transient_data

Operationally:

• TLOAD and TSTORE would work similarly to SLOAD and SSTORE, but with lifecycle checks.
  • Before loading or storing data, the tombstone would be evaluated. If the transient data’s lifecycle doesn’t match the current transaction, the data would be cleared first.
• Lifecycle validation could also be incorporated into the System load method, clearing transient data automatically if the lifecycle has expired.

Downsides

1. Incomplete Clearing
   There’s no straightforward mechanism to fully clear transient data. For example, a contract that uses transient storage once might leave persistent data indefinitely.

2. Increased Storage Requirements

   • Two additional variables in every EVM contract’s State (for transient data and lifecycle tracking).
   • This would increase storage usage and require a migration process for existing contracts.

---

Does this approach sound like a viable way forward for compatibility with EIP-1153? If there are specific improvements or alternative paths you’d recommend, I’d be happy to explore those further. Your insights have been incredibly helpful, and I want to ensure we’re on the right track here.

[Stebalien]

Yeah, it sounds reasonable. Note: I would avoid updating the actor to clear the transient data unless the user is performing some other update/write (unset the transient data field but don't mark the state as dirty).

It would be nice to avoid writing a new object in this case, but designing a way to inline this state is probably more trouble than its worth.

[Stebalien]

I've thought about this a bit more. I think @snissn's current approach is good for now but, if this ever becomes a performance issue, we can optimize it.

Specifically, I'd propose a second wasm memory:

1. When we first call into an actor, we'd create an empty "transient" memory for that actor, scoped to the lifetime of the top-level message. Really, we can make this optional by having actors import this memory if and only if they want transaction-scoped transient memory.
2. Every instance of that actor during that top-level message execution would see the same shared memory.

The tricky part about this approach is resource management. Specifically, this is a resource that's not scoped to the lifetime of a call to a specific actor. I wish we could scope it to the lifetime of the first call (in the call stack) of a specific actor, but the EIP doesn't allow for this (the data must live for the full transaction, regardless).

The only solution I can think of is to limit the maximum memory by gas (similar to Ethereum) instead of by some absolute value (as we currently do). E.g., because the max gas for a transaction is 10B, we could charge 10 gas per byte of transient storage allocated, giving us a max 1GiB of memory used (reset on every transaction). This is how we deal with IPLD data as well (we charge a 10 gas memory retention fee).

[Stebalien]

Note: accessing this memory would be a bit tricky, I'm not aware of any multi-memory aware programming langauges.

Instead, we'd need to:

1. Write a small wasm module (directly in wasm assembly) that provides memory read/write functions.
2. Link this wasm module via FFI calls to our actors.