2023 年 6 月，Uniswap 官方發布的一篇博客吸引了幣圈所有人的眼球。繼 Uniswap-v3 推出 2 年後，v4 要來了！
憑借大幅的 gas 優化以及全新的 Hook 玩法，進一步鞏固了 Uniswap 在 Dex 領域的龍頭地位。
但直到筆者寫作日期的 10 月，都還遲遲未上線，這是為什麼呢？
因為它需要下次升級（坎昆升級）所引入的新字節碼，具體就是EIP-1153
EIP-1153 幹了什麼事#
官方是這麼寫的
Add opcodes for manipulating state that behaves identically to storage but is discarded after every transaction.
我們知道，目前在智能合約中，變量通常可以聲明存儲為 2 個位置storage和memory:
storage 修飾的變量是永久保存鏈上的，涉及SSTORE和SLOAD這兩個 opcode，gas 花費很大
memory 出現在一個函數裡臨時聲明的變量，用完（函數執行結束）就釋放了，gas 消耗小，但只是函數內可見
折中一下它們兩者，其實就是 EIP-1153 要做的：修改了storage變量，但最後又復原了，一套下來相當於沒改。比起普通修改storage要節省很多 gas
引入新的 opcode:TSTORE和TLOAD，筆者預測關鍵字：Transient
意義#
引入這一機制，能帶來什麼好處呢？
在 Uniswap-v4 中，廢棄了 Factory - Pair 這種模式，轉而將所有幣對池子都放在一個（單例）合約裡，因為省去了跨合約調用，故節省了很多 gas。單例合約的實現需要依靠 EIP-1153 來記錄 token balance 變化
當然關於 Uniswap-v4 具體是如何運用 EIP-1153 的還需要讀者自己去研究🤓
Reentrancy lock#
筆者在這裡介紹一個很常見的應用場景 ——ReentrancyGuard
相信稍懂些智能合約的朋友都知道 “重入攻擊” 是區塊鏈一大經典攻擊手段，ReentrancyGuard 作為 OpenZeppelin 推出一個庫，能有效防止被重入。
我們來看下它的核心代碼：
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;
}
它做的事情很簡單，引入了一種 “鎖” 機制，在上下文的前後檢查和修改_status的值從而防止 “重入” 進來
那麼為什麼要使用 1 和 2 來做區分，而不是 True 和 False 呢，為了節省 gas，具體可以參考WTF-Academy
然而我們可以注意到，在nonReentrant裡，最開始和結束後的_status是一樣，一套下來沒變，恰好符合 EIP-1153
因此在坎昆升級後，將會有更節省 gas 的新版 ReentrancyGuard 出來，或者說不需要單獨的庫，直接自己幾行代碼搞定。到時會讓絕大部分 DeFi 合約更節省 gas
Single transaction ERC-20 approval#
不知道有沒有其他小夥伴和筆者一樣，在剛接觸 Dex 的時候，被想要 Swap 卻要先 Approve Token 這一操作給整懵了。更難受的是，假如你之前 approve 的數量不夠，還要再 approve 一次，要知道每筆交易都要付錢啊😭；一次 approve 的數量過多，暫時花不完又會有安全問題（合約把你的 token 轉走），這叫一個矛盾啊😤
為了解決先 approve 再 swap 這個問題，提出了 transferFromWithPermit 這一方法，通過預先簽名隨後驗簽的方式把 approve 合併到 swap 裡來從而實現 “一步化”。
但有個問題，假如我簽名 approve 後那些 token 沒用上反悔了，簽名被盜取怎麼辦，會不會給壞人可乘之機？
EIP-1153 可以帶來 temporary approve 也就是在交易開始時我 approve 了，經過一系列操作，不管那些 token 用沒用上，最後都恢復回去，這樣是不是安全很多。
將來針對此特性應該會出新的 ERC-20 Extension 估計還會對 AA 賬戶抽象起一定幫助。