Ⅰ 以太坊stratum协议原理
参照比特币的 stratum协议 和 NiceHash的stratum协议规范 编写了一版以太坊版本的stratum协议说明.
stratum协议是目前最常用的矿机和矿池之间的TCP通讯协议。
以太坊是一个去中心化的网络架构，通过安装Mist客户端的节点来转发新交易和新区块。而矿机、矿池也同时形成了另一个网络，我们称之为矿工网络。
矿工网络分成矿机、矿池、钱包等几个主要部分，有时矿池软件与钱包安装在一起，可合称为矿池。
矿机与矿池软件之间的通讯协议是 stratum ，而矿池软件与钱包之间的通讯是 bitcoinrpc 接口。
stratum是 JSON 为数据格式.
矿机启动，首先以 mining.subscribe 方法向矿池连接，用来订阅工作。
矿池以 mining.notify 返回订阅号、ExtraNonce1和ExtraNonce2_size。
Client:
Server:
其中：
是 订阅号 ；
080c是 extranonce ，Extranonce可能最大3字节；
矿机以 mining.authorize 方法，用某个帐号和密码登录到矿池，密码可空，矿池返回 true 登录成功。该方法必须是在初始化连接之后马上进行，否则矿机得不到矿池任务。
Client:
Server:
难度调整由矿池下发给矿机，以 mining.set_difficulty 方法调整难度， params 中是难度值。
Server:
矿机会在下一个任务时采用新难度，矿池有时会马上下发一个新任务并且把清理任务设为true，以便矿机马上以新难度工作。
该命令由矿池定期发给矿机，当矿机以 mining.subscribe 方法登记后，矿池应该马上以 mining.notify 返回该任务。
Server:
任务ID ： bf0488aa ；
seedhash ： 。每一个任务都发送一个seedhash来支持尽可能多的矿池，这可能会很快地在货币之间交换。
headerhash : 。
boolean cleanjobs : true 。如果设为true，那么矿工需要清理任务队列，并立即开始从事新提供的任务，因为所有旧的任务分享都将导致陈旧的分享错误。如果是 false 则等当前任务结束才开始新任务。
矿工使用seedhash识别DAG，然后带着headerhash,extranonce和自己的minernonce寻找低于目标的share(这是由提供的难度而产生的)。
矿机找到合法share时，就以” mining.submit “方法向矿池提交任务。矿池返回true即提交成功，如果失败则error中有具体原因。
Client:
任务ID : bf0488aa
minernonce : 6a909d9bbc0f 。注意minernonce是6个字节，因为提供的extranonce是2个字节。如果矿池提供3字节的extranonce，那么minernonce必须是5字节
Server:
一般的矿机与矿池通讯过程就如下所示：
Ⅱ 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的工作流程做大致梳理和介绍