📜 [專欄新文章] EIP2929, EIP2930 簡介
✍️ Anton Cheng
📥 歡迎投稿： https://medium.com/taipei-ethereum-meetup #徵技術分享文 #使用心得 #教學文 #medium
Opcode 加油Proposal，會不會讓以太坊變更貴呢
昨天在同事的推薦下發現了這個YouTube系列：Peep an EIP，也聽了Vitalik和Martin介紹EIP2929 + 2930的這一期。這兩個EIP都已經被列入下一次的硬分岔(Berlin Hardfork)，所以我就來寫個學習筆記。先打個預防針，本人對EVM可以說是非常不熟，但也希望藉著這個機會逼自己學習，如果有錯誤的話也希望懂的更多的各路大神可以不吝賜教。
Berlin without hardfork. (By Claudio Schwarz on Unsplash)
EIP2929: Gas cost increases for state access opcodes
乍看之下這是一個極為恐怖的Proposal。在Gas已經高到爆炸的2021年，理論上不應該再通過這種「加油」類的方案。不過不用緊張，其實這個EIP真正改變的是第一次access的價格，如果一筆交易內要執行一樣Opcode動作輛次，那麼gas cost 將降低為100。
Increases gas cost for SLOAD, *CALL, BALANCE, EXT* and SELFEDESTRUCT when used for the first time in a transaction.
大家都知道，合約最終會被Compile成一堆Opcode，這些Opcode也是用來計算最終交易手續費的依據：理論上越是花時間的的Opcode，應該要收越高的手續費。
但是一直以來，state access opcode 太便宜都是一個已知的問題：在2016年的上海DOS攻擊中，其中幾個攻擊的手法就是透過惡意交易大量讀取帳戶資訊、大量的創造合約再銷毀，或是不斷用 EXTCODESIZE 來讀合約大小等等，讓Client必須花大量的IO資源處理交易(需要讀寫disk的動作特別慢)，最終使Client程式Crash或是延長出塊時間。儘管大部分的弱點已經透過EIP150中大量提升gas cost獲得改善（還有其後的EIP1884），但在EIP2929中，也引用的這篇Paper的數據：現在replay所有以太坊上的交易，當時那些惡意交易中的worst case還會需要~80秒才能完成。這跟以太坊所定義的13秒出塊時間有著很大的差距，也代表這個潛在的攻擊是可行的。
透過增加這些opcode所需要的gas cost，可以降低每個區塊最大可能的讀取數。以下是偷抄Vitalik PPT 的數據：(12,500,000 為gas limit上限)
Pre-EIP 2929:
BALANCE spam: 12,500,000 / (400 cost + 320 address size + 50 boilerplate) = 16,233 accesses per block
CALL spam: 12,500,000 / (700 + 320 + 50) = 11,682 accesses per block
SLOAD spam: 12,500,000 gas / (800 + 25 boilerplate) = 15,151 accesses per block (but of a smaller tree)
Post-EIP 2929:
BALANCE spam: 12,500,000 / (2,600 + 320 + 50) = 4,280 accesses per block
CALL spam: 12,500,000 / (2,600 + 320 + 50) = 4,280 accesses per block
SLOAD spam: 12,500,000 / (2,100 + 25) = 5,882 accesses per block
說實在的這個數據的解釋也很廢話，就是把Opcode變得用貴，能Spam的數量越少。平均來說Gas cost 變高3倍，所以之前worst case的80秒執行時間可以被下降到大概 ~27秒。
SSTORE changes
在實作層，EVM會維繫一個本筆交易讀取過所有交易的 Set。每次有尚未讀取過的slot時，就會先收取一筆 CLOD_SLOAD_COST (2100) ，然後把這個slot加入這個set中，下次讀寫就會比較便宜。
對於已經讀取過的Slot，再次寫入的Opcode SSTORE 之gas cost為會降低為
5000 — COLD_SLOAD_COST (2100) = 2900
簡單的說，單純只操作一次 SSTORE 的總gas 會維持一樣在 5000 。但如果這個slot是之前有讀過的，則寫入的gas cost就會降低。近一步來說，一個 x += 100 ，其實會變得更便宜:
Pre-EIP-2929: 800 SLOAD + 5000 SSTORE = 5800
Post-EIP-2929: 2100 SLOAD + 2900 warm SSTORE = 5000
其他Side effects
這個改動除了降低了最高能夠spam的次數以外，也降低了以太坊想要做到stateless client，理論上最大的witness 大小。其實這裡的原理跟前面很類似，下圖的表格比較的是目前使用hexary tree所需要的witness大小：若12.5M的區塊全部塞滿該Opcode的witness，理論上最大會佔多少空間。在EIP2929之後由於gas cost增加，就壓縮了最大可能的witness size.
這裡單純只比較增加gas cost後，對於max witness size的影響。影片中有提到其他許多方法旨在減少Witness bytes，包括使用binary tree而不是hexary tree，以及用Code Merklization等等。這些其他方法也能夠降低最後的Max Witness size，但跟這個EIP沒有直接相關。不過可以注意的一點是，這些其他在witness size上面的優化跟 gas cost 所帶來的優化的效果是可以相乘的，例如 SLOAD，更改gas price已經能夠讓max size 縮小2.6倍，若是改用Binary tree可以將 Witness bytes降低到 288 bytes，就會是再3~倍的優化。
對用戶的影響
依照Martin Swende 給出的數據，這個EIP對於一般交易的影響僅有提高0.3~0.4%。理由很簡單，雖然第一次access storage變貴了，但是後面幾次讀寫就會變得便宜。大部分應用的程式邏輯都是類似的幾個變數進行讀寫，因此可能有不少的動作反而會變得更便宜。一個最簡單的例子就是ERC20 Transfer，兩個餘額的 +=和 -= 都會變便宜，所以總共的花費也是變便宜的。
這其中也會對於Solidity的開發pattern有著一定程度的影響，我目前想到的影響可能有兩個：
由於多次的storage access變便宜，永遠cache state variables不再是一個最佳策略。以前我們會盡量想辦法減少寫入state storage的次數，現在可能會基於coding style考量減少一些的memory cache。
之前寫合約都會盡量避免external call，甚至會寫一些一次把所有 variable都回傳回來的笨函示，來避免多次的external calls。這有一部分原因是因為每次external call都會需要使用到 EXTCODESIZE 這個Opcode所以很貴。但如果 EXT 系列的Opcode也變得越call越便宜，那麼這個一次全部call 回來cache 住的pattern也可能改變。
以上兩個想法都還沒有經過實證，如果之後看到更有證據的分析的話，也會來這裡分享。
EIP2930: Optional access lists
EIP2929可能會影響一些鏈上的合約，因為有些合約有hardcode external call的gas 上限。對於這方面的問題，EIP2930提出一個新的交易類型，讓交易中多帶一個access list，即所有這筆交易即將讀寫的storage slot，並且先幫忙付掉第一次讀寫的gas，而真正交易讀寫該storage時，只會被要求付100 gas。
這不但可以避免這次EIP2929帶來的副作用，也可以被使用在其他因為gas price 改變的硬分岔升級而壞掉的合約，例如在EIP1184 增加 SLOAD gas price 時影響到的 Aragon 和Kyber 等等。儘管當時升級前各大專案都有幫助用戶提出migration 方案，但如果有人曾經卡錢在裡面，也可以Follow一下這次柏林Hardfork。
小結
新的一年就用一篇簡單的文章來開頭。最近發現自己以前的學習習慣有點亂無章法，所以新年整理了reading list，逼自己做筆記，順便發想一些想要寫的主題。今年的期許就是學更多Ethereum底層一點的知識，當然還有上層一點Defi的知識。也歡迎大家分享一下自己都是怎麼follow這麼多東西的><
EIP2929, EIP2930 簡介 was originally published in Taipei Ethereum Meetup on Medium, where people are continuing the conversation by highlighting and responding to this story.
👏 歡迎轉載分享鼓掌
