瑞波Ripple关键要点汇总

　

ripple

发行及XRP介绍

"早在 2004 年，Ryan Fugger 就推出了Ripple 项目的第一个现实版本。 它是基于互联网为解决银行间转账与汇款手续费用高昂而设计的支付与清算网络，运作方式类似于银行的清算系统。"

"Ripple 总共发行 1000 亿单位的 XRP，XRP 目前可精确到 6 位小数； 最小的单位称为一滴（drop），即 100 万滴等于 1 个 XRP， 也就是 1XRP=1000000dXRP。 "

"2013 年，Open Coin 公司推出了新版的 Ripple 网络，通过两个措施解决了孤立小圈子的问题：其一是推出瑞波币（XRP），作为 Ripple 网络的基础货币，可以在整个 Ripple 网络中无限制的自由流通；其二是引入了网关（Gateway）系统，就像是金融中介，可以对货币进行存取和兑换， 人们信任的不再是某个人，而是这个网关系统，并且允许人们通过网关将法定货币或者虚拟货币注入和抽离 Ripple 网络，使得 XRP之外的转账可以在信任网关的用户之间进行，而不再局限于彼此信任的人之间。"

rippledAPI要求所有的XRP amounts都要以Drop为精度。例如，1个XRP表示为1000000Drop。

XRP账本的一致性算法在4到5秒内完成交易确认，每秒处理吞吐量高达1500笔交易。

账户

XRP账本中的“账户”负责持有XRP瑞波币和发送交易。账户的属性元素有：

• 识别地址，例如rf1BiGeXwwQoi8Z2ueFYTEXSwuJYfV2Jpn
• 一个XRP余额（XRP balance）。一些XRP预留给Reserve。
• 一个起始序号（sequence number），从1开始，随着从该帐户发送的每个交易增加而增加。除非交易的序号与其发送方的下一个序号相匹配，否则交易不能包含在账本中。
• 交易历史（history of transactions），影响本账户及其余额。
• 一种或多种授权交易，可能包括：
  • 该帐户固有的主密钥对。（这可以禁用但不能更改。）
  • 一个可以替换的 “常规”密钥对。
  • 多签名的签名者列表。（与帐户的核心数据分开存储。）

非XRP货币和资产不存储在XRP帐户帐户本身中; 每个这样的资产都存储在一个称为“信任线”的会计关系中，该关系连接双方。

如一个支付交易发送大于等于预留数额（account reserve ）的XRP到一个合法的地址，这个地址还没被使用的话，则会自动创建账户。这称为创建账户，并在账本中创建AccountRoot对象

警告：您第一次在您自己的XRP账本地址收到XRP时，您必须支付帐户预留（当前为20 XRP），无限期锁定XRP的数量。相比之下，私人交易通常将所有客户的XRP都保存在几个共享的XRP账户中，因此客户不必为交易所的个人账户支付保留金。在退出之前，考虑在XRP账本上直接拥有自己的账户是否物有所值。

账户地址特征

XRP账本中的帐户由base58 XRP账本地址标识。该地址来源于账户的主公钥，而后者又是从一个私钥中派生出来的。地址在JSON中表示为一个字符串，并具有以下特征：

• 长度在25到35个字符之间
• 从角色开始 r
• 使用字母数字字符，不包括数字“ 0”大写字母“ O”，大写字母“ I”和小写字母“ l”
• 区分大小写
• 包含一个4字节的校验和，从随机字符生成有效地址的概率约为1 / 2 ^ 32

任何有效的地址都可以通过创建成为XRP账户中的一个资金账户。您还可以使用尚未创建的地址来作为常规密钥或签名人列表的成员。只有资金账户才能成为交易的发送方。

地址编码算法：

XRP账本的公共账本链的每个新版本的账页都包含账本的全部状态，随着每个新账户的创建规模也会增加。出于这个原因，Ripple不鼓励创建新账户，除非完全有必要。代表许多用户发送和接收价值的机构可以使用“ 源标签（Source tags）”和“ 目的地标签（Destination tags）”来区分来自其客户的付款，同时仅使用XRP账本中的一个（或少数）帐户。

“完整”交易历史记录包括的历史对象如下：

• RippleState 对象（信任线）与该帐户连接。
• DirectoryNode 对象，尤其是追踪账户自己拥有的对象。
• Offer 代表去中心化交易所中账户未完成的货币兑换订单。
• PayChannel 对象，代表帐户间的异步付款渠道。
• Escrow 对象，代表按时间或加密条件锁定的账户间的付款。
• SignerList对象，表示可以通过多重签名为帐户授权交易的地址列表。

创建账户命令：

rippled wallet_propose masterpassphrase

field	Type	Description
key_type	String	Which elliptic curve to use for this key pair. valid values are ed25519 and secp256k1 (all lower case). Defaults to secp256k1.
passphrase	String	(optional) Generate a key pair and address from this seed value. This value can be formatted in hexadecimal, base58, RFC-1751, or as an arbitrary string. cannot be used with seed or seed_hex.
seed	String	(Optional) Generate the key pair and address from this base58-encoded seed value. Cannot be used with passphrase or seed_hex.
seed_hex	String	(Optional) Generate the key pair and address from this seed value in hexadecimal format. Cannot be used with passphrase or seed.

You must provide at most one of the following fields: passphrase, seed, or seed_hex. If you omit all three, rippled uses a random seed.

生成的密钥对可用于以下三种方式：作为主密钥对，常规密钥对或签署者列表成员。

主密钥对由私钥和公钥组成。除了能够签署常规密钥对可以使用的所有交易之外，主密钥对的私钥是唯一可用于执行以下操作的密钥：

• 禁用主公钥。
• 永久放弃冻结的能力。
• 发送成本为0的密钥重置事务。

主密钥对不能更改，但可以禁用。这意味着如果您的主密钥被泄露，而不是改变它，您必须禁用它。

使主密钥对保持离线状态意味着不要将主密钥放在恶意角色可以访问的地方。例如，这可能意味着将其保存在永不连接互联网的空隙机器上，保存在保险箱中的一张纸上，或者一般来说，保存在与整个互联网互动的计算机程序的范围内。理想情况下，主密钥对仅在最值得信赖的设备上使用，并仅用于紧急情况，例如在发生可能或实际的危害时更改常规密钥对。

常规密钥对（TODO）

XRP账户允许账户授权一个称为常规密钥对的二级密钥对来签署未来的交易，同时保持您的主密钥对离线。

如果常规密钥对的私钥遭到破坏，您可以删除或替换它，而无需更改帐户的其余部分并重新建立与其他帐户的关系。

使用该SetRegularKey方法将常规密钥对分配给帐户。

可以随时移除或更改常规密钥对。这意味着，如果普通私钥遭到破坏（但不是主密钥），只需删除或更改常规密钥对，即可重新获得对您帐户的控制权。有关更改或删除常规密钥对的教程，请参阅分配常规密钥对。

（TODO）requireDest标志指示发送交易需要指定目标标签才能接收货币。这可以防止用户忘记指明付款的目的，但不会保护收件人免受未知发送方的限制，这些发送方可以组成任意目标标签。

通过在AccountSet交易中设置asfDepositAuth标志来启用存款授权的帐户只能通过托管，付款渠道或支票接收资金。如果启用存款授权，支票是最直接，最熟悉，最灵活的转账方式。

多签

在您可以进行多重签名之前，您必须创建一个可以为您签名的地址列表。最多可以在SignerList中包含8个地址。您可以通过使用SignerList的法定人数和权重值来控制需要多少签名，以及在哪些组合中。

发送多重签名交易

要成功提交多签名交易，您必须执行以下所有操作：

• 发送交易的地址（在该Account字段中指定）必须SignerList在账本中拥有一个地址。
• 该交易必须包含该SigningPubKey字段作为空字符串。
• 该交易必须包含一个包含一系列签名的Signers字段。
• Signers数组中存在的签名必须与SignerList中定义的签名者匹配。
• 对于提供的签名，weight与这些签名者相关的总数必须等于或大于quorumSignerList的总数。
• 交易费用（Fee字段）必须至少在正常的交易成本（N + 1）倍，其中N是所提供的签名的数目。
• 收集签名之前，必须定义交易的所有字段。您无法自动填写任何字段。
• 如果以二进制形式表示，则Signers必须根据签名者地址的数值对数组进行排序，并以最低值开头。（如果以JSON提交，submit_multisigned方法会自动处理。）

准备金要求分为两种：

• 基本储备是必需的账本每个地址XRP的最小量。目前，20个XRP（20000000Drop）。
• 所有者储备是该地址增加账本对象的存款准备金。目前，每个对象5000000， 5个XRP（Drop）。

转账

在默认情况下，XRP账本Amount中的付款交易字段指的是在支付汇率和转账费用后要交付的确切金额。“部分支付”标志（tfPartialPayment）允许通过减少收到的金额来使交易成功，而不是增加发送的金额。部分支付对返还支付很有用，而不会对自己造成额外费用。

无论交易类型如何，用于交易费用的XRP金额总是从发送方的帐户中扣除。

发送不使用部分支付标志的支付时，Amount交易SendMax字段指定要交付的确切金额，并且该字段指定要发送的最大金额和货币。如果付款无法在Amount不超过SendMax参数的情况下交付全款，或者由于其他原因无法交付全额金额，交易将失败。如果该SendMax字段在交易指令中被忽略，则认为它等于Amount。在这种情况下，只有当费用总额为0时，付款才能成功。

换一种说法：

Amount + (fees) = (sent amount) ≤ SendMax

（TODO）部分支付要检查delivered_amount字段，而不是检查amount字段

处理传入交易时使用delivered_amount字段足以避免此漏洞。尽管如此，额外的主动商业行为还可以避免或减轻这种类似漏洞攻击的可能性。例如：

• 为您的业务逻辑添加额外的健全性检查以处理提款。如果您在XRP账簿中持有的总余额与您预期的资产和义务不符，请不要处理提款。（TODO）
• 遵循“了解您的客户”指南并严格验证您的客户身份。您可能会提前识别并阻止恶意用户，或对利用您的系统的恶意攻击者采取法律行动。

网关

不同网关发行的同名货币，可能造成伪币的产生。 原则上，只要有用户信任你，你就成了一个网关，可以发行任何一种货币，甚至是人民币 CNY 和美元 USD。 当然你所发行的 CNY 和别的网关发行的 CNY 是不一样。网关所发行的只是一种叫 CNY 的符号 （本质上是一种债务关系或者说借据 IOU）， 这种符号只能在信任该网关的人之间流通。 由于每个人都可以自由发行任意数量的 CNY，这就有了一个伪币的问题 8。 其三，网关破产。 不少网关提供充值提现以及交易服务，充值后网关会把相应的 CNY 或者 USD 送达到你的钱包，可是网关发行的 CNY 只是你钱包里的一个符号，真金白银还在网关老板手里。 一旦网关老板因为各种原因或者别的生意失败破产跑路了， 你就不能再提现了，大家手里剩下的只是钱包里的一些没用的数字罢了。

启用了RequireAuth的XRP账本发送资金的过程如下所示：

1. 发行网关将其发行地址发布给客户。
2. 客户发送一个TrustSet交易来创建一个信任线，从她的XRP账本地址到网关的发行地址。这表明她愿意持有由网关发行的特定货币，达到特定的数字限制。
3. 网关的发布地址发送授权客户信任线的TrustSet交易。

没有人可以冻结XRP。对于XRP账本中的其他货币，其发行人可以冻结他们发行的非XRP余额。

默认情况下，NoRipple标志会禁用所有信任线上的波动，除非帐户通过启用DefaultRipple标志来默认启用波动。

如果使用相同的货币代码，发行的货币可以通过多个发行人和持有人进行“Ripple”。这在某些情况下很有用，但会在其他情况下导致意想不到的行为。您可以使用信任行上的NoRipple标志来防止这些信任行波动。

非发行账户，尤其是流动性提供者可能持有来自不同费用和政策的不同发行人的余额，通常不希望他们的余额可以波动。

“NoRipple”标志是信任线上的设置。当两条信任线都使用同一地址启用NoRipple时，来自第三方的支付不能通过该信任线上的该地址进行波动。这样可以防止流动性提供者在同一货币的不同发行人之间出现意外的余额变动。

通过启用DefaultRipple标志，该帐户还可以启用全局波动

瑞波共识RPCA

UNL（unique Node List），即信任节点列表。每一个节点都维护这一个信任节点列表，并且在共识过程中，节点只会接受来自UNL的节点的投票。

XRP账本网络是选择加入的。每个参与者直接或间接选择其UNL。如果Ripple停止运行或Ripple恶意操作，参与者可以更改其UNL以继续使用XRP账本。

如果网络中超过20％的节点不同意大多数，该网络可能会暂时停止重新配置，以便继续以希望达成共识的新UNL List为基础。

RPCA对交易分两个阶段完成，第一阶段是达成交易集（即未打包进入区块的合法交易的集合）的共识，第二阶段是对新生成的区块进行提议，最终形成被共识过的区块。

交易共识。

1 每个节点在共识开始时尽可能多的收集所能收集到的需要共识的交易，并放到“候选集”里面；

2 每个节点对它信任节点列表中的 “候选集”做一个并集，并对每一个交易进行投票；

3 UNL中的服务节点交流交易的投票结果，达到一定投票比例的交易会进入到下一轮，达不到比例的交易要么被丢弃，要么进入到下一次共识过程的候选集中；

4.    在最终轮中，所有投票超过80%的交易会被放到共识过的交易集中。

区块共识。

形成交易集后，每个节点开始打包新的区块，打包区块的过程如下：

1.  每个节点广播自己得出的区块

2.  节点收集到它所有可信列表中节点广播过来的区块后，如超过80%，则认为这是获得共识的区块。否则，重头开始，直到实现80%以上的认可。

瑞波系统非常依赖UNL的体系，节点相互需要信任，并且每个每一个节点之间都要有相当完整的信任连接度，才可以使得系统顺利的运行。否则很可能会产生分叉。一旦前提达成，瑞波的就可以非常迅速的出块并达成共识，目前瑞波可以保证3秒出一个块，并且TPS达到1500。已经基本上满足了外汇交易的数量。

成功的交易具有tesSUCCESS 结果代码，该结果代码指示所请求的更改应用于账本，并收取费用。账本中的其他交易具有tec分类结果代码，这些代码表示仅支付费用并且不执行其他更改的交易。

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

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

使用LastLedgerSequence 参数确保事务以确定性和即时方式进行验证或失败。

• 检查经过验证的账本中的交易结果。
  • 在包含交易的账本被验证或LastLedgerSequence 通过之前，结果是临时的。
  • 交易结果代码是tesSUCCESS并且"validated": true最终是成功的，不可更改。
  • 交易结果代码是其他代码并且"validated": true最终是失败的，不可更改。
  • 直到经过验证的账本序号LastLedgerSequence，在任何经验证的账本中也未出现的交易，最终是失败的，不可更改。
    • 注意使用具有连续账本历史的节点来检测此情况¹¹。

可能需要重复检查交易的状态，直至确认的LastLedgerSequence 账本被验证。

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

瑞波还是一个偏中心化的数字货币，不管从运营模式、token集中度、验证节点来说都是。虽然是公链，但是由于其信任体系（UNL）的存在，其运作模式也非常类似联盟链。

Each rippledserver stores that ledger data in its ledger store, but the online delete logic rotates these databases when the number of stored ledgers exceeds configured space limitations.

Public Servers

Currently Ripple (the company) maintains a set of public Websocket servers at:

Domain	Port	Notes
s1.ripple.com	443	wss:// only; general purpose server
s2.ripple.com	443	wss:// only; full-history server

提交和验证是两个独立的程序，可以使用本文档中描述的逻辑来实现。

提交 - 交易提交给网络并返回临时结果。

1. 验证 - 权威结果是通过检查验证的账本确定的。

（TODO）提交过程：

构建并签署交易

• 包含LastLedgerSequence参数

构造交易细节，保存：

• 交易哈希
• LastLedgerSequence
• 发送方地址和序列号
• 提交时最新验证的账本索引
• 根据需要应用程序特定的数据

提交交易

（TODO）On restart, or the determination of a new last validated ledger (pseudocode):

For each persisted transaction without validated result:

    Query transaction by hash
    If (result APPears in validated ledger)
        # Outcome is final
        Persist the final result
        If (result code is tesSUCCESS)
            Application may act based on successful transaction
        Else
            The transaction failed (1)
            If appropriate for the application and failure type, submit with
                new LastLedgerSequence and Fee

    Else if (LastLedgerSequence > newest validated ledger)
        # Outcome is not yet final
        Wait for more ledgers to be validated

    Else
        If (server has continuous ledger history from the ledger when the
              transaction was submitted up to and including the ledger
              identified by LastLedgerSequence)
            The transaction failed (2)
            If appropriate for the application, submit with
                new LastLedgerSequence and Fee

        Else
            # Outcome is final, but not known due to a ledger gap
            Wait to acquire continuous ledger history

（TODO）rippled服务器应该有足够资源（cpu / RAM /磁盘IO）时自动获取缺失的账本版本，除非账本的版本数大于其配置的历史存储量。根据差距的大小和服务器的资源使用情况，获取缺失的账本应该花费几分钟的时间。您还可以在您的服务器上手动使用ledger_request方法发送请求获取历史账本版本。

或者，您可以使用rippled已经提供的存有全部账本历史记录的服务器（如Ripple的完整历史记录服务器s2.ripple.com）查看交易状态。达到此目的应该使用您信任的服务器。恶意服务器可能被编程来提供虚假交易状态和结果。

实现交易提交和验证最佳实践，应用程序需要执行以下操作：

确定签名账户的下一个序列号next sequence number

• 每笔交易都有一个账户特定的序列号。这保证了执行帐户签署的交易的顺序，并且可以安全地重新提交交易，而不会将交易多次应用于账本。（类似于以太坊的nonce）

决定一个 LastLedgerSequence

• 交易的LastLedgerSequence是根据上次验证的账本序号计算得出的。

构建并签署交易

• 提交前持久化签署交易的细节。

提交交易

• 初步结果暂定，可能会有变动。

确定交易的最终结果

• 最终结果是账本历史中不可变的部分。

（TODO）If an application were to submit three transactions signed by this account, they would use sequence numbers 4, 5, and 6. To submit multiple transactions without waiting for validation of each, an application should keep a running account sequence number.

Verify the Transaction

response shows "validated": true, indicating the transaction has been included in a validated ledger, so the result of the transaction is immutable. Further, the metadata includes "TransactionResult": "tesSUCCESS", indicating the transaction was applied to the ledger.

If the response does not include "validated": true, the result is provisional and subject to change. To retrieve a final result, applications must invoke the txmethod again, allowing enough time for the network to validate more ledger instances. It may be necessary to wait for the ledger specified in LastLedgerSequence to be validated, although if the transaction is included in an earlier validated ledger the result becomes immutable at that time

 Look up Transaction Results

To see the final result of a transaction, use the tx method, account_tx method, or other response from rippled. Look for "validated": true to indicate that this response uses a ledger version that has been validated by consensus.

Field	Value	Description
meta.TransactionResult	String	A code that categorizes the result, such as tecPATH_DRY
validated	Boolean	Whether or not this result comes from a validated ledger. If false, then the result is provisional. If true, then the result is final.

部分付款警告

当tfPartialPayment标志启用时，该Amount字段不保证是收到的金额。该支付的元数据的delivered_amount字段表示货币由目标帐户实际收到的金额。收到付款后，请使用delivered_amount金额字段来确定您的帐户收到的金额。

Alpha Exchange应在XRP账本上创建至少两个新帐户。一个冷钱包可以安全地占有大部分XRP和客户的资金。此帐户的密钥应该处于脱机状态。一个或多个热钱包负责管理客户XRP取款和存款的日常业务。

A user named Charlie wants to deposit 50,000 XRP to Alpha Exchange. Doing this involves the following steps:

1. Charlie submits a payment of 50,000 XRP (by using RippleAPI or similar software) to Alpha Exchange's cold wallet.

   a. Charlie adds an identifier (in this case, 789) to the payment to associate it with his account at Alpha Exchange. This is called a destination tag. (To use this, Alpha Exchange should have set the asfRequireDest flag on all of its accounts to require all incoming payments to have a destination tag like Charlie's. For more information, see AccountSet Flags).

2. The software at Alpha Exchange detects the incoming payment, and recognizes 789 as the destination tag for Charlie’s account.

3. When it detects the incoming payment, Alpha Exchange's software updates its balance sheet to indicate that the 50,000 XRP it received is controlled by Charlie.

the XRP Ledger has a currency exchange built into the protocol itself.

Payments going from the XRP Ledger to a gateway can be single-currency or cross-currency payments. The gateway's issuing address can only receive issuances it created (or XRP).

there are several prerequisites that ACME must meet to process payments coming from the XRP Ledger:

ACME must monitor its XRP Ledger addresses for incoming payments.

• ACME must know which user to credit in its system of record for the incoming payments.
  • We recommend that ACME should bounce any unrecognized incoming payments back to their sender.
  • Typically, the preferred method of recognizing incoming payments is through destination tags

目的地标签是XRP的一项功能支付可用于指示付款的受益人或目的地。例如，到网关的XRP账本支付可能包括目的地标记，以指示哪个客户应该记入该支付。网关应该在网关的记录系统中保留目标标签到帐户的映射。

源标签指明付款的来源或来源。最常见的是，包含一个来源标签，以便付款的接收方知道在哪里退款。当您退回收款时，请使用传入付款中的来源代码作为传出（反弹）付款的目标代码。

RequireDest设置（requireDestinationTag在RippleAPI中）旨在防止客户向您的地址发送付款，同时意外忘记了目标标签，该标签标识谁应该记入付款。启用后，XRP账本拒绝向您的地址付款，但没有指定目的地代码。

RequireAuth设置可防止所有交易对手持有地址发行的余额，除非该地址已明确批准与该交易对手之间的会计关系。

• When sending into the XRP Ledger, specify the issuing address as the issuer of the currency. Otherwise, you might accidentally use paths that deliver the same currency issued by other addresses.

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

还没完！往下看！！！

相关阅读