paxos属于区块链通信协议吗

1. btt是什么数字货币,未来发展前景如何

BTT，是BitTorrent(比特流)上的激励代币，中文是流币，对于BitTorrent，早期的互联网从业人员都很清楚，当时网络下载很慢，很多学生会在宿舍用BT下载资源，该协议使客户端软件端点能够相互协作，从而将大文件高效且可靠地分发到多个客户端，下载的用户越多，速度越快。

BitTorrent原是2001年诞生的一种点对点分布式通信协议，拥有超过1亿的用户，去年TRON基金会正式发表社区公开信，宣布了对 BitTorrent 公司的收购，这标志着BitTorrent协议与TRON波场区块链协议达成战略合作伙伴关系。

发展前景：

BitTorrent迅速发展成为了一个去中心化、缓慢发展、且几乎无需治理的生态系统，然而由于数亿用户依然在线上共享各种类型的媒体文件，因此它其实还是具备了强大的审查能力。

作为颠覆者，BitTorrent公司并未获得商业成功，尽管BitTorrent生态系统已经有了一定规模，而且获得了足够的行业影响力，但是作为一种颠覆创新技术，BitTorrent公司本身似乎从来没有靠技术本身获得商业成功，也许是缺少一个好的商业模式。

BTT商业模式

从商业模式的对比来看，BTT和链克虽然都是类似“上传即挖矿”的模式，但是细节上还是有很大的区别，比如，BTT是空投给用户使用，而链克还需要购买硬件，参与的门槛不一样。

两个项目虽然相似，但是还是有很大不同，链克需要有自己的硬件，而BTT直接用自身推出的APP+钱包的模式去推进，这样的方式对于推广而言成本较低，是一个可持续增长的过程。

说白了BTT其实也是做一个区块链的内容分发协议，类似于IPFS，如果说IPGS是分布式的HTTP，那么BT就是分布式的FTP。

2. 如何浅显易懂地解说 Paxos 的算法

Phase1：确定谁的编号最高，只有编号最高者才有权利提交proposal；
Phase2：编号最高者提交proposal，如果没有其他节点提出更高编号的proposal，则该提案会被顺利通过；否则，整个过程就会重来。
反复如此，算法永远无法结束，这叫活锁。FLP Impossibility已经证明，在异步通信中不存在任何一致性算法，活锁便是Paxos无法解决的硬伤。
Phase1，Phase2非常像2PC中的两个阶段，因此paxos本质上是多个2PC交替执行！
另外，即使明白了，在实现时会知道有多难，工程实现与理论差距很大。

3. 刚刚了解，谁能告诉我区块链是什么通俗解释一下区块链技术的方法

大家共同记账的方式，也被称为“分布式”或“去中心化”，因为人人都记账，且账本的准确性由程式算法决定，而非某个权威机构。

这就是区块链，核心讲完了，区块链就这么简单，一个共同记账的账本

区块链技术六大核心算法：

区块链核心算法一：拜占庭协定

拜占庭的故事大概是这么说的：拜占庭帝国拥有巨大的财富，周围10个邻邦垂诞已久，但拜占庭高墙耸立，固若金汤，没有一个单独的邻邦能够成功入侵。任何单个邻邦入侵的都会失败，同时也有可能自身被其他9个邻邦入侵。拜占庭帝国防御能力如此之强，至少要有十个邻邦中的一半以上同时进攻，才有可能攻破。然而，如果其中的一个或者几个邻邦本身答应好一起进攻，但实际过程出现背叛，那么入侵者可能都会被歼灭。于是每一方都小心行事，不敢轻易相信邻国。这就是拜占庭将军问题。

区块链核心算法二：非对称加密技术

在上述拜占庭协定中，如果10个将军中的几个同时发起消息，势必会造成系统的混乱，造成各说各的攻击时间方案，行动难以一致。谁都可以发起进攻的信息，但由谁来发出呢？其实这只要加入一个成本就可以了，即：一段时间内只有一个节点可以传播信息。当某个节点发出统一进攻的消息后，各个节点收到发起者的消息必须签名盖章，确认各自的身份。

区块链核心算法三：容错问题

我们假设在此网络中，消息可能会丢失、损坏、延迟、重复发送，并且接受的顺序与发送的顺序不一致。此外，节点的行为可以是任意的：可以随时加入、退出网络，可以丢弃消息、伪造消息、停止工作等，还可能发生各种人为或非人为的故障。我们的算法对由共识节点组成的共识系统，提供的容错能力，这种容错能力同时包含安全性和可用性，并适用于任何网络环境。

区块链核心算法四：Paxos 算法（一致性算法）

Paxos算法解决的问题是一个分布式系统如何就某个值(决议)达成一致。一个典型的场景是，在一个分布式数据库系统中，如果各节点的初始状态一致，每个节点都执行相同的操作序列，那么他们最后能得到一个一致的状态。为保证每个节点执行相同的命令序列，需要在每一条指令上执行一个“一致性算法”以保证每个节点看到的指令一致。一个通用的一致性算法可以应用在许多场景中，是分布式计算中的重要问题。 节点通信存在两种模型：共享内存和消息传递。Paxos算法就是一种基于消息传递模型的一致性算法。

区块链核心算法五：共识机制

区块链共识算法主要是工作量证明和权益证明。拿比特币来说，其实从技术角度来看可以把PoW看成重复使用的Hashcash，生成工作量证明在概率上来说是一个随机的过程。开采新的机密货币，生成区块时，必须得到所有参与者的同意，那矿工必须得到区块中所有数据的PoW工作证明。与此同时矿工还要时时观察调整这项工作的难度，因为对网络要求是平均每10分钟生成一个区块。

区块链核心算法六：分布式存储是一种数据存储技术，通过网络使用每台机器上的磁盘空间，并将这些分散的存储资源构成一个虚拟的存储设备，数据分散的存储在网络中的各个角落。所以，分布式存储技术并不是每台电脑都存放完整的数据，而是把数据切割后存放在不同的电脑里。就像存放100个鸡蛋，不是放在同一个篮子里，而是分开放在不同的地方，加起来的总和是100个。想了解更多可以多利用网络搜索，网络搜索结果-小知识

4. 分布式共识包含哪三种方法

PoW 、PoS 、DPOW都是什么意思？
说到区块链，我们必然会谈及它的共识机制。不了解区块链的共识机制，就无法理解区块链的真正意义。那么，今日份的区块链的共识机制了解一下？
共识机制是什么？
什么是共识？直取它的字面意思，就是"共同的认识".
人与人是不同的，这种不同不仅体现在身材、长相、能力，更体现在文化、观点、想法、利益诉求等等方面。
共识，简而言之，就是一个群体的成员在某一方面达成的一致意见。
我们了解到，信任是社会运转中的一大痛点，银行有自己的信用体系，过去的金融体系服务于只服务于极少的企业家，因为建立信用体系耗资巨大。后来支付宝有了芝麻信用，信用已经关系到生活的很多方面，信用卡额度、花呗额度，芝麻信用高出国还可以免签。我们正享受着信用给我们带来的便捷。
区块链本质是去中心化，去中心化的核心是共识机制，区块链上的共识机制主要解决由谁来构造区块，以及如何维护区块链统一的问题。
区块链共识机制的目标是使所有的诚实节点保存一致的区块链视图，同时满足两个性质：
1）一致性：所有诚实节点保存的区块链的前缀部分完全相同。
2）有效性：由某诚实节点发布的信息终将被其他所有诚实节点记录在自己的区块链中。
区块链的自信任主要体现于分布于区块链中的用户无须信任交易的另一方，也无须信任一个中心化的机构，只需要信任区块链协议下的软件系统即可实现交易。
共识机制是什么？PoW 、PoS 、DPOW都是什么意思？
共识机制的必要性？
分布式系统中，多个主机通过异步通信方式组成网络集群。在这样的一个异步系统中，需要主机之间进行状态复制，以保证每个主机达成一致的状态共识。错误信息可能出现在异步系统内并不断传播，因此需要在默认不可靠的异步网络中定义容错协议，以确保各主机达成安全可靠的状态共识，这就是共识机制诞生的必要性。
这种自信任的前提是区块链的共识机制（consensus），即在一个互不信任的市场中，要想使各节点达成一致的充分必要条件是每个节点出于对自身利益最大化的考虑，都会自发、诚实地遵守协议中预先设定的规则，判断每一笔记录的真实性，最终将判断为真的记录记入区块链之中。attachments-2018-08-9yY7VRHa5b738e3d96021.jpg
换句话说，如果各节点具有各自独立的利益并互相竞争，则这些节点几乎不可能合谋欺骗你，而当节点们在网络中拥有公共信誉时，这一点体现得尤为明显。区块链技术正是运用一套基于共识的数学算法，在机器之间建立"信任"网络，从而通过技术背书而非中心化信用机构来进行全新的信用创造。
当今区块链的几种共识机制介绍
区块链上的共识机制有多种，但任何一种都不是完美无缺，或者说适用于所有应用场景的。
PoW 工作量证明
整个系统中每个节点为整个系统提供计算能力（简称算力），通过一个竞争机制，让计算工作完成最出色的节点获得系统的奖励，即完成新生成货币的分配，简单理解就是多劳多得，bitcoin、LTC等货币型区块链就应用POW机制。
优点
完全去中心化节点自由进出，算法简单，容易实现破坏系统花费的成本巨大，只要网络破坏者的算力不超过网络总算力的50%,网络的交易状态就能达成一致
缺点
浪费能源，这是最大的缺点区块的确认时间难以缩短，如bitcoin每秒只能做7笔交易，不适合商业应用新的区块链必须找到一种不同的散列算法，否则就会面临bitcoin的算力攻击对节点的性能网络环境要求高容易产生分叉，需要等待多个确认无法达成最终一致性
PoS 权益证明
也称股权证明，类似于你把财产存在银行，这种模式会根据你持有加密货币的数量和时间，分配给你相应的利息。
优点
对节点性能要求低，达成共识时间短
缺点
没有最终一致性，需要检查点机制来弥补最终性
DPOW 委托股权证明
DPOW是 PoS 的进化方案，在常规 PoW和 PoS 中，任何一个新加入的区块，都需要被整个网络所有节点做确认，非常影响效率。
DPoS则类似于现代董事会的投票机制，通过选举代表来进行投票和决策。被选举出的n个记账节点来做新区块的创建、验证、签名和相互监督，这样就极大地减少了区块创建和确认所需要消耗的时间和算力成本。
优点
大幅缩小参与验证和记账节点的数量，可以达到秒级的共识验证
缺点
牺牲了去中心化的概念，不适合公有链
PBFT 实用拜占庭容错
实用拜占庭容错机制是一种采用"许可投票、少数服从多数"来选举领导者并进行记账的共识机制，该共识机制允许拜占庭容错，允许强监督节点参与，具备权限分级能力，性能更高，耗能更低，而且每轮记账都会由全网节点共同选举领导者，允许33%的节点作恶，容错率为33%.实用拜占庭容错特别适合联盟链的应用场景。
优点
会背离中心化，加密货币的存在及奖励机制会产生马太效应，让社区中的穷者更穷，富者更富共识效率高，可实现高频交易
缺点
当系统只剩下33%的节点运行时，系统会停止运行
dBFT 授权拜占庭容错
这种机制是用权益来选出记账人，然后记账人之间通过拜占庭容错算法达成共识。授权拜占庭容错机制最核心的一点，就是最大限度地确保系统的最终性，使区块链能够适用于真正的金融应用场景。
优点
专业化的记账人可以容忍任何类型的错误记账由多人协同完成，每一个区块都有最终性，不会分叉算法的可靠性有严格的数学证明
缺点
当三分之一或以上记账人停止工作后，系统将无法提供服务当三分之一或以上记账人联合作恶，可能会使系统出现分叉
Pool 验证池
基于传统的分布式一致性技术，加上数据验证机制。
优点
不需要加密货币也可以工作，在成熟的分布式一致性算法（Pasox、Raft）基础上，实现秒级共识验证。
缺点
去中心化程度不如bitcoin,更适合多方参与的多中心商业模式。
Paxos
这是一种传统的分布式一致性算法，是一种基于选举领导者的共识机制。领导者节点拥有绝对权限，并允许强监督节点参与，其性能高，资源消耗低。所有节点一般有线下准入机制，但选举过程中不允许有作恶节点，不具备容错性。
Paxos算法中将节点分为三种类型：
proposer:提出一个提案，等待大家批准为结案。往往是客户端担任该角色
acceptor:负责对提案进行投票。往往是服务端担任该角色
learner:被告知结案结果，并与之统一，不参与投票过程。可能为客户端或服务端
Paxos 能保证在超过50%的正常节点存在时，系统能达成共识。
瑞波共识机制
瑞波共识算法使一组节点能够基于特殊节点列表形成共识，初始特殊节点列表就像一个俱乐部，要接纳一个新成员，必须由该俱乐部51%的会员投票通过。共识遵循这些核心成员的"51%权利",外部人员则没有影响力。由于该俱乐部由中心化开始，它将一直是中心化的，而如果它开始腐化，股东们什么也做不了。与bitcoin及Peercoin一样，瑞波系统将股东们与其投票权隔开，因此，它比其他系统更中心化。
Peercoin
Peercoin（点点币，PPC），混合了POW工作量证明及POS权益证明方式，其中POW主要用于发行货币，未来预计随着挖矿难度上升，产量降低，系统安全主要由POS维护。
在区块链网络中，由于应用场景的不同，所设计的目标各异，不同的区块链系统采用了不同的共识算法。每种共识算法都不是完美的，都有其优点和局限性。
区块链解决了在不可信信道上传输可信信息、价值转移的问题，而共识机制解决了区块链如何分布式场景下达成一致性的问题。
虽然区块链目前还处于发展的早期，行业发展还面临着一些阻碍，但社会已经足够多地认识到区块链的价值，区块链发展的脚步绝不会停滞不前，行业发展也定会找到突破阻碍的方法。

5. 区块链使用什么网络协议

协议是管理网络的一组规则。区块链协议通常包括共识、交易验证和网络参与的规则。协议通常依赖于经济激励——这意味着协议取决于某项资产。
通常，协议级别的资产也可以作为协议的本地产品（无需平台！）比特币就是一个很好的例子。Bitcoin（大写B）是指协议。协议取决于本地资产：bitcoin（小写字母b）。这个本地资产也被用作最终产品：它是用户的支付手段，价值储存，以及（说实话）一定程度上的炒作手段。请注意，比特币并不真正提供一个平台。对于那些试图在其上建立新产品的开发者来说，这并不是很友好。
另一方面，以太坊则存在着三个层次。这是一个协议，提供基本的规则。这是一个平台，使开发人员能够在系统上构建新的产品。而且，因为它的协议中包含一项本地资产，所以它也得到了一个内置的产品（以ether以太币的形式）。
区块链的应用领域有数字货币、通证、金融、防伪溯源、隐私保护、供应链、娱乐等等，区块链、比特币的火爆，不少相关的top域名都被注册，对域名行业产生了比较大的影响。

6. 区块链技术是一种网络协议吗

重庆金窝窝分析区块链也是一种网络协议，如果说互联网是信息传输的技术协议，那么区块链就是价值传输的技术协议。

7. Paxos 算法的几种算法

上面通过证明如果一个协议满足B1-B3 约束条件，那么就可以保证一致性。直接从这些约束得到preliminary protocol ，basic protocol 是preliminary protocol 的限制版，保证了一致性。complete Synod protocol 进一步限制了basic protocol ，满足一致性和过程需求（progress requirements）。下面将这三个算法的具体过程。 满足B1，牧师发起选举的编号必须满足偏序关系，有一个方法是每个发起牧师使用递增的数值作为选举编号，但这样牧师无法立即知道他们选的数值有没有被其他牧师选作选举编号已经被使用。还有一个方法是使用数字+牧师姓名作为选举编号，这样就避免了自己的选举编号被其他牧师使用。
满足B2，每次选举的法定人数必须是一个大部分集合（majority set）Q，这样任意两个选举都会有一个共同的牧师。这里大部分集合是一个灵活的选择，在原文中Lamport 使用体重打比方，体重的人更有可能呆在议会大厅，这样就可以使用体重超过一半的牧师集合作为大部分集合。至于实际情况中的大部分集合是什么要看具体情况了。
满足B3，要求每个牧师p 每次在发起选举前必须找到B_qrm 中每个牧师q 的MaxVote(b,q,B)。
根据以上要求，可以得到初始协议：
1. 牧师p 选择一个选举编号b ，并发送NextBallot(b)送给其他牧师
2. 其他牧师q 在收到NextBallot(b) 后，返回LastVote(b,v) 给牧师p，v=MaxVote(b,q,B)$是小于b 编号的q 投的最大的赞成票。为了保证B3，q 不能在b 和b_bal 之间的选举投赞成票。（如果q 在发送了LastVote(b,v)又对新的选举投票了那么v 也就不是q 投的最大赞成票）
3. 牧师p 从一个大部分集合Q 中每个牧师q 中都收到LastVote(b,v) 后，发起一个新的选举，编号为b，法定人数为Q，法律d满足B3。然后牧师p 将这个法律写在自己账目的背面，发送BeginBallot(b,d)给Q 中每个牧师。
4. 牧师q 收到BeginBallot(b,d) 后决定是否为这次选举投赞成票，如果赞同，则他将发送Vote(b,q) 给牧师p。
5. 如果牧师p 收到Q 中每个牧师q 发来的赞成票Vote(b,q)，则将法律d 写入他的账目中，并向所有q发送Success(d) 消息。
6. 收到Success(d) 消息后，牧师q 将法律d 写入到自己的账目中。
说明：第一步表示发起法律的牧师p 希望下一个选举的编号是b 。牧师q 用LastVote(b,v) 回应了牧师p 的请求，也就是向牧师p 通过法律时保证了v=MaxVote(b,q,B) 的被改变，具体来说就是不在b 和b_bal 之间的选举投赞成票。
第三步要求法律d 需要满足B3，这里我开始有点迷糊，实际系统中的值是客户端决定的，而不应该是B3 决定的。这里我们还是用上面的key-value 数据库的例子来理清下思路：当某个节点/牧师第一次发起更新前相当于B为空集，发起更新/选举的操作不断进行，直至所有法定人数（quorum）都对法律投了赞成票（即majority set 的节点都更新了该key-value 的值则认为更新成功），B3对应的就是之前的更新没有成功，那么新的选举值需要保持的情况。第四步允许牧师可以不发送Vote(b,q) 或者发送几次，对应的是发送的信息可能因为通信而失败而未发送或者被多次发送。一旦牧师投了赞成票则确认可以修改该值。
考虑到最后第六步法律d 才被牧师q 写入到账目，有可能出现的情况就是在第五步的时候牧师p 将法律写入到了自己账目中，接着发送Success(d) 给其他牧师，其中因为通信或者牧师离开议会大厅而没有被写入到自己的账目中，导致不一致。所以真正写入到账目时机应该是在第四步牧师q 在发送给牧师p 赞成票的同时就法律写入到了各自账目中。而不用考虑如何保证牧师q 第四步写入的法律会导致不一致，因为法律如果没有通过则还有更多的选举来保证一致性。后面也谈到了当法律第一次别写入到账目中算通过法律。 初始协议（Preliminary Protocol）要求每个牧师都保存 (i) 他发起的每个选举； (ii) 他投的每个赞成票； (iii) 他发送的每个$LastVote$。为了简化牧师需要保存的数据，我们对上面的协议做一个限制，得到基础（Basic Protocol）协议。首先介绍三个新的参数：
lastTried[p] 牧师p 发起的最后一个选举
prevVote[p] 牧师p 最近一次的投票
nextBal[p] 收到的选举编号的b 的最大值，即牧师p参加的最大选举编号
在初始协议中，每个牧师可以同时发起任意个选举，在基础协议中要求每个牧师只能发起一个选举lastTried[p]，一旦发起一个选举，那么之前发起选举的信息就都不重要了。在初始协议中要求每个牧师不能在b_bal 和b 之间投赞成票，在基础协议中则更严格地要求不能给小于b 的选举投赞成票。那么基础协议可以概述为下面几步：
1. 牧师p 选择一个大于lastTried[p] 的选举编号b ，发送NextBallot(b)给其他牧师
2. 牧师q 收到NextBallot(b) 且b>nextBal[q]后设置nextBal[q]=b ，接着发送LastVote(b,v) 给牧师p，其中v==prevBa[q] 。（如果b 小于或等于nextBal[q]，则不回复）
3. 从满足某个大部分集合Q 中每个牧师收到了LastVote(b,v) 信息，牧师p 发起一个编号为b ，法定人数为Q ，法律为d（满足B3 ）的选举，并将BeginBallot(b,d) 发送给Q 中每个牧师。（如果没有满足任意大部分集合Q 的牧师返回，则返回第一步）
4. 牧师q 收到BeginBallot(b,d) ，决定投赞成票，设置prevVote[p] 为这次投票，并发送Vote(b,q) 给牧师p。（如果在收到BeginBallot(b,d) 后发现b 不等于nextBal[q] 则忽略这条信息，说明这期间牧师q 还收到了其他的编号更大的选举）
5. 牧师p 从大部分集合Q 中每个牧师q 收到了Voted(b,d) ，且b==lastTried[p] ，则认为这次选举成功，将法律d 记录在账目中，并向Q 中每个牧师q 发功成功消息Success(d) 。
6. 每个牧师q 收到Success(d) 消息后将法律写入账目。
基础协议是初始协议的限制版，因为两者都对牧师没有行为要求，所以也不保证过程（QS）。下面介绍一个保证过程的协议— 完整议会协议（complete Synode protocol）。 基础协议保证了一致性却没有保证任何过程，因为它只阐述了牧师可能做什么，没有要求牧师应该做什么。为了达到之前谈到的过程需求（Qrogress Requirements），我们需要添加一些额外的要求使得牧师们尽快执行完2-6 步。
考虑一种情况如果牧师q 第二步收到的选举编号b 都比之前收到的要大，那么他就要放弃之前收到的所有选举。可是在选举编号为b 的选举在未确认前，可能又会收到更大编号的选举b’ ，这样就无法通过任何法律，过程也不能保证。所以为了达到过程需求则需要一个选举成功后再发起另一个选举。而首先应该知道服务员传递消息和牧师处理消息的时间，在网络中常常通过设置timeout 来实现，同样的如果超过了一定时间牧师没有收到服务员的回复，则认为该服务员或者对应的牧师离开了议会大厅。
假设牧师执行一个动作在7 分钟以内，服务员传递一个消息在4 分钟以内，那么一个牧师p 发送消息给牧师q ，希望其回复的时间应该是在22 分钟内（7+4+7+4 分钟）。
有了上面时间的假设，再考虑上面讨论过的情况，如果发起选举的牧师p 会在第二步和第四步期望22 分钟内收到其他牧师的回复，如果没有则可能是一些牧师或者服务员离开了议会大厅，或者还有一些牧师发起了编号更大的选举。遇到这两种情况都牧师p 应该终止本次选举，而重新开始发起一个新的选举，为了不至于新发起的选举编号还是太小而仍不能执行，需要从其他牧师哪里获取最新的选举编号，从而选取一个更大的编号发起选举。
进而假设牧师p 是唯一能够发起选举的牧师且议会大厅内有大部分集合的牧师，那么可以保证在99分钟内通过一条法律：22 分钟内发现了有更大编号的法律，22 分钟内获取最大编号并选择个更大的编号，55 分钟内完成1-6 步完成一次成功的选举（疑问：既然只有牧师p 能够发起选举，那么编号都是由其控制的，前两步发现并选择更大的编号似乎就没有必要了。答：并不是所有的选举都是president发起的，其他牧师发起选举，president向其他希望发起选举的牧师配发选举编号）。从上面的过程我们发现完整议会协议需要一个选举president的过程，president的选举算法不是文章重点，所以文章中仅用T 分钟代替了选举president的时间，这样T+99 分钟内可以通过一部法律。
文中选择president的方法是谁的姓在字母表中最后，并将自己的姓发送给议会大厅内所有牧师，如果在T-11 分钟内某个牧师没有收到比自己姓在字母表中更靠后的姓，则认为自己是president（我觉得广播体重也应该不错，不是说体重更重的呆在议会大厅会更久么？^_^）。还有一个细节：在选举president的时候每个牧师p 需要将自己的lastTried[p] 发送给其他牧师，以使得president能够在第一次选举时选择一个足够大的编号。
至此，通过选举president和设置超时，完整议会协议就可以保证过程了。
多法律国会协议
上节的议会协议（complete Synod protocol）中，president被选举出来后，每个希望发起选举的牧师通知他，president给牧师配发选举编号，每次仅通过一部法律。多法律国会协议（The Multi-Decree Parliment）选择一个president通过一系列法律，且只需要执行前两步一次即可。
具体方法是president第一步发送NextBallot(b,n) 代替NextBallot(b) ，表示希望通过n-b 之间的所有的法律，在president 的账目上，编号n 之前的法律都是连续记录了的，b>n 。其他牧师q 收到消息后将每部已经出现在其账目中编号大于$n$的法律都返回给president，不在账目上的返回正常的LastVote 信息。
下面谈到多法律国会协议有关性质，首先是法律的顺序，不同法律编号的选举同时进行，发起选举的每个牧师都认为自己是president（不知道president 是怎么选举出来的，也不知道法律通过的顺序）。在完整议会协议第三步中法律被提议，第一次写入到账目上时称法律被通过。当一个president需要提出新的法案时，他必须从大部分集合牧师中学习到那么法律他们都投了赞成票，每部法律都被大部分集合牧师中至少一个牧师投了票，所以president发起新的选举前总能学到所有之前通过了的法律。president不会在空缺的法律编号内填补重要的法律。，也不会乱序提议法律，所以协议满足“法律有序性”：如果法律A 和法律B 都是重要的法律，法律A 在法律B 提议之前通过，那么法律A 有比法律B 更低的法律编号。第二点属性是president在选举出后且没有人再进出议会大厅，法律是按照下面步骤不断通过的（对应完整议会协议的3-5步）：
3. president 向一个法定人数牧师中每个牧师发送BeginBallot ；
4.每个牧师向president 发送Voted 信息。
5.president向每个牧师发送Success 消息。这样通过每部法律只需要三次消息传递，通过合并BeginBallot 和Success 命令可以进一步减少消息传递。

8. OceanBase的一致性协议为什么选择 paxos而不是raft

基于Raft的分布式一致性协议实现的局限及其对数据库的风险普通服务器具有良好的性价比，因此在互联网等行业得到了广泛的应用。但普通服务器也不得不面对2%-4%的年故障率([1])，于是必须高可用的传统数据库只得很悲催地使用性价比低得可怜的高可靠服务器。分布式一致性协议（distributed consensus protocol）是迄今为止最有效的解决服务器不可靠问题的途径，因为它使得一组服务器形成一个相互协同的系统，从而当其中部分服务器故障后，整个系统也能够继续工作。而Paxos协议([2])则几乎成了分布式一致性协议的代名词。然而，Paxos协议的难以理解的名声似乎跟它本身一样出名。为此，Stanford大学的博士生Diego Ongaro甚至把对Paxos协议的研究作为了博士课题。他在2014年秋天正式发表了博士论文：“CONSENSUS: BRIDGING THEORY AND PRACTICE”，在这篇博士论文中，他给出了分布式一致性协议的一个实现算法，即Raft。由于这篇博士论文很长（257页），可能是为了便于别人阅读和理解，他在博士论文正式发表之前，即2014年初，把Raft相关的部分摘了出来，形成了一篇十多页的文章：“In Search of an Understandable Consensus Algorithm”，即人们俗称的Raft论文。Raft算法给出了分布式一致性协议的一个比较简单的实现，到目前为止并没有人挑战这个算法的正确性。然而，OceanBase却没有采用Raft算法，这并非是OceanBase团队同学不懂Raft，而是Raft的一个根本性的局限对数据库的事务有很大的风险。Raft有一个很强的假设是主（leader）和备（follower）都按顺序投票，为了便于阐述，以数据库事务为例：·主库按事务顺序发送事务日志·备库按事务顺序持久化事务和应答主库