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模式，该模式允许更改实现逻辑而无需更改存储或接口层。