📜 [專欄新文章] 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.
👏 歡迎轉載分享鼓掌
opcode表 在 i386手册指令集阅读指南· GitBook 的推薦與評價
我们以 mov 指令的opcode表为例来说明如何阅读: Opcode Instruction Clocks Description < 1> 88 /r MOV r/m8,r8 2/2 Move byte register to r/m byte ... ... <看更多>
opcode表 在 Blockchain-and-Cryptography/2-7-bitcoin-script-yu-opcode.md 的推薦與評價
本書連結:https://easonwang01.gitbooks.io/blockchain-and-cryptography/content/ - Blockchain-and-Cryptography/2-7-bitcoin-script-yu-opcode.md at master ... ... <看更多>