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

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

👏 歡迎轉載分享鼓掌

📜 [專欄新文章] [zkp 讀書會] Cairo 語言介紹

✍️ NIC Lin

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

Cairo 是 STARK 證明系統的其中一個編程語言，讓開發者能透過 Cairo 來使用 STARK，撰寫效能更高的 Dapp

Photo by Simon Berger on Unsplash

Warning：本篇會保持在 high level 的介紹，實際深入的部分請見文內附上的文檔或是官方開發者文件

背景介紹

建構於密碼學的零知識證明能提供計算的隱私性，但同時在區塊鏈生態系也被用來提升 Scalability — 我可以用 10 秒的運算資源來驗證原本耗費 1000 秒運算資源的計算過程

如同更多人熟悉的 SNARK，STARK 也是一個零知識證明的證明系統，但當前的 STARK 著重的是在 Scalability ，而非大家比較習以為常零知識證明提供的隱私性特質

其實目前基於 SNARK 的 Rollup 項目，例如 zkSync、Loopring、Aztec、zkopru，除了 Aztec 外，其他都是利用 SNARK 來增加 Scalability — 這些 Rollup 上資料都還是公開、沒有隱私性的

StarkWare 是目前唯一基於 STARK 的開發團隊

STARK 要加上隱私保護不會太難，只是 StarkWare 還沒有把這項功能放在未來規劃中

Cairo 簡介

標榜為圖靈完備的零知識證明系統語言，Cairo 對原本熟悉 Solidity 的開發者來說還是會感到比較難上手和陌生的。再加上套件庫還不夠充足，目前支援的雜湊函式是 Pedersen，數位簽章演算法是 ECDSA（相對於 SNARK，EdDSA 的效能反而比較差所以沒有支援）。
但 Cairo 還在早期開發的階段，相信開發體驗會越來越好的。

另外需要注意的是作為一個證明系統，會有 Prover 和 Verifier 的角色。而 STARK 的 Verifier 是公開的，但 Prover 軟體預計會有 License 保護。Prover 一般情況下不得用於商業用途，除非將 proof 上傳至官方的 Verifier。

最後要提及的是，第一版的 Cairo 是設計來方便開發者將 Dapp 的運算遷移至鏈下。不同於 Rollup，這個鏈下只會有它自己一個 Dapp。這個 Dapp 的項目方自己維護自己 Dapp 的 state。（ Rollup 則是 operator 維護所有 Dapp 的 state，Dapp 開發者不需自己操煩）
這可能有點難懂。如果你有在寫 Solidity，想像一下今天你在合約要用到合約裡宣告的 storage 變數時，你要自己提供 merkle proof 上來，證明這個storage 變數真的是這個值。這個就是開發者要自己維護 state 的意思。

而第二版的 Cairo 則是 StarkNet 裡使用的 Cairo（第一和第二版是不同編譯器），這版的 Cairo 就是作為 Dapp 在 Rollup 開發所使用 — 開發者可以在合約裡宣告變數，變數的值不需開發者維護，可以直接假設存在。
註1：StarkWare 不喜歡 Rollup 這個詞，他們覺得 Data Availability 的需求是一段光譜：不一定得要把 data 全都送上 L1，中間有其他方式可以做不同層級的 Data Availability。
註2：第一版和第二版實際上在官方版本裡是 0.0.1 及 0.0.2，在撰文當前最新版即是 0.0.2

官方網站：https://www.cairo-lang.org
開發者文件：https://www.cairo-lang.org/docs/

開發環境

Cairo 有提供像是 Remix 的瀏覽器 IDE：playground。裡面提供各種範例練習和挑戰，除了可以編譯，還可以直接生成並上傳 proof。
註：但有些功能還是沒辦法在 playground 裡使用，例如要給你的程式 custom input 時。這時候只能在本地端開發才能使用這個功能。

開發 Cairo 要先安裝python，我將開發者文件整理出來的資料統整在這個 hackmd 文檔裡：https://hackmd.io/w690dpAQTsKeKZv3oikzTQ
裡面包含簡介、設置本地開發環境以及 Cairo 基礎（因為篇幅原因，所以不將內容複製到這裡）
註：我把開發者文件裡的代碼整理到這裡：https://github.com/NIC619/cairo_practice/tree/master/practices
如果不想在研究開發者文件過程中，還要自己手動拼湊裡面例子的話，可以直接用整理好的代碼來執行。同時 repo 裡還有包含一些額外自己測試 Cairo 功能的範例。

深入 Cairo

在那份 hackmd 文檔裡的開頭，可以連結到第二部分 — 深入 Cairo 的部分。裡面也是從開發者文件裡擷取出來我覺得比較重要的部分。如果你要讀開發者文件的話，我建議從 Hello Cairo 開始，它會從例子切入，會比較好知道 Cairo 怎麼使用。接著如果要更深入了解，再去讀 How Cairo Works。

StarkNet Cairo

第二版的 Cairo 其實功能和第一版的 Cairo 是差不多的，所以不必擔心在開發者文件裡學到的 Cairo 在 StarkNet 版本會不能用或差很多。在讀完 Hello Cairo/How Cairo works 後，就可以接著看 Hello StarkNet。會很順利的切換到 StarkNet 版本的 Cairo。
註1：我整理的文檔裡是按照第一版 Cairo 所寫的
註2：如果你從開發者文件一路看下來，體驗過非 StarkNet 版的 Cairo，那你在體驗 StarkNet 版的 Cairo 時一定會發現這更像一般智能合約的使用方式 — 你可以用 view 函式查詢 storage 變數，可以用 external 函式去執行合約（非 StarkNet 版本不是這樣操作 Dapp 的，這邊因為篇幅原因沒有詳細介紹）。

非常建議嘗試兩種版本的 Cairo，你會知道 1. 操作一個單獨在 L2 的 Dapp 和2. 操作與其他 Dapp 共存在 Rollup 上的 Dapp 的不同。這對了解 L2 怎麼運行、需要哪些資料、為什麼需要這些資料非常有幫助。

0.0.2 版的 StarkNet Cairo 目前還缺少一些功能：

函式還沒辦法宣告陣列或 struct 型態的參數

合約和合約之間還沒辦法互動

L1 沒有辦法讀取到 L2 的資料，L2 也沒辦法讀取到 L1 的資料。如果要建立跨 L2 Bridge，這個功能非常重要。

補充及個人心得

STARK 的 proof size 相比於 SNARK 系列的 proof size 大很多，又其證明所包含的交易數量對 proof size 和驗證時間的影響不大，所以把很多筆交易一併做一個 proof 會是對 STARK 非常有利、節省成本的方式（SNARK、STARK 比較表）。但這同時也是一個缺點，如果你的 Dapp 或 Rollup 的 TPS 不高，那就只能等更久時間搜集多一點的交易，要不然就只能提高成本來維持驗證 proof 的頻率。

StarkWare和 zkSync 一樣都有 Rollup 宇宙的概念（ Rollup 宇宙的用詞並不精確，因為在他們的宇宙中不會所有子鏈都是 Rollup，而是會有依照 Data Availability 程度不同所區分的子鏈，像是 Validium、zk Porter 的設計），個人覺得能夠有（針對 Data Availability 程度的）選擇是會比只有一個選擇（完全 Data Available） 還好的方式，但實際上的可行性就要等其團隊釋出更多的資訊。

在 Rollup 越趨成熟的情況下，能夠提供快速跨 Rollup 服務的流動性提供者的角色會越來越重要。zk Rollup（StarkNet、zkSync、etc…）比 Optimistic Rollup （Optimism、Arbitrum、etc…）有著短上許多的 finalize 時間，這對降低流動性提供者的風險有很大的幫助，但目前 zk Rollup 支援合約功能甚至 L1 <-> L2 互動的完成度都比 Optimistic Rollup 還低上許多。短期內快速跨 Rollup 的服務應該還是侷限在 Optimitic Rollup 之間。

abbrev

[zkp 讀書會] Cairo 語言介紹 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.

👏 歡迎轉載分享鼓掌