Part 1. Changes to Factory Structure (Singleton Contract)
UniswapV2 and V3 operate by creating numerous child contracts (Pairs) through a primary contract (Factory). The Factory records minimal information about the Pairs, does not engage in internal swap transactions, and does not hold any tokens.
In V2, the Factory holds basic information, such as the addresses of Pairs and the tokens involved in each Pair. In V3, the Factory keeps slightly more complex information, such as the Pair's address, fee rate, and type of tokens involved.
In V4, the pattern changes. V4 conducts specific swap activities within the main contract (Manager Singleton) and holds various tokens like USDT, WETH, etc., instead of Pairs holding them.
In V2 and V3, if users wanted to perform multi-hop transactions, such as WETH->USDT->USDC, they would need an additional contract (Router contract) to ensure all transactions are completed within one transaction and can rollback all transactions in case of excessive slippage or other unmet trade conditions (atomicity of transactions).
However, V2 and V3's approach leads to additional costs as in these transactions we effectively deposit various tokens into different Pairs. Taking the WETH->USDT->USDC transaction as an example, we first deposit WETH into the WETH-USDT Pair, then WETH-USDT Pair sends USDT into USDT-USDC Pair, and finally, the USDT-USDC Pair gives us USDC. Each step costs as much as transferring tokens to other addresses, which is why transaction fees increase with the number of Pairs in Uniswap or other DEXs.
In V4, all transactions are completed within the main contract (Manager Singleton), eliminating the need to transfer tokens between different addresses and thus saving the fee for state changes (Token balance changes).
Part 2. How to Swap and Flashswap (Flash Accounting)
The exact meaning of Flash Accounting, I guess, is to ensure state consistency through _accountDelta, where as long as you can meet the delta consistency in the end, the contract doesn't care what you do with the money.
In V4, based on my preliminary observations, we need an auxiliary contract (Router or some other third-party contract) to initiate the swap, unlike in V2 or V3 versions where an EOA (user address) could directly call the Pair for operation. This is because the V4 checks the lock status during the swap operation. We must call the lock function first, then the swap function, and finally the take function to withdraw the money, ensuring _accountDelta.
V4 retains the Flashswap (Flashloan) function. The calling method is to first call the lock and take functions to withdraw the money, and then return the money, ensuring _accountDelta.
To further save on gas fees, Uniswap has actively promoted the implementation of EIP1153. Simply put, EIP1153 introduces two new opcodes, which can make the swaps in UniswapV4 more gas-efficient. Because the V4's swap requires the _accountDelta and other states to remain unchanged before and after the transaction, only changing during the transaction.
The current EVM in Ethereum calculates the gas for state changes both within and outside the transaction. However, with EIP1153 implemented in Ethereum, such a transaction will be regarded by Ethereum as not changing the state after the transaction, thus greatly reducing the transaction fee.
Applying this example to Uniswap, since all tokens and states are held in the main contract (Manager Singleton), and the state does not change except for the money put in by the user and the money to be paid out by the main contract after the swap settlement, EIP1153 recognizes that the final state remains unchanged, which can save a lot of transaction fees.
There is some history regarding EIP1153. Some developers are concerned that with less gas needed for state changes, it could expose Ethereum to unnecessary risks, such as DDOS attacks. Uniswap founder, Hayden, has debated this point with many people.
Part 3. Hook Contract
In V2, all fees are set at 0.3%, so the pair composed of two tokens is fixed. For example, everyone knows that the WETH-USDT V2 pair is 0x0d4a11d5eeaac28ec3f61d100daf4d40471f1852.
In V3, due to different fee rates, the pair composed of two tokens is no longer fixed. For example, the WETH-USDT pair may have three different addresses depending on the fee rate, but the functions are fixed, with the same contract code for each.
In V4, with increased flexibility, the fee rate is not limited to three levels, and the concept of a hook contract is introduced. So theoretically, there can be countless contracts for the WETH-USDT V4 pair, each with different hooks, even at the same fee rate.
For V2 and V3, a pair is a contract. But for V4, a pair consists of two contracts (pool+hook).
During a swap transaction, the data sent by the user to the Manager Singleton contract includes key.hooks and key.poolId, which guide the Manager Singleton contract to operate the corresponding hook and pool contracts. The code in the hook contract is created by the creator, while the content in the pool contract is homogeneous.
The interaction sequence of V4 swap is as follows: The Hooks contract executes the custom beforeSwap method -> the pool contract calculates the specific swap values -> the pool contract returns the values to the Manager Singleton contract -> the Manager Singleton contract performs the swap -> the Hooks contract executes the custom afterSwap method.
Uniswap has provided four example hook contracts (https://github.com/Uniswap/v4-periphery/tree/main/contracts/hooks/examples), which include Geometric Mean Oracle, Limit Order Pattern, TWAMM, and Volatility Oracle.
Other hook use cases I can think of include custom bull-bear pairs. Usually, Uniswap pairs automatically sell targets when they rise and buy when they fall. If reversed operations are performed on-chain, they require substantial gas fees. However, if the afterSwap in the hook contract checks whether the pair's oracle is rising and then performs a bull-bear operation, a lot of gas can be saved. This saved gas can be used as a reward to reduce the LP fees for swappers, achieving a win-win situation.