Ⅰ 以太坊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:
一般的礦機與礦池通訊過程就如下所示：
Ⅱ Quorum介紹（二）：Quorum共識
我們知道，公共區塊鏈是一個開放的社區，任何人都能夠成為一個節點加入網路，在網路中計算，提交交易到鏈上等，因此公鏈是沒有信任基礎的，所以公鏈的共識第一要義就是證明交易的合法性和真實性，防止惡意成員的搗亂，效率不是第一要義。
與公鏈的環境不同，有準入門檻的企業鏈或者聯盟鏈鏈上的所有成員在加入時實際上是已經獲得了某些認可和許可的，因此企業鏈/聯盟鏈上的成員是有一定信任基礎的。在企業級鏈上我們沒有必要使用POW或者POS這種浪費算力或者低效的交易共識。
Quorum提供了多種共識供用戶採用：
在講Raft前，有必要提一下Paxos演算法，Paxos演算法是Leslie Lamport於1990年提出的基於消息傳遞的一致性演算法。然而，由於演算法難以理解，剛開始並沒有得到很多人的重視。其後，作者在八年後，也就是1998年在ACM上正式發表，然而由於演算法難以理解還是沒有得到重視。而作者之後用更容易接受的方法重新發表了一篇論文《Paxos Made Simple》。
可見，Paxos演算法是有多難理解，即便現在放到很多高校，依然很多學生、教授都反饋Paxos演算法難以理解。同時，Paxos演算法在實際應用實現的時候也是比較困難的。這也是為什麼會有後來Raft演算法的提出。
Raft是實現分布式共識的一種演算法，主要用來管理日誌復制的一致性。它和Paxos的功能是一樣，但是相比於Paxos，Raft演算法更容易理解、也更容易應用到實際的系統當中。而Raft演算法也是聯盟鏈採用比較多的共識演算法。
Raft一共有三種角色狀態：
每個節點上都有一個倒計時器 (Election Timeout)，時間隨機在 150ms 到 300ms 之間。有幾種情況會重設 Timeout：
在分布式系統中，「時間同步」是一個很大的難題，因為每個機器可能由於所處的地理位置、機器環境等因素會不同程度造成時鍾不一致，但是為了識別「過期信息」，時間信息必不可少。
Raft演算法中就採用任期（Term）的概念，將時間切分為一個個的Term（同時每個節點自身也會本地維護currentTerm），可以認為是邏輯上的時間，如下圖。
每一任期的開始都是一次領導人選舉，一個或多個候選人（Candidate）會嘗試成為領導（Leader）。如果一個人贏得選舉，就會在該任期（Term）內剩餘的時間擔任領導人。在某些情況下，選票可能會被評分，有可能沒有選出領導人（如t3），那麼，將會開始另一任期，並且立刻開始下一次選舉。Raft 演算法保證在給定的一個任期最少要有一個領導人。
特殊情況的處理
在以太坊中節點本身並沒有角色，因此在使用Raft共識時，我們稱leader節點為挖礦節點：
Raft共識機制本身保證了同一時間點最多隻有一個leader，因此用在以太坊模型下也只會有一個出塊者，避免了同時出塊或者算力浪費的情況。
在單筆交易(transaction)層級Quorum依然沿用了Ethereum的p2p傳輸機制，只有在塊(block)層級才會使用Raft的傳輸機制。
其中需要注意到一點，在以太坊中一個節點收到塊以後就會立刻記賬，而在Quorum模型中，一個塊的記錄必須遵從Raft協議，每個節點從leader處收到塊以後必須報告給leader確認收到以後，再由leader通知各個節點進行數據提交（記錄）
在Quorum模型中新塊的信息是很有可能和已有塊的header信息不符的，最容易發生這種情況的就是選舉人更替(挖礦節點更替)，具體描述如下：
假設有兩個節點，node1和node2，node1是現有的leader，現有鏈的最新區塊是0xbeda，它的父區塊是0xacaa
對塊「Extends」或者「No-op」的標記是在更上層完成的，並不由raft本身log記錄機制實現。因為在raft內部，信息並不分為有效或無效，只有在區塊鏈層面才會有有效區塊和無效區塊的含義。
需要注意的是，Quorum的這種記賬機制和本身Ethereum的LVC（最長鏈機制）是完全不一樣的
Quorum的出塊頻率默認是50ms一個塊，可以通過 --raftblocktime 參數進行設置
投機性出塊並不是以太坊Raft共識嚴格必須的核心機制之一，但是是提高出塊效率的有效方式。
一個塊從產生到實際被記錄賬本，走完整個raft流程實際上是需要耗費一定時間的。如果我們在上一個塊被計入賬本之後才開始產生下一個塊，那麼一筆交易想要成功被記錄需要耗費較多的時間。
而在投機性(speculative minting)出塊中，我們允許一個新塊在它的父塊被記錄之前就產生。依次類推，在一段時間內，實際上會產生「投機鏈（speculative chain）」，在祖先塊沒有被記錄進賬本之前，一個一個新塊已經依據先後關系組成了一條臨時鏈片段，等待被記錄。
對於已經被記錄進投機塊的交易，我們會在交易池中標記為「proposed transaction」
在之前我們說過，raft機制中是存在兩個挖礦節點比賽出塊和記賬的可能的，因此，一條 speculative chain 中間的某一個塊很有可能不會被記錄到賬本中。在這種情況下我們也會把交易池中的交易狀態修改回來。( InvalidRaftOrdering event)
目前，Quorum並沒有對speculative chain的長度做限制，但在它的未來規劃中有講這一點作為一個性能優化項加入開發進程，最後能夠讓一個挖礦節點即使在raft共識層沒有連接上，它也可以離線一直出塊，產生自己的speculative chain。
一條speculative chain有以下幾個部分構成：
在塊傳輸上我們使用etcd Raft默認的http傳輸，當然使用Ethereum的p2p傳輸也是可以的，但是Quorum團隊在測試階段發現，高負載的狀態下，ETH p2p的性能沒有raft p2p性能好。
Quorum使用50400埠作為Raft 傳輸層的默認監聽埠，也可以通過 --raftport 參數自行設置。
一個集群默認的最大節點個數是25，可以通過 --maxpeers N 來設置，N是你的最大節點個數。
Quorum的IBFT其實就是PBFT，只不過摩根大通把它自己實現的PBFT叫做IBFT，所以IBFT的基本原理與PBFT是一樣的，所不同的是,IBFT中把出塊和共識的三階段結合在了一起。
Istanbul BFT修改自PBFT演算法，包括三個階段： PRE-PREPARE 、 PREPARE 以及 COMMIT 。在 N 個節點的網路中，這個演算法可以最多容忍 F 個出錯節點，其中 N=3F+1 。
Istanbul BFT演算法中的區塊是確定的，意味著鏈沒有分叉並且合法的區塊一定是在鏈中。為了防止一個惡意節點生成不同的鏈，在把區塊插入進鏈 之前 ，每一個validator必須把 2F + 1 個 COMMIT 簽名放進區塊頭的 extraData 欄位。因此，區塊是可以自我驗證的（因為有簽名）並且輕客戶端也支持。
然而動態的 extraData 也會造成區塊的hash計算問題。因為一個區塊可以被不同的validator驗證，所以會有不同的簽名，所以同一個區塊會有不同的hash。解決的方案是，計算區塊hash的時候把 COMMIT 簽名排除在外。因此我們任然可以在保證block hash一致性的同時進行共識驗證。
由於Ethereum POA共識在網上已經有大量介紹，筆者這里就不多做詳細介紹，只對重要特點和POA的工作流程做大致梳理和介紹