Quorum工作原理

文章目录

- 1. 概述
- 2. 逻辑架构
- - - 2.1 Quorum Node
    - 2.2 Constellation（星座）
    - 2.3 Tessera（特赛拉）
    - 2.4 Transaction Manager
    - 2.5 Enclave
- 3. 交易（事务）处理
- - - 3.1 公开交易
    - 3.2 隐私交易
    - 3.3 交易处理
    - 3.4 隐私交易流程（Tessera）
- 4. 共识
- - - 4.1 Raft-based
    - 4.2 Istanbul BFT
- 5. 权限许可
- - - 权限设计

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）

隐私交易流程（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-512哈希值，然后将加密的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将哈希返回到Party A的Quorum节点，Quorum节点随后用该哈希替换交易的原始Payload，并将交易签名的V值更改为37或38，37或38就是隐私交易的标识。其他节点查询后发现 V 的值为37或38时，就会认定其为隐私交易。
使用标准的以太坊P2P协议将交易传播到网络的其余部分。
创建一个包含交易AB的Block，并将其分发给网络上的每一方。
在处理该区块时，所有各方都将尝试处理该交易。每个Quorum节点将识别V为37或38 的值，将交易标识为需要解密其Payload的交易，并调用其本地Transaction Manager以确定它们是否持有事务（使用哈希作为索引来查找）。
由于Party C不持有该交易，它将收到一条NotARecipient消息并跳过该交易-它不会更新其private StateDB。Party A和Party B将在其本地Transaction Manager中查找哈希，并确定他们确实持有交易。然后，每个用户都将调用其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-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与以太坊矿工一样负责将交易打包到一个区块中，但不提供工作证明。