文章目录 1. 概述2. 逻辑架构2.1 Quorum Node2.2 Constellation（星座）2.3 Tessera（甜美的裙子）2.4 Transaction Manager2.5 Enclave 3. 交易（事务）处理3.1 公开交易3.2 隐私交易3.3 交易处理3.4 隐私交易流程（Tessera） 4. 共识4.1 Raft-based4.2 Istanbul BFT 5. 权限许可权限设计
1. 概述
Quorum是摩根大通推出的联盟链，它是一种基于以太坊的分布式账本协议，可以称之为企业以太坊。
Quorum是以太坊go-ethereum的分支，并对go-ethereum进行了修改。
相比以太坊主要增强的功能：
隐私 -私有交易和私有智能合约新的共识机制-非POW/POS,基于raft的共识和Istanbul BFT网络、节点权限许可更高的性能 2. 逻辑架构
主要的组件:
Quorum Node，又名Quorum Client，是一个胖客户端，其隐私交易功能操作依赖用于加密和解密私有交易playload的Transaction Manager客户端。Quorum客户端及其依赖项（Transaction Manager, Peers, and Enclave）都使用传统的TCP / UDP传输层进行通信。
Quorum节点本身是一个轻量版的Geth。沿用Geth可以发挥以太坊社区原有的研发优势，因此Quorum会随着Geth未来的版本更新而更新。
Quorum节点基于Geth做了以下改动：
Constellation是基于Haskell开发，用于对Quorum隐私交易的加密，解密和分发。
Constellation是一个自我管理的peer-to-peer系统：
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的gsdxtg值。参与交易的参与者将能够通过其Constellation / Tessera实例将gsdxtg值替换为实际的Transaction Payload，而未参与交易的参与者将只能看到gsdxtg值。如果将隐私交易发送到持有合约代码的帐户，则那些不参与交易的参与者将最终跳过交易，因此不执行合约代码。但是，参与交易的那些参与者将在调用EVM执行之前将gsdxtg替换为原始Transaction Payload，并且其StateDB将相应更新。如果没有对geth客户进行相应的更改，那么这两组参与者最终将拥有不同的StateDB，并且无法达成共识。因此，为了支持合同状态的这种分歧，Quorum将公共合约的状态存储在全局同步的Public State Trie中，并将隐私合约的状态存储在未全局全局同步的Private State Trie中 3.4 隐私交易流程（Tessera）
上面示例中展示了Quorum隐私交易的流程，这笔交易只有参与者A与参与者B知道，C并不知道：
Dapp将Tx发送到Party A的Quorum节点，节点收到Tx后 ，生成Transaction Payload并将privateFor的值设置为为A和B的公钥（A是可选的）
Party A的Quorum节点将交易传递到其配对的Transaction Manager，要求其存储Transaction Payload
Party A的Transaction Manager调用对其关联的Enclave，以验证sender并加密Payload
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
Party A的Transaction Manager计算加密的Payload的SHA3-512gsdxtg值，然后将加密的Payload和加密的RMK、Hash存储在数据库中
Party A的Transaction Manager安全地（通过HTTPS）将加密的Payload和已使用共享密钥加密的RMK从先前的步骤4.c（随机数）转移到Party B的Transaction Manager。Party B的Transaction Manager以Ack / Nack响应进行响应。请注意，如果Party A未收到Party B的响应/未收到应答，则交易将不会传播到网络。接受者必须存储通信的Payload。
一旦成功传输到Party B的Transaction Manager，Party A的Transaction Manager将gsdxtg返回到Party A的Quorum节点，Quorum节点随后用该gsdxtg替换交易的原始Payload，并将交易签名的V值更改为37或38，37或38就是隐私交易的标识。其他节点查询后发现 V 的值为37或38时，就会认定其为隐私交易。
使用标准的以太坊P2P协议将交易传播到网络的其余部分。
创建一个包含交易AB的Block，并将其分发给网络上的每一方。
在处理该区块时，所有各方都将尝试处理该交易。每个Quorum节点将识别V为37或38 的值，将交易标识为需要解密其Payload的交易，并调用其本地Transaction Manager以确定它们是否持有事务（使用gsdxtg作为索引来查找）。
由于Party C不持有该交易，它将收到一条NotARecipient消息并跳过该交易-它不会更新其private StateDB。Party A和Party B将在其本地Transaction Manager中查找gsdxtg，并确定他们确实持有交易。然后，每个用户都将调用其Enclave，向其传入加密payload，加密的对称秘钥和交易签名。
Enclave验证签名，然后使用Enclave中保留的方的私钥解密对称密钥，使用现在公开的对称密钥解密Transaction Payload，然后将解密的Payload返回给Transaction Manager。
然后，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-basedQuorum有一个基于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与以太坊矿工一样负责将交易打包到一个区块中，但不提供工作证明。
Istanbul BFT共识是受Castro-Liskov 99 论文启发的。IBFT从原来的PBFT继承了三阶段一致性：PRE-PREPARE, PREPARE , COMMIT。在N个验证网络中，系统最多能容忍F个故障节点，其中N=3F+1。
5. 权限许可
关键定义
权限模型完全基于智能合约，智能合约设计如下：
权限智能合约设计遵循Proxy-Implementation-Storage模式，该模式允许更改实现逻辑而无需更改存储或接口层。