以太坊狀態樹實現

1. 以太坊技術系列-以太坊數據結構

本篇文章和大家介紹一下以太坊的數據結構，上篇文章我們提到，以太坊為了實現智能合約這一功能，使用了基於賬戶的模型。我們來看看以太坊中數據結構。

既然是基於賬戶的模型，我們需要通過賬戶地址找到賬戶的狀態。就像通過銀行卡號可以找到你在銀行中的各種信息一樣。最簡單的想法當然是一個簡單的哈希表 key是賬戶地址 value是賬戶狀態。但這里有個問題解決不了。

輕節點如何校驗賬戶合法性？

上篇我們說過，區塊鏈中有2類節點，全節點和輕節點，輕節點只會存儲block header，所以輕節點如何才能校驗賬號是否合法呢？

這個思路和我們平時用的md5校驗一致，我們會對區塊內的信息進行hash運算從而得出區塊內信息唯一確定的值，區塊鏈所有節點中這個值都是相同的。

在這個過程中我們用到了一種數據結構Merkle Tree（哈希樹），我們先看下Merkle Tree（哈希樹）的示意圖。

上篇文章說到區塊鏈中的鏈表(哈希鏈)和我們平時常見鏈表不同的是將指針從地址改為了hash指，這里也一樣，哈希樹和二叉樹的區別有2個

1.將地址改為了哈希值

2.只有葉子節點存儲數據

回到之前的問題輕節點是如何校驗1個賬戶或交易是否是在鏈上的呢？

整個流程如上圖所示

1.輕節點需要判斷1個賬號是否合法

2.輕節點由於只存儲block header，所以拿到1個賬號的時候會向全節點發出請求

3.全節點存儲了所有賬戶狀態，將賬戶路徑中的需要計算用到的hash值返回給輕節點

4.輕節點本地進行計算根hash值，如果計算結果和自己存儲一致則賬戶合法，不一致則不合法。

那以太坊中的賬戶信息的數據結構就是這樣嗎？

直接用這樣的數據結構來存儲賬戶信息會有2個問題

查找困難

生成hash值不確定

第1個問題應該比較容易發現，在這個樹中尋找1個賬號需要的復雜度是O(n),因為沒有任何順序。

第2個問題其實也是因為無序導致的，無序的組合每個節點針對同一批賬戶生成的hash值不一致，這就導致無法達成共識。

既然2個問題都和順序有關，那我們類似二叉排序樹一樣，使用哈希排序樹是不是就可以解決問題了呢？

使用排序樹後會帶來另外1個問題

插入困難

因為要維持樹是有序的，很可能帶來樹結構的很大變動。

以太坊中使用了另外一種數據結構字典樹。和哈希樹不同，字典樹應該是很多地方都有使用。我們簡單來看下字典樹的結構。

字典樹能夠較好地解決哈希樹的2個缺點1.查找困難 2.生成的hash值不確定以及排序二叉樹的1個缺點 插入困難。

但字典樹我們可以看到可能樹的深度可能由於部分元素導致整棵樹深度非常深。

這時我們可以進一步優化，將相同路徑進行壓縮。這就是壓縮字典樹。

將哈希樹和壓縮字典樹結合，就可以得到以太坊存儲賬戶的最終數據結構-MPT。

將壓縮字典樹裡面的指針從地址改為指針，並且將數據存儲在葉子節點中即可。

介紹完狀態樹的數據結構，我們接下來討論1個問題，區塊中存儲的賬戶狀態是什麼樣的范圍。有2種選擇。

只保存當時區塊中產生交易的賬戶狀態。

保存全局所有的賬戶。

我們可以看下這2種方式，無非就是空間和時間的平衡，只保存當前區塊產生的交易意味著是做懶載入(需要的時候才去尋找賬戶)，在區塊鏈中這個代價是非常大的，因為尋找的賬戶之前從未交易過，這樣會遍歷整個區塊鏈。另外一種保存全局的賬戶方式雖然看起來空間消耗較大，但查找快捷，而且空間的問題我們可以通過其他方式優化。所以最終以太坊選擇了第2種每個區塊都報錯全局所有賬戶的方式。

我們來看下以太坊中是如何保存狀態樹的。

可以看到以太坊中雖然每個區塊都保存了全部賬戶，但是會將未發生變化的賬戶狀態指向前1個節點，本身只存儲發生變化的狀態，這樣可以較大程度優化空間佔用。

介紹完以太坊中比較復雜的狀態樹後，我們繼續來看看以太坊中的另外兩棵樹，交易樹和收據樹。

首先介紹一下，為什麼需要交易樹&收據樹。

1.交易樹

雖然以太坊是基於賬戶的模型，但是就像銀行不僅會存儲銀行卡的余額，還會存儲卡中的每筆錢怎麼來的以及怎麼花的。交易樹中就存儲著當前區塊中的包含的所有交易。

2.收據樹

由於智能合約的引入增加了不少復雜性，所以以太坊用收據樹存儲著一些交易操作的額外信息。比如交易過程中執行日誌就包含在收據樹中方便查詢。收據樹和交易樹是一一對應的。每發生一次交易就會有一次收據。

和狀態樹不同交易樹和收據樹只維護當前區塊內發生的交易，因為當時區塊發生交易時不需要再去查找另外1個交易，也就之前需要可能遍歷整個區塊鏈的查找操作了。

由於以太坊中的出塊速度較快，我們進行一些查詢一些符合條件交易的時候會面臨大量數據遍歷困難的問題。收據樹中引入了布隆過濾器可以幫助我們有效緩解這一困難。

布隆過濾器將大集合中每個元素進行hash運算映射到1個較小的集合，這時再來1個元素要判斷是否在大集合的時候，不需要遍歷整個大集合，而是去進行hash運算去小集合中尋找是否存在，如果不存在，肯定不在大集合中，如果存在則不能說明任何問題。

如上圖所示，布隆過濾器只能證明某1個元素不在集合中，不能證明1個元素在結合中。

以太坊中如果我們要在較多區塊中尋找某1個交易，則可以利用布隆過濾器，過濾掉肯定不存在目標交易的區塊，然後進入收據樹內繼續利用布隆過濾器篩選，剩下的才是可能的目標交易的交易，進行一一比對即可。

我們介紹了以太坊的核心數據結構，狀態樹&交易樹&收據樹，他們都是使用相同的數據結構-哈希壓縮字典樹。但狀態樹是維護1顆全局賬戶樹，交易樹和收據樹則是維護本區塊內的交易或收據。

介紹完數據結構後，後面我們會用幾篇文章來介紹以太坊中的一些核心演算法，比如共識機制，挖礦演算法等。

2. 以太坊解讀——Recursive Length Prefix協議圖解(上)

在以太坊中，採用了一種名為Recursive Length Prefix(RLP)的方法對交易、賬號、合約等基礎的數據結構進行序列化處理，從而實現對鏈上數據的網路傳輸和持久化存儲。RLP作為最為底層的編碼方法，其重要性是不言而喻。因此，網上介紹RLP的文章也不少，但是由於RLP是二進制編碼，又涉及到嵌套結構，造成編碼過程的可讀性較差，在學習中過程中，也一直沒有找到完整的、易於理解的說明，總是繞在各種規則之中，且不能"自拔"，著實有點無奈。所以，在本文中，採用圖形化的解釋和舉例的方法，幫助大家理解RLP嵌套等特點、編解碼過程等。

和其他的序列化協議不同，RLP只支持兩種數據類型：
1）byte數組，可以是二進制數組，當然也可以是字元串；
2）byte數組的數組，也就是列表。並支持列表內的嵌套。
對於其他的數據類型，RLP都不支持，需要用戶自己先轉化為數組和列表的類型。

從RLP的命名中就可以看出兩個關鍵字：一個是遞歸Recursive和前綴Prefix。首先，關於遞歸，也就是嵌套結構，結構上非常接近「樹」，在Ethereum WiKi中，更是直接地採用樹的items來進行命名，葉子節點(leaf tress)來存儲「byte數組」，嵌套的節點就是一個樹的分叉(branching trees)。

比如，需要是對如下對象進行RLP的編碼，該對象中包含一個字元數組的列表、一個單個字元的字元數組、一個空字元數組。

< <[cat],[dog]>, [0xbf], [] >

將該對象展開為樹的結構，就如下圖。其中[0xbf]和[]屬於字元數組。<[cat], [dog]>屬於列表，可以嵌套展開，再根據各個節點，進行編碼。然後，對於不同長度的數組和列表，編碼的方法略有不同，這個也就是Length Prefix相關的內容，和「編碼過程」相關的內容，在第二節進行詳細地說明。

關於為什麼以太坊需要單獨設計一種序列化協議，目前還沒有找到官方的描述。但與其他序列化方法相比，RLP協議具有一些直接的優點，比如：

1）在以太坊中，最小貨幣單位為1 Wei，並且1 ETH = 10^18 Wei，所以在編碼中，需要考慮對很大的整數類型的序列化，在RLP中採用去除前導零(leading zero)的大端big-endian方式，可以有效處理大整數；

2）使用了靈活的長度前綴來表示數據的實際長度，並且使用遞歸的方式能編碼相當大的數據；

3）為了實現在鏈上節點的「共識Consensus」，防止出現數據的不一致，以太坊中並不支持浮點數類型，所以一般的序列化協議也不適用。

編碼的過程就是將嵌套結構(nested sequence)的樹形結構，添加長度前綴(Length Prefix)後，轉化為順序結構(flat sequence)的過程。添加長度前綴的目的，就是在反序列化時，可以根據長度前綴(Length Prefix)，將(flat sequence)重構出樹的結構(nested sequence)。

關於前綴的生成規則，《Ethereum Yellow Paper》[2]給出了非常形式化的數學符號描述，漂亮是非常漂亮，可惜不是人類的語言，非常難於理解和表達。網上大部分文章的寫法也是引用了Yellow Paper中的5個文字形式上的描述，把原文和翻譯一並給出如下：

將上面這個「長度」Length Prefix的編碼規則，通過「決策樹」可以圖形化的表達如下圖。

首先，根據編碼的類型，進行分類，分為「位元組數組」和「列表」兩類；第二，根據不同的長度，編碼的長度前綴不同。若待編碼對象的長度小於56，就是把長度和「前綴字元」進行求和，佔用一個位元組。反之，待編碼對象的長度大於56，其前綴需要多個位元組，第一個位元組，求出「長度」所佔的位元組數，再加上「前綴字元」，比如：長度為56，佔用1位元組。然後對「長度」進行編碼，其實也是一個嵌套的過程。

還是以上文中的例子，該編碼對象，已經完成了「樹的構建」，然後根據「長度前綴」的原則，對樹的各個項目進行長度前綴的計算。

< <[cat],[dog]>, [0xbf], [] >

-對於<[cat],[dog]>屬於嵌套數組，需要對內部各項非常進行長度編碼的計算
  `對於[cat]，屬於字元數組，且長度為3，其對應的長度為0x80+3 = 0x83
  `對於[dog]，屬於字元數組，且長度為3，其對應的長度為0x80+3 = 0x83
  `<[cat],[dog]>整體上，其長度前綴為0xc0 + 2(新增的兩個子項的長度所佔用的位元組)+6(待編碼字元的長度)=0xC8
- 對於[0xbf], 屬於字元數組，且長度為1，其對應的長度為0x80+1 = 0x81
- 對於[dog]，屬於字元數組，且長度為3，其對應的長度為0x80+3 = 0x83
- 對於[]，屬於字元數組，且長度為0，其對應的長度為0x80+0=0x80
總體上，增加的「長度編碼」的位元組數為6，加上原來的長度為10，所以整個對象的長度前綴為0xC0+16d=0xD0。所以最後的編碼結果為：
D0 C8 83636174 83646F67 81B7 83646F67 80

解碼過程將在 《以太坊解讀——Recursive Length Prefix協議圖解(下)》 一文中，給出圖形化的解讀說明。

3. 以太坊技術系列-以太坊共識機制

區塊鏈的特點之一是去中心化。也就是節點會分布在各個地方組成分布式系統。各個節點需要對1個問題達成一致，理想情況下，只需要同步狀態即可。

如上圖所示 B節點將a=1=> a=2的狀態同步給  ACDE四個節點，這時系統中狀態變為a=2, 但如果其中有惡意節點 AE 收到通知後把a=1=>a=3修改為錯誤的節點，這個時候大家的狀態就不一致了，此時需要共識機制使系統中得到1個唯一正確的狀態。

如上面說到分布式系統存在惡意節點導致系統中狀態不一致的情況有1個比較著名的虛擬問題-拜占庭將軍問題。

拜占庭將軍問題是指，N個將軍去攻打一座城堡，如果大於一定數量的將軍同時進攻則可以攻打成功，如果小於則進攻失敗。將軍中可能存在叛徒。

這個時候有2種情況

1.如果2個叛徒都在BCDE中，那麼共識演算法需要讓其餘2個將軍聽從A的正確決策進攻城堡。

2.如果A是1個叛徒，共識演算法需要讓BCDE中剩餘的3個忠誠將軍保持一致。

這個問題有很多種解法，大家有興趣可以自行查閱(推薦學習PBFT)，我們重點來看看以太坊中目前正在使用的Nakamoto 共識和將要使用的 Casper Friendly Finality Gadget共識是如何解決拜占庭將軍問題的。

說到Nakamoto共識和Casper Friendly Finality Gadget共識可能大家不太熟悉，但他們的部分組成應該都比較熟悉-POW(工作量證明)和POS(權益證明)。

POW或POS稱之為Sybil抗性機制，為什麼需要Sybil抗性機制呢，剛剛我們說到拜占庭將軍問題，應該很容易看出惡意節點越多，達成正確共識的難度也就越大，Sybil攻擊就是指1個攻擊者可以偽裝出大量節點來進行攻擊，Sybil抗性是指抵禦這種攻擊能力。

POW通過讓礦工或驗證者投入算力，POS通過讓驗證者質押以太坊，如果攻擊者要偽裝多個節點攻擊則必將投入大量的算力或資產，會導致攻擊成本高於收益。在以太坊中保障的安全性是除非攻擊者拿到整個系統51%算力或資產否則不可能進攻成功。

在解決完Sybil攻擊後，通過選取系統中的最長鏈作為大家達成共識的鏈。

很多人平時為了簡化將pow和pos認為是共識機制，這不夠准確，但也說明了其重要作用，我們接下來分析pow和pos。

通過hash不可逆的特性，要求各個礦工不停地計算出某個值的hash符合某一特徵，比如前多少位是000000，由於這個過程只能依賴不停的試錯計算hash,所以是工作量證明。計算完成後其他節點驗證的值符合hash特徵非常容易驗證。驗證通過則成為成為合法區塊(不一定是共識區塊，需要在最長鏈中)。

以太坊中的挖礦演算法用到2個數據集，1個小數據集cache,1個大數據集DAG。這2個數據集會隨著區塊鏈中區塊增多慢慢變大，初始大小cache為16M DAG為1G。

我們先來看這2個數據集的生成過程

cache生成規則為有1個種子隨機數seed，cache中第1個元素對seed取hash，後面數組中每個元素都是前1個元素取hash獲得。

DAG生成規則為 找到cache中對應的元素後 根據元素中的值計算出下次要尋找的下標，循環256次後獲得cache中最終需要的元素值進行hash計算得到DAG中元素的值。

然後我們再看看礦工如何進行挖礦以及輕節點如何驗證

礦工挖礦的過程為，選擇Nonce值映射到DAG中的1個item，通過item中的值計算出下次要找的下標，循環64次，得到最終item，將item中的值hash計算得到結果，結果和target比較，符合條件

則證明挖到區塊，如果不符合則更換nonce繼續挖礦。礦工在挖礦過程中需要將1G的DAG讀取到內存中。

輕節點驗證過程和礦工挖礦過程基本一致，

將塊頭裡面的Nonce值映射到DAG中的1個item，然後通過cache數組計算出該item的值，通過item中的值計算出下次要找的下標，循環64次，得到最終item，將item中的值hash計算得到結果，結果和target比較，符合條件則驗證通過。輕節點在驗證過程中不需要將1G的DAG讀取到內存中。每次用到DAG的item值都使用cache進行計算。

以太坊為什麼需要這2個不同大小的數組進行輔助hash運算呢，直接進行hash運算會有什麼問題？

如果只是進行重復計算會導致挖礦設備專業化，減少去中心化程度。因為我們日常使用的計算機內存和計算力是都需要的，如果挖礦只需要hash運算，挖礦設備則會設計地擁有超高算力，但對內存可以縮小到很小甚至沒有。所以我們選用1G的大內存增加對內存訪問的頻率，增加挖礦設備對內存訪問需求，從而更接近於我們日常使用的計算機。

我們看看在Nakamoto共識是如何解決拜占庭將軍問題的。首先看看區塊鏈中的拜占庭將軍問題是什麼？

區塊鏈中需要達成一致的是哪條鏈為主鏈，雖然採用了最長鏈原則，但由於分叉問題，還是會帶來拜占庭將軍問題。

本來以太坊pow目標是抵抗51%以下的攻擊，但如上圖如果惡意節點沿著自己挖出的區塊不斷挖礦，由於主鏈上有分叉存在，惡意節點不需要達到51%算力就可以超過主鏈進而成為新的主鏈，為此以太坊使用了ghost協議給上圖中的B1和C1也分配出塊獎勵，盡快合並到主鏈中，這樣主鏈長度(按照合並後的總長度算，長度只是抽象概念，以太坊中按照區塊權重累加)還是大於惡意節點自己挖礦的。

網路中的用戶通過質押一定數量的以太坊成為驗證者。每次系統從這些驗證者從隨機選擇出區塊創建者，其餘驗證者去驗證創建出的區塊是否合法。驗證者會獲得出塊獎勵，沒有被選中的區塊不進行驗證則會被扣除一定質押幣，如果進行錯誤驗證則會被扣除全部質押幣。

如上圖，權益證明在每隔一定區塊的地方設置一個檢查點，對前面的區塊進行驗證，2/3驗證者通過則驗證通過，驗證通過則該區塊所在鏈成為最長合法鏈(不能被回滾)。

我們簡化地只分析了權益證明本身，在以太坊中權益證明較為復雜的點在於和分片機制結合在一起時的運行流程，這部分會在後面單獨將分片機制的一篇文章中詳述。

本篇文章主要討論了共識機制是解決分布式系統中的拜占庭將軍問題，以及分析了以太坊中的共識機制一般包括最長鏈選擇和一種sybil抗性機制(pow或pos)。重點分析了pow和pos的流程以及設計思想。後續將開始重點討論智能合約的部分。

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. 什麼是狀態樹

狀態樹
是運用狀態機進行開發的有利助手，狀態樹位於Visual C++的Workspace Tab窗口。在開發過程中，它能夠提供一個狀態機代碼自動生成框架，幫您輕松地完成諸如「新建一個狀態機應用」、「新建一個狀態」、「定義狀態的入口/出口函數」以及「定義事件處理函數」這些重復性的工作。在調試期，您還可以在狀態樹中獲得跟蹤功能支持

6. 什麼是以太坊（Ethereum）imToken支持符合ERC20代幣

以太坊（Ethereum）是一個開源的有智能合約功能的公共區塊鏈平台。通過其專用加密貨幣以太幣（Ether，又稱「以太幣」）提供去中心化的虛擬機（稱為「以太虛擬機」Ethereum Virtual Machine）來處理點對點合約。以太坊的概念首次在2013至2014年間由程序員Vitalik Buterin受比特幣啟發後提出，大意為「下一代加密貨幣與去中心化應用平台」，在2014年通過ICO眾籌得以開始發展。
以太坊不僅是一個資料庫，它還允許你在區塊鏈的可信環境中運行程序。以太坊在區塊鏈上搭建了一個名為 EVM（Ethereum Virtual Machine，以太坊虛擬機）的虛擬機。EVM 允許在區塊鏈上驗證和執行代碼，為代碼在每個人的機器上以相同方式運行提供保障。這些代碼包含在智能合約中。除了追蹤賬戶余額，以太坊使用相同方法將 EVM 的狀態保存在區塊鏈上。所有節點處理智能合約，來驗證合約本身及其輸出的完整性。

7. 狀態管理（1）- Rex

應用的整體全局狀態以對象樹的方式存放於單個store。唯一改變狀態樹（state tree）的方法是創建action， 一個描述發生了什麼的對象，並將其dispatch給store。要指定狀態樹如何響應action來進行更新，你可以編寫recer函數，這些函數根據舊的action來計算新state。

上面這段摘抄自官網，個人認為是比較通俗的概括了rex的使用方法，你或許還沒有很理解它，繼續往下看，相信你會有所收獲

一個簡單的例子，帶你熟悉rex

『默認值』 存在state里，我們點擊按鈕之後，改變改值

使用腳手架創建應用，安裝依賴

安裝rex

編寫ui

添加home組件

創建action：
在根目錄下創建action文件夾，在action文件下創建index.js
這里我們定義一個action的構建函數，讓他返回action對象

action 可以理解為表示即將放生的變化類別，它是一個普通的對象，必須包含type屬性，這里我們添加我們需要的value屬性，作為傳遞的數據

創建Recer：
在根目錄下新建recer文件夾，在recer文件夾下新建index.js 文件
本質就是函數，用於響應發送過來的action，函數接受兩個參數，第一個是初始化state，第二個是發送過來的action
這里我們將默認的state也放到recer 文件中Object.assign({},state,action);
如果action的type為send_type 則返回， 不要忘記將recer暴露出去

創建store
store是用來把action和recer關聯到一起的， 我們通過createStore來構建store，通過subscribe來注冊監，通過dispatch來發送action。
store.dispatch() 並傳入一個action對象，store將執行所有recer函數並計算出更新後的state，調用getState()可以獲取新state
dispatch一個action可以形象的理解為「出發一個事件」，發生了一些事情，我們希望store知道這件事。Recer就像事件監聽器一樣，當它們收到關注的action後，它就會更新state作為響應

這里是最難理解的地方，你可以認為store的dispatch方法才是最終告知要執行action的動作了，你這個動作具體做了什麼需要recer來處理

根目錄下創建store文件夾，在store文件夾下創建index.js
同樣的將store暴露出去

action、recer、store 都寫好了，現在我們將這個rex用到組件中
我們通過store的subscribe來注冊監，通過dispatch來發送action
組件一載入完成就注冊監聽
Home組件

store.getState()獲取當前state

8. 以太坊架構是怎麼樣的

以太坊最上層的是DApp。它通過Web3.js和智能合約層進行交換。所有的智能合約都運行在EVM（以太坊虛擬機）上，並會用到RPC的調用。在EVM和RPC下面是以太坊的四大核心內容，包括：blockChain, 共識演算法，挖礦以及網路層。除了DApp外，其他的所有部分都在以太坊的客戶端里，目前最流行的以太坊客戶端就是Geth（Go-Ethereum）

9. 【以太坊易錯概念】nonce, 公私鑰和地址，BASE64/BASE58,

以太坊里的nonce有兩種意思，一個是proof of work nonce，一個是account nonce。

在智能合約里，nonce的值代表的是該合約創建的合約數量。只有當一個合約創建另一個合約的時候才會增加nonce的值。但是當一個合約調用另一個合約中的method時 nonce的值是不變的。
在以太坊中nonce的值可以這樣來獲取（其實也就是屬於一個賬戶的交易數量）：

但是這個方法只能獲取交易once的值。目前是沒有內置方法來訪問contract中的nonce值的

通過橢圓曲線演算法生成鑰匙對（公鑰和私鑰），以太坊採用的是secp256k1曲線,
公鑰採用uncompressed模式，生成的私鑰為長度32位元組的16進制字串，公鑰為長度64的公鑰字串。公鑰04開頭。
把公鑰去掉04，剩下的進行keccak-256的哈希，得到長度64位元組的16進制字串，丟掉前面24個，拿後40個，再加上"0x"，即為以太坊地址。

整個過程可以歸納為：

2）有些網關或系統只能使用ASCII字元。Base64就是用來將非ASCII字元的數據轉換成ASCII字元的一種方法，而且base64特別適合在http，mime協議下快速傳輸數據。Base64使用【字母azAZ數字09和+/】這64個字元編碼。原理是將3個位元組轉換成4個位元組(3 X 8) = 24 = (4 X 6)
當剩下的字元數量不足3個位元組時，則應使用0進行填充，相應的，輸出字元則使用'='佔位，因此編碼後輸出的文本末尾可能會出現1至2個'='。

1）Base58是用於Bitcoin中使用的一種獨特的編碼方式，主要用於產生Bitcoin的錢包地址。相比Base64，Base58不使用數字"0"，字母大寫"O"，字母大寫"I"，和字母小寫"l"，以及"+"和"/"符號。

Base58Check是一種常用在比特幣中的Base58編碼格式，增加了錯誤校驗碼來檢查數據在轉錄中出現的錯誤。 校驗碼長4個位元組，添加到需要編碼的數據之後。校驗碼是從需要編碼的數據的哈希值中得到的，所以可以用來檢測並避免轉錄和輸入中產生的錯誤。使用 Base58check編碼格式時，編碼軟體會計算原始數據的校驗碼並和結果數據中自帶的校驗碼進行對比。二者不匹配則表明有錯誤產生，那麼這個 Base58Check格式的數據就是無效的。例如，一個錯誤比特幣地址就不會被錢包認為是有效的地址，否則這種錯誤會造成資金的丟失。

為了使用Base58Check編碼格式對數據（數字）進行編碼，首先我們要對數據添加一個稱作「版本位元組」的前綴，這個前綴用來明確需要編碼的數 據的類型。例如，比特幣地址的前綴是0（十六進制是0x00），而對私鑰編碼時前綴是128（十六進制是0x80）。 表4-1會列出一些常見版本的前綴。

接下來，我們計算「雙哈希」校驗碼，意味著要對之前的結果（前綴和數據）運行兩次SHA256哈希演算法：

checksum = SHA256(SHA256(prefix+data))
在產生的長32個位元組的哈希值（兩次哈希運算）中，我們只取前4個位元組。這4個位元組就作為校驗碼。校驗碼會添加到數據之後。

結果由三部分組成：前綴、數據和校驗碼。這個結果採用之前描述的Base58字母表編碼。下圖描述了Base58Check編碼的過程。

相同:

1） 哈希演算法、Merkle樹、公鑰密碼演算法
https://blog.csdn.net/s_lisheng/article/details/77937202?from=singlemessage

2）全新的 SHA-3 加密標准 —— Keccak
https://blog.csdn.net/renq_654321/article/details/79797428

3）在線加密演算法
http://tools.jb51.net/password/hash_md5_sha

4）比特幣地址生成演算法詳解
https://www.cnblogs.com/zhaoweiwei/p/address.html

5）Base58Check編碼實現示例
https://blog.csdn.net/QQ604666459/article/details/82419527

6） 比特幣交易中的簽名與驗證
https://www.jianshu.com/p/a21b7d72532f

10. 以太坊是如何挖礦的

以太坊的代幣是通過采礦過程中產生的，每塊采礦率為 5 個以太幣。以太坊的采礦過程幾乎與比特幣相同，對於每一筆交易，礦工都可以使用計算機通過散列函數運行該塊的唯一標題元數據，反復，快速地猜出答案，直到其中一人獲勝。

許多新用戶認為，采礦的唯一目的是以不需要中央發行人的方式生成醚（參見我們的指南「 什麼是以太？ 」）。這是真的。以太坊的代幣是通過采礦過程中產生的，每塊采礦率為 5 個以太幣。但是，采礦還有至少同樣重要的作用。通常，銀行負責保持交易的准確記錄。他們確保資金不是憑空創造的，用戶不會多次欺騙和花錢。不過，區塊鏈引入了一種全新的記錄保存方式，整個網路而不是中介，驗證交易並將其添加到公共分類賬。

Ethereum Mining

盡管「無信任」或「信任最小化」貨幣體系是目標，但仍有人需要確保財務記錄的安全，確保沒有人作弊。采礦是使分散記錄成為可能的創新之一。礦工們在防止欺詐行為（特別是醚的雙重支出）方面達成了關於交易歷史的共識 – 這是一個有趣的問題，在分散化的貨幣未在工作區塊鏈之前解決。雖然以太坊正在研究其他方法來就交易的有效性達成共識，但采礦目前將平台保持在一起。

挖礦如何工作
今天，以太坊的采礦過程幾乎與比特幣相同。對於每一筆交易，礦工都可以使用計算機反復，快速地猜出答案，直到其中一人獲勝。更具體地說，礦工將通過散列函數（它將返回一個固定長度，亂序的數字和字母串，它看起來是隨機的）運行該塊的唯一標題元數據（包括時間戳和軟體版本），只改變』nonce 值』 ，這會影響結果散列值。

如果礦工發現與當前目標相匹配的散列，礦工將被授予乙醚並在整個網路上廣播該塊，以便每個節點驗證並添加到他們自己的分類賬副本中。如果礦工 B 找到散列，礦工 A 將停止對當前塊的工作，並為下一個塊重復該過程。礦工很難在這場比賽中作弊。沒有辦法偽造這項工作，並拿出正確的謎題答案。這就是為什麼解謎方法被稱為「工作證明」。

另一方面，其他人幾乎沒有時間驗證散列值是否正確，這正是每個節點所做的。大約每 12-15 秒，一名礦工發現一塊石塊。如果礦工開始比這更快或更慢地解決謎題，演算法會自動重新調整問題的難度，以便礦工回彈到大約 12 秒鍾的解決時間。

礦工們隨機賺取這些乙醚，他們的盈利能力取決於運氣和他們投入的計算能力。以太坊使用的具體工作量驗證演算法被稱為』ethash』，旨在需要更多的內存，使得使用昂貴的 ASIC 難以開采 – 特殊的采礦晶元，現在是唯一可以盈利的比特幣開采方式。

從某種意義上講，ethash 可能已經成功實現了這一目的，因為專用 ASIC 不可用於以太坊（至少目前還沒有）。此外，由於以太坊旨在從工作證明挖掘轉變為「股權證明」（我們將在下面討論），購買 ASIC 可能不是一個明智的選擇，因為它可能無法長久證明有用。

轉移到股權證明
不過，以太坊可能永遠不需要礦工。開發人員計劃放棄工作證明，即網路當前使用的演算法來確定哪些交易是有效的，並保護其免受篡改，以支持股權證明，網路由代幣所有者擔保。如果並且當該演算法推出時，股權證明可以成為實現分布式共識的一種手段，而該共識使用更少的資源。