Transient Storage in Ethereum Smart Contracts
BUILDBEAR // TUTORIALS
Transient Storage in Ethereum Smart Contracts
Solidity released the latest version with support for transient storage (EIP- 1153) as part of the Cancun network upgrade. In this article, we'll dive into transient storage, explaining how it works, and demonstrating its impact through practical use cases.
Contract Storage Spaces in Solidity
Before exploring transient storage further, it’s essential to understand how Solidity handles different storage spaces. Usually, Smart contracts in Solidity use three primary data locations: storage, memory, and calldata.
| Data Location | Description | Usage | Modifiability | Lifetime |
|---|---|---|---|---|
| Storage | Permanently stores data on the blockchain. Accessible by all functions within the contract. | Used for state variables that need to persist. | Read-Write | Persistent (lives on-chain) |
| Memory | Stores temporary data only during function execution. Freed after function execution completes. | Used for temporary variables, function arguments. | Read-Write | Temporary (freed after execution) |
| Calldata | Stores function arguments from an external caller. Read-only and cannot be modified by the function. | Used for external function arguments only. | Read-Only | Temporary (freed after execution) |
What is meant by Transient Storage?
Transient Storage is a new data location as part of EIP-1153. It acts as a temporary storage space during a transaction for smart contracts on EVM-based blockchain networks, helping significantly reduce gas costs.
In simple words, Transient Storage is an empty storage slot, writing a value to it, and clearing it in the same transaction, so we don’t need to write anything to disk.
Key Features:
- Temporary: Data stored in transient storage only lasts for the current transaction and resets afterward.
- Key-Value Store: Functions similarly to persistent storage but without the long-term gas costs associated with it.
- Gas Efficiency: Reduces costs by eliminating the need to modify persistent storage for short-lived data repeatedly.
This makes transient storage a perfect fit for applications where data is only relevant during the execution of a single transaction, such as reentrancy locks, temporary variables in batch transactions, or temporary proxies.
How does it work?
Transient storage is accessible to smart contracts via two new opcodes, i.e., TLOAD and TSTORE, where “T” stands for “transient".
- TSTORE: Assigns a value to a transient storage slot.
- TLOAD: Retrieves a value from a transient storage slot.
Transient storage is also cheaper since it never requires disk access. In addition, it enables cleaner smart contract designs, saves tons of gas, and simplifies the EVM design. It is closer to the machine state than the persistent storage region.
Source: Pascal Marco Caversaccio
Implementation of Transient Storage
The contract "token.sol" is an example of a nice use case of transient storage. This example will show how you can store temporary data (like token details) during a transaction using transient storage.
This example uses this pattern to deploy a token contract:
- first the token name is stored via tempStoreKeyValue();
- then the token symbol is stored via tempStoreKeyValue();
- finally the token is deployed via deployToken().
Note: values can also be erased by assigning an empty value via tempStoreKeyValue(), otherwise they will be erased at the end of the transaction.
To make it more realistic, this contract setup includes a proxy pattern (using OpenZeppelin's TransparentUpgradeableProxy). This lets the contract be upgradeable, meaning we can deploy a new implementation in the future without changing the proxy address.
The contract also checks whether the chain supports transient storage and executes the logic accordingly. If transient storage is available, it uses it. If transient storage is not available, it falls back to regular storage
The example can be run in Remix IDE by creating a Sandbox on Ethereum using the BuildBear plugin. Here’s another implementation for transient storage within a reentrancy lock.
Conclusion
EIP-1153 brings new storage locations for developers to build more gas-efficient dApps by optimizing gas costs in Solidity. This feature is useful in cases where temporary data is required only for the duration of a transaction, such as reentrancy locks, batch transactions, or caching intermediate outputs.
About BuilBear:
BuildBear is a platform tailored for DApp development and testing. Developers gain the freedom to construct a personalized Private Testnet sandbox across a variety of blockchain networks. The liberty to mint unlimited Native and ERC20 tokens, coupled with rapid transaction times on BuildBear (under 3 seconds!), enhances the DApp development lifecycle manifold. The platform comes equipped with tools and plugins designed for real-time testing and debugging, ensuring developers can keep tabs on intricate blockchain transactions with unparalleled ease.
Connect with us on Twitter | LinkedIn | Telegram | GitHub