History of V4 Quick History Lesson - v1 to v4 Let's take a few minutes to dive into Uniswap's history a bit so we develop some context for what's to come. Uniswap v1 launched in late 2018 as a way to exchange ERC20 tokens against ETH onchain in a decentralized way. It had a Factory contract that allowed anyone to deploy a new pool for any ETH -- ERC20 token pair. The core logic for Uniswap v1 worked on the CPMM xy = k equation we've all come to know and love - and marked the beginning of many years of DEX improvements by the Uniswap team. The problem with v1, however, was that being limited to ETH -- ERC20 token pairs was slightly annoying. Users looking to swap two ERC-20s would have to swap against ETH as an intermediary which cost unnecessary gas and was an additional extra step (not even considering the approve + transfer flow of ERC20 tokens). Uniswap v2 then came out in mid 2020 - and is still one of the largest DEXes today by volume - which solved this problem. It introduced ERC20 -- ERC20 token pools, allowed for more complex routing strategies (hopping across multiple pools), introduced Flash Swaps (akin to Flash Loans, but for swapping), and the Time Weighted Average Price (TWAP) oracle. With v2 then a new problem became more widely talked about. Liquidity Providers (LPs) faced impermanent losses when providing liquidity to a pool since all liquidity needed to be provided across the entire price range since v2 still used the xy = k curve. But the downside of that design was it caused pricing inefficiencies for many tokens since their volatility wasn't high enough to truly warrant liquidity across the entire price range. Uniswap v3 then launched almost a year later in 2021 and introduced concentrated liquidity. Instead of LPs being forced to provide liquidity over the full price range, they could now supply liquidity within a concentrated range they could choose - and they'd only earn fees if swaps were happening within that price range. This allowed for a more capital efficient design since the most liquidity could be made available within the price range where most swaps were happening. In exchange, LPs had to deal with lower impermanent losses due to not being spread out across the entire range. Today, both Uniswap v2 and v3 combined do billions of dollars of onchain volume every day, and the official Uniswap frontend can seamlessly switch between the two to find the best price for you when looking to swap a token. But with the popularity came forks - and a lot of them. Many Uniswap forks were launched over the years - mostly being deployed to newer chains before an official Uniswap deployment came to be, and occasionally they also modified the behaviour of Uniswap a bit. For example, PancakeSwap - a Uniswap fork on BNB - slightly changed how their governance tokens worked and deployed before Uniswap did an official deployment - and therefore Pancake has significant market share on BNB. This issue leads not just to liquidity fragmentation but also confusion for the end user - as apps they're familiar with and used to are not popular on whatever XYZ chain. Another big problem is the security of these contracts - since some forks modify the code but do not get re-audited, and sometimes that leads to hacks or rugpulls which hurts the users. Uniswap v4 (launched on Jan 31, 2025) now aims to solve a lot of these problems and then some. First of all, we have hooks - the thing you're all here for. Hooks allow anyone to write smart contracts that can modify the behaviour of a liquidity pool by "hooking into" key parts of the control flow. For example, functions such as beforeSwap and afterSwap can be used to run arbitrary code before or after a swap takes place in the pool. This allows anyone, effectively, to create derivate DEXes on Uniswap without needing to fork the entire codebase - and can enable some really interesting ideas as we will see later. It also has a brand new accounting system. Essentially, how is the balance between the maker and the taker (swapper and LPs) settled. By having a focus on gas optimization, v4 uses Transient Storage (EIP-1153), Flash Accounting (to only settle all pending balances at the end of the transaction, while only modifying temporary variables throughout the control flow), and even allows users to choose not to withdraw their tokens from Uniswap if they wish to. For example, if I regularly trade ETH -- USDC, I can just choose to keep my funds in the contract and keep making swaps in either direction - and only actually withdraw those funds like a month later once I'm done making those trades regularly. This is still just scratching the surface - and we'll learn about more possibilities as we dive into the technical parts of v4 in the next lesson - but hopefully provides some context on how we got here and the problems that are being solved. Why should you care? By creating hooks that modify the control flow of the DEX, a ton of exciting ideas become possible. I have nowhere close to an exhaustive list, but some examples include: Onchain Orderbooks Custom pricing curves to create more efficient markets for certain tokens (e.g. stablecoins) Reduction of toxic MEV Dynamic fees to react to real world situations and create game theoretic models Depositing out-of-range liquidity into a lending protocol to earn yield for LPs not earning fees on swaps Autocompounding LP fees into LP positions Creating enterprise DEXes with KYC'd pools and many more! Just like how Uniswap v2 was a big jump from v1, we believe v4 is going to be an even bigger jump from v3. With the unbounded creativity that becomes possible you have the opportunity to build cool new use cases without worrying about writing the boilerplate DEX code, getting it audited, and so on. You will still need to get your hooks audited to be fair if you're launching something on mainnet, but realistically that's going to be a much smaller codebase than the v4 core DEX itself. 将上述内容制作成中文视频，介绍uniswap 的历史