Add Support for EIP-1153 (Transient Storage) in the FEVM (FIP-0097)

FIPS/fip-0097.md

@@ -0,0 +1,104 @@
+---
+fip: "0097"
+title: Add Support for EIP-1153 (Transient Storage) in the FEVM  
+author: Michael Seiler (@snissn), Steven Allen (@stebalien)  
+discussions-to: https://github.com/filecoin-project/FIPs/discussions/855
+status: Draft  
+type: Technical  
+category: Core  
+created: 2024-11-19  
+---
+
+# FIP-0097: Add Support for EIP-1153 (Transient Storage) in the FEVM
+
+## Simple Summary
+This proposal introduces support for **[EIP-1153: Transient Storage](https://eips.ethereum.org/EIPS/eip-1153)** in the Filecoin Ethereum Virtual Machine (FEVM). Transient storage provides data storage during transaction execution, scoped strictly to the transaction and the contract utilizing it. To maintain compatibility with Ethereum contracts utilizing this feature, the FEVM will implement transient storage with lifecycle validation and isolation.
+
+## Abstract
+EIP-1153 defines transient storage as temporary data accessible only during the originating transaction, cleared automatically at the end of the transaction. This FIP adapts transient storage to the FEVM using `TLOAD` and `TSTORE` opcodes, ensuring compatibility with Ethereum contracts and libraries that rely on this feature. Transient storage is scoped to the specific contract and transaction, ensuring that each contract’s transient storage is isolated. Nested contract calls cannot access the transient storage of other contracts, but reentrant calls to the same contract within a transaction will access the same transient storage space. Lifecycle validation mechanisms enforce this behavior, achieving functional equivalence with Ethereum’s implementation while maintaining seamless integration with Filecoin’s architecture.
+
+## Change Motivation
+Transient storage offers developers temporary, transaction-scoped storage for managing intermediate states. One key benefit of this feature is its ability to improve the implementation of reentrancy locks, enhancing security by mitigating risks associated with multiple calls to a function within sub-transactions. This feature was introduced on Ethereum mainnet in March 2024 as part of the Cancun (Dencun) upgrade, making adopting this FIP important to align the FEVM with Ethereum’s evolving tooling and Solidity’s modern features. By implementing transient storage, the FEVM ensures a seamless developer experience while supporting advanced contract use cases and secure computing.
+
+While the FEVM implementation utilizes permanent storage for practical reasons, its lifecycle validation ensures it functionally replicates Ethereum’s transient storage. This enables compatibility with contracts and libraries that rely on `TLOAD` and `TSTORE` while supporting transaction-scoped data handling.
+
+## Specification
+
+### Opcode Descriptions
+
+#### `TLOAD`
+- **Opcode Hex:** `0x5C`  
+- **Stack Input:**  
+  - `key`: Location of the transient storage value to load  
+- **Stack Output:**  
+  - `value`: Stored value or zero if no value exists  
+- **Description:** Retrieves the value associated with `key` in the transient storage for the current transaction.
+
+#### `TSTORE`
+- **Opcode Hex:** `0x5D`  
+- **Stack Input:**  
+  - `key`: Location to store the value  
+  - `value`: Value to store  
+- **Output:** None  
+- **Description:** Stores `value` at the specified `key` in the transient storage for the current transaction.
+
+### Lifecycle Management
+Transient storage is valid only within the context of a single transaction. A lifecycle mechanism tracks transaction metadata (`origin` and `nonce`) to enforce lifecycle validation. 
+
+### Implementation Details
+The FEVM implements transient storage using a lifecycle validation mechanism to ensure data remains accessible only during the originating transaction. This validation enforces the same behavior as Ethereum’s transient storage. Internally, transient storage relies on permanent storage to manage lifecycle data and state while ensuring functional adherence to Ethereum’s behavior.
+
+---
+
+## Design Rationale
+
+The design adheres to the intent of EIP-1153 while adapting to Filecoin's architecture. The use of lifecycle validation ensures transient storage behaves as expected within the scope of a single transaction. This approach balances compatibility with Ethereum contracts and simplifies implementation within the existing FEVM architecture. 
+
+Alternative designs, such as purely in-memory storage, were considered but deemed impractical due to technical implementation difficulties.
+
+## Backwards Compatibility
+The addition of transient storage is fully backward-compatible. Existing contracts remain unaffected unless they utilize `TLOAD` and `TSTORE`. Contracts compiled with older Solidity versions will continue to execute without changes.
+
+At the time of writing, support for `TLOAD` and `TSTORE` in current versions of Solidity is only available using inline-assembly. Thus, it is an explicitly opt-in feature, rather than a feature that contract authors may unknowngly be enabling when bumping compiler version and EVM target.
+
+## Test Cases
+
+### Essential Tests
+1. **Basic Functionality:**
+   - Verify `TLOAD` retrieves the correct value.
+   - Verify `TSTORE` writes data to the transient storage correctly.
+   - Verify `TLOAD` from an unitialized location returns the zero value.
+
+2. **Lifecycle Validation:**
+   - Verify that transient storage is automatically cleared and becomes inaccessible after the transaction ends.
+   - Verify that transient storage is properly cleared at the end of each transaction and any out-of-lifecycle data does not interfere with subsequent transaction operations.
+   - Verify that nested contracts have independent transient storage spaces can read and write independently.
+   - Verify that memory remains accessible and stable after contract reentry.
+
+---
+
+## Security Considerations
+Transient storage introduces minimal additional risk compared to existing state storage. Lifecycle validation ensures storage is inaccessible outside the originating transaction. Security measures include:
+- Preventing out-of-bounds memory access.
+- Ensuring transient storage clears properly after a transaction ends.
+- Ensuring nested contracts do not have access to each other's memory spaces.
+
+---
+
+## Incentive Considerations
+By adding support for transient storage, this FIP improves the FEVM's compatibility with Ethereum and provides developers with useful functionality for transaction-scoped data handling. This feature enables capabilities outlined in EIP-1153, such as reentrancy locks, temporary approvals, on-chain address computation, and enhanced proxy call metadata handling. These improvements align with Filecoin's goal of enabling scalable and reliable decentralized applications. However, transient storage does not introduce or impact economic incentives within the network.
+
+---
+
+## Product Considerations
+Adding transient storage ensures compatibility with modern Ethereum tooling, attracting developers to Filecoin’s ecosystem. This feature supports the development of advanced smart contracts and storage-related services. This addition further solidifies Filecoin’s position as a robust EVM-compatible chain, enhancing its attractiveness to Ethereum developers and expanding its ecosystem of decentralized applications.
+
+---
+
+## Implementation
+The reference implementation, including `TLOAD` and `TSTORE`, is available in the following pull request: [filecoin-project/builtin-actors#1588](https://github.com/filecoin-project/builtin-actors/pull/1588). The implementation includes lifecycle validation and persistent backing for ease of use.
+
+---
+
+## Copyright
+Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/).  

README.md

@@ -131,3 +131,4 @@ This improvement protocol helps achieve that objective for all members of the Fi
 | [0092](https://github.com/filecoin-project/FIPs/blob/master/FIPS/fip-0092.md) | Non-Interactive PoRep | FIP | luca (@lucaniz), kuba (@Kubuxu), nicola (@nicola), nemo (@cryptonemo), volker (@vmx), irene (@irenegia), Alex North (@anorth), orjan (@Phi-rjan) | Final |
 | [0094](https://github.com/filecoin-project/FIPs/blob/master/FIPS/fip-0094.md) | Add Support for EIP-5656 (MCOPY Opcode) in the FEVM | FIP | Michael Seiler (@snissn), Raúl Kripalani (@raulk), Steven Allen (@stebalien) | Final |
 | [0095](https://github.com/filecoin-project/FIPs/blob/master/FIPS/fip-0095.md) | Add FEVM precompile to fetch beacon digest from chain history | FIP | @ZenGround0, Alex North (@anorth) | Final |
+| [0097](https://github.com/filecoin-project/FIPs/blob/master/FIPS/fip-0097.md) | Add Support for EIP-1153 (Transient Storage) in the FEVM | FIP | Michael Seiler (@snissn), Steven Allen (@stebalien) | Draft |