Quorum工作原理

1. 概述

Quorum是摩根大通推出的聯盟鏈，它是一種基於以太坊的分佈式賬本協議，可以稱之爲企業以太坊。
Quorum是以太坊go-ethereum的分支，並對go-ethereum進行了修改。

相比以太坊主要增強的功能：

• 隱私 -私有交易和私有智能合約
• 新的共識機制-非POW/POS,基於raft的共識和Istanbul BFT
• 網絡、節點權限許可
• 更高的性能

2. 邏輯架構

主要的組件:

• Quorum Node(對標準的Geth客戶端做了修改)
• privacy Manager(實現有Constellation和Tessera)
  • Transaction Manager
  • Enclave

2.1 Quorum Node

Quorum Node，又名Quorum Client，是一個胖客戶端，其隱私交易功能操作依賴用於加密和解密私有交易playload的Transaction Manager客戶端。Quorum客戶端及其依賴項（Transaction Manager, Peers, and Enclave）都使用傳統的TCP / UDP傳輸層進行通信。
Quorum節點本身是一個輕量版的Geth。沿用Geth可以發揮以太坊社區原有的研發優勢，因此Quorum會隨着Geth未來的版本更新而更新。
Quorum節點基於Geth做了以下改動：

• 使用Raft或Istanbul BFT共識算法而不是使用工作量證明來達成共識。
• P2P層已被修改爲僅允許與許可節點之間的連接。
• 塊的產生邏輯不再是“global state root”決定，而是“global public state root”狀態決定
• 塊的驗證邏輯已修改爲將塊頭中的“global state root”替換爲“global public state root”
• State Patricia trie 已經被分成了兩個: public state trie 和 private state trie
• 塊驗證邏輯支持“隱私交易”
• 交易創建已被修改，允許將交易數據替換爲加密的哈希值，以便在需要時保留私有數據
• 保留了gas的概念，但是交易不會產生gas費用

2.2 Constellation（星座）

Constellation是基於Haskell開發，用於對Quorum隱私交易的加密，解密和分發。
Constellation是一個自我管理的peer-to-peer系統：

• 託管多個NaCl（Curve25519）公鑰/私鑰對。
• 與最少一臺主機同步後，自動發現網絡上的其他節點。
• 將映射到收件人主機的公共密鑰目錄與網絡上的其他節點同步。
• 暴露一個公共API，該API允許其他節點將加密的字節串發送到您的節點，並進行同步，檢索有關您節點知道的節點的信息。
• 暴露一個私有API，該私有API：
  • 允許您向一個或多個公共密鑰發送bytestring，並返回內容可尋址的標識符。將其傳輸到正確的接收者節點（並且僅這些節點）之前，將透明且有效地（以對稱加密速度）對該bytestring進行加密。標識符是每個接收者節點接收到的加密playload的哈希摘要。每個接收者節點還收到一個針對其公共密鑰加密的小Blob，其中包含用於加密playload的主密鑰。
  • 允許您基於標識符接收解密的字節串。您的節點已發送或接收的playload可以通過這種方式解密和檢索。
  • 公開刪除，重新同步和其他管理功能的方法。
• 支持許多存儲後端，包括LevelDB，BerkeleyDB，SQLite和適用於任何FUSE適配器（例如，適用於AWS S3的的Directory / Maildir樣式的文件存儲。
• 支持TLS通信
• 支持IP白名單。

2.3 Tessera（特賽拉）

Tessera是基於Java開發，用於對Quorum隱私交易的加密，解密和分發。

• 生成並維護許多私鑰/公鑰對
• 通過連接至最少一個其他節點，自我管理並發現網絡中的所有節點（即它們的公鑰）
• 提供私有和公用API接口：
  • 私有API-用於與Quorum通信
  • 公共API-用於Tessera peer節點之間的通信
• 支持TLS通信
• 支持IP白名單
• 支持JDBC客戶端的SQL DB

2.4 Transaction Manager

存儲隱私交易，並且會將這條隱私交易內容與其他參與方相關的 Transaction Manager 進行交互，但無權訪問任何敏感的私鑰，同時它也會調用 Enclave 來加密或解密其收到的隱私交易。Transaction Manager是無狀態的，並且可以輕鬆實現負載均衡。

2.5 Enclave

公私鑰生成、隱私交易playload的加密與解密，enclave與Transaction Manager攜手合作，通過以隔離方式管理加密/解密來增強隱私。通過並行化某些加密來提高性能。

3. 交易（事務）處理

Quorum的主要功能之一是交易隱私，Quorum並沒有引入新的交易類型，而是擴展了以太坊交易模型，包括一個可選privateFor參數和交易類型具有IsPrivate新方法，依此識別交易是私有還是公開。

3.1 公開交易

同一Quorum網絡的所有參與者可見的那些事務，和以太坊交易一致

3.2 隱私交易

• 隱私交易是指那些僅對privateFor在交易參數中指定了公鑰的網絡參與者可見，privateFor可以使用逗號分隔的列表中的多個地址。
• 當Quorum節點遇到具有非空privateFor值的事務時，它將Transaction Signature 中的V的值設置爲0x25或0x26。

3.3 交易處理

• 公共交易是以標準的以太坊方式執行的，因此，如果將公共交易發送到持有合同代碼的賬戶，則每個參與者將執行相同的代碼，並且其底層StateDB將相應更新。
• 隱私交易不會按標準的以太坊執行：Quorum節點將交易傳播到網絡的其餘部分之前，它將原始的Transaction Payload替換爲從Constellation/Tessera接收到的Transaction Payload的哈希值。參與交易的參與者將能夠通過其Constellation / Tessera實例將哈希值替換爲實際的Transaction Payload，而未參與交易的參與者將只能看到哈希值。
• 如果將隱私交易發送到持有合約代碼的帳戶，則那些不參與交易的參與者將最終跳過交易，因此不執行合約代碼。但是，參與交易的那些參與者將在調用EVM執行之前將哈希替換爲原始Transaction Payload，並且其StateDB將相應更新。如果沒有對geth客戶進行相應的更改，那麼這兩組參與者最終將擁有不同的StateDB，並且無法達成共識。因此，爲了支持合同狀態的這種分歧，Quorum將公共合約的狀態存儲在全局同步的Public State Trie中，並將隱私合約的狀態存儲在未全局全局同步的Private State Trie中

3.4 隱私交易流程（Tessera）

上面示例中展示了Quorum隱私交易的流程，這筆交易只有參與者A與參與者B知道，C並不知道：

1. Dapp將Tx發送到Party A的Quorum節點，節點收到Tx後 ，生成Transaction Payload並將privateFor的值設置爲爲A和B的公鑰（A是可選的）

2. Party A的Quorum節點將交易傳遞到其配對的Transaction Manager，要求其存儲Transaction Payload

3. Party A的Transaction Manager調用對其關聯的Enclave，以驗證sender並加密Payload

4. Party A的Enclave會檢查Party A的私鑰，並在驗證後執行交易轉換，詳細步驟如下：
   a.生成隨機主密鑰（RMK）和隨機數Nonce
   b.使用步驟a的隨機數Nonce和RMK加密Transaction Payload。
   c.遍歷交易接收方列表（在本例中爲Party A和Party B）。根據Party A的私鑰和接收者的公鑰生成對稱密鑰，生成另外一個隨機數。根據對稱密鑰和隨機數加密RMK，每個加密的RMK對於每個接收者都是唯一的，並且僅與加密的Payload一起與相應的接收者共享。每個加密RMK對每一個交易參與方是獨一無二的。
   d.返回a中的加密Payload和c中的所有加密RMKs給Transaction Manager

5. Party A的Transaction Manager計算加密的Payload的SHA3-512哈希值，然後將加密的Payload和加密的RMK、Hash存儲在數據庫中

6. Party A的Transaction Manager安全地（通過HTTPS）將加密的Payload和已使用共享密鑰加密的RMK從先前的步驟4.c（隨機數）轉移到Party B的Transaction Manager。Party B的Transaction Manager以Ack / Nack響應進行響應。請注意，如果Party A未收到Party B的響應/未收到應答，則交易將不會傳播到網絡。接受者必須存儲通信的Payload。

7. 一旦成功傳輸到Party B的Transaction Manager，Party A的Transaction Manager將哈希返回到Party A的Quorum節點，Quorum節點隨後用該哈希替換交易的原始Payload，並將交易簽名的V值更改爲37或38，37或38就是隱私交易的標識。其他節點查詢後發現 V 的值爲37或38時，就會認定其爲隱私交易。

8. 使用標準的以太坊P2P協議將交易傳播到網絡的其餘部分。

9. 創建一個包含交易AB的Block，並將其分發給網絡上的每一方。

10. 在處理該區塊時，所有各方都將嘗試處理該交易。每個Quorum節點將識別V爲37或38 的值，將交易標識爲需要解密其Payload的交易，並調用其本地Transaction Manager以確定它們是否持有事務（使用哈希作爲索引來查找）。

11. 由於Party C不持有該交易，它將收到一條NotARecipient消息並跳過該交易-它不會更新其private StateDB。Party A和Party B將在其本地Transaction Manager中查找哈希，並確定他們確實持有交易。然後，每個用戶都將調用其Enclave，向其傳入加密payload，加密的對稱祕鑰和交易簽名。

12. Enclave驗證簽名，然後使用Enclave中保留的方的私鑰解密對稱密鑰，使用現在公開的對稱密鑰解密Transaction Payload，然後將解密的Payload返回給Transaction Manager。

13. 然後，Party A和Party B的Transaction Manager將解密後的Payload發送到EVM，以執行合同代碼。此執行將僅更新Quorum節點的private StateDB中的狀態。注意：一旦執行了代碼，則將其丟棄，因此，如果不經過上述過程，將永遠無法讀取該代碼。

4. 共識

Quorum不需要在許可的網絡中使用POW / POS，而是提供了多個更適合於聯盟的共識機制：

• Raft-based Consensus：一種共識模型，可加快區塊時間，完成交易和按需創建區塊
• Istanbul BFT (Byzantine Fault Tolerance) Consensus：AMIS啓發的PBFT共識算法，具有立即完成交易的功能。
• Clique POA Consensus：與Go Ethereum捆綁在一起的默認POA共識算法。

4.1 Raft-based

Quorum有一個基於Raft的共識機制的實現（使用etcd的Raft實現），以替代以太坊的工作量證明。這對於不需要拜占庭式容錯的封閉社團/聯盟非常有用，並且有更快的出塊時間（以毫秒爲單位，而不是秒）和事務確定性（沒有分叉）。這種共識機制不會“不必要地”創建空塊，而有效地“按需”創建塊。
raft中處於正常運行狀態的節點可以是“leader”，“follower”或“learner”。整個集羣只有一個領導者，所有日誌條目都必須流經該領導者。也有“candidate”的概念，但僅在領導人選舉期間。
leader
- 產生塊並將塊發送給verifier和learner節點
- 在重選期間參加投票，如果未贏得多數選票，則可以成爲verifier
- 如果領導節點死亡，則網絡將觸發重新選舉。
- 可以添加/刪除verifier/learner，並將learner提升爲verifier
verifier
- 跟隨leader
- 使用learner生成的塊
- 連任期間參加投票，如果贏得多數票就可以成爲領導人
- 向leader發送確認
- 可以添加/刪除verifier/learner，並將learner提升爲verifier
learner
- 跟隨leader
- 使用leader生成的塊
- 連任期間不能參加投票
- 不能自己成爲verifier
- 需要由leader或verifier提升爲verifier
- 它無法添加verifier/learner，無法將將learner提升爲verifier
- 它不能刪除其他verifier/learner，但可以刪除自己
在以太坊中，沒有“leader”，“follower”或“learner”之類的東西。網絡中的任何節點都有可能挖掘一個新塊，這類似於這裏的leader。在基於Raft的共識中，我們在Raft和以太坊節點之間強加了一對一的對應關係：每個以太坊節點也是Raft節點，並且按照慣例，Raft集羣中的“leader”是唯一生成新區塊的以太坊節點。minter與以太坊礦工一樣負責將交易打包到一個區塊中，但不提供工作證明。

4.2 Istanbul BFT

Istanbul BFT共識是受Castro-Liskov 99 論文啓發的。IBFT從原來的PBFT繼承了三階段一致性：PRE-PREPARE, PREPARE , COMMIT。在N個驗證網絡中，系統最多能容忍F個故障節點，其中N=3F+1。

5. 權限許可

關鍵定義

• Network - 代表企業區塊鏈中的一組互連節點，包含組織
• Organization -具有與網絡交互的各種權限的一組角色、以太坊賬戶、節點
• Sub Organization -根據業務需要在組織內進一步分組
• Account - 以太坊賬戶EOA
• Voter - 能夠對特定操作進行投票的帳戶
• Role - 一個組織中的職能或者功能,擁有與其相關聯的授權和職責,可以通過分配來授予一個賬戶
• Node - 屬於網絡一部分並屬於組織或子組織的geth節點

權限設計

權限模型完全基於智能合約，智能合約設計如下：

權限智能合約設計遵循Proxy-Implementation-Storage模式，該模式允許更改實現邏輯而無需更改存儲或接口層。