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.

[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.