📜 [專欄新文章] 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.
👏 歡迎轉載分享鼓掌
同時也有10000部Youtube影片,追蹤數超過2,910的網紅コバにゃんチャンネル,也在其Youtube影片中提到,...
「binary tree教學」的推薦目錄:
- 關於binary tree教學 在 Taipei Ethereum Meetup Facebook 的最讚貼文
- 關於binary tree教學 在 Taipei Ethereum Meetup Facebook 的最讚貼文
- 關於binary tree教學 在 コバにゃんチャンネル Youtube 的最佳解答
- 關於binary tree教學 在 大象中醫 Youtube 的最佳貼文
- 關於binary tree教學 在 大象中醫 Youtube 的精選貼文
- 關於binary tree教學 在 Binary Tree: Intro(簡介) 的評價
- 關於binary tree教學 在 How to implement a binary tree? - Stack Overflow 的評價
- 關於binary tree教學 在 jwasham/coding-interview-university - GitHub 的評價
binary tree教學 在 Taipei Ethereum Meetup Facebook 的最讚貼文
📜 [專欄新文章] Crosslink 2019 Taiwan|LibraBridge: 橋接 Libra 與 Ethereum
✍️ AndyLin
📥 歡迎投稿: https://medium.com/taipei-ethereum-meetup #徵技術分享文 #使用心得 #教學文 #medium
十月19–20日於台北矽谷會議中心舉行的 Crosslink 2019 Taiwan,由 Taipei Ethereum Meetup 合計共40多位志工協力舉辦,吸引了上百位來自全球的區塊鏈開發者社群齊聚。自從 Facebook 在今年六月公布 Libra 計劃之後,造成全球政府、金融機構以及區塊鏈產業的熱烈關注,其中也有許多區塊鏈開發者對於 Libra 的技術及應用產生很大的興趣。在19日上午其中一場演講由來自區塊鏈技術開發公司 AMIS 的軟體工程師 Bun Hsu,分享了其開發的專案「LibraBridge: 橋接 Libra 與 Ethereum」,透過實作 MVP 來實現 Libra 與 ETH 之間的 Swap 互換。
LibraBridge: 橋接 Libra 與 Ethereum — Bun Hsu(source: Crosslink 2019 Taiwan)
在演講的前半段,講者先介紹了在驗證 Libra 交易所需具備的基本知識;後半段則介紹其實作的 LibraBridge,並現場 demo。
一、驗證 Libra 交易
首先,先介紹驗證 Libra 交易需要具備的基本知識,包括 Merkle tree, transaction info 以及 transaction accumulator 等。區塊鏈網路中的 client node 分為 full node, light node, relay node,在這裡會著重在 light node 輕節點。輕節點不需擁有區塊鏈上所有的資料,只需透過 block header 中的 Merkle root 即可驗證交易。
接著介紹 Libra 的交易資訊,稱為 Transaction Information,主要分為 RawTransaction, SignedTransaction 以及 TransactionInfo 三部分,內容如下圖所示。
Libra Transaction Tree (source)
因為 Merkle root 的值在每次新節點加進來後都會改變,導致 Merkle tree 會不斷變大,因此,Libra 中的 transaction tree 被稱為 transaction accumulator。
Data stricture in the Libra protocol(source)
接著,講者以一個範例來說明上述內容。
從 gRPC client 收到交易後會顯示以下內容:
version: 44767signed_transaction { signed_txn: "..."}proof { ledger_info_to_transaction_info_proof { bitmap: 45055 non_default_siblings: "..." non_default_siblings: "..." non_default_siblings: "..." ... } transaction_info { signed_transaction_hash: "..." state_root_hash: "..." event_root_hash: "..." major_status: 4001 }}events { ...}
Version
每一個交易都有其唯一的版本號碼,也就是在 transaction accumulator 中 leaf node 的位置。以下圖為例,藍色節點的交易 version 為 4,二進制表示為 100,其中 0 表示向左,1 表示向右,因此我們可以從 root 出發,向右一次、向左兩次後找到此交易。此概念和 Plasma Cash 相似。
Transaction version(source)
bitmap & non_default_siblings
bitmap 表示哪個 siblings 為 default,1 表示 non-default;0 為 default。因為 transaction accumulator 會一直變大,大多數時間都不會是 full binary tree,因此,需要 default(placeholder) 來維持樹的結構。
bitmap & non_default_siblings(source)
transaction_info
交易的細節。其中,major_status: 4001 表示交易已被節點執行。而因為目前 Libra 不會消耗 gas,因此 gas_used 為 0 而未顯示。
在前半段演講結束前,講者也展示了用 Solidity 語言來驗證 Libra transaction Merkle proof 的程式碼。
Solidity snippet
而在後半段演講,講者先介紹了 LibraBridge 的應用場景。
二、透過可信任的第三方來執行 LIB-ETH 交換
目前要進行 Libra token 和 ETH 的交換,必須透過可信任的第三方來確保交易執行。舉例來說,假設參與方(使用者)擁有 Libra token,而託管方(MAX 交易所)有賣 ETH,參與方想要和託管方進行幣幣交換的方法為從 MAX 交易所入金 Libra 並與之交換 ETH,但前提是相信 MAX 交易所會如期出金,不會作惡。
但此時會有個問題產生:是否可在不完全信任託管方(MAX 交易所)的情況下來實現 LIB-ETH 的幣幣交換呢?
三、LibraBridge — Trustless custodian between Libra and Ethereum
在 LibraBridge 的實作中,藉由兩個 function 來實現無需託管信任的 LIB-ETH 幣幣交換:
Deposit:託管方傳送較多的 ETH 至合約中作為保證金。
Challenge:參與方可以質疑託管方是否實現承諾(在合約中驗證 Libra transaction Merkle proof)
以下分別討論正常情況及違約挑戰的情況:
Case 1: 正常情況
在正常的情況下,首先託管方會在合約中存入保證金,同時被鎖定直到一定時間後才能被託管方取回。而當使用者(參與方)想與託管方進行幣幣交換時,會先查詢合約上是否有足夠的保證金,若驗證通過,使用者將 Libra 代幣存入託管方,而當託管方確認後,則會傳送等值的 ETH 給使用者。
Case 1(source)
Case 2: 託管方違約
若託管方收到 Libra 後卻沒轉送 ETH 給使用者,則託管方即違約,使用者可以透過合約中的 Challenge 功能來執行違約挑戰,使用者可以出示 Libra 轉帳證明作為憑據,在驗證過 Libra transaction Merkle proof 後,合約上的押金(保證金)會被削減以歸還給使用者作為補償。
Case 2(source)
Demo
在演講的最後,講者也現場 demo 了 LibraBridge 的實作,有興趣的讀者也可以參考其官方錄製的 demo 影片。
而這場演講裡提到的內容,讀者也可參考 AMIS 的 Medium 文章及 github。
Crosslink 2019 Taiwan|LibraBridge: 橋接 Libra 與 Ethereum was originally published in Taipei Ethereum Meetup on Medium, where people are continuing the conversation by highlighting and responding to this story.
👏 歡迎轉載分享鼓掌
binary tree教學 在 コバにゃんチャンネル Youtube 的最佳解答
binary tree教學 在 大象中醫 Youtube 的最佳貼文
binary tree教學 在 大象中醫 Youtube 的精選貼文
binary tree教學 在 jwasham/coding-interview-university - GitHub 的推薦與評價
Trees - Intro; Binary search trees: BSTs; Heap / Priority Queue / Binary Heap; balanced search trees (general concept, not details); traversals: preorder, ... ... <看更多>
binary tree教學 在 Binary Tree: Intro(簡介) 的推薦與評價
若限制node只能有兩個child,等價於「樹上的每一個node之degree皆為2」,此即稱為Binary Tree(二元樹),並稱兩個child pointer為left child和right child。 ... <看更多>