修订

修订系统提供了一种去中心化的XRP账本网络引入新功能而不会导致中断的方法。修订体系通过利用网络的核心共识流程，通过在变更生效之前显示持续的支持来批准任何变更。修正案通常需要两周内获得80％的支持才能生效。

修订版启用后，它将永久应用于所有账本版本之后的账本版本。除非您引入新的修正案，否则您不能禁用修正案。

有关已知修订的完整列表，其状态和ID，请参阅：已知修订。

背景

对交易处理的任何更改都可能导致服务器使用同一组交易构建不同的账本。如果某些验证节点（参与共识的rippled服务器）已升级到新版本的软件，而其他验证节点使用旧版本，则这可能会导致任何问题，从小的不便到完全中断。在较小的情况下，少数服务器花费更多时间和带宽获取实际的共识账本，因为他们无法使用他们已知的交易处理规则来构建它。在最糟糕的情况下，共识流程可能无法验证新账本版本，因为具有不同规则的服务器无法就要构建的账本达成共识。

修正解决了这个问题，因此只有足够的验证节点支持这些功能时才能启用新功能。

依赖XRP账本的用户和企业也可以使用修订提前通知交易处理中可能影响其业务的变更。但是，不影响交易处理或共识流程的 API更改不需要修订。

关于修正案

修正是一个全功能的功能或变化，等待对等网络启用，作为共识流程的一部分。一个rippled想要使用的修正服务器有两种模式代码：不支持该修正案（旧的行为），支持修正（新的行为）。

每项修订都有一个唯一的标识十六进制值和一个简称。简称目的是使人看起来容易辨认，并未在修改过程中使用。两台服务器可以支持相同的修订ID，同时使用不同的名称来描述它。修正案的名称不保证是唯一的。

按照惯例，Ripple的开发人员使用修订名称的SHA-512Half散列作为修订ID。

修改过程

每个第256个账本都称为“标志”账本。审批修正案的过程始于标志账本之前的账本版本。当rippled验证节点服务器发送该账本的验证消息时，这些服务器也会提交投票以支持特定的修改。如果验证节点不赞成修正案，这与对修正案投反对票相同。（费用投票也发生在标志账本的附近。）

标志账本本身没有特殊的内容。但是，在那段时间内，服务器会查看他们信任的验证节点的投票，并决定是否将EnableAmendment伪交易插入到以下账本中。EnableAmendment伪交易的标志显示服务器认为发生了什么：

该tfGotMajority标志意味着对修改的支持已经增加到至少80％的可信验证节点。
该tfLostMajority标志意味着对修正案的支持减少到不到80％的可信验证者。
没有标志的EnableAmendment伪交易意味着已经启用对修改的支持。（交易处理的变化适用于此后的所有分类帐。）

如果满足以下所有条件，则服务器仅插入伪交易以启用修改：

该修正案尚未启用。
以前的账本包含tfGotMajority启用标志的此修订的EnableAmendment伪交易。
有问题的上一个账本是当前账本的祖先。
有关问题的前一个账本有一个关闭时间，至少在最近的标志账本的结束时间的两周前。
对于此修正案，没有EnableAmendment伪交易，且tfLostMajority在tfGotMajority伪交易和当前账本之间的共识账本中启用了标志。

理论上，tfLostMajorityEnableAmendment伪交易可以与伪交易包含在同一账本中，以启用修改。在这种情况下，使用伪交易的tfLostMajority伪交易不起作用。

修改投票

每个版本rippled都包含已知修订列表和实施这些修订的代码。默认情况下，rippled支持已知修正并反对未知修正。rippled验证节点员的操作员可以配置他们的服务器，以明确支持或反对某些修改，即使这些修改未知其rippled版本。

要启用，修订必须持续两周至少80％的受信任验证节点支持。如果对修正案的支持低于可信验证节点的80％，修正案将被暂时拒绝。如果修订重新获得至少80％的可信验证者的支持，那么两周时间将重新开始。（如果验证者投票的方式不同，或者验证者信任度发生变化，则会发生这种情况。）修改可以在永久启用之前获得并失去大多数次数。修正案不能被永久拒绝，但如果新版本rippled在其已知的修改列表中没有修改，修改就不太可能启用。

与协商一致过程的所有方面一样，只有服从信任验证者发送投票的服务器才会考虑修正投票。目前，Ripple（该公司）建议仅信任Ripple运行的默认验证节点。就目前而言，仅仅信任这些验证节点就足以与Ripple协调发布新功能。

配置修改投票

您可以使用功能方法临时配置修订。要持久更改服务器对修正的支持，请更改服务器的rippled.cfg文件。

使用该[veto_amendments]节列出您不希望服务器投票支持的修改。每行应包含一个修订的唯一ID，可选的是修改的简称。例如：

[veto_amendments]

C1B8D934087225F509BEB5A8EC24447854713EE447D277F69545ABFA0E0FD490Tickets

DA1BD556B42D85EA9C84066D028D355B52416734D3283F85E216EA5DA6DB7E13SusPay

使用该[amendments]节列出要投票的修改。（即使你没有在这里列出它们，默认情况下服务器会投票支持它知道如何应用的所有修改。）每行应包含一个修订的唯一ID，后面可以选择修改的简称。例如：

[amendments]

4C97EBA926031A7CF7D7B36FDE3ED66DDA5421192D63DE53FFB46E43B9DC8373MultiSign

42426C4D4F1009EE67080A9B7965B44656D7714D104A72F9B4369F97ABF044EEFeeEscalation

修正案被封锁

如果在投票过程之后为网络启用了修订，则运行早期版本的服务器rippled不知道修改的服务器会因为不再了解网络规则而被“修改阻止”。被阻止的服务器：

无法确定账本的有效性
无法提交或处理交易
无法参与共识流程
无法对将来的修改进行投票

成为修正被阻止的是一项安全功能，用于保护依赖于XRP账本数据的应用程序。在应用新规则后，与其猜测并可能误解账本rippled，并不报告账本的状态，因为它不知道修订是如何工作的。

一个修正案rippled服务器配置为投票赞成或反对对服务器是否变为修正案阻止没有影响。一个rippled服务器尽可能始终遵循由网络其余部分启用的一套修订。如果已启用的修订未包含在编译为服务器源代码的修订定义中，换句话说，如果修订比服务器更新，则服务器仅被修改为阻止。

如果您的服务器遭到修改阻止，您必须升级到新版本才能与网络同步。

如何判断您的rippled服务器是否被修改被阻止

您提交交易时返回rippled的amendmentBlocked错误是您的服务器被修改阻止的第一个迹象之一。这是一个示例错误：amendmentBlocked

{

"result":{

"error":"amendmentBlocked",

"error_code":14,

"error_message":"Amendment blocked,need upgrade.",

"request":{

"command":"submit",

"tx_blob":"479H0KQ4LUUXIHL48WCVN0C9VD7HWSX0MG1UPYNXK6PI9HLGBU2U10K3HPFJSROFEG5VD749WDPHWSHXXO72BOSY2G8TWUDOJNLRTR9LTT8PSOB9NNZ485EY2RD9D80FLDFRBVMP1RKMELILD7I922D6TBCAZK30CSV6KDEDUMYABE0XB9EH8C4LE98LMU91I9ZV2APETJD4AYFEN0VNMIT1XQ122Y2OOXO45GJ737HHM5XX88RY7CXHVWJ5JJ7NYW6T1EEBW9UE0NLB2497YBP9V1XVAEK8JJYVRVW0L03ZDXFY8BBHP6UBU7ZNR0JU9GJQPNHG0DK86S4LLYDN0BTCF4KWV2J4DEB6DAX4BDLNPT87MM75G70DFE9W0R6HRNWCH0X075WHAXPSH7S3CSNXPPA6PDO6UA1RCCZOVZ99H7968Q37HACMD8EZ8SU81V4KNRXM46N520S4FVZNSJHA"

"status":"error"

}

以下rippled日志消息还表示您的服务器已被修改阻止：

2018-Feb-1219:38:30 账本Master:ERR One or moreunsupported amendments activated: server blocked.

如果您使用的是rippled版本0.80.0以上版本，则可以rippled使用该server_info命令验证您的服务器是否已被修正。在回应中，寻找result.info.amendment_blocked。如果amendment_blocked设置为true，则表示您的服务器已被修正。

示例JSON-RPC响应：

{

"result": {

"info": {

"amendment_blocked": true,

"build_version": "0.80.1",

"complete_账本s": "6658438-6658596",

"hostid": "ip-10-30-96-212.us-west-2.compute.internal",

"io_latency_ms": 1,

"last_close": {

"converge_time_s": 2,

"proposers": 10

...

"status": "success"

}

如果您的服务器未被修改阻止，则该amendment_blocked字段不会在响应中返回。

警告：即使您的服务器被修改阻止，rippled0.80.0之前的版本也不包含该amendment_blocked字段。

如何取消阻止修改被阻止的rippled服务器

升级到rippled支持导致您的服务器被修改阻止的修改的版本。Ripple建议您升级到最新rippled版本，以解除对服务器的阻止并使其再次与网络同步。

根据情况，您可以通过升级到rippled比最新版本旧的版本来（并且想要）解锁服务器。如果旧版本支持阻止您的rippled服务器的修改，则可以这样做。

警告：如果最新rippled版本提供安全性或其他紧急修复，应尽快升级到最新版本。

要确定您是否可以rippled通过升级到比最新版本更旧的版本来解锁服务器，请查明哪些功能会阻止您的服务器，然后查找rippled支持阻止功能的版本。

要找出哪些功能阻止了您的rippled服务器，请使用featureadmin命令。寻找具有"enabled": true和的功能"supported" : false。这些功能的值意味着修订目前在最新的分类帐中启用（必需），但您的服务器不知道如何支持或应用修订。

示例JSON-RPC响应：

{

"result": {

"features": {

"07D43DCE529B15A10827E5E04943B496762F9A88E3268269D69C44BE49E21104": {

"enabled": true,

"name": "Escrow",

"supported": true,

"vetoed": false

"08DE7D96082187F6E6578530258C77FAABABE4C20474BDB82F04B021F1A68647": {

"enabled": true,

"name": "PayChan",

"supported": true,

"vetoed": false

"1562511F573A19AE9BD103B5D6B9E01B3B46805AEC5D3C4805C902B514399146": {

"enabled": false,

"name": "CryptoConditions",

"supported": true,

"vetoed": false

"157D2D480E006395B76F948E3E07A45A05FE10230D88A7993C71F97AE4B1F2D1": {

"enabled": true,

"supported": false,

"vetoed": false

...

"67A34F2CF55BFC0F93AACD5B281413176FEE195269FA6D95219A2DF738671172": {

"enabled": true,

"supported": false,

"vetoed": false

...

"F64E1EABBE79D55B3BB82020516CEC2C582A98A6BFE20FBE9BB6A0D233418064": {

"enabled": true,

"supported": false,

"vetoed": false

}

"status": "success"

}

在这个例子中，与以下功能的冲突导致您的rippled服务器被修改阻止：

157D2D480E006395B76F948E3E07A45A05FE10230D88A7993C71F97AE4B1F2D1
67A34F2CF55BFC0F93AACD5B281413176FEE195269FA6D95219A2DF738671172
F64E1EABBE79D55B3BB82020516CEC2C582A98A6BFE20FBE9BB6A0D233418064

要查找哪个rippled版本支持这些功能，请参阅已知修订。

测试修正案

如果要查看rippled启用修订后的行为，在生产网络上启用修订之前，可以运行用户rippled的配置文件强制启用某个功能。这仅用于开发目的。

由于共识网络的其他成员可能没有启用该功能，因此在连接到生产网络时不应使用此功能。在强制启用功能的情况下进行测试时，应该rippled以独立模式运行。

要强制启用某个功能，[features]请在rippled.cfg文件中添加一节。在本节中，添加要启用的功能的简称，每行一个。例如：

[features]

MultiSign

TrustSetAuth

共识原则和规则

XRP账本是一种通用的支付系统，使用户能够像发送电子邮件一样无缝地跨境转移资金（包括法定货币，数字货币和其他形式的价值）。像其他数字货币（如比特币）一样，XRP账本可以通过去中心化的计算机网络实现点对点交易结算。与其他数字货币协议不同，XRP账本还允许用户以账本本币XRP以外的货币进行交易。此外，该技术能够近乎实时地结算（三至六秒），并且可以将每笔国际交易转换为网络中可用的最便宜的外汇买卖价差。

背景

机械学

核心内容是，XRP账本是一个共享数据库，用于记录账户，余额和交易资产报价等信息。被称为“交易”的签名指令会导致更改，如创建帐户，进行付款和交易资产。

作为一个加密系统，XRP账本的所有者由加密身份标识。交易由与这些身份匹配的加密签名进行授权。每个服务器根据相同的确定性已知规则处理每个交易。最终目标是网络中的每台服务器都拥有完全相同的账本状态副本，而无需单个中央机构仲裁交易。

双重支出问题

“双重支出”问题是操作任何支付系统的根本挑战。问题来自要求，当钱花在一个地方，它不能在另一个地方度过。更一般地说，当你有任何两个交易时，问题就会发生，即任何一个交易都是有效的，但不是两个交易。

假设Alice，Bob和Charlie正在使用支付系统，Alice的余额为10美元。为了使支付系统有用，爱丽丝必须能够将她的10美元送给鲍勃或查理。但是，如果Alice试图向Bob发送10美元并且同时向Charlie发送10美元，那么这就是双重花费问题的来源。

如果Alice可以向Charlie和Bob发送“相同”10美元，则支付系统不再有用。支付系统需要一种方式来选择哪个交易应该成功，哪个交易应该失败，以便所有参与者就发生哪些交易达成一致。这两项交易中的任何一项都有自己的同等效力。但是，支付系统中的不同参与者可能会对先前交易有不同的看法。

传统上，支付系统通过让中央机构跟踪和批准交易来解决双重支出问题。例如，银行决定根据发行人的可用余额清算支票，其中银行是唯一的托管人。在这样一个体系中，所有参与者都遵循中央当局的决定。

分布式账本技术，如XRP账簿，没有中央管理机构。他们必须以其他方式解决双重花费问题。

如何达成共识

简化问题

许多双重花费问题可以通过众所周知的规则来解决，例如禁止账户花费它没有的资金。事实上，双重支出问题可以减少到有序交易。

考虑Alice试图向Bob和Charlie发送相同的10美元的例子。如果向Bob支付款项是第一次，那么每个人都可以同意她有资金支付Bob。如果支付给查理的费用是第二，那么每个人都可以同意，她不能将这些资金发送给查理，因为这笔钱已经发给了鲍勃。

我们也可以通过决定性规则来排序交易。由于交易是数字信息的集合，因此计算机对它们排序是琐碎的。

这足以在没有中央机构的情况下解决双重支出问题，但是，在我们确定任何交易结果之前，我们必须先做好每一笔交易（以便我们可以对其进行分类）。显然，这是不切实际的。

如果我们可以将交易收集到小组并就这些小组达成一致，那么我们可以对该小组内的交易进行排序。只要每个参与者同意将哪些交易作为一个整体来处理，他们就可以使用确定性规则来解决双重支出问题，而无需中央当局。参与者根据已知规则对交易进行排序并以确定性方式应用它们。XRP账本正是以这种方式解决了双重支出问题。

XRP账本允许多个相冲突的交易在协议组中。这组交易按照确定性规则执行，因此根据排序规则成功的交易先到达第一个冲突交易第二个失败。

共识规则

达成共识的主要角色是让参与者在流程中就哪些交易作为一个整体进行处理以解决双重支出问题达成一致。这个协议比预期的要容易实现有四个原因：

如果没有理由交易不应该包含在这样一组交易中，所有诚实的参与者都同意将其包括在内。如果所有参与者都已经达成一致，那么共识就没有工作要做
如果有任何理由，交易不应该包含在这样一组交易中，所有诚实的参与者都愿意排除它。如果交易仍然有效，那么没有理由不将其包含在下一轮中，并且他们都应该同意将其包含在内。
参与者特别关心交易如何分组是非常罕见的。当每个人的优先重点都达成一致时，协议是最容易的，只有在存在分歧的利益时才会遇到挑战。
甚至可以使用确定性规则来形成分组，导致仅在边缘情况下不一致。例如，如果一轮中存在两个冲突交易，则可以使用确定性规则来确定下一轮中包含哪些交易。

每位参与者的首要任务是正确。他们必须首先执行规则，以确保没有任何违反共享账本的完整性。例如，一个没有正确签名的交易决不能被处理（即使其他参与者想要被处理）。然而，每位诚实参与者的第二优先事项是协议。可能的双重花费网络根本没有用处。每个诚实的参与者都认为它高于一切而非正确，这一事实促进了协议的实现。

重复共识

协商一致意见是试图就一组交易达成一致意见，以便对其进行处理。每一位希望这样做的参与者都会采取初步立场。这是他们看到的一组有效交易。

参与者然后“雪崩”达成共识：如果某项交易没有多数支持，参与者同意推迟交易。如果特定交易确实拥有多数支持，参与者同意包含交易。因此，轻微的多数迅速获得全力支持，轻微的少数群体迅速成为本轮的普遍拒绝。

为了防止拖延达到50％的共识，并减少可靠收敛所需的重叠，包含交易所需的阈值随着时间的推移而增加。最初，如果50％或更多的其他参与者同意，参与者仍然同意包括交易。如果参与者不同意，他们会增加这个门槛，首先增加到60％，然后再增加，直到所有有争议的交易从当前集合中删除。以这种方式移除的任何交易都推迟到下一个账本版本。

当一个参与者看到一个同意这组交易的超级大多数人接下来将被处理时，它宣布已达成共识。

共识可能失败

开发一个永远不能达成完美共识的共识算法是不现实的。要理解为什么，请考虑共识过程如何完成。在某些时候，每个参与者必须声明已达成共识，并且已知某些交易是该过程的结果。作为共识流程的结果，此声明将该参与者不可撤销地委托给某些特定的一组交易。

一些参与者必须首先做到这一点，否则参与者永远不会这样做，他们永远不会达成共识。现在，请考虑首先做到这一点的参与者。当这个参与者决定共识完成时，其他参与者还没有做出这个决定。如果他们不能从他们的观点来改变商定的集合，他们已经决定完成共识。所以他们必须仍然能够改变他们同意的设置。

换句话说，为了达成一致的过程，一些参与者必须声明，即使所有其他参与者在理论上仍然能够改变商定的交易集合，已经就一系列交易达成了一致意见。

想象一下，一个房间里的一群人试图认同他们应该用哪个门退出。无论参与者讨论多少，在某个时刻，必须有人成为第一个走出门外的人，尽管这个人背后的人仍然可以改变主意并通过其他门离开。

这种失败的可能性可能非常低，但不能降为零。工程上的权衡使得这个概率下降到千分之一以下使得共识明显变慢，并且不能容忍网络和端点故障。

XRP账簿如何处理共识失败

在协商一致结束后，每个参与者都应用他们认为已经同意的一组交易。这导致构建他们认为账本的下一个状态应该是什么。

也是验证者的参与者然后发布该下一个账本的加密指纹。我们称这个指纹为“验证投票”。如果协商一致成功，绝大多数诚实的验证者应该发布相同的指纹。

参与者然后收集这些验证票。从有效的投票中，他们可以确定先前的协商一致是否导致绝大多数参与者同意一组交易。

然后参与者按照概率顺序发现自己处于三种情况之一：

他们建立了同意的绝大多数账簿。在这种情况下，他们可以认为该账本已经完全验证并依赖于其内容。
他们建立了一个不同于大多数人认同的账本。在这种情况下，他们必须建立并接受绝大多数的账本。这通常表明他们早期宣布达成共识，其后许多其他参与者也发生了变化。他们必须“跳跃”到超级大多数账本才能恢复运作。
收到的验证中没有绝对多数。在这种情况下，先前的共识回合被浪费了，并且在任何账本可以被验证之前必须发生新一轮。

当然，情况1是最常见的。案例2对网络没有任何损害。一小部分参与者甚至可能会陷入每一轮的情况2，并且网络将毫无问题地工作。即使那些参与者也可以认识到他们并没有像超级多数人那样建立同样的账本，所以他们知道不要把他们的结果报告为最终结果，直到他们与超级多数人达成一致为止。

案例3导致网络在几秒钟内失去了它可能取得进展的情况，但是非常罕见。在这种情况下，下一轮达成一致意见的可能性大大降低，因为意见分歧在协商一致的过程中得到解决，只有余下的分歧才能导致失败。

在极少数情况下，整个网络几秒钟内未能取得进展。作为交换，平均交易确认时间很少。

哲学

可靠性的一种形式是即使在一些组件失败，一些参与者是恶意的情况下系统也能够提供结果的能力等等。虽然这很重要，但在加密支付系统中还有另一种形式的可靠性 - 系统产生可靠结果的能力。也就是说，当系统向我们报告结果可靠时，我们应该能够依靠这一结果。

然而，真实世界的系统面临着两种可靠性都可能受到损害的运行条件。这些包括硬件故障，通信故障，甚至是不诚实的参与者。XRP 账本设计理念的一部分是检测结果可靠性受损的情况并报告，而不是提供一定不能依赖的结果。

XRP 账本的一致性算法为工作系统证明提供了一个强有力的替代方案，而无需耗费计算资源。拜占庭的失败是可能的，而且确实发生，但后果只是轻微的延误。在所有情况下，只有在实际情况下，XRP 账本的一致性算法才会报告结果的可靠性。

费用投票

验证节点可以对基本交易成本以及储备金要求进行投票。如果验证节点的配置中的首选项与网络的当前设置不同，验证节点会定期向网络表示其首选项。如果验证节点的法定人数同意更改，他们可以应用此后生效的更改。验证节点员可能会出于各种原因来执行此操作，尤其是要适应XRP值的长期变化。

rippled验证节点的操作员可以[voting]在rippled.cfg文件的节中设置他们对交易成本和预留需求的偏好。

警告：如果需求不充分（如果采用可信验证节点的共识），可能会使XRP分类帐对等网络遭受拒绝服务攻击。

您可以设置的参数如下所示：

参数	描述	推荐值
reference_fee	XRP，单位drop，必须销毁数量，最便宜的交易费用。（1 XRP = 1百万滴）。实际交易成本是此值的倍数，根据各个服务器的负载进行动态扩展。	10 （0.00001 XRP）
account_reserve	账户必须有预留的最小XRP drop。这是可以发送给账户中新账户的最小金额。	20000000 （20 XRP）
owner_reserve	XRP，单位drop，即地址必须为其持有的每个对象锁定的金额。	5000000 （5 XRP）

投票过程

每个第256个账本都称为“标志”账本。（标志账本的定义使得账本_index 模数 256等于0）。在标志账本紧前面的账本中，每个帐户储备金或交易成本偏好与当前网络设置不同的验证节点在分类帐验证的同时分发“投票”消息，表明验证者喜欢的值。

在标志帐本本身中，没有任何反应，但验证节点收到并记下他们信任的其他验证节点的投票。

在计算其他验证节点的投票数后，每位验证节点都会尝试在其自己的偏好和其信任的大多数验证节点的偏好之间妥协。（例如，如果一个验证节点想将最小交易成本从10提高到100，但大多数验证节点只是想将其从10提高到20，那么验证节点就会根据更改将成本提高到20.但是，验证节点永远不会落在低于10或高于100的值上。）如果妥协是可能的，验证节点将插入一个SetFee伪交易纳入其关于标志账本的账本的提案。其他需要相同更改的验证节点将相同的SetFee伪交易插入到他们对相同账本的提案中。（其偏好与现有网络设置相匹配的验证节点什么都不做）。如果SetFee伪交易在共识过程中存在，以包含在验证分类帐中，则由SetFee伪交易表示的新交易成本和保留设置将开始生效以下账本。

简而言之：

Flag ledger-1：验证节点提交投票。
Flag ledger：验证节点会计票并决定包含哪些SetFee（如果有）。
Flag ledger+1：验证节点将SetFee伪交易插入其建议的账本中。
Flag ledger+2：如果SetFee psuedotransaction达成了共识，则新设置会生效。

最大费用值

费用的最大可能值受存储在FeeSettings分类帐对象中的内部数据类型的限制。这些值如下所示：

参数	最大值（下降）	最大值（XRP）
reference_fee	2 ** 64	（比以往更多的XRP。）
account_reserve	2 ^ 32drop	大约4294 XRP
owner_reserve	2 ^ 32drop	大约4294 XRP

共识研究

Ripple研究XRP 账本共识协议的理论和实际限制，并探讨同一空间中的其他想法。下表列出了由Ripple发布的学术文章：

日期	标题	作者	概要
2018年2月20日	Cobalt：开放网络中的BFT治理	MacBrough	引入了一种名为Cobalt的新型原子广播算法，可在共识UNL中提供更大的灵活性。
2018年2月20日	XRP账本共识协议分析	Chase，MacBrough	XRP 账本一致性算法及其安全性和活性属性的详细和更新分析。
2014	ripple协议共识算法	施瓦茨，杨斯，布里托	介绍XRP账本背后的共识算法。

并行网络（测试网络）

大多数时候，我们将XRP账本描述为一个单一的实体 - 而且大多数情况都是如此。有一个生产XRP账本的对等网络，并且所有发生在XRP账本上的业务都发生在生产网络中。

但是，有时您可能想要在不与核心网络交互的情况下进行测试和实验。这就是为什么Ripple开创Ripple Test Net这个“测试”网络的原因，它可以作为应用程序和rippled服务器本身的测试场地，而不会影响日常XRP账本用户的业务运营。Ripple Test Net（也称为AltNet）单独提供TestNet-only XRP，Ripple 免费赠送给有意在测试网上开发应用程序的各方。

注意：Ripple不保证测试网络的稳定性。它一直并将继续用于测试服务器配置，网络拓扑和网络性能的各种属性。

随着时间的推移，可能还会有更小的临时测试网络用于特定目的。

并行网络和共识

没有配置可以定义它使用哪个网络。相反，它使用它所信任的验证节点的共识来知道哪个账本可以被正式接受。当rippled实例的不同共识组仅信任同一组中的其他成员时，每个组继续作为并行网络。即使恶意或行为异常的计算机连接到两个网络，只要每个网络的成员未配置为信任另一个网络的成员超过其仲裁设置，共识流程就会覆盖混淆。

总结：

写一句原话吧：

At this time, Ripple (the company) recommends only trusting the default validators that Ripple operates.

还没完！往下看！！！

瑞波Ripple概念解析-共识网络（官方文档不完全翻译）相关推荐

瑞波Ripple概念解析-共识Consensus（官方文档不完全翻译）
共识由Dave Cohen,David Schwartz和Arthur Britto撰写. 本文提供了XRP账本的高层次概述,其存储的信息以及交易如何导致账本更改. 在XRP 账本上构建应用程序时, ...
瑞波Ripple概念解析-XRP账本概述（官方文档不完全翻译）
XRP账本概述 XRP账本是一个区中心化的加密账本,运行在P2P网络上.XRP是一个在世界范围内用来桥接多种货币的数字资产.Ripple负责账本的开发,及推动XRP为价值互联网做出关键贡献. 支付数字 ...
瑞波Ripple概念解析-技术FAQ（官方文档不完全翻译）
技术FAQ 验证程序和唯一节点列表交易验证节点提供什么服务? 验证程序确定交易是否符合协议要求,因此是"有效的".服务验证程序唯一提供的是将交易分组为有序单元,并专门对顺序达成一 ...
瑞波Ripple概念解析-XRP账本业务（官方文档不完全翻译）
将XRP上到交易所本文档描述了交换所需列出XRP的步骤. Alpha Exchange 为了便于说明,本文档使用名为Alpha Exchange的虚构业务来解释列出XRP所需的高级步骤.为了本文档的 ...
瑞波Ripple概念解析-复杂的付款类型（官方文档不完全翻译）
跨货币支付在XRP账本中,您可以发送交换一种或多种已发行货币XRP或二者的交叉货币付款.与直接XRP付款一样,这些付款使用付款交易类型.XRP账本内的跨货币支付是完全原子的,这意味着支付完全执行或者 ...
【Spring Boot官方文档原文理解翻译-持续更新中】
[Spring Boot官方文档原文理解翻译-持续更新中] 文章目录 [Spring Boot官方文档原文理解翻译-持续更新中] Chapter 4. Getting Started 4.1. Int ...
Android官方文档training中英文翻译目录大全：29篇已翻译，45篇未翻译
Android官方文档training中英文翻译目录大全:29篇已翻译,45篇未翻译 1. Getting Started Building Your First App: 原文: https://d ...
matlab 2019a 的官方文档及其中文翻译
matlab 2019a 的官方文档及其中文翻译资源链接:https://download.csdn.net/download/weixin_39817698/11347351 此文件包含matla ...
Android官方文档系列（翻译）
下面一些内容是我翻译Android官方文档相关文章,以及整理的其它内容. 菜鸟上路,一边学习一边整理,若您发现有错误的地方还请不吝赐教. Activity 解读Android之Activity基础知识 ...

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

共识研究

并行网络（测试网络）

并行网络和共识

瑞波Ripple概念解析-共识网络（官方文档不完全翻译）相关推荐

最新文章

热门文章