關於 solidity address ，我們在網路上蒐集到這些相關的討論、資訊與評價

📜 [專欄新文章] Solidity Data Collision

✍️ Wias Liaw

📥 歡迎投稿： https://medium.com/taipei-ethereum-meetup #徵技術分享文 #使用心得 #教學文 #medium

這是一篇關於 Proxy Contract 和 delegatecall 的注意事項。

Delegatecall

當 A 合約對 B 合約執行 delegatecall 時，B 合約的函式會被執行，但是對 storage 的操作都會作用在 A 合約上。舉例如下：

但是假如多加了一個 other 欄位在 _value 之前，執行合約之後反而是 other 欄位被更改了。

Storage Layout

了解上面的合約之前要先了解 Solidity 怎麼儲存 State Variables。Solidity Storage 以 Slot 為單位，每個 Slot 可以儲存 32 bytes 的資訊，一個 Contract 擁有 2**256 個 Slot。上述可以寫成一個映射關係 mapping(uint256 => bytes32) slots。

Solidity 會從 Slot Index 為零開始分配給 State Variable。

除了 mapping 和 dynamically-sized array，其他的 State Variable 會從 index 為零的 slot 開始被分配。

沒有宣告確切大小的 Array 會以 Slot Index 計算出一個雜湊值並將其作為 Slot Index。透過計算 keccak256(slot) 可以得知 _arr[0] 被存在哪裡，如果要取得 _arr[1] 則將計算出來的雜湊加上 Array 的 index 即可。

Mapping 則是以 Slot Index 和 Key 計算出一個雜湊值並將其作為 Slot Index。透過計算 keccak256(key, slot) 可以得到 mapping(key => value) 被存在哪。

Storage Collision

回到 DelegateExample_v2 的合約，對 B 來說， add 最後儲存加法的 Slot Index 為零，所以使用 A 的 Storage 執行 B 的函式結果自然會儲存在 A 的 other 裡，其 Slot Index 為 0。

這個問題也發生在 Proxy Contract，Layout 如下，當有需要更改 _owner 的操作，就會順帶把 _implementation 也更改了。

|Proxy |Implementation ||--------------------------|-------------------------||address _implementation |address _owner | <= collision|... |mapping _balances || |uint256 _supply || |... |

OpenZeppelin 處理的手法也很簡單，就是將 _implementation 換地方擺。以特定字串的雜湊值作為 Slot Index，儲存 Implementation 的地址。

|Proxy |Implementation ||--------------------------|-------------------------||... |address _owner ||... |mapping _balances ||... |uint256 _supply ||... |... ||address _implementation | | <= specified|... | |

openzeppelin-contracts/ERC1967Upgrade.sol at 83644fdb6a9f75a652d2fe2d96cb26073a14f6f8 · OpenZeppelin/openzeppelin-contracts

hardhat-storage-layout

如何知道合約的 Storage Layout 呢？這邊推薦一個 Hardhat Plugin，按照文件就能得到合約的 Storage Layout。

Ethereum development environment for professionals by Nomic Labs

Reference

Understanding Ethereum Smart Contract Storage

Collisions of Solidity Storage Layouts

Proxy Upgrade Pattern - OpenZeppelin Docs

Solidity Data Collision was originally published in Taipei Ethereum Meetup on Medium, where people are continuing the conversation by highlighting and responding to this story.

👏 歡迎轉載分享鼓掌

📜 [專欄新文章] Tornado Cash 實例解析

✍️ Johnson

📥 歡迎投稿： https://medium.com/taipei-ethereum-meetup #徵技術分享文 #使用心得 #教學文 #medium

Tornado Cash 是一個使用 zk-SNARKs 建立的 Dapp，它實現了匿名的代幣交易，這篇文章就用一些程式碼片段，來分享它是怎麼運作的。

本文為 Tornado Cash 研究系列的 Part 3，本系列以 tornado-core 為教材，學習開發 ZKP 的應用，另兩篇為：

Part 1：Merkle Tree in JavaScript

Part 2：ZKP 與智能合約的開發入門

Special thanks to C.C. Liang for review and enlightenment.

我們知道在以太坊上的交易紀錄都是公開的，你可以在 etherscan 上看到某個地址的所有歷史交易紀錄，當然地址是合約的話也是一樣。

也許創建一個新的錢包和地址就好了？假設一個情境是 Alice 想要匿名傳送 1 ETH 給 Bob，Alice 原本的錢包是 A，但她不想讓 A 地址傳給 Bob 的交易紀錄被看到，所以 Alice 創建另一個錢包 B，顯然 B 錢包是空的，Alice 必須把 A 錢包的 1 ETH 傳到 B 錢包，再用 B 錢包的地址傳給 Bob。

但問題就在於，只要追蹤 B 錢包的地址，就能看到 B 的歷史交易紀錄中 A 錢包曾經打幣給 B 錢包，於是到頭來交易還是被追蹤到了。

Tornado Cash 的解決方案，簡單來說，它是一份合約，當你要匿名傳送代幣時，就把一定數量的幣丟進合約裡 (Deposit)，此時你會拿到一個 note，長得像這樣：

tornado-eth-0.1-5-0x3863c2e16abc85d72b64d78c68fca5936db2501832e26345226efdfb2bc45804977f167d86b711bb6b4095ddaa646ec93f0a93ac4884a66c1d881f4fc985

note 就是一串字串，擁有這字串的人，就能提領 (Withdraw) 剛剛傳入合約的代幣。握有 note 就代表擁有提款的權利，所以 note 一旦被別人知道，別人就可以把錢給提走。

其中，後面那段亂碼，本篇文章就以「秘密」來稱呼，這個秘密是由 secret 與 nullifier 組成，而這兩個都是在鏈下隨機產生的亂數。

因此 Tornado 的合約基本上會有兩個函式：

Deposit

Withdraw

有興趣的人可以先到 Dapp 上先玩一次看看，使用 Goerli 測試網，這裡可以領 Goerli 的代幣：https://goerli-faucet.slock.it/

Deposit

我們就從 Deposit 開始說起，簡單來說， Deposit 是將資料儲存到合約的 Merkle Tree 上。

剛剛提到的秘密，它是在鏈下產生，由 secret 跟 nullifier 組成，合在一起之後也稱作 preimage，因為我們要對這個 preimage 進行 hash，就會成為 commitment。

合約中 Deposit 如下：

deposit 除了傳送代幣到合約之外，需填入一個參數 _commitment。

我們對 preimage 使用 Pedersen 作為 hash function 加密後產生 commitment，以偽代碼表示如下：

const preimage = secret + nullifier;const commitment = pedersenHash(preimage);

這個 commitment 會成為 Merkle Tree 的葉子，所以合約中的 _insert(commitment) 來自 MerkleTreeWithHistory.sol 的合約，將我們的資料插入 Merkle Tree，然後回傳一個 index 給你，告訴你這個 commitment 在 Merkle Tree 上的位置，最後一起發布成公開的 Deposit 事件。

我們知道 MerkleTree 是將一大筆資料兩兩做雜湊後產生一個唯一值 root，這個 root 就是合約上所儲存的歷史資料。

root 的特性就是只要底下的資料一有更動，就會重新產生新的 root。

所以只要一有用戶 deposit ，就會插入新的葉子到 Merkle Tree 上，於是就會產生新的 root，所以在合約中有一個陣列是用來儲存所有的 root 的 roots：

bytes32[ROOT_HISTORY_SIZE] public roots;

roots 是用來紀錄每個 deposit 的歷史，每一次 deposit 都會創造新的 root，而所有 root 都會被儲存進 roots 裡，於是當你要提領的時候，就要證明你的 commitment 所算出的 root 曾經出現在 roots 裡，代表曾經有 deposit 的動作，因此才可以進行提領。

Withdraw

在 Deposit 之前 Tornado Cash 就會在鏈下產生秘密後交給使用者，擁有這個秘密的人等於擁有提款的權利。

提領的時候，秘密會在鏈下計算後產生 proof，proof 是 withdraw 需要的參數，所以只要確保這個 proof 能夠被驗證，那麼代幣的接收地址 (recipient) 就可以隨便我們填，只要不填上當初拿來 deposit 用的地址，基本上就做到匿名交易的效果了。

也就是說，產生這個 proof 並提交給合約，能夠證明此人知道秘密，但卻不告訴合約秘密本身是什麼。

function withdraw(bytes calldata _proof, bytes32 _root, bytes32 _nullifierHash, address payable _recipient, address payable _relayer, uint256 _fee, uint256 _refund) external payable nonReentrant;

我們可以清楚看到 withdraw 函式裡沒有接收有關秘密的任何資訊作為參數，也就是秘密不會與合約有所接觸，也不會暴露在 etherscan 上。

回顧 ZKP 所帶來的效果：

鏈下計算

隱藏秘密

在 Tornado Cash 的例子中，我們用秘密來產生證明，完成的鏈下計算包括：

將秘密 hash 成 commitment

算出 Merkle Tree 的 root。

以下是簡化後的 withdraw.circom：

template Withdraw(levels) { signal input root; signal input nullifierHash;

signal private input nullifier; signal private input secret; signal private input pathElements[levels]; signal private input pathIndices[levels];

component hasher = CommitmentHasher(); // Pedersen hasher.nullifier <== nullifier; hasher.secret <== secret; hasher.nullifierHash === nullifierHash;

component tree = MerkleTreeChecker(levels); // MiMC tree.leaf <== hasher.commitment; tree.root <== root; for (var i = 0; i < levels; i++) { tree.pathElements[i] <== pathElements[i]; tree.pathIndices[i] <== pathIndices[i]; }}

component main = Withdraw(20);

從上述代碼就可以看出這份 circuit 的 private 變數有：

secret

nullifier

pathElements

pathIndices

而 public 變數有：

root

nullifierHash

如同我們一開始說過的，秘密就是指 secret 與 nullifier。這裡進行的鏈下計算就是對 secret 與 nullifier 雜湊成 commitment。而使用的 hash function 叫做 Pedersen。

在進行 Merkle Tree 的計算之前，我們還檢查了 nullifier 雜湊後的 nullifierHash 跟 public 變數 nullifierHash 是不是一樣的。

hasher.nullifierHash === nullifierHash;

接下來，開始計算 Merkle Proof，用意是確認經過雜湊後的 commitment 有沒有出現在 Merkle Tree 上，所以我們的 private input 還有 pathElements 與 pathIndices（詳情參考 Part 1 Merkle Tree in JavaScript），讓它跑一趟 Merkle Proof 的計算，最後就能夠算出一個 root，再確認計算後的 root 與我們的 public 變數 root 是否一樣。

tree.root <== root;

於是我們就能產生一個 ZKP 的證明 — 證明 private 變數：secret, nullifier, pathElements, pathIndices 可以計算出 public 變數：root 與 nullifierHash。

把這個證明提交給合約，合約透過 Verifier 驗證 proof 是否正確，以及必須事先確認：

public 變數 root 有在合約的 roots 裡面。

public 變數 nullifierHash 在合約中是第一次出現。

以下附上完整的 withdraw 原始碼：

必須注意 ZKP 是向合約證明使用者填入的 secret 和 nullifier 可以計算出某個 root，但無法保證這個 root 曾經在合約的 roots 歷史上。

所以合約的 withdraw 中，除了 verifyProof 之外，還要事先檢查 ZKP 算出來的 root 是不是真的在歷史上發生過，所以需要 isKnownRoot 的檢查：

function isKnownRoot(bytes32 _root) public view returns(bool)

必須先檢查 isKnownRoot 後才能進行 verifyProof。

經過 verifyProof 驗證成功後，合約就開始進行提款的動作，也就會將代幣傳到 recipient 的地址，最後拋出 Withdrawal 的事件。

nullifier 與 nullifierHash

為什麼我們的秘密不是只有 secret 還要額外加一個 nullifier？

簡單來說，這是為了防止已經提領過的 note 又再提領一次，也就是所謂的 double spend。

require(!nullifierHashes[_nullifierHash], "The note has been already spent");

可以看到 withdraw 需要填入參數 nullifierHash，跟 isKnownRoot 一樣的狀況，我們需要對電路的 public 變數先經過一層檢查之後，才能帶入到 verifyProof 裡面。

nullifierHash 可以理解為這個 note 的 id，但它不會連結到 deposit，因此可以用來紀錄這個 note 是否已經被提領過。

所以當 verifyProof 驗證成功之後，我們要紀錄 nullifierHash 已完成提領：

nullifierHashes[_nullifierHash] = true;

有關為什麼需要事先檢查 public 變數後，才能帶入 verifyProof ，可以參考 Part 2：ZKP 與智能合約的開發入門 提到的 publicSignals 的部分。

附上 Tornado Cash 的架構圖：

簡化版的 tornado-core

tornado-core 的程式碼很簡潔漂亮，所以我模仿該專案自己實作一遍：

simple-tornado：https://github.com/chnejohnson/simple-tornado

這份專案只完成了 tornado-core 的核心部分，不一樣的是我的開發環境使用 hardhat 與 ethers 寫成，而 circom 與 snarkjs 使用官方當前的版本，合約用 0.7.0，測試使用 Typescript 。

比起兩年前的 tornado-core ，simple-tornado 使用的技術更新，可能更適合初學者理解這份專案，但是它有 bug…我在 issues 的地方有紀錄說明。

在開發的過程中，我的順序是先從最小單位的 MiMC hash function 開始玩，發現必須 javascript 算一次 hash、solidity 算一次、circom 再算一次，確保這三個語言對同一個值算出同樣的 hash 之後，才能放心去做更複雜的 Merkle Tree。

總結

我們可以看到 Tornado Cash 簡單的兩個函式：Deposit 與 Withdraw，透過將代幣送入合約後再提領到另一個地址的流程，應用 ZKP 達成匿名的交易。

除了斷開 Deposit 與 Withdraw 的地址關聯性之外，Tornado Cash 還有做了一層「藏樹於林」的隱私防護，這部份的解釋就請參考 ZKP 讀書會 Tornado Cash。

網路上很多關於 ZKP 的文章或專案都是在 2019 年後出產的，經過許多人對這項技術的嘗試，讓我們對 ZKP 有了更清晰的理解，如今兩年後，開發工具也變得更加成熟，期待未來在 web 隱私議題上能看到更多 ZKP 大放異彩的應用。

原始碼

tornado-core

simple-tornado

參考資料

ZKP 讀書會 Tornado Cash

Tornado Privacy Solution Cryptographic Review

Tornado Cash 實例解析 was originally published in Taipei Ethereum Meetup on Medium, where people are continuing the conversation by highlighting and responding to this story.

👏 歡迎轉載分享鼓掌

📜 [專欄新文章] 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.

👏 歡迎轉載分享鼓掌