1. 以太坊是什麼丨以太坊開發入門指南
以太坊是什麼丨以太坊開發入門指南
很多同學已經躍躍欲試投入到區塊鏈開發隊伍當中來，可是又感覺無從下手，本文將基於以太坊平台，以通俗的方式介紹以太坊開發中涉及的各晦澀的概念，輕松帶大家入門。
以太坊是什麼
以太坊（Ethereum）是一個建立在區塊鏈技術之上， 去中心化應用平台。它允許任何人在平台中建立和使用通過區塊鏈技術運行的去中心化應用。
對這句話不理解的同學，姑且可以理解為以太坊是區塊鏈里的Android，它是一個開發平台，讓我們就可以像基於Android Framework一樣基於區塊鏈技術寫應用。
在沒有以太坊之前，寫區塊鏈應用是這樣的：拷貝一份比特幣代碼，然後去改底層代碼如加密演算法，共識機制，網路協議等等（很多山寨幣就是這樣，改改就出來一個新幣）。
以太坊平台對底層區塊鏈技術進行了封裝，讓區塊鏈應用開發者可以直接基於以太坊平台進行開發，開發者只要專注於應用本身的開發，從而大大降低了難度。
目前圍繞以太坊已經形成了一個較為完善的開發生態圈：有社區的支持，有很多開發框架、工具可以選擇。
智能合約
什麼是智能合約
以太坊上的程序稱之為智能合約， 它是代碼和數據(狀態)的集合。
智能合約可以理解為在區塊鏈上可以自動執行的（由事件驅動的）、以代碼形式編寫的合同（特殊的交易）。
在比特幣腳本中，我們講到過比特幣的交易是可以編程的，但是比特幣腳本有很多的限制，能夠編寫的程序也有限，而以太坊則更加完備（在計算機科學術語中，稱它為是「圖靈完備的」），讓我們就像使用任何高級語言一樣來編寫幾乎可以做任何事情的程序（智能合約）。
智能合約非常適合對信任、安全和持久性要求較高的應用場景，比如：數字貨幣、數字資產、投票、保險、金融應用、預測市場、產權所有權管理、物聯網、點對點交易等等。
目前除數字貨幣之外，真正落地的應用還不多（就像移動平台剛開始出來一樣），相信1到3年內，各種殺手級會慢慢出現。
編程語言：Solidity
智能合約的默認的編程語言是Solidity，文件擴展名以.sol結尾。
Solidity是和JavaScript相似的語言，用它來開發合約並編譯成以太坊虛擬機位元組代碼。
還有長像Python的智能合約開發語言：Serpent，不過建議大家還是使用Solidity。
Browser-Solidity是一個瀏覽器的Solidity IDE, 大家可以點進去看看，以後我們更多文章介紹Solidity這個語言。
運行環境：EVM
EVM（Ethereum Virtual Machine）以太坊虛擬機是以太坊中智能合約的運行環境。
Solidity之於EVM，就像之於跟JVM的關系一樣，這樣大家就容易理解了。
以太坊虛擬機是一個隔離的環境，在EVM內部運行的代碼不能跟外部有聯系。
而EVM運行在以太坊節點上，當我們把合約部署到以太坊網路上之後，合約就可以在以太坊網路中運行了。
合約的編譯
以太坊虛擬機上運行的是合約的位元組碼形式，需要我們在部署之前先對合約進行編譯，可以選擇Browser-Solidity Web IDE或solc編譯器。
合約的部署
在以太坊上開發應用時，常常要使用到以太坊客戶端（錢包）。平時我們在開發中，一般不接觸到客戶端或錢包的概念，它是什麼呢？
以太坊客戶端（錢包）
以太坊客戶端，其實我們可以把它理解為一個開發者工具，它提供賬戶管理、挖礦、轉賬、智能合約的部署和執行等等功能。
EVM是由以太坊客戶端提供的。
Geth是典型的開發以太坊時使用的客戶端，基於Go語言開發。 Geth提供了一個互動式命令控制台，通過命令控制台中包含了以太坊的各種功能（API）。Geth的使用我們之後會有文章介紹，這里大家先有個概念。
Geth控制台和Chrome瀏覽器開發者工具里的面的控制台是類似，不過是跑在終端里。
相對於Geth，Mist則是圖形化操作界面的以太坊客戶端。
如何部署
智能合約的部署是指把合約位元組碼發布到區塊鏈上，並使用一個特定的地址來標示這個合約，這個地址稱為合約賬戶。
以太坊中有兩類賬戶：
· 外部賬戶
該類賬戶被私鑰控制（由人控制），沒有關聯任何代碼。
· 合約賬戶
該類賬戶被它們的合約代碼控制且有代碼與之關聯。
和比特幣使用UTXO的設計不一樣，以太坊使用更為簡單的賬戶概念。
兩類賬戶對於EVM來說是一樣的。
外部賬戶與合約賬戶的區別和關系是這樣的：一個外部賬戶可以通過創建和用自己的私鑰來對交易進行簽名，來發送消息給另一個外部賬戶或合約賬戶。
在兩個外部賬戶之間傳送消息是價值轉移的過程。但從外部賬戶到合約賬戶的消息會激活合約賬戶的代碼，允許它執行各種動作（比如轉移代幣，寫入內部存儲，挖出一個新代幣，執行一些運算，創建一個新的合約等等）。
只有當外部賬戶發出指令時，合同賬戶才會執行相應的操作。
合約部署就是將編譯好的合約位元組碼通過外部賬號發送交易的形式部署到以太坊區塊鏈上（由實際礦工出塊之後，才真正部署成功）。
運行
合約部署之後，當需要調用這個智能合約的方法時只需要向這個合約賬戶發送消息（交易）即可，通過消息觸發後智能合約的代碼就會在EVM中執行了。
Gas
和雲計算相似，佔用區塊鏈的資源（不管是簡單的轉賬交易，還是合約的部署和執行）同樣需要付出相應的費用（天下沒有免費的午餐對不對!）。
以太坊上用Gas機制來計費，Gas也可以認為是一個工作量單位，智能合約越復雜（計算步驟的數量和類型，佔用的內存等），用來完成運行就需要越多Gas。
任何特定的合約所需的運行合約的Gas數量是固定的，由合約的復雜度決定。
而Gas價格由運行合約的人在提交運行合約請求的時候規定，以確定他願意為這次交易願意付出的費用：Gas價格（用以太幣計價） * Gas數量。
Gas的目的是限制執行交易所需的工作量，同時為執行支付費用。當EVM執行交易時，Gas將按照特定規則被逐漸消耗，無論執行到什麼位置，一旦Gas被耗盡，將會觸發異常。當前調用幀所做的所有狀態修改都將被回滾， 如果執行結束還有Gas剩餘，這些Gas將被返還給發送賬戶。
如果沒有這個限制，就會有人寫出無法停止（如：死循環）的合約來阻塞網路。
因此實際上（把前面的內容串起來），我們需要一個有以太幣余額的外部賬戶，來發起一個交易（普通交易或部署、運行一個合約），運行時，礦工收取相應的工作量費用。
以太坊網路
有些著急的同學要問了，沒有以太幣，要怎麼進行智能合約的開發？可以選擇以下方式：
選擇以太坊官網測試網路Testnet
測試網路中，我們可以很容易獲得免費的以太幣，缺點是需要發很長時間初始化節點。
使用私有鏈
創建自己的以太幣私有測試網路，通常也稱為私有鏈，我們可以用它來作為一個測試環境來開發、調試和測試智能合約。
通過上面提到的Geth很容易就可以創建一個屬於自己的測試網路，以太幣想挖多少挖多少，也免去了同步正式網路的整個區塊鏈數據。
使用開發者網路(模式)
相比私有鏈，開發者網路(模式)下，會自動分配一個有大量余額的開發者賬戶給我們使用。
使用模擬環境
另一個創建測試網路的方法是使用testrpc，testrpc是在本地使用內存模擬的一個以太坊環境，對於開發調試來說，更方便快捷。而且testrpc可以在啟動時幫我們創建10個存有資金的測試賬戶。
進行合約開發時，可以在testrpc中測試通過後，再部署到Geth節點中去。
更新：testrpc 現在已經並入到Truffle 開發框架中，現在名字是Ganache CLI。
Dapp：去中心化的應用程序
以太坊社區把基於智能合約的應用稱為去中心化的應用程序(DecentralizedApp)。如果我們把區塊鏈理解為一個不可篡改的資料庫，智能合約理解為和資料庫打交道的程序，那就很容易理解Dapp了，一個Dapp不單單有智能合約，比如還需要有一個友好的用戶界面和其他的東西。
Truffle
Truffle是Dapp開發框架，他可以幫我們處理掉大量無關緊要的小事情，讓我們可以迅速開始寫代碼-編譯-部署-測試-打包DApp這個流程。
總結
我們現在來總結一下，以太坊是平台，它讓我們方便的使用區塊鏈技術開發去中心化的應用，在這個應用中，使用Solidity來編寫和區塊鏈交互的智能合約，合約編寫好後之後，我們需要用以太坊客戶端用一個有餘額的賬戶去部署及運行合約（使用Truffle框架可以更好的幫助我們做這些事情了）。為了開發方便，我們可以用Geth或testrpc來搭建一個測試網路。
註：本文中為了方便大家理解，對一些概念做了類比，有些嚴格來不是准確，不過我也認為對於初學者，也沒有必要把每一個概念掌握的很細致和准確，學習是一個逐步深入的過程，很多時候我們會發現，過一段後，我們會對同一個東西有不一樣的理解。
2. 以太坊stratum協議原理
參照比特幣的 stratum協議 和 NiceHash的stratum協議規范 編寫了一版以太坊版本的stratum協議說明.
stratum協議是目前最常用的礦機和礦池之間的TCP通訊協議。
以太坊是一個去中心化的網路架構，通過安裝Mist客戶端的節點來轉發新交易和新區塊。而礦機、礦池也同時形成了另一個網路，我們稱之為礦工網路。
礦工網路分成礦機、礦池、錢包等幾個主要部分，有時礦池軟體與錢包安裝在一起，可合稱為礦池。
礦機與礦池軟體之間的通訊協議是 stratum ，而礦池軟體與錢包之間的通訊是 bitcoinrpc 介面。
stratum是 JSON 為數據格式.
礦機啟動，首先以 mining.subscribe 方法向礦池連接，用來訂閱工作。
礦池以 mining.notify 返回訂閱號、ExtraNonce1和ExtraNonce2_size。
Client:
Server:
其中：
是 訂閱號 ；
080c是 extranonce ，Extranonce可能最大3位元組；
礦機以 mining.authorize 方法，用某個帳號和密碼登錄到礦池，密碼可空，礦池返回 true 登錄成功。該方法必須是在初始化連接之後馬上進行，否則礦機得不到礦池任務。
Client:
Server:
難度調整由礦池下發給礦機，以 mining.set_difficulty 方法調整難度， params 中是難度值。
Server:
礦機會在下一個任務時採用新難度，礦池有時會馬上下發一個新任務並且把清理任務設為true，以便礦機馬上以新難度工作。
該命令由礦池定期發給礦機，當礦機以 mining.subscribe 方法登記後，礦池應該馬上以 mining.notify 返回該任務。
Server:
任務ID ： bf0488aa ；
seedhash ： 。每一個任務都發送一個seedhash來支持盡可能多的礦池，這可能會很快地在貨幣之間交換。
headerhash : 。
boolean cleanjobs : true 。如果設為true，那麼礦工需要清理任務隊列，並立即開始從事新提供的任務，因為所有舊的任務分享都將導致陳舊的分享錯誤。如果是 false 則等當前任務結束才開始新任務。
礦工使用seedhash識別DAG，然後帶著headerhash,extranonce和自己的minernonce尋找低於目標的share(這是由提供的難度而產生的)。
礦機找到合法share時，就以」 mining.submit 「方法向礦池提交任務。礦池返回true即提交成功，如果失敗則error中有具體原因。
Client:
任務ID : bf0488aa
minernonce : 6a909d9bbc0f 。注意minernonce是6個位元組，因為提供的extranonce是2個位元組。如果礦池提供3位元組的extranonce，那麼minernonce必須是5位元組
Server:
一般的礦機與礦池通訊過程就如下所示：
3. Php如何調用以太坊介面
curl方法，file_get_contents,
4. 區塊鏈和智能合約，以太坊開發，183位開發者整理，知識體系匯總
在以太坊上開發應用程序的可用工具、組件、模式和平台的指南。
此列表的創建是由 ConsenSys 的產品經理推動的，他們認為需要在新的和有經驗的區塊鏈開發人員之間更好地共享工具、開發模式和組件。
開發智能合約
智能合約語言
構架
IDE
其他工具
測試區塊鏈網路
測試以太水龍頭
前端以太坊 API
後端以太坊 API
引導程序/開箱即用工具
以太坊 ABI（應用程序二進制介面）工具
以太坊客戶端
貯存
Mahuta - 具有附加搜索功能的 IPFS 存儲服務，以前稱為 IPFS-Store
OrbitDB - IPFS 之上的去中心化資料庫
JS IPFS API - IPFS HTTP API 的客戶端庫，用 JavaScript 實現
TEMPORAL - 易於使用的 API 到 IPFS 和其他分布式/去中心化存儲協議
PINATA - 使用 IPFS 的最簡單方法
消息傳遞
測試工具
安全工具
監控
其他雜項工具
Cheshire - CryptoKitties API 和智能合約的本地沙箱實現，可作為 Truffle Box 使用
ERCs-以太坊評論請求存儲庫
ERC-20 - 可替代資產的原始令牌合約
ERC-721 - 不可替代資產的令牌標准
ERC-777 - 可替代資產的改進令牌標准
ERC-918 - 可開采令牌標准
流行的智能合約庫
可擴展性
支付/狀態通道
等離子體
側鏈
POA橋
POA 橋用戶界面
POA 橋梁合同
ZK-SNARK
ZK-STARK
預構建的 UI 組件
以上內容，來自git庫：
github.com/ConsenSys/ethereum-developer-tools-list
我是魚歌，一個在深圳創業的全棧程序員，主攻區塊鏈，元宇宙和智能合約，附加小程序和app開發。
[祈禱]
5. 以太坊多節點私有鏈部署
假設兩台電腦A和B
要求：
1、兩台電腦要在一個網路中，能ping通
2、兩個節點使用相同的創世區塊文件
3、禁用ipc;同時使用參數--nodiscover
4、networkid要相同，埠號可以不同
1.4 搭建私有鏈
1.4.1 創建目錄和genesis.json文件
創建私有鏈根目錄./testnet
創建數據存儲目錄./testnet/data0
創建創世區塊配置文件./testnet/genesis.json
1.4.2 初始化操作
cd ./eth_test
geth --datadir data0 init genesis.json
1.4.3 啟動私有節點
1.4.4 創建賬號
personal.newAccount()
1.4.5 查看賬號
eth.accounts
1.4.6 查看賬號余額
eth.getBalance(eth.accounts[0])
1.4.7 啟動&停止挖礦
啟動挖礦：
miner.start(1)
其中 start 的參數表示挖礦使用的線程數。第一次啟動挖礦會先生成挖礦所需的 DAG 文件，這個過程有點慢，等進度達到 100% 後，就會開始挖礦，此時屏幕會被挖礦信息刷屏。
停止挖礦，在 console 中輸入：
miner.stop()
挖到一個區塊會獎勵5個以太幣，挖礦所得的獎勵會進入礦工的賬戶，這個賬戶叫做 coinbase，默認情況下 coinbase 是本地賬戶中的第一個賬戶，可以通過 miner.setEtherbase() 將其他賬戶設置成 coinbase。
1.4.8 轉賬
目前，賬戶 0 已經挖到了 3 個塊的獎勵，賬戶 1 的余額還是0：
我們要從賬戶 0 向賬戶 1 轉賬，所以要先解鎖賬戶 0，才能發起交易：
發送交易，賬戶 0 -> 賬戶 1：
需要輸入密碼 123456
此時如果沒有挖礦，用 txpool.status 命令可以看到本地交易池中有一個待確認的交易，可以使用 eth.getBlock("pending", true).transactions 查看當前待確認交易。
使用 miner.start() 命令開始挖礦：
miner.start(1);admin.sleepBlocks(1);miner.stop();
新區塊挖出後，挖礦結束，查看賬戶 1 的余額，已經收到了賬戶 0 的以太幣：
web3.fromWei(eth.getBalance(eth.accounts[1]),'ether')
用同樣的genesis.json初始化操作
cd ./eth_test
geth --datadir data1 init genesis.json
啟動私有節點一,修改 rpcport 和port
可以通過 admin.addPeer() 方法連接到其他節點，兩個節點要要指定相同的 chainID。
假設有兩個節點：節點一和節點二，chainID 都是 1024，通過下面的步驟就可以從節點二連接到節點一。
首先要知道節點一的 enode 信息，在節點一的 JavaScript console 中執行下面的命令查看 enode 信息：
admin.nodeInfo.enode
" enode://@[::]:30303 "
然後在節點二的 JavaScript console 中執行 admin.addPeer()，就可以連接到節點一：
addPeer() 的參數就是節點一的 enode 信息，注意要把 enode 中的 [::] 替換成節點一的 IP 地址。連接成功後，節點一就會開始同步節點二的區塊，同步完成後，任意一個節點開始挖礦，另一個節點會自動同步區塊，向任意一個節點發送交易，另一個節點也會收到該筆交易。
通過 admin.peers 可以查看連接到的其他節點信息，通過 net.peerCount 可以查看已連接到的節點數量。
除了上面的方法，也可以在啟動節點的時候指定 --bootnodes 選項連接到其他節點。 bootnode 是一個輕量級的引導節點，方便聯盟鏈的搭建 下一節講 通過 bootnode 自動找到節點
參考： https://cloud.tencent.com/developer/article/1332424
6. 5、以太坊名詞解析
詳解參見: 私鑰、公鑰、地址
以太坊的密鑰與比特幣作用相同[相當於你在工商、招商、建設等銀行設置的密碼]
以太坊將明文 密鑰 通過 [混入用戶自己設置的密碼] 加密演算法生成的一種JSON格式的字元串，並以文件格式存儲，以達到保存密鑰的作用。
一系列的由12、15、18、21等不同數量的單詞構成。
作用跟Keystore相同，就是給腦子不好使的同學們用的
'JSON是啥...' '這一長串的括弧加數字是什麼鬼...' '我輸入了密碼為什麼出來了這些東西... 你們的錢包APP是不是有問題啊 ...'
舉個花生：
大白話時間：
所有交易都包含以下組件：
7. Infura API 獲取以太坊當前配置鏈 ID - 區塊鏈數據開發實戰
簡介：Infura 是以太坊和 IPFS 的 API 服務提供商。Infura 一開始只是為 ConsenSys 內部項目提供穩定可靠的 RPC 訪問，後來隨著以太坊生態發展，他們意識到自己可以起到更大作用，於是開始面向開發者提供公共 API 服務。本文整理使用 Infura API 獲取以太坊當前配置鏈 ID 的實現。
Infura 是以太坊和 IPFS 的 API 服務提供商。Infura 一開始只是為 ConsenSys 內部項目提供穩定可靠的 RPC 訪問，後來隨著以太坊生態發展，他們意識到自己可以起到更大作用，於是開始面向開發者提供公共 API 服務。
本文整理使用 Infura API 獲取以太坊當前配置鏈 ID 的實現。
Infura API 官方文檔： https://infura.io/docs
使用 API 需要申請 Project ID ，ID 是免費申請的，申請流程為「注冊 - 登錄 - 創建新項目」，不需要審核，幾分鍾就能搞定。
Infura API 標准請求埠格式：
本例中我們使用基於 HTTP 的以太坊主網 JSON-RPC 埠：
Infura API 獲取以太坊當前配置鏈 ID：
Curl 示例：
Node.js 示例：
返回的 JSON 示例：
返回當前鏈 ID 的大整數。
Infura API 服務思維導圖：
我們有一個區塊鏈知識星球，做區塊鏈前沿資料的歸納整理以方便大家檢索查詢使用，也是國內頂尖區塊鏈技術社區，歡迎感興趣的朋友加入。如果你對上面內容有疑問，也可以加入知識星球提問我：
8. 如何使用 Etherscan 的 API
雖然以太坊提供了 Web3 和 Json Rpc 這 2 種 API，geth 也額外提供了一些 API ，但是對於開發以太坊應用來說還是顯得有些不足，比如說獲取交易記錄的時間，需要先通過交易的 hash 找到該交易對應的區塊 id，然後才能找到對應的時間，查詢起來相當不方便。
好在 Etherscan 對外提供了一些公共的 API，給我們提供了額外的能力來處理更多的業務場景。
為了方便開發人員更好地使用 ethersacn.io ，網站提供了 一系列 API 供開發人員使用。
API 的使用非常簡單，基本上都是 get 方法，通過 http 請求就可以直接調用，在每個 Api 的說明文檔都有對應的例子可以查看。
API 主要包含以下模塊：賬號、智能合約、交易、區塊、事件日誌、代幣及工具等。
賬號相關的 API，有獲取賬號金額，獲取交易記錄等，該模塊提供的 API 最多。
API 示例
https://api.etherscan.io/api?mole)=account&action=balance&address=&tag=latest&apikey=YourApiKeyToken
參數說明
其中 mole、action、apikey 是每個 API 都有的參數，其他的參數則因不同 API 而不同。
返回結果
API 示例
https://api.etherscan.io/api?mole=account&action=balancemulti&address=,,&tag=latest&apikey=YourApiKeyToken
參數說明
（前面有講過的參數就不講了，下同）
與單個賬號金額 API 相比，參數 address 用 , 號分隔多個賬號，最多可支持 20 個賬號的金額查詢。
返回結果
API 示例
https://api.etherscan.io/api?mole=account&action=txlist&address=&startblock=0&endblock=99999999&page=1&offset=10&sort=asc&apikey=YourApiKeyToken
參數說明
返回結果
API 示例
https://api.etherscan.io/api?mole=account&action=txlistinternal&address=&startblock=0&endblock=2702578&page=1&offset=10&sort=asc&apikey=YourApiKeyToken
參數說明
參數與上一個 API 基本相同，只有 action 是 txlistinternal 這一點不同，這 2 種交易的區別是什麼呢？簡單的理解就是「正常」的交易是會記錄到區塊鏈上的，而「內部」交易是指不會記錄到區塊鏈上的記錄，比如交易失敗的記錄。
另外這個 API 還可以通過交易 hash 查看交易的詳情。
https://api.etherscan.io/api?mole=account&action=txlistinternal&txhash=&apikey=YourApiKeyToken
返回結果
API 示例
參數說明
返回結果
API 示例
參數說明
返回結果
智能合約相關的 API，其實只有一個獲取智能合約介面的 API，但是這個 API 非常有用。
API 示例
參數說明
智能合約的 abi 就是一個 json 對象，通過這個對象我們可以調用其介面方法，後面會寫一篇文章介紹如何操作 abi 對象，敬請期待。
返回結果
返回結果內容比較長，這里省略，就是一個 json 對象，感興趣的可以自行調用該 API 看結果。
賬號和智能合約的 API 已經能滿足大部分的業務需求了，其他模塊的 API 感覺沒什麼太大的作用，這里就不介紹了，感興趣的讀者可以自行查閱。
這里再說下 API 的使用限制，剛才提到每個 API 都有一個 apikey 參數，如果 API 沒加上這個參數的話，每個 API 的請求次數不能超過 5 次每秒。
Etherscan 提供的這些 API 有些是和以太坊提供的 API 有重復的，比如說獲取賬號金額，獲取事件日誌記錄等，但有一些 API 給我們帶來了很大的便利性，比如獲取賬號交易記錄，有了這個 API 就不用使用幾個原生 API 進行各種數據拼接了。
另外 Etherscan 的這套 API 在 Rinkeby 測試網路也有一套一模一樣的，區別只是前面的 url 不同，Rinkeby 的是： api-rinkeby.etherscan.io ，感興趣的同學可以去試試。
9. DApp開發入門
本文僅介紹以太坊系列的DApp開發，其他鏈原理差不太多。
MetaMask安裝完成並運行後，可以在Chrome控制台列印 MetaMask注入的window.ethereum對象
關於ethereum對象，我們只需要關心 ethereum.request 就足夠了，MetaMask 使用 ethereum.request(args) 方法 來包裝 RPC API。這些 API 基於所有以太坊客戶端公開的介面。 簡單來說錢包交互的大部分操作都是由 request() 方法實現，通過傳入不同的方法名來區分。
⚠️ 即使ethereum對象中提供了chainId，isMetaMask，selectAddress屬性，我們也不能完全相信這些屬性，他們是不穩定或不標准，不建議使用。我們可以通過上面說的request方法，拿到可靠的數據 。
錢包通過method方法名，進行對應的實現 以獲取錢包地址為例
調用 ethereum.request({ method: "eth_requestAccounts" }) ，錢包實現了該方法，那麼就可以拿到錢包的地址了。
MetaMask注入的 window.ethereum 就是一個Provider，一個RPC節點也是一個Provider，通過Provider，我們有了訪問區塊鏈的能力。 在連接到錢包的情況下，通常使用錢包的Provider就可以了， ethers.providers.Web3Provider(ethereum)
如果只需要查詢一些區塊鏈數據，可以使用EtherscanProvider 和 InfuraProvider 連接公開的 第三方節點服務提供商 。JsonRpcProvider 和 IpcProvider 允許連接到我們控制或可以訪問的以太坊節點。
獲取當前賬戶余額
獲取最新區塊號
其他RPC操作，可以通過 JSON-RPC 查看。
通過 ethers.js 可以連接ERC20的合約，合約編譯後會生成ABI，合約部署後，會生成合約地址，開發者通過 ABI和合約地址 ，對合約發送消息。
合約中的方法大致分為兩種： 視圖方法(免費)，非視圖方法(消耗Gas) ，可以通過ABI查看方法類型。
⚠️ ERC20需要多加關注的是 Approve() 方法以及 transfer() 和 transferFrom() 的區別 ，授權過的代幣，被授權的那一方，可以通過調用 transferFrom() 方法,轉走你授權數量內的代幣，所以授權是一個很危險的操作，假設你授權了一個不良的合約，那你會面臨授權的token被轉走的風險，即使你沒有泄露私鑰助記詞。
便利三方庫： web3-react use-wallet
文檔： doc.metamask.io ethers
10. 【深度知識】以太坊數據序列化RLP編碼/解碼原理
RLP(Recursive Length Prefix)，中文翻譯過來叫遞歸長度前綴編碼，它是以太坊序列化所採用的編碼方式。RLP主要用於以太坊中數據的網路傳輸和持久化存儲。
對象序列化方法有很多種，常見的像JSON編碼，但是JSON有個明顯的缺點：編碼結果比較大。例如有如下的結構：
變數s序列化的結果是{"name":"icattlecoder","sex":"male"},字元串長度35，實際有效數據是icattlecoder 和male，共計16個位元組，我們可以看到JSON的序列化時引入了太多的冗餘信息。假設以太坊採用JSON來序列化，那麼本來50GB的區塊鏈可能現在就要100GB，當然實際沒這么簡單。
所以，以太坊需要設計一種結果更小的編碼方法。
RLP編碼的定義只處理兩類數據：一類是字元串（例如位元組數組），一類是列表。字元串指的是一串二進制數據，列表是一個嵌套遞歸的結構，裡面可以包含字元串和列表，例如["cat",["puppy","cow"],"horse",[[]],"pig",[""],"sheep"]就是一個復雜的列表。其他類型的數據需要轉成以上的兩類，轉換的規則不是RLP編碼定義的，可以根據自己的規則轉換，例如struct可以轉成列表，int可以轉成二進制（屬於字元串一類），以太坊中整數都以大端形式存儲。
從RLP編碼的名字可以看出它的特點：一個是遞歸，被編碼的數據是遞歸的結構，編碼演算法也是遞歸進行處理的；二是長度前綴，也就是RLP編碼都帶有一個前綴，這個前綴是跟被編碼數據的長度相關的，從下面的編碼規則中可以看出這一點。
對於值在[0, 127]之間的單個位元組，其編碼是其本身。
例1：a的編碼是97。
如果byte數組長度l <= 55，編碼的結果是數組本身，再加上128+l作為前綴。
例2：空字元串編碼是128，即128 = 128 + 0。
例3：abc編碼結果是131 97 98 99，其中131=128+len("abc")，97 98 99依次是a b c。
如果數組長度大於55， 編碼結果第一個是183加數組長度的編碼的長度，然後是數組長度的本身的編碼，最後是byte數組的編碼。
請把上面的規則多讀幾篇，特別是數組長度的編碼的長度。
例4：編碼下面這段字元串：
The length of this sentence is more than 55 bytes, I know it because I pre-designed it
這段字元串共86個位元組，而86的編碼只需要一個位元組，那就是它自己，因此，編碼的結果如下：
184 86 84 104 101 32 108 101 110 103 116 104 32 111 102 32 116 104 105 115 32 115 101 110 116 101 110 99 101 32 105 115 32 109 111 114 101 32 116 104 97 110 32 53 53 32 98 121 116 101 115 44 32 73 32 107 110 111 119 32 105 116 32 98 101 99 97 117 115 101 32 73 32 112 114 101 45 100 101 115 105 103 110 101 100 32 105 116
其中前三個位元組的計算方式如下：
184 = 183 + 1，因為數組長度86編碼後僅佔用一個位元組。
86即數組長度86
84是T的編碼
例5：編碼一個重復1024次"a"的字元串，其結果為：185 4 0 97 97 97 97 97 97 ...。
1024按 big endian編碼為004 0，省略掉前面的零，長度為2，因此185 = 183 + 2。
規則1~3定義了byte數組的編碼方案，下面介紹列表的編碼規則。在此之前，我們先定義列表長度是指子列表編碼後的長度之和。
如果列表長度小於55，編碼結果第一位是192加列表長度的編碼的長度，然後依次連接各子列表的編碼。
注意規則4本身是遞歸定義的。
例6：["abc", "def"]的編碼結果是200 131 97 98 99 131 100 101 102。
其中abc的編碼為131 97 98 99,def的編碼為131 100 101 102。兩個子字元串的編碼後總長度是8，因此編碼結果第一位計算得出：192 + 8 = 200。
如果列表長度超過55，編碼結果第一位是247加列表長度的編碼長度，然後是列表長度本身的編碼，最後依次連接各子列表的編碼。
規則5本身也是遞歸定義的，和規則3相似。
例7：
["The length of this sentence is more than 55 bytes, ", "I know it because I pre-designed it"]
的編碼結果是:
248 88 179 84 104 101 32 108 101 110 103 116 104 32 111 102 32 116 104 105 115 32 115 101 110 116 101 110 99 101 32 105 115 32 109 111 114 101 32 116 104 97 110 32 53 53 32 98 121 116 101 115 44 32 163 73 32 107 110 111 119 32 105 116 32 98 101 99 97 117 115 101 32 73 32 112 114 101 45 100 101 115 105 103 110 101 100 32 105 116
其中前兩個位元組的計算方式如下：
248 = 247 +1
88 = 86 + 2，在規則3的示例中，長度為86，而在此例中，由於有兩個子字元串，每個子字元串本身的長度的編碼各佔1位元組，因此總共佔2位元組。
第3個位元組179依據規則2得出179 = 128 + 51
第55個位元組163同樣依據規則2得出163 = 128 + 35
例8：最後我們再來看個稍復雜點的例子以加深理解遞歸長度前綴，
["abc",["The length of this sentence is more than 55 bytes, ", "I know it because I pre-designed it"]]
編碼結果是：
248 94 131 97 98 99 248 88 179 84 104 101 32 108 101 110 103 116 104 32 111 102 32 116 104 105 115 32 115 101 110 116 101 110 99 101 32 105 115 32 109 111 114 101 32 116 104 97 110 32 53 53 32 98 121 116 101 115 44 32 163 73 32 107 110 111 119 32 105 116 32 98 101 99 97 117 115 101 32 73 32 112 114 101 45 100 101 115 105 103 110 101 100 32 105 116
列表第一項字元串abc根據規則2，編碼結果為131 97 98 99,長度為4。
列表第二項也是一個列表項：
["The length of this sentence is more than 55 bytes, ", "I know it because I pre-designed it"]
根據規則5，結果為
248 88 179 84 104 101 32 108 101 110 103 116 104 32 111 102 32 116 104 105 115 32 115 101 110 116 101 110 99 101 32 105 115 32 109 111 114 101 32 116 104 97 110 32 53 53 32 98 121 116 101 115 44 32 163 73 32 107 110 111 119 32 105 116 32 98 101 99 97 117 115 101 32 73 32 112 114 101 45 100 101 115 105 103 110 101 100 32 105 116
長度為90，因此，整個列表的編碼結果第二位是90 + 4 = 94, 佔用1個位元組，第一位247 + 1 = 248
以上5條就是RPL的全部編碼規則。
各語言在具體實現RLP編碼時，首先需要將對像映射成byte數組或列表兩種形式。以go語言編碼struct為例，會將其映射為列表，例如Student這個對象處理成列表["icattlecoder","male"]
如果編碼map類型，可以採用以下列表形式：
[["",""],["",""],["",""]]
解碼時，首先根據編碼結果第一個位元組f的大小，執行以下的規則判斷：
1.如果f∈ [0,128),那麼它是一個位元組本身。
2.如果f∈[128,184)，那麼它是一個長度不超過55的byte數組，數組的長度為 l=f-128
3.如果f∈[184,192)，那麼它是一個長度超過55的數組，長度本身的編碼長度ll=f-183,然後從第二個位元組開始讀取長度為ll的bytes，按照BigEndian編碼成整數l，l即為數組的長度。
4.如果f∈(192,247]，那麼它是一個編碼後總長度不超過55的列表，列表長度為l=f-192。遞歸使用規則1~4進行解碼。
5.如果f∈(247,256]，那麼它是編碼後長度大於55的列表，其長度本身的編碼長度ll=f-247,然後從第二個位元組讀取長度為ll的bytes,按BigEndian編碼成整數l，l即為子列表長度。然後遞歸根據解碼規則進行解碼。
以上解釋了什麼叫遞歸長度前綴編碼，這個名字本身很好的解釋了編碼規則。
（1） 以太坊源碼學習—RLP編碼( https://segmentfault.com/a/1190000011763339 )
（2）簡單分析RLP編碼原理
( https://blog.csdn.net/itchosen/article/details/78183991 )