EIP-1153: Transient storage

Understanding Transient Storage in Ethereum

Definition and Conceptualization:

Transient storage represents an innovative, writable data location within Ethereum’s architecture, characterized by its persistence exclusively for the duration of a transaction. Specific to the execution layer, transient storage will operate similarly to existing storage opcodes in the EVM, but with a key difference: they will be discarded at the end of each transaction, much like how a computer’s RAM is cleared when it’s no longer needed. This temporary nature of data storage offers a significant advantage: post-transaction, there is no requirement for the blockchain to retain this data, thereby eliminating the need for disk storage by nodes. Consequently, transient storage emerges as a cost-effective alternative compared to other traditional storage methods.

Another Type of Storage

In Ethereum, a transaction may involve multiple “frames” of execution. For example, if a transaction calls a smart contract, which in turn calls another smart contract, each of these calls represents a different frame of execution. Currently, communication between these frames can only be done through the EVM’s storage, which is costly in terms of gas. EIP-1153’s introduction of transient storage provides a more gas-efficient solution for this inter-frame communication, as data can be temporarily stored and accessed across different frames within a transaction without the need for costly writes to the EVM’s permanent storage.

Applicability and Utility of Transient Storage

In the evolving landscape of Ethereum transactions, which increasingly involve intricate interactions with multiple contracts, transient storage finds its significance. It is particularly beneficial in scenarios where a contract necessitates temporary data storage in one call frame, to access this data in subsequent call frames within the same transaction.

Illustrative Examples:

• Reentrancy Locks: This involves contracts temporarily storing a flag in one call frame to monitor potential reentries in subsequent frames.
• Token Permits: Commonly utilized for setting allowances within the same transaction, token permits can leverage transient storage for cost efficiency, especially since allowances are reset post-usage.
• Callback-Utilizing Contracts: These contracts can effectively use transient storage for temporarily holding dynamic data required during callbacks.
• State Variables in Multi-Step Transactions: In a contract that involves multi-step processes (like a multi-stage game or a complex financial transaction), use transient storage to hold intermediate state variables that are only relevant within the transaction’s context.
• Voting Mechanisms: In a decentralized voting system, transient storage can temporarily hold votes or tallies that are only relevant for the duration of the voting period, reducing the need for more expensive permanent storage writes.
• Data Passing in Contract Interactions:When a contract calls another contract, use transient storage to pass data between them. This is particularly useful in complex DApps where multiple contracts interact and need to share data temporarily.
• Temporary Data Buffers: Use transient storage as a buffer for temporary data aggregation or computation, such as accumulating values or intermediate results in a contract’s function before finalizing the output.
• Conditional Logic and Checks: In scenarios where a contract must perform checks or conditional logic based on the current transaction context, transient storage can hold flags or data used to guide these conditional paths.

Gas Costs for Transient Storage Operations

EIP-1153, there are two transient storage opcodes: TLOAD and TSTORE. Together they will provide a more gas-efficient solution for inter-frame communication during a transaction by discarding the associated values after every transaction.

TSTORE Operation: 100 gas

TLOAD Operation: 100 gas

These values align with the costs associated with warm and dirty storage operations, providing a balanced approach to gas consumption.

Comparison with Storage

While storage gas refunds, as per EIP-3529 introduced in the London hard fork, partially address similar needs, they are capped at 20% of the total gas expenditure of a transaction. This limitation restricts the effectiveness of refunds for transient storage, especially in transactions with lower overall gas usage. In the current setup, Ethereum uses regular storage for temporary data needs, which leads to unnecessary data reading from the disk. To manage this temporary data, known as ‘transient data‘, the Ethereum Virtual Machine (EVM) offers gas refunds when data stored in a slot is reset to its original value within the same transaction. However, this refund system is complex and unpredictable in terms of gas costs. Developers mostly have to use workarounds, like resetting values to a non-zero ‘dirty’ state, to manage these costs. Additionally, this approach can lead to wasted gas, especially when transactions are reversed or fail.

EIP-1153 aims to simplify this process. By introducing a dedicated transient storage mechanism, it eliminates the need for these complex refund strategies and reduces unnecessary gas expenditure, making the whole system more efficient and easier to work with for developers.

Enhancing Contract Security

The introduction of transient storage is poised to significantly bolster smart contract security. Many contracts currently forgo reentrancy guards due to gas costs, but with transient storage, these protective measures become more feasible. Furthermore, transient storage paves the way for new, more straightforward, and auditable smart contract patterns.

Integration into Smart Contract Languages

Adapting smart contract languages like Solidity to accommodate transient storage can be very straightforward. For instance, Solidity could introduce a ‘transient’ qualifier, akin to its existing ‘memory’ and ‘storage’ qualifiers. This integration is facilitated by the similarity in addressing schemes between TSTORE/TLOAD and SSTORE/SLOAD, allowing for a seamless extension of existing code generation routines to support transient storage.

Advantages of Transient Storage:

• Simplifies EVM Design: Regular storage, which is currently used for transient use-cases, necessitates unnecessary disk reads. Transient storage eliminates this need, streamlining the Ethereum Virtual Machine (EVM) design.
• Complexity Reduction in Refund Logic: The existing refund logic for storage slots is complex and unpredictable in terms of gas accounting. Transient storage simplifies this by removing the need for such refunds.
• Saves a ton of gas: Transient storage significantly reduces gas costs. For instance, a cold read from storage is 2100 gas. A dirty write to storage is 2900. With a cap on refunds, any use of transient storage after the cap will cost the same as using regular storage, ~5000 gas if writing back dirtied values. Without using this dirty value trick, it would cost MUCH more as a clean write to storage is 20,000. Transient storage can save on these costs, especially since the cap on refunds makes regular storage use more expensive.

Impact on Smart Contract Development:

• Enhanced Developer Experience: The introduction of transient storage simplifies smart contract design patterns. For example, using transient storage for re-entrancy locks will be as straightforward as using a transient keyword.
• Forward Compatibility: Contracts developed with transient storage in mind will be compatible with future visions and designs for Ethereum.

A Simple Yet Powerful Upgrade:

The implementation of EIP-1153 has been successfully completed in major Ethereum clients like Nethermind, Besu and Geth. This wide adoption is a testament to its ease of integration and potential impact. Comprehensive tests, both for individual transactions and broader blockchain interactions, have been conducted and are available in the ethereum/tests repository. These tests have been effectively run against the mentioned clients.

Kaif Ahmed