ethtxhash

Ⅰ 【ETH錢包開發03】web3j轉賬ETH

在之前的文章中，講解了創建、導出、導入錢包。
【ETH錢包開發01】創建、導出錢包
【ETH錢包開發02】導入錢包

本文主要講解以太坊轉賬相關的一些知識。交易分為ETH轉賬和ERC-20 Token轉賬，本篇先講一下ETH轉賬。

1、解鎖賬戶發起交易。錢包keyStore文件保存在geth節點上，用戶發起交易需要解鎖賬戶，適用於中心化的交易所。

2、錢包文件離線簽名發起交易。錢包keyStore文件保存在本地，用戶使用密碼+keystore的方式做離線交易簽名來發起交易，適用於dapp，比如錢包。

本文主要講一下第二種方式，也就是錢包離線簽名轉賬的方式。

交易流程
1、通過keystore載入轉賬所需的憑證Credentials
2、創建一筆交易RawTransaction
3、使用Credentials對象對交易簽名
4、發起交易

注意以下幾點：

1、Credentials
這里，我是通過獲取私鑰的方式來載入 Credentials

還有另外一種方式，通過密碼+錢包文件keystore方式來載入 Credentials

2、nonce

nonce是指發起交易的賬戶下的交易筆數，每一個賬戶nonce都是從0開始，當nonce為0的交易處理完之後，才會處理nonce為1的交易，並依次加1的交易才會被處理。

可以通過 eth_gettransactioncount 獲取nonce

3、gasPrice和gasLimit
交易手續費由gasPrice 和gasLimit來決定，實際花費的交易手續費是 gasUsed * gasPrice 。所有這兩個值你可以自定義，也可以使用系統參數獲取當前兩個值

關於 gas ，你可以參考我之前的一篇文章。
以太坊（ETH）GAS詳解

gasPrice和gasLimit影響的是轉賬的速度，如果gas過低，礦工會最後才打包你的交易。在app中，通常給定一個默認值，並且允許用戶自己選擇手續費。

如果不需要自定義的話，還有一種方式來獲取。獲取以太坊網路最新一筆交易的 gasPrice ,轉賬的話， gasLimit 一般設置為21000就可以了。

Web3j還提供另外一種簡單的方式來轉賬以太幣,這種方式的好處是不需要管理nonce，不需要設置gasPrice和gasLimit，會自動獲取最新一筆交易的gasPrice，gasLimit 為21000（轉賬一般設置成這個值就夠用了）。

這個問題，我想是很多朋友所關心的吧。但是到目前為止，我還沒有看到有講解這方面的博客。

之前問過一些朋友，他們說可以通過區塊號、區塊哈希來判斷，也可以通過Receipt日誌來判斷。但是經過我的一番嘗試，只有 BlockHash 是可行的，在web3j中根據 blocknumber 和 transactionReceipt 都會報空指針異常。

原因大致是這樣的：在發起一筆交易之後，會返回 txHash ，然後我們可以根據這個 txHash 去查詢這筆交易相關的信息。但是剛發起交易的時候，由於手續費問題或者乙太網絡擁堵問題，會導致你的這筆交易還沒有被礦工打包進區塊，因此一開始是查不到的，通常需要幾十秒甚至更長的時間才能獲取到結果。我目前的解決方案是輪詢的去刷 BlockHash ，一開始的時候 BlockHash 的值為0x00000000000，等到打包成功的時候就不再是0了。

這里我使用的是rxjava的方式去輪詢刷的，5s刷新一次。

正常情況下，幾十秒內就可以獲取到區塊信息了。

區塊確認數=當前區塊高度-交易被打包時的區塊高度。

Ⅱ linux 內核軟中斷 是在中斷狀態嗎

先說說環境
1.硬體:DELL R410
2.網卡:板載1000M BCM5709
2.OS: RHEL 5.5 x86_64
3.KERNEL: 2.6.18-194.el5
所出現的問題
1.網卡毫無徵兆的down掉，而且沒有任何log信息
2.當流量增大時，不到理論上限的1/3時機器出現網路延遲嚴重，伴隨大量的丟包
3.機器的cpu軟中斷不均衡，只有1個cpu處理軟中斷，並且該cpu的軟中斷周期性的達到100%
4.內外網網卡做nat丟包數據量不一致，差別很大，不在同一個數量級
想必第一個問題，大部分使用bcm網卡，rhel 5.3以後得機器都會遇到這種情況，網上的資料比較的多，我也不多啰嗦了，直接升級網卡驅動就可以解決了。第二，三，四其實是同一個問題都是由於網卡中斷過多，cpu處理不過來(准確的說，cpu分配不均衡，導致只有一個cpu處理，處理不過來)，引起丟包，那麼為什麼兩個網卡丟包的數量級不一樣呢，下面從原理上進行解釋，既然是做nat多出口，那麼就有大量的路由信息，是一個網路應用，當一個數據包請求nat時，數據包先被網卡驅動的數據接收，網卡收到數據時，觸發中斷。在中斷執行常式中，把skb掛入輸入隊列，並觸發軟中斷。稍後的某個時刻，當軟中斷執行時，再從該隊列中把skb取下來，投遞給上層協議。
如果在這個過程當中cpu沒有及時處理完這個隊列導致網卡的buffer滿了，網卡將直接丟棄該數據包。這里牽涉到2個隊列，一個是tx，一個是rx，它的隊列的大小默認都是255，可以通過ethtool -g eth0(你指定的網卡)，為了防止丟包，當時我通過ethtool -G eth0 rx xxx 把它調大了，但是調大以後，還是杯水車薪啊，通過ethtool -S eth0 |grep rx_fw_discards,發現數值還是不停的在增長，也就是說還在不停的丟包，cpu處理不過來，這時候找到網上有人在利用lvs時也遇到這個問題，cpu軟中斷分配不均衡，只有一個cpu處理軟中斷的問題，網上的資料五花八門，有建議使用修改設備中斷方式。即通過修改設置中斷/proc/irq/${網卡中斷號}/smp_affinit這時候，我也修改過，沒有什麼實質的效果，
從官方的bug報告，https://bugzilla.redhat.com/show_bug.cgi?id=520888，其中提到rhel5.6已經修復了這個bug，這其中也提到目前我們的版本可以升級內核到kernel-2.6.18-194.3.1.el5可以解決這個問題。
紅帽子官方修復報告中的說明如下：http://rhn.redhat.com/errata/RHSA-2010-0398.html，我們升級了這個內核算是解決單核處理軟中斷的問題，升級後各個cpu已經能夠平均的分配這個軟中斷，也不丟包了，那麼為什麼cpu處理不過來這個軟中斷呢，數據量並不是特別的大啊，上層應用接到這個數據包後，通過路由協議，找到某個出口給nat出去，找nat出口是需要查找路由表，查詢路由表是一件很耗時的工作，而每一個不同源地址，不同目的地址的數據包都得重新查找一次路由表，導致cpu處理不過來，為了提高路由查詢的效率。Linux內核引用了路由緩存，用於減少對路由表的查詢。Linux的路由緩存是被設計來與協議無關的獨立子系統，查看路由緩存可以通過命令route -Cn,由於路由緩存當中是採用hash演算法進行才找，它的查找速度非常之快，既然是cache就有超時這一概念。系統默認為10分鍾，可以通過這個文件進行查看和修改/proc/sys/net/ipv4/route/secret_interval。而當路由緩存當中未找到或者已經超時的路由信息才開始查找路由表，查詢到的結果保存在路由緩存中。如果路由表越大，那麼查詢的時間就越長，一個新的連接進來後或者是老連接cache超時後，佔用大量的cpu查詢時間，導致cpu周期性的軟中斷出現100%，而兩個網卡丟包的情況來看不均衡也是因為用戶的數據包是經過其中一個網卡進來後查詢路由表耗時過長，cpu處理不過來，導致那塊網卡的隊列滿了，丟包嚴重。當然在路由表變動不大的情況下可以加大cache的時間，修改上述內容後，從我監測的情況來看，扛流量能力得到了大大的提升。

Ⅲ 如何使用 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 ，感興趣的同學可以去試試。

Ⅳ tx鏈怎麼發幣

1、首先打開以太坊官網下載一個錢包，下載完成後解壓到本地打開這個文件度條是正在同步區塊鏈。
2、其次同步完區塊鏈數據後，點擊LAUNCH APPLICPTION打開錢包創建一個ETH賬戶往裡面充0.05個ETH就可以了。
3、然後創建一個合約然後在下圖紅圈圈起來的地方把原有的代碼刪除掉顯示新創建的貨幣，確認完畢，再進入CONTRACTS（合約）頁面，將看到剛才創建的代幣進入SEND（發送）頁面。
4、最後在右上角的紅色方框中輸入收款者的賬戶地址。在AMOUT中填寫發送的數量，在右邊的紅色方框中選擇要發送的貨幣。

Ⅳ ETH轉賬的2種方式的對比

web3j支持使用以太坊錢包文件（推薦）和乙太網客戶端管理命令來發起一筆交易。當你創建了一個擁有以太幣的賬戶後，你可以通過以下兩種交易機制，和以太坊網路（私網/公網）交易：

這里主要講一下 線下簽名交易（Offline transaction signing） 。線下簽名交易允許你使用web3j提供的錢包賬戶發起交易，你完全控制自己的私鑰，交易發送到網路上的其它節點並廣播。

線下簽名交易使用 RawTransaction 對象來完成，一共有如下幾步：

1、通過私鑰或密碼+錢包文件（keystore）來載入轉賬憑證Credentials
2、獲取發起轉賬賬戶的nonce 值，也就是第幾筆交易
3、創建 RawTransaction交易 對象
4、簽名 RawTransaction 對象，也就是對交易做簽名
5、發送交易（ RawTransaction 對象）給節點處理。
6、獲取交易哈希值TxHash

以太坊實戰-再談nonce使用陷阱： https://blog.csdn.net/wo541075754/article/details/79054937

此外，還有一種簡單的轉賬方式

這種方式，不需要自己管理nonce。

這2種方式都是離線交易，先組裝交易，然後發送到鏈上。

參考：
https://docs.web3j.io/getting_started.html#transactions
https://www.jianshu.com/p/6650d2a3aea9

Ⅵ 對區塊鏈游戲是什麼有價值嗎

區塊鏈游戲是什麼？

目前對於區塊鏈游戲的定義很多，比較公認的一個定義是的把核心數據寫入區塊鏈、基於鏈上數據作為隨機數來源。比如之前的游戲中的貨幣是由游戲運營商決定，但是由於區塊鏈的去中心化特點，貨幣之間的交易都是透明，並且交易數據都是同步到每一個玩家身上，那麼這樣一來，貨幣總量不變的情況下， 游戲獲得貨幣會更具價值。

區塊鏈能給游戲帶來什麼價值？

游戲資產的所有權和流通性

在區塊鏈上，玩家可以擁有游戲內的資產，而這些資產則有更廣泛意義上的流通性。傳統游戲中的積分、道具、武器、角色往往全部歸開發商所有，也因此中心化的開發商有更大的權力對這些資產進行大刀闊斧的改動，甚至隨意處置。游戲內的這些資產往往也只能局限於這一個游戲內部進行流通，出了游戲之外，似乎毫無復用的價值，也從技術層面很難被再次賦予應用場景。

在區塊鏈邏輯下，一旦游戲內的資產上鏈，這些積分、道具、武器、角色完全可以歸屬到玩家的區塊鏈地址下面，玩家對於這個地址以及其下面的資產擁有所有權。那麼我們可以設想若干個應用場景：

1.資產隨時隨地交易：大量的游戲是不具備道具交易功能的，當然這么設計很多時候的初衷是為了避免游戲內經濟機制的混亂、延長用戶游戲時間、增加開發商的收入。假設以上並不是開發者所擔心的問題，那麼「道具上鏈+移動錢包」可以實現兩個用戶隨時隨地在線上線下交易。你跟好友在吃飯時聊到最近的一個PC端游戲，打開手機錢包，看看彼此有什麼樣的武器裝備，完成一筆交易的體驗就像一次微信掃碼支付一樣簡單，晚上回到家，打開PC登錄游戲，交易完成的道具早已躺在了你的裝備欄里。

2.游戲資產復用：資產上鏈後因為掛在每一個玩家的地址下，對於開發商來說可以輕松的復用其他游戲的資產進行二次改造或者實現跨游戲復用。SpiderStore有一個游戲叫CryptoCuddles，基於加密貓的貓咪戰斗游戲，玩家用自己的以太坊地址登錄，游戲就會自動獲取到該地址下所有的加密貓咪，角色來自於加密貓，只有戰斗邏輯來自於CryptoCuddles本身。

3.新的用戶獲取方式：傳統游戲下，新的游戲往往需要重新獲取用戶，或者用老游戲給新游戲導流。區塊鏈可以打破這種方式，降低獲客成本，比如上述的CryptoCuddles，所有加密貓的用戶都是潛在可以直接轉換過來的游戲玩家。如果直接復用資產涉及到IP問題，開發商也可以這樣設計，只要在加密貓擁有貓咪的用戶，可以直接在這個游戲中直接獲取一定的獎勵，可以是角色、寶箱、道具等等，驗證方式只需要用地址登錄讀取一下鏈上數據即可。

這樣一來，一款新游戲上線完全可以借用現有爆款游戲的用戶引流，這個玩法其實不就是分叉幣發糖果、新代幣空投的套路么？利用ETH或者EOS這類持幣人數最大的幣種，給持幣人1：1空投自己的代幣，從而非常低成本獲取用戶。

SpiderStore目前擁有2000多個游戲DApp下，累計幾十萬個玩過以太坊游戲的用戶信息，如果新的一款游戲需要推廣，最簡單的就是給這些地址空投游戲資產，這可比傳統的廣告投放精準多。

Ⅶ 為什麼ETH挖礦需要用這么大的顯存

1、挖礦主要是使用高端3G顯存以上顯卡來挖礦。顯卡通常搭載有4GB以上的物理顯存，在大吞吐量計算時有很大的作用。
2、其中顯卡決定挖礦的速度，主板、電源在很大程度上決定了礦機運行的穩定程度。

Ⅷ Quorum介紹

Quorum和以太坊的主要區別:

Quorum 的主要組件：

1,用其自己實現的基於投票機制的共識方式 來代替原來的 「Proof of work」 。
2,在原來無限制的P2P傳輸方式上增加了許可權功能。使得P2P傳輸只能在互相允許的節點間傳輸。
3, 修改區塊校驗邏輯使其能支持 private transaction。
4, Transaction 生成時支持 transaction 內容的替換。這個調整是為了能支持聯盟中的私有交易。

Constellation 模塊的主要職責是支持 private transaction。Constellation 由兩部分組成：Transaction Manager 和 Enclave。Transaction Manager 用來管理和傳遞私有消息，Enclave 用來對私有消息的加解密。

在私有交易中，Transaction Manager 會存儲私有交易的內容，並且會將這條私有交易內容與其他相關的 Transaction Manager 進行交互。同時它也會利用 Enclave 來加密或解密其收到的私有交易。

為了能更有效率的處理消息的加密與解密，Quorum 將這個功能單獨拉出並命名為 Enclave 模塊。Enclave 和 Transaction Manager 是一對一的關系。

在 Quorum 中有兩種交易類型，」Public Transaction」 和 「Privat Transaction」。在實際的交易中，這兩種類型都採用了以太坊的 Transaction 模型，但是又做了部分修改。Quorum 在原有的以太坊 tx 模型基礎上添加了一個新的 「privateFor」 欄位。同時，針對一個 tx 類型的對象添加了一個新的方法 「IsPrivate」。用 「IsPrivate」 方法來判斷 Transaction是 public 還是 private，用 「privateFor」 來記錄 事務只有誰能查看。

Public Transaction 的機理和以太坊一致。Transaction中的交易內容能被鏈上的所有人訪問到。

Private Transaction 雖然被叫做 「Private」，但是在全網上也會出現與其相關的交易。只不過交易的明細只有與此交易有關系的成員才能訪問到。在全網上看到的交易內容是一段hash值，當你是交易的相關人員時，你就能利用這個hash值，然後通過 Transaction Manager 和 Enclave 來獲得這筆交易的正確內容。

Public Transaction的處理流程和以太坊的Transaction流程一致。Transaction 廣播全網後，被礦工打包到區塊中。節點收到區塊並校驗區塊中的 事務 信息。然後根據 Transaction信息更新本地的區塊

Private Transaction也會將 Transaction 廣播至全網。但是它的 Transaction payload已經從原來的真實內容替換為一個hash值。這個hash值是由Transaction Manager提供的。

有兩個共識機制：QuorumChain Consensus 和 Raft-Based Consensus。
在 Quorum 1.2 之前的 Release 版本都採用了 QuorumChain。
從 2.0 版本開始，Quorum 廢棄了 QuorumChain 轉而只支持 Raft-based Consensus。

QuorumChain Consensus 是一個基於投票的共識演算法。其主要特點有：

相比較以太坊的POW，Raft-based 提供了更快更高效的區塊生成方式。相比 QuorumChain，Raft-based 不會產生空的區塊，而且在區塊的生成上比前者更有效率。

要想了解Raft-based Consensus，必須先了解Raft演算法

Raft演算法
Raft是一種一致性演算法，是為了確保容錯性，也就是即使系統中有一兩個伺服器當機，也不會影響其處理過程。這就意味著只要超過半數的大多數伺服器達成一致就可以了，假設有N台伺服器，N/2 +1 就超過半數，代表大多數了。
Raft的工作模式：
raft的工作模式是一個Leader和多個Follower模式，即我們通常說的領導者-追隨者模式。除了這兩種身份，還有Candidate身份。下面是身份的轉化示意圖

1，leader的選舉過程
raft初始狀態時所有server都處於Follower狀態，並且隨機睡眠一段時間，這個時間在0~1000ms之間。最先醒來的server A進入Candidate狀態，Candidate狀態的server A有權利發起投票，向其它所有server發出投票請求，請求其它server給它投票成為Leader。
2，Leader產生數據並同步給Follower
Leader產生數據，並向其它Follower節點發送數據添加請求。其它Follower收到數據添加請求後，判斷該append請求滿足接收條件（接收條件在後面安全保證問題3給出），如果滿足條件就將其添加到本地，並給Leader發送添加成功的response。Leader在收到大多數Follower添加成功的response後。提交後的log日誌就意味著已經被raft系統接受，並能應用到狀態機中了。

Leader具有絕對的數據產生權利，其它Follower上存在數據不全或者與Leader數據不一致的情況時，一切都以Leader上的數據為主，最終所有server上的日誌都會復製成與Leader一致的狀態。

Raft的動態演示： http://thesecretlivesofdata.com/raft/

安全性保證，對於異常情況下Raft如何處理：

1，Leader選舉過程中，如果有兩個FollowerA和B同時醒來並發出投票請求怎麼辦？
在一次選舉過程中，一個Follower只能投一票，這就保證了FollowerA和B不可能同時得到大多數（一半以上）的投票。如果A或者B中其一幸運地得到了大多數投票，就能順利地成為Leader，Raft系統正常運行下去。但是A和B可能剛好都得到一半的投票，兩者都成為不了Leader。這時A和B繼續保持Candidate狀態，並且隨機睡眠一段時間，等待進入到下一個選舉周期。由於所有Follower都是隨機選擇睡眠時間，所以連續出現多個server競選的概率很低。
2，Leader掛了後，如何選舉出新的Leader？
Leader在正常運行時候，會周期性的向Follower節點發送數據的同步請求，同時也是起到一個心跳作用。Follower節點如果在一段時間之內（一般是2000ms左右）沒有收到數據同步請求，則認為Leader已經死了，於是進入到Candidate狀態，開始發起投票競選新的Leader，每個新的Leader產生後就是一個新的任期，每個任期都對應一個唯一的任期號term。這個term是單調遞增的，用來唯一標識一個Leader的任期。投票開始時，Candidate將自己的term加1，並在投票請求中帶上term；Follower只會接受任期號term比自己大的request_vote請求，並為之投票。 這條規則保證了只有最新的Candidate才有可能成為Leader。

3，Follower的數據的生效時間
Follower在收到一條添加數據請求後，是否立即保存並將其應用到狀態機中去？如果不是立即應用，那麼由什麼來決定該條日誌生效的時間？
首先會檢查這條數據同步請求的來源信息是否與本地保存的leader信息符合，包括leaderId和任期號term。檢查合法後就將日誌保存到本地中，並給Leader回復添加log成功，但是不會立即將其應用到本地狀態機。Leader收到大部分Follower添加log成功的回復後，就正式將這條日誌commit提交。Leader在隨後發出的心跳append_entires中會帶上已經提交日誌索引。Follower收到Leader發出的心跳append_entries後，就可以確認剛才的log已經被commit(提交)了，這個時候Follower才會把日誌應用到本地狀態機。下表即是append_entries請求的內容，其中leaderCommit即是Leader已經確認提交的最大日誌索引。Follower在收到Leader發出的append_entries後即可以通過leaderCommit欄位決定哪些日誌可以應用到狀態機。

4，向raft系統中添加新機器時，由於配置信息不可能在各個系統上同時達到同步狀態，總會有某些server先得到新機器的信息，有些server後得到新機器的信息。比如在raft系統中有三個server，在某個時間段中新增加了server4和server5這兩台機器。只有server3率先感知到了這兩台機器的添加。這個時候如果進行選舉，就有可能出現兩個Leader選舉成功。因為server3認為有3台server給它投了票，它就是Leader，而server1認為只要有2台server給它投票就是Leader了。raft怎麼解決這個問題呢？

產生這個問題的根本原因是，raft系統中有一部分機器使用了舊的配置，如server1和server2，有一部分使用新的配置，如server3。解決這個問題的方法是添加一個中間配置(Cold, Cnew)，這個中間配置的內容是舊的配置表Cold和新的配置Cnew。這個時候server3收到添加機器的消息後，不是直接使用新的配置Cnew，而是使用(Cold, Cnew)來做決策。比如說server3在競選Leader的時候，不僅需要得到Cold中的大部分投票，還要得到Cnew中的大部分投票才能成為Leader。這樣就保證了server1和server2在使用Cold配置的情況下，還是只可能產生一個Leader。當所有server都獲得了添加機器的消息後，再統一切換到Cnew。raft實現中，將Cold，(Cold,Cnew)以及Cnew都當成一條普通的日誌。配置更改信息發送Leader後，由Leader先添加一條 (Cold, Cnew)日誌，並同步給其它Follower。當這條日誌(Cold, Cnew)提交後，再添加一條Cnew日誌同步給其它Follower，通過Cnew日誌將所有Follower的配置切換到最新。

Raft演算法和以太坊結合
所以為了連接以太坊節點和 Raft 共識，Quorum 採用了網路節點和 Raft 節點一對一的方式來實現 Raft-based 共識

一個Transaction完整流程
1，客戶端發起一筆 Transaction並通過 RPC 來呼叫節點。
2，節點通過以太坊的 P2P 協議將節點廣播給網路。
3，當前的 Raft leader 對應的以太坊節點收到了 Transaction後將它打包成區塊。
區塊被 編碼後傳遞給對應的 Raft leader。
leader 收到區塊後通過 Raft 演算法將區塊傳遞給 follower。這包括如下步驟：
3.1，leader 發送 AppendEntries 指令給 follower。
3.2，follower 收到這個包含區塊信息的指令後，返回確認回執給 leader。
3.3，leader 收到不少於指定數量的確認回執後，發送確認 append 的指令給 follower。
3.4，follower 收到確認 append 的指令後將區塊信息記錄到本地的 Raft log 上。
3.5，Raft 節點將區塊傳遞給對應的 Quorum 節點。Quorum 節點校驗區塊的合法性，如果合法則記錄到本地鏈上。

參考鏈接： http://blog.csdn.net/about_blockchain/article/details/78684901

Ⅸ 011：Ethash演算法|《ETH原理與智能合約開發》筆記

待字閨中開發了一門區塊鏈方面的課程：《深入淺出ETH原理與智能合約開發》，馬良老師講授。此文集記錄我的學習筆記。

課程共8節課。其中，前四課講ETH原理，後四課講智能合約。
第四課分為三部分：

這篇文章是第四課第一部分的學習筆記：Ethash演算法。

這節課介紹的是以太坊非常核心的挖礦演算法。

在介紹Ethash演算法之前，先講一些背景知識。其實區塊鏈技術主要是解決一個共識的問題，而共識是一個層次很豐富的概念，這里把范疇縮小，只討論區塊鏈中的共識。

什麼是共識？

在區塊鏈中，共識是指哪個節點有記賬權。網路中有多個節點，理論上都有記賬權，首先面臨的問題就是，到底誰來記帳。另一個問題，交易一定是有順序的，即誰在前，前在後。這樣可以解決雙花問題。區塊鏈中的共識機制就是解決這兩個問題，誰記帳和交易的順序。

什麼是工作量證明演算法

為了決定眾多節點中誰來記帳，可以有多種方案。其中，工作量證明就讓節點去算一個哈希值，滿足難度目標值的勝出。這個過程只能通過枚舉計算，誰算的快，誰獲勝的概率大。收益跟節點的工作量有關，這就是工作量證明演算法。

為什麼要引入工作量證明演算法？

Hash Cash 由Adam Back 在1997年發表，中本聰首次在比特幣中應用來解決共識問題。

它最初用來解決垃圾郵件問題。

其主要設計思想是通過暴力搜索，找到一種Block頭部組合（通過調整nonce）使得嵌套的SHA256單向散列值輸出小於一個特定的值（Target）。

這個演算法是計算密集型演算法，一開始從CPU挖礦，轉而為GPU，轉而為FPGA，轉而為ASIC，從而使得算力變得非常集中。

算力集中就會帶來一個問題，若有一個礦池的算力達到51%，則它就會有作惡的風險。這是比特幣等使用工作量證明演算法的系統的弊端。而以太坊則吸取了這個教訓，進行了一些改進，誕生了Ethash演算法。

Ethash演算法吸取了比特幣的教訓，專門設計了非常不利用計算的模型，它採用了I/O密集的模型，I/O慢，計算再快也沒用。這樣，對專用集成電路則不是那麼有效。

該演算法對GPU友好。一是考慮如果只支持CPU，擔心易被木馬攻擊；二是現在的顯存都很大。

輕型客戶端的演算法不適於挖礦，易於驗證；快速啟動

演算法中，主要依賴於Keccake256 。

數據源除了傳統的Block頭部，還引入了隨機數陣列DAG（有向非循環圖）（Vitalik提出）

種子值很小。根據種子值生成緩存值，緩存層的初始值為16M，每個世代增加128K。

在緩存層之下是礦工使用的數據值，數據層的初始值是1G，每個世代增加8M。整個數據層的大小是128Bytes的素數倍。

框架主要分為兩個部分，一是DAG的生成，二是用Hashimoto來計算最終的結果。

DAG分為三個層次，種子層，緩存層，數據層。三個層次是逐漸增大的。

種子層很小，依賴上個世代的種子層。

緩存層的第一個數據是根據種子層生成的，後面的根據前面的一個來生成，它是一個串列化的過程。其初始大小是16M，每個世代增加128K。每個元素64位元組。

數據層就是要用到的數據，其初始大小1G，現在約2個G，每個元素128位元組。數據層的元素依賴緩存層的256個元素。

整個流程是內存密集型。

首先是頭部信息和隨機數結合在一起，做一個Keccak運算，獲得初始的單向散列值Mix[0]，128位元組。然後，通過另外一個函數，映射到DAG上，獲取一個值，再與Mix[0]混合得到Mix[1]，如此循環64次，得到Mix[64]，128位元組。

接下來經過後處理過程，得到 mix final 值，32位元組。（這個值在前面兩個小節《 009：GHOST協議 》、《 010：搭建測試網路 》都出現過）

再經過計算，得出結果。把它和目標值相比較，小於則挖礦成功。

難度值大，目標值小，就越難（前面需要的 0 越多）。

這個過程也是挖礦難，驗證容易。

為防止礦機，mix function函數也有更新過。

難度公式見課件截圖。

根據上一個區塊的難度，來推算下一個。

從公式看出，難度由三部分組成，首先是上一區塊的難度，然後是線性部分，最後是非線性部分。

非線性部分也叫難度炸彈，在過了一個特定的時間節點後，難度是指數上升。如此設計，其背後的目的是，在以太坊的項目周期中，在大都會版本後的下一個版本中，要轉換共識，由POW變為POW、POS混合型的協議。基金會的意思可能是使得挖礦變得沒意思。

難度曲線圖顯示，2017年10月，難度有一個大的下降，獎勵也由5個變為3個。

本節主要介紹了Ethash演算法，不足之處，請批評指正。

Ⅹ 以太國際空間誰知道怎麼玩。EIS幣怎麼交易

現在我們大家都很關注關於以太坊方面的問題，那麼關於以太幣怎麼交易?我想我們大家應該會很想了解一些內容，那麼下面就讓我們小編在這里就來為大家好好的介紹一下很多內容關於以太幣怎麼交易?以太坊的交易最直觀解釋：從外部賬戶發送到區塊鏈上的另一個賬戶的消息和簽名的數據包。

包含如下內容：
發送者的簽名
接收的地址
轉移的數字貨幣數量等內容
以太坊上的交易都是需要支付費用，和比特幣以比特幣來支付一定的交易費用不同，以太坊上固定了這個環節，那麼這個間接理解是以太坊的一種安全防範錯誤，防止了大量的無意義的交易，保證一定的安全性，特別是智能合約的創建、執行、調用都需要消耗費用，那麼也保證了整個系統的穩定性，防止了一些鏈上無意義的惡意行為。
交易手續費
以太坊的核心是EVM，以太坊虛擬機，那麼在EVM中執行的位元組碼都是要支付費用。也就是經常看到的Gas、Gas limit、Gas Price這幾個概念。
Gas：字面理解就是汽油，以太坊和日常的汽車一樣需要Gas才能運行。Gas是一筆交易過程中計算消耗的基本單位。有一個列表可以直觀看到在以太坊中操作的Gas消耗量：
操作Gas消耗具體內容
step1執行周期的默認費用。
stop0終止操作是免費的。
suicide0智能合約賬戶的內部數據存儲空間，當合約賬戶調用suicide()方法時，該值將被置為null。
sha320加解密
sload20在固定的存儲器中去獲取
sstore100輸入到固定的存儲器中
balance20賬戶余額
create100創建合約
call20初始化一個只讀調用
memory1擴充內存額外支付的費用
txdata5交易過程中數據或者編碼的每一個位元組的消耗
transaction500交易費用
contract creation53000homestead中目前從21000調整到53000
所以有些公司或者個人覺得區塊鏈技術去中介化，不需要中心伺服器，這種開發模式是比較便宜的，但是事實上區塊鏈的開發不比之前的那些傳統軟體開發來的便宜。
Gas Price：字面理解汽油價格，這個就像你去加油站，95#汽油今天是什麼價格。一個Gas Price就是單價，那麼你的交易費用=Gas*Gas Price，然後以以太幣來ether來支出。當然你覺得我不想支付費用，你可以設置Gas Price為0，但是選擇權在礦工手中，礦工有權選擇收納交易和收取費用，那麼最簡單的想想很難讓一個礦工去接收一個價格很低的交易吧。另外提一句，以太坊默認的Gas Price是1wei。
Gas Limit：字面理解就是Gas的限制，限制是必要的，沒有限制就沒有約束。這個Gas Limit是有兩個意思的。首先針對單個交易，那麼這個表示交易的發起者他願意支付最多是多少Gas，這個交易發起者在發起交易的時候需要設置好。還有一個是針對區塊的Gas Limit，一個單獨的區塊也有Gas的限制。
假設幾個場景來說明Gas的使用：
用戶設置Gas Limit，那麼在交易過程中，如果你的實際消耗的Gas used
用戶設置Gas Limit，那麼交易過程中，如果你的實際消耗的Gas used > Gas Limit，那麼礦工肯定發現你的Gas不足，這個交易就無法執行完成，這個之後會回滾到執行之前的狀態，這個時候礦工會收取Gas Price*Gas Limit。
區塊的Gas Limit，區塊中有一個Gas上限，收納的交易會出現不同的用戶指定的Gas Limit。那麼礦工就會根據區塊限制的Gas Limit來選擇，「合理」選擇打包交易。
具體交易
以太坊上交易可以是簡單的以太幣的轉移，同時也可以是智能合約的代碼消息。列個表格看下交易的具體內容：
代碼內容
from交易發起者的地址、不能為空，源頭都沒有不合理。
to交易接收者的地址(這個可以為空，空的時候就表示是一個合約的創建)
value轉移的以太幣數量
data數據欄位。這個欄位存在的時候表示的是，交易是一個創建或者是一個調用智能合約的交易
Gas Limit字面理解就是Gas的限制，限制是必要的，沒有限制就沒有約束。這個Gas Limit是有兩個意思的。首先針對單個交易，那麼這個表示交易的發起者他願意支付最多是多少Gas，這個交易發起者在發起交易的時候需要設置好。還有一個是針對區塊的Gas Limit，一個單獨的區塊也有Gas的限制。
Gas Price一個Gas Price就是單價，那麼你的交易費用=Gas*Gas Price，然後以以太幣來ether來支出。以太坊默認的Gas Price是1wei。
nonce用於區別用戶發出交易的標識。
hash交易ID，是由上述的信息生成的一個hash值
r、s、v交易簽名的三部分，交易發起者的私鑰對hash簽名生成。
交易分三種類型
轉賬：簡單明了的以太坊上的以太幣的轉移，就和比特幣類似，A向B轉移一定數量的以太幣。這種交易包含：交易發起者、接收者、value的數量，其餘類似Gas Limit、hash、nonce都會默認生成。所以你會看到一段代碼：
web3.eth.sendTransaction({ from: "交易發起者地址", to：「交易接收者地址」, value: 數量});
智能合約創建：創建智能合約就是把智能合約部署到區塊鏈上，那麼這個時候to是一個空的欄位。data欄位則是初始化合約的代碼。所以看到代碼：
web3.eth.sendTransaction({ from: "交易發起者地址", data: "contract binary code"});
智能合約執行：合約創建部署在區塊鏈上，那麼執行就是會加上to欄位到要智能合約執行的地址，然後data欄位來指定調用的方法和參數的傳遞，所以看到代碼：
web3.eth.sendTransaction({ from: "交易發起者地址", to：「合約執行者地址」, data：「調用的方法和參數的傳遞」});
以上大致就是交易的類型。
交易的確認
和比特幣一樣，以太坊的交易需要後續區塊確認後，節點同步後、才能確認。簡單理解就是多挖出一些區塊來，通過驗證後這一筆交易才算確認，以太坊時常會出現擁堵的情況，所以有時候需要等待確認。
轉賬、合約交易流轉
首先交易發起者A發起一筆轉賬交易，那麼發送的格式如下：
代碼具體內容
from交易發起者的地址
to交易接收者的地址
value轉移的以太幣數量
GasGas的量
Gas PriceGas的單價
data發送給接收者的消息
nonce交易編號
節點驗證：以太坊網路中會有節點收到A發送出來的消息，那麼會去檢查這個消息格式時候有效，然後計算Gas Limit。這個時候回去驗證A的以太坊余額，如果余額不足，那麼就返回錯誤，不予處理。一旦A發送的消息通過了節點的驗證，那麼節點就會把這個交易放到交易存儲池中。並廣播到區塊鏈網路。
礦工驗證：那麼寫入區塊鏈必須要礦工打包，礦工在接收到A發出的交易，會和其他交易一塊打包，普通轉賬交易打包即可，那麼合約調用的交易則需要在礦工本地的EVM上去執行調用的合約代碼，代碼執行過程中檢查Gas的消耗。一旦Gas消耗完了，那麼就回滾，如果Gas足夠那麼返回多餘的Gas。並廣播到區塊鏈網路。
其餘節點：重復節點驗證步驟，然後合約也會在本地EVM上執行驗證。通過驗證後同步區塊鏈。
首先還是發起者A發起一個創建智能合約的交易請求。格式如下：
代碼具體內容
from交易發起者的地址
to0
value轉移的以太幣數量
GasGas的量
Gas PriceGas的單價
data合約代碼
nonce交易編號
節點驗證：
以太坊網路中會有節點收到A發送出來的消息，檢查交易是否有效，格式是否正確，驗證交易簽名。計算Gas，確定下發起者的地址，然後查詢A賬戶以太幣的余額。如果余額不足，那麼就返回錯誤，不予處理。一旦A發送的消息通過了節點的驗證，那麼節點就會把這個交易放到交易存儲池中。並廣播到區塊鏈網路。
礦工驗證：
礦工將交易打包，那麼會根據交易費用和合約代碼，來創建合約賬戶，在賬戶的空間中部署合約。這里說下合約地址(智能合約賬戶的地址是有發起者的地址和交易的隨機數作為輸入，然後通過加密演算法生成)。交易確認後會把智能合約的地址返回給A。且廣播到區塊鏈網路。
其餘節點：
重復節點驗證步驟，驗證區塊，在節點的內存池中更新A的智能合約交易，同步區塊鏈，且智能合約部署在自己本地的區塊鏈中。