Update FIP-0097 (Transient Storage): Add Implementation Details, Security Considerations, and Test Cases

[snissn]

Update FIP-0097: Add Implementation Details, Security Considerations, and Test Cases

Summary

This PR updates FIP-0097 to include:

• A new Implementation Details section describing the technical approach for TLOAD and TSTORE.
• Enhanced Specification details with explicit lifecycle enforcement rules.
• Expanded Test Cases covering transient storage behavior across transactions, reentrant calls, and nested contracts.
• Strengthened Security Considerations to ensure isolation, automatic cleanup, and mitigation of reentrancy risks.

These updates clarify the behavior of transient storage (TSTORE/TLOAD) and provide a more robust specification for its implementation in FEVM.

---

Changes in this PR

1. Added "Implementation Details" Section

• Introduces new Rust data structures:
  • TransientData for tracking transient storage state.
  • TransientDataLifespan to enforce transaction lifecycle constraints.
• Defines storage lifecycle enforcement:
  • Ensures transient storage is tied to origin and nonce of a transaction.
  • Implements automatic clearing when a transaction ends.
• Explains handling of reentrant calls and nested transactions:
  • Contracts calling themselves within a transaction retain access.
  • Cross-contract calls do not share transient storage.

2. Modified "Specification" Section

• Enhanced Opcode Descriptions for TLOAD and TSTORE
  • Explicitly states that transient storage is cleared after a transaction.
  • Clarifies stack inputs/outputs and lifecycle behavior.

3. Expanded "Lifecycle Management" Section

• Defines strict enforcement of transient storage expiration:
  • If a new transaction begins, previous transient storage is discarded.
  • Reentrant contract calls access the same transient storage scope.
  • Nested contract calls operate with independent transient storage.
• Specifies that transient storage is managed using StateKamt<U256, U256> to maintain transaction-scoped isolation.

4. Extended "Test Cases" Section

• Basic Functionality Tests

  • Ensure TLOAD retrieves expected values.
  • Validate TSTORE correctly writes to transient storage.
  • Confirm TLOAD from an uninitialized key returns zero.

• Lifecycle Validation Tests

  • Verify that transient storage is cleared after each transaction.
  • Check that reentrant contract calls maintain the same transient storage context.
  • Ensure nested contract calls do not share transient storage.

• Cross-Contract Isolation Tests

  • Deploy contracts A and B.
  • Contract A writes to transient storage.
  • Contract B attempts to access A’s transient storage.
  • Verify that B cannot read A’s transient data.

• Handling of Reverted Transactions

  • Write to transient storage.
  • Trigger a transaction revert.
  • Ensure that TLOAD returns zero after the revert.

5. Strengthened "Security Considerations"

• Automatic Clearing at Transaction End

  • Transient storage resets immediately upon a new transaction.
  • The system enforces reset, even if a contract does not explicitly clear data.

• Cross-Contract Data Isolation

  • Contracts cannot access another contract’s transient storage.
  • Each contract’s transient storage is isolated by its execution context.

• Reentrancy Safety

  • Prevents unintended data persistence across transactions.

[rvagg]

Suggested change

	1. **Automatic Clearing at Transaction End**
	- Transient storage is reset when a new transaction starts.
	1. **Effective Automatic Clearing at Transaction End**
	- Transient storage is reset when a new transaction starts.

not actually cleared at end, but effectively is because it's done before a new one

[rvagg]

very nice; one minor semantic suggestion but otherwise lgtm! Thanks for putting in the work to get this updated.