瑞波Ripple概念解析-共识Consensus（官方文档不完全翻译）

共识

由Dave Cohen，David Schwartz和Arthur Britto撰写。

本文提供了XRP账本的高层次概述，其存储的信息以及交易如何导致账本更改。

在XRP 账本上构建应用程序时，理解此过程非常重要，以免让XRP 账本 API及其影响的行为感到意外。

警告：事务不会立即应用于XRP账本; 需要一段时间才能应用交易的效果。在此过程中，rippledAPI可能会返回不应被误认为交易的最终不变结果的临时结果。不可变的结果只能通过查看经过验证的账本来确定。

介绍

点对点XRP账本网络提供全球共享账本，为应用程序提供有关其内容状态的权威信息。此状态信息包括：

• 每个帐户的设置
• 账户之间的余额（信任线）
• 在分布式交易所的发行
• 网络设置，如交易成本和储备金额
• 时间戳

有关账本版本中包含哪些数据的完整技术说明，请参阅账本格式参考。

图1：XRP账本元素

XRP账本每隔几秒就有一个新的账本版本。之前的账本版本构成账本历史记录。即使是最近的验证账本也是历史的一部分，因为它代表了不久之前的网络状态。目前，网络正在评估可能在下一个账本版本中应用和完成的交易。

图2：XRP账本序列和历史记录

账本实例由其序列号 ¹标识，也称为账本索引。账本按增量编号。如果最后验证的账本是N，则前一个是N-1，下一个是N + 1。N + 1账本是通过将一组交易应用于账本N.

用户级别更改为账本是交易的结果。交易的例子包括付款，账户设置或信任线的更改以及交易提议。每项交易授权对账本进行更改，并由账户所有者进行加密签名。交易是授权对帐户进行更改的唯一方式。

账本实例还包含一组关于这些交易的交易和元数据。这些交易是应用于先前账本创建新实例的交易。元数据精确地记录了交易对账本的影响。

图3：应用于账本版本的交易

包含在账本实例中的一组交易记录在该账本中，并允许XRP账本历史的可审计性。如果账本N + 1中的账户余额不同于账本N中的账户余额，则账本N + 1包含负责变更的交易。

出现在经过验证的账本中的交易可能已成功更改账本，或者没有执行请求操作就已经被处理。成功的交易具有tesSUCCESS 结果代码，该结果代码指示所请求的更改应用于账本，并收取费用。账本中的其他交易具有tec分类结果代码，这些代码表示仅支付费用并且不执行其他更改的交易²。

tec类交易包含在账本中，因为它们在支付费用时会更改帐户余额。

除了tes和tec分类结果代码之外，还有ter，tef和tem类别代码。后三者表示API调用返回的临时失败。只有tes和tec代码出现在账本中。

在使用rippledAPI时，应用程序必须区分拟纳入账本的候选交易与包含在验证账本中的经验证交易。只有在经过验证的账本中找到的交易结果是不可变的。候选交易可能会也可能不会被包含在经过验证的账本中。

重要提示：根据候选交易³，一些rippledAPI提供临时结果³。申请不应依赖临时结果来确定交易的最终结果。确信事务最终成功的唯一方法是检查事务的状态，直到它处于验证账本并且结果代码为tesSUCCESS。如果该交易与任何其他结果代码一起处于验证账本中，则该交易记录已失败。如果交易中指定的账本Last账本Sequence已经过验证，但交易没有出现在该账本或其之前的任何账本中，那么该交易失败并且永远不会出现在任何账本中。结果仅限于出现在验证账本中的交易的最终结果，否则将因此而无法出现Last账本Sequence 如本文件稍后解释的那样。

XRP账本协议 - 共识和验证

点对点XRP账本网络由许多分布式服务器组成，这些服务器称为节点，用于接受和处理事务。客户端应用程序签署并发送事务到节点，这些节点将这些候选事务转发到整个网络进行处理 客户端应用程序的例子包括移动和网络钱包，金融机构网关和电子交易平台。

图4：XRP账本协议中的参与者

接收，中继和处理事务的节点可能是跟踪节点或验证节点。跟踪节点的主要功能包括分配来自客户端的交易和响应有关账本的查询。验证节点执行与跟踪节点相同的功能，并有助于推进账本序列⁴。

在接受客户端应用程序提交的事务时，每个跟踪节点都使用上次验证的账本作为起点。接受的交易是候选人。节点将他们的候选交易传递给他们的同伴，允许候选交易在整个网络中传播。理想情况下，每个候选交易对于所有节点都是已知的，允许每个候选交易考虑应用于上一个验证账本的同一组交易。但是，事务处理需要时间来传播，所以这些节点在任何时候都不会与同一组候选事务一起工作。为了解决这个问题，XRP账本户使用称为共识的流程来确保处理相同的交易，并验证账本在整个对等XRP账本网络中保持一致。

共识

网络上的节点共享有关候选事务的信息。通过共识过程，验证节点同意候选交易的特定子集将被考虑用于下一个账本。共识是一个迭代的过程，其中节点传递提议或候选事务集合。节点沟通和更新提案，直到绝大多数节点对同一组候选交易达成一致为止。

在达成共识的过程中，每个节点都会评估来自特定的一组节点的提议，这些节点称为被选的见证人（ Chosen Validators ） ⁶ 。选择的见证人代表网络的一个子集，从全部节点选取的，它是 “ 可信 ” 的，不会串谋欺骗评估提案的节点。这种 “ 信任 ” 的定义并不要求每个人选择的验证者都是可信的。然而，验证者的选择是基于他们不会在中继网络的过程中合谋伪造数据 ⁷ 的期望的。

图5：验证者提出事务集 - 在共识开始时，节点使用不同的事务集。提案的几轮决定哪些交易适用于账本，哪些交易必须等待稍后的一轮协商一致。

未被列入议定提案的候选交易仍为候选交易。他们可能会在下一轮的共识中再次考虑。

图6：通过共识，节点就交易集达成一致 - 节点将商定的一组交易（以绿色显示）应用于最后验证的账本。可能会在下一轮达成一致（红色）的交易。

通常情况下，一轮未达成共识的交易有可能在下一轮中达成共识。但是，在某些情况下，交易可能无法无限期地达成共识。比如一种情况，网络将基本费用增加到高于交易提供的价值，但如果费用在未来某个时候降低，交易就可能会成功。

设置LastLedgerSequence字段可以使交易如果不在合理的时间范围内执行使交易失效的机制。应用程序应该为每个交易包含LastLedgerSequence这个参数。这可以确保事务在指定的账本序列号之前或之前成功或失败，从而限制应用程序在获取确定的事务结果之前必须等待的时间量。有关更多信息，请参阅可靠事务提交。

验证

当一轮协商一致完成后，每个节点通过将共识交易集中的候选交易应用于上一个验证的账本，计算新的账本。

图7：网络节点对已验证账本的处理 - 每个跟踪节点将商定的交易应用于上一个经过验证的账本。验证节点将其结果发送到整个网络。

验证节点计算账本的新版本并将其结果转发给网络，每个账户都发送基于共识期间提出的候选交易计算的账本的签名散列。这些经过签名的哈希，称为验证，允许每个节点将其计算的账本与其对等方的账本进行比较。

图8：当绝大多数节点都认同计算结果时账本就是已验证的 - 节点将其计算的账本与从所选见证人收到的散列值进行比较。如果不一致，节点必须重新计算或检索正确的账本。

当绝大多数的同伴签署并广播相同的验证散列⁸时，网络的节点会识别账本实例为有效。展望未来，交易将应用于此序列号为N + 1的更新且现已验证的账本。

在节点处于少数情况下，计算了与其对等方不同的账本时，该节点忽略其计算的账本⁹。它会重新计算正确的账本，或根据需要检索正确的账本。

如果网络未能就验证达成绝大多数的一致意见，这意味着交易量过高或网络延迟太大，无法形成一致的提案。在这种情况下，节点重复共识过程。随着协商一致开始，随着时间的推移，大多数节点越来越有可能收到同一组候选交易，因为每次协商一致都会减少分歧。 XRP 账本动态调整 交易成本 和等待达成共识的时间以响应这些条件。

图9：网络识别新的验证账本版本 - 在一轮共识流程结束时，节点拥有更新的验证账本。

一旦他们中的绝大多数就验证问题达成共识，这些节点将使用新的经过验证的账本，序列号为N + 1。共识和验证过程不断重复¹⁰，对上一轮未包括的候选交易以及同时提交的新交易进行共识。

关键要点

提交给XRP账本的交易不会即时处理。一段时间内，每笔交易都是候选人。

单个交易的生命周期如下所示：

• 交易是由帐户所有者创建并签署的。
• 交易提交给网络。
  • 形成不良的交易可能会立即被拒绝。
  • 良好的交易可能暂时成功，然后失败。
  • 良好的交易可能暂时失败，然后成功。
• 在达成共识的过程中，交易包含在账本中。
  • 成功达成共识的结果是经过验证的账本。
  • 如果一轮协商一致失败，共识过程将重复，直到成功。
• 经过验证的账本包括交易及其对账本状态的影响。

应用程序只应依赖经过验证的账本中的信息，而不是候选交易的临时结果。一些rippledAPI最初会返回交易的临时结果。只有当该交易包含在经过验证的账本中，或者该交易包含LastLedgerSequence字段且未出现在具有该序列号或更低的任何验证账本中时，交易结果才是最终结果，不可变。

提交交易的应用程序的最佳做法包括：

• 使用LastLedgerSequence 参数确保事务以确定性和即时方式进行验证或失败。
• 检查经过验证的账本中的交易结果。
  • 在包含交易的账本被验证或LastLedgerSequence 通过之前，结果是临时的。
  • 交易结果代码是tesSUCCESS并且"validated": true最终是成功的，不可更改。
  • 交易结果代码是其他代码并且"validated": true最终是失败的，不可更改。
  • 直到经过验证的账本序号LastLedgerSequence，在任何经验证的账本中也未出现的交易，最终是失败的，不可更改。
    • 注意使用具有连续账本历史的节点来检测此情况¹¹。
  • 可能需要重复检查交易的状态，直至确认的LastLedgerSequence 账本被验证。

更多资源

• • 共识白皮书
  • 账本格式参考
  • Ripple共识视频
  • 可靠的交易提交

结束笔记

¹ - 账本实例也可以通过它的散列唯一标识，散列是其内容的数字指纹。

² - 与 tec结果代码的交易包含在账本中，而不执行所请求的操作。其基本原理是可以按顺序提交多个交易，其处理顺序由与账户相关的序列号确定（不要与账本序号混淆）。为了防止阻止后续交易的账户序列号，处理交易以消耗序列号。此外，分发给网络的交易必须要求费用以防止网络滥用。

³ - 例如，考虑Alice有$ 100的情况，并将其全部发送给Bob。如果应用程序首先提交该支付交易，则在检查Alice的余额后立即返回$ 0。该值基于候选交易的暂定结果。有些情况下，付款失败，爱丽丝的余额仍为100美元（或者由于其他交易，成为其他金额）。确切知道Alice向Bob支付成功的唯一方法是检查事务的状态，直到它处于验证账本中且结果代码为 tesSUCCESS。如果交易与任何其他结果代码一起处于验证账本中，则付款失败。

⁴ - 严格地说，验证节点是跟踪节点的一个子集。它们提供相同的功能，并额外创建“验证”。跟踪节点可以根据他们是否保留全部或部分账本历史来进一步分类。

⁵ - 交易承认交易的百分比低于阈值时，交易未能达成一致意见。每一轮都是一个迭代过程。在第一轮开始时，至少有50％的同行必须同意。达成协商一致意见的最后门槛是80％。这些具体的价值可能会发生变化

⁶ - 有时被称为唯一节点列表（UNL）。

⁷ - 如果对所有验证人提出的建议进行评估，而不仅仅是选择不勾结的验证人，则恶意攻击者可以腾出足够的验证节点形成共谋绝大多数，引入无效交易或忽略提案中的有效交易。所选择的验证者列表为Sybil攻击辩护。

⁸ - 截至2014年11月，绝大多数门槛要求至少有80％的同行必须同意账本进行验证。这恰好与一轮共识所要求的百分比相同。两个门槛都可能发生变化，不一定相同。

⁹ - 实际上，节点在接收来自所有同行的验证之前检测到它处于少数。它知道它何时从超过20％的同行接收到不匹配的验证，验证无法满足80％的阈值。此时，它可以开始重新计算账本。

¹⁰ - 实际上，在验证完成之前，通过同时启动新一轮的共识，XRP账本运行更加高效。

 ¹¹ -rippled即使没有完整的账本历史记录，服务器也可以响应API请求。服务中断或网络连接可能导致节点账本历史记录中的账本或间隔缺失。随着时间的推移，如果进行配置，rippled填补其历史上的空白。在测试缺失的交易时，重要的是从提交交易的时间开始直到LastLedgerSequence的连续完整账本节点进行验证。使用RPC server_state来确定哪些 complete_ledgers可用于特定节点。

总结：

见证人应改为验证节点。瑞波共识主要依赖于验证节点对候选交易达成共识，满足至少80%的投票，然后将共识集里的候选交易应用于最新账本以计算最新账本，并将最新账本进行分发。

每个验证节点都有个UNL节点列表，当这些列表中大多数节点发来了相同的Hash账本则更新已验证账本，否则重新计算账本或获取正确的账本。

所有交易应该设置LastLedgerSequence参数。

本文作者：architect.bian，欢迎收藏，转载请保留原文地址并保留版权声明！谢谢~
还没完！往下看！！！