本文主要是介绍Ripple结点和相关共识介绍及思考，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！
1. RPCA概述
目前，针对决拜占庭将军问题，已经有几种可行的解决方案，比如比特币与以太坊采用的POW算法，HyperLedger采用的PBFT算法。然而，在这种分布式支付系统中，由于节点间需要同步沟通，导致共识效率比较低。
在RPCA算法中，为了降低这种同步沟通的成本，使用了一种子网络内部互相信任，由这些内部信任的子网络构成大的网络的方案。这里子网络的信任成本非常低，可以被进一步降低为网络节点对于子网络内部其它节点的原子性选择。另外，为了维护全网节点数据的一致性，子网络之间需要的连接度不能小于一个阈值。
通过以上解决方案，RPCA实现了一种高性能，同时拥有较高拜占庭容错的算法。RPCA算法已经应用在Ripple共识协议中。
2. 要解决的问题
近些年，针对分布式共识系统的研究越来越多，研究的目标是实现一种高性能，低花费，同时去中心化的交易系统。在这类系统的研究过程中主要问题可归为三类：正确性、一致性、可用性。
正确性指的是分布式系统要能识别正常交易与欺诈交易。在中心化系统中，这个问题是通过机构之间的信任以及数字签名来保证交易确实是由某个机构发出来解决的。而在去中心化系统中，大家甚至都不认识对方，自然无法建立类似的信任关系，因此，必须找到一种替代方案来保证交易的正确性。
一致性指的是要在去中心化系统中保证能达成全局唯一的共识。与正确性不同的是，一个恶意用户也许不会发起欺诈交易，但是他可以通过同时发起多笔正确的交易来谋利。在区块链中，典型的例子是“双花”问题。双花问题就是一笔钱花两次，比如你拿着比特币，在A商店买了瓶水，在B商店买了包瓜子。两个商店几乎同时花，假设商店都不等交易确认。那么可能A或B商店最后有一家没有能收到币。那么就实现一次双花。 因此一致性问题可被归结为如何保证系统中只能有一个全局唯一识别的交易集的问题。
可用性在去中心化支付系统中一般指的是性能问题。假设一个系统既能保证正确性又能保证一致性，但是需要一年时间才能确认一笔交易 ，那很显然这个系统的可用性很低。另外，可用性的其它方面包括达成正确性与一致性需要的算力水平、为避免一个用户被欺诈所应用的算法复杂度等。
RPCA算法就能很好的解决以上三个问题。
3. RPCA中的基本概念
在讲算法之前，有一些基本概念需要了解：
服务节点，就是可以接收交易的区块链节点，包括验证节点与非验证节点两种，验证节点是指被其它节点加入到信任列表中的节点，可参与共识过程，非验证节点不参与共识过程。
区块，区块记录交易，在RPCA中有两种区块比较关键，一个是最新关闭的区块，也就是最新被共识过的区块，另一个是开放区块，开放区块是指当前正被共识的区块，当开放区块被共识过，也就成了新的最新关闭的区块。
UNL（Unique Node List）信任节点列表，每个服务节点都会维护一个信任节点列表，这里的信任并不是我们通常理解的信任，而是指我信任这个列表中的节点不会联合起来作弊。在共识过程中，我们只接受来自信任节点列表中节点的投票。在Ripple中，我们用在配置文件中加入其它验证节点的公钥的方式来指定UNL。
4.共识过程
Ripple网络每隔几秒就会产生一个新的区块，这个区块的产生过程就是所有网络节点RPCA共识的过程。假设共识过程是成功的，并且网络中没有分叉产生，那么新生成的区块就是全网唯一的。
RPCA对交易分两个阶段完成，第一阶段是达成交易集的共识，第二阶段是对新生成的区块进行提议，最终形成被共识过的区块。
达成交易集的共识分轮进行，在每一轮中进行下面的操作：
交易共识，形成交易集
1 每个节点在共识开始时尽可能多的收集所能收集到的需要共识的交易，并放到“候选集”里面；
2 每个节点对它信任节点列表中的 “候选集”做一个并集，并对每一个交易进行投票；
3 UNL中的服务节点交流交易的投票结果，达到一定投票比例的交易会进入到下一轮，达不到比例的交易要么被丢弃，要么进入到下一次共识过程的候选集中；
- 在最终轮中，所有投票超过80%的交易会被放到共识过的交易集中，这里的交易集与比特币类似，也是Merkle树的数据结构。
区块打包，再共识
形成交易集后，每个节点开始打包新的区块，打包区块的过程如下：
把当前区块号、共识交易集的Merkle树根Hash、父区块Hash、当前时间戳等内容放到一起，计算一个区块哈希
每个节点广播自己得出的区块哈希到它可见的节点，这里的可见节点不仅仅指可信列表中的节点，而是通过节点发现过程能发现的节点
节点收集到它所有可信列表中节点广播过来的区块哈希后，结合自己生成的区块哈希，对每个区块哈希计算一个比例，如果某一哈希的比例超过一个阈值（一般是80%），则认识这个哈希是共识通过的区块哈希。如果自己的哈希与之相同，则说明自己打包的区块得到了确认，是新的被共识过的区块，直接存到本地，并且更新状态。如果自己的哈希与共识通过的哈希不同，那就需要去某个区块哈希正确的节点索要新的区块信息，要到之后存储到本地并且更新当前状态。
如果上面没有对某一区块哈希超过设定的阈值，那么重新开始共识过程，直到满足条件。
至此，一个区块的共识过程结束，开启下一轮共识过程。
5.验证
前面第三节中我们提出了三个问题，正确性、一致性、可用性，下面我们挨个验证：
- 正确性：
RPCA中正确性的验证方式很简单，因为共识需要80%的阈值，那么只要UNL中有80%的诚实节点，就能达成共识，另外即使有超过20%的欺诈节点，也不能破坏正确性，因为欺诈节点也必须达到80%以上才能达成共识。无论欺诈节点还是诚实节点，达不到80%，都无法通过共识。
- 一致性：
RPCA中一致性是通过子网络与其它子网络的连通性来保证的，要保证区块链不分叉，必须确保每个子网络必须至少与整个网络节点中的20%保持连通性。达到20%连通性的前提下，如果一个子网络中得出的共识区块哈希与整个网络得出的不一致，也就无法达成80%的共识要求，也就无法产生分叉。
- 可用性
在每一轮投票过程中，节点会搜集它UNL中每个节点的响应时间，一直响应时间慢的节点将会被剔除出去，这样UNL就能保持一个较高的沟通效率。在高效沟通的前提下，RPCA算法能保证每3秒左右就能产生一个区块，Ripple官方给出的tps数据是1500。这样的性能基本能满足一般的生产需求。
6、UNL
配置文件中的可信任列表。
其实Ripple中的这个东西有好处也有诟病，好处是可以控制链的安全性，不管链上有多少不安全的作弊的验证节点，只要节点不信任你，作弊的就无计可施。坏处是，Ripple也因此被认为不是完全去中心化的网络，违背了初衷。
7、validation_quorum
validation_quorum是达成共识的门槛数量。
8、普通节点与验证节点
普通节点只转发交易，信任UNL中的信任节点，参与共识。
验证节点可以被普通节点信任，决定共识。
9、公钥和私钥
Ripple和Bitcoin采用椭圆曲线算法，生成一对公私钥，公钥可以根据私钥生成，但是反过来不行。私钥用来签名，公钥验证，具体后面专门讲解。
10、双花
Ripple和Bitcoin都面临的问题是双花和分叉。
双花通俗的说，就是一笔钱花两次，因为Ripple每提交一次交易先本地验证接受，然后提交网络共识，共识过程可能耗费3-8秒。
在共识未成功之前，可以以这笔钱再提交一次交易，本地由于前一次还没有共识通过，所以此次交易还是能验证通过，然后提交网络共识。
Ripple的解决方法看起来很简单，就是依据共识的时间先后，对于上述实例，第一次交易共识通过，第二次交易的共识就通不过。
11、分叉与防作弊
对于一个Ripple网络，假设有个普通节点的UNL中的验证节点都是作弊节点，或者作弊节点超过UNL总数量的2/3(具体怎么算的，后面专门介绍，涉及到数学证明过程)，那么对于这个普通节点的本地区块链就会分叉。
RIpple是如何防作弊的呢？当分叉后的作弊区块链又连接到网络上时，首先节点会广播区块信息，这是Ripple网络上的节点发现这个区块和自己的接不上或不一致，就把它标记为INSANE，意为我们都不信任你的区块，所以作弊的区块链无效。（具体如何标记，如何比对，后面专门介绍）。
12、共识
Ripple网络上的每笔交易发出时，先经过本地节点的验证（签名和交易合法性，签名是用公钥验证交易的签名，合法性主要是验证有没有这笔钱可以花费等），再提交网络参与共识。共识就是UNL中的信任节点参与投票的过程，后面会详细讲解。
博主QQ: 122209017
这篇关于Ripple结点和相关共识介绍及思考的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！
