⑴ 以太坊技術系列-以太坊數據結構
本篇文章和大家介紹一下以太坊的數據結構，上篇文章我們提到，以太坊為了實現智能合約這一功能，使用了基於賬戶的模型。我們來看看以太坊中數據結構。
既然是基於賬戶的模型，我們需要通過賬戶地址找到賬戶的狀態。就像通過銀行卡號可以找到你在銀行中的各種信息一樣。最簡單的想法當然是一個簡單的哈希表 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顆全局賬戶樹，交易樹和收據樹則是維護本區塊內的交易或收據。
介紹完數據結構後，後面我們會用幾篇文章來介紹以太坊中的一些核心演算法，比如共識機制，挖礦演算法等。
⑵ 【深度知識】以太坊數據序列化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 )
⑶ 什麼是以太坊（Ethereum）imToken支持符合ERC20代幣
以太坊（Ethereum）是一個開源的有智能合約功能的公共區塊鏈平台。通過其專用加密貨幣以太幣（Ether，又稱「以太幣」）提供去中心化的虛擬機（稱為「以太虛擬機」Ethereum Virtual Machine）來處理點對點合約。以太坊的概念首次在2013至2014年間由程序員Vitalik Buterin受比特幣啟發後提出，大意為「下一代加密貨幣與去中心化應用平台」，在2014年通過ICO眾籌得以開始發展。
以太坊不僅是一個資料庫，它還允許你在區塊鏈的可信環境中運行程序。以太坊在區塊鏈上搭建了一個名為 EVM（Ethereum Virtual Machine，以太坊虛擬機）的虛擬機。EVM 允許在區塊鏈上驗證和執行代碼，為代碼在每個人的機器上以相同方式運行提供保障。這些代碼包含在智能合約中。除了追蹤賬戶余額，以太坊使用相同方法將 EVM 的狀態保存在區塊鏈上。所有節點處理智能合約，來驗證合約本身及其輸出的完整性。
⑷ 以太坊是什麼丨以太坊開發入門指南
以太坊是什麼丨以太坊開發入門指南
很多同學已經躍躍欲試投入到區塊鏈開發隊伍當中來，可是又感覺無從下手，本文將基於以太坊平台，以通俗的方式介紹以太坊開發中涉及的各晦澀的概念，輕松帶大家入門。
以太坊是什麼
以太坊（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來搭建一個測試網路。
註：本文中為了方便大家理解，對一些概念做了類比，有些嚴格來不是准確，不過我也認為對於初學者，也沒有必要把每一個概念掌握的很細致和准確，學習是一個逐步深入的過程，很多時候我們會發現，過一段後，我們會對同一個東西有不一樣的理解。
⑸ 什麼是以太幣/以太坊ETH
以太幣（ETH）是以太坊（Ethereum）的一種數字代幣，被視為「比特幣2.0版」，採用與比特幣不同的區塊鏈技術「以太坊」（Ethereum），一個開源的有智能合約成果的民眾區塊鏈平台，由全球成千上萬的計算機構成的共鳴網路。開發者們需要支付以太幣（ETH）來支撐應用的運行。和其他數字貨幣一樣，以太幣可以在交易平台上進行買賣 。
溫馨提示：以上解釋僅供參考，不作任何建議。入市有風險，投資需謹慎。您在做任何投資之前，應確保自己完全明白該產品的投資性質和所涉及的風險，詳細了解和謹慎評估產品後，再自身判斷是否參與交易。
應答時間：2020-12-02，最新業務變化請以平安銀行官網公布為准。
[平安銀行我知道]想要知道更多？快來看「平安銀行我知道」吧~
https://b.pingan.com.cn/paim/iknow/index.html
⑹ 以太坊架構是怎麼樣的
以太坊最上層的是DApp。它通過Web3.js和智能合約層進行交換。所有的智能合約都運行在EVM（以太坊虛擬機）上，並會用到RPC的調用。在EVM和RPC下面是以太坊的四大核心內容，包括：blockChain, 共識演算法，挖礦以及網路層。除了DApp外，其他的所有部分都在以太坊的客戶端里，目前最流行的以太坊客戶端就是Geth（Go-Ethereum）
⑺ 以太坊怎麼修改數據
先以太坊的數據保存在user用戶名當中需要在硬碟的位置,一是可以備份你的私鑰,而是可以刪除錢包,還有其他的一些比較詳細的操作
原標題:《解碼以太坊智能合約數據》 正如我們在之前的文章中所討論的,智能合約交易類似於智能合約驅動的web3應用程序中的後端API調用。每個智能合約交易和結果應用程序狀態更改的細
以太坊中各種操作都需要支付gas,如存儲數據、創建合約以及執行哈希計算等操作發起方在某次操作中願意支付的最高手續費
⑻ 區塊鏈中的數據存在哪裡
區塊鏈的數據中都存在終端或者是存在伺服器裡面的。因為都說的是區塊鏈嘛，他的用戶終端也可以是伺服器，伺服器也可以是用戶終端，所以都儲存在這些設備上面。
⑼ 以太坊是一個什麼樣的東西怎麼開發
以太坊是一種區塊鏈的實現。在以太坊網路中，眾多的節點彼此連接，構成了以太坊網路： 以太坊節點軟體提供兩個核心功能：數據存儲、合約代碼執行。在每個以太坊全節點中，都保存有完整的區塊鏈數據。以太坊不僅將交易數據保存在鏈上，編譯後 的合約代碼同樣也保存在鏈上。以太坊全節點中，同時還提供了一個虛擬機來執行合約代碼。以太坊虛擬機 以太坊區塊鏈不僅存儲數據和代碼，每個節點中還包含一個虛擬機（EVM：Ethereum Virtual Machine）來執行 合約代碼 —— 聽起來就像計算機操作系統。事實上，這一點是以太坊區別於比特幣（Bitcoin）的最核心的一點：虛擬機的存在使區塊鏈邁入了2.0 時代，也讓區塊鏈第一次成為應用開發者友好的平台。以上內容來自：以太坊DApp開發入門教程
⑽ 以太坊技術系列-以太坊共識機制
區塊鏈的特點之一是去中心化。也就是節點會分布在各個地方組成分布式系統。各個節點需要對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的流程以及設計思想。後續將開始重點討論智能合約的部分。