| Finnciti傳送的是理財觀念；推廣的是扶平計劃；做到的是提升民生；得到的是財務自由;倡導的是說真話講實話不忽悠；不賣產品不找人；穩賺不賠！ |
|
|
Radar总账一致共识 过程 二維碼
这篇文章是Radar总账的高级概述，介绍关于Radar存储的信息及交易怎样导致总账变化。 当在Radar上建立应用时，理解这个进程是很重要的，从而不会被Radar API和它们对总账的影响吓到。 重点：交易不能即刻应用到Radar总账；使交易生效需要一些时间。在这个过程中，Radar API可能回送临时结果，不要把这个和交易最终不可变的结果相混淆。不可变的结果只能由经过验证的总账决定。 Radar网络提供全球共享的总账，把关于账户余额和要约的权威信息给应用。这些信息包括：
图表1：Radar总账元素 Radar网络每几秒钟就会产生一个新总账实例。之前的总账组成总账历史。甚至最新被验证的总账都是历史的一部分，因为它代表很短时间之前网络的状态。现在，网络正在评估可能在下个总账实例中被请求或结束的交易。 图表2：总账队列时间轴 总账实例只能通过它的序列号来识别，总账编号递增。如果最后一个被验证的总账是N，那之前的一个是N-1，之后的一个会是N+1。N+1总账是通过向N总账申请交易组而产生的。 总账用户级的变化是交易结果。交易例子包括支付，账户设置或信任线（TrustLine）的改变，交易要约等。每个交易授权总账修改，并由账户所有者加密签名。交易是授权账户变动的**方式。 一个总账实例还包括一个交易组和关于这些交易的元数据。在先前的总账中被应用的交易是用于创建新实例。元数据精确地记录了总账上交易的影响。 图表3：应用于总账队列的交易 一个总账实例中的交易组被记录在那个总账上，而且允许审核Radar总账历史。如果账户余额在N+1总账和N总账中不同，那么N+1总账包含的交易对修改负责。 出现在一个已验证总账中的交易可能会成功修改总账，或没有按要求活动而被处理。成功的交易会有tesSUCCESS结果代码，说明被要求的修改已应用于总账而且收取了费用。总账的其他交易有tec class结果代码，说明交易只收取了费用，没有其他修改。 总账包含tec class交易，因为当收取费用时，交易修改了账户余额。 除了tes class和tec class结果代码外，还有ter、tef和tem class代码。后三个说明出现由API calls返还的临时失败。这三种错误不会出现在已验证的总账中。 当使用Radar API时，应用必须区分针对总账内容的候选交易和已验证总账包含的已验证交易。只有已验证总账中的交易结果是不可变的。候选交易可能会或者永远不会被包含在已验证总账中。 重要提示：基于候选交易的Radar API提供临时结果。应用永远不要依赖临时结果来决定交易的最终结果。**知道交易最终成功的确切方式是检查交易状态，直至交易都在已验证总账中而且有tesSUCCESS结果代码。如果在已验证总账中的交易出现其他任何交易代码，那交易失败。如果被指定在交易最后总账队列（LastLedgerSequence）的总账已被验证，而在它之前任何总账中没有出现过这个交易，那交易失败而且永远不会出现在任何总账中。交易最终结果只能出现在已验证总账中，或永远不出现，这是由于LastLedgerSequence限制，这一点会在接下来的文件中详细解释。 Radar协议——一致共识和验证 Radar网络由许多分布式服务器组成，它们被称为节点，能接受和处理交易。客户端应用签名并发送交易给节点，它们在网络中转发交易进行处理。客户端应用的例子包括移动和网络钱包、金融机构的网关和电子交易平台。 图表4：Radar协议参与者 接收、转发和处理交易的节点可能是追踪节点或验证节点。追踪节点的基本功能包括分配来自客户端的交易并回应总账查询。验证节点和追踪节点有相同功能，另外还有助于推进总账队列。 当接受客户端应用提交的交易时，每个追踪节点使用最后一个被验证总账当作起始点。被接受的交易是候选。节点把候选交易转发给同等节点，允许候选交易在全网络进行传递。理想情况下，所有节点应了解每个候选交易，允许每个交易考虑同一交易组来应用于最终已验证的总账。然而，由于交易传递需要时间，节点不能一直和同一候选交易组工作。为了解决这个问题，Radar网络使用一致共识进程，确保同一交易能被处理，而且已验证总账能在网络中能相容。 一致共识 网络节点共享有关候选交易的信息。通过一致共识进程，验证节点就被认为是下一总账的特定候选交易组达成一致。一致共识是一个节点转发建议或候选交易组的反复性过程。节点传递和更新建议，直至绝大多数就同一候选交易组达成一致。 在一致共识中，每个节点评估来自特定同等节点组的提议，被称为被选择的验证者。当共同运行时，被选择的验证者代表一个被信任不会串通欺骗节点评估提议的子集。“信任”的定义不要求单个被选中的验证者被信任。更确切地说，选中这些验证者是希望它们不会串通伪造转发到网络的数据。 图表5：验证者提出交易组——在一致共识开端，节点和不同交易组工作。多轮提议决定哪些交易被应用到总账以及哪些交易需要等待后来的一致共识。 未被纳入达成一致的建议的候选交易保持不变。它们可能在下一轮一致共识中被考虑。 图表6：通过一致共识，节点就交易组达成一致——节点会把达成一致的交易组（绿色标识）应用于最后的已验证总账。未在该组的交易（红色标识）可能在下一轮达成一致。 通常来说，没有通过一致共识的交易会在下一轮成功。然而，在某种情况下，交易会无限期地不能实现一致共识。有一种情况是网络增加基础费用且比交易提供的高。如果未来交易费在某种程度上变低，交易很可能成功。 Radar提供防止交易无限期可行的途径，确保交易进程及时发生。应用需包含每个交易的LastLedgerSequence参数。这保证交易在规定的总账序列号（或之前）成功或失败，从而限制了在获取最后交易结果前的等待时间。 验证 在一轮一致共识结束后，每个节点把一致共识交易组中的候选交易应用至最后已验证总账，以此来计算一个新总账。 图表7：网络节点计算总账验证——每个追踪节点把达成一致的交易应用至最后已验证总账。验证节点将把结果传给整个网络。 验证节点计算一个新版本总账，把结果转发至网络，每次转发一个它计算出的基于候选交易的总账签名哈希。这些签名的哈希，被称为验证，允许每个节点和其它同等节点对比总账。 图表8：当绝大多数节点计算出同一结果，那总账就被验证——节点把它们计算的总账和从被选择验证者接收到的哈希作比较。如果不一致，节点必须再次计算或恢复正确的总账。 当绝大多数节点签名并传递同一验证哈希，那网络节点意识到总账实例已被验证。进一步说，交易将被应用到这个更新中及现在用序列号N+1的已验证总账。 在节点处于少数的情况下，节点计算出不同于其它的总账后，会忽视它计算出的总账。节点将重新计算正确的总账，或者需要的话恢复正确的总账。 如果网络没能实现绝大多数验证一致，这表明对于一致共识来说交易量太大或网络潜在因素太多以至于不能产生持续提议。这种情况下，节点重复一致共识。自一致性进程开始后，似乎越来越有可能大多数节点收到同一候选交易组，每轮一致共识减少不一致意见。Radar网络不断调整费用和等待一致共识的时间。 图表9：网络识别新的已验证总账——在一轮一致共识结束后，节点拥有一个更新的已验证总账。 一旦节点达到验证的绝大多数一致，它们就会跟新的已验证总账一起运作，序列号是N+1。考虑到不被收入最后一轮的候选交易和同时已经提交的新交易，一致共识和验证进程出现反复。 关键信息 提交至Radar网络的交易不是即时被处理的。在一段时间内，每个交易都是候选。 单一交易过程如下：
应用只能依赖已验证总账的信息，而不是候选交易的临时结果。某些Radar API最初向交易反馈临时结果。只有当交易被收入已验证总账，或交易包括LastLedgerSequence且不出现在任何具有该序列号及之前序列号的已验证总账中时，交易结果才成为不可变。 提交交易的应用的**实践包括：
|
