專注於 WEB 3.0 區塊鏈工程師與人才培育，孵化與投資區塊鏈項目，打造亞洲最大的區塊鏈開發與社群人才之生態圈。

KryptoCamp - 智能合約教學與區塊鏈工程師課程

#333333

在區塊鏈領域中的大多數公鏈項目都是開源的，所以常會需要社區來共同改進這個項目。以比特幣為例，任何人都可以上 Github 網站 Pull Source Code 來自行修改程式碼。

要移除或增加各種功能並不是由哪一個中心組織或個人決定的，而是由核心團隊、礦工、社區愛好者、用戶等眾多角色構成。

BIP 為比特幣改進建議（Bitcoin Improvement Proposal），為一項用於介紹和著名比特幣各項協議、資訊、特色、改進想法、意義和技術內容的文件。任何人都可以在任何地方提出新的討論，爭取到社區的支持以後以 BIP 模板的方式提交給核心開發者，最後便可透過多重步驟拍板通過（或遭到否決）。
常見的技術內容包含區塊擴容、簽名支付技術、錢包技術等。
EIP(Ethereum Improvement Proposal) 是由任何人發佈在以太坊開源區的建議提案。EIP 和 BIP 一樣可以是各種技術或想法的改進，比如說 ERC、協議改進、開發工具、新特性等等。

ERC (Ethereum Request for Comments) 是將開發規則統一為標準的提案。在提出 EIP 建議後，接受認可後官方會發出相應的 ERC 進行一些細節和問題討論，通常情況下此時 EIP 及 ERC 使用相同編號。
ERC 和 EIP 的編號就僅僅是提案被提出的先後順序決定，並沒有其他的意義。就像我們最常使用的 ERC-20 為第 20 個提出的提案。
官方認可的 ERC標準有非常多，其中也包含了 ERC-20 （同質化代幣，FT）和 ERC-721（非同質化代幣，NFT）等，均為以太坊上代幣種被的規範標準。
ERC-20 在 2015-11-19 由 Fabian Vogelsteller, Vitalik Buterin 提出。ERC-20 為目前以太坊上最多人使用的標準，此標準除了提高 Token 的互換性，還能在 DApp 上面進行同樣的運行。常見的應用有：

穩定幣：與法定貨幣錨定的代幣，發行者可能持有相對應的抵押資產，或儲蓄。

安全代幣：為股權型代幣的一種，可能是有價證券，例如股票、債券或實物資產。
功能型代幣：為服務型代幣的一種，可能是遊戲貨幣、Dapp 燃料、忠誠度積分。
ERC-20 包含六個功能函式、兩個事件以及三個 Token 資訊的函式。
ERC-721 正式應用為 2018-01-24 由 William Entriken, Dieter Shirley, Jacob Evans, Nastassia Sachs 發行，Dieter Shirley 也是 Axiom Zen 的技術總監，就是第一個使用 ERC-721 作為去中心化遊戲應用 CryptoKitties 的公司。用於處理不可替換資產的另一種以太坊代幣標準。
所有的 NFTs 都會擁有一個 uint256 也就是 256 位元的代號，也就是 tokenId 所以在每個 ERC-721 的合約之中， 每組 contract address, uint256 tokenId 都是獨一無二的，這種代幣可以通過區塊鏈上的智能合約追蹤，從而形塑數位化的資產。在 dApp 都有一個 "converter" 可以以 tokenId 為輸入並輸出有趣又特別的圖片。也就是眾所皆知的 NFT 藝術收藏品！
半同質性代幣（Semi-fungiable token）是藉由 ERC-1155 (Multi Token Standard) 標準發行的代幣。
ERC-1155 讓交易變得更為便利，不只有轉換同質化和非同質化代幣，還提供了批量轉帳、批量查額、批量授權等功能。這對一些 NFT 項目和 Game-Fi 來說是非常便利的，因為他們就可以在一次合約調用的情況下做到批量功能來節省開銷和提升效率。整個以太坊經濟系統變可達到更規模化的程度。
ERC-1155 代幣標準特性：
ERC-1155 是一個同時擁有同質化、半同質化、非同質化代幣的合約介面（Contract Interface）

ERC-1155 可同時使用 ERC-20 和 ERC-721 的函式

利用 ERC-1155 代幣標準發行的代幣可同時擁有同質化、半同質化、非同質化代幣的性質，也可以有不同的價值、MetaData格式

以這種代幣標準發行的合約可以透過在合約內轉換代幣來節省 Gas，過往我們需要互換不同的代幣必須使用另外一個智能合約建置的 DApp 或相關客戶端來執行這項動作，但在同一個合約內與不同類型的代幣互動便可以省掉上述繁瑣又開銷的步驟。

Solidity 教學: Ethereum Improvement Proposal, EIP & Ethereum Request for Comments, ERC & Token

在 Solidity 中，當一個 Event 被呼叫之後它的參數就會被置於區塊鏈之中。事件讓我們在 DApp 或瀏覽器的環境下可以呼叫 Javascript 的監聽，藉此得到一些我們想知道的訊息。區塊鏈上的交易會有所謂的日誌（logs），我們沒有辦法以一合約直接訪問該合約中的事件和 logs，所以它的可視性是 external 的。事件是合約的可繼承成員，發出一個事件可以使用合約的地址訪問事件，生成的事件不能從合約內部訪問。

Solidity 教學: 事件 Event

在開發工具中，Geth 為一個區塊鏈節點，Parity 為另外一個區塊鏈節點，而這些節點、Hyper Ledger、私有網路，皆是使用同樣的 Ethereum Protocol。同樣的 Protocol 代表同樣儲存資料的方式，也代表同樣訪問資料的方式。
當前開發者可利用的網路分類如下：
主網：
永遠存在
為真實的區塊鏈
耗費真錢
測試網路：
理論上永遠存在，但有可能被刪除
為真實的區塊鏈
可以在上面測試項目的 Beta 版本，測試智能合約，甚至測試新的 Protocal Updates
開發者網路：
例如：Ganache
並非永遠存在，運作類似真實的區塊鏈網路，但並非真的區塊鏈
可用於進行 Unit Testing 或其他測試佈署
運作非常快速，可以直接見到區塊打包或交易的結果
區塊鏈比較常是使用 RPC，區塊鏈節點是一個很低階的部位，提供的 API -> JSON-RPC ，如果底層的函數包太多東西上層的應用開發反而會很困難
Go-Ethereum，又簡稱 Geth，為：
Ethereum Protocol
Command Line 工具
當我們運行了 Geth 以後：
Geth 會以區塊鏈節點的方式運行
Geth 會找到其他區塊鏈節點並與其連接
Geth 會在本地端打開 一 JavaScript RPC，讓我們可以以此和節點互動
開始連接節點，下載（複製）區塊鏈上的資料
區塊鏈（資料）會存在我們的本地端，並不存在任何的中央伺服器或者資料庫

EIPs 是以太坊中的一套標準，內容會包含 core protocol specifications、用戶 API、和合約標準。

gas 是一個在與合約進行交易時的內部價格，當我們傳送一些指令給 Ethereum Virtual Machine (EVM) 來進行交易或與合約互動時就會消耗一定量的 gas。

Solidity 教學: 開發工具 Dev.Tools

已知區塊鏈的連接方式為 Block-0(Genesis Block) --> Block-1 --> Block-2 ... Block-N 之間接連的 hash 下去，而智能合約從建立到運作的過程為：
撰寫智能合約
編譯智能合約後程式碼被轉為 bytes code
這些 bytes code 會轉為交易（transaction），並且被打包到區塊中
此智能合約被打包到該區塊之後，整個區塊會對內容進行 hash（因此我們無法改變這筆交易，也無法改變已經佈署的合約程式碼，因為這樣做會把整個區塊鏈的 hash 破壞掉）
由第四點可知我們無法真正地刪掉智能合約，但能夠透過「狀態（state）改變」來編輯智能合約或其他資料的狀態
ABI（Application Binary Interface）

如果我們理解 API 就很容易了解 ABI。簡單來說 API（應用程式介面）就是程式跟程式之間互動的接口，此接口包含了提供外界存取所需要的 functions、variables 等。

ABI 也是程式之間互動的接口，但是程式是編譯後的 binary code。ABI 描述的是如何 decode/encode 程式之間傳遞的 binary 信息，從另一個角度看，它就只是一個告訴客戶端怎麼和合約互動 JSON 檔。
ABI 就像是以太坊生態系統中與合約進行互動的標準方式，無論是從區塊鏈外部還是從合約到合約的互動。我們需要一個固定模式並根據其類型進行編碼。其中包含可供外部使用或聆聽的 Function 和 Event。
在我們和合約互動時，需要傳遞一個 transaction 到智能合約的地址，此時以太坊的節點會在觀察完 ABI 之後會選擇要執行哪個函數或事件。
以太坊虛擬機（Ethereum Virtual Machine，EVM）是在以太坊中，用來處理智能合約的佈署以及執行的一個虛擬機。是使得以太坊和比特幣區分的最大關鍵，也就是說 EVM 使得以太坊區塊鏈從「分散式帳本」昇華成「分散式狀態機」。

我們在過往提到過非常多次「狀態」，包含各式各樣的記憶體更改，或者是狀態變數的宣告與使用等。在EVM這樣大型的狀態機的資料結構下，儲存了所有原先區塊鏈會儲存的「帳戶、交易」之外，還有「機器狀態」（Machine State）
虛擬機就是透過軟體模擬的計算機系統，進入這個虛擬系統之後，我們可以在裡面進行各種獨立地日常操作，包含獨立安裝軟體和保存數據等等。這樣一來，我們就可以在虛擬機中做任何想做的事情，不用擔心各種病毒和攻擊都不怕。即便遇到了也可以藉由重裝虛擬機來解決，並不會對真正的系統產生任何影響。
當以太坊鏈上發生轉帳交易的時候，以太坊虛擬機（EVM）會進行以下工作：
調取轉帳數值
分析合約指令
計算Gas的消耗（手續費）
確保發出轉賬的地址有足夠的Gas費
執行合約
實現轉帳到對應的地址
EVM 的功能：
安全性：EVM 是一個獨立的運作空間，使合約可以在內部獨立地運行。此外，設定 Gas 的總量限制使所有的程式碼都有一個終點，如果有惡意或意外的不當程式被執行時，因為有 Gas 的限制，可以讓不當程式停下來，進而保全以太坊不會停機。
穩定性：由於以太坊虛擬機部署在以太坊網絡的每個節點，整個以太坊網絡的數據由眾多節點共同維護和更新，這保持了整個區塊鏈數據的一致性，這同樣也使以太坊有極高的故障容錯性，保證零停機。
方便性：以太坊虛擬機可以做為獨立的程式碼運行環境。測試時不會占用到主鏈資源，也不受其他區塊鏈或網路的影響。
EVM 使用堆疊結構的記憶體架構，將所有記憶體內（in-memory）的值存儲在堆疊區裡。
由於橢圓加密曲線的相關操作，具有多個以 256 位元為單位，可「以址查詢」的資料結構：
所有 EVM 內部的 Operations 都已經被定義在黃皮書中。像是：XOR, AND, ADD, SUB。同時EVM 也包含各種區塊鏈相關的堆疊區operations，例如：ADDRESS, BALANCE, BLOCKHASH 等。

Solidity 教學: 佈署 Deploy & 編譯 Compiler

在參考一些合約的時候，初學者往往最難理解的可能是一種沒有內容的函式存在，其實這些函式被稱為接口或介面，就像是我們電腦上的 USB 插座一樣，Solidity 中的 Interface 也提供了一個「規格化、模組化」的接口使我們可以跟一些「既定的規則」進行互動，以達到方便更具規模使用。Interface 就像是一個抽象合約，以下為 interface 的重要特徵：
Interface 的函數不可以有實作部分，也不能繼承其他合約、Interface
Interface 中函數的可視性只能是 external
Interface 不可有 constructor
Interface 不可有任何 state variables
Interface 可以有像是 enum 或 structs 的資料結構，並且用 <interface>.<data structures> 的方式訪問

合約就像是我們在物件導向程式語言中的 Classes，可以包含許多永遠存在（不會因為生命週期而消亡）的狀態變數和相關的成員函式。而抽象合約（Abstract Contract）的定義是：當這個 Contracts 物件中至少有一個函式沒有包含實作部分時，並稱做抽象合約。

我們什麼時候適合使用抽象合約呢，一是使用 template method 時，我們可以在合約中依照已經定義好的骨架來建置我們自己的函式內容。二是我們可以用於 debug，因為如果我們的合約裡面和抽象合約定義的內容不同時，compiler 或出現錯誤或者警告。

與 Interface 不同的是：Interface 只能是合約 ABI 能夠表示的範疇，所以才會有我們之前提到的那些規定。而使用 Interface 的好處是在大型專案裡面，擁有一個定義完善的 Interface 可以讓彈性、效率、可擴充性、模組化發揮到最高的程度。

Solidity 教學: 介面 Interface

ERC404是近期非常紅的提案，主打圖幣結合，也就是一個合約同時擁有ERC20及ERC721的特性，並擁有以下特徵：
* 持有一個 NFT就代表你也持有一顆 ERC20，持有一顆 ERC20 就代表你也持有一顆NFT。

重新鑄造一個 NFT，發送方會減少一顆 ERC20 及燒毀一個 NFT。(燒毀的NFT會是狀態變數陣列中最後一個tokenId)
交易/轉移一個NFT，接收方會增加一顆ERC20及收到該NFT，發送方會減少一顆 ERC20 及發送的 NFT。
交易/轉移一顆 ERC20，接收方會增加一顆ERC20及重新鑄造一個NFT，發送方會減少一顆ERC20及燒毀一個NFT。(燒毀的NFT會是狀態變數陣列中最後一個tokenId)
上述特性，讓 NFT 碎片化，並可以不斷的交易 ERC20 來重新鑄造新的 NFT，讓 NFT 出現不喜歡就可以刷掉重新鑄造的可能。
Pandora則是該提案合約的第一個項目，地址見下方連結：
https://etherscan.io/token/0x9e9fbde7c7a83c43913bddc8779158f1368f0413?a=2656#code

ERC404 合約程式碼導讀

Solidity 中繼承有以下的特性：當進行多重繼承（Multiple Inheritance）使用 C3 Linearization演 算法, 具有多態性質（Polymorphism）,使用 is 關鍵字來做為繼承語法：
當宣告 A is X, Y, Z 時，Z 是最末端繼承合約
可使用 super 來訪問（access）最源頭的合約
被繼承的合約會被佈署成單一合約，不會佈署多個合約上鏈
C3 Linearization 演算法用於決定多重繼承中的順序，其中包含子合約不可以改變父合約的方法搜尋順序、局部優先原則（A 繼承 B 和 C，C 繼承 B，那麼 A 讀取父合約方法時優先使用 Ｃ）。這會強制將繼承轉換為一個有向無環圖的特定順序，同時我們在進行繼承時的宣告順序也很重要（is 後放的合約順序）。

Solidity 教學: 繼承 Inheritance

在 Solidity 中，一個 .sol 檔中可以有多個 contract 物件，故可以藉由引用的方式將其它檔案內的contract 引入至當前檔案中。
Library 非常類似於 contracts，但我們不能在裡面宣告任何的 state variables，也不可以傳送任何 ether，只會被佈署一次。在引入 Library 的時候可以將其視為繼承來的父合約，這樣去理解其中的函式可視性與 this 的使用會比較好懂。
在 Solidity 裡面有兩種 Libraries 類型：
deployed：有自己的合約地址，可以被智能合約在執行時調用
embedded：當所有的 library 函數皆為 internal；沒有自己的合約地址，會變成我們合約的一部分程式碼。
OpenZeppelin 是一個智能合約庫，其中包含了經過社區審查的 ERC 代幣標準、安全協議以及其他輔助工具，使用 OpenZeppelin 可以極大的提高 Solidity 合約的開發效率並保證合約的安全性。最常用的合約庫如下：
Ownable：
OpenZeppelin 的 Ownable 合約提供的 onlyOwner 模式是用來保護特定合約方法的訪問權限的基礎但非常有效的模式。
SafeMath：
這個合約會進行所有必要的檢查，避免你的程式碼因算術運算而出現漏洞，或者因為溢位等因素而出現預期外的計算結果。
SafeCast：
當我們在做型別轉換的時候有可能會出現精度遺漏或者溢位等問題，SafeCast 可以幫我們完成這些轉換而無需擔心溢出問題。


Solidity 教學:引用 Imports and 函式庫 Libraries

首先我們可以觀察智能合約被佈署之後，在 Console window debugger 中的資訊：
主要有三項內容比較重要：
gas: operation 的複雜度
transaction cost: 已經包含在 execution cost 中
execution cost
只要我們選擇了較高的 Gas Fee 或讓合約的 Gas 較多，則交易速度就會更快，因為從 Mine(Space Complexity) Level，礦工會更傾向選擇我們的交易進行打包。
Gas 和汽車耗油的概念一樣，每輛車在理想情況下(不會折舊)的單位耗油量、油箱容量是不變的，然而油價是會起伏的。同理，已佈署合約的 Gas Consumption 是固定不變的，真正導致每次佈署同樣合約(程式碼)、呼叫相同函式的 Gas fee 都不一樣的原因來自於 Gas Price 是不斷變動的。
如果真的得徹底了解合約中耗費的 Gas，我們可以利用 REMIX Debugging Step Detail 取得合約到底執行了哪些 Operation，再利用 Ethereum Yellow Paper 中的定義計算 Gas Consumption。也就是說實際上是 Operational Complexity 決定了 Gas Cost。
資料儲存處
我們遇到的問題是在以太坊區塊鏈中儲存資料實在是太貴了，所以想要找到一個便宜儲存資料的方法。目前根據儲存位置的不同，有幾種解決方式:
將資料儲存在鏈外，只儲存 proof(hash)，例如:Notary
儲存在分散式資料庫，例如: IPFS
雜湊樹 Merkle Tree
從底層的角度來看，我們已經把 Event 的內容儲存在編譯並交易的區塊上了，何不直接利用這些 Event 來查看和呼叫資料。
利用事件節省的想法是: 如果這些資料並不需要被智能合約直接使用，那我們就只要把它放在 log 裡就好。
也就衍伸出兩種想法: Store Path on Cahin vs. Store String in Events。
不過還是得避免無用的 Event 宣告，因為即便 Event 是相對便宜 的，其參數和宣告都需要耗費 Gas。無論是 Event、Function、加密演算法(ripemd160、sha256、keccak256)的參數多寡都會影響到 Gas，所以在撰寫時務必力求精簡。
也就是說選擇資料儲存處的概念是那些資料和計算是必須 On- Chain 的，那些是不必的，如果是已知的計算結果或 Constant，甚至是 Metadata、相關檔案、參數或相關設定資料，便可以選擇在合約(鏈)外計算完畢，最後只要想辦法導入結果即可。
如何減少 gas 的耗費：
減少鏈上的資料
使用 event 而非 storage
最佳化變數宣告

Solidity 教學: 最佳化合約 Contract Optimization

面對異常處理，我們得先簡單理解交易以及錯誤（Transactions and Errors），並且條列一些在 Solidity 中異常處理的性質。Revert 和 require 可以回傳錯誤訊息
require() 用於檢驗簡單的條件:合理的輸入, 執行前必要的簡單條件, 回傳一則訊息
assert() 必須指被用來檢測內部錯誤，意思就是用來測試或 debug，並且用來檢測不變量（不該被改變的常數等）
revert() 用於確認複雜狀態，意思就是說我們必須寫上一連串的巢狀 if-else 或其他條件式選擇來過濾各種情形，最後才加上 revert() 如果我們進到了錯誤結果。
try/catch 用於確認外部執行函數和合約建立時（在一個合約裡面建立另外一個合約時）的錯誤，可以利用類條件式選擇來排除錯誤情況。
try 這個關鍵字必須要根據「外部函式呼叫」或「創建合約」這類的行為來定義，例如：new ContractName()。
而其中的 returns 部份是可有可無的，若需要的話，宣告 returns 部份必須要符合外部函式呼叫的回傳型態。

Solidity 教學: 異常處理 Handling Exception

全局訊息（或稱全局變數）和平常我們在寫其他程式語言的定義稍有不同，
這裡指的是區塊鏈提供給我們的訊息，而非指我們自己定義出來的變數當前的資訊是什麼。通常使用全局變數來聆聽區塊鏈上的交易資訊和訊息。msg 有兩個屬性，一個是 msg.sender，另一個是 msg.value，這兩個值可以被任何 external 函數調用，包含庫裏面的函數。
block 顧名思義就是區塊鏈的訊息


熱門文章

Solidity 教學: Ethereum Improvement Proposal, EIP & Ethereum Request for Comments, ERC & Token

Solidity 教學: 角色和全局訊息 Global Variables

Solidity 教學: 介面 Interface

ERC404 合約程式碼導讀

Solidity 教學: 事件 Event