详解瑞波程序中共识算法

瑞波共识协议(Ripple Consensus Protocol,RCP),使一组节点能够基于特殊节点列表达成共识。初始特殊节点列表就像一个俱乐部,要接纳一个新成员,必须由一定比例的该俱乐部会员投票通过。
  RCP机制的工作原理如下:

  1. 验证节点接收存储待验证交易。首先验证节点接收待验证交易,将其存储在本地;其次本轮共识过程中新到的交易需要等待,在下次共识时再确认。
  2. 活跃信任节点发送提议:首先,信任节点列表是验证池的一个子集,其信任节点来源于验证池;其次,参与共识过程的信任节点须出于活跃状态,验证节点与信任节点间存在保活机制,长期不活跃节点将被从信任节点列表删除;最后,信任节点根据自身掌握的交易双方额度、交易历史等信息对交易做出判断,并加入到提议中进行发送。
  3. 本验证节点检查收到的提议是否来自信任节点列表中的合法信任节点,如果是,则存储;如果不是,则丢弃。
  4. 验证节点根据提议确定认可交易列表的步骤如下:首先,令信任节点列表中活跃的信任节点个数为M(比如5个),本轮中交易认可阔值为N(百分比,比如50%),则每一个超过M*N个信任节点认可的交易将被本验证节点认可;其次,本验证节点生成认可交易列表。系统为验证节点设置一个计时器,如果计时器时间已到,本信任节点需要发送自己的认可交易列表。
  5. 账本共识达成的步骤如下:首先,本验证节点仍然在接收来自信任节点列表中信任节点的提议,并持续更新认可交易列表;其次,验证节点认可列表的生成并不代表最终账本的形成以及共识的达成,账本共识只有在每笔交易都获得至少超过一定阔值(比如80%)的信任节点列表认可才能达成。如果账本中每笔交易都获得至少超过一定阔值的信任节点列表认可,则共识达成,交易验证结束,否则继续上述过程。
  6. 共识过程结束后,已经形成最新的账本,现将上轮剩余的待确认交易以及新交易纳入待确认交易列表,开始新一轮共识过程。



  有两个事情需要共识算法:
    1. 账本中的事务集合.
    2. 账本的关闭时间.
  基本流程:
    1. 首先调用`startRound`使Node处于`Open` 阶段.  在这个阶段Node打开账本等待交易事务
    2. 不停地调用`timerEntry` 检查Node是否能关闭账本,一旦Node `Close` 账本,Node将进入 `Establish` 阶段,Node将分享或接收对等Node的提案(将被关闭账本中接收的提案)

    3. 在调用 `timerEntry`的后续期间, Node将决定是否在某个事务上和对等Node达成共识,进入一个 `Accept` 阶段,在这个期间,Node将用这个交易事务更新之前的账本从而产生一个新的关闭账本,一旦新的账本已经完成,Node将和网络其他Node分享这个有效账本,然后再进行一些登记的工作,接着再次调用`startRound` 进入下一轮循环周期

单个账本的共识阶段如下:

              "close"             "accept"
     open ------- > establish ---------> accepted
       |                     |                                |
       |---------------|                                |
                     "startRound"                     |
       |--------------------------------------|


当出现错误账本时的处理方法:

当我们进入提议或观察的轮询后,如果我们发现我们正在处理错误的先前Ledger,我们就进入wrongLedger类并试图获得正确的一个,
   一旦我们获得正确的Ledger,我们进入switchedLedger 模式,有可能Ledger又落后了,发现有新的更好Ledger,这样来回移动wrongledger和switchledger之间试图解决该问题。

     proposing               observing

         \                       /
          \---> wrongLedger <---/
                     ^
                     |
                     |
                     v
                switchedLedger

一致共识(consensus)

  1. 综述

协商是整个网络就同一总账(Ledger)达成一致的过程,这让所有人在同一账页(page)。

系统说明协商过程是如何运作的

白皮书(white paper) Ripple达成一致共识图解 视频 Ripple总账一致共识过程 Ripple达成一致性共识 1.1总账

总账是系统状态的快照。它包括每个人的余额和信托额度。总账被按照 哈希树(Hash Tree)结构排列,从而它可以被概括为单一的数字。

1.2不串通

我们选择“相信不会串通欺骗我们”的特定的验证者,而不是随机验证者。这远比“相信”一个人不撒谎的标准要宽松的多。

想象一下,我们认为Wile E. Coyote和Road-Runner是竞争对手。由于他们事实上长期处在斗争中,所以一般来说,他们不会串通起来,尤其是不会串通起来欺骗我们。如果他们都证实了某件事,那么这件事非常可能是真实的。这表明,当他们可能完全不可靠时,我们可以利用他们不会串通而欺骗我们的特点,从而得出某件事非常可能成真的结论。

1.3 唯一节点列表(Unique Node List)

验证者运行代表它们自己处理验证的Ripple节点。我们相信不会串通起来进行欺骗的验证者列表被称为我们的唯一节点列表(Unique Node List,简称UNL)。

为了更好地确认某事是真实的,我们向UNL中添加了更多的验证者。例如,我们添加了Itchy 和Scratchy。它们不具有百分百的可信度,但不太会串通起来欺骗我们。

1.4精选验证者

在现实世界关系中,人们应精选包括1000个验证者的UNL列表。他们应从5个不同大洲选择200个验证者。他么应选择具有不同利益的验证者:做市商、金融公司、非盈利机构、政党、宗教组织等。通过选择大量不可能说谎、不可能被迫成为一个组织及串通欺骗我们的有信誉度的派别,可以确认总账是准确的。

实际上,大多数人会使用由客户端提供的默认UNL。但软件允许他们选择特定的验证者。

1.5通用一致性

如果每个人选择了一套完全不相干的验证者,网络将不会达成一致共识,总账的特殊版本就是唯一正确的总账。但实际上,人们的UNL列表会重复。这种重复导致可靠的验证者达成同样的协商。

每个人可靠的系统用户都想让系统达成协商。验证者会选择其他验证者格外相信的,因为他们也想达成协商。基本上,所有可靠的系统用户合作保证协商是可以达成的且可维持的。当然同时,缺乏一致性共识是很容易发觉的。

1.6说谎者

如果有人不诚实,那么诚实的参与者将会注意到他们撒谎,并且不考虑他们今后的证明。也就是说,如果你撒谎一次,你就不会再有收益,网络在未来不会再考虑你说的话。

Ripple协议要求验证者在每次验证间隔在协商总账上签字。如果验证者忘记做这件事,是很容易被发觉的。同样,如果如果一个验证者签了总账而且是在有效交易不能实现的情况下签了总账,也是很容易被发觉的。

1.7人格分裂

有人说Sybil可能伪装成为一个百万节点。Sybil希望选择信任Sybil节点的人不串通,然后Sybil就能撒谎。Ripple不受这种类型的攻击的影响,因为人们避免选择匿名节点来防止这个问题。人们只选择实体作为非匿名或具有良好声誉的验证者。即便他们偶然选择了Sybil的一些节点,这些节点也不会成为主流,不会产生有意义的影响。

此外,除非你的行为很明显,没有什么途径能造成任何实际伤害。如果一个交易完全有效,而且比协商窗口先被发现,那就没有不给交易投yes的理由。如果一个交易集群被接受成为主流,就没有理由不证实交易集群形成的总账。我们可以预见的这个攻击带来的最糟糕的伤害是让网络瘫痪。如果这种情况真发生了,所有系统可靠用户都会判断是什么节点导致了这个问题并停止信任他们。目前,攻击者回到了起点。

1.8协商可扩展性

Ripple的协商进程只用一些验证者。当Ripple网络开始工作,就只有非常少的验证者了。然而,那些验证者对Ripple网络的成功有非常既定的兴趣。因此,他们非常不愿意串通其他验证者来欺骗某些人或破坏网络。一旦他们这样做了,他们就会被抓住,从此之后被忽视。

向网络中添加更多的验证者只能强化网络不会欺骗任何人的可信度。

1.9结论

通过信任验证者不串通来寻找协商是一种建立有效总账的简单而可靠的方式。因为,网络不是依赖工作证明,该协商过程很快,而且允许Ripple网络在数秒内证实总账。

2.技术说明

2.1综述

一致共识过程的目标是确保所有节点同意相同的总账。总账是在某个特殊时间点每个人余额和要约的即时性快照。你可以通过接管先前的总账及申请自那时起已经发生的所有交易来形成总账。因此,为了对现有总账取得一致意见,节点必须同意先前的总账及自那时发生的交易集群。

Ripple网络中每个参与者都有一个验证者列表。它也被称为独特节点表(UNL)。每个在线验证节点将看到所有的交易。所有节点会试图定期验证或关闭一个新总账。每个节点会显示它认为的交易集群应用到先前总账的内容。如果一个节点发现它的大部分UNL都支持一个交易集群,那么它就会转向这个新的交易集群。

这个过程是反复进行的。一个节点会建议一个特定的交易集群,如果它发现大部分UNL支持一个不同的集群,它会转向并建议这个由大多数支持的集群。在一定循环后,节点会集中于同一交易集群。交易集群被精选的内容是不相干的。所有之中最重要的是每个人都同意。一旦交易集群被选中,它就会被应用到先前的总账。这是一个确定的过程,从而每个人开始于同一先前总账,交易集群得到同一结果。

如果某个有效交易被投票移除正在关闭的总账且持续有效,它将被写入下一个关闭总账。新总账大约每五秒被关闭一次。所以你只需要等5-10秒,交易就可以被网络确认。

许多人想知道,既然每个节点有不同的UNL,那么这是否会导致总账有许多不同版本。只要UNL间有最小程度的内部连接,一致共识就会快速达成。这根本上是因为每个可靠节点的最初目标是实现一致共识。

此外,如果一致共识过程中很早宣布了一个交易且充分有效,那所有可靠节点会认为它应该进入下个集群。如果交易很晚被接受或者可能与另一交易有冲突,那么没有可靠节点会特别关注它是否进入一致性集群。如果交易实际上有效,那它无论如何都会进入下一个一致性过程,因为所有可靠节点都认为它该这样做。它们真正看重的是一致性。

2.2更多细节

一致共识发生在每个总账的多轮中。

参与算法的每个节点提出一个交易集(通过树根的单一哈希值)

节点获取它们信任的节点提出的所有交易集。(这意味着多亏树状结构,只在差异中有错误)

如果一个节点不了解一个交易,那它不会把交易放入任何提出的哈希树中,不会给交易投票。这让系统比较容易地处理符合。如果交易没有被足够多的验证者看到或处理,那么大多数会投否定票。剩余的会在一致共识过程中把投票转成否定,交易会被推迟。

基本原则是,如果你的UNL上,包括你自己,有50%的节点投票赞成一个交易,那你就收入了它。反之,则无法收入。几秒后,入口从50%升至60%,且持续上升(同意失败就是失败协议)。这保证了较长一段时间交易投票不会只在50%附近波动。

有两个需要理解的重要事项:1)任何合法交易,如果在本轮开始前被发现,可以得到绝对多数。2)任何出局而合法的交易会在下一个总账中被每个可靠节点投票通过。有一点例外的是在总账关闭时间恰好进来的交易。这种情况下,我们不管交易是否通过,结果都是“正确的”。它们都是正确的,因为交易会出现在这个总账或下个总账中。

现在这个被同意的交易集群只是一个候选集群。如果节点认为交易应进入总账,它们会投票赞成,但理论上它可能会在应用到总账上时失败。 如果两个相冲突的交易同时被赞成进入一个交易集群,这是没有关系的。申请交易的进程是确定性的,而且至多一个会成功。由于相冲突的交易不再有效,它将永远不会允许进入另一个集群。

恢复未能进入一致性集群的过程也是确定性的。所以,如果有两个相冲突的交易且没有一个占据多数,那将在下一次一致共识窗口中由大多数可靠节点选择,它将进入下个一致性交易集群。

为Ripple网络选定的时间方案被称为持续总账关闭(continuous ledger close)。

2.3规模扩展

这里有一些帮助扩展规模的事项。交易树完成同步的事实意味着你只需要发送小的更新。

你只需要一次检查一个交易。如果节点给你无效交易,你可以在重新连接时,通过不连接及要求工作证明来惩罚它。没有重要节点会发送给你无效交易。没有人会让可靠节点发送无效数据。

规则是只有你相信交易能索取费用才能推进这个交易。这防止网络因不能成功的交易而堵塞。

我们处理看起来是合法交易的DoS攻击的主要方式是提高交易费用。如果51%的网络要求特定的交易费用,那么如果你不付费的话,就不能达成一致性共识。

节点只是处理本地工作,称有人断开可能滥用的节点,要求边界滥用节点的工作证明,提高他们要求推进交易的费用,从而发送无效交易给他们。验证者还在验证中发布交易费用标准来在事件中施加反向压力,因此得到更多的可靠交易,甚至超出他们处理的能力。

如果验证者赶不上被投票赞成进入一致性集群的交易负荷,那它将转向发行局部验证。这让那些相信它的人知道,它不是从网络中被分离出来的(而且可能验证其他总账)。此外,验证者将提升交易费用,从而防止网络缩小为“超级节点”小集群,尽管这样会增加串通风险。

2.4迷你FAQ

2.4.1 假设33%的节点首先看到交易A,33%的节点看到交易B,34%的节点看到交易C,且这三个交易是相互冲突的,这种情况下会发生什么?

没有交易会被投票赞成,同时,具有确定性算法(deterministic algorithm)只会选择一个交易作为下一总账的候选。

2.4.2 收入总账交易的确定性算法是如何运作的?

基本上,它按最大效率原则 应用交易,直到没有新交易进入。交易可能是:通过,hard fail或soft fail 三种结果。如果交易通过了,它们就会被收录。如果是hard fail,交易就会失败。如果是soft fail,交易就会成为候选。

一旦交易进入,所有与之的冲突的其它交易都会hard fail。

现有算法首先是按哈希顺序,所有账户/队列顺序中反复soft fail。当没有新交易通过时,该运行过程结束。



阅读更多

更多精彩内容