㈠ 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模块完成。