全异步算法(全异步算法是什么)
本篇文章给大家谈谈全异步算法，以及全异步算法是什么对应的知识点，文章可能有点长，但是希望大家可以阅读完，增长自己的知识，最重要的是希望对各位有所帮助，可以解决了您的问题，不要忘了收藏本站喔。
matlab最优化算法有哪些
matlab最优化程序包括
无约束一维极值问题进退法黄金分割法斐波那契法牛顿法基本牛顿法全局牛顿法割线法抛物线法三次插值法可接受搜索法Goidstein法Wolfe.Powell法
单纯形搜索法Powell法最速下降法共轭梯度法牛顿法修正牛顿法拟牛顿法信赖域法显式最速下降法，Rosen梯度投影法罚函数法外点罚函数法
内点罚函数法混合罚函数法乘子法G－N法修正G－N法L－M法线性规划单纯形法修正单纯形法大M法变量有界单纯形法整数规划割平面法分支定界法0-1规划二次规划
拉格朗曰法起作用集算法路径跟踪法粒子群优化算法基本粒子群算法带压缩因子的粒子群算法权重改进的粒子群算法线性递减权重法自适应权重法随机权重法
变学习因子的粒子群算法同步变化的学习因子异步变化的学习因子二阶粒子群算法二阶振荡粒子群算法
分布式一致性算法
sschrodinger
2019/07/17
一个分布式系统不可能同时满足一致性（C:Consistency)，可用性（A:Availability）和分区容错性（P：Partitiontolerance）这三个基本需求，最多只能同时满足其中的2个。
如下：
BASE是BasicallyAvailable(基本可用)，Softstate（软状态）,和Eventuallyconsistent（最终一致性）三个短语的缩写。
既是无法做到强一致性（Strongconsistency），但每个应用都可以根据自身的业务特点，采用适当的方式来使系统达到最终一致性（Eventualconsistency）
基本可用
允许出现响应时间损失或者功能损失。
软状态
允许系统中的数据存在中间状态，并认为该状态不影响系统的整体可用性，即允许系统在多个不同节点的数据副本存在数据延时。
最终一致性
系统能够保证在没有其他新的更新操作的情况下，数据最终一定能够达到一致的状态，因此所有客户端对系统的数据访问最终都能够获取到最新的值。
在分布式系统中，会有多个机器节点，因此需要一个“协调者”，而各个节点就是“参与者”，协调者统一调度所有分布式节点的执行逻辑，这些被调度的分布式节点就是“参与者”。
阶段一
阶段一主要是询问参与者是否可以进行提交。
阶段二
阶段二会根据阶段一的投票结果执行两种操作：执行事务提交，回滚事务。
执行事务提交步骤如下：
中断事务步骤如下：
优点
原理简单，实现方便
缺点
同步阻塞，单点问题，数据不一致，过于保守
2PC（两阶段提交协议）
三阶段提交协议在协调者和参与者中都引入超时机制，并且把两阶段提交协议的第一个阶段拆分成了两步：询问，然后再锁资源，最后真正提交。
协调流程如下：
阶段一：CanCommit
阶段二：preCommit
协调者在得到所有参与者的响应之后，会根据结果执行2种操作：执行事务预提交，或者中断事务。
执行事务预提交分为3个步骤：
中断事务也分为2个步骤：
阶段三：doCommit
该阶段做真正的提交，同样也会出现两种情况：
执行提交
中断事务
假设有任何参与者反馈了no响应，或者超时了，就中断事务。
优点
缺点
如果参与者收到了preCommit消息后，出现了网络分区，那么参与者等待超时后，都会进行事务的提交，这必然会出现事务不一致的问题
3PC（三阶段提交协议）
paxos算法保证了一致性。
在一个分布式系统中，有一组的process，每个process都可以提出一个value，consensus算法就是用来从这些values里选定一个最终value。如果没有value被提出来，那么就没有value被选中；如果有1个value被选中，那么所有的process都应该被通知到。
在2PC或者3PC中，如果协调者宕机了，整个系统就宕机了，这个时候就需要引用多个协调者，paxos就是用来协调协调者的协议。
首先将议员的角色分为proposers，acceptors，和learners（允许身兼数职）。proposers提出提案，提案信息包括提案编号和提议的value；acceptor收到提案后可以接受（accept）提案，若提案获得多数派（majority）的acceptors的接受，则称该提案被批准（chosen）；learners只能“学习”被批准的提案。划分角色后，就可以更精确的定义问题：
通过不断加强上述3个约束（主要是第二个）获得了Paxos算法。
批准value的过程中，首先proposers将value发送给acceptors，之后acceptors对value进行接受（accept）。为了满足只批准一个value的约束，要求经“多数派（majority）”接受的value成为正式的决议（称为“批准”决议）。这是因为无论是按照人数还是按照权重划分，两组“多数派”至少有一个公共的acceptor，如果每个acceptor只能接受一个value，约束2就能保证。
于是产生了一个显而易见的新约束：
注意P1是不完备的。如果恰好一半acceptor接受的提案具有valueA，另一半接受的提案具有valueB，那么就无法形成多数派，无法批准任何一个value。
约束2并不要求只批准一个提案，暗示可能存在多个提案。只要提案的value是一样的，批准多个提案不违背约束2。于是可以产生约束P2：
如果P1和P2都能够保证，那么约束2就能够保证。
批准一个value意味着多个acceptor接受（accept）了该value。因此，可以对P2进行加强：
由于通信是异步的，P2a和P1会发生冲突。如果一个value被批准后，一个proposer和一个acceptor从休眠中苏醒，前者提出一个具有新的value的提案。根据P1，后者应当接受，根据P2a，则不应当接受，这种场景下P2a和P1有矛盾。于是需要换个思路，转而对proposer的行为进行约束：
由于acceptor能接受的提案都必须由proposer提出，所以P2b蕴涵了P2a，是一个更强的约束。
但是根据P2b难以提出实现手段。因此需要进一步加强P2b。
假设一个编号为m的valuev已经获得批准（chosen），来看看在什么情况下对任何编号为n（n>m）的提案都含有valuev。因为m已经获得批准（chosen），显然存在一个acceptors的多数派C，他们都接受（accept）了v。考虑到任何多数派都和C具有至少一个公共成员，可以找到一个蕴涵P2b的约束P2c：
如果一个没有chose过任何proposer提案的acceptor在prepare过程中接受了一个proposer针对提案n的问题，但是在开始对n进行投票前，又接受（accept）了编号小于n的另一个提案（例如n-1），如果n-1和n具有不同的value，这个投票就会违背P2c。因此在prepare过程中，acceptor进行的回答同时也应包含承诺：不会再接受（accept）编号小于n的提案。这是对P1的加强：
通过一个决议分为两个阶段：
prepare阶段
proposer选择一个提案编号n并将prepare请求发送给acceptors中的一个多数派；
acceptor收到prepare消息后，如果提案的编号大于它已经回复的所有prepare消息(回复消息表示接受accept)，则acceptor将自己上次接受的提案回复给proposer，并承诺不再回复小于n的提案；
批准阶段
当一个proposer收到了多数acceptors对prepare的回复后，就进入批准阶段。它要向回复prepare请求的acceptors发送accept请求，包括编号n和根据P2c决定的value（如果根据P2c没有已经接受的value，那么它可以自由决定value）。
在不违背自己向其他proposer的承诺的前提下，acceptor收到accept请求后即批准这个请求。
这个过程在任何时候中断都可以保证正确性。例如如果一个proposer发现已经有其他proposers提出了编号更高的提案，则有必要中断这个过程。因此为了优化，在上述prepare过程中，如果一个acceptor发现存在一个更高编号的提案，则需要通知proposer，提醒其中断这次提案。
一个实例如下：
在这之后，提议者还需要做一件事，就是告知D,E，被决定的决议已经是什么了。即可。
这个过程叫Learn。D，E被称为Learner.
PaxosVSZab
wiki百科
维基百科-paxos
对于paxos来说，每一个议案都要经过不同节点的提出，并且讨论，在提出一个议案的阶段，另外的提议会被否决，导致了性能的低下。
ZAB协议是为分布式协调服务Zookeeper专门设计的一种支持崩溃恢复和原子广播协议。
基于该协议，Zookeeper实现了一种主备模式的系统架构来保持集群中各个副本之间数据一致性。具体如下图所示：
即只有一个proposal可以提出提议，其他的进程都只能复制决议。
所有客户端写入数据都是写入到主进程（称为Leader）中，然后，由Leader复制到备份进程（称为Follower）中。从而保证数据一致性。
ZAB协议的消息广播过程使用的是一个原子广播协议，类似一个二阶段提交过程。但是只需要Follower有一半以上返回Ack信息就可以执行提交，大大减小了同步阻塞。也提高了可用性。
对于客户端发送的写请求，全部由Leader接收，Leader将请求封装成一个事务Proposal，将其发送给所有Follwer，然后，根据所有Follwer的反馈，如果超过半数成功响应，则执行commit操作（先提交自己，再发送commit给所有Follwer）。
流程如下：
Leader挂了之后，ZAB协议就自动进入崩溃恢复模式，选举出新的Leader，并完成数据同步，然后退出崩溃恢复模式进入消息广播模式。
可能Leader遇到如下异常情况：
第一种情况主要是当leader收到合法数量follower的ACKs后，就向各个follower广播COMMIT命令，同时也会在本地执行COMMIT并向连接的客户端返回「成功」。但是如果在各个follower在收到COMMIT命令前leader就挂了，导致剩下的服务器并没有执行都这条消息。
为了实现已经被处理的消息不能丢这个目的，Zab的恢复模式使用了以下的策略：
第二种情况主要是当leader接收到消息请求生成proposal后就挂了，其他follower并没有收到此proposal，因此经过恢复模式重新选了leader后，这条消息是被跳过的(其他机器日志中没有这一条记录，但是他的日志中有这一条记录)。此时，之前挂了的leader重新启动并注册成了follower，他保留了被跳过消息的proposal状态，与整个系统的状态是不一致的，需要将其删除。
Zab通过巧妙的设计zxid来实现这一目的。一个zxid是64位，高32是纪元（epoch）编号，每经过一次leader选举产生一个新的leader，新leader会将epoch+1。低32位是消息计数器，每接到一个消息，则$lo^{32}+1$，新leader选举后这个值重置为0。这样设计的好处是旧的leader挂了后重启，它不会被选举为leader，因为此时它的zxid肯定小于当前的新leader。当旧的leader作为follower接入新的leader后，新的leader会让它将所有的拥有旧的epoch未被COMMIT的proposal清除。
Zookeeper系列（5）--ZAB协议，消息广播，崩溃恢复，数据同步
Raft是用于管理复制日志的一致性算法，raft协议也是一个主备模型，有一个唯一的leader控制任务的提交。
如下是一个raft协议中每一个节点可能存在的状态，主要分为领袖、群众和候选人。
raft最关键的一个概念是任期，每一个leader都有自己的任期，必须在任期内发送心跳信息给follower来延长自己的任期。
Raft协议强依赖Leader节点的可用性来确保集群数据的一致性。数据的流向只能从Leader节点向Follower节点转移。当Client向集群Leader节点提交数据后，Leader节点接收到的数据处于未提交状态（Uncommitted），接着Leader节点会并发向所有Follower节点复制数据并等待接收响应，确保至少集群中超过半数节点已接收到数据后再向Client确认数据已接收。一旦向Client发出数据接收Ack响应后，表明此时数据状态进入已提交（Committed），Leader节点再向Follower节点发通知告知该数据状态已提交。
在数据同步阶段，可能出现七种情况：
动画演示raft算法
动画演示raft算法-2
RaftVszab
NWR是一种在分布式存储系统中用于控制一致性级别的一种策略。在Amazon的Dynamo云存储系统中，就应用NWR来控制一致性。
让我们先来看看这三个字母的含义：
在分布式系统中，数据的单点是不允许存在的。即线上正常存在的Replica数量是1的情况是非常危险的，因为一旦这个Replica再次错误，就可能发生数据的永久性错误。假如我们把N设置成为2，那么，只要有一个存储节点发生损坏，就会有单点的存在。所以N必须大于2。N约高，系统的维护和整体成本就越高。工业界通常把N设置为3。
当W是2、R是2的时候，W+R>N，这种情况对于客户端就是强一致性的。
在具体实现系统时，仅仅依靠NWR协议还不能完成一致性保证，因为在上述过程中，当读取到多个备份数据时，需要判断哪些数据是最新的，如何判断数据的新旧？这需要向量时钟来配合，所以对于Dynamo来说，是通过NWR协议结合向量时钟来共同完成一致性保证的。
常见的共识算法介绍
在异步系统中，需要主机之间进行状态复制，以保证每个主机达成一致的状态共识。而在异步系统中，主机之间可能出现故障，因此需要在默认不可靠的异步网络中定义容错协议，以确保各个主机达到安全可靠的状态共识。
共识算法其实就是一组规则，设置一组条件，筛选出具有代表性的节点。在区块链系统中，存在很多这样的筛选方案，如在公有链中的POW、Pos、DPOS等，而在不需要货币体系的许可链或私有链中，绝对信任的节点、高效的需求是公有链共识算法不能提供的，对于这样的区块链，传统的一致性共识算法成为首选，如PBFT、PAXOS、RAFT等。
目录
一、BFT（拜占庭容错技术）
二、PBFT（实用拜占庭容错算法）
三、PAXOS
四、Raft
五、POW（工作量证明）
六、POS（权益证明）
七、DPOS（委任权益证明）
八、Ripple
拜占庭弄错技术是一类分布式计算领域的容错技术。拜占庭假设是由于硬件错误、网络拥塞或中断以及遭到恶意攻击的原因，计算机和网络出现不可预测的行为。拜占庭容错用来处理这种异常行为，并满足所要解决问题的规范。
拜占庭容错系统是一个拥有n台节点的系统，整个系统对于每一个请求，满足以下条件：
1）所有非拜占庭节点使用相同的输入信息，产生同样的结果；
2）如果输入的信息正确，那么所有非拜占庭节点必须接收这个信息，并计算相应的结果。
拜占庭系统普遍采用的假设条件包括：
1）拜占庭节点的行为可以是任意的，拜占庭节点之间可以共谋；
2）节点之间的错误是不相关的；
3）节点之间通过异步网络连接，网络中的消息可能丢失、乱序并延时到达，但大部分协议假设消息在有限的时间里能传达到目的地；
4）服务器之间传递的信息，第三方可以嗅探到，但是不能篡改、伪造信息的内容和验证信息的完整性。
拜占庭容错由于其理论上的可行性而缺乏实用性，另外还需要额外的时钟同步机制支持，算法的复杂度也是随节点的增加而指数级增加。
实用拜占庭容错降低了拜占庭协议的运行复杂度，从指数级别降低到多项式级别。
PBFT是一种状态机副本复制算法，即服务作为状态机进行建模，状态机在分布式系统的不同节点进行副本复制。PBFT要求共同维护一个状态。需要运行三类基本协议，包括一致性协议、检查点协议和视图更换协议。
一致性协议。一致性协议至少包含若干个阶段：请求（request）、序号分配（pre-prepare）和响应（reply），可能包含相互交互（prepare），序号确认（commit）等阶段。
PBFT通信模式中，每个客户端的请求需要经过5个阶段。由于客户端不能从服务器端获得任何服务器运行状态的信息，PBFT中主节点是否发生错误只能由服务器监测。如果服务器在一段时间内都不能完成客户端的请求，则会触发视图更换协议。
整个协议的基本过程如下：
1）客户端发送请求，激活主节点的服务操作。
2）当主节点接收请求后，启动三阶段的协议以向各从节点广播请求。
［2.1］序号分配阶段，主节点给请求赋值一个序列号n，广播序号分配消息和客户端的请求消息m，并将构造PRE-PREPARE消息给各从节点；
［2.2］交互阶段，从节点接收PRE-PREPARE消息，向其他服务节点广播PREPARE消息；
［2.3］序号确认阶段，各节点对视图内的请求和次序进行验证后，广播COMMIT消息，执行收到的客户端的请求并给客户端以响应。
3）客户端等待来自不同节点的响应，若有m+1个响应相同，则该响应即为运算的结果。
PBFT一般适合有对强一致性有要求的私有链和联盟链，例如，在IBM主导的区块链超级账本项目中，PBFT是一个可选的共识协议。在Hyperledger的Fabric项目中，共识模块被设计成可插拔的模块，支持像PBFT、Raft等共识算法。
在有些分布式场景下，其假设条件不需要考虑拜占庭故障，而只是处理一般的死机故障。在这种情况下，采用Paxos等协议会更加高效。。PAXOS是一种基于消息传递且具有高度容错特性的一致性算法。
PAXOS中有三类角色Proposer、Acceptor及Learner，主要交互过程在Proposer和Acceptor之间。算法流程分为两个阶段：
phase1
a)proposer向网络内超过半数的acceptor发送prepare消息
b)acceptor正常情况下回复promise消息
phase2
a)在有足够多acceptor回复promise消息时，proposer发送accept消息
b)正常情况下acceptor回复accepted消息
流程图如图所示：
PAXOS协议用于微信PaxosStore中，每分钟调用Paxos协议过程数十亿次量级。
Paxos是Lamport设计的保持分布式系统一致性的协议。但由于Paxos非常复杂，比较难以理解，因此后来出现了各种不同的实现和变种。Raft是由Stanford提出的一种更易理解的一致性算法，意在取代目前广为使用的Paxos算法。
Raft最初是一个用于管理复制日志的共识算法，它是在非拜占庭故障下达成共识的强一致协议。Raft实现共识过程如下：首先选举一个leader，leader从客户端接收记账请求、完成记账操作、生成区块，并复制到其他记账节点。leader有完全的管理记账权利，例如，leader能够决定是否接受新的交易记录项而无需考虑其他的记账节点，leader可能失效或与其他节点失去联系，这时，重新选出新的leader。
在Raft中，每个节点会处于以下三种状态中的一种：
（1）follower：所有结点都以follower的状态开始。如果没收到leader消息则会变成candidate状态；
（2）candidate：会向其他结点“拉选票”，如果得到大部分的票则成为leader。这个过程就叫做Leader选举(LeaderElection)；
（3）leader：所有对系统的修改都会先经过leader。每个修改都会写一条日志(logentry)。leader收到修改请求后的过程如下：此过程叫做日志复制（LogReplication）
1）复制日志到所有follower结点
2）大部分结点响应时才提交日志
3）通知所有follower结点日志已提交
4）所有follower也提交日志
5）现在整个系统处于一致的状态
Raft阶段主要分为两个，首先是leader选举过程，然后在选举出来的leader基础上进行正常操作，比如日志复制、记账等。
（1）leader选举
当follower在选举时间内未收到leader的消息，则转换为candidate状态。在Raft系统中：
1）任何一个服务器都可以成为候选者candidate，只要它向其他服务器follower发出选举自己的请求。
2）如果其他服务器同意了，发出OK。如果在这个过程中，有一个follower宕机，没有收到请求选举的要求，此时候选者可以自己选自己，只要达到N/2+1的大多数票，候选人还是可以成为leader的。
3）这样这个候选者就成为了leader领导人，它可以向选民也就是follower发出指令，比如进行记账。
4）以后通过心跳消息进行记账的通知。
5）一旦这个leader崩溃了，那么follower中有一个成为候选者，并发出邀票选举。
6）follower同意后，其成为leader，继续承担记账等指导工作。
（2）日志复制
记账步骤如下所示：
1）假设leader已经选出，这时客户端发出增加一个日志的要求；
2）leader要求follower遵从他的指令，将这个新的日志内容追加到各自日志中；
3）大多数follower服务器将交易记录写入账本后，确认追加成功，发出确认成功信息；
4）在下一个心跳消息中，leader会通知所有follower更新确认的项目。
对于每个新的交易记录，重复上述过程。
在这一过程中，若发生网络通信故障，使得leader不能访问大多数follower了，那么leader只能正常更新它能访问的那些follower服务器。而大多数的服务器follower因为没有了leader，他们将重新选举一个候选者作为leader，然后这个leader作为代表与外界打交道，如果外界要求其添加新的交易记录，这个新的leader就按上述步骤通知大多数follower。当网络通信恢复，原先的leader就变成follower，在失联阶段，这个老leader的任何更新都不能算确认，必须全部回滚，接收新的leader的新的更新。
在去中心账本系统中，每个加入这个系统的节点都要保存一份完整的账本，但每个节点却不能同时记账，因为节点处于不同的环境，接收不同的信息，如果同时记账，必然导致账本的不一致。因此通过同时来决定那个节点拥有记账权。
在比特币系统中，大约每10分钟进行一轮算力竞赛，竞赛的胜利者，就获得一次记账的权力，并向其他节点同步新增账本信息。
PoW系统的主要特征是计算的不对称性。工作端要做一定难度的工作才能得出一个结果，而验证方却很容易通过结果来检查工作端是不是做了相应的工作。该工作量的要求是，在某个字符串后面连接一个称为nonce的整数值串，对连接后的字符串进行SHA256哈希运算，如果得到的哈希结果（以十六进制的形式表示）是以若干个0开头的，则验证通过。
比特币网络中任何一个节点，如果想生成一个新的区块并写入区块链，必须解出比特币网络出的PoW问题。关键的3个要素是工作量证明函数、区块及难度值。工作量证明函数是这道题的计算方法，区块决定了这道题的输入数据，难度值决定了这道题所需要的计算量。
（1）工作量证明函数就是<ustyle="box-sizing:border-box;">SHA256</u>
比特币的区块由区块头及该区块所包含的交易列表组成。拥有80字节固定长度的区块头，就是用于比特币工作量证明的输入字符串。
（2）难度的调整是在每个完整节点中独立自动发生的。每2016个区块，所有节点都会按统一的公式自动调整难度。如果区块产生的速率比10分钟快则增加难度，比10分钟慢则降低难度。
公式可以总结为：新难度值=旧难度值×（过去2016个区块花费时长/20160分钟）
工作量证明需要有一个目标值。比特币工作量证明的目标值（Target）的计算公式：目标值=最大目标值/难度值
其中最大目标值为一个恒定值：
0x00000000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
目标值的大小与难度值成反比。比特币工作量证明的达成就是矿工计算出来的区块哈希值必须小于目标值。
（3）PoW能否解决拜占庭将军问题
比特币的PoW共识算法是一种概率性的拜占庭协议（ProbabilisticBA）
当不诚实的算力小于网络总算力的50%时，同时挖矿难度比较高（在大约10分钟出一个区块情况下）比特币网络达到一致性的概念会随确认区块的数目增多而呈指数型增加。但当不诚实算力具一定规模，甚至不用接近50%的时候，比特币的共识算法并不能保证正确性，也就是，不能保证大多数的区块由诚实节点来提供。
比特币的共识算法不适合于私有链和联盟链。其原因首先是它是一个最终一致性共识算法，不是一个强一致性共识算法。第二个原因是其共识效率低。
扩展知识：一致性
严格一致性，是在系统不发生任何故障，而且所有节点之间的通信无需任何时间这种理想的条件下，才能达到。这个时候整个系统就等价于一台机器了。在现实中，是不可能达到的。
强一致性，当分布式系统中更新操作完成之后，任何多个进程或线程，访问系统都会获得最新的值。
弱一致性，是指系统并不保证后续进程或线程的访问都会返回最新的更新的值。系统在数据成功写入之后，不承诺立即可以读到最新写入的值，也不会具体承诺多久读到。但是会尽可能保证在某个时间级别（秒级）之后。可以让数据达到一致性状态。
最终一致性是弱一致性的特定形式。系统保证在没有后续更新的前提下，系统最终返回上一次更新操作的值。也就是说，如果经过一段时间后要求能访问到更新后的数据，则是最终一致性。
在股权证明PoS模式下，有一个名词叫币龄，每个币每天产生1币龄，比如你持有100个币，总共持有了30天，那么，此时你的币龄就为3000，这个时候，如果你发现了一个PoS区块，你的币龄就会被清空为0。你每被清空365币龄，你将会从区块中获得0.05个币的利息(假定利息可理解为年利率5%)，那么在这个案例中，利息=3000*5%/365=0.41个币，这下就很有意思了，持币有利息。
点点币（Peercoin）是首先采用权益证明的货币。，点点币的权益证明机制结合了随机化与币龄的概念，未使用至少30天的币可以参与竞争下一区块，越久和越大的币集有更大的可能去签名下一区块。一旦币的权益被用于签名一个区块，则币龄将清为零，这样必须等待至少30日才能签署另一区块。
PoS机制虽然考虑到了PoW的不足，但依据权益结余来选择，会导致首富账户的权力更大，有可能支配记账权。股份授权证明机制（DelegatedProofofStake，DPoS）的出现正是基于解决PoW机制和PoS机制的这类不足。
比特股（Bitshare）是一类采用DPoS机制的密码货币。它的原理是，让每一个持有比特股的人进行投票，由此产生101位代表,我们可以将其理解为101个超级节点或者矿池，而这101个超级节点彼此的权利是完全相等的。如果代表不能履行他们的职责（当轮到他们时，没能生成区块），他们会被除名，网络会选出新的超级节点来取代他们。
比特股引入了见证人这个概念，见证人可以生成区块，每一个持有比特股的人都可以投票选举见证人。得到总同意票数中的前N个（N通常定义为101）候选者可以当选为见证人，当选见证人的个数（N）需满足：至少一半的参与投票者相信N已经充分地去中心化。
见证人的候选名单每个维护周期（1天）更新一次。见证人然后随机排列，每个见证人按序有2秒的权限时间生成区块，若见证人在给定的时间片不能生成区块，区块生成权限交给下一个时间片对应的见证人。
比特股还设计了另外一类竞选，代表竞选。选出的代表拥有提出改变网络参数的特权，包括交易费用、区块大小、见证人费用和区块区间。若大多数代表同意所提出的改变，持股人有两周的审查期，这期间可以罢免代表并废止所提出的改变。这一设计确保代表技术上没有直接修改参数的权利以及所有的网络参数的改变最终需得到持股人的同意。
Ripple（瑞波）是一种基于互联网的开源支付协议，在Ripple的网络中，交易由客户端（应用）发起，经过追踪节点（trackingnode）或验证节点（validatingnode）把交易广播到整个网络中。
追踪节点的主要功能是分发交易信息以及响应客户端的账本请求。验证节点除包含追踪节点的所有功能外，还能够通过共识协议，在账本中增加新的账本实例数据。
Ripple的共识达成发生在验证节点之间，每个验证节点都预先配置了一份可信任节点名单，称为UNL（UniqueNodeList）。在名单上的节点可对交易达成进行投票。每隔几秒，Ripple网络将进行如下共识过程：
1）每个验证节点会不断收到从网络发送过来的交易，通过与本地账本数据验证后，不合法的交易直接丢弃，合法的交易将汇总成交易候选集（candidateset）。交易候选集里面还包括之前共识过程无法确认而遗留下来的交易。
2）每个验证节点把自己的交易候选集作为提案发送给其他验证节点。
3）验证节点在收到其他节点发来的提案后，如果不是来自UNL上的节点，则忽略该提案；如果是来自UNL上的节点，就会对比提案中的交易和本地的交易候选集，如果有相同的交易，该交易就获得一票。在一定时间内，当交易获得超过50%的票数时，则该交易进入下一轮。没有超过50%的交易，将留待下一次共识过程去确认。
4）验证节点把超过50%票数的交易作为提案发给其他节点，同时提高所需票数的阈值到60%，重复步骤3）、步骤4），直到阈值达到80%。
5）验证节点把经过80%UNL节点确认的交易正式写入本地的账本数据中，称为最后关闭账本（LastClosedLedger），即账本最后（最新）的状态。
在Ripple的共识算法中，参与投票节点的身份是事先知道的。该共识算法只适合于权限链（Permissionedchain）的场景。Ripple共识算法的拜占庭容错（BFT）能力为（n-1）/5，即可以容忍整个网络中20%的节点出现拜占庭错误而不影响正确的共识。
在区块链网络中，由于应用场景的不同，所设计的目标各异，不同的区块链系统采用了不同的共识算法。一般来说，在私有链和联盟链情况下，对一致性、正确性有很强的要求。一般来说要采用强一致性的共识算法。而在公有链情况下，对一致性和正确性通常没法做到百分之百，通常采用最终一致性（EventualConsistency）的共识算法。
共识算法的选择与应用场景高度相关，可信环境使用paxos或者raft，带许可的联盟可使用pbft，非许可链可以是pow，pos，ripple共识等，根据对手方信任度分级，自由选择共识机制。
全异步算法的介绍就聊到这里吧，感谢你花时间阅读本站内容，更多关于全异步算法是什么、全异步算法的信息别忘了在本站进行查找哦。
Tags：