nikitakle
Uniswap v4 research, here are some interesting observations that have been noted by our development team so far :
1️⃣ The behavior of a hook can vary.
To ensure the pool works correctly with the hook, it is necessary to deploy the hook in a way that obtains the correct initial bits of its address. This requires mining the addresses for hooks contracts: https://github.com/Uniswap/v4-core/blob/2f9b30663b53c0165cd6d34651d8ff13287667c4/contracts/libraries/Hooks.sol#L8
2️⃣ Another interesting point: the Uniswap team implemented the SafeTransfer part in a similar way to Algebra V2.0, which caused some integration issues on zksync Era:
https://github.com/Uniswap/v4-core/blob/2f9b30663b53c0165cd6d34651d8ff13287667c4/contracts/libraries/CurrencyLibrary.sol#L36-L56
(Luckily enough, zkSync ended up releasing a compiler update)
3️⃣ It is worth noting that Uniswap chose to keep the bitmap as the data structure for the ticks, while we prefer using a doubly linked list, which makes large swaps cheaper with our model: https://github.com/Uniswap/v4-core/blob/main/contracts/libraries/TickBitmap.sol
Without the doubly linked list, there are additional iterations during the swap, which is not seen in the Algebra V2 code:
https://github.com/Uniswap/v4-core/blob/2f9b30663b53c0165cd6d34651d8ff13287667c4/contracts/libraries/Pool.sol#L422
4️⃣ What’s more? #UniV4 decided to remove all the side information from the ticks. Previously, it contained additional data that could be used to calculate various statistics, but traders had to pay for it. In the fourth implementation of Uniswap, such data will not be stored:
https://github.com/Uniswap/v4-core/blob/2f9b30663b53c0165cd6d34651d8ff13287667c4/contracts/libraries/Pool.sol#L80-L89
5️⃣ It is not entirely clear why the #Uni team prefers to initialize this structure in memory with every iteration of the loop, instead of making one and reusing it. Maybe they prefer to sacrifice gas efficiency for a more ‘readable’ code?
https://github.com/Uniswap/v4-core/blob/2f9b30663b53c0165cd6d34651d8ff13287667c4/contracts/libraries/Pool.sol#LL417C37-L417C41
by Algebra
https://twitter.com/CryptoAlgebra/status/1668670629623607304?s=20
1️⃣ The behavior of a hook can vary.
To ensure the pool works correctly with the hook, it is necessary to deploy the hook in a way that obtains the correct initial bits of its address. This requires mining the addresses for hooks contracts: https://github.com/Uniswap/v4-core/blob/2f9b30663b53c0165cd6d34651d8ff13287667c4/contracts/libraries/Hooks.sol#L8
2️⃣ Another interesting point: the Uniswap team implemented the SafeTransfer part in a similar way to Algebra V2.0, which caused some integration issues on zksync Era:
https://github.com/Uniswap/v4-core/blob/2f9b30663b53c0165cd6d34651d8ff13287667c4/contracts/libraries/CurrencyLibrary.sol#L36-L56
(Luckily enough, zkSync ended up releasing a compiler update)
3️⃣ It is worth noting that Uniswap chose to keep the bitmap as the data structure for the ticks, while we prefer using a doubly linked list, which makes large swaps cheaper with our model: https://github.com/Uniswap/v4-core/blob/main/contracts/libraries/TickBitmap.sol
Without the doubly linked list, there are additional iterations during the swap, which is not seen in the Algebra V2 code:
https://github.com/Uniswap/v4-core/blob/2f9b30663b53c0165cd6d34651d8ff13287667c4/contracts/libraries/Pool.sol#L422
4️⃣ What’s more? #UniV4 decided to remove all the side information from the ticks. Previously, it contained additional data that could be used to calculate various statistics, but traders had to pay for it. In the fourth implementation of Uniswap, such data will not be stored:
https://github.com/Uniswap/v4-core/blob/2f9b30663b53c0165cd6d34651d8ff13287667c4/contracts/libraries/Pool.sol#L80-L89
5️⃣ It is not entirely clear why the #Uni team prefers to initialize this structure in memory with every iteration of the loop, instead of making one and reusing it. Maybe they prefer to sacrifice gas efficiency for a more ‘readable’ code?
https://github.com/Uniswap/v4-core/blob/2f9b30663b53c0165cd6d34651d8ff13287667c4/contracts/libraries/Pool.sol#LL417C37-L417C41
by Algebra
https://twitter.com/CryptoAlgebra/status/1668670629623607304?s=20