📜 [專欄新文章] 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.
👏 歡迎轉載分享鼓掌
proxy pattern 在 Taipei Ethereum Meetup Facebook 的最讚貼文
📜 [專欄新文章] 2019 台北以太坊社群回顧
✍️ Juin Chiu
📥 歡迎投稿: https://medium.com/taipei-ethereum-meetup #徵技術分享文 #使用心得 #教學文 #medium
很快地,2019 年過去了,台北以太坊社群(TEM)也滿 3 歲了,過去一年,TEM 完成了許多重大的里程碑:
舉辦台灣最大的區塊鏈技術研討會 Crosslink
主持台灣開源界最大的研討會 COSCUP 的區塊鏈議程
參加世界最大的區塊鏈技術研討會 DEVCON
Medium 專欄累積 30+ 篇優質文章
Youtube 頻道累積 50+ 個技術演講
在這篇文章中,我們首先來審視 2019 年以太坊取得重大進展的技術:以太坊2.0與零知識證明,接著再回顧 TEM 於 2019 的優質專欄文章。
*本文由 Juin Chiu 與 Chih-Cheng Liang 共同整理
以太坊重大進展
以太坊2.0的信標鏈
對一般大眾最重要最能吸收的事情大概是 Eth2.0 的信標鏈有測試網路了。透過儀表板網站 www.beaconcha.in 可以看見 Prysmatic Labs 團隊的測試網路的動態。細節很多,但本文就只談這張圖最上面有出現的東西。
在 Eth2.0 沒有挖礦和礦工了,取而代之的是抵押以太幣的驗證者(Validator)來成為資料的寫入者。因此也沒有「區塊時間」這個詞了,新協定以 12 秒為一個「時段」(Slot),信標鏈隨機分配驗證者在指定的時間點產出區塊。在 32 個時段的時間,稱為一個「時期」(Epoch),約 6.4 分鐘,信標鏈會處理驗證者的賞、罰、進、出。在儀表板的左上角可以看到 Epoch 與 Slot 的數字,代表距離最早最古老的區塊多久了。
要怎麼成為驗證者呢?首先要在以太坊 1.0 主網路的抵押合約上,送出一筆交易(在信標鏈測試網路則是送到 Goerli 測試網路)。這筆交易會註冊驗證者的公鑰,並且存入押金(在正式網路是 32 ETH ,測試網路則是 3.2 ETH)。送完之後就排隊等待信標鏈激活驗證者,驗證者就需要開始執行信標鏈分配的任務了。在畫面中間可以看到左邊是 27539 個活躍的驗證者,右邊則是有 4623 個排隊進入的。
在這種基於押金的網路,系統的威脅來自於攻擊者買通大量驗證者,送出矛盾訊息,致使於系統不同節點無法取得共識,鏈資料不可挽回的分叉為兩條。因此系統累積的總押金越多,代表攻擊者成本越高。畫面最右上角左邊即為總押金,右邊為平均一個驗證者的餘額。
假期間和親朋好友一起跑一個驗證者節點,是個活絡氣氛的好活動。要做到這件事,目前 Prysm 客戶端有最友善的介面,請點 連結。程式也用 Docker 包好了,免煩惱安裝。
也記得 Eth2.0 協定有 9 個團隊 用不同程式語言實作。例如:有 Python 語言的客戶端 Trinity ,以及 Rust 語言客戶端 Lighthouse。基本上不用擔心找不到自己喜歡的程式語言的實作。
零知識證明
2019 年,零知識證明的理論與應用也突飛猛進,Kimi Wu 剛好寫了一篇很棒的文獻調查。
前年底提出的 zk rollup,目前由 Matter Labs 在開發,Matter Labs更在上個月(2019/12)發表了 ZK Sync,解決了因為產生證明(proof)而延伸的延遲問題。
此外 Iden3 跟 ConsenSys 也有 zk rollup 的專案。在以太坊研究論壇有基於 zk rollup 的一個提案,是可以達到 匿名性的 zk rollup。
Semaphore是一個基於零知識證明的一個訊號系統,發送者可以不揭露身份的狀況下廣播任何訊息(an arbitrary string)。 Semaphorejs 延續 Semaphore 的核心概念,並將整個概念更加完整化,從前端網頁到後端服務。
這兩年才發表的 zk-STARKs,也在去年年初跟 0x 合作,推出基於 zk-STARKs 的 去中心化交易所。
在技術上,去年下半年有新的論文,使用 DARK compiler 可以讓 SNARKs 達到公開性(Transparent)。還有 MARLIN, SONIC, PLONK 等可通用且可更新的可信設定(trusted setup)。STARKs 的 FRI 驗證方式也默默地跟 SNARKs 做結合。(東西越來越多,根本看不完 QQ)
零知識證明在區塊鏈的重要用途就是「擴展」和「隱私」。技術上的進展,一般可以觀察證明方產出證明的時間、證明的資料大小、驗證方驗證的時間、需不需要可信設定、可信設定有什麼限制、以及抵抗量子電腦的能力。
社群專欄優質文章
Crossslink 2019
Crosslink 2019 Taiwan|以太坊 2.0 的未來藍圖及挑戰
Crosslink Recap: Design pattern: build your first profitable DApp and smart contract
Private key security and protection / 私錀的安全與保護 — Tim Hsu
Crosslink 2019 Taiwan|LibraBridge: 橋接 Libra 與 Ethereum
Aragon Fundraising:下一代的去中心化募資平台
The next generation Ethereum Virtual Machine — Ewasm VM
libp2p — 模組化的點對點網路協議
教學(Tutorial)
一分鐘做出自己的代幣購買App
Web3 Java 開發:用 Geth、Ganache 及 Infura 測試和 Smart Contract 互動
Let’s Capture The Flag! Etheruem CTF Tutorial 從零開始破解智能合約漏洞!
Your First Transaction on Facebook Libra — 動手玩 Libra
ELI5! 區塊鏈到底在幹嘛?
共識協定(Consensus)
Casper FFG:以實現權益證明為目標的共識協定
Casper FFG 與 Casper CBC 的瑜亮情結
若想搞懂區塊鏈就不能忽視的經典:PBFT
密碼學(Cryptography)
Ethereum RNG (RANDAO & VDF)
深入瞭解 zk-SNARKs
瞭解神秘的 ZK-STARKs
隱私性與匿名性(Privacy and Anonymity)
新一代加密貨幣Grin和MimbleWimble區塊鏈解析
Monero.門羅幣 隱匿交易的基礎介紹
隱私、區塊鏈與洋蔥路由
資料可得性(Data Availability)
Data Availability on Ethereum 2.0 Light Node
Fraud and Data Availability Proofs
點對點網路(p2p Network)
連Ethereum都在用!用一個例子徹底理解DHT
針對DHT的花式攻擊與精簡對策
智能合約(Smart Contract)
深入解析Solidity合約
Upgradable Smart Contracts using zos
Reason Why You Should Use EIP1167 Proxy Contract. (With Tutorial)
去中心化金融(DeFi)
DeFi 項目《Uniswap》完整解析(一)Uniswap 是什麼?
解析 DeFi 項目《Uniswap》(二)Uniswap 如何使用?
去中心化身份(DID)
我們與「身份自主」的距離
其他(Miscellaneous)
論言論自由
作為負債的控制
0x 黑客松 — 獲獎作品回顧與分析
技術解析台灣交易所BitoPro駭客攻擊
總結
2019 是個樸實無華但充實的一年,除了在底層技術方面有所進展,在應用方面,例如去中心化金融(DeFi)與去中心化身份(DID),也逐漸獲得大眾的興趣,期待 2020 年區塊鏈能為這世界帶來更多驚奇!
2019 台北以太坊社群回顧 was originally published in Taipei Ethereum Meetup on Medium, where people are continuing the conversation by highlighting and responding to this story.
👏 歡迎轉載分享鼓掌
proxy pattern 在 Taipei Ethereum Meetup Facebook 的最佳解答
📜 [專欄新文章] Reason Why You Should Use EIP1167 Proxy Contract. (With Tutorial)
✍️ Ping Chen
📥 歡迎投稿: https://medium.com/taipei-ethereum-meetup #徵技術分享文 #使用心得 #教學文 #medium
EIP1167 minimal proxy contract is a standardized, gas-efficient way to deploy a bunch of contract clones from a factory.
1. Who may consider using EIP1167
For some DApp that are creating clones of a contract for its users, a “factory pattern” is usually introduced. Users simply interact with the factory to get a copy. For example, Gnosis Multisig Wallet has a factory. So, instead of copy-and-paste the source code to Remix, compile, key in some parameters, and deploy it by yourself, you can just ask the factory to create a wallet for you since the contract code has already been on-chain.
The problem is: we need standalone contract instances for each user, but then we’ll have many copies of the same bytecode on the blockchain, which seems redundant. Take multisig wallet as an example, different multisig wallet instances have separate addresses to receive assets and store the wallet’s owners’ addresses, but they can share the same program logic by referring to the same library. We call them ‘proxy contracts’.
One of the most famous proxy contract users is Uniswap. It also has a factory pattern to create exchanges for each ERC20 tokens. Different from Gnosis Multisig, Uniswap only has one exchange instance that contains full bytecode as the program logic, and the remainders are all proxies. So, when you go to Etherscan to check out the code, you’ll see a short bytecode, which is unlikely an implementation of an exchange.
0x3660006000376110006000366000732157a7894439191e520825fe9399ab8655e0f7085af41558576110006000f3
What it does is blindly relay every incoming transaction to the reference contract 0x2157a7894439191e520825fe9399ab8655e0f708by delegatecall.
Every proxy is a 100% replica of that contract but serving for different tokens.
The length of the creation code of Uniswap exchange implementation is 12468 bytes. A proxy contract, however, has only 46 bytes, which is much more gas efficient. So, if your DApp is in a scenario of creating copies of a contract, no matter for each user, each token, or what else, you may consider using proxy contracts to save gas.
2. Why use EIP1167
According to the proposal, EIP is a “minimal proxy contract”. It is currently the known shortest(in bytecode) and lowest gas consumption overhead implementation of proxy contract. Though most ERCs are protocols or interfaces, EIP1167 is the “best practice” of a proxy contract. It uses some EVM black magic to optimize performance.
EIP1167 not only minimizes length, but it is also literally a “minimal” proxy that does nothing but proxying. It minimizes trust. Unlike other upgradable proxy contracts that rely on the honesty of their administrator (who can change the implementation), address in EIP1167 is hardcoded in bytecode and remain unchangeable.
That brings convenience to the community.
Etherscan automatically displays code for EIP1167 proxies.
When you see an EIP1167 proxy, you can definitely regard it as the contract that it points to. For instance, if Etherscan finds a contract meets the format of EIP1167, and the reference implementation’s code has been published, it will automatically use that code for the proxy contract. Unfortunately, non-standard EIP1167 proxies like Uniswap will not benefit from this kind of network effect.
3. How to upgrade a contract to EIP1167 compatible
*Please read all the steps before use, otherwise there might have problems.
A. Build a clone factory
For Vyper, there’s a function create_with_code_of(address)that creates a proxy and returns its address. For Solidity, you may find a reference implementation here.
function createClone(address target) internal returns (address result){ bytes20 targetBytes = bytes20(target); assembly { let clone := mload(0x40) mstore(clone, 0x3d602d80600a3d3981f3363d3d373d3d3d363d73000000000000000000000000) mstore(add(clone, 0x14), targetBytes) mstore(add(clone, 0x28), 0x5af43d82803e903d91602b57fd5bf30000000000000000000000000000000000) result := create(0, clone, 0x37) }}
You can either deploy the implementation contract first or deploy it with the factory’s constructor. I’ll suggest the former, so you can optimize it with higher runs.
contract WalletFactory is CloneFactory { address Template = "0xc0ffee"; function createWallet() external returns (address newWallet) { newWallet = createClone(Template); }}
B. Replace constructor with initializer
When it comes to a contract, there are two kinds of code: creation code and runtime code. Runtime code is the actual business logic stored in the contract’s code slot. Creation code, on the other hand, is runtime code plus an initialization process. When you compile a solidity source code, the output bytecode you get is creation code. And the permanent bytecode you can find on the blockchain is runtime code.
For EIP1167 proxies, we say it ‘clones’ a contract. It actually clones a contract’s runtime code. But if the contract that it is cloning has a constructor, the clone is not 100% precise. So, we need to slightly modify our implementation contract. Replace the constructor with an ‘initializer’, which is part of the permanent code but can only be called once.
// constructorconstructor(address _owner) external { owner = _owner;}// initializerfunction set(address _owner) external { require(owner == address(0)); owner = _owner;}
Mind that initializer is not a constructor, so theoretically it can be called multiple times. You need to maintain the edge case by yourself. Take the code above as an example, when the contract is initialized, the owner must never be set to 0, or anyone can modify it.
C. Don’t assign value outside a function
As mentioned, a creation code contains runtime code and initialization process. A so-called “initialization process” is not only a constructor but also all the variable assignments outside a function. If an EIP1167 proxy points to a contract that assigns value outside a function, it will again have different behavior. We need to remove them.
There are two approaches to solve this problem. The first one is to turn all the variables that need to be assigned to constant. By doing so, they are no longer a variable written in the contract’s storage, but a constant value that hardcoded everywhere it is used.
bytes32 public constant symbol = "4441490000000000000000000000000000000000000000000000000000000000";uint256 public constant decimals = 18;
Second, if you really want to assign a non-constant variable while initializing, then just add it to the initializer.
mapping(address => bool) public isOwner;uint public dailyWithdrawLimit;uint public signaturesRequired;
function set(address[] _owner, uint limit, uint required) external { require(dailyWithdrawLimit == 0 && signaturesRequired == 0); dailyWithdrawLimit = limit; signaturesRequired = required; //DO SOMETHING ELSE}
Our ultimate goal is to eliminate the difference between runtime code and creation code, so EIP1167 proxy can 100% imitate its implementation.
D. Put them all together
A proxy contract pattern splits the deployment process into two. But the factory can combine two steps into one, so users won’t feel different.
contract multisigWallet { //wallet interfaces function set(address[] owners, uint required, uint limit) external;}contract walletFactory is cloneFactory { address constant template = "0xdeadbeef"; function create(address[] owners, uint required, uint limit) external returns (address) { address wallet = createClone(template); multisigWallet(wallet).set(owners, required, limit); return wallet; }}
Since both the factory and the clone/proxy has exactly the same interface, no modification is required for all the existing DApp, webpage, and tools, just enjoy the benefit of proxy contracts!
4. Drawbacks
Though proxy contract can lower the storage fee of deploying multiple clones, it will slightly increase the gas cost of each operation in the future due to the usage of delegatecall. So, if the contract is not so long(in bytes), and you expect it’ll be called millions of times, it’ll eventually be more efficient to not use EIP1167 proxies.
In addition, proxy pattern also introduces a different attack vector to the system. For EIP1167 proxies, trust is minimized since the address they point to is hardcoded in bytecode. But, if the reference contract is not permanent, some problems may happen.
You might ever hear of parity multisig wallet hack. There are multiple proxies(not EIP1167) that refer to the same implementation. However, the wallet has a self-destruct function, which empties both the storage and the code of a contract. Unfortunately, there was a bug in Parity wallet’s access control and someone accidentally gained the ownership of the original implementation. That did not directly steal assets from other parity wallets, but then the hacker deleted the original implementation, making all the remaining wallets a shell without functionality, and lock assets in it forever.
https://cointelegraph.com/news/parity-multisig-wallet-hacked-or-how-come
Conclusion
In brief, the proxy factory pattern helps you to deploy a bunch of contract clones with a considerably lower gas cost. EIP1167 defines a bytecode format standard for minimal proxy and it is supported by Etherscan.
To upgrade a contract to EIP1167 compatible, you have to remove both constructor and variable assignment outside a function. So that runtime code will contain all business logic that proxies may need.
Here’s a use case of EIP1167 proxy contract: create adapters for ERC1155 tokens to support ERC20 interface.
pelith/erc-1155-adapter
References
https://eips.ethereum.org/EIPS/eip-1167
https://blog.openzeppelin.com/on-the-parity-wallet-multisig-hack-405a8c12e8f7/
Donation:
pingchen.eth
0xc1F9BB72216E5ecDc97e248F65E14df1fE46600a
Reason Why You Should Use EIP1167 Proxy Contract. (With Tutorial) was originally published in Taipei Ethereum Meetup on Medium, where people are continuing the conversation by highlighting and responding to this story.
👏 歡迎轉載分享鼓掌
proxy pattern 在 Proxy Design Pattern Tutorial - YouTube 的美食出口停車場
Code is Here: http://goo.gl/dzqhV Welcome to my Proxy Design Pattern Tutorial! The Proxy design pattern limits access to just the methods ... ... <看更多>