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

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

#333333

多鏈錢包的管理，包含 Bitcoin, Ethereum, Tron 的多鏈錢包，以及在這些鏈上如何發出交易。之前的內容較專注在 Ethereum 鏈的機制，因此也會稍微介紹 Bitcoin, Tron 與 Ethereum 的不同。
要實作 Bitcoin, Ethereum, Tron 的多鏈錢包，最方便的作法還是使用 HD Wallet，因為這樣使用者只要記一個註記詞，就能用他計算出 Bitcoin, Ethereum, Tron 鏈的錢包（不熟悉的讀者可以回去看 Day 10 的內容），而且每條鏈還能產生多個錢包，可以說光一個註記詞就能儲存一個人在任何區塊鏈上的資產了（只要任何新的公鏈都選擇好在 BIP-44 標準中要用什麼 Coin Type 即可）
可以安裝 bip39 跟 flutter_bitcoin 套件來透過註記詞產生 HD Wallet，並按照 BIP-44 標準查到 Bitcoin, Ethereum, Tron 各自對應的 Coin Type 為 0, 60, 195，因此就可以 Derive 出對應的公私鑰：


Web3 全端工程師的技術養成之路 - Day 12 - Web 3 與 App：創多鏈錢包與發送交易

在開發工具中，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

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 合約程式碼導讀

實作完錢包登入的雛形，這個錢包在使用者的瀏覽器 Extension 內管理的。而有些時候也會需要在後端管理錢包，例如當使用者要把幣打到中心化交易所的入金地址時，交易所會產生一個錢包地址給使用者，並保管好這個錢包的私鑰，使用者入金完成後再自動把這個錢包內的幣轉到歸集錢包中（這樣就能統一把使用者的資金放在幾個大錢包中）。
因此今天我們會來實作產生助記詞、私鑰及錢包地址的功能。有了地址後就能取得他在鏈上的代幣餘額、持有的 NFT 數量等資訊，這樣才能基於這些資訊來自動發送轉出代幣的交易。不過今天我們會先專注在讀取資料的階段，明天才會進到發送交易的實作。
這邊先只考慮 12 個字的註記詞（12 ~ 24 個字都有可能）。這個格式就是 BIP-39 標準定義的，寫清楚了要用哪些英文單字以及為何選擇這些字等等。在 BIP-39 中總共有 2048 個英文單字，也就是 2 的 11 次方，代表一個單字內會有 11 bits 的資訊量，而 12 個字加起來總共就有 132 bits，這樣就剛好可以對應到一個 128 bits 的隨機數（剩下的 4 個 bits 是會是前 128 bits 的 checksum 來提高容錯率）。這個 128 bits 的隨機數就是能用來產生大量錢包私鑰的根源，也被稱為 seed （因此註記詞又被稱為 seed phrase）

有了這個 128 bits 的隨機數後，接下來就可以透過 BIP-32 標準定義的演算法從他衍生出大量的錢包。他會先從 seed 算出一個 master key （對應到下圖中的 Master Node），接下來就可以產生一整個樹狀結構的錢包們，每個點都是一個錢包（因此有對應的公私鑰）。所以當沿著這棵樹往右邊走的時候，選擇不同的路徑（分支）就會產生不同的錢包，而且他的特點是只要 seed 跟路徑參數是固定的，就會產生確定的錢包公私鑰，所以這個標準才被稱為 Hierarchical Deterministic Wallet（階層式確定性錢包），簡稱 HD Wallet。至於路徑參數會是長得像 m/0/1/1 的字串，代表每一步往右走時選擇的分支是什麼。
但是一個 seed 可以產生太多的錢包公私鑰了，對以太坊來說要怎麼知道一個註記詞預設產生的錢包是哪個呢？這就是 BIP-44 定義的內容了。它規定如果要從 seed 產生預設的比特幣錢包，就要使用 m/44'/0'/0'/0/0 這個路徑參數。而如果要產生預設的以太坊錢包，就要使用 m/44'/60'/0'/0/0 ，他們的差別在路徑的第二個數字不同，這就是 BIP-44 中定義不同的鏈必須要用他對應的數字來產生錢包（定義列表）。

有了第一個錢包後，第二個錢包就只要對路徑的最後一個數字 +1 就能從 seed 算出來了，後續的錢包就可以以此類推。另外在路徑上有個 ' 代表這是 hardened derivation，是個提高安全性的機制，有興趣的讀者可以再深入研究。

了解以上概念後就能理解接下來的程式碼。以下會使用 go-bip39 套件來產生註記詞，以及 go-ethereum-hdwallet 套件來產生這個註記詞對應的兩個預設錢包。直接來看實作

Web3 全端工程師的技術養成之路 - Day 10 - Web3 與後端：建立錢包與取得 Token Balance

首先我們可以觀察智能合約被佈署之後，在 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

進入 Web3 與後端的開發，在 Day 7 的前端程式已經準備好了簽名的訊息及簽章結果，因此後端需要提供一個 API 來驗證這個簽名，若驗證通過就可以任意選擇一種 Session 的實作方式來讓前端維持這個登入狀態。今天會示範用 golang 實作 Personal Message 以及 SIWE Message 的簽名驗證功能。


Web3 全端工程師的技術養成之路 - Day 9 - Web3 與後端：實作錢包登入 Part 2

完成在後端產生錢包助記詞、私鑰、讀取代幣餘額的實作，今天就會來實作簽名並發送交易的功能，才能完成在區塊鏈上的寫入，作為 Web3 與後端第一部分的結尾。為了產生完整的交易，除了 from address, to address, value 之外，還有像是 nonce, gas price, gas limit, chain ID 等等元素是不可或缺的，在前端的部分沒有講到是因為 wagmi 與 Metamask 已經幫我們處理好這些資料的計算，而在後端這些數值就需要自己算出來。
Nonce 的概念是對於一個固定的錢包地址來說，他發送的第一個交易 Nonce 就必須為 0，第二個 Nonce 為 1 以此類推，因此 Nonce 是嚴格遞增且不能被重複使用的。這個機制也是為了避免 replay attack。想像一下如果 A 簽名了一個轉移 1 ETH 給 B 的交易並廣播出去，如果這個交易的簽章還能重複使用的話，B 就能再廣播一次這個交易讓 A 多轉 1 ETH 給他。有的 Nonce 機制就可以確保 A 要送出的下一個交易的簽名一定跟之前交易的簽名不一樣（因為 Nonce 不一樣就會讓整個交易 hash 出來的結果不一樣）
在以太坊上執行任何交易、智能合約操作時，都需要支付一定的費用，這個費用被稱為 Gas Fee。在發送交易時，他是由 Gas Price 及 Gas 數量這兩個數值相乘算出來的。
在以太坊上進行任何操作時，這些操作其實是由底層的 EVM code 所組成，這是以太坊中類似組合語言的存在。而每個操作都有他對應的 Gas 數量作為這個操作的費用，例如 ADD 指令（加法）花費 3 個 gas、MUL 指令（乘法）花費 5 個 gas。而一筆交易中會執行到的所有指令的 Gas 總合就是這筆交易需花費的 Gas 數量。例如一筆簡單的轉帳交易需要的 Gas 數量通常是 21000，複雜的智能合約操作就需要更多的 Gas。
Gas Price 指的是你願意為每單位的 Gas 支付多少金額，通常以 Gwei 來表示（Wei 是 ETH 的最小單位也就是 10^-18 ETH，因此 10^9 Wei = 1 Gwei ，10^9 Gwei = 1 ETH）。交易指定的 Gas Price 越高，交易確認的速度通常也越快，因為礦工更願意優先確認這筆交易以獲得更高的獎勵。
因此在發送交易時我們需要指定 Gas Limit 跟 Gas Price，Gas Limit 指的就是這筆交易最多只能使用多少個 Gas 單位，因此這樣就能算出一筆交易最多會花多少手續費。例如假設進行一個 Swap 交易要花 80,000 個 Gas，而當下以太坊的 Gas Price 為 20 Gwei，那就可以計算出這筆交易的手續費會是 80000 * 20 * 10^-9 = 0.0016 ETH ，再乘上當下 ETH 的價格 1629 USD 就可以算出大約要花 2.61 USD 的手續費。
若設定的 Gas Limit 太低，交易可能因為沒有足夠的 Gas 而失敗，但還是需要支付已經消耗的 Gas 費用（交易會上鏈但在 Etherscan 上會顯示交易失敗，而且 Gas Fee 照扣）。若 Gas Price 設定的太高可能會花不必要的錢，但太低又可能會讓交易要等很久才上鏈，因此正確設定 Gas 的參數非常重要。
在 ethclient 物件中可以使用SuggestGasPrice方法來查詢當前的 Gas Price，以及 EstimateGas 方法可以估算這筆交易大約會花多少 Gas，而有時為了確保交易成功會再基於這個值往上加一些 Gas。
當我們說一條鏈是 EVM 相容時（例如以太坊主網、Sepolia 測試網、Polygon、Arbitrum 等鏈），代表像私鑰格式、地址、交易簽名方式、智能合約的程式碼等等執行層的機制都是跟以太坊幾乎一樣的（差異可能較多是在共識層也就是節點之間如何達成共識、挖礦機制等等），一個很大的好處是開發者可以在不同的鏈上都部署相同的智能合約，而不需要做任何修改，甚至部署的合約地址在各條 EVM 相容的鏈都可以一模一樣。
但為了確保交易的安全性（避免 replay attack），每條 EVM 相容的鏈需要有自己獨特的 Chain ID，才能用來在交易中區分不同的 EVM 鏈。而 Chain ID 的概念是在 EIP-155 中定義的，他讓交易的簽名計算中多包含了 Chain ID，這樣即使交易在以太坊主網上有效，它也不能被重放到其他鏈上，因為每個鏈的 Chain ID 都是獨特的。
chainlist 是一個知名的網站，上面列出了許多 EVM 相容的鏈，並提供了他們的節點 JSON-RPC 網址、Chain ID、區塊鏈瀏覽器（Explorer）連結等資訊。對於要新增 EVM 相容鏈到錢包 Extension 時是個很有用的工具。在裡面搜尋 Sepolia 並勾選 Include Testnets 就可以看到他對應的 Chain ID 是 11155111。

Solidity 入門教學

初學者入門智能合約開發

ERC404 合約程式碼導讀

Solidity 教學: 最佳化合約 Contract Optimization

Solidity 教學: 開發工具 Dev.Tools

Solidity 教學: 佈署 Deploy & 編譯 Compiler

ERC404 合約程式碼導讀

Solidity 教學: 最佳化合約 Contract Optimization

Solidity 教學: 開發工具 Dev.Tools

Solidity 教學: 佈署 Deploy & 編譯 Compiler

Web3 全端技術養成

成為 Web3 全端工程師

Web3 全端工程師的技術養成之路 - Day 12 - Web 3 與 App：創多鏈錢包與發送交易

Web3 全端工程師的技術養成之路 - Day 11 - Web3 與後端：簽名與發送交易

Web3 全端工程師的技術養成之路 - Day 10 - Web3 與後端：建立錢包與取得 Token Balance

Web3 全端工程師的技術養成之路 - Day 9 - Web3 與後端：實作錢包登入 Part 2

Web3 全端工程師的技術養成之路 - Day 12 - Web 3 與 App：創多鏈錢包與發送交易

Web3 全端工程師的技術養成之路 - Day 11 - Web3 與後端：簽名與發送交易

Web3 全端工程師的技術養成之路 - Day 10 - Web3 與後端：建立錢包與取得 Token Balance

Web3 全端工程師的技術養成之路 - Day 9 - Web3 與後端：實作錢包登入 Part 2