What else can EIP-1153 do besides empowering Uniswap-v4?

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

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

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

Because it requires the introduction of new bytecode in the next upgrade (Cancun upgrade), specifically EIP-1153.

What does EIP-1153 do?#

This is how the official documentation describes it:

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

We know that currently in smart contracts, variables are usually declared and stored in two locations: storage and memory:

Variables marked with storage are permanently stored on the chain and involve the SSTORE and SLOAD opcodes, which consume a lot 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 is essentially a compromise between these two. It modifies the storage variable but then reverts it, so it's as if nothing was changed. Compared to a regular modification of storage, it saves a lot of gas.

It introduces new opcodes: TSTORE and TLOAD. The keyword that the author predicts is "Transient".

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 and saves a lot of gas. The implementation of the singleton contract relies on EIP-1153 to record token balance changes.

Of course, readers need to study how Uniswap-v4 specifically uses EIP-1153 on their own.

Reentrancy lock#

Here, I will introduce a very common use case - ReentrancyGuard.

I believe friends who have some understanding of smart contracts are familiar with "reentrancy attacks," which are a classic attack method in blockchain. ReentrancyGuard is a library introduced by OpenZeppelin that effectively prevents reentrancy.

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 that checks and modifies the value of _status before and after the context to prevent "reentrancy" from occurring.

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

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 perfectly aligns with EIP-1153.

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

Single transaction ERC-20 approval#

I don't know if there are other friends who, like me, were confused when they first encountered Dex and had to approve tokens before swapping. What's even more frustrating is that if the amount you previously approved is not enough, you have to approve again. Keep in mind that every transaction costs money. If you approve too much at once and can't spend it temporarily, there will be security issues (the contract can transfer your tokens). It's a dilemma.

To solve the problem of approving before swapping, the concept of transferFromWithPermit was introduced. It combines approval into the swap process by pre-signing and subsequently verifying the signature, achieving a "one-step" operation.

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

EIP-1153 can bring 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 will be restored in the end. This makes it much safer.

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