CN114556863A - 计算机实施的系统和方法 - Google Patents

Abstract

在第一方面，本公开提出了用于实现支付服务的方法、装置和系统，以使与客户端相关联的交易能够被写入或存储在分布式账本(即，区块链)中。支付服务被实现为API，一个或多个客户端可以访问该API以处理与相应客户端有关的数字资产支付。在第一方面，包括从多个矿工为客户端获得挖掘费用报价，并基于选定的费用报价处理向区块链提交交易的请求。在第二方面，本公开提出了用于基于客户端(付款方)与客户端的客户(收款方)之间的数字资产支付来请求与数字资产支付相关联的交易的方法、装置和系统，将在区块链中挖掘该交易。该请求与选定的费用报价和/或与上述方面中接收到的费用报价中选定的费用报价相关联的服务水平相关联。在第三方面，方法包括基于矿工满足来自客户端的选定的费用报价(如以上方面所述)而由矿工创建、处理和挖掘与客户端相关联的区块链交易。

Description

计算机实施的系统和方法

技术领域

本公开大体涉及用于为一个或多个客户端实现支付服务或支付接口的方法和系统。特别地，但不限于，本公开涉及为一个或多个客户端或代表一个或多个客户端实现与区块链或分布式账本相关联的安全且可靠的支付交易，该交易与和客户或付款方实体相关联的数字资产支付有关。

背景技术

在本文档中，我们使用术语“区块链”来包括所有形式的电子的、基于计算机的分布式账本(ledger)。这些包括基于共识的区块链和交易链技术、许可的和未被许可的账本、共享账本、公共和私有区块链及其变型。尽管已经提出并开发了其他区块链实现方式，但是区块链技术最广为人知的应用是比特币账本。尽管为了方便和说明的目的在本文中可能提及比特币，但是应当注意，本公开不限于与比特币区块链一起使用，并且与任何类型的数字资产或数字资产的表示相关联的替代区块链实现和协议落入本公开的范围内。术语“客户端”、“实体”、“节点”、“用户”、“发送方”、“接收方”、“付款方”、“收款方”在本文中可以指基于计算或处理器的资源。在本文中使用术语“比特币”来包括源自或基于比特币协议的任何版本或变型。术语“数字资产”可以指任何可转移资产，例如，加密货币、表示至少一部分财产的代币(token)、智能合约、许可证(即，软件许可证)或媒体内容的DRM合约等。应当理解，本文档通篇使用术语数字资产来表示可能与价值相关联的商品，该价值可以在从一个实体到另一个实体的交易中转移或作为付款来提供。

区块链是一种点对点的电子账本，其被实现为基于计算机的去中心化的分布式系统，该系统由区块组成，而区块又由交易组成。每个交易是一种数据结构，该数据结构对区块链系统中参与者之间的数字资产的控制权的转移进行编码，并包括至少一个输入和至少一个输出。每个区块都包含前一个区块的哈希，因此区块被链接在一起来创建所有交易的永久、不可更改的记录，这些交易自其开始就已经被写入区块链中。交易包含嵌入到其输入和输出中的称为脚本的小程序，这些小程序指定如何以及由谁可以访问交易的输出。在比特币平台上，这些脚本是使用基于堆栈的脚本语言编写的。

为了将交易写入区块链，必须对其进行“验证”。网络节点(矿工)执行工作以确保每个交易有效，而无效交易则被网络拒绝。安装在节点上的软件客户端通过执行其锁定脚本和解锁脚本来对未花费交易(unspent transaction，UTXO)执行该验证工作。如果锁定脚本和解锁脚本的执行被评估为真(TRUE)，则该交易有效，并且该交易然后被写入区块链。因此，为了将交易写入区块链，必须：i)由接收交易的第一节点验证该交易–如果交易经过验证，则该节点将其中继到网络中的其他节点；ii)将该交易添加到由矿工建造的新区块中；以及iii)对该交易进行挖掘，即将该交易添加到过去交易的公共账本中。

一旦作为UTXO存储在区块链中，用户就可以将关联的资源的控制权转移到与另一个交易中的输入关联的另一个地址。该转移通常是使用数字钱包完成的，但这不是必须的。该数字钱包可以是诸如台式机、笔记本电脑或移动终端等计算装置上的装置、物理介质、程序、应用程序(app)，或是与网络工作上的域(例如，互联网)关联的远程托管服务。数字钱包存储公钥和私钥，并且可用于跟踪与用户关联的资源、代币和资产等的所有权，接收或花费数字资产，转移可能与数字资产(例如，加密货币或许可证)、财产或其他类型的资源相关的代币。

尽管区块链技术最广为人知的是使用加密货币实施，但数字企业家正在探索使用比特币所基于的加密安全系统以及可以存储在区块链上的数据来实施新系统。如果区块链可以用于不限于加密货币领域的自动化任务和流程，那将是非常有利的。这样的解决方案将能够利用区块链的好处(例如，永久的、防篡改的事件记录、分布式处理等)，同时在其应用方面更加通用。

当前研究的一个领域是使用区块链来实施“智能合约”。这些是旨在自动执行机器可读和约或协议条款的计算机程序。与以自然语言编写的传统合约不同，智能合约是一种机器可执行程序，其中包含可以处理输入以产生结果的规则，然后可以根据这些结果执行操作。另一个与区块链相关的兴趣领域是使用“代币”(或“彩色硬币”)以通过区块链代表和转移现实世界的实体。一个潜在的敏感或秘密项目可以由没有明显意义或价值的代币表示。因此，代币充当标识符，允许从区块链中引用现实世界的项目。

上述示例或场景涉及某些资产(即，数字资产)的转移，或涉及对用户或实体之间数字资产的控制。因此，需要实现安全且稳健的系统，该系统类似于现有的用于两个实体之间的资金交换(尤其是用于商家与客户之间的数字资产支付)的支付或电子商务系统，并且可以尊重现实世界的资产，具有更好的用户体验、更便宜的商家或收款方成本、以及更安全的安全级别。更具体地，希望利用分布式账本(区块链)技术和提高记录的安全性、透明度和可靠性的优势来提供通用的平台或接口，使任何商家或多个商家能够确保与其相应的客户的数字资产支付可以即时且安全地被挖掘或写入到区块链中，从而提供这种支付的持久、防篡改且可审计的记录。

现在已经设计出这种改进的解决方案。本公开通过提出技术来解决这些技术问题，通过这些技术，针对作为数字资产(例如，加密货币)的接收方的一个或多个客户端(即，商家或收款方实体)的交易可以通过为这种客户端提供应用编程接口(API)的方法、技术和装置而即时写入到区块链中。在这种技术中，矿工将能够动态地或即时地将交易挖掘或写入到区块链中，即，以安全且可靠的方式为客户端提供允许即时交易或零确认交易(0-conf)的服务。

发明内容

在第一方面，本公开提出了用于实现支付服务的方法、装置和系统，以使与客户端相关联的交易能够被写入或存储在分布式账本(即，区块链)中。支付服务被实现为API，一个或多个客户端可以访问该API以处理与相应客户端有关的数字资产支付。在第一方面，包括从多个矿工为客户端获得挖掘费用报价，并基于选定的费用报价处理向区块链提交交易的请求。

在第二方面，本公开提出了用于基于客户端(付款方)与客户端的客户(收款方)之间的数字资产支付来请求与数字资产支付相关联的交易的方法、装置和系统，将在区块链中挖掘该交易。该请求与上述方面中接收到的费用报价中选定的费用报价相关联。

在第三方面，方法包括基于矿工满足来自客户端的选定的费用报价(如以上方面所述)而由矿工创建、处理和挖掘与客户端相关联的区块链交易。

在整个本说明书中，词语“包括(comprise)”或诸如“包括(includes)”、“包括(comprises)”或“包括(comprising)”等变型将被理解为暗示包括所述元素、整数或步骤，或元素、整数或步骤的组，但不排除任何其他元素、整数或步骤，或元素、整数或步骤的组。

附图说明

现在将仅通过示例的方式并参考附图来描述本公开的各方面和实施例，其中：

图1是描绘用于实现支付服务或支付接口的方法的流程图，该支付服务或支付接口用于为一个或多个客户端实现与区块链相关联的数字资产交易，该方法根据第一方面由支付处理器实施。

图2是描绘用于请求区块链交易的处理的方法的流程图，该区块链交易与数字资产支付相关联，该数字资产支付与客户端相关联，其中，该方法根据第二方面由与客户端相关联的一个或多个处理器实施。

图3是描绘处理与针对客户端的数字资产支付相关联的区块链交易的方法的流程图，其中，该方法根据第三方面由与矿工相关联的一个或多个处理器实施。

图4是示出用于证明支付服务或支付接口的系统的示意图，该支付服务或支付接口用于为客户端实现区块链交易。

图5是描绘与第一请求相关联的数据流的示意图，该第一请求用于获得与多个矿工相关联的费用报价。

图6是描绘与第二请求相关联的数据流的示意图，该第二请求用于基于选定的费用报价来提交交易。

图7是描绘与基于区块链交易标识符的状态查询相关联的数据流的示意图。

图8是示出可以实施本公开的各个方面和实施例的计算环境的示意图。

具体实施方式

根据第一方面，本公开提供了一种针对与区块链相关联的交易为一个或多个客户端实现支付服务的计算机实施的方法，该方法由与支付服务相关联的支付处理器实施。在一些实施例中，客户端可以是计算资源或节点，或者是可以与用于接受和/或处理加密货币支付的数字钱包相关联且可以与这种钱包的公钥或公共地址相关联的实体。在一些实施例中，客户端可以表示商家实体或终端(例如，销售点装置)，该商家实体或终端在现实世界中提供商品或服务，并接收这种商品或服务的数字资产支付，但不限于此。在一些实施例中，支付处理器被配置为提供一个或多个客户端的支付接口作为关联的服务或第三方服务。在一些示例中，支付处理器被称为支付聚合器，因为它经由一个或多个用户友好界面为客户端以及矿工提供与区块链相关联的多个支付服务和功能。在一些实施例中，支付处理器被实现为应用编程接口(API)，用于为一个或多个客户端提供基于网络的交互(即，实现为网络服务)，使得通信可以使用基于网络的服务的标准互联网通信协议(例如，HTTPS、TCP/IP等)在互联网上进行。该API是已知的或可供与支付处理器相关联的一个或多个客户端使用或发送/提供给该一个或多个客户端。在一些实施例中，该API可以在进行注册或登记过程时提供给客户端，以访问由支付处理器提供的服务或功能。在一些示例中，API可以经由API用户界面(例如，Swagger)提供或发布以供客户端使用，API用户界面是用于希望访问基于网络的服务的客户端或其他实体的众所周知的API设计和开发工具或接口。

第一方面的方法包括从用于挖掘交易的多个矿工中的每个矿工获得费用报价的步骤。该步骤响应于来自客户端的第一请求而发生，该第一请求是针对与挖掘交易相关联的挖掘费用报价。在一些实施例中，来自客户端的第一请求可以是针对用于挖掘单个交易的费用报价或针对用于挖掘多个交易的(一个或多个)费用报价。在一些实施例中，如果存在多个交易，则支付处理器可以与单独的API或端点相关联，以用于一起接收或处置或处理与两个或更多个(多个)交易相关联的请求。这种端点还可以处理单个或单独的交易。在其他实施例中，同一端点(即，前面提到的与支付处理器相关联的API)用于单个交易以及多个交易。因此，从一个或多个矿工获得的费用报价可以是：(i)从每个矿工针对单个交易获得的费用报价，(ii)来自每个矿工的多个单独的费用报价，一个费用报价针对多个交易中的每一个，(iii)适用于多个交易中的每一个的单个费用报价，(iv)或涵盖用于挖掘客户端在第一请求中请求的所有多个交易的挖掘费用的单个综合费用报价。在一些实施例中，矿工是由一个或多个处理器实施的节点，该一个或多个处理器被委托对锁定脚本和解锁脚本进行验证，以及挖掘交易或将交易写到区块链，如上述背景技术部分中所解释的。例如，如果比特币中本聪愿景(BSV)是要交易或转移的加密货币或数字资产，则矿工可以被称为BSV节点。第一方面的方法包括将获得的费用报价提供给客户端的步骤。在一些实施例中，费用报价与矿工针对将交易挖掘到区块链中而征收或收取的当前费用相关，而不管交易涉及什么或涉及的各方。在其他实施例中，可以基于给定交易来定制费用报价，该给定交易可以在请求中标识出。在一些实施例中，支付处理器可以向客户端提供所有接收到的费用报价，或者可以在获得的费用报价中提供一个或多个推荐的费用报价以提供给客户端。

有利地，通过实现作为API提供给一个或多个客户端(即，商家或收款方实体)的支付服务，这些客户端作为诸如加密货币(如比特币SV(BSV))之类的数字资产的接收方，第一方面的方法通过允许客户端登记或使用由支付处理器提供的网络服务而允许支付交易几乎立即被挖掘(写入区块链中)，或在矿工解决工作量证明的谜题之后尽快被挖掘。通过提供当前的费用报价，给定的矿工理论上同意或承诺将交易添加到要由该给定的矿工以该费用挖掘的下一区块。有利地，这意味着客户端(即，商家实体)不再必须等待来自矿工的任何确认。因此，可以有利地实现与客户端和相应矿工相关联的零确认(0-conf)交易。使用支付服务API的客户端的身份可以有利地保持匿名，同时与客户端相关联的所有交易仍然可以由多个矿工中满足或符合所选或选定的挖掘费用报价的矿工可靠地挖掘。因此，单个客户端或商家可以利用与相应客户端相关联的所有支付的不可修改且可验证的记录的透明度、可靠性和提供的好处，无需实现任何附加的处理或网络资源，而是通过利用提出的支付服务API。

在第一方面的一些实施例中，响应于来自客户端的提交给定交易的第二请求，该给定交易与获得的费用报价中选定的费用报价有关或包括该选定的费用报价，该方法包括向多个矿工中的一个或多个矿工发送请求以生成针对给定交易的区块链交易。在一些实施例中，如上所述，来自客户端的请求可以是提交多个交易，而不是单个交易。在客户端可能是在任何给定时段内处理或处置大量交易的商家实体的情况下，这是有利的，其中，时段可以动态地限定或预定为数分钟、数小时或数天。这有利地允许根据客户端工作负载/性能要求与区块链网络相关联的无缝可扩展性，并且可以基于客户端处置的交易和/或客户的数量。在一些实施例中，如果存在多个交易，则支付处理器可以与用于提交多个交易的单独端点相关联。在其他实施例中，支付处理器的同一API端点用于来自客户端的用于提交单个交易以及多个交易的请求。

在一些实施例中，选定的费用报价是从客户端接收的并且被选择用于给定交易，该给定交易又可能与客户端和另一个节点或实体(例如，客户端的客户，其考虑从客户端购买需要数字资产支付的商品或服务)之间的支付请求或支付交易相关。然后该方法包括从多个矿工中满足选定的费用报价的至少一个矿工接收与区块链交易相关联的输出脚本(例如，UTXO)。例如，在一些实施例中，为了满足费用报价，至少一个矿工应该已经提供有当前费用报价或与当前费用报价相关联，该当前费用报价的值高于或低于选定的费用报价，并且在某些情况下高于选定的费用报价，这取决于一个或多个规则或与客户端相关联的预定标准。然后，该方法包括向客户端发送结果，该结果包括区块链交易的交易标识符(TxID)，该区块链交易与给定交易(即，客户端与客户之间的支付)有关。

有利地，本公开的API可以被实现为REST(Representational State Transfer，表征状态转移)端点，从而允许客户端使用标准互联网或基于网络的协议(例如，HTTPS)进行通信。此外，有利地，第一方面的支付服务使得与数字资产支付相关联的对应交易能够基于选定的费用报价被即时创建并写入区块链中。基于由客户端或代表客户端的支付处理器选择或所选的选定的费用报价对交易进行挖掘，有利地使多个矿工中的至少一个矿工能够几乎即时地或者尽快地挖掘交易或将交易写入区块链中，已经提供了如下保证：给定矿工将以匹配或满足来自客户端的选定的费用报价的当前费用报价对交易进行挖掘。因此，支付服务API具有以下优势：允许即时交易或零确认(0-conf)交易以安全且可靠的方式在区块链中为客户端挖掘，而客户端无需等待来自矿工的交易确实已被添加到区块中并将在区块链中挖掘的确认。这是因为给定的矿工已经表明了，该给定的矿工可以通过响应于第一请求发送用于挖掘交易的当前费用报价来执行挖掘。第一方面的方法降低了与允许即时交易被挖掘相关联的双重花费风险，因为根据第一方面的挖掘将基于客户端所选的或为客户端所选的选定的费用报价进行。因此，只有满足选定的费用报价的矿工才能挖掘交易，并且一旦该交易由满足该费用报价的第一矿工添加到与区块链关联的区块中，该交易就不能被其他矿工挖掘。

根据由支付处理器实施的提供支付服务的第一方面的方法的一些实施例，包括基于确定向客户端提议的推荐费用来提供获得的交易挖掘费用报价，其中，确定的费用可以是从多个矿工获得的费用报价的平均值，或从多个矿工获得的费用报价的最大值。有利地，为了避免双重花费，支付处理器可以推荐的是，以响应于第一请求从多个矿工获得的最高费用值来提交交易。这样，所有矿工都可以被提供有平等的机会以其相应的当前报价费用挖掘该交易。但是，如果推荐的是以等于或高于接收到的所有费用报价的中间值或平均值的费用提交交易，则具有较高报价的矿工可以简单地将该交易保留在内存池(例如，辅助内存池)中，并使用它检查和拒绝交易的任何双重花费。如果选定的费用报价基于推荐的费用报价，或者如果推荐是客户端做出选择的一部分，则类似的优势适用。

有利地，支付处理器推荐的费用报价是客户端然后可选作为选定的费用报价，在一些实施例中，该费用报价是客户端愿意为向客户端提交与数字资产支付相关联的交易支付的最大值。如果客户端是计算不复杂的客户端，或者如果客户端已经预先确定由支付处理器提供推荐，而不是自己选择费用报价，这将是有利的。因此，有利地，客户端可以基于推荐的费用报价来选择费用报价，而不是应用新的或单独的探索或计算来选择费用报价或任意地选择费用报价。

在一些实施例中，当从支付服务(即，支付处理器提供的API)提供推荐或推荐的费用报价时，可以提供该推荐的费用报价，或者可以提供包括推荐的费用报价的所有获得的费用报价，该推荐的费用报价包括标识符。有利地，通过提供推荐以及接收到的所有费用报价，支付处理器为客户端提供了使用推荐的费用报价来提交交易或者从接收到的其他费用报价中选择不同的费用报价的选项。

在一些实施例中，一旦从矿工获得费用报价，第一方面的方法包括由支付处理器将获得的费用报价分类成服务水平或服务类别。在一些实施例中，这可以基于从每个矿工为单个交易或成批的交易获得的费用报价。例如，如果获得的费用报价在动态设定或预定的范围内，则为给定矿工分配特定的服务水平。在一些实施例中，该服务水平可以基于交易费用(例如，这可以是由矿工报价的费用)和中继费用。中继费用是用于使给定矿工考虑验证交易并随后将其中继到区块链网络中的对等节点的最低费用。在某些情况下，这两项费用可能相同。在大多数情况下，中继费用将低于来自给定矿工的报价的交易费用。对于某些区块链，矿工报价的费用通常是设定的或默认的交易费用，其对于任何交易都保持不变。在一些实施例中，对于多个矿工，中继费用是已知的或/或可以是共同的，即默认的中继费用。如上所述，在大多数情况下，该中继费用低于交易费用。有时，它可能与交易费用相同。

在一些实施例中，为从矿工获得的费用报价分配的多个可能的服务水平中特定的服务水平可以是基于与要在区块中挖掘的(一个或多个)交易相关联的优先级。在一些实施例中，特定的服务水平还可以基于由矿工提供的双重花费保护程度，以用于确保拒绝进一步花费与同一交易相关联的资金/数字资产的任何恶意尝试。因此，较高的服务水平可以表示可能需要在短时间段内(例如，少于几分钟，即，在15-20分钟内)并且以更好的双重花费保护挖掘的较高优先级的交易。较低的服务水平可能与较长的挖掘时间(例如，在24-48小时内)相关联，和/或没有为不是由给定矿工挖掘的交易提供的双重花费保护。在一些实施例中，交易的优先级可以由客户端提供，然后基于客户端要求，针对所有交易将服务水平与该客户端相关联。在一些实施例中，双重花费保护可以与一功能相关联，该功能是将没有由给定矿工挖掘的交易存储在辅助内存池中，从而可以执行双重花费检查。

在一些实施例中，服务水平的确定可以基于与配置记录或与支付处理器相关联的文件条目相关联的静态值和规则。在这种情况下，可以在支付处理器处设置这些用于分配服务水平的值。在其他实施例中，可以添加新值或规则或修改配置记录，以进一步限定与给定服务水平相关联的特征。这可以是对上述与给定服务水平相关联的交易优先级和双重花费保护中的一个或多个的补充，或在某些情况下代替上述与给定服务水平相关联的交易优先级和双重花费保护中的一个或多个。然后可以与为分配服务水平而获得的费用报价进行比较。

在一些实施例中，与给定服务水平相关联的交易费用可以动态分配或预定为支付处理器为该服务水平默认推荐的或选定的费用。在一些实施例中，该推荐的或选定的费用然后可以连同给定矿工提供的服务水平指示符一起发送到客户端。在一些实施例中，与每个服务水平相关联的费用可能已经为客户端所知或与客户端商定好。例如，在某些情况下，可以预先商定基于客户端要求的服务水平以及针对交易的与客户端相关联的选定的费用。这可以基于外部服务水平协议，也可以在客户端注册使用支付处理器提供的服务或功能时进行设置。在一些实施例中，客户端可以为每个交易选择服务水平以及费用，或者在成批的多个交易的情况下，为该批交易选择服务水平以及费用。

在一些实施例中，由支付处理器预先分配或推荐或选择的服务水平可以是基于作为第一请求的一部分从客户端接收到的一个或多个服务要求。在一些实施例中，服务水平与选定的/推荐的报价以及用于创建区块链交易的请求一起被提供或标识给矿工。

有利地，基于然后可以与相应矿工相关联的限定的服务水平集合的挖掘费用分类确保了将应用于挖掘交易的挖掘费用金额的透明度和标准化，以及与给定矿工相关联的表现的透明度，该给定矿工用于以指定的服务水平挖掘交易。当要在区块链上发布或提交的交易数量随着区块链用于可能的应用扩展而增加时，这种限定数量的服务水平的分类确保了预期针对服务收取费用的透明度和更高的可见性，以及确保了矿工提供防止双重花费所需的保护级别。这对于确保由与区块链相关联的支付处理器处置的客户端、矿工以及每个客户端/矿工的交易的数量的指数增长的无缝可扩展性是重要的。目前，利用所有现有的矿工费用机制，无法保证或不可行的是，报价的费用率实际上会提供0-conf安全性。

在一些实施例中，一旦支付处理器基于默认的或限定的或已知的中继费用进行分类，这种分类就可以用于或应用于矿工以进行未来的交易。此外，有利地，这种分类还可以促使矿工为挖掘交易提供更好或更具竞争力的费用报价，以便它们可以与适合给定客户端的不同或更好的服务水平相关联，同时坚持挖掘满足费用报价的交易(即，首先看到的要挖掘的交易)。

此外，有利地，服务水平分类允许客户端以及矿工能够基于服务水平对交易进行区分。目前，不存在区分交易并以不同价格为不同客户端对不同类型的交易进行定价的机制。此外，有利地，上述由支付处理器基于服务水平执行的分类允许或使得这种分类能够在不需要对矿工节点配置进行任何修改的情况下实现。这是因为提出的与服务水平相关联的机制使用支付处理器的API将费用评估外部化到支付处理器，而不是矿工或验证模式，因此易于实现，适用于客户端和矿工，并极大地有助于区块链(例如，BSV区块链)的可扩展性。

在一些实施例中，该方法包括验证多个矿工中提供相应费用报价的给定矿工的身份的步骤，其中，基于与给定矿工相关联的数字签名来验证身份。包括与每个矿工相关联的私钥和公钥(或公共地址)的加密密钥对可用于验证费用报价确实源自给定矿工，即，通过私钥签署的数据只能使用对应的公钥来恢复或验证。如果基于数字签名进行验证，则可以使用和实现标准公钥基础设施(PKI)技术。

在其他实施例中，附加地或替代地，与给定矿工有关的标识符可以用于验证矿工的身份。在一些实施例中，该方法包括支付处理器，例如，矿工ID(MinerID)。在一些实施例中，所述标识符可以与给定矿工的信誉指标相关联。在一些实施例中，矿工ID可以基于矿池，给定矿工是该矿池的一部分，或该矿池可以特定于给定矿工。信誉指标与矿工表现的度量有关。例如，在一些示例中，该信誉可以基于给定矿工过去如何以报价的费用执行或挖掘交易。例如，如果矿工定期以该矿工报价的费用或在该费用的可接受范围内挖掘交易，则信誉指标可以例如通过更高的值来指示良好的信誉。在一些实施例中，矿工的信誉分数或指标可以由通信地耦合到矿工的至少一个支付处理器计算、维护和管理。

在一些实施例中，由支付处理器实施的第一方面的方法可以包括基于矿工签名来验证从多个矿工中的给定矿工获得的费用报价的步骤，该矿工签名不同于用于使用PKI技术验证给定矿工的身份的数字签名。支付处理器用于验证步骤的矿工签名有利地指示或用作矿工的承诺，该承诺用于挖掘提供给支付处理器的相应费用报价的交易。矿工签名的存在还可以有利地用于确认矿工将拒绝任何冲突的交易。因此，基于矿工签名进行验证的步骤有利地充当了如下保证：给定矿工将在区块中包括交易以进行挖掘，并且将不包括任何冲突的交易。在一些实施例中，基于给定矿工提供的这种保证来监测给定矿工的表现可以限定或影响与给定矿工相关联的矿工信誉或分数。

在一些实施例中，由多个矿工中的每个矿工提供的费用报价作为包括费用报价的值的数据类型而提供给支付处理器。在一些实施例中，数据类型为JavaScript对象表示法(JSON)对象格式。

在一些实施例中，在支付处理器处从至少一个矿工接收到的输出脚本是与至少一个矿工的内存池相关联的未花费交易输出(UTXO)，该UTXO包括区块链交易的交易标识符(TxID)，其中，区块链交易与客户端和客户之间的数字资产支付有关。

在一些实施例中，为了使客户端能够有利地标识或跟踪与和客户的给定支付交易相关的区块链交易或与客户端相关联的任何交易，该方法包括向多个矿工发送请求以获得针对交易标识符的对应区块链交易的步骤，该请求由支付处理器响应于来自客户端的与交易标识符相关联的状态查询而发送到至少一个矿工。作为响应，支付处理器获得先前从多个矿工中的至少一个矿工生成的对应区块链交易。基于至少一个矿工对区块链交易的挖掘状态，该方法包括向客户端发送与获得的区块链交易有关的状态结果的步骤，该获得的区块链交易与交易标识符相关联。结果可以指示区块链交易是已经被挖掘(即，完成)，还是由于某种原因被拒绝，还是因为可能已经在该给定矿工之前被多个矿工中的另一个矿工挖掘而无效。这有利地避免了在不同的矿工针对特定交易完成挖掘的情况下的双重花费。在一些实施例中，矿工可以维护其尚未添加到区块或尚未在辅助内存池中挖掘的交易，该辅助内存池可以是或表现为替代或附加的内存池，与和矿工相关联的主内存池分开。辅助内存池可以是临时内存池，以便可以针对双重花费对TxID进行检查。这有利地确保了即使交易未由给定的矿工挖掘，它仍然保留在辅助内存池中，并在将来用于检查和拒绝双重花费。在给定矿工的辅助内存池中保留没有由给定矿工挖掘或打算进行挖掘的交易，可能存在时间限制。在一些实施例中，存储在辅助内存池中的交易可以与到期时间相关联，在到期时间之后它们将被清除。在一些实施例中，可能存在与矿工将给定矿工未挖掘的交易存储在其相应的辅助内存池中相关联的单独费用。如上所述，在费用报价被分类成服务水平的情况下，辅助内存池与提供双重花费保护的矿工相关联。

在一些实施例中，如上所述，来自客户端的请求可以是一起成批次地查询多个交易的状态，而不是每次查询单个交易的状态。类似于提交多个交易到区块链进行挖掘；在单个状态查询请求中一起查询多个交易是有利的，特别是在客户端可能是处理或处置大量交易并已提交多个交易以进行一次性处理的商家实体的情况下。这有利地允许系统根据客户端的要求无缝扩展，并且可以基于客户端处置的交易和/或客户的数量。在一些实施例中，如果存在多个交易，则支付处理器可以与用于查询多个交易的单独端点相关联。在其他实施例中，支付处理器的同一端点用于来自客户端的查询单个交易以及多个交易的请求。

在一些实施例中，第一方面的方法还包括提供与支付处理器相关联的应用编程接口(API)转换器的步骤，以执行以下步骤：接收针对费用报价的第一请求、用于提交与客户端的数字资产支付相关联的交易的第二请求、和/或以超文本传输协议安全(HTTPS)格式来自客户端的针对交易的状态查询；然后将这些转换成远程过程调用(Remote ProcedureCall，RPC)格式，然后将RPC发送到多个矿工。这是有利的，因为它允许客户端经由HTTPS使用基于网络的API来传达与区块链相关联的请求，并无缝地提供与多个矿工的互操作性，该多个矿工不使用用于网络服务的互联网协议通信标准进行通信。例如，所有现有的BSV矿工或实现方式都使用远程过程调用。在本实施例中实现的API转换器不限于HTTPS到RPC和RPC到HTTPS的转换，或其他基于网络的协议到各个矿工支持的替代通信协议，或也可以设想到的给定加密货币或数字资产的网络。在反向流路径中，第一方面的方法还包括以RPC格式从多个矿工中的一个或多个矿工接收与对应的区块链交易相关联的响应，并相应地使用HTTPS为客户端转换相应的响应。因此，当客户端(收款方)和矿工使用不同的无线数据通信协议和机制时，通过支付处理器有利地实现提出的接口，能够实现无缝通信以将交易提交到区块链。

在一些实施例中，可以提供与支付处理器相关联的API网关。在这样的实施例中，上述API转换器可以与API网关相关联。此外，在一些实施例中，API网关还可以在一个或多个计算装置中实现，以执行/负责包括但不限于以下中的一个或多个的功能：

-缓存交易

-在矿工节点故障的情况下执行弹性功能

-记录一个或多个端点或URL，这些端点或URL可用于向支付处理器和/或客户端和/或矿工节点发送消息或通知/从其接收消息或通知

-提供弹性功能，包括跟踪由于某种原因未能提交的交易。在一些示例中，这可能包括由支付处理器保存或设置的可配置参数；以及清除那些已过期的被跟踪的交易的机制。API网关还可以与在失败场景下重新提交交易的功能相关联，从而提供用于真正交易的错误处置的功能，并区分双重花费。

根据第二方面，本公开提供了一种用于处理与区块链相关联的交易的方法，该方法由与客户端相关联的一个或多个处理器实施，客户端通信地耦合到至少一个支付处理器，该至少一个支付处理器为客户端实现支付服务。在一些实施例中，支付处理器被配置为实施上述第一方面的方法和相关联的实施例。由客户端(即，商家)实施的第二方面的方法包括向至少一个支付处理器中的支付处理器发送第一请求的步骤，该请求与要经由支付处理器从多个矿工获得的用于挖掘交易或多个交易的一个或多个费用报价有关。如上所述，获得的费用报价与挖掘任何交易相关，或者可能特定于与来自客户的数字资产支付相关的给定交易。如上所述，第一请求还可以指示挖掘所需的服务水平。

在第二方面的一些实施例中，响应于从支付处理器接收到一个或多个费用报价，该方法包括在一个或多个接收到的费用报价中选择费用报价。如第一方面所述，选定的费用报价可能基于或可能不基于支付处理器做出的推荐。然后，第二方面的方法包括从客户请求数字资产支付和/或处理来自客户的数字资产支付，该请求与选定的费用报价相关联。在一些实施例中，该请求类似于客户端向客户发出的针对数字资产支付的发票或支付请求。例如，客户端可能是与数字钱包相关联的咖啡店终端，并且客户可以响应于该请求而为咖啡支付例如2聪，该客户也与数字钱包相关联。由于现在选择了选定的费用报价，因此可以将其添加到来自客户的支付请求。然后该方法包括向支付处理器提交针对给定交易的第二请求，该给定交易与上述客户支付相关联，该提交是基于用于挖掘给定交易的选定的费用报价。在一些实施例中，选定的费用报价被清楚地指示或包括在第二请求中，使得支付处理器能够有利地标识可以以选定的费用报价或低于选定的费用报价挖掘交易的矿工，或者附加地或替代地，矿工能够标识他们是否满足选定的费用报价。

如上所述，在一些实施例中，客户端可以基于从支付处理器接收到的最高费用报价的值来选择费用报价，或者可以基于处于或接近接收到的费用报价的平均值或中间值来选择费用报价。与任一个选项相关联的优点与上面讨论的相同，即，最大值允许所有矿工都有机会进行挖掘，而其他值将挖掘限制到满足费用报价的一些矿工，因为他们能够以选定的报价或更低的报价来挖掘交易，同时那些无法挖掘交易的矿工(例如，由于报价太高)仍然可以将区块链交易的记录保存在临时存储(例如，辅助内存池)中，使得这可以用于验证给定交易的任何双重花费。

在第二方面的一些实施例中，该方法还包括接收已经由至少一个矿工生成的区块链交易的交易标识符，该区块链交易对应于提交的交易(即，客户端与客户之间的交易)。在一些实施例中，该方法包括发送与获得的交易标识符相关联的状态查询；以及获得与交易标识符对应的区块链交易的状态结果。

和第二方面相关联的优点与以上关于第一方面讨论的那些优点相关。第二方面是对第一方面的补充，但描绘了由客户端实施的方法，请求将交易写入区块链中。在一些实施例中，实施第二方面的方法的客户端可以与至少一个支付处理器通信，该至少一个支付处理器被配置为根据第一方面的方法将支付服务实现为支付API。

此外，本方面的方法有利地允许客户端选择提供给支付服务的费用报价，这为客户端或商家提供了对影响他们的交易将以及时的方式在给定的挖掘费用下被挖掘的控制或确定性，从而为使用提出的支付服务或支付API的客户端挖掘的交易提供了更高的安全性、互操作性、可靠性、效率和及时性。

如上所述，在一些实施例中，由于支付处理器实现的支付服务是API，因此来自客户端的第一请求和/或状态查询是HTTPS GET请求，并且其中，第二请求是HTTPS POST请求。因此，有利地，客户端可以使用标准互联网和基于网络的通信协议来请求将交易挖掘到区块链中。在一些实施例中，以JavaScript对象表示法(JSON)对象格式提供与第一请求和/或第二请求相关联的数据和/或来自客户端的状态查询。

根据第三方面，本公开提供了一种用于处理与区块链相关联的交易的计算机实施的方法，该方法由与多个矿工中的矿工相关联的一个或多个处理器实施，其中，多个矿工通信地耦合到至少一个支付处理器，该至少一个支付处理器为客户端实现支付服务。在一些实施例中，支付服务由支付处理器基于上面与第一方面相关联地描述的方法来实现。在一些实施例中，客户端被配置为实施与如上所述的第二方面相关联的方法。由多个矿工中的矿工实施的第三方面的方法包括以下步骤：响应于针对与客户端相关联的交易的费用报价的第一请求，提供当前费用报价，该当前费用报价与该矿工挖掘区块链中的交易有关。在一些实施例中，可以将费用报价作为数据类型来提供给与客户端相关联的支付处理器。如上所述，第一请求可以与针对任何交易或多个交易的当前费用报价的请求相关，或者可以特定于客户端与客户之间的特定交易。

在第三方面的一些实施例中，响应于来自代表客户端的支付处理器的第二请求，第二请求与在区块链中提交给定交易相关，该给定交易基于选定的费用报价，其中，该部分可以如第一方面和第二方面所述的那样由客户端完成，该方法包括以下步骤。基于确定与给定交易相关联的选定的费用报价满足矿工的当前费用报价，即，确定选定的费用报价等于当前费用报价或在当前费用报价内，给定矿工然后生成与给定交易相关联的对应区块链交易。该方法还包括为创建的区块链交易生成输出脚本(UTXO)，将生成的输出脚本添加到与矿工相关联的内存池，以及将输出脚本发送到支付处理器，其中，输出脚本包括与对应区块链交易相关联的交易标识符TxID。在一些实施例中，响应于针对与交易标识符相关联的状态的请求，矿工包括基于对应区块链交易的当前挖掘状态而返回结果。

和第三方面相关联的优点与以上关于第一方面和第二方面所讨论的那些优点相关。第三方面是对第一方面和第二方面的补充，但描绘了由耦合到支付处理器的多个矿工中的矿工实施的方法，该支付处理器用于为客户端构建可以被写入区块链中的交易。在一些实施例中，实施第三方面的方法的矿工可以与至少一个支付处理器进行通信，该至少一个支付处理器被配置为根据第一方面的方法将支付服务实现为支付API。

在一些实施例中，提供当前费用报价的步骤，和/或发送输出脚本的步骤，和/或返回结果的步骤，被实现为远程过程调用(RPC)。如果例如像BSV比特币网络，矿工被配置为经由RPC对应于无线，则这是有利的。在一些实施例中，第三方面的方法可以包括以下步骤：将RPC从矿工发送到节点连接器以及可选地多个矿工的防火墙，然后通过无线通信网络传播到客户端的支付处理器，以用于矿工池或网络(即，与支付处理器相关联的多个矿工)间的数据流的附加安全性和流线化。此外，有利地，节点连接器可以在与支付处理器相关联的API转换器和池中的一个或多个矿工之间提供安全通信信道。

在一些实施例中，基于确定与给定交易相关联的选定的费用报价不满足矿工的当前费用报价，例如，如果当前费用报价高于选定的费用报价，则该方法包括将与区块链交易相关联的输出添加到辅助内存池，该辅助内存池可以是与矿工相关联的附加的临时内存池。如上所述，这在本文中可以被存储持续某个预定时间段，以便矿工节点可以使用这种临时条目来检查并有利地确保没有与给定交易相关联的双重花费。

本公开还提供了一种计算机系统，包括支付处理器，该支付处理器经由无线通信网络通信地耦合到至少一个客户端和至少一个矿工，该支付处理器与API转换器相关联，该API转换器用于将来自客户端的HTTPS请求转换成针对矿工的RPC请求，反之亦然，由此支付处理器是根据第一方面实现的。该计算机系统还包括客户端，该客户端经由无线通信网络通信地耦合到支付处理器并且能够与至少一个客户进行通信，由此该客户端是根据第二方面的计算装置实现的。该计算机系统还包括多个矿工，每个矿工经由无线通信网络通信地耦合到支付处理器，由此每个矿工是根据第三方面实现的。

在一些实施例中，提供了一种计算装置，该计算装置包括处理器和存储器，该存储器包括可执行指令，该可执行指令由于被处理器执行而使该计算装置执行以上讨论的各方面和/或实施例。

在一些实施例中，提供了一种其上存储有可执行指令的计算机可读存储介质，该可执行指令由于被计算机系统的处理器执行而使计算机系统执行以上讨论的各方面和/或实施例的方法。

现在参照附图通过说明的方式描述一些具体实施例，在附图中相同的附图标记指代相同的特征。

第一方面—支付处理器

图1涉及本公开的第一方面并且描绘了由支付处理器执行的用于为客户端实现支付服务的方法，如上所述。支付处理器通信地耦合到客户端或多个客户端，并且还耦合到多个矿工，这些矿工可以包括多于一个的矿工网络或多于一个的矿池。在一些实施例中，支付处理器可以是客户端的一部分或与客户端相关联地实现。如果客户端是计算复杂的商家销售点(POS)终端，情况就是如此。设想本公开的各方面和实施例涵盖这两种实现方式，即，远程支付处理器或作为客户端的一部分的支付处理器。图4中可以看到示例系统架构，本文稍后将对其进行解释。

在图1中描绘的示例场景中，实施例涉及以下步骤：获得多个挖掘费用报价，基于获得的多个挖掘费用报价中选定的费用报价提交交易，以及发送与交易标识符相关的状态查询，在图1的流程图中，所有步骤都被描述为依次发生并被描述为单个过程。然而，本公开和第一方面不应被认为限于此。以下描述的与步骤102至106中在第一请求中获得费用报价相关的步骤可以独立于其余步骤单独地实施。类似地，与在来自步骤108至114的第二请求中提交交易相关的步骤可以单独实施，并且在与获得费用报价的先前步骤不同的时间实施。同样地，从步骤116开始的与交易状态查询相关的步骤可以在客户端已经知道交易的标识符之后的任何时间实施，并且不需要遵循图1的次序。本文依次示出了所有步骤只是为了便于解释和理解，并且在任何情况下，本公开都不应被认为限于这种次序或场景。

步骤102描绘了接收来自客户端的针对挖掘费用报价的第一请求，该挖掘费用报价与挖掘区块链中的交易相关联。如前所述，第一请求也可能与多个交易相关。为了便于解释和理解，将关于与客户端相关联的第一请求中的单个转换来解释图1，但是本公开不以任何方式受限于此。该步骤表示从多个矿工处收集代表客户端挖掘交易的挖掘费用报价。交易通常与客户端(即，商家计算资源或实体)和客户实体之间发生的数字资产支付相关。如上所述，经由或使用HTTPS协议接收第一请求，并以JSON格式接收来自客户端的该第一请求。支付处理器将支付接口实现为用于客户端的应用编程接口(API)，因此当API被实现为网络服务时，可以接受和处理HTTPS。API端点可供客户端使用。在第一请求中有多个交易的情况下，可以使用支付处理器的同一API端点或者单独的API端点。

例如，在一些实施例中，支付处理器可以使用诸如REST接口之类的基于标准的接口设计来实现支付服务。REST是用于开发网络服务和基于网络的交互的架构模式。RESTAPI设计标准可以使用以下命令处理HTTPS请求和通信：

本文将主要讨论GET和POST HTTPS请求，但本申请不限于这些命令。在该步骤102中，支付处理器接收到的第一请求可以是GET getFeeQuote形式的HTTPS请求。

在REST API背景下的资源是具有类型、关联数据、与其他资源的关系以及对其进行操作的方法集的对象。在一些实施例中，支付服务由支付处理器提供为API实现方式，以经由应用接口访问区块链或分布式账本(例如，比特币SV(BSV)区块链)的状态，并触发可以改变该状态的操作，并将其暴露为REST API。因此，支付处理器可以被视为针对一个或多个客户端的REST端点。仅为了便于解释，将自始至终讨论一个客户端(或商家)和一个支付处理器，但本公开不限于此。因此，客户端可以经由HTTPS与支付服务进行通信，此外，客户端可以有利地匿名访问支付处理器或由支付处理器实现的支付服务。在一些实施例中，当存在多于一个的客户端和多于一个的支付处理器时，客户端将负责基于例如客户端可能与运行支付处理器的一个或多个第三方之间的任何协议来定位或联系正确或预期的支付处理器或REST端点。

步骤104描绘了从多个矿工中的每个矿工获得用于挖掘交易的费用报价。在该步骤中，支付处理器可以轮询或联系耦合到支付处理器的所有矿工，并要求其返回用于挖掘交易的当前费用报价，即，在验证锁定脚本和解锁脚本后将交易写入到区块链。目前，一些区块链网络(例如，BSV网络)支持经由远程过程调用(RPC)的通信。因此，在这种情况下，与支付处理器相关联的API转换器用于将HTTPS第一请求(即，GET getFeeQuote)转换为RPC第一请求(即，RPC getFeeQuote())，反之亦然。在需要支持这种BSV节点实现方式的实施例中，或在仅支持RPC的其他实现方式中，这种转换是必要的。如上所述，API转换器可以是与支付处理器相关联的API网关或网关处理器的一部分，其中，HTTP/RPC转换只是API网关提供的功能之一。以RPC格式发送到矿工的getFeeQuote()的目的是通知客户端每个矿工收取的费用。不需要输入参数，但可能需要实现与RPC getFeeQuote()相关的RPC接口，使得该命令以JavaScript对象表示法(JavaScript Object Notation，JSON)对象的形式返回来自每个矿工的数据类型，即，MinerFeeQuote(矿工费用报价)，其包含从每个矿工收集到的费用相关数据。

从每个矿工收集到的与获得的费用报价相关的数据可以被定义为JSON对象，如在下面的示例中给出。

从每个矿工返回的JSON对象FeeQuotes如下所示。尽管示出了与单个交易相关的示例，但本公开不限于此，并且同样适用于表示多个交易的挖掘费用的费用报价：

在一些实施例中，JSON FeeQuotes对象包含矿工详细信息和收取的费用的数组，而MinerFeeQuote是包含矿工和从单个矿工接收到的费用数据的JSON结构。上面的JSON对象中的一些术语解释如下。

CurrentHighestBlockHash可用作标记，以在getFeeQuote()被调用时标识区块链已增长到的点处的区块哈希。

MinerSignature可以包含同意保证该交易的矿工的签名，如上所述。这与用于验证矿工的身份的数字签名不同。通过这样做，矿工可以保证的是，该矿工将很快把交易包含在区块中，并且可选地，将不包括任何冲突的交易。如果矿工不愿意保证交易，则可以将其设置为空(Null)。

SignatureTimestamp指示矿工保证以规定的当前费用挖掘交易的时间，即，从该时间点起保证该费用直到被取代为止。如果客户端随后调用getFeeQuote()，则该时间被取代。

MinerReputation与矿工的表现的度量(即，矿工以承诺或报价的当前费用执行交易的情况如何)相关。信誉分数/指标可以由每个支付处理器计算、维护和管理。

Miner ID可以是当区块被挖掘时添加到创币(coinbase)交易的两部分数据。如果不存在矿工ID，则支付处理器可以将用矿工ID为“空(NULL)”来标记该矿工或简单地留空。

在每个MinerFeeQuote中，FeeTypes对象的数组可以用于捕获当前可用的各种费用类型。将来可以引入费用类型，而无需对支付处理器提供的getFeeQuote()接口进行任何改变。所有交易可以具有一个FeeTypes数组。

步骤106描绘了由支付处理器将获得的费用报价提供给客户端。在一些实施例中，这可以包括由支付处理器确定的推荐费用报价。如上文关于第一方面所述，该步骤可以包括通过API转换器从RPC到HTTPS的转换，使得客户端将能够使用基于网络的API访问详细信息。

在步骤108中，接收来自客户端的第二请求，该第二请求是提交与获得的费用报价中选定的费用报价有关的给定交易的请求。在一些实施例中，给定交易基于客户响应于来自客户端的支付请求而向客户端进行的数字资产支付。例如，如果客户端是咖啡店中的商户终端，则这可能是中本聪(satoshis)或其他类型的数字资产支付以换取一杯咖啡。在该步骤中，客户端经由支付处理器实现的支付服务API请求将该数字资产支付写入区块链中。

如上所述，在一些实施例中，来自客户端的第二请求可以是提交多个交易的请求。与提交多个交易相关的请求可以被发送到同一支付处理器API或与支付处理器相关联的另一个端点。与支付处理器相关联的所有端点都将告知或提供给客户端。在多个交易的情况下，选定的费用报价可以与挖掘所有多个交易相关联(即，选定的费用是用于挖掘成批次的多个交易中的10个交易的10中本聪(satoshis))；或针对选定的费用报价为挖掘多个交易中的每个交易所选择的费用(即，选定的费用)是用于挖掘批次中10个交易中的每个交易的1中本聪(satoshis)/交易。

在多个交易的情况下，第二请求的主体可以是原始交易数组的形式。该端点用于向矿工发送多个原始交易，以包括在矿工创建的下一个区块中。

请求主体的示例格式如下所示：

示例响应可以如下：

在第二交易中选定的费用报价可以基于支付处理器做出的推荐，或者可以由客户端针对一个或多个交易来选择。

如上所述，选定的报价可以基于所有获得的费用报价的平均值或最大值。

如上所述，在一些实施例中，选定的费用报价可以是基于服务水平的报价，其中，获得的费用报价由支付处理器分类成服务水平。

在一些实施例中，将与每个服务水平相关联的挖掘费用以及特征/功能可以由支付处理器预定。然后，基于给定客户端的要求，可以为该客户端分配服务水平和相关联的挖掘费用(选定的费用报价)。客户端要求可以基于客户端处理的交易类型。服务水平可以例如基于外部服务水平协议预先分配或预先商定。因此，预先分配可以基于与交易相关联的优先级以及满足选定的费用报价/服务水平的矿工提供的防止双重花费的保护级别。

因此，针对要挖掘的交易，与服务水平相关联的费用可以由支付处理器预定并与客户端商定。如果客户端还没有选择服务水平或费用，则可以将获得的费用报价的详细信息提供给客户端以供选择，获得的费用报价被分类成服务水平，每个服务水平与其相应的费用相关联。

或者，也可以由支付处理器推荐服务水平和相关联的费用作为选定的费用报价。服务水平的这种推荐可以基于从与该客户端相关联的早期交易中获知的数据和统计。或者，在某些情况下，支付处理器基于来自客户端的输入提供推荐。

如上所述，在一些实施例中，基于获得的费用报价和矿工用于挖掘一个或多个交易的最小可能费用(即，中继费用)，将服务水平分配给矿工。因此，有利地，可以针对不同的交易类型或用例应用不同的费用。在一些实施例中，交易类型或服务要求可以由客户端获得。

服务水平也可以由支付处理器基于从矿工获得的交易费用报价的知识以及矿工的中继费用的知识而直接确定。这使支付处理器能够对费用进行分类，甚至可选地，为客户端推荐费用，无论客户端是否已指示最低服务水平。一旦获得费用，支付处理器就可以通知客户端可以从任何选定/推荐的交易费用预期的服务水平。这些可以包括与服务水平相关联的属性。

下表提供了矩阵示例，支付处理器可以使用该矩阵来基于中继费用和交易(txn)费用在服务水平(SL)0-4中对费用进行分类。在该示例中，费用单位以每字节聪表示，但是本公开不限于此。对于某些交易，这可以以每数据字节聪表示。可以使用其他数字资产或加密货币。该矩阵可以存储在与支付处理器相关联的静态或动态配置文件或条目中，使得可以基于该逻辑对服务水平进行分类。

在下面的示例中，已经针对服务水平考虑了两个特征：(i)交易的优先级，以及(ii)防止双重花费提供的保护。然而，本公开不限于此，服务水平可以基于其他特征和属性。

矿工	中继费用	txn费用	服务水平
				0	＜0.20	＜0.3	SL0
1	0.20	0.3	SL1
				2	0.25	0.4	SL2
3	0.25	0.5	SL3
				4	＞0.25	＞0.5	SL4

由此，在该示例中：

对于服务水平(SL)0(即，SL0)—没有矿工保证挖掘，也没有双重花费保护，其中，minRelayrfee<0.20中本聪(satoshis)，即，不保证任何挖掘服务。没有附加的双重花费保护，因为费用不涵盖包括交易，其不会在辅助内存池中被挖掘以检查双重花费。

SL1—低优先级，无双重花费保护，如果(minRelayrfee)＝<0.20中本聪(satoshis)并且(txnfee)＝<0.3中本聪(satoshis)，即，该交易可能不会优先于挖掘队列中的其他交易被挖掘，因此可能(例如)再过24小时左右才被挖掘。没有附加的双重花费保护，因为费用不涵盖包括交易，其不会在辅助内存池中被挖掘以检查双重花费。

SL2—中等优先级，存在双重花费保护，如果(minRelayrfee)＝0.25中本聪(satoshis)并且(txnfee)＝<0.4中本聪(satoshis)，即交易优先于挖掘队列中的一些，但不是全部或大部分其他交易，因此可能在(例如)12到24小时左右的时段内被挖掘。有附加的双重花费保护，因为费用确实涵盖包括交易，其不会在辅助内存池中被挖掘，这将用于检查双重花费。

SL3—高优先级，存在双重花费保护，如果(minRelayrfee)>＝0.25中本聪(satoshis)并且(txnfee)＝0.5中本聪(satoshis)，即，交易优先于挖掘队列中的大多数其他交易，因此可能在(例如)12小时左右的时段内被挖掘。有附加的双重花费保护，因为费用确实涵盖包括交易，其不会在辅助内存池中被挖掘，这将用于检查双重花费。

SL4—最高优先级，所有矿工都将进行挖掘，完整的双重花费保护，其中，txnfee>0.5中本聪(satoshis)，即，交易优先于挖掘队列中的所有其他交易，因此可能在(例如)2小时左右的时段内被挖掘。有附加的双重花费保护，因为费用确实涵盖包括交易，其不会在辅助内存池中被挖掘，这将用于检查双重花费。

在这种情况下，上述步骤104中列出的JSON对象FeeQuotes还可以包括：

在一些实施例中，第二请求是以POST submitTransaction(Tx)形式的HTTPS请求，其中，在一些实施例中Tx是JSON格式的对象，与针对客户端与客户之间的支付的给定交易相关联。因此，Tx(JSON对象)包含在区块链上创建交易所需的数据，客户端可以在向支付处理器提交第二请求以传递给矿工之前将该交易提供或构建为JSON结构。

步骤110描绘了向多个矿工中的一个或多个矿工发送请求以生成对应于步骤108中的给定交易的区块链交易的步骤。在该步骤中，支付处理器在一些实施例中将先前步骤中的HTTPS POST请求转换为RPC请求以提交给矿工。这可以通过请求RPCcreateRawTransaction(Tx)来完成，其中，Tx包括与给定交易相关联的数据，作为JSON对象给出，如步骤108中讨论。RPC createRawTransaction(Tx)是RPC调用，用于创建花费给定输入并创建新输出的交易，其中，输出可以是地址或数据。RPC请求可以发送到多个矿工，或者发送到步骤108中满足或符合来自客户端的选定的费用报价的矿工。如上所述，提供了等于或低于选定的费用报价的当前费用报价的矿工被认为是满足选定的费用报价的要求，因为他们可以以其相应的当前报价的费用挖掘交易。作为响应，满足选定的费用报价的矿工创建了与给定交易对应的区块链交易。在一些实施例中，对应于给定交易的十六进制编码的原始交易被返回给支付处理器。

在步骤112中，在支付处理器处接收与对应的区块链交易相关联的输出或输出脚本，该区块链交易已由多个矿工中满足选定的费用报价的至少一个矿工创建。输出脚本可以是与相应的矿工创建的对应区块链交易相关联的UTXO。在一些实施例中，UTXO也可以存储在满足选定的费用报价的相应矿工的内存池中。该步骤中的输出将包括由相应的矿工创建的对应区块链交易的交易标识符(TxID)。TxID是对提交给矿工内存池的十六进制编码的交易的引用，然后由支付处理器相应地映射到区块链交易。

然后可以即时或稍后挖掘该区块链交易，以在当前的费用报价下完成挖掘过程。在某些情况下，创建的交易可能不会被挖掘，因为另一个矿工已将其写入区块链中，或者可能由于某些原因(例如，双重花费或延时或无效)而处于挂起状态或被拒绝。

步骤114描绘了向客户端发送交易结果TxResult，该结果包括区块链交易的交易标识符TxID，该区块链交易由相应的矿工对应于步骤108中的给定交易创建。在一些实施例中，交易结果TxResult是JSON对象，其基于对应区块链交易的详细信息而使用HTTPS协议从支付处理器发送到客户端，该对应区块链交易在步骤110和112中由满足选定的费用报价的相应矿工创建。

客户端的TxResult对象中存在的详细信息的示例如下给出：

JSON对象TxResult针对相应的矿工如下所示，并且包括步骤104中作为FeeQuotesJSON对象的一部分讨论的一些术语和对象。

上述ReturnResult可能包含以下可能的值之一，这些可能的值如下所示：

·Submitted—没有问题，交易被提交到内存池

·Rejected_DS—由于双重花费而被拒绝–DoubleSpendTxID不能为空

·Rejected_Policy—由于违反政策而被拒绝

·Rejected_Invalid—由于交易无效而被拒绝

·Rejected_FeeTooLow—费用太低，所以矿工不会在区块中包括Tx

·Rejected_KeepInMemPool—Tx被拒绝，但保留在内存池中以检查双重花费。

在与客户端关联并使用与支付处理器关联的同一或单独的端点一起提交的多个交易存在的情况下，则返回到第二请求的响应主体可以为以下JSON格式：

在一些实施例中，对于在第二请求中提交的多个交易，响应主体提供以下内容：

-响应对标头信息和交易级别(有效载荷)信息进行分组

-响应报告每个交易的返回结果(或当前状态)

-响应返回错误计数：count(returnResult<>success)

-响应返回错误阈值，其中，如果错误计数大于X，则停止交易的进一步处理，并且拒绝在第二请求中提交的所有多个交易，其中，X是可配置参数，其可以是预定的或动态定义的。如果在第二次请求中一起提交的成批的多个交易由于错误计数大于X而被矿工拒绝挖掘，则可以分配具有适当的代码描述的错误代码。

下面列出了JSON信封(JSON envelope)术语及其功能说明：

字段	功能
		有效载荷	主要数据有效载荷—基于交易级别信息
签名	有效载荷字符串上的签名
		公钥	用于验证签名的公钥
编码	编码类型
		mine类型	多用途互联网邮件扩展类型

下面给出了有效载荷或消息字段返回的示例：

步骤116描绘了从客户端接收与交易标识符TxID相关联的状态查询以继续发送到多个矿工的步骤。该步骤开始可以与上述在多个挖掘费用报价中选择费用报价之后安排提交交易的步骤异步进行，并且不认为是对于第一方面的操作必不可少的。从步骤116开始的实施例涉及客户端希望知道在步骤108中做出的一个或多个第二请求的状态的场景。

步骤116使客户端能够查询交易的状态，客户端已经经由步骤108中讨论的HTTPSPOST submitTransaction(Tx)将这些交易提交给支付处理器。因此，该步骤中的TxID可以对应于针对任何给定交易进行的任何第二请求，该给定交易与客户端及其客户之间的数字资产支付相关。如上述步骤所讨论，从客户端使用HTTPS作为传输协议来接收状态查询，该查询以JSON格式(例如，GET queryTransactionStatus(TxID))发送，进而被转换为RPC请求(RPC getRawTransaction(TxID))以发送到多个矿工中的一个或多个矿工。

在一些实施例中，如果客户端在第二请求中提交了多个交易，如上所述，则客户端可以在单个查询交易状态请求中查询多个交易的状态，而不是针对每个交易发送单独的请求。与查询多个交易的状态相关的请求可以发送到同一支付处理器API或与支付处理器相关联的另一个端点。与支付处理器相关联的所有端点将被告知或提供给客户端。这可以在客户端注册与支付处理器相关联的服务时提供。如上所述，可以使用诸如Swagger之类的已知开放API工具来向客户端提供API。

在查询多个交易的情况下，第二请求的主体可以是以交易标识符(TxID)数组的形式。请求格式的示例如下所示：

在步骤118中，支付处理器从多个矿工中与创建和/或处理和TxID相关联的区块链交易相关联的相应矿工接收响应。在一些实施例中，上述RPC getRawTransaction(TxID)可以包括Verbose参数，该参数可能与设置为1的自变量相关。在这种情况下，如果成功，则从相应矿工返回的结果在一些实施例中将为JSON格式，包含在步骤110和112中解码的对应区块链交易。这有利地提供了捕获和处理其中数据的灵活性。如果Verbose参数被设置为0，则不是JSON数据类型或文档格式，而是十六进制编码的交易被返回到支付处理器。如果没有找到与TxID相关的这种交易，则可以返回空(Null)，这进而将导致ReturnResult对象被设置为“未知”。任何其他返回的错误也可以由矿工经由ReturnResult和ResultDescription对象报告给支付处理器。这些对象已关于步骤114进行了指示。

在步骤120中，与TxID有关的TxResult被返回给客户端，使用HTTPS发送响应。这表示与步骤116中客户端在状态查询中发送的给定TxID相关联的挖掘结果。下面给出了从支付处理器发送到客户端的TxResult的示例。JSON对象TxStatus如下所示：

如果交易已被相应的矿工成功挖掘并标记为Confirmed(已确认)(即，添加到区块)，则可以填充BlockHash和MinerID。如果矿工未设置其MinerID，那么它将被设置为“空(NULL)”。

那么ReturnResult对象可以包含以下挖掘结果之一：

·Submitted—没有问题，交易被提交到内存池

·Confirmed—交易已确认–确认不能为0或空(Null)

·Rejected_DS—由于双重花费而被拒绝–DoubleSpendTxID不能为空

·Rejected_Policy—由于违反政策而被拒绝

·Rejected_Invalid—由于交易无效而被拒绝

·Rejected_FeeTooLow—费用太低，所以矿工不会在区块中包括该Tx

·Rejected_KeepInMemPool—Tx被拒绝，但保留在内存池中以检查双重花费

·Unknown—交易未被看到或不存在—可能的情况下是具有提供的TxID的交易在内存池或区块链中不存在。如果是这样，这应该在ResultDescription中说明。

在与客户端关联的要使用和支付处理器关联的同一或单独的端点一起查询的多个交易存在的情况下，则返回的响应主体可以为以下JSON格式：

在一些实施例中，对于查询的多个交易，响应主体将标头信息和交易级别(有效载荷)信息分组在一起

字段	功能
		有效载荷	主要数据有效载荷—基于交易级别信息
签名	有效载荷字符串上的签名
		公钥	用于验证签名的公钥
编码	编码类型
		mime类型	多用途互联网邮件扩展类型

下面给出了返回的有效载荷或消息字段的示例：

第二方面—客户端

图2涉及本公开的第二方面并且描绘了一种由与客户端相关联的一个或多个处理器执行的方法，其中，客户端通信地耦合到至少一个支付处理器，该至少一个支付处理器实施如关于第一方面所讨论的方法。如上所述，支付处理器为客户端实现与图1相关地讨论的支付服务或支付API。

在图2中描绘的示例场景中，实施例涉及以下步骤：获得多个挖掘费用报价，基于获得的多个挖掘费用报价中选定的费用报价提交交易，以及发送与交易标识符相关的状态查询，在图2的流程图中，所有步骤都被描述为依次发生，即被描述为单个过程。然而，本公开和第二方面不应被认为限于此。以下描述的与步骤202至206中在第一请求中获得费用报价相关的步骤可以独立于其余步骤单独地实施。类似地，与在来自步骤208至212的第二请求中提交交易相关的步骤可以单独实施，并且在与获得费用报价的先前步骤不同的时间实施。同样地，从步骤214开始的与交易状态查询相关的步骤可以在客户端已经知道交易的标识符之后的任何时间实施，并且不需要遵循图2的次序。本文依次示出了所有步骤只是为了便于解释和理解，并且在任何情况下，本公开都不应被认为限于这种次序或场景。此外，如上面关于图1所讨论，可以针对单个交易每次单独请求和/或获得和/或提交和/或查询费用报价，或者针对成组或成批的要由客户端在单个请求中提交(即，同时提交)的多个交易请求和/或获得和/或提交和/或查询费用报价。为了便于解释和理解，将结合第一请求/第二请求中的单个转换以及与客户端相关联的状态查询来解释图2，但是本公开绝不限于此。

步骤202描绘了向至少一个支付处理器中与客户端相关联以用于提供相应支付服务的支付处理器发送第一请求。如关于图1的步骤102所讨论，该请求与用于为客户端挖掘交易的一个或多个费用报价有关。该第一请求涉及关于步骤102所讨论的HTTPS GETgetFeeQuote。如上所述，该请求可以用于为客户端挖掘任何交易，或者可以是获得用于挖掘与数字资产支付相关的交易的费用报价的请求，该数字资产支付来自与客户端关联的客户。如上所述，在一些实施例中，第一请求还可以包括要挖掘的一个或多个交易所需的服务水平的详细信息。这可能与矿工提供的挖掘速度和/或防止双重花费的保护相关。

在步骤204中，从支付处理器接收多个挖掘费用报价，该费用报价与多个矿工中的每一个的挖掘费用相关，该多个矿工通信耦合到为客户端服务的支付处理器。已结合图1的步骤104讨论了接收到的费用报价的结构和详细信息。

步骤206描绘了在步骤204中接收到的一个或多个费用报价中选择费用报价。在一些实施例中，选定的费用报价可以基于由支付处理器提出的推荐费用报价。在一些实施例中，选择由与客户端相关联的一个或多个处理器进行。如上所述，选定的费用报价可以是获得的费用报价的平均值或中间值，或者从多个矿工获得的费用报价的最大值或辅助内存池中的最高费用报价。因此，客户端可以响应于第一请求而选择从多个矿工获得的最高费用值。这样，所有矿工都可以被提供有平等的机会以其相应的当前报价费用挖掘交易。但是，客户端可以替代地改为选择等于或高于接收到的所有费用报价的中间值或平均值的费用报价，以使具有较高报价的矿工可以简单地将该交易保留在辅助内存池中并使用它来检查和/或拒绝交易的任何双重花费。

步骤208描绘了从与客户端相关联的客户请求数字资产支付和/或处理来自与客户端相关联的客户的数字资产支付的步骤。这可以是支付请求，或者是客户端使用已知方法向客户发送的针对数字资产支付的发票，该已知方法适用于双方相应的数字钱包实现。由于用于将任何交易挖掘到区块链的选定的费用报价是已知的，因此请求可以包括选定的费用报价或与选定的费用报价相关联。

步骤210描绘了发送第二请求以向区块链提交与从客户到支付处理器的数字资产支付相关联的给定交易的步骤。该步骤中的提交是基于步骤206中用于挖掘给定交易的选定的费用报价。该步骤涉及图1的步骤108中客户端向支付处理器发送HTTPS POSTsubmitTransaction(Tx)请求，该请求具有以JSON数据类型格式的给定交易的相关详细信息。

步骤212描绘了接收与提交的交易相对应的区块链交易的交易标识符(TxID)的步骤。如图1的步骤110和112中所讨论，TxID由满足选定的费用报价的至少一个矿工创建。在一些实施例中，这可以与交易结果相关联地发送或作为交易结果的一部分发送，即，TxResult表明针对相应矿工的对应区块链交易的当前挖掘状态。这结合图1的步骤114进行了描述。

步骤214涉及当客户端希望查询先前在步骤210中提交的交易的挖掘状态时，客户端发送状态查询，该交易与客户端和客户之间的支付相关。由于客户端将在步骤212中接收到已提交的交易的TxID，因此该请求可以基于TxID并且格式为HTTPS GETqueryTransactionStatus(TxID)，如图1的步骤116中所述。

步骤216描绘了获得与在步骤214中查询到的交易标识符TxID对应的区块链交易的挖掘状态结果。这可以是以JSON格式，并且在支付处理器接收到对应交易的详细信息之后由支付处理器使用HTTPS发送到客户端。状态结果可以是以TxResult JSON对象的形式，如图1的步骤120中所看到的那样。

第三方面—矿工实现方式

图3涉及本公开的第二方面并且描绘了一种由多个矿工中的矿工执行的方法，其中，多个矿工通信地耦合到至少一个支付处理器，该至少一个支付处理器实施如关于第一方面所讨论的方法。支付处理器为客户端实现与图1相关地讨论的支付服务或支付API。客户端被配置为实施关于图2所讨论的方法。

在图3中描绘的示例场景中，实施例涉及以下步骤：提供多个挖掘费用报价，基于获得的多个挖掘费用报价中选定的费用报价生成/创建区块链交易，以及提供与交易标识符相关的挖掘状态，在图3的流程图中，所有步骤都被描述为依次发生，即被描述为单个过程。然而，本公开和第三方面不应被认为限于此。以下描述的与步骤302和304中响应于第一请求而提供当前费用报价相关的步骤可以独立于其余步骤单独地实施。类似地，与响应于来自步骤308至314的第二请求而生成对应区块链交易相关的步骤可以单独实施，并且在与获得费用报价的先前步骤不同的时间实施。同样地，与步骤316中提供交易状态相关的步骤可以在客户端已经知道交易的标识符之后的任何时间实施，并且不需要遵循图3的次序。本文依次示出了所有步骤只是为了便于解释和理解，并且在任何情况下，本公开都不应被认为限于这种次序或场景。此外，如上面关于图1和图2所讨论，可以针对单个交易每次单独请求和/或获得和/或提交和/或查询费用报价，或者针对成组或成批的要由客户端在单个请求中提交(即，同时提交)的多个交易请求和/或获得和/或提交和/或查询费用报价。为了便于解释和理解，将关于第一请求/第二请求中的单个交易以及与客户端相关联的状态查询来解释图3，但是本公开绝不限于此。

步骤302描绘了从支付处理器接收第一请求，该支付处理器用于代表客户端提供用于挖掘交易的费用报价。该请求与从支付处理器发送的RPC getFeeQuote()请求相关，如关于图1的步骤104所述。

步骤304描绘了提供与多个矿工中的每个矿工相关的用于在区块链中挖掘交易的当前费用报价。费用报价可以以JSON对象FeeQuotes的格式提供，如关于图1的步骤104所述。

步骤306描绘了多个矿工中的矿工接收第二请求的步骤，该第二请求与向区块链提交和客户端相关联的给定交易相关，其中，给定交易基于来自客户端的选定的费用报价。给定交易与图2的步骤210中POST submitTransaction(Tx)中的Tx(即，客户端与客户之间的给定数字资产支付交易)相关。这种从支付处理器接收到的RPC版本是针对给定交易的RPC createRawTransaction(Tx)，如关于图1的步骤110所解释的那样。

步骤308描绘了检查矿工是否满足或符合来自客户端的选定的费用报价。这可以包括确定步骤304中由相应矿工提供给支付处理器的当前费用报价是否等于或低于客户端愿意为挖掘给定交易Tx支付的选定的费用报价。

如果当前费用报价满足选定的费用报价，则在步骤310中创建与给定交易对应的区块链交易。这关于图1的步骤110进行了讨论。在一些实施例中，对应于给定交易的十六进制编码的原始交易被返回到支付处理器。还向支付处理器提供输出脚本或UTXO，如图1的步骤112中所讨论，其中，输出脚本包括交易标识符(TxID)，该交易标识符(TxID)与已由相应矿工创建的对应区块链交易相关联。然后可以将区块链交易的输出脚本(UTXO)添加到与矿工关联的内存池中，以便即时或稍后进行挖掘。

在一些实施例中，如果当前费用报价不满足选定的费用报价，即，如果相应矿工的当前费用报价高于客户端允许或选定的费用报价，则相应矿工可以选择以低于当前费用报价的费用进行挖掘，或者可以选择不挖掘给定交易，因为选定的费用低于其相应的当前报价费用。在相应矿工选择不以较低的选定费用报价挖掘交易的实施例中，在步骤312中，相应矿工可以替代地在与相应矿工相关联的辅助内存池中添加与针对给定交易构建的区块链交易相关的详细信息。在一些实施例中，该交易可以保留在辅助内存池中并用于检查双重花费。存储在辅助内存池中的所有交易都可以具有到期时间，之后它们可以被清除。

假设已经创建了区块链交易，即相应矿工满足客户端设定的选定的费用报价的要求，步骤316涉及相应矿工接收与区块链交易的TxID相关联的状态查询，该区块链交易是为客户端创建的。该状态查询是基于经由API转换器接收到的RPC请求RPCgetRawTransaction(TxID)，如关于图1的步骤116和118所讨论。

在步骤318中，将基于与相应矿工有关的对应区块链交易的当前挖掘状态的结果提供给支付处理器。这可以基于针对TxStatus的JSON对象结构，如关于图1的步骤120所解释。

图4是由支付处理器404提供给客户端402的作为API的支付服务的部署架构的示意图。可以存在多于一个的这种支付处理器404，并且一个或多个支付处理器404也可以作为客户端的一部分实现，或者可以与客户端相关联，或者可以与客户端分开实现并通过诸如互联网之类的通信网络与客户端进行通信。如以上方面所讨论，客户端402与支付处理器404之间的通信使用HTTPS协议。API转换器406也在该示意图中单独示出，但在一些实施例中可以被实现为支付处理器404的一部分。在一些实施例中，API转换器406可以由多个矿工412-1至412-n操作或与多个矿工412-1至412-n相关联地实现。API转换器406允许在将HTTPS请求发送到一个或多个矿工412-1至412-n之前将HTTPS请求转换为RPC请求，该一个或多个矿工412-1至412-n耦合到用于向客户端402提供服务的支付处理器404。API转换器406被示为经由防火墙408连接到矿工412-1至412-n。与矿工412-1至412-n相关联的所有通信都使用RPC。还示出了节点连接器410，用于经由防火墙408将多个矿工412-1至412-n连接到支付处理器404。在一些实施例中，节点连接器可以确保或处理与实现相应支付服务的一个或多个支付处理器相关联的RPC调用，如关于图1所讨论。节点连接器410提供API转换器406与一个或多个矿工412-1至412-n之间的安全通信信道。

可以存在经由API转换器406连接矿工412-1至412-n的一个或多个支付处理器404。客户端402将很可能包括数字钱包应用以获得矿工费用的报价(getFeeQuote)、提交交易(submitTransaction)并查询交易的状态(queryTransactionStatus)，如关于针对单个或多个交易的第一至第三方面所解释的那样。支付处理器404充当客户端402的REST端点，并且客户端可以匿名访问该服务。矿工412-1至412-n可以挖掘一个或多个节点以换取挖掘奖励，在一些实施例中，挖掘奖励可以由区块奖励和矿工费用组成。区块奖励指的是一旦矿工412成功挖掘区块即奖励的BSV或加密货币。矿工费用是矿工412在确认交易并将其添加到新挖掘的区块时接收到的奖励。

图5是描述图4所示架构的组件之间的数据流的示意图，用于实现来自客户端的getFeeQuote命令或模板。这已经在上面关于图1至图3进行了详细讨论，并且图4简单地示意性列出了客户端、支付处理器和矿工的交互以获得挖掘费用报价。当在步骤501中将HTTPS GET getFeeQuote命令发送到支付处理器404时，该流程源自客户端402。在步骤502中，将GET命令发送到API转换器406，在步骤503中，该API转换器406将其转换为RPC命令RPCgetFeeQuote()。在步骤504中，MinerFeeQuote作为JSON对象格式从多个矿工412-1至412-n中的每个矿工412返回到API转换器406，在其又在步骤505中提供给支付处理器404。对多个矿工412-1至412-n中的每个矿工重复步骤502至505，并且在步骤506中，在HTTPS传输中将结果(费用报价)发送到客户端402。

图6是描绘图4中所示架构的组件之间的数据流的示意图，用于实现来自客户端的submitTransaction命令或模板。这已经在上面关于图1至图3进行了详细讨论，并且图4简单地示意性列出了客户端、支付处理器和矿工的交互以提供与针对客户端的支付相关联的区块链交易。当在步骤601中针对客户端402与客户之间的给定交易Tx向支付处理器404发送HTTPS POST submitTransaction(Tx)命令时，该流程源自客户端402。如关于上述方面所提到的，Tx可以与选定的费用报价(图中未示出)相关联。在步骤602中，将POST命令发送到API转换器406，在步骤603中，API转换器406将其转换为RPC命令RPCcreateRawTransaction(Tx)。然后为满足选定的费用报价的每个矿工412构建区块链交易。在步骤604中，将十六进制编码的区块链交易返回到API转换器406。交易包括特定标识符TxID，如以上方面所解释的。在步骤605中，将与区块链交易相关联的输出发送到支付处理器404。在步骤606中，将与区块链交易有关的结果作为包括TxID的JSON TxResult对象返回到客户端。

图7是描述图4所示架构的组件之间的数据流的示意图，用于实现来自客户端的queryTransactionStatus命令或模板。这已经在上面关于图1至图3进行了详细讨论，并且图4简单地示意性列出了客户端、支付处理器和矿工的交互以提供与和客户端相关联的支付相关联的区块链交易。当在步骤701中针对与区块链交易相关的给定交易TxID将HTTPSGET queryTransactionStatus(TxID)命令发送到支付处理器404时，该流程源自客户端402，该区块链交易先前作为图6中submitTransaction流程的一部分返回给客户端。在步骤702中，将GET命令发送到API转换器406，在步骤703中，API转换器406将其转换为RPC命令RPC getRawTransaction(TxID)。然后标识与TxID有关的给定矿工412相关联的区块链交易。在步骤704中，将标识出的十六进制编码的区块链交易及其关联状态返回到API转换器406。在步骤705中，将与TxID有关的区块链交易相关联的状态结果发送到支付处理器404。然后在步骤706中，将与TxID的区块链交易有关的状态结果作为JSON TxStatus对象返回给客户端。

此外，如上面关于图1至图3所讨论的，可以针对单个交易每次单独请求和/或获得和/或提交和/或查询费用报价，或者针对成组或成批的要由客户端在单个请求中提交(即，同时提交)的多个交易请求和/或获得和/或提交和/或查询费用报价。为了便于解释和理解，上面已经关于第一请求和/或第二请求中的单个交易和/或与客户端相关联的状态查询解释了图4至图7，但将理解的是，本公开绝不限于此。

现在转向图8，提供了可用于实践本公开的至少一个实施例的计算装置2600的说明性简化框图。在各种实施例中，计算装置2600可以用于实现以上示出和描述的任何系统。例如，计算装置2600可以被配置为用作图形中DBMS的一个或多个组件，或者计算装置2600可以被配置为与给定用户相关联的客户端实体，客户端实体对由图8的DBMS管理的数据库进行数据库请求。因此，计算装置2600可以是便携式计算装置、个人计算机或任何电子计算装置。如图8所示，计算装置2600可以包括具有一个或多个级别的高速缓冲存储器和存储器控制器的一个或多个处理器(统称为2602)，该处理器可以被配置为与包括主存储器2608和永久存储装置2610的存储子系统2606进行通信。如图所示，主存储器2608可以包括动态随机存取存储器(DRAM)2618和只读存储器(ROM)2620。存储子系统2606和高速缓存存储器2602可以用于存储信息，例如与本公开中描述的交易和区块相关联的细节。(一个或多个)处理器2602可用于提供本公开中描述的任何实施例的步骤或功能。

(一个或多个)处理器2602还可以与一个或多个用户接口输入装置2612、一个或多个用户接口输出装置2614以及网络接口子系统2616进行通信。

总线子系统2604可以提供用于使得计算装置2600的各个组件和子系统能够按预期彼此通信的机制。尽管总线子系统2604被示意性地示出为单个总线，但是总线子系统的替代实施例可以利用多个总线。

网络接口子系统2616可以提供至其他计算装置和网络的接口。网络接口子系统2616可以用作从不同于计算装置2600的其他系统接收数据以及将数据传输到不同于计算装置2600的其他系统的接口。例如，网络接口子系统2616可以使数据技术人员能够将装置连接至网络，使得数据技术员可以在位于远程位置(例如，数据中心)的同时，将数据传输到该装置并从该装置接收数据。

用户接口输入装置2612可以包括一个或多个用户输入装置，例如，键盘；诸如集成鼠标、轨迹球、触摸板或图形输入板等定点装置；扫描仪；条形码扫描仪；合并到显示器中的触摸屏；诸如语音标识系统、麦克风等音频输入装置；以及其他类型的输入装置。通常，术语“输入装置”的使用旨在包括用于将信息输入到计算装置2600的所有可能类型的装置和机构。

一个或多个用户接口输出装置2614可以包括显示子系统、打印机或诸如音频输出装置等非可视显示器。显示子系统可以是阴极射线管(CRT)、诸如液晶显示器(LCD)、发光二极管(LED)显示器或投影仪的平板装置或其他显示装置。通常，术语“输出装置”的使用旨在包括用于从计算装置2600输出信息的所有可能类型的装置和机构。一个或多个用户接口输出装置2614可以用于例如呈现用户界面，以有助于用户与执行所描述的过程及其中的变型的应用的交互，如果这样的交互是适当的话。

存储子系统2606可以提供计算机可读存储介质，该计算机可读存储介质用于存储可以提供本公开的至少一个实施例的功能的基本编程和数据构造。当由一个或多个处理器执行时，应用程序(程序、代码模块、指令)可以提供本公开的一个或多个实施例的功能，并且可以存储在存储子系统2606中。这些应用程序模块或指令可以由一个或多个处理器2602执行。另外，存储子系统2606可以提供用于存储根据本公开而使用的数据的存储库。例如，主存储器2608和高速缓存存储器2602可以为程序和数据提供易失性存储。永久存储装置2610可以为程序和数据提供永久性(非易失性)存储，并且可以包括快闪存储器、一个或多个固态驱动器、一个或多个磁性硬盘驱动器、一个或多个具有关联的可移除介质的软盘驱动器、一个或多个具有关联的可移除介质的光驱(例如，CD-ROM或DVD或Blue-Ray)驱动器、以及其他类似的存储介质。这样的程序和数据可以包括用于执行如本公开中所描述的一个或多个实施例的步骤的程序以及与本公开中所描述的交易和区块关联的数据。

计算装置2600可以是各种类型，包括便携式计算机装置、平板计算机、工作站或以下描述的任何其他装置。另外，计算装置2600可以包括可以通过一个或多个端口(例如，USB、耳机插孔、闪电连接器等)连接到计算装置2600的另一装置。可以连接到计算装置2600的装置可以包括被配置为接受光纤连接器的多个端口。因此，该装置可以被配置为将光信号转换为电信号，该电信号可以通过将装置连接至计算装置2600的端口来传输以进行处理。由于计算机和网络不断变化的性质，图8中所描绘的计算装置2600的描述仅旨在作为特定示例，以达到说明该装置的优选实施例的目的。具有比图8中描绘的系统更多或更少的组件的许多其他配置是可能的。

列举的示例实施例

特此基于与上述方面相关的以下条款讨论本公开，本文提供这些条款作为示例性实施例以更好地解释、描述和理解要求保护的各方面和实施例。

1、一种针对与区块链相关联的交易为一个或多个客户端提供支付服务的计算机实施的方法，所述方法由支付处理器实施并且包括以下步骤：

接收来自客户端的第一请求，所述第一请求与在区块链中挖掘交易相关联；

向通信地耦合到所述支付处理器的多个矿工中的每个矿工发送针对费用报价的请求；

从每个矿工获得用于挖掘所述交易的费用报价；以及

将从所述多个矿工获得的费用报价提供给所述客户端，其中，基于获得的费用报价确定用于挖掘所述交易的选定的费用报价；或者

基于获得的费用报价，为所述客户端确定用于挖掘所述交易的选定的费用报价。

2、根据条款1所述的方法，其中，与所述第一请求相关联的交易包括成批的多个交易。

3、根据条款1或2所述的方法，包括以下步骤：

响应于来自所述客户端的用于提交给定交易的第二请求，向所述多个矿工中的一个或多个矿工发送请求以生成对应于所述给定交易的区块链交易，所述给定交易与获得的费用报价中所述选定的费用报价有关；

从所述多个矿工中满足所述选定的费用报价的至少一个矿工接收与对应的区块链交易相关联的输出脚本；以及

向所述客户端发送结果，所述结果包括对应于所述给定交易的区块链交易的交易标识符。

4、根据条款3所述的方法，其中，所述给定交易包括成批的多个交易。

5、根据前述任一条款所述的方法，其中，提供所述获得的费用报价的步骤还包括：基于所述获得的费用报价的平均值或所述获得的费用报价中的最大值来确定推荐的费用报价。

6、根据条款5所述的方法，还包括：提供所述推荐的费用报价或提供包括所述推荐的费用报价的所有获得的费用报价，其中，所述推荐的费用报价包括标识符。

7、根据条款5或7中任一项所述的方法，其中，所述选定的费用报价与所述推荐的费用报价相同或不同于所述推荐的费用报价，其中，不同的费用报价是预定的或任意选择的。

8、根据前述任一条款所述的方法，其中，确定选定的费用报价的步骤包括：将多个服务水平中的服务水平分配给每个获得的费用报价，每个服务水平与用于挖掘所述交易的相应选定的费用报价相关联。

9、根据条款8所述的方法，其中，基于所述获得的费用报价和与矿工相关联的最小中继费用来分配所述服务水平，所述矿工与相应的费用报价有关。

10、根据条款8或9所述的方法，其中，分配的服务水平指示挖掘所述交易的优先级和/或防止与推荐的费用的交易相关联的双重花费的保护级别。

11、根据条款8至10中任一项所述的方法，其中，基于从所述客户端获得的一个或多个服务要求来分配针对要挖掘的交易的服务水平。

12、根据前述任一条款所述的方法，包括：验证所述多个矿工中给定矿工的身份的步骤，其中，所述验证基于与所述给定矿工相关联的数字签名，或基于与所述给定矿工有关的标识符，可选地，所述标识符与所述给定矿工的信誉指标相关联。

13、根据前述任一条款所述的方法，包括：基于矿工签名验证从所述多个矿工中的给定矿工获得的相应费用报价的步骤，所述矿工签名用作来自所述给定矿工的对于挖掘所述相应费用报价的交易并可选地拒绝任何冲突交易的承诺。

14、根据前述任一条款所述的方法，其中，从每个矿工获得的费用报价以数据类型提供，所述数据类型为JavaScript对象表示法(JSON)对象格式。

15、根据前述任一条款所述的方法，其中，接收到的输出脚本是与所述至少一个矿工的内存池相关联的未花费交易输出(UTXO)，所述未花费交易输出(UTXO)包括所述区块链交易的交易标识符(TxID)。

16、根据前述任一条款所述的方法，包括以下步骤：

响应于来自所述客户端的与交易标识符相关联的状态查询，向所述多个矿工发送请求以获得与所述交易标识符对应的区块链交易；

从所述多个矿工中的至少一个矿工获得对应的区块链交易；以及

将与获得的区块链交易有关的状态结果发送给所述客户端。

17、根据任一前述条款所述的方法，其中，所述支付处理器被实施为用于所述一个或多个客户端的表征状态转移(REST)端点，并且其中，所述方法还包括：提供与所述支付处理器相关联的应用编程接口(API)转换器的步骤，以执行以下步骤：

使用超文本传输协议安全(HTTPS)传输协议格式从所述客户端接收与所述给定交易有关的第一请求和/或第二请求和/或状态查询；

将相应的请求转换成远程过程调用(RPC)格式，并将远程过程调用(RPC)发送到所述多个矿工中的一个或多个；

以RPC格式从所述多个矿工中的一个或多个矿工接收与对应的区块链交易相关联的响应；以及

转换相应的响应，使得能够使用HTTPS传输协议将所述响应发送到所述客户端。

18、一种用于处理与区块链相关联的交易的计算机实施的方法，所述方法由与客户端相关联的一个或多个处理器实施，所述客户端通信地耦合到为所述客户端实现支付服务的至少一个支付处理器，所述方法包括以下步骤：

向所述至少一个支付处理器中的支付处理器发送第一请求，所述请求与用于挖掘交易的一个或多个费用报价有关，所述交易与来自客户的数字资产支付相关；以及

响应于从所述支付处理器接收到一个或多个费用报价，在一个或多个接收到的费用报价中选择费用报价。

19、根据条款18所述的方法，包括以下步骤：

从所述客户请求数字资产支付和/或处理来自所述客户的数字资产支付，所述请求与选定的费用报价相关联；

发送第二请求以向区块链提交与从所述客户到所述支付处理器的数字资产支付相关联的给定交易，所述提交是基于用于挖掘所述给定交易的选定的费用报价；以及

获得与提交的交易对应的区块链交易的交易标识符(TxID)。

20、根据条款19所述的方法，其中，所述第二请求中的给定交易包括成批的多个交易。

21、根据条款18至20中任一项所述的方法，包括以下步骤：

发送与获得的交易标识符相关联的状态查询；以及

获得与所述交易标识符对应的区块链交易的状态结果。

22、根据条款18至21中任一项所述的方法，其中，所述客户端包括或通信地耦合到所述至少一个支付处理器，所述至少一个支付处理器被配置为实施根据条款1至17中任一项所述的方法。

23、根据条款18至22中任一项所述的方法，其中，所述第一请求和/或所述状态查询是HTTPS GET请求，并且其中，所述第二请求是HTTPS POST请求。

24、根据条款18至23中任一项所述的方法，其中，选择费用报价的步骤包括：确定获得的费用报价的平均值并基于确定的平均值来选择费用报价。

25、根据条款18至24中任一项所述的方法，其中，选择费用报价的步骤包括：在获得的费用报价中确定费用报价的最大值，并基于所述最大值选择费用报价。

26、根据条款18至25中任一项所述的方法，其中，与所述第一请求和/或所述第二请求和/或所述状态查询相关联的数据以JavaScript对象表示法(JSON)对象格式提供。

27、一种用于处理与区块链相关联的交易的计算机实施的方法，所述方法由与多个矿工中的矿工相关联的一个或多个处理器实施，所述多个矿工通信地耦合到为客户端实现支付服务的至少一个支付处理器，所述方法包括以下步骤：

从支付处理器接收第一请求，所述第一请求是针对用于挖掘与所述客户端相关联的交易的费用报价；以及

提供与所述矿工在所述区块链中挖掘所述交易有关的当前费用报价，其中，所述当前费用报价表示以所述当前费用报价挖掘交易的许诺。

28、根据条款27所述的方法，包括以下步骤：

响应于向所述区块链提交与所述客户端相关联的给定交易相关的第二请求，所述给定交易基于选定的费用报价，所述方法还包括以下步骤：

基于确定与所述给定交易相关联的选定的费用报价满足所述矿工的当前费用报价，生成与所述给定交易对应的区块链交易；

为所述区块链交易生成输出脚本(UTXO)；

将生成的输出脚本添加到与所述矿工相关联的内存池中；以及

将输出脚本发送到所述支付处理器，其中，所述输出脚本包括与对应的区块链交易相关联的交易标识符(TxID)。

29、根据条款28所述的方法，包括：响应于针对与所述交易标识符相关联的状态的请求，返回基于对应的区块链交易的挖掘状态的结果。

30、根据条款27至29中任一项所述的方法，其中，提供所述当前费用报价的步骤和/或发送所述输出脚本的步骤和/或返回所述结果的步骤被实施为远程过程调用(RPC)。

31、根据条款30所述的方法，包括以下步骤：将RPC从所述矿工发送到节点连接器以及可选地所述多个矿工的防火墙，然后通过无线通信网络将所述RPC传播到客户端的支付处理器。

32、根据条款27至31中任一项所述的方法，其中，基于确定与所述给定交易相关联的选定的费用报价不满足所述矿工的当前费用报价，将与对应的区块链交易相关联的输出添加到与所述矿工相关联的辅助内存池。

33、根据条款27至32中任一项所述的方法，其中，所述矿工通信地耦合到所述至少一个支付处理器，所述至少一个支付处理器被配置为实施根据条款1至9中任一项所述的方法，并且其中，所述至少一个支付处理器与客户端相关联或通信地耦合到所述客户端，所述客户端被配置为实施根据条款12至19中任一项所述的方法。

34、一种针对与区块链相关联的交易为一个或多个客户端提供支付服务的计算机实施的方法，所述方法由支付处理器实施并且包括以下步骤：

从客户端接收针对要在区块链中挖掘的交易的一个或多个服务要求或与所述客户端商定所述一个或多个服务要求；

从客户端接收用于在区块链中挖掘一个或多个交易的第一请求；

向通信地耦合到支付处理器的多个矿工中的每个矿工发送针对费用报价的请求；

从每个矿工获得用于挖掘所述一个或多个交易的费用报价；

将获得的费用报价分类成为挖掘提供的多个服务水平中的给定服务水平，每个服务水平与设定的挖掘费用相关联；

基于接收到的所述一个或多个服务要求确定所述客户端的服务水平；其中，与确定的服务水平相关联的设定的挖掘费用是用于挖掘与所述客户端相关联的所述一个或多个交易的选定的费用报价；并且其中，确定的服务水平指示用于挖掘交易的优先级和/或防止双重花费的保护级别。

35、一种计算装置，包括：处理器；以及包括可执行指令的存储器，所述可执行指令由于被所述处理器执行而使所述装置执行根据条款1至17和33中任一项所述的计算机实施的方法，所述计算装置与支付处理器有关。

36、一种计算装置，包括：处理器；以及包括可执行指令的存储器，所述可执行指令由于被所述处理器执行而使所述装置执行根据条款18至26中任一项所述的计算机实施的方法，所述计算装置与客户端有关。

37、一种计算装置，包括：处理器；以及包括可执行指令的存储器，所述可执行指令由于被所述处理器执行而使所述装置执行根据条款27至33中任一项所述的计算机实施的方法，所述计算装置与矿工有关。

38、一种计算机系统，包括：

支付处理器，经由无线通信网络通信地耦合到至少一个客户端和至少一个矿工，所述支付处理器可选地与API转换器相关联，所述API转换器用于将来自客户端的HTTPS请求转换成用于矿工的RPC请求，反之亦然，其中，所述支付处理器是根据条款35所述的计算装置实施的；

客户端，经由所述无线通信网络通信地耦合到支付处理器，并且能与至少一个客户进行通信；所述客户端是根据条款36所述的计算装置实施的；以及

多个矿工，经由所述无线通信网络通信地耦合到支付处理器，每个矿工是根据条款37所述的计算装置实施的。

39、一种其上存储有可执行指令的计算机可读存储介质，所述可执行指令由于被计算机的处理器执行而使所述计算机执行条款1至34中任一项的方法。

应当注意，上述各方面和实施例说明而不是限制本公开，并且本领域技术人员将能够设计许多替代实施例，而不脱离由所附权利要求限定的本公开的范围。在权利要求中，括号中的任何附图标记都不应解释为对权利要求的限制。单词“包括(comprising、comprise)”等不排除任何权利要求或整个说明书中列出的元素或步骤之外的元素或步骤的存在。在本说明书中，“包括(comprise)”是指“包括(include)或由……组成(consistof)”，“包括(comprising)”是指“包括(including)或由……组成(consisting of)”。元素的单数形式并不排除此类元素的复数形式，反之亦然。本公开可以通过包括几个不同元件的硬件以及通过适当编程的计算机来实现。在列举几个部件的装置权利要求中，这些部件中的几个可以由一个且相同的硬件项来实施。在互不相同的从属权利要求中记载某些手段的事实并不表示不能有利地使用这些手段的组合。

Claims (39)

1.一种针对与区块链相关联的交易为一个或多个客户端提供支付服务的计算机实施的方法，所述方法由支付处理器实施并且包括以下步骤：

接收来自客户端的第一请求，所述第一请求与在区块链中挖掘交易相关联；

向通信地耦合到所述支付处理器的多个矿工中的每个矿工发送针对费用报价的请求；

从每个矿工获得用于挖掘所述交易的费用报价；以及

将从所述多个矿工获得的费用报价提供给所述客户端，其中，基于获得的费用报价确定用于挖掘所述交易的选定的费用报价；或者

基于获得的费用报价，为所述客户端确定用于挖掘所述交易的选定的费用报价。

2.根据权利要求1所述的方法，其中，与所述第一请求相关联的交易包括成批的多个交易。

3.根据权利要求1或2所述的方法，包括以下步骤：

响应于来自所述客户端的提交给定交易的第二请求，向所述多个矿工中的一个或多个矿工发送请求以生成对应于所述给定交易的区块链交易，所述给定交易与获得的费用报价中所述选定的费用报价有关；

从所述多个矿工中满足所述选定的费用报价的至少一个矿工接收与对应的区块链交易相关联的输出脚本；以及

向所述客户端发送结果，所述结果包括与所述给定交易相对应的区块链交易的交易标识符。

4.根据权利要求3所述的方法，其中，所述给定交易包括成批的多个交易。

5.根据前述任一权利要求所述的方法，其中，提供获得的费用报价的步骤还包括：基于所述获得的费用报价的平均值或所述获得的费用报价中的最大值来确定推荐的费用报价。

6.根据权利要求5所述的方法，还包括：提供所述推荐的费用报价或提供包括所述推荐的费用报价的所有获得的费用报价，其中，所述推荐的费用报价包括标识符。

7.根据权利要求5或6中任一项所述的方法，其中，所述选定的费用报价与所述推荐的费用报价相同或不同于所述推荐的费用报价，其中，不同的费用报价是预定的或任意选择的。

8.根据前述任一权利要求所述的方法，其中，确定选定的费用报价的步骤包括：将多个服务水平中的服务水平分配给每个获得的费用报价，每个服务水平与用于挖掘所述交易的相应选定的费用报价相关联。

9.根据权利要求8所述的方法，其中，基于所述获得的费用报价和与相应的费用报价有关的矿工相关联的最小中继费用来分配所述服务水平。

10.根据权利要求8或9所述的方法，其中，分配的服务水平指示挖掘所述交易的优先级和/或防止与推荐的费用的交易相关联的双重花费的保护级别。

11.根据权利要求8至10中任一项所述的方法，其中，基于从所述客户端获得的一个或多个服务要求来分配要挖掘的交易的服务水平。

12.根据前述任一权利要求所述的方法，包括：验证所述多个矿工中的给定矿工的身份的步骤，其中，所述验证是基于与所述给定矿工相关联的数字签名，或基于与所述给定矿工有关的标识符，可选地，所述标识符与所述给定矿工的信誉指标相关联。

13.根据前述任一权利要求所述的方法，包括：基于矿工签名来验证从所述多个矿工中的给定矿工获得的相应费用报价的步骤，所述矿工签名用作来自所述给定矿工的对于挖掘所述相应费用报价的交易并可选地拒绝任何冲突交易的承诺。

14.根据前述任一权利要求所述的方法，其中，从每个矿工获得的费用报价以数据类型提供，所述数据类型为JavaScript对象表示法(JSON)对象格式。

15.根据前述任一权利要求所述的方法，其中，接收到的输出脚本是与所述至少一个矿工的内存池相关联的未花费交易输出(UTXO)，所述未花费交易输出(UTXO)包括所述区块链交易的交易标识符(TxID)。

16.根据前述任一权利要求所述的方法，包括以下步骤：

响应于来自所述客户端的与交易标识符相关联的状态查询，向所述多个矿工发送请求以获得与所述交易标识符对应的区块链交易；

从所述多个矿工中的至少一个矿工获得对应的区块链交易；以及

将与获得的区块链交易有关的状态结果发送到所述客户端。

17.根据任一前述权利要求所述的方法，其中，所述支付处理器被实施为用于所述一个或多个客户端的表征状态转移(REST)端点，并且其中，所述方法还包括：提供与所述支付处理器相关联的应用编程接口(API)转换器的步骤，以执行以下步骤：

使用超文本传输协议安全(HTTPS)传输协议格式从所述客户端接收与所述给定交易有关的第一请求和/或第二请求和/或状态查询；

将相应的请求转换成远程过程调用(RPC)格式，并将所述远程过程调用(RPC)发送到所述多个矿工中的一个或多个矿工；

以远程过程调用(RPC)格式从所述多个矿工中的一个或多个矿工接收与对应的区块链交易相关联的响应；以及

转换相应的响应，使得能够使用所述超文本传输协议安全(HTTPS)传输协议将所述响应发送到所述客户端。

18.一种用于处理与区块链相关联的交易的计算机实施的方法，所述方法由与客户端相关联的一个或多个处理器实施，所述客户端通信地耦合到为所述客户端实现支付服务的至少一个支付处理器，所述方法包括以下步骤：

向所述至少一个支付处理器中的支付处理器发送第一请求，所述请求与用于挖掘交易的一个或多个费用报价有关，所述交易与来自客户的数字资产支付相关；以及

响应于从所述支付处理器接收到一个或多个费用报价，在一个或多个接收到的费用报价中选择费用报价。

19.根据权利要求18所述的方法，包括以下步骤：

从所述客户请求数字资产支付和/或处理来自所述客户的数字资产支付，所述请求与选定的费用报价相关联；

发送第二请求以向区块链提交给定交易，所述给定交易与从所述客户到所述支付处理器的数字资产支付相关联，所述提交是基于用于挖掘所述给定交易的选定的费用报价；以及

获得与提交的交易对应的区块链交易的交易标识符(TxID)。

20.根据权利要求19所述的方法，其中，所述第二请求中的给定交易包括成批的多个交易。

21.根据权利要求18至20中任一项所述的方法，包括以下步骤：

发送与获得的交易标识符相关联的状态查询；以及

获得与所述交易标识符对应的区块链交易的状态结果。

22.根据权利要求18至21中任一项所述的方法，其中，所述客户端包括或通信地耦合到所述至少一个支付处理器，所述至少一个支付处理器被配置为实施根据权利要求1至17中任一项所述的方法。

23.根据权利要求18至22中任一项所述的方法，其中，所述第一请求和/或所述状态查询是HTTPS GET请求，并且其中，所述第二请求是HTTPS POST请求。

24.根据权利要求18至23中任一项所述的方法，其中，选择费用报价的步骤包括：确定获得的费用报价的平均值，并基于确定的平均值来选择费用报价。

25.根据权利要求18至24中任一项所述的方法，其中，选择费用报价的步骤包括：确定获得的费用报价中的费用报价的最大值，并基于所述最大值选择费用报价。

26.根据权利要求18至25中任一项所述的方法，其中，与所述第一请求和/或所述第二请求和/或所述状态查询相关联的数据以JavaScript对象表示法(JSON)对象格式提供。

27.一种用于处理与区块链相关联的交易的计算机实施的方法，所述方法由与多个矿工中的矿工相关联的一个或多个处理器实施，所述多个矿工通信地耦合到为客户端实现支付服务的至少一个支付处理器，所述方法包括以下步骤：

从支付处理器接收第一请求，所述第一请求是针对用于挖掘与所述客户端相关联的交易的费用报价；以及

提供与所述矿工在所述区块链中挖掘所述交易有关的当前费用报价，其中，所述当前费用报价表示保证以所述当前费用报价挖掘交易。

28.根据权利要求27所述的方法，包括以下步骤：

响应于第二请求，所述第二请求涉及向所述区块链提交与所述客户端相关联的给定交易，所述给定交易基于选定的费用报价，所述方法还包括以下步骤：

基于确定与所述给定交易相关联的选定的费用报价满足所述矿工的当前费用报价，生成与所述给定交易对应的区块链交易；

为所述区块链交易生成输出脚本(UTXO)；

将生成的输出脚本添加到与所述矿工相关联的内存池中；以及

将所述输出脚本发送到所述支付处理器，其中，所述输出脚本包括与对应的区块链交易相关联的交易标识符(TxID)。

29.根据权利要求28所述的方法，包括：响应于针对与所述交易标识符相关联的状态的请求，返回基于对应的区块链交易的挖掘状态的结果。

30.根据权利要求27至29中任一项所述的方法，其中，提供所述当前费用报价的步骤和/或发送所述输出脚本的步骤和/或返回所述结果的步骤被实施为远程过程调用(RPC)。

31.根据权利要求30所述的方法，包括以下步骤：将所述远程过程调用(RPC)从矿工发送到节点连接器以及可选地所述多个矿工的防火墙，然后通过无线通信网络将所述远程过程调用(RPC)传播到客户端的支付处理器。

32.根据权利要求27至31中任一项所述的方法，其中，基于确定与所述给定交易相关联的选定的费用报价不满足所述矿工的当前费用报价，将与对应的区块链交易相关联的输出添加到与所述矿工相关联的辅助内存池。

33.根据权利要求27至32中任一项所述的方法，其中，所述矿工通信地耦合到至少一个支付处理器，所述至少一个支付处理器被配置为实施根据权利要求1至9中任一项所述的方法，并且其中，所述至少一个支付处理器与客户端相关联或通信地耦合到所述客户端，所述客户端被配置为实施根据权利要求12至19中任一项所述的方法。

34.一种针对与区块链相关联的交易为一个或多个客户端提供支付服务的计算机实施的方法，所述方法由支付处理器实施并且包括以下步骤：

针对要在区块链中挖掘的交易从客户端接收一个或多个服务要求，或者与所述客户端商定所述一个或多个服务要求；

从客户端接收用于在区块链中挖掘一个或多个交易的第一请求；

向通信地耦合到支付处理器的多个矿工中的每个矿工发送针对费用报价的请求；

从每个矿工获得用于挖掘所述一个或多个交易的费用报价；

将获得的费用报价分类成为挖掘提供的多个服务水平中的给定服务水平，每个服务水平与设定的挖掘费用相关联；

基于接收到的一个或多个服务要求确定所述客户端的服务水平；其中，与确定的服务水平相关联的设定的挖掘费用是用于挖掘与所述客户端相关联的一个或多个交易的选定的费用报价；并且其中，确定的服务水平指示用于挖掘所述交易的优先级和/或防止双重花费的保护级别。

35.一种计算装置，包括：处理器；以及包括可执行指令的存储器，所述可执行指令由于被所述处理器执行而使所述计算装置执行根据权利要求1至17和33中任一项所述的计算机实施的方法，所述计算装置与支付处理器有关。

36.一种计算装置，包括：处理器；以及包括可执行指令的存储器，所述可执行指令由于被所述处理器执行而使所述计算装置执行根据权利要求18至26中任一项所述的计算机实施的方法，所述计算装置与客户端有关。

37.一种计算装置，包括：处理器；以及包括可执行指令的存储器，所述可执行指令由于被所述处理器执行而使所述计算装置执行根据权利要求27至33中任一项所述的计算机实施的方法，所述计算装置与矿工有关。

38.一种计算机系统，包括：

支付处理器，经由无线通信网络通信地耦合到至少一个客户端和至少一个矿工，所述支付处理器可选地与应用编程接口(API)转换器相关联，所述应用编程接口(API)转换器用于将来自客户端的超文本传输协议安全(HTTPS)请求转换成用于矿工的远程过程调用(RPC)请求以及将来自矿工的远程过程调用(RPC)请求转换成用于客户端的超文本传输协议安全(HTTPS)请求，其中，所述支付处理器是根据权利要求35所述的计算装置实施的；

客户端，经由所述无线通信网络通信地耦合到所述支付处理器并且能够与至少一个客户进行通信；所述客户端是根据权利要求36所述的计算装置实施的；以及

多个矿工，经由所述无线通信网络通信地耦合到所述支付处理器，每个矿工是根据权利要求37所述的计算装置实施的。

39.一种其上存储有可执行指令的计算机可读存储介质，所述可执行指令由于被计算机的处理器执行而使所述计算机执行根据权利要求1至34中任一项所述的方法。

Images