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

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

👏 歡迎轉載分享鼓掌

📜 [專欄新文章] 2021 區塊鏈開發入門
✍️ Johnson Chen
📥 歡迎投稿： https://medium.com/taipei-ethereum-meetup #徵技術分享文 #使用心得 #教學文 #medium

在我大學的時候，除了學習網頁前端之外，因為課程報告的需要接觸到以太坊(Ethereum)，於是開始學寫智能合約，包括它使用的程式語言 solidity。

工作以後鮮少再碰以太坊的相關技術，直到最近想重新把以太坊學起來，故而決定寫這篇文章，讓初次接觸區塊鏈與智能合約的人更好地進入開發者的世界。這篇文章不只面向開發者，同時也希望能夠給對區塊鏈有興趣的人，指引一條清晰的學習路線。

關於區塊鏈

區塊鏈會被廣為人知，無非是因為虛擬貨幣的出現，而虛擬貨幣的鼻祖就是比特幣。在比特幣出現以前，沒有一個能夠在全球網路上通用的數位貨幣；在比特幣出現之後，才真的實現了數位化的貨幣，能夠在全球網路上流通。

這樣的技術性突破，blockchain 的名字從比特幣白皮書中被萃取出來，而這項技術也被更多人拿去做研發以及創新。

區塊鏈這項技術的特性可以簡單概括為兩點：去中心化(decentralized)與不可竄改(immutable)。去中心化有程度上的差別，在公共網路上由世界各地的節點共同維護的區塊鏈，去中心化程度較高；相較之下，私人企業開發由特定節點來驗證交易的區塊鏈，去中心化程度較低。

為什麼是以太坊？

這年頭區塊鏈三個字大行其道，大部分都是為區塊鏈而區塊鏈的商業炒作。容許我獨斷地說，以太坊才是區塊鏈應用的大門。

以太坊由全球最大的區塊鏈社群組成，提供一個去中心化的虛擬機器（Ethereum Virtual Machine）來處理「智能合約」，它是一個公共的區塊鏈平台，逛逛以太坊的官網吧！

智能合約

在以太坊區塊鏈中有所謂的智能合約，智能合約能夠部屬到以太坊區塊鏈上，合約即程式碼，放到區塊鏈上就不能再更新，只能執行合約上的程式，持有以太幣的人能夠與合約進行交易。把智能合約想像成是一台自動販賣機，把錢(以太幣)投進去，飲料會掉出來(合約上的程式會被執行)。

在現實生活中，簽訂合約的雙方認為合約有效而且可以被信任，是因為有國家法律來保障，違反合約可能會受到法律制裁；而用以太幣與智能合約互動，認為智能合約可以被信任，是因為智能合約的不可竄改性 — 以太坊虛擬機會毫無偏袒、完全中立、冰冷不帶任何感情地執行智能合約上已經寫好的程式碼。

建立在智能合約之上的虛擬貨幣

事實上，以太坊擴大了區塊鏈這項技術的應用層面。回頭想想，比特幣來自區塊鏈技術，某個人若想打造一款同比特幣一樣的虛擬貨幣，就得模仿比特幣去建造一個自己的虛擬貨幣區塊鏈，一個區塊鏈網路要能夠有效運作並非易事，還需要節點、需要靠人挖礦去驗證交易。此時，若使用以太坊的智能合約，撰寫虛擬貨幣需要的程式碼，將合約部屬到以太坊區塊鏈上，叮咚！他就可以發行自己的虛擬貨幣，根本不必再去建造底層的區塊鏈，也不用想挖不挖礦了。

此時會發現以太坊就像是一個區塊鏈平台，你不需要親手打造區塊鏈網路，即可享有區塊鏈去中心化與不可竄改的特性。與其他智能合約的開發者共同使用以太坊虛擬機 EVM(Ethereum Virtual Machine)，在 EVM 上部屬無上限個智能合約。

以太坊是一項基礎建設，底層區塊鏈幫你架設好，開發者便有更多時間去發想應用到網頁、手機、或物連網設備上，以下是一段簡單的智能合約，該合約創造了一個虛擬貨幣簡稱 MAT…

直接進入開發領域 — 線上編輯器 Remix

Remix 是開發智能合約的線上編輯器，進入Remix官網，點選 Create New File 以後，把上方程式碼複製貼上。在左側欄位中有 solidity compiler 的選項，確認一下左側欄第一列顯示的版本，調成 0.7.0 (上方程式碼使用的版本)，就可以按下下方 compile 的按鈕，將智能合約「編譯」成 bytecode（給機器讀的語言）。

接著我們要部屬合約到區塊鏈上，首先到左側欄位點選 DEPLOY & RUN TRANSACTIONS 的選項，可以看到環境是 javascript VM，這是指現在要部屬到的測試用虛擬機。按下下方的按鈕 Deploy 即可將合約「部屬」到 javascript VM 上。成功部屬後，你會發現 ACCOUNT 所持有的以太幣，從 100 變成 99.9999…，我們得知部屬智能合約需要花費一點點以太幣。

左側下方會有 Deployed Contracts，點開來就會列出合約上可供呼叫的函式，點那些函式就能與剛剛部屬上去的智能合約進行互動了。

有些函式呼叫會引發交易，所以需要以太幣，有些則不用。在 ACCOUNT 的地方可以展開來，它提供許多的地址 (address)，也就是錢包，每個錢包裡面預設給你 100 顆以太幣，試著用那些地址去操作智能合約，你就能慢慢體會什麼是建立在以太坊之上的虛擬貨幣了。

真正的開發者世界

實際上開發智能合約只能算是以太坊開發的其中一部分，其他包括以太坊區塊鏈擴容方案、節點驗證等等又是另一個開發領域了，那部份我就沒有研究太多。而智能合約的開發是比較接近應用層面的，透過網頁前端或手機應用程式，與智能合約進行互動，稱作 Dapp(Decentralized App) 的開發，也象徵著網際網路走向 web3.0 的時代。

學習 solidity 語言，除了看硬生生的官方文件之外，我推薦去玩cryptozombies，我本身就是從這款網頁遊戲中學習這門語言，聽說是連小孩子都能輕易學習的教材。

除了學 solidity 之外，網路上還有很多方便的開發工具，開發者主要是運用這些工具做測試、自動化部屬、串接前端等等。許多網路上的教學文章會使用 Truffle + Ganache + web3.js 來建置開發環境。但我在這裡推薦另一款開發環境的架構，如果是新手直接從 hardhat 開始也是非常適合的，hardhat 的教學文章寫得清楚完整，本篇文章使用的程式碼也是從 hardhat-hackathon-boilerplate 這個專案而來。hardhat 使用的開發環境是 Waffle + Hardhat + ethers，它幫你把開發環境處理的簡單又舒服，讓開發者可以專注在開發智能合約上。

OpenZeppelin 是很有名的智能合約套件庫，開發時可以引入它的智能合約。智能合約很講究安全性，稍微沒寫好就可能被駭客鑽漏洞，虛擬貨幣就被盜走了！OpenZeppelin 提供的 SafeMath 很常被引入到專案，對新手來說看 OpenZeppelin 的合約也是很好的學習管道。此外，官方也建了一個學習網站ethernaut，主要在教導如何寫出安全性夠強的智能合約，可惜網站在我寫這篇文章的時間一直處於維修不能用的狀態。

最後再介紹一款實際上線的智能合約專案：Argent。它是一款運用智能合約來做虛擬貨幣錢包的公司，除了使用他們的錢包之外，也可以看看他們的智能合約是怎麼寫的，感受一下專業的程式碼架構與寫法。

小結

這篇文章希望能幫助到想了解區塊鏈這項技術的人，同時也想呈現一個智能合約的開發生態系，你大可以不必花太多力氣去了解密碼學、挖礦、節點、共識機制等等五花八門的專有名詞；反之，你可以專注在智能合約的開發，或回到本質去思考去中心化的用意、以及為什麼不可竄改的特性那麼重要。

智能合約除了做虛擬貨幣之外，也能夠做投票系統，原本以貨幣為起始點的區塊鏈技術，是智能合約的出現擴大了區塊鏈更具彈性的用途，這圈子需要更多的開發者來探勘這片新大陸。

尤其鼓勵人文社會科學的人才，無論是哲學、政治、經濟、法律或社會等各方領域，試著撇開人工智慧將主導未來社會的發展路線，與之截然不同的另一種形式：人類社會能否依靠科技的力量，促成彼此之間的合作，創造更有效率的市場、更公平的治理方式？

延伸閱讀：激進市場（Radical Markets: Uprooting Capitalism and Democracy for a Just Society）

2021 區塊鏈開發入門 was originally published in Taipei Ethereum Meetup on Medium, where people are continuing the conversation by highlighting and responding to this story.

👏 歡迎轉載分享鼓掌

📜 [專欄新文章] 可升級合約介紹 - 鑽石合約（EIP-2535 Diamond standard）
✍️ Kimi Wu
📥 歡迎投稿： https://medium.com/taipei-ethereum-meetup #徵技術分享文 #使用心得 #教學文 #medium

Photo by Evie S. on Unsplash

前言

可升級合約簡單來說是透過 proxy contract（代理合約）來達成，藉由代理合約去呼叫欲執行的合約，若要升級，則把代理合約中的指向的地址換為新的合約地址即可。而執行的方式則是透過 delegateCall，但 delegateCall 不會更動目標合約的狀態。所以要怎麼處理變數，就是一門學問了。

舉例來說，contract B 有個變數 uint256 x，初始值為 0， 而 function setX(uint256)，可以改變 x 的值。proxy contract A 使用 delegatecall 呼叫 contract B 的 setX(10)，交易結束後，contract B中的 x 依然還是 0。

OpenZeppelin 提出了三種實作方式，可以做到可升級合約，細節可參考 Proxy Patterns，而最終的實作選用了 Unstructured Storage的這個方式，這種方式對於開發較友善，開發時不需特別處理 state variables（不過升級時就需要特別注意了）。而這篇主要是介紹 Diamond standard，OpenZeppelin 的可升級合約就不多做介紹。

USDC V2 : Upgrading a multi-billion dollar ERC-20 token 詳細地介紹代理合約跟變數儲存之間的關係，不了解升級合約的原理，建議先看看。

鑽石合約

名詞介紹

diamond：合約本體，是一個代理合約，無商業邏輯

facet：延伸的合約（實際商業邏輯實作的合約）

loupe：也是一個 facet，負責查詢的功能。可查詢此 diamond所提供的 facet與facet所提供的函式

diamondCut：一組函式，用來管理（增加/取代/減少）此 diamond合約所支援的功能

Loupe

直接來看 loupe的介面，從宣告就能很清楚暸解 diamond合約的實作方式，loupe宣告了一個結構 Facet，Facet結構包含一個地址及 function selector 陣列，所以我們只需要記錄一個 Facet陣列就可以得知這個 diamond 合約有多少個延伸合約及所支援的功能（loupe只定義結構，而實際變數是存在diamon合約中的）。也就是 diamond合約中只記錄延伸合約的地址及其支援的 function selectors，及少數 diamond合約的管理邏輯，並無商業邏輯，因此可以外掛非常非常多的合約上去（就像一個Hub），也就可以突破一個合約只有２４Ｋ的限制。

// A loupe is a small magnifying glass used to look at diamonds.interface IDiamondLoupe { struct Facet { address facetAddress; bytes4[] functionSelectors; } function facets() external view returns (Facet[] memory facets_); function facetFunctionSelectors(address _facet) external view returns (bytes4[] memory facetFunctionSelectors_); function facetAddresses() external view returns (address[] memory facetAddresses_); function facetAddress(bytes4 _functionSelector) external view returns (address facetAddress_);}

DiamondCut

至於 facet在 diamond合約上的註冊或是修改，就由 diamondCut負責，從以下程式碼可以清楚瞭解其功能（EIP中有規範，每次改變都需要發送DiamondCut事件）

interface IDiamondCut { enum FacetCutAction {Add, Replace, Remove} // Add=0, Replace=1, Remove=2 struct FacetCut { address facetAddress; FacetCutAction action; bytes4[] functionSelectors; } function diamondCut( FacetCut[] calldata _diamondCut, address _init, bytes calldata _calldata ) external; event DiamondCut(FacetCut[] _diamondCut, address _init, bytes _calldata);}

Diamond合約

接下來就是最核心的部分 — diamond本體合約。以下是官方的範例，方法上跟 OpenZeppelin 一樣使用 fallback 函式跟 delegateCall 。

呼叫合約所不支援的函式，就會去執行 fallback 函式，fallback 函式中再透過 delegateCall 呼叫 facet 合約相對應的函式

fallback() external payable { address facet = selectorTofacet[msg.sig]; require(facet != address(0)); // Execute external function from facet using delegatecall and return any value. assembly { calldatacopy(0, 0, calldatasize()) let result := delegatecall(gas(), facet, 0, calldatasize(), 0, 0) returndatacopy(0, 0, returndatasize()) switch result case 0 {revert(0, returndatasize())} default {return (0, returndatasize())} }}

主要的差異在於變數的處理，OpenZepplin 是針對單一合約設計的代理合約（也就是每個合約都有自己的代理合約），所以無法處理單一代理合約儲存多個合約的變數（state variables）的狀況（後有圖例）。先由官方的範例程式來了解是怎麼處理變數的

在官方的範例中，都是以更改合約 owner 為例子

首先看到 DimaondStorage這個結構，結構中的前面三個變數都是在維持 diamond合約的運作（同上面loupe的範例），最後一個變數 contractOwner就是我們商業邏輯中所需的變數。
接著看到 function diamondStorage()，取變數的方式就跟OpenZeppelin 儲存特定變數方式一樣（EIP-1967），是把變數存到一個遠方不會跟其他變數碰撞到的位置，在這裡就是從 DIMOND_STORAGE_POSITION 這個 storage slot 讀取。
在實作上就可以有 LibDiamond1 ，宣告DIMOND_STORAGE_POSITION1=keccak256("diamond.standard.diamond.storage1") ，負責處理另一組的變數。藉由這種方式讓每個 facet合約有屬於自己合約的變數， facet合約間就不會互相影響。而最下方的 setContractOwner 是實際使用的範例。

library LibDiamond {

bytes32 constant DIAMOND_STORAGE_POSITION = keccak256("diamond.standard.diamond.storage");

struct FacetAddressAndSelectorPosition { address facetAddress; uint16 selectorPosition; }

struct DiamondStorage { mapping(bytes4 => FacetAddressAndSelectorPosition) facetAddressAndSelectorPosition; bytes4[] selectors; mapping(bytes4 => bool) supportedInterfaces; // owner of the contract address contractOwner; }

function diamondStorage() internal pure returns (DiamondStorage storage ds) { bytes32 position = DIAMOND_STORAGE_POSITION; assembly { ds.slot := position } }

function setContractOwner(address _newOwner) internal { DiamondStorage storage ds = diamondStorage(); address previousOwner = ds.contractOwner; ds.contractOwner = _newOwner; emit OwnershipTransferred(previousOwner, _newOwner); }

每個 library 處理了一組或多組變數的存取， facet 合約透過 library 對變數做操作。也就是把變數存在diamond主體合約，延伸的 facet合約只處理邏輯，是透過 library 去操作變數。

下面圖中清楚地解釋了 facet合約，function selectors 與變數之間的關係，從最左上這邊有個 facets 的 map，紀錄了哪個 selector 在哪個合約中，例如func1, func2是 FacetA的函式。左下角宣告了變數，每組變數的存取如同上述 library 的方式處理。

https://eips.ethereum.org/EIPS/eip-2535#diagrams

在 diamond的設計中，每個 facet合約都是獨立的，因此可以重複使用（跟library 的概念一樣）

https://eips.ethereum.org/EIPS/eip-2535#diagrams

小結

diamond合約使用不同的設計來達成合約的可升級性，藉由這種Hub方式可隨時擴充/移除功能，讓合約不再受限於24KB的限制，此外充分的模組化，讓每次升級的範圍可以很小。最後，因為跟library一樣只處理邏輯，並無狀態儲存，所以可以重複被不同的diamond合約所使用。

雖然又不少好處，也是有些缺點。首先，術語名詞太多，facet, diamondCut, loupe等等（其實還有好幾個，不過沒有介紹到那些部分，所以沒有寫出來）。開發上不直覺，把變數跟邏輯拆開，若要再加上合約之間的繼承關係，容易搞混，不易維護。最後，gas的花費，在函式的讀取、呼叫，變數的存取、傳遞都會有不少的額外支出。Trail of Bits 專欄中有點出更多的缺陷 Good idea, bad design: How the Diamond standard falls short，不過作者也有反擊 Addressing Josselin Feist’s Concern’s of EIP-2535 Diamond Standard，有興趣的讀者可以自行看看、比較。

為了模組化及彈性，diamond合約在設計上有點太複雜（over engineering），會造成可讀性越差（這點也是Vyper誕生的原因之一），而可讀性越差就越容易產生bug、也越不容易抓到bug，而在defi專案中，一個小小的bug通常代表著大筆金額的損失 😱😱😱。

雖然如此，筆者還是覺得很酷，有些設計的思維仍然可以使用在自己的專案

ref:
EIP 2535
Diamond 實作
Addressing Josselin Feist’s Concern’s of EIP-2535 Diamond Standard
OpenZeppelin upgradeable contract

可升級合約介紹 - 鑽石合約（EIP-2535 Diamond standard） was originally published in Taipei Ethereum Meetup on Medium, where people are continuing the conversation by highlighting and responding to this story.

👏 歡迎轉載分享鼓掌