EIP-1153 and Transient storage

Introduction:

Ethereum, hailed as the world computer, has been a beacon of innovation. However, its journey has been marred by challenges, notably the blockchain trilemma and the intricacies of gas fees and data storage.

The Ethereum Virtual Machine (EVM) is a decentralized computer that executes smart contracts. It is a sandboxed environment that ensures that smart contracts can only access and modify their own data, and that they cannot interfere with the operation of other smart contracts.

The EVM has three main storage spaces:

Stack:

The stack is a temporary storage space that is used to store data that is being processed by the EVM. The stack is LIFO (last-in-first-out), meaning that the last item that is pushed onto the stack is the first item that is popped off of the stack.

Storage:

Storage is a permanent storage space that is used to store data that needs to be persisted across transactions. Storage is addressed using 32-byte words, and each word can store any type of data, including integers, strings, and arrays.

Memory:

Memory is a temporary storage space that is used to store data that is being used by the EVM but does not need to be persisted across transactions. Memory is addressed using bytes, and it can be used to store any type of data.
Gas is a fee that is paid to miners to execute smart contracts on the Ethereum network. The amount of gas that is required to execute a smart contract depends on the complexity of the smart contract. The more complex the smart contract, the more gas it will require to execute.

The use of gas helps to prevent the Tragedy of the Commons. The Tragedy of the Commons is a situation in which a shared resource is overused because individuals act in their own self-interest. In the case of the Ethereum network, the shared resource is the computing power of the miners. If individuals were able to use the miners' computing power for free, they would overuse it, which would make it difficult for other individuals to use the network.

Gas helps to prevent the Tragedy of the Commons by charging individuals for the use of the miners' computing power. This discourages individuals from overusing the network, and it ensures that the network is available to everyone.

The way that data is stored in a smart contract is greatly influenced by the cost of gas. For example, storing data in storage is more expensive than storing data in memory. This is because storage is a permanent storage space, while memory is a temporary storage space.

Smart contract developers often use a variety of techniques to reduce the cost of gas.
For example, they may use memory to store data that does not need to be persisted across transactions. They may also use libraries to implement common functions, which can help to reduce the amount of code that needs to be executed.

Ethereum, with its groundbreaking EVM, has been a pioneer in decentralized computation. However, challenges like gas fees and storage limitations have hindered its potential.

Enter EIP-1153, a proposal introducing transient storage, offering a paradigm shift in how data is handled.
This article explores the significance, controversies, and potential impact of this Ethereum Improvement Proposal.

Problems:

1. The problem is that inter-frame communication on Ethereum is expensive. This is because contracts have to communicate with each other by passing data through the calldata, which can be expensive, especially if the amount of data is large. Additionally, re-entrancy guards, which are mechanisms that protect contracts from being attacked by other contracts, can also be expensive to implement.

2. Refunds are capped to 1/5th transaction gas spent since London Hard fork.

3. Storage refunds are not given on Refund. (see EIP - 3978)

4. Reading of disk cannot be avoided. E.g.The node always have to read a “0”value of the reentrancy lock slot from disk.

5. Refund logic is complicated.

6. Transient storage blocks parallelism - Users can't run two transactions in parallel that touches the same contract because the client doesn't know that both transactions fit around parallel because they touch the same storage slot and they have to read from the slot.

Solution:

Transient storage is a solution to these problems. Transient storage is a new type of storage that is only available within a single transaction. It is much cheaper to use than regular Ethereum storage, and it can be used to implement re-entrancy guards in a more gas-efficient way.

Deep Dive into EIP-1153:

The Ethereum Virtual Machine (EVM) operates on the principle of executing smart contracts within the Ethereum network. Smart contracts are composed of bytecode, and their execution involves transactions that can create multiple nested execution frames. These frames are generated by CALL instructions, and if a contract has multiple execution frames, it is considered re-entrant.

Ethereum transactions often create multiple nested execution frames. Communication between these frames, especially when re-entering contracts, faces challenges. Current methods, like inputs/outputs and storage updates, have drawbacks. Transient storage emerges as an efficient and secure solution to inter-frame communication, addressing issues like gas refunds and high costs.

Introduction of Transient Storage:

EIP-1153 proposes the introduction of a new storage space called transient storage.
Transient storage operates similarly to regular storage but is discarded, like memory, at the end of the transaction.

It is comparable to a computer's RAM in that it provides a temporary storage solution during the execution of a transaction.

There are two main motivations for transient storage:

To reduce the cost of inter-frame communication:

When a contract is called by another contract, the two contracts can communicate with each other by passing data through the calldata. However, this can be expensive, especially if the amount of data is large. Transient storage provides a cheaper way for contracts to communicate with each other.

To reduce the gas cost of re-entrancy guards:

A re-entrancy guard is a mechanism that protects contracts from being attacked by other contracts. Transient storage can be used to implement re-entrancy guards in a more gas-efficient way.

How Transient Storage Works

Transient storage is implemented using two new opcodes:

TLOAD and TSTORE.

TLOAD is used to load data from transient storage, and TSTORE is used to store data in transient storage.
To use transient storage, a contract first needs to declare a transient variable. This can be done using the transient keyword. Once a transient variable has been declared, it can be used like any other variable in the contract.

The data in a transient variable is only available within the current transaction. After the transaction is completed, the data in the transient variable is deleted.

Gas Cost Efficiency:

The gas cost for invoking TSTORE and TLOAD is approximately 100 GAS each, making them significantly cheaper than the original storage operations (SLOAD and SSTORE).

Communication Between Execution Frames:

Multiple nested execution frames:

An execution frame is a stack frame that is used to execute a function. When a smart contract is called, a new execution frame is created. The execution frame contains the local variables and parameters for the function that is being called.

Multiple nested execution frames can be created when a smart contract calls another smart contract. For example, if contract A calls contract B, and contract B calls contract C, then there will be three nested execution frames: one for contract A, one for contract B, and one for contract C.

Communication methods using calldata and storage updates:

There are two main ways that execution frames can communicate with each other:

Calldata:

Calldata is a temporary storage space that is used to pass data between smart contracts. It is addressed using bytes, and it can be used to store any type of data.

Storage updates:

Storage is a permanent storage space that is used to store data that needs to be persisted across transactions. It is addressed using 32-byte words, and each word can store any type of data, including integers, strings, and arrays.
Elaboration

When a smart contract calls another smart contract, it can pass data to the other smart contract using calldata. The other smart contract can then access the data in calldata by using the CALLDATA opcode.

Smart contracts can also communicate with each other by updating storage.
For example, a smart contract could store a variable in storage that is used by another smart contract. The other smart contract can then access the variable by using the SLOAD opcode.

Communication challenges

There are a number of challenges associated with communication between execution frames.

For example:

Calldata can be expensive. The amount of gas that is required to pass calldata between smart contracts depends on the amount of data that is being passed. If a lot of data is being passed, the transaction can be very expensive.

Calldata can be manipulated. An attacker can manipulate calldata to change the behavior of a smart contract.
For example, an attacker could change the value of a parameter that is being passed to a smart contract.

Storage updates can be expensive. Updating storage is one of the most expensive operations on the Ethereum network. This is because storage is a permanent storage space, and updating it increases the size of the Ethereum state.
It can be difficult to coordinate communication between execution frames. This is because execution frames are isolated from each other.

Potential Use Cases:

Reentrancy locks:

Efficiently manage and communicate reentrancy lock states.

On-chain computable CREATE2 addresses:

Constructor arguments read from the factory contract instead of being part of init code hash.

Single transaction ERC-20 approvals:

Streamlined approval in a single transaction.

Fee-on-transfer contracts:

Pay a fee to unlock transfers for the duration of a transaction.

Reading constructor arguments from msg.sender:

It is a technique that can be used to save gas when deploying smart contracts. It works by storing the constructor arguments in the msg.sender variable, which is a global variable that contains the address of the account that is currently deploying the contract.

To read constructor arguments from msg.sender, the contract can use the CALLDATA opcode to access the calldata. The calldata is a temporary storage space that contains the data that was passed to the contract when it was deployed.

Use case in Uniswap V3:

Uniswap V3 uses transient storage to store the constructor parameters of a pool so that the pool init code is always the same, rather than passing the constructor arguments as part of the init code. This makes it cheaper to compute the pool address on-chain.

To do this, Uniswap V3 uses the following steps:

1. The pool parameters are stored in transient storage
2. The pool init code is generated from the pool parameters.
3. The pool is created using the pool init code.
4. The pool parameters are deleted from transient storage.
5. The pool init code is a piece of code that is executed when the pool is created. It is used to initialize the pool state.

"Till" pattern:

Perform all actions as part of a callback, ensuring balance at the end.

Proxy call metadata:

Pass metadata to an implementation contract without using calldata.

Arbitrum uses it for L2-to-L1 outbox:

They use transient storage to represent the L2 state when executing an L2 message on L1. This means the arbitrum contract doesn’t have to assume any interface of the L1 contract, it can make any arbitrary call, but the L1 contract also has access to the L2 state from the call.

Specification:

Introduces two new opcodes:

TLOAD and TSTORE.

(Operate similarly to SLOAD and SSTORE but are more efficient)

TLOAD pops an address from the stack, fetches from transient storage, and pushes the value.

TSTORE pops an address and a value, storing the value in transient storage at the given address.

Gas costs for TLOAD and TSTORE are lower than SLOAD and SSTORE.

Transient storage is private to the owning contract, discarded at the end of the transaction.Accessible only by the owning contract's frames.

Rationale:

Transient storage provides a more gas-efficient solution compared to repricing SSTORE and SLOAD.
Separating refund counters for transient storage avoids complexity and encourages efficiency.
The word-addressed storage-like interface is preferred for its compatibility with mappings and transaction-scoped memory.

Backwards Compatibility:

Requires a hard fork but is backwards compatible with existing smart contracts.
Does not change the behavior of existing opcodes.

Pros and Cons:

Pros:

Addresses transient usages without changing existing contracts.
New concepts are considered separately in protocol upgrades.
Clients do not need to load the original value, simplifying gas accounting rules.

Cons:

Requires new code in clients and updates to the yellow paper.
Does not address transient usages in existing contracts.
New concept for the yellow paper.

EIP-1153 introduces a transformative approach to inter-frame communication in Ethereum. By mitigating gas inefficiencies and providing secure and private transient storage, this proposal has the potential to enhance various aspects of Ethereum, from reentrancy locks to streamlined ERC-20 approvals. The proposal reflects a meticulous consideration of Ethereum's evolving needs and sets the stage for a more efficient and secure smart contract ecosystem.

Transient storage is a powerful tool that can be used to reduce gas costs and improve the performance of smart contracts. It is important to note that transient storage is still under development, and it is not yet available on all Ethereum clients. However, it is expected to be widely adopted in the near future.

Read similar posts

• EIP - 4844 Shard Blob Transaction in Ethereum

• Eip - 5656 Mcopy an Efficient EVM instruction

• Censorship Resistance vs Scalability

• Ethereum Layer 2 Projects

• scroll-successfully-launches-mainnet-for-zkevm-boosting-ethereum-scalability

• Solutions to Scalability: Can Off-Chain Payments Scale Blockchain?

• what-is-sharding-and-why-is-it-important

• ethereum-updates-q4-round-up-scalability-r-d-subsidy-programs-website-redesigning-eth-recorded-new-all-time-high