EIP-1153, besides empowering Uniswap-v4, what else can it do?

In June 2023, a blog post released by the official Uniswap website attracted the attention of everyone in the cryptocurrency community. After the launch of Uniswap v3 two years ago, v4 is finally coming!

With significant gas optimization and a new Hook gameplay, Uniswap further solidifies its leading position in the decentralized exchange (Dex) field.

However, as of the writing date in October, it has still not been launched. Why is that?

It is because it requires the introduction of new bytecode in the next upgrade, known as EIP-1153.

What does EIP-1153 do?#

According to the official description:

Add opcodes for manipulating state that behaves identically to storage but is discarded after every transaction.

Currently, in smart contracts, variables are typically stored in two locations: storage and memory.

Variables marked with storage are permanently stored on the blockchain and involve the SSTORE and SLOAD opcodes, which consume a significant amount of gas.

memory is used for variables declared temporarily within a function and is released after use (when the function execution ends). It consumes less gas but is only visible within the function.

EIP-1153 aims to provide a compromise between these two by modifying storage variables but then reverting them, effectively making no changes. This saves a lot of gas compared to regular storage modifications.

It introduces new opcodes: TSTORE and TLOAD, and the keyword "Transient" is predicted by the author.

Significance#

What benefits does this mechanism bring?

In Uniswap v4, the Factory-Pair pattern is abandoned, and all token pairs are placed in a single (singleton) contract. This eliminates the need for cross-contract calls, resulting in significant gas savings. The implementation of the singleton contract relies on EIP-1153 to record token balance changes.

Of course, readers need to study how EIP-1153 is specifically used in Uniswap v4.

Reentrancy lock#

Here, the author introduces a common use case - ReentrancyGuard.

Reentrancy attack is a classic attack method in blockchain, and ReentrancyGuard is a library introduced by OpenZeppelin to effectively prevent it.

Let's take a look at its core code:

uint256 private constant NOT_ENTERED = 1;
uint256 private constant ENTERED = 2;

modifier nonReentrant() {
    _nonReentrantBefore();
    _;
    _nonReentrantAfter();
}

function _nonReentrantBefore() private {
    if (_status == ENTERED) {
        revert ReentrancyGuardReentrantCall();
    }
    _status = ENTERED;
}

function _nonReentrantAfter() private {
    _status = NOT_ENTERED;
}

It does a simple thing: it introduces a "lock" mechanism to check and modify the value of _status before and after the context, preventing "reentrancy" from occurring.

So why use 1 and 2 to differentiate instead of True and False? It is to save gas, and you can refer to WTF-Academy for more details.

However, we can notice that in nonReentrant, the initial and final values of _status are the same, so it remains unchanged after the process, which aligns with EIP-1153.

Therefore, after the Cancun upgrade, a new version of ReentrancyGuard that saves more gas will be available, or it may not require a separate library and can be implemented with just a few lines of code. This will allow most DeFi contracts to save more gas.

Single transaction ERC-20 approval#

I don't know if there are other people who, like me, were confused when first encountering Dex and had to approve tokens before swapping. It is even more frustrating that if the previously approved amount is not enough, you have to approve again. Remember, each transaction requires payment. If you approve too much at once, there may be security issues (the contract transfers your tokens). It's a dilemma.

To solve the problem of approving before swapping, the concept of transferFromWithPermit was proposed, which combines approval into the swap process through pre-signing and subsequent verification, achieving a "one-step" operation.

But there is a problem. What if I sign the approval but the tokens are not used and I change my mind? What if the signature is stolen and exploited by malicious actors?

EIP-1153 introduces temporary approval, which means that I approve at the beginning of the transaction, and after a series of operations, regardless of whether those tokens are used or not, they are restored in the end. This provides much more security.

In the future, there may be new ERC-20 extensions for this feature, which will likely also provide some help in abstracting AA (Autonomous Account) accounts.