Network Fees

When we talk about the singleton pattern, we must first understand what problem the singleton is important to solve. This problem is network fees. There is no need to go too deep into the opcode pricing table and distinguish between calldata and storage. We only need to remember one fact: cross-contract calls are expensive and writing data is expensive. For example, if we observe a uniswap v2 routing transaction of user->A->B->C, how many contracts do we need to access? For users who just want to complete the A-C exchange, let's calculate together:

  1. router contract

  2. User A's assets are reduced and changed. You need to register with the A token contract and write the new balance.

  3. Call pairA->B

  4. The B asset of pairA->B is transferred to the user user address. You need to register the transfer in the B token contract and write the new balance.

  5. The B asset of pair B-C increases, and the user's asset decreases. Register it in the B token contract.

  6. Call pair B -> C

  7. In pair B -> C, C's assets decrease, and B's assets increase

In addition to the router call to transmit the exchange information, there are 6 other calls: two pair calls and 4 token settlements. The singleton is to solve these six calls. Is there a chance to reduce them?

pool is no longer an address

In v2 and v3, a pool is a smart contract created by a factory contract. It contains liquidity data and an interface responsible for transactions. In v4, multiple pools are stored under the pool manager. When we construct a new pool, we do not construct a new smart contract, but add some data under the pool manager.

From the perspective of traditional software engineering, such a design has severe coupling, and it is not good to put all the code functions into one file/smart contract. But for the ruthless gas pricing program, this can save a lot of gas, which is a good design.

But there is an obvious problem with this. Originally one pool managed two assets, but now one pool manager manages countless assets. How can I figure out which pool the 10 A tokens in my account belong to? This is also related to the next question.

From the market to the casino

Let's go back to the question of 7 calls. We only explained why the singleton can solve the pair call. For the V2 V3 model, it is more like buying vegetables in the market. Every time we swap, we have to pay for the goods. Then we go to the next stall to sell different vegetables. But for Ethereum's ERC20, the action of paying for the goods requires a handling fee.

In real life, we have another way to manage multiple stalls, which is casino chips. Chips can be cleared at the entrance and exit. As for how individual users lose or earn, the waiter in charge of the exchange does not care. We only clear at the entrance and exit, and the wins and losses in the middle do not need to be reported to the bank system to transfer assets. In the v2 v3 vegetable market model, we paid eth to write each settlement into the blockchain, which is naturally expensive. Of course, this is not a new solution, it is the CEX solution we are familiar with.

But compared to CEX, a smart contract chip liquidation solution has additional advantages: if we are more extreme, if we win 10 U chips at the A stall, but the casino goes bankrupt while you are running to the front desk to liquidate, then our money is gone. Not your key, not your money. But dex is different, you become the Flash, and a lot of swap operations are run in the structure of an on-chain transaction. You will run the deposit, exchange chips, exit, and exit settlement at the speed of light but in order. The backward single thread of evm protects you from running and running fast. Of course, our anxiety is unnecessary. A decentralized exchange will not go bankrupt. The more important advantage is that this transaction can be linked to other DeFi. Although there are many businesses, it is still a link in the Defi lego world.

We have basically explained how the singleton solves the 7-call problem we mentioned. As for how the chips are accounted for and why everyone is still talking about double-entry bookkeeping, this part requires in-depth code discussion. Let's skip it for now. Let's review the routing transaction of uniswap v4 from user->A->B->C:

  1. Calling the router

  2. outer looking for pool manager

  3. Exchange chips

  4. Go to the pool manager to find the internal location of the pool

  5. trade

  6. Repeat steps 2/3 twice

  7. Exchange chips

So how many contracts did we call this time? 4. Router, pool manager, tokenA, token C. We used the pool manager to avoid two extra pair calls and two token b accounting.

HOOK

A pool has the following eight points (v4-core/contracts/interfaces/IHooks.sol):

  • beforeInitialize / afterInitialize(before/after the state of a pool is initialized).

  • beforeModifyPosition / afterModifyPosition(The hook called before/after a position is modified)

  • beforeSwap / afterSwap(The hook called before/after a swap)

  • beforeDonate / afterDonate(The hook called before/after donate)

At these 8 points, the creator of the pool can insert his own code. Note that users can choose to register the time and method they expect to use in the behavior specified by the hook. When triggered by others, such as after other users trade, users can passively execute the code. Note that the right to define the hook lies with the builder of the pool, not the users of the pool. Of course, users can vote with their feet to choose the one they like.

I deliberately use a very abstract rather than a very specific description here, because being too specific will limit the imagination. We will give a specific example soon.

After we further study the code, we need to pay attention to the following points:

  1. To construct a pool, you need to specify the hook.

  2. There is no subsequent modification method for hook. Pool is bound to hook. Of course, hook can also be an upgradeable contract.

  3. If you want to make a hook that meets your needs, you need to construct a new pool

  4. The only difference is the hook. The same trading pair can have multiple pools.

The official website provides several examples, among which the most interesting one is the hook for the current price order. In fact, you don’t need to look at the code. The limit order does the following things

To manage user registration:

  • place order

  • kill

  • withdraw

Management time point:

  • afterswap: After being triggered, check whether there is an executable limit order or fill order.

That’s all there is to the limited order hook.

We believe that hook is just a way of describing business. If the business you want to do can be decomposed into user behavior registration and passive triggering of behavior at a certain point in time, then your business can be migrated to uniswap v4. It can be a limit order or a time-weighted AMM.

From this perspective, we can fully handle the business and not be limited to trading scenarios. Lending, options, stablecoins, and NFTs can all be reconstructed with hooks. Swap handles instantaneous business, and ModifyPosition handles cross-period business. What the swap exchanged and what the modifiyposition did is actually not that important.

Here I make up a hook as an example: the function is that through the hook, I can keep my assets in it and not rush to exit the uniswap low-fee platform.

1. Manage user registration

  • Mint/burn will construct unilateral liquidity and deposit assets in the form of lp

2. Management timing

  • Before swap, create a huge advantage, or use high dynamic fees to prevent ordinary users from swapping

Then no traders will come to my pool, which is a static fund pool. My assets are temporarily stored in Uniswap in the form of LP, and I can withdraw them later for other transactions. This reduces the number of liquidations.

Rewriting the business with hooks is a definite direction. In order to ensure long-term competitive advantage, uni's grant support will also be much stronger.

There are already some projects ready to go, waiting for v4 to be launched. For example, the following lending protocols will be launched together with uniswap v4.

What is Uniswap v4?

For v4, we make two comparisons blindly:

uni v4 and layer 2:

• Same point:

  1. Low handling fee advantage

  2. eth ecosystem compatibility

• difference:

  1. v4 project needs to rewrite using hook method

  2. Enter a low-fee environment in one transaction and then return to the eth mainnet to call other mainnet services

  3. No cross-chain bridge required

Uni v4 and Cloud Exchange:

• Same point:

  1. Open a pool together and share a low-fee environment

  2. Shared Liquidity

• difference:

  1. v4 does not limit the business type, not necessarily an exchange

  2. v4 Shared liquidity needs to be outsourced to good routing providers

  3. v4 No access

We believe that Uniswap v4 should be defined from the perspective of the platform. When the critical point is reached, under the pressure of ETH fees, v4 may be a better solution than layer2, and more financial businesses will actively or passively migrate from the main network to the Uniswap v4 platform. In particular, financial businesses are relatively uncomplicated, but have higher security requirements. They can be withdrawn from the ETH main network in a flash, alleviating the urgent needs of the ETH main network. From this perspective, Uniswap has won the DEX war, and V4's competitors are platform-level competitors such as CEX Cloud Exchange and MATIC.

So what is the cost?

  1. Liquidity tokens: There are no liquidity tokens. In other words, this accounting unit cannot be separated from the scope of Uniswap, and the project side must solve the problem in the Uniswap v4 ecosystem.

  2. Liquidity fragmentation: v3 has three different fee pools for one asset pair, while v4 is completely different, which requires higher management of routers and makers. The solution to this problem depends not only on market competition but also on whether the Uniswap community can come up with some standardized solutions, U (Uniswap) RC.