📜 [專欄新文章] Optimistic Rollup 就這樣用(2)
✍️ Juin Chiu
📥 歡迎投稿: https://medium.com/taipei-ethereum-meetup #徵技術分享文 #使用心得 #教學文 #medium
ERC721 的儲值、轉移與提領
TL;DR
本文會跳過 Optimistic Rollup 的介紹而直接實際演示,關於 Optimistic Rollup 的概念與設計原理筆者將在日後另撰文說明,有興趣的讀者可以先參考下列三篇文章(由淺入深):1. OVM Deep Dive 2. (Almost) Everything you need to know about Optimistic Rollup 3. How does Optimism’s Rollup really work?
本文將演示一個 Optimism Rollup 的 ERC721 範例,程式碼在這裡。
本演示大量參考了以下範例:Optimistic Rollup Example: ERC20。
本演示所使用的 ERC721 Gateway 合約來自這個提案,目前尚未成為官方標準。
環境設置
Git
Node.js
Yarn
Docker
Docker-compose
筆者沒有碰到環境相容問題,但是建議都升到最新版本, Node.js 使用 v16.1.0 或以上版本
Optimism 服務啟動
有關 Optimisim 的所有服務,都包裝在 Optimism 這個超大專案當中了,直接使用原始碼進行組建:
$ git clone git@github.com:ethereum-optimism/optimism.git$ cd optimism$ yarn$ yarn build
組建完成後,就可以在本機啟動服務了:
$ cd ops$ docker-compose build$ docker-compose up
這個指令會啟動數個服務,包括:
L1 Ethereum Node (EVM)
L2 Ethereum Node (OVM)
Batch Submitter
Data Transport Layer
Deployer
Relayer
Verifier
Deployer 服務中的一個參數要特別注意: FRAUD_PROOF_WINDOW_SECONDS,這個就是 OPtimistic Rollup 的挑戰期,代表使用者出金(Withdraw)需等候的時長。在本篇演示中預設為 0 秒。
如果有需要重啟,記得把整個 Docker Volume 也清乾淨,例如: docker-compose down -v
Optimism 整合測試
在繼續接下來的演示之前,我們需要先確認 Optimism 是否有順利啟動,特別是 Relayer 是否運作正常,因此我們需要先進行整合測試:
$ cd optimism/integration-tests$ yarn build:integration$ yarn test:integration
確保 L1 <--> L2 Communication 相關測試通過後再繼續執行接下來的演示內容。
啟動服務及部署合約需要花費一些時間,運行一段時間(約 120 秒)之後再執行測試,如果測試結果全部皆為 Fail,可能是 Optimism 尚未啟動完成,再等待一段時間即可。
ERC721 合約部署
Optimism 啟動成功並且完成整合測試後,接下來進行 ERC721 合約的部署。筆者已將合約及部署腳本放在 optimistic-rollup-example-erc721 這個專案中:
$ git clone git@github.com:ethereum-optimism/optimistic-rollup-example-erc721.git$ cd optimistic-rollup-example-erc721$ yarn install$ yarn compile
接下來我們需要部署以下合約:
ERC721,部署於 L1
L2DepositedEERC721,部署於 L2
OVM_L1ERC721Gateway,部署於 L1
OVM_L1ERC721Gateway 只部署在 L1 上,顧名思義它就是 L1 <=> L2 的「門戶」,提供 Deposit / Withdraw 兩個基本功能,使用者必須透過這個合約來進出 L2。
雖然 OVM_L1ERC20Gateway 是 Optimistic Rollup 官方提供的合約。但是開發者也可以依需求自行設計自己的「門戶」。
OVM_L1ERC20Gateway 目前沒有 Optimism 的官方實作,本演示所使用的 ERC721 Gateway 合約來自這個提案,目前尚未成為官方標準。
接下來,我們直接用腳本進行部署:
$ node ./deploy.jsDeploying L1 ERC721...L1 ERC2721 Contract Address: 0xFD471836031dc5108809D173A067e8486B9047A3Deploying L2 ERC721...L2 ERC721 Contract Address: 0x09635F643e140090A9A8Dcd712eD6285858ceBefDeploying L1 ERC721 Gateway...L1 ERC721 Gateway Contract Address: 0xcbEAF3BDe82155F56486Fb5a1072cb8baAf547ccInitializing L2 ERC721...
ERC721 鑄造、儲值、轉移與提領
鑄造(L1)
初始狀態如下,所有帳戶皆尚未持有任何代幣:
接下來,我們將鑄造 2 個代幣以進行接下來的演示。首先,進入 ETH(L1) 的 Console:
$ npx hardhat console --network ethWelcome to Node.js v16.1.0.Type ".help" for more information.>
取得 Deployer / User 帳戶:
// In Hardhat ETH Console
> let accounts = await ethers.getSigners()
> let deployer = accounts[0]
> let user = accounts[1]
取得 ERC721 及 OVM_L1ERC721Gateway 合約物件,合約地址可以從部署訊息中取得:
// In Hardhat ETH Console
> let ERC721_abi = await artifacts.readArtifact("ExampleToken").then(c => c.abi)
> let ERC721 = new ethers.Contract("0xFD471836031dc5108809D173A067e8486B9047A3", ERC721_abi)
> let Gateway_abi = await artifacts.readArtifact("OVM_L1ERC721Gateway").then(c => c.abi)
> let Gateway = new ethers.Contract("0xcbEAF3BDe82155F56486Fb5a1072cb8baAf547cc", Gateway_abi)
鑄造兩個 ERC721 代幣:
// In Hardhat ETH Console
> await ERC721.connect(deployer).mintToken(deployer.address, "foo")
{ hash: "...", ...}
> await ERC721.connect(deployer).mintToken(deployer.address, "bar")
{ hash: "...", ...}
只有合約的 Owner(deployer) 可以進行鑄造的操作。
確認 Deployer 餘額:
> await ERC721.connect(deployer).balanceOf(deployer.address)
BigNumber { _hex: '0x02', _isBigNumber: true } // 2
確認代幣的 TokenID 與 Owner:
> await ERC721.connect(deployer).ownerOf(1)
'0xf39Fd6e51aad88F6F4ce6aB8827279cffFb92266' // deployer
> await ERC721.connect(deployer).ownerOf(2)
'0xf39Fd6e51aad88F6F4ce6aB8827279cffFb92266' // deployer
儲值(L1 => L2)
完成以上步驟後,目前的狀態如下:
接下來,授權 OVM_L1ERC721Gateway使用 TokenID 為 2 的代幣:
// In Hardhat ETH Console
> await ERC721.connect(deployer).approve("0xcbEAF3BDe82155F56486Fb5a1072cb8baAf547cc", 2)
{ hash: "...", ...}
在 OVM_L1ERC721Gateway 合約呼叫 Deposit,儲值 TokenID 為 2 的代幣:
// In Hardhat ETH Console
> await Gateway.connect(deployer).deposit(2)
{ hash: "...", ...}
我們可以到 Optimism (L2) 的 Console 確認入金是否成功:
$ npx hardhat console --network optimismWelcome to Node.js v16.1.0.Type ".help" for more information.>
取得 Deployer / User 帳戶:
// In Hardhat Optimism Console
> let accounts = await ethers.getSigners()
> let deployer = accounts[0]
> let user = accounts[1]
取得 L2DepositedERC721 合約物件,合約地址可以從部署訊息中取得:
// In Hardhat Optimism Console
> let L2ERC721_abi = await artifacts.readArtifact("OVM_L2DepositedERC721").then(c => c.abi)
> let L2DepositedERC721 = new ethers.Contract("0x09635F643e140090A9A8Dcd712eD6285858ceBef", L2ERC721_abi)
確認入金是否成功:
// In Hardhat Optimism Console
> await L2DepositedERC721.connect(deployer).balanceOf(deployer.address)
BigNumber { _hex: '0x01', _isBigNumber: true } // 1
> await L2DepositedERC721.connect(deployer).ownerOf(2)
'0xf39Fd6e51aad88F6F4ce6aB8827279cffFb92266' // deployer
ERC721 轉移(L2 <=> L2)
完成以上步驟後,目前的狀態如下:
接下來,我們在 L2 從 Deployer 轉移代幣給 User:
// In Hardhat Optimism Console
> await L2DepositedERC721.connect(user).balanceOf(user.address)
BigNumber { _hex: '0x00', _isBigNumber: true } // 0
> await L2DepositedERC721.connect(deployer).transferFrom(depoyer.address, user.address, 2)
{ hash: "..." ...}
> await L2DepositedERC721.connect(user).balanceOf(user.address)
BigNumber { _hex: '0x01', _isBigNumber: true } // 1
> await L2DepositedERC721.connect(user).ownerOf(2)
'0x70997970C51812dc3A010C7d01b50e0d17dc79C8' // user
ERC721 提領(L2 => L1)
完成以上步驟後,目前的狀態如下:
接下來,我們用 User 帳戶提領資金,在 L2DepositedERC721 合約呼叫 Withdraw:
// In Hardhat Optimism Console
> await L2DepositedERC721.connect(user).withdraw(2)
{ hash: "..." ...}
> await L2DepositedERC721.connect(user).balanceOf(user.address)
BigNumber { _hex: '0x00', _isBigNumber: true }
最後,檢查在 L1 是否提領成功:
// In Hardhat ETH Console
> await ERC721.connect(user).balanceOf(user.address)
BigNumber { _hex: '0x01', _isBigNumber: true } // 1
> await ERC721.connect(deployer).balanceOf(deployer.address)
BigNumber { _hex: '0x01', _isBigNumber: true } // 1
> await ERC721.connect(user).ownerOf(2)
'0x70997970C51812dc3A010C7d01b50e0d17dc79C8' // user
由於挑戰期為 0 秒,因此提領幾乎無需等待時間,頂多只需數秒鐘
做完上述所有操作,最終狀態應該如下:
總結
本文演示了:
Optimistic Rollup 相關服務的本機部署
ERC721 L1 => L2 的儲值(Deposit)
ERC721 L2 帳戶之間轉移(Transfer)
ERC721 L2 => L1 的提領(Withdraw)
筆者未來將繼續擴充此系列的教學內容,例如支援其他標準的合約如 ERC1155,以及如何運行 Optimistic Rollup 生態系中最重要的驗證者(Verifier),敬請期待。
參考資料
OVM Deep Dive
(Almost) Everything you need to know about Optimistic Rollup
How does Optimism’s Rollup really work?
Optimistic Rollup Official Documentation
Ethers Documentation (v5)
Optimistic Rollup Example: ERC20(Github)
Optimism (Github)
optimism-tutorial (Github)
l1-l2-deposit-withdrawal (Github)
Proof-of-concept ERC721 Bridge Implementation (Github)
Optimistic Rollup 就這樣用(2) was originally published in Taipei Ethereum Meetup on Medium, where people are continuing the conversation by highlighting and responding to this story.
👏 歡迎轉載分享鼓掌
evm address 在 Taipei Ethereum Meetup Facebook 的最讚貼文
📜 [專欄新文章] Optimistic Rollup 就這樣用(1)
✍️ Juin Chiu
📥 歡迎投稿: https://medium.com/taipei-ethereum-meetup #徵技術分享文 #使用心得 #教學文 #medium
ERC20 的入金、轉帳與出金
TL;DR
本文會跳過 Optimistic Rollup 的介紹而直接實際演示,關於 Optimistic Rollup 的概念與設計原理我將在日後另撰文說明,有興趣的讀者可以先參考下列三篇文章(由淺入深):1. OVM Deep Dive 2. (Almost) Everything you need to know about Optimistic Rollup 3. How does Optimism’s Rollup really work?
本文將演示一個 Optimism Rollup 範例,程式碼在這裡。
本演示大量參考了以下這兩個官方範例:optimism-tutorial、l1-l2-deposit-withdrawal。
環境設置
Git
Node.js
Yarn
Docker
Docker-compose
筆者沒有碰到環境相容問題,但是建議都升到最新版本, Node.js 使用 v16.1.0 或以上版本
Optimism 服務啟動
有關 Optimisim 的所有服務,都包裝在 Optimism 這個超大專案當中了,直接使用原始碼進行組建:
$ git clone git@github.com:ethereum-optimism/optimism.git$ cd optimism$ yarn$ yarn build
組建完成後,就可以在本機啟動服務了:
$ cd ops$ docker-compose build$ docker-compose up
這個指令會啟動數個服務,包括:
L1 Ethereum Node (EVM)
L2 Ethereum Node (OVM)
Batch Submitter
Data Transport Layer
Deployer
Relayer
Verifier
Deployer 服務中的一個參數要特別注意: FRAUD_PROOF_WINDOW_SECONDS,這個就是 Optimistic Rollup 的挑戰期,代表使用者出金(Withdraw)需等候的時長。在本篇演示中預設為 0 秒。
如果有需要重啟,記得把整個 Docker Volume 也清乾淨,例如: docker-compose down -v
Optimism 整合測試
在繼續接下來的演示之前,我們需要先確認 Optimism 是否有順利啟動,特別是 Relayer 是否運作正常,因此我們需要先進行整合測試:
$ cd optimism/integration-tests$ yarn build:integration$ yarn test:integration
確保 L1 <--> L2 Communication 相關測試通過後再繼續執行接下來的演示內容。
啟動服務及部署合約需要花費一些時間,運行一段時間(約 120 秒)之後再執行測試,如果測試結果全部皆為 Fail,可能是 Optimism 尚未啟動完成,再等待一段時間即可。
ERC20 合約部署
Optimism 啟動成功並且完成整合測試後,接下來進行 ERC20 合約的部署。筆者已將合約及部署腳本放在 optimistic-rollup-example-erc20 這個專案中:
$ git clone git@github.com:ethereum-optimism/optimistic-rollup-example-erc20.git$ cd optimistic-rollup-example-erc20$ yarn install$ yarn compile
接下來我們需要部署以下合約:
ERC20,部署於 L1
L2DepositedEERC20,部署於 L2
OVM_L1ERC20Gateway,部署於 L1
其中,ERC20 與 L2DepositedERC20 是由上面的範例專案編譯的,可以直接在範例專案中直接取得 ABI;而 OVM_L1ERC20Gateway 則是由 Optimism 編譯的,屬於 Optimistic Rollup 協定的一部分,無法直接在範例專案中取得 ABI。
因此在部署以上三個合約前,我們需先手動將 OVM_L1ERC20Gateway 編譯後的生成品 (Artifacts)——即 ABI,複製到此專案中:
$ cp -r ~/projects/optimism/packages/contracts/artifacts/contracts/optimistic-ethereum/OVM/bridge/tokens/OVM_L1ERC20Gateway.sol ~/projects/optimistic-rollup-example-erc20/artifacts/contracts/
OVM_L1ERC20Gateway 只部署在 L1 上,顧名思義它就是 L1 <=> L2 的「門戶」,提供 Deposit / Withdraw 兩個基本功能,使用者必須透過這個合約來進出 L2。
雖然 OVM_L1ERC20Gateway 是 Optimistic Rollup 官方提供的合約。但是開發者也可以依需求自行設計自己的「門戶」。
接下來,我們直接用腳本進行部署:
$ node ./deploy.jsDeploying L1 ERC20...Deploying L1 ERC20...L1 ERC20 Contract Address: 0x1429859428C0aBc9C2C47C8Ee9FBaf82cFA0F20fDeploying L2 ERC20...L2 ERC20 Contract Address: 0x67d269191c92Caf3cD7723F116c85e6E9bf55933Deploying L1 ERC20 Gateway...L1 ERC20 Gateway Contract Address: 0xB0D4afd8879eD9F52b28595d31B441D079B2Ca07Initializing L2 ERC20...
ERC20 入金、轉帳與出金
ERC20 入金(L1 => L2)
目前餘額:
在合約部署完成後,Deployer 是目前唯一有資金的帳戶,接下來我們就進行入金(Deposit),將 Deployer 的資金從 L1 搬到 L2。
首先,進入 ETH(L1) 的 Console:
$ npx hardhat console --network ethWelcome to Node.js v16.1.0.Type ".help" for more information.>
取得 Deployer / User 帳戶:
// In Hardhat ETH Console
> let accounts = await ethers.getSigners()> let deployer = accounts[0]> let user = accounts[1]
取得 ERC20 及 OVM_L1ERC20Gateway 合約物件,合約地址可以從部署訊息中取得:
// In Hardhat ETH Console
> let ERC20_abi = await artifacts.readArtifact("ERC20").then(c => c.abi)> let ERC20 = new ethers.Contract("0x1429859428C0aBc9C2C47C8Ee9FBaf82cFA0F20f", ERC20_abi)> let Gateway_abi = await artifacts.readArtifact("OVM_L1ERC20Gateway").then(c => c.abi)> let Gateway = new ethers.Contract("0xB0D4afd8879eD9F52b28595d31B441D079B2Ca07", Gateway_abi)
先授權 OVM_L1ERC20Gateway 花費 ERC20:
// In Hardhat ETH Console
> await ERC20.connect(deployer).approve("0xB0D4afd8879eD9F52b28595d31B441D079B2Ca07", 10000)> await ERC20.connect(user).approve("0xB0D4afd8879eD9F52b28595d31B441D079B2Ca07", 10000)
注意:Deployer 及 User 都需要對 OVM_L1ERC20Gateway 進行授權,否則在接下來的出金步驟時 Relayer 會出錯
接著,在 OVM_L1ERC20Gateway 合約呼叫 Deposit:
// In Hardhat ETH Console
> await Gateway.connect(deployer).deposit(1000)
我們可以到 Optimism (L2) 的 Console 確認入金是否成功:
$ npx hardhat console --network optimismWelcome to Node.js v16.1.0.Type ".help" for more information.>
取得 Deployer / User 帳戶:
// In Hardhat Optimism Console
> let accounts = await ethers.getSigners()> let deployer = accounts[0]> let user = accounts[1]
取得 L2DepositedERC20 合約物件,合約地址可以從部署訊息中取得:
// In Hardhat Optimism Console
> let L2ERC20_abi = await artifacts.readArtifact("L2DepositedERC20").then(c => c.abi)> let L2DepositedERC20 = new ethers.Contract("0x67d269191c92Caf3cD7723F116c85e6E9bf55933", L2ERC20_abi)
確認入金是否成功:
// In Hardhat Optimism Console
> await L2DepositedERC20.connect(deployer).balanceOf(deployer.address)BigNumber { _hex: '0x03E8', _isBigNumber: true } // 1000
ERC20 轉帳(L2 <=> L2)
完成以上步驟後,目前的餘額如下:
接下來,我們在 L2 從 Deployer 轉移一部分資金給 User:
// In Hardhat Optimism Console
> await L2DepositedERC20.connect(user).balanceOf(user.address)BigNumber { _hex: '0x00', _isBigNumber: true } // 0> await L2DepositedERC20.connect(deployer).transfer(user.address, 1000){ hash: "..." ...}> await L2DepositedERC20.connect(wallet_1).balanceOf(user.address)BigNumber { _hex: '0x03E8', _isBigNumber: true } // 1000
ERC20 出金(L2 => L1)
完成以上步驟後,目前的餘額如下:
接下來,我們用 User 帳戶提領資金,在 L2DepositedERC20 合約呼叫 Withdraw:
// In Hardhat Optimism Console
> await L2DepositedERC20.connect(user).withdraw(1000){ hash: "..." ...}> await L2DepositedERC20.connect(user).balanceOf(user.address)BigNumber { _hex: '0x00', _isBigNumber: true }
最後,檢查在 L1 是否提領成功:
// In Hardhat ETH Console
> await ERC20.connect(user).balanceOf(user.address)BigNumber { _hex: '0x03E8', _isBigNumber: true } // 1000
由於挑戰期為 0 秒,因此提領幾乎無需等待時間,頂多只需數秒鐘
做完上述所有操作,餘額應該如下:
總結
本文演示了:
Optimistic Rollup 相關服務的本機部署
ERC20 L1 => L2 的入金(Deposit)
ERC20 L2 帳戶之間轉帳(Transfer)
ERC20 L2 => L1 的出金(Withdraw)
筆者未來將繼續擴充此系列的教學內容,例如 ERC721 / ERC1155 的使用方式,敬請期待。
參考資料
OVM Deep Dive
(Almost) Everything you need to know about Optimistic Rollup
How does Optimism’s Rollup really work?
Optimistic Rollup Official Documentation
Ethers Documentation (v5)
Optimism (Github)
optimism-tutorial (Github)
l1-l2-deposit-withdrawal (Github)
Optimistic Rollup 就這樣用(1) was originally published in Taipei Ethereum Meetup on Medium, where people are continuing the conversation by highlighting and responding to this story.
👏 歡迎轉載分享鼓掌
evm address 在 Taipei Ethereum Meetup Facebook 的最佳貼文
📜 [專欄新文章] 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.
👏 歡迎轉載分享鼓掌