跨货币支付

在XRP账本中，您可以发送交换一种或多种已发行货币XRP或二者的交叉货币付款。与直接XRP付款一样，这些付款使用付款交易类型。XRP账本内的跨货币支付是完全原子的，这意味着支付完全执行或者没有执行。

默认情况下，交叉货币付款会为其来源以可变费用向其目的地提供固定金额。跨货币支付也可以在设置了发送限额后向目的地提供可变金额的部分支付。

先决条件

  • 根据定义，交叉货币支付至少涉及两种货币，这意味着至少涉及一种货币必须是非XRP发行货币。

    • 通常，这意味着使用由XRP账本网关发行的一种或多种货币。此类货币由XRP账本之外的资金支持，并可通过网关提取。
    • 只要交易双方都愿意发送或接收这些tokens并将它们视为有价值的东西，您也可以使用仅在XRP账本内发行并且没有外部支持的数字tokens 。
  • 发送者和接收者之间必须至少有一条路径，并且所有路径的总流动性必须足以支付款项。对于交叉货币付款，这通常意味着要撮合挂单从一种货币转换为另一种货币。

Autobridging（自动寻找最优路径）

用来交换两种已发行货币的跨货币支付通过连接订单簿（order books ）来加强流动性，自动使用XRP来降低支付成本。例如，从USD发送到MXN的付款会自动将USD转换为XRP，然后将XRP转换为MXN（注意：前提是这样做比直接将USD转换为MXN便宜）。

有关更多信息，请参阅Autobridging。

支票

XRP账本中的支票功能允许用户创建可以由预期接收方取消或兑现的延期付款。就像个人纸质支票一样，XRP账本支票从资金发送人开始，创建一个指定金额和收款人的支票。接收方兑现支票，将资金从发送方账户中提取到收款人的账户中。直到接收方兑现支票，才能移动钱。由于创建支票时资金并未被搁置，如果发送方在收款人尝试兑现时没有足够的资金，则兑现支票可能会失败，就像传统支票一样。如果支票兑现失败，发送方可以重试，直到支票到期。

XRP账本支票有到期时间，之后可能不再兑现。如果接收方未成功兑现支票，Check对象将保留在XRP账本中直到有人取消为止。只有发送方和接收方可以在支票过期或兑现前取消支票。当发送方兑现了支票或有人取消支票时，Check对象将从账本中移除。

支票与托管和付款渠道类似，但这些功能与支票之间存在一些重要区别：

·         您可以通过Checks支票发送发行货币。通过付款渠道和托管，您只能发送XRP。

·         支票不捆绑任何资金。支付渠道和托管的XRP只有在发送方赎回（支付渠道）或到过期时间或满足加密条件（托管）才能使用。

·         您可以通过Escrow将XRP发送给您自己。您不能使用支票或支付渠道向您自己发送XRP（或在支票，发行货币的情况下）。

注意：“ 检查”修订会更改OfferCreate事务的到期行为。有关更多信息，请参阅优惠到期。

为什么用支票Checks？

传统的纸质支票允许人们在不立即兑换实际货币的情况下转账余额。XRP账本支票允许人们使用银行业熟悉和接受的流程异步交换资金。

XRP账本支票也解决了XRP账本唯一的问题：它允许用户拒绝不想要的付款或仅接受部分付款。这对于那些因合规原因需要小心接受付款的机构很有用。

检查可能启用许多其他用例。Ripple鼓励社区为支票寻找新的和创造性的应用程序。

使用案例：付款授权

问题：为遵守像BSA，KYC，AML和CFT这样的规定，金融机构必须提供关于他们收到资金来源的文件。这些法规旨在通过要求机构披露机构处理的所有付款的来源和目的地来防止非法转移资金。由于XRP账本的性质，任何人都可能将XRP（并且在适当的情况下，包括发行货币）发送到XRP账本的机构账户里。处理这些不必要的支付会给这些机构的合规部门带来巨大的成本和时间延迟，包括可能的罚款或处罚。

解决方案：机构可以通过在交易中设置标志，在其XRP账本帐户上启用存款授权。这使该帐户无法接收付款交易。通过在AccountSet交易中设置asfDepositAuth标志来启用存款授权的帐户只能通过托管，付款渠道或支票接收资金。如果启用存款授权，支票是最直接，最熟悉，最灵活的转账方式。

用法

检查通常具有下述的生命周期。

步骤1：要创建支票，发送方提交CheckCreate交易并指定接收方（Destination），到期时间（Expiration）以及可能从发送方帐户（SendMax）中扣除的最高金额。

步骤2：处理CheckCreate事务后，将在XRP账本上创建一个Check对象。该对象包含由创建它的事务定义的Check的属性。该对象只能由发送方（通过取消CheckCancel交易）或接收方（通过取消或兑现）在到期时间过去之前进行修改。到期后，任何人都可以取消支票。

步骤3：为了兑现支票，接收者提交CheckCash交易。接收方有两个选项可以兑现支票：

·         Amount - 接收者可以使用这个选项来指定一个确切的现金金额。这对于发送方填写的支票以涵盖可能的转账费用并且接收人只能接受确切金额的发票，这在其他合同中的情况可能是有用的。

·         DeliverMin - 接收方可以使用此选项来指定他们愿意从支票收到的最低金额。如果接收方使用此选项，则rippled尽可能多地尝试交付并至少交付此金额。如果可以记入收款人的金额不低于此金额，则交易失败。

如果发送方有足够的资金支付支票并且过期时间未过，则资金从发送方的帐户中扣除并记入收款人的账户，并且支票对象被销毁。

过期案例

在过期的情况下，支票的生命周期如下所述。

所有检查都以相同的方式开始，因此步骤1和步骤2是相同的。

步骤3a：如果支票在收款人可以兑现之前到期，则支票不能再兑现，但仍保留在账本中。

步骤4a：在支票到期后，任何人都可以通过提交CheckCancel交易来取消它。该交易将从账本中删除支票。

支票的可用性

支票需要rippledv0.90.0或更高版本支持。支票修正案在2018-03-22正式XRP 账本上获得了大多数验证节点的支持：EnableAmendment pseudo-transaction: EC0D90F114D4F3C599FEABCAF47DCF0CAC29A272D1EF6C9BEF7F420819540F04。有关如何启用和投票修订的更多信息，请参阅修订流程。

不使用正式XRP账本时，可以使用功能方法检查支票修订的状态。

进一步阅读

有关XRP账本中的支票的更多信息，请参阅：

  • 交易参考

    • 检查修正
    • CheckCreate
    • CheckCash
    • CheckCancel
  • 支票教程
    • 发送支票
    • 按发送方地址查找支票
    • 按接收方地址查找支票
    • 以确切金额兑换支票
    • 以灵活金额兑换支票
    • 取消支票

有关相关功能的更多信息，请参阅：

  • 存款授权
  • 第三方托管
  • 付款频道教程

第三方托管

托管是XRP账本的特征，允许您发送有条件的XRP支付交易。这些有条件的付款（称为托管）将XRP留出，并在满足特定条件后再交付。成功完成托管的条件包括基于时间的解锁和加密条件。如果未及时完成，也可以将Escrow设置为过期。有条件持有的支付交易是 Interledger Protocol 支持的一个关键特征，它可以使支付链跨越任何数量的账本。

在托管中搁置的XRP被锁定。在托管成功完成或取消之前，任何人都不能使用或销毁XRP。在到期时间之前，只有预期的接收者可以获得XRP。过了到期时间后，XRP只能退回给发送方。

用法

步骤1：要发送托管，发送方使用EscrowCreate事务来锁定某些XRP。该交易定义了完成时间，到期时间或两者。交易也可以定义一个加密条件，必须满足完成托管。此交易必须定义XRP的预期接收方; 接收方可能与发送方相同。

步骤2：在处理完此事务后，XRP账本拥有一个托管对象，用于保存托管的XRP。该对象包含由创建它的事务定义的托管属性。如果此托管有结束时间，则在此之前没有人可以访问XRP。

步骤3：接收方或任何其他XRP账本地址发送EscrowFinish交易以交付XRP。如果符合正确的条件，则会销毁账本中的Escrow对象，并将XRP归入预期的收款人。如果托管存在加密条件，则该交易必须包含该条件的履行。如果托管的过期时间已经过去，则EscrowFinish交易将失败并显示代码tecNO_PERMISSION。

过期案例

所有托管开始的方式相同，因此步骤1和2与成功案例中的步骤相同。

步骤3a：如果托管有到期时间，并且在此之前尚未成功完成，则托管被视为过期。它继续存在于XRP账本中，但不能再成功完成。（过期对象保留在账本中，直到事务修改它们为止。基于时间的触发器不能更改账本内容。）

步骤4a：发送方或任何其他XRP账本地址发送EscrowCancel交易以取消过期的托管。这会销毁账本中的Escrow对象并将XRP返回给发送方。

限制

Escrow被设计为一项功能，可以使XRP账本在Inter账本协议和其他智能合约中使用。目前的版本有一个适度的范围以避免复杂性。

  • 托管仅适用于XRP，不适用于已发行的货币。
  • 托管要求至少发送两笔交易：一笔交易创建托管，一笔交易完成或取消。因此，在非常小的数额内托管支付可能在财务上并不明智，因为参与者必须支付两笔交易的交易费用。
    • 使用加密条件时，交易完成托管的成本比平时高。
  • 所有托管必须具有“完成后”时间或到期时间，或两者兼有。当创建代管的交易执行时，既不是过去的时间。
  • 定时发布和到期仅限于XRP账本关闭的解决方案。这意味着在实践中，时间可能会四舍五入到大约5秒的时间间隔，具体取决于账本的确切时间。
  • 唯一支持的加密条件类型是PREIMAGE-SHA-256。

托管提供了最适合高价值，低数量支付的强有力保证。付款渠道更适合快速，低价值的付款。当然，无条件支付对于许多用例也是可取的。

托管的可用性

Conditional payments have been enabled by the "Escrow" Amendment to the XRP Ledger Consensus Protocol since 2017-03-31. A previous version of the same functionality was available on the Ripple Test Net by the name "Suspended Payments" (SusPay) in 2016.

在独立模式下进行测试时，无论修改状态如何，您都可以在本地启用Escrow功能。将以下节添加到您的rippled.cfg：

[features]
Escrow

您可以使用特征方法检查托管修正的状态。

EscrowFinish交易费用

在使用加密条件时，由于验证密码条件实现所涉及的处理负载较高，因此EscrowFinish事务必须支付较高的交易费用。

如果托管纯粹是时间锁定而没有加密条件，则EscrowFinish仅参考交易的标准交易费用支付费用。

所需的额外交易成本与履行的规模成正比。目前，满足要求的EscrowFinish要求交易成本最低为330 滴XRP，并且在履行规模中每16字节有10滴。如果交易是多重签署的，则多次签署的成本将被添加到履行的成本中。

注意：上述公式基于一个事务的参考成本为10个XRP的假设。

如果费用投票更改了该reference_fee值，则公式将根据新的参考成本进行缩放。具有履约的EscrowFinish交易的广义公式如下：

reference_fee * (signer_count + 33 + (fulfillment_bytes / 16))

为什么托管？

Escrow的古老做法使得许多种金融交易成为可能，特别是在线上。通过让一个值得信赖的第三方在交易或评估期间持有资金，双方都可以放心，另一方必须阻止交易的结束。

托管功能通过用XRP帐簿中内置的自动化系统取代第三方来进一步实现这一想法，从而锁定和释放资金是公正的，并且可以自动化。

完全自动托管由XRP账本本身的完整性支持，解决了Ripple的重要问题，并且我们认为还有许多其他使用托管的用例。Ripple鼓励业界找到新的独特的方式来代管使用。

举例：基于时间的锁定

背景：Ripple拥有大量的XRP，它有条不紊地出售，作为资助和激励XRP 账本及相关技术健康发展的一种方式。同时，拥有如此大量的XRP会给公司带来问题，例如：

  • 使用XRP账本的个人和企业担心，如果Ripple通过以比平常更高的利率销售来刺激市场，他们在XRP上的投资可能会被稀释或贬值。

    • 虽然flooding the marke对Ripple来说是一个长期的损失，但公司这样做的可能性会对XRP的价格施加下行压力，从而降低公司资产的价值。
  • Ripple一定要谨慎管理其帐户的所有权，以防止数字窃取和其他形式的恶意行为，即使是内部人员也是如此。

解决方案：通过将550亿XRP放入基于时间的托管中，Ripple确保循环中XRP的供应可预测并以缓慢但稳定的速率增加。其他持有XRP的人都知道，即​​使公司的优先事项或策略发生变化，Ripple也不能淹没市场。

将资金存入第三方托管并不能直接保护Ripple的资产免受恶意行为者的侵害，但是如果恶意行为者对Ripple的XRP账户进行临时控制，它会大幅度减少可能被迅速盗走或重定向的XRP数量。这降低了XRP灾难性损失的风险，并增加了Ripple检测，防止和追踪Ripple XRP资产非预期使用的时间。

举例：Interledger Payments支付

背景：在快速发展的金融技术世界中，核心挑战之一是协调跨多个数字货币系统或账本的活动。许多提出的解决方案（包括XRP账本的早期观点）可以被缩减为创建“一个账本来统治它们”。Ripple认为没有一个系统能够满足世界上每个人的需求：事实上，一些理想的功能是相互排斥的。相反，Ripple认为，互联网账本 - 一个互联网 - 是金融技术的真正未来。所述Inter账本协议定义了用于制备如许多系统尽可能连接可靠顺畅地标准。

账本支付的最基本原则是有条件转移。多跳支付有一个风险问题：中间跳跃越多，付款失败的地方就越多。Inter账本通过“ 两阶段承诺 ” 的金融解决方案解决了这个问题，其中两个步骤是（1）准备有条件的转账，然后（2）履行执行转账的条件。Inter账本项目定义了一个加密条件规范，以标准化自动化方式来定义和验证条件，并将SHA-256哈希定义为这些条件的“共同点”。

解决方案：借助Escrow功能，XRP分帐器非常适合使用Inter账本协议来桥接多跳付款，因为它本身支持基于PREIMAGE-SHA-256加密条件提供XRP的传输，并且在提交后几秒钟内即可执行这些传输与匹配的履行。

进一步阅读

有关XRP账本中托管的更多信息，请参阅以下内容：

  • 托管教程

    • 发送延时托管
    • 发送有条件的托管
    • 通过发送方或接收方查找托管
  • 交易参考
    • EscrowCreate交易
    • EscrowFinish交易
    • EscrowCancel交易
  • 账本参考
    • 托管对象

有关Inter账本以及条件传输如何跨多个账本实现安全支付的更多信息，请参阅Inter账本架构。

有关Ripple的55亿XRP锁定的更多信息，请参阅Ripple的Insights博客。

部分付款

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

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

部分支付可用于利用与XRP账本的原生集成从交易所和网关窃取资金。本文档的部分支付利用部分描述了如何利用此漏洞以及如何避免它。

语义

没有部分付款

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

换一种说法：

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

在这个公式中，“费用”是指转账费用和汇率。“已发送金额”和已交付金额（Amount）可以以不同货币计价，并通过在XRP去中心化交易所中撮合挂单进行转换。

注：该Fee交易的领域是指XRP 交易成本，该交易转发到网络后被销毁。指定的确切交易成本始终从发送方中扣除，并且与任何类型付款的收费计算完全分开。

部分付款

在发送启用了部分支付标志的支付时，Amount交易字段指定了要交付的最大金额。尽管收费包括费用，流动性不足，接收账户信托额度不足或其他原因，但部分支付可以成功发送部分预期价值。

可选DeliverMin字段指定了要交付的最低金额。该SendMax领域的功能与非部分支付相同。如果部分付款交易的交付金额大于等于该DeliverMin字段，且不超过SendMax金额，则该部分付款交易成功。如果DeliverMin未指定该字段，则可以通过提供任何大于0的数来支付部分付款。

换一种说法：

Amount ≥ (Delivered Amount) = SendMax - (Fees) ≥ DeliverMin > 0

部分支付限制

部分付款具有以下限制：

  • 部分支付无法创建资金地址; 这种情况下返回结果代码 telNO_DST_PARTIAL。
  • 直接XRP到XRP付款不能是部分付款; 这种情况下返回结果代码 temBAD_SEND_XRP_PARTIAL。
    • 但是，issuance至XRP付款或XRP到issuance付款可以是部分付款。

delivered_amount字段

为了帮助理解实际交付的部分付款的金额，成功的付款交易的元数据包含一个delivered_amount字段。该字段描述实际交付的金额，格式与Amount字段相同。

对于非部分支付，delivered_amount交易元数据的Amount字段等于交易字段。当交付已发行货币时，由于四舍五入的原因，delivered_amount与Amount字段可能略有不同。

交付金额不适用于符合以下两个标准的交易：

·         部分付款

·         2014-01-20之前的账本交易

如果两个条件均为真，则delivered_amount包含字符串值unavailable而不是实际金额。如果发生这种情况，您只能通过读取交易元数据中的AffectedNodes来确定实际交付金额。如果事务递送的货币发行和issuer的Amount是相同的帐户作为Destination地址，所递送的量可以在多个之间划分AffectedNodes表示信任线不同对手成员。

您可以在以下位置找到该delivered_amount字段：

API

Method

Field

JSON-RPC / WebSocket

account_tx method

result.transactions array members' meta.delivered_amount

JSON-RPC / WebSocket

tx method

result.meta.delivered_amount

JSON-RPC / WebSocket

transaction_entry method

result.metadata.delivered_amount

RippleAPI

getTransaction method

outcome.deliveredAmount

RippleAPI

getTransactions method

array members' outcome.deliveredAmount

部分支付利用

如果一家金融机构与XRP账簿的整合假定Amount支付领域始终是全额交付的，恶意行为者可能会利用这一假设从该机构窃取资金。只要这些机构的软件没有正确处理部分支付，这种利用可以用于网关，交易所或商家。

处理传入的支付交易的正确方法是使用delivered_amount元数据字段，而不是Amount场。通过这种方式，一个机构从不会误解它实际收到了多少。

利用场景步骤

为了利用一个脆弱的金融机构，恶意行为者可以这样做：

  1. 恶意演员向机构发送支付交易。此事务有一个大的Amount字段，并启用了tfPartialPayment标志。
  2. 部分支付成功（结果代码tesSUCCESS），但实际上只提供了非常少量的指定货币。
  3. 易受攻击的机构Amount无需查看Flags字段或delivered_amount元数据字段即可读取交易的字段。
  4. 尽管在XRP账本中只收到了一个小得多的delivered_amount数量的账单，但是这个脆弱的机构将这个恶意行为者执行了一个外部系统，比如该机构自己的账本。
  5. 在易受攻击的机构注意到这种差异之前，恶意行为者尽可能多地将余额提取到另一个系统。
  • 恶意行为者通常宁愿将余额转换为另一种加密货币，如比特币，因为区块链交易通常是不可逆的。随着撤回到法定货币体系，金融机构可能能够在最初执行后几天撤销或取消交易。
  • 在交换的情况下，恶意行为人也可以将XRP余额直接回收到XRP账本中。

在商人的情况下，操作顺序略有不同，但概念是相同的：

  1. 恶意的演员要求购买大量的商品或服务。
  2. 易受攻击的商家向恶意行为者提供这些商品和服务的价格。
  3. 恶意演员向商家发送支付交易。此事务有一个大的Amount字段，并启用了tfPartialPayment标志。
  4. 部分支付成功（结果代码tesSUCCESS），但只提供指定的非常少量的货币。
  5. 易受攻击的商家Amount无查看Flags字段或delivered_amount元数据字段即可读取该事务的字段。
  6. 易受攻击的商家将发票视为已付款，并将商品或服务提供给恶意行为者，尽管delivered_amount在XRP账本中仅收到了更小的发票。
  7. 恶意行为者在商家注意到这种差异之前使用，转售或者销售商品和服务。

进一步的缓解措施

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

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

付款渠道

付款渠道是一项发送“异步”XRP付款的高级功能，可以分为很小的增量并在稍后解决。

支付渠道的XRP在特定时间段内被预留。发送方根据频道创建声明，接收方验证该声明而不发送XRP账本处理或等待新的账本版本获得一致批准。（这是一个异步过程，因为它与通过一致性获得交易的通常模式分开。）在任何时候，接收方都可以兑换Claim 以获得由该索赔授权的XRP数量。作为通常的共识流程的一部分，使用标准的XRP账本交易来解决此类索赔。这种单一交易可以包含任何数量的由较小索赔保证的交易。

由于理赔可以单独进行验证，但之后可以批量结算，因此支付渠道可以以仅限参与者创建和验证这些索赔的数字签名的能力进行交易。这个限制主要基于参与者硬件的速度和签名算法的复杂性。为获得最大速度，请使用比XRP账本的默认secp256k1 ECSDA签名更快的Ed25519签名。研究表明，每秒能够创建超过Ed25519 100,000个签名并验证每秒超过70,000个签名 在2011年的商品硬件上。

为什么使用付款渠道

使用付款渠道的过程总是涉及两方，即付款人和收款人。付款人是使用作为收款人客户的XRP账本的个人或机构。收款人是收到XRP作为商品或服务付款的个人或企业。

付款渠道本质上并未指明您可以随意购买和出售的东西。但是，适合付款渠道的商品和服务类型包括：

  • 可以即时传输的东西，如数字项目
  • 廉价的东西，其中处理交易的成本是价格的一个不平凡的部分
  • 通常情况下，散装物品都是购买的，而预先确定的数量并不知道

付款渠道生命周期

下图总结了付款渠道的生命周期：

也可以看看

  • 使用付款渠道，这是一个教程，介绍使用付款渠道的过程。
  • Escrow，对于价值较高，速度较低的有条件XRP付款的类似功能

总结：

复杂的支付功能有：

跨货币支付，多种发行货币的交易，会自动选择最优路径，跨货币支付也使用部分支付交易

支票，可以设置过期时间，接受者可以拒绝支付

托管，可以对XRP进行锁定

部分付款，支付的金额是delived_amount，而不是amount

付款通道，类似于比特币的微支付通道

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

瑞波Ripple概念解析-复杂的付款类型（官方文档不完全翻译）相关推荐

  1. 瑞波Ripple概念解析-XRP账本概述（官方文档不完全翻译）

    XRP账本概述 XRP账本是一个区中心化的加密账本,运行在P2P网络上.XRP是一个在世界范围内用来桥接多种货币的数字资产.Ripple负责账本的开发,及推动XRP为价值互联网做出关键贡献. 支付数字 ...

  2. 瑞波Ripple概念解析-XRP账本业务（官方文档不完全翻译）

    将XRP上到交易所 本文档描述了交换所需列出XRP的步骤. Alpha Exchange 为了便于说明,本文档使用名为Alpha Exchange的虚构业务来解释列出XRP所需的高级步骤.为了本文档的 ...

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

    共识 由Dave Cohen,David Schwartz和Arthur Britto撰写. 本文提供了XRP账本的高层次概述,其存储的信息以及交易如何导致账本更改. 在XRP 账本上构建应用程序时, ...

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

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

  5. 瑞波Ripple概念解析-技术FAQ（官方文档不完全翻译）

    技术FAQ 验证程序和唯一节点列表 交易验证节点提供什么服务? 验证程序确定交易是否符合协议要求,因此是"有效的".服务验证程序唯一提供的是将交易分组为有序单元,并专门对顺序达成一 ...

  6. Hyperledger Fabric 2.0 官方文档中文版 第3章 关键概念

    Hyperledger Fabric 2.0 官方文档中文版 第3章 关键概念 总目录 3.关键概念 引言 什么是区块链? 区块链为什么有用? 什么是Hyperledger Fabric? Hyper ...

  7. 【官方文档】Fluent Bit 概念

    文章目录 1. 关键概念 1.1. 事件或记录(Event or Record) 1.2. 过滤(Filtering) 1.3. 标签(Tag) 1.4. 时间戳(Timestamp) 1.5. 匹配 ...

  8. HarmonyOS（一） 快速开始学习鸿蒙开发，官方文档学习路线解析

    系列文章目录 HarmonyOS(一):快速开始学习鸿蒙开发,官方文档学习路线解析 HarmonyOS(二):应用开发环境搭建准备 HarmonyOS(三):创建你的第一个HelloWorld应用 文 ...

  9. oracle12c官方文档中文版_三分钟让你真正读懂oracle12c 中cdb pdb概念及原理

    Oracle 12C引入了CDB与PDB的新特性,在ORACLE 12C数据库引入的多租用户环境(Multitenant Environment)中,允许一个数据库容器(CDB)承载多个可插拔数据库( ...

最新文章

  1. C++Primer ch4笔记
  2. 码农翻身之——分布式，集群，负载均衡
  3. System.Timers.Timer 多线程问题[转]
  4. eclipse中启动tomcat，不能访问localhost解决办法
  5. java处理Excel(POI包)
  6. 高清、免版权美图资源大全
  7. 缓存与数据库的一致性：先操作缓存还是先操作数据库？
  8. New directions in automated traffic analysis论文解读
  9. 数字化时代的新职业教育行业洞察
  10. 【AI视野·今日CV 计算机视觉论文速览 第203期】Fri, 21 May 2021
  11. AlphaZero完胜三大世界冠军棋类程序：5000个TPU、自学一天
  12. 几个 h5页面效果和 自动 app 生成网站 微页
  13. C# BackgroundWorker
  14. Android像素密度dpi/ppi计算公式，px、sp、dp互转工具类——概念解释
  15. R语言使用mad函数、median函数、mean函数计算向量数据的中位数绝对偏差、中位数、均值、数据中包含NA值的情况
  16. SXT分布式缓存技术公开课的观后感
  17. 常见的GC算法（GC的背景与原理）
  18. CISCO数据中心虚拟化之VSS技术和配置
  19. OpenGL红宝书的部分学习记录
  20. 白盒测试概述及其方法简介

热门文章

  1. 从入坑PMP至拿证的心路历程
  2. 视频号、抖音、快手各侧重的是哪方面，有什么不同？
  3. 多版本cuda安装及灵活切换详细教程
  4. 转载大神IOS开发系列【16】--通讯录、蓝牙、内购、GameCenter、iCloud、Passbook
  5. 高德推出查岗功能_打尽渣男渣女的查岗神器？高德家人地图实测
  6. [mgoj]1995. WZK的排名
  7. 优思学院｜常用于过程管理模型的乌龟图是怎么画的？
  8. 目前已经知道的乐视所有产品各个型号的强刷方法！更新X50
  9. python入门教程之五元组
  10. 贝叶斯概率图计算（1）