瑞波Ripple关键要点汇总

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

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

区块共识。

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

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:

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

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

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是根据上次验证的账本序号计算得出的。

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

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

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

（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.

 部分付款警告

 当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设置可防止所有交易对手持有地址发行的余额，除非该地址已明确批准与该交易对手之间的会计关系。