㈠ 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
㈡ 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的工作流程做大致梳理和介紹
㈢ 區塊鏈｜主流企業區塊鏈的技術分析：以太坊，Fabric，Corda
自2018年起，企業區塊鏈技術穩步發展，政府和企業積極嘗試運用該技術解決交易難題。在身份和許可權許可方面，企業和監管部門有嚴格規定，促使他們更多選擇許可區塊鏈（私有鏈）而非無許可區塊鏈（公共區塊鏈）。目前，全球范圍內，Hyperledger Fabric、企業以太坊和R3 Corda成為各行業首選的許可鏈協議。這三個協議具有不同的起源和設計重點，已在企業和政府生產系統中廣泛應用。
作者參與了Fabric和Quorum（企業以太坊實現之一）的開發工作。本文旨在比較這三種廣泛使用的協議，而不評判哪個更好。以太坊、Fabric和Corda之間的主要差異如下：
起源和譜系：企業以太坊聯盟採用標准驅動方法，促進互操作，允許多個創新者根據企業需求開發獨立解決方案。Hyperledger Fabric由Linux基金會發布，主要考慮企業端應用。Corda最初是R3內部的一個閉源項目，後開源，旨在為金融業開發分布式賬本技術。
共識模型：所有區塊鏈系統都需要共識機制，確保所有節點對交易和排序有一致看法。以太坊採用「排序和執行」模型，而Fabric採用「執行-排序-驗證」模型，允許非確定性Chaincode。Corda的共識設計與Fabric相似，通過執行目標合約並簽署執行結果來協調交易處理。
多版本並發控制（MVCC）：Fabric借鑒了資料庫設計中的MVCC技術，跟蹤在執行智能合約時正被查看和更新的狀態值。Corda基於UTXO模型，確保每個輸入都是唯一的，避免雙花問題。
交易模型：以太坊採用「賬戶狀態」交易模型，Fabric和Corda則採用不同的交易模型。以太坊智能合約類似於帶有私鑰的用戶帳戶，而Fabric的Chaincode沒有身份概念。Corda交易基於UTXO模型，確保每個交易使用唯一的輸入。
隱私支持：企業以太坊和Fabric通過私有交易支持隱私，Corda基於所有交易都是「私有」的理念設計，交易僅發送給特定交易對手。
智能合約管理：以太坊的智能合約不可篡改，而Fabric和Corda的智能合約可升級。Corda合約通過其完全限定的類名和包含JAR的哈希值進行引用，實現代碼重用。
通證支持：以太坊、Fabric和Corda都支持基於通證的解決方案。以太坊社區已開發豐富通證合同設計，Corda具有內置資產類型，類似通證的模型。
運營治理：治理是協議運行時的過程和策略，確保聯盟成員適當參與決策過程。企業以太坊、Fabric和Corda都內置了許可管理，支持聯盟和通道級別的許可和治理。
總結：企業以太坊、Hyperledger Fabric和R3 Corda均已被行業領導者、政府和創新型初創公司採用。這三個協議都為運行真實業務的交易的生產系統提供支持。區塊鏈技術仍處於活躍增長階段，選擇一個協議可能不是最佳策略。區塊鏈協議層只是企業聯盟解決方案的基礎，還需要考慮許多其他問題。
㈣ Quorum介紹（一）：Quorum整體結構概述
一句話概括，就是企業級以太坊模型。與傳統的以太坊模型不同，Quorum既然是企業級應用，那麼准入門檻、共識處理以及交易的安全機制上一定與傳統的公鏈模型不同。稍後我們也將從以下幾個方面詳細介紹Quorum的結構模型和核心功能特色。
Quorum本身支持兩種交易狀態
兩種交易核心不同就是內容是否加密。為了區別兩種交易的類型，Quorum在每筆交易的簽名中設置了一個特殊的value值，當簽名中的value值為27或28時，表示這是一筆公開交易，如果是37或者38則是一筆私密交易。私密交易的內容會被加密，只有具有解密能力的節點才能獲得具體的交易內容。
所以最終每個節點會有兩套賬本：一個是所有人都一樣的公有賬本，另一個是自己本地存儲的私有賬本。
所以Quorum的賬本狀態改變機制 允許以下幾種情況的調用
s 表示交易發起者，(X) 表示私密， X表示公開
上述公式可以翻譯為：
Quorum 不允許以下兩種情況的調用
Quorum具體的狀態狀態校驗（世界狀態）可以調用RPC方法 eth_storageRoot(address[, blockNumber]) -> hash
Quorum核心分為兩大塊：Node節點和隱私管理。
Quorum節點本身是一個輕量版的Geth。沿用Geth可以發揮以太坊社區原有的研發優勢，因此Quorum會隨著Geth未來的版本更新而更新。
Quorum節點基於Geth做了一下改動：
Constellation和Tessera（以下簡稱C&T）是一種用Java和Haskell實現的安全傳輸信息模型，他們的作用就像是網路中的信息傳輸代理（MTA, Message Transfer Agent）所有消息的傳輸都通過會話信息秘鑰進行加密
C&T其實是一種多方參與網路中實現個人消息加密的常用組件，在許多應用中都很常見，並不是區塊鏈領域專有技術（筆者注，其實區塊鏈本身就是各種技術的大雜燴，我們很難專門找到一門技術，說它就是區塊鏈 ）。C&T主要包括兩個子模塊：
交易管理模塊主要負責交易的隱私，包括存儲私密交易數據、控制私密交易的訪問、與其他參與者的交易管理器進行私密交易載荷的交換。Transaction Manager 本身並不涉及任何私鑰和私鑰的使用，所有數字加密模塊的功能都由The Enclave來完成。
Transaction Manager屬於靜態/Restful模組，能夠非常容易的被載入。
分布式賬本協議通常都會涉及交易驗證、參與者授權、歷史信息存儲（通過hash鏈）等。為了在加密這一方面實現平行操作的性能擴展和，所有公私鑰生成、數據的加密/解密都由Enclave模塊完成。