CN114641967A - 区块链交易的回调机制 - Google Patents

Abstract

在一个方面中，本公开提出了用于处理与客户端相关联的区块链交易的方法、设备和系统。支付服务被实现为网关或API端点，一个或多个客户端可以对所述网关或API端点进行访问。从给定客户端接收到提交交易的请求，所述给定客户端与回调标识符相关联。所述回调标识符能够实现所述给定客户端与另一实体(诸如矿工或另一对手方)之间的直接通信。支付处理器将所述交易提交给矿工，该提交与所述回调标识符相关联。随后，一旦已经由所述矿工创建了对应区块链交易，则可以使用所述回调标识符从所述矿工直接为所述客户端提供与其有关的回调通知。

Description

区块链交易的回调机制

技术领域

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

背景技术

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

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

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

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

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

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

上述示例或场景涉及传递某些资产(即，数字资产)，或用户或实体之间的数字资产的控制。因此，期望实现一种类似于现有支付系统或电子商务系统的安全且稳健的系统，以用于两个实体之间的资金交换——特别是用于商户和顾客之间的数字资产支付，该系统可以尊重真实世界中的资产，具有更好的用户体验、更低的商户成本或收款方成本，以及更安全的安全级别。更具体地，期望利用分布式分类账(区块链)技术以及其改进的记录安全性、透明度和可靠性的优点来提供一种公共平台或公共接口，该公共平台或公共接口使得任何商户或多个商户能够确保与它们各自的顾客进行的数字资产支付可以即时地且安全地被挖掘或写入区块链中，从而提供此类支付的持久的、防篡改和可审计的记录。

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

发明内容

在一个方面中，本公开提出了与支付服务相关联的方法、设备和系统，用于对与客户端相关联的区块链交易进行处理。支付服务被实现为网关或API端点，一个或多个客户端可以访问该网关或API端点。在本方法中，从给定客户端接收的提交交易的请求与回调标识符相关联。回调标识符使得能够在给定客户端和另一实体之间进行直接通信。支付处理器将交易以及回调标识符一起提交给矿工。随后，一旦已经由矿工创建了对应区块链交易，就可以从矿工直接为客户端提供与对应区块链交易有关的回调通知。

在另一方面中，来自客户端的请求与通道相关联，所述通道由通道服务提供并与一个或多个功能相关联，该一个或多个功能使得能够在客户端与另一实体之间进行直接通信。在这种情况下，还为客户端提供有用于通道的一个或多个访问令牌(access token)和应用程序编程接口(API)。随后，客户端可以基于这些访问令牌和/或API向另一实体(诸如矿工，其已经被识别为针对客户端挖掘交易的实体)提供对所述通道的访问。这使得与对应区块链交易有关的数据能够被其他实体直接写入通道。随后，特定于对应交易的回调通知可以经由通道服务提供。这使得与给定交易相关联的数据能够在需要的时候或在可能的情况下(诸如，当客户端在线并且经由网络与通道服务进行通信时)由客户端直接从通道进行访问。在一些情况下，通道服务可以由通道处理器实现。通道处理器可以是与上述支付处理器相同的实体，或者可以是独立于支付处理器的实体。

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

附图说明

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

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

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

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

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

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

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

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

图8是一流程图，其描绘了一种用于实现交易的回调机制的方法，其中，该方法根据第四方面由与支付处理器相关联的一个或多个处理器实施。

图9是一流程图，其描绘了一种用于为一个或多个客户端实现通道服务的方法，其中，该方法根据第四方面由与通道处理器相关联的一个或多个处理器实施。

图10是一流程图，其描绘了一种用于对支付服务进行访问的方法，其中，该方法根据第四方面由与客户端相关联的一个或多个处理器实施。

图11是一流程图，其描绘了一种用于对与给定区块链交易相关联的消息进行处理的方法，其中，该方法根据第四方面由与矿工相关联的一个或多个处理器实施。

图12是一示意图，其示出了可以在其中实现本公开的各个方面和实施例的计算环境。

具体实施方式

尽管所附权利要求与下文详细描述的本公开的第四方面有关，但本文提供了对第一方面、第二方面和第三方面的详细讨论，以使读者全面且完整地理解本公开所要求保护的各方面和相关实施例。

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

第一方面的方法包括以下步骤：从多个矿工中的每个矿工获取针对挖掘交易的费用报价。该步骤响应于来自客户端的第一请求而发生，该第一请求针对与挖掘交易相关联的挖掘费用报价。在一些实施例中，矿工是由一个或多个处理器实现的节点，这些处理器被委托对锁定脚本和解锁脚本进行验证，以及挖掘交易或将交易写入区块链，如上文背景部分中所解释。例如，如果BSV(Bitcoin Satoshi’s Vision(比特币中本聪愿想))是待交易或转移的加密货币或数字资产，则矿工可以被称为BSV节点。第一方面的方法包括将所获取的费用报价提供给客户端的步骤。在一些实施例中，费用报价与矿工为将交易挖掘到区块链中所征收或收取的当前费用有关，而不管该交易与什么有关或所涉及的各方如何。在其他实施例中，费用报价可以被定制为基于一给定交易，该给定交易可以在请求中识别。在一些实施例中，支付处理器可以向客户端提供所有接收到的费用报价，或者可以在所获取的费用报价中向客户端提供一个或多个建议费用报价。

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

在第一方面的一些实施例中，响应于来自客户端的、提交与所获取的费用报价中的所选费用报价有关或者包括所获取的费用报价中的所选费用报价的给定交易的第二请求，该方法包括向多个矿工中的一个或多个矿工发送请求，用于针对给定交易生成区块链交易。

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

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

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

有利的是，支付处理器建议的是客户端随后可以选择将其作为所选费用报价的费用报价，在一些实施例中，该费用报价是客户端愿意为提交与去往客户端的数字资产支付相关联的交易而支付的最大费用。如果客户端是计算简单的客户端，或者如果客户端已经预先确定了由支付处理器提供建议，而不是由它们自己选择费用报价，则这是有利的。因此，有利的是，客户端可以基于建议费用报价来选择费用报价，而不是采用新的或另外的启发式方法或计算来选择费用报价，或任意地选择费用报价。

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

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

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

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

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

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

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

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

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

-交易的高速缓存

-在矿工节点发生故障的情况下，执行恢复功能

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

-提供恢复特征，以对那些由于某些原因而提交失败的交易进行跟踪。

在一些示例中，这可以是包括由支付处理器保持或设置的可配置参数；

以及，对那些已过期的被跟踪交易进行清除的机制。API网关还可以与故障场景中用于重新提交交易的功能相关联，从而提供针对真实交易(genuine transaction)的错误处理以及对双重花费进行区分的功能。

根据第二方面，本公开提供了一种用于对与区块链相关联的交易进行处理的方法，所述方法由与客户端相关联的一个或多个处理器实施，所述客户端通信地联接到与为所述客户端实现支付服务的至少一个支付处理器。在一些实施例中，支付处理器被配置为实施上述第一方面的方法及其相关联的实施例。由客户端(即，商户)实施的第二方面的方法包括以下步骤：向至少一个支付处理器中的支付处理器发送第一请求，该请求与经由支付处理器从多个矿工获取的、针对挖掘一个或多个交易的一个或多个费用报价有关。如上所述，所获取的费用报价与挖掘任意交易有关，或者可以特定于一给定交易，该给定交易与来自顾客的数字资产支付有关。

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

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

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

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

此外，本公开的方法有利地允许客户端选择一费用报价以提供给支付服务，这为客户端或商户提供了如下控制或：即，它们的交易将按照给定挖掘费用及时地进行挖掘，从而为利用所提议的支付服务或支付API的客户端而进行挖掘的那些交易提供改进的安全性、互操作性、可靠性、效率和及时性。

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

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

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

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

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

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

随着分布式分类账(区块链)技术在许多应用中的使用的增加，这些应用需要安全、可审计、防篡改和可靠地记录与其相关的事件或交易；参与实体(诸如客户端或商户实体)的解决方案传统上依赖于：实时同步区块链的完整副本，直接从区块链识别与参与实体的应用和相关联的数字钱包有关的交易和嵌入数据二者。然而，随着客户端(即，商户应用程序)的范围、能力和安全性的发展，以及随着区块链的扩展，为了扩展和充分实现和利用与区块链相关联的优点的全部潜力，并使解决方案可供任何类型的客户端或实体使用——无论它们计算上是否复杂，很明显需要一种允许参与方直接进行通信的技术解决方案，并且需要用于直接交换消息的此类应用程序。本公开的第四方面为与支付服务相关联的客户端提供了此类解决方案，如上文在第一方面中所讨论。

根据第四方面的第一实现，本公开提供了一种计算机实施的方法，用于为一个或多个客户端提供针对与区块链相关联的交易的支付服务，所述方法由支付处理器实施。在一些实施例中，支付处理器可以是如结合第一方面所讨论的支付处理器。所述方法包括以下步骤：从一个或多个客户端中的给定客户端接收请求，该请求针对向区块链提交与数字资产相关联的交易。如上述方面所述，使用HTTP传输格式将该请求发送到支付处理器。在一些示例中，该请求是如上所述的从客户端接收到的提交交易的第二请求。

在第四方面的第一实现中，来自客户端的请求与回调标识符相关联，用于实现客户端与另一实体之间的直接通信。在一些实施例中，回调标识符可以是与客户端相关联的接入点或URI或URL。其他类型的回调标识符和机制也是可能的。下文中详细讨论的这种机制是提供通信通道。

随后，第四方面的方法包括将与请求相关联的交易提交给矿工，以将该交易包括在区块链中。在一些实施例中，该步骤类似于根据从客户端接收到的第二请求来提交交易，如结合第一方面所讨论。支付处理器将与请求相关联的交易以及回调标识符提交给多个矿工中的给定矿工。

在一些实施例中，当给定矿工接收到经由支付处理器提交的交易时，如上文第一方面和/或第二方面和/或第三方面所述，与对应区块链交易(其对应于所提交的请求)相关联的交易标识符(TxID)作为响应而从矿工接收。在一些实施例中，这包括接收一输出脚本，例如未花费交易输出(UTXO)UTXO，该输出脚本与对应区块链交易相关联，如上述第一方面中所述。随后，将对应区块链交易的交易标识符(TxID)发送给客户端。

通过提供与矿工相关联的接入端点或矿工标识符(矿工ID)或位置，支付处理器还向客户端识别给定矿工。在一些情况下，矿工可以作为具有TxID的上述响应的一部分而识别给客户端。客户端拥有TxID是有利的，使得客户端能够跟踪与TxID相关的任何进一步的通信或消息。如上所述，如果客户端选择发起检查，则TxID还可以用于对相应交易的状态进行此类检查。

随后，所述方法包括为客户端启用或处理至少一个回调通知，该至少一个回调通知与由矿工提供的对应区块链交易有关。在实施例中，在回调标识可以被矿工直接使用(即，经由客户端的位置或URL)以关于对应交易来联系客户端的情况下，支付处理器启用回调通知。如果所识别的回调需要进一步的步骤(诸如提供访问令牌或交换密钥等)来发起此类直接通信，则支付流程必须处理此类进一步访问，以允许矿工使用回调标识符与客户端进行通信。

本公开第四方面的第二实现涉及一实施例，在该实施例中，来自客户端的、针对提交交易的请求与通道相关联。在这种情况下，上述第一实现中提到的通道标识符是以通道的形式，该通道被配置为能够实现给定客户端和另一实体之间的直接通信。通道是这样一种实现，其由与给定客户端关联的通道服务促成或提供，并且特定于给定客户端的给定主题或给定交易。通道可以通过与客户端相关联的位置或URL或通道标识符来识别。

通道服务可以由单独的通道处理器提供，或者也可以由上述支付处理器提供，或者可以与客户端集成在一起。在一些实施例中，通道与一个或多个功能相关联，这些功能包括：与数据传输有关的通道功能或程序；和/或与使用通道进行传输的数据有关的消息功能或程序。因此，通道能够在实体之间实现直接的或点对点的通信路径或会话，以用于消息或数据的传递。在大多数实施例中，每个通道只用于两个实体。

以nChain控股有限公司(nChain Holdings Limited)的名义提交的、申请号为2007597.4的英国专利申请详细描述了通道服务和/或通道处理器的示例，其主题通过引用并入本文。

在一些实施例中，一个或多个功能以接口或接入点的形式提供给客户端，并且在大多数情况下，该一个或多个功能特定于可能与客户端相关联的多个通道中的给定通道，例如，针对每个交易特定一个功能。在大多数实施例中，通道能够实现全双工传输(full-duplex)，即客户端和另一实体之间的双向通信。在一些实施例中，仅可以允许在一个方向上进行通信，即客户端可能希望仅向另一实体发送消息或者仅从另一实体接收消息。

在一些实施例中，客户端可以是多个通道的拥有者或与多个通道相关联，并且上述通道是该多个通道中的一个，这些通道是基于由通道服务提供的一个或多个功能的通道。在一些实施例中，一个或多个功能是为给定客户端发布的或向给定客户端提供的应用程序编程接口(API)，所述API包括：用于一个或多个通道的通道API；以及用于数据(即，与主题相关的消息，该主题与每个通道或给定通道相关联)的消息API。API可以被理解为端点、接口或者一组功能和程序，其允许为实体(诸如在这种情况下的客户端)创建或管理应用程序，该实体对应用程序的特征或数据或者其他服务进行访问。在这种情况下，API用于实现通道功能和消息功能。

在第二实现中，来自客户端的请求还与用于通道的一个或多个访问令牌相关联。这些令牌由通道处理器提供。在一些实施例中，所述一个或多个令牌被配置用于与另一实体进行安全通信，所述一个或多个令牌与给定通道有关，或者甚至用于给定通道中的一个或多个消息。在一些实施例中，访问令牌是特定于给定通道或给定消息的API令牌。访问令牌，特别是API令牌，在一些实施例中可以充当请求对通道进行访问的实体或应用程序的唯一标识符。在一些实施例中，访问令牌可以被认为是分配给客户端的唯一认证凭证，并且甚至可以针对各个通道或每个通道中的单个消息进行细化。在一些实施例中，访问令牌可以使得客户端能够向另一实体提供这些令牌，以用于该客户端的每个通道进行验证。在本实施例中，可以由客户端或通道服务为每个交易、为与交易相关联的矿工生成或提供访问令牌。

在一些实施例中，通道可以与通道标识符相关联，而通道标识符与通道的位置或接入点相关联。在一些实施例中，每个通道与一特定通道标识符相关联。同一给定客户端可以具有多个单独的通道，每个通道具有其自身的唯一标识符，该标识符可以对应于位置或端点，经由该位置或端点可以访问该通道。在一些实施例中，给定通道用于和与数据有关的任何其他实体进行通信，该数据与特定类型或主题相关联，其中，通道中的与每个主题相关联的数据是一个或多个消息或交易，或者被包括在一个或多个消息或交易中。有利的是，针对特定主题或交易具有特定通道确保了客户端更高的清晰度、可靠性和灵活性，特别是在诸如商户实体等客户端的情况下，该客户端可以具有多个主题(诸如交易号、交易ID或单据号)，而这些主题需要独立于与同一客户端相关联的所有其他主题或其他交易来进行跟踪或处理。

在实施例中，在第一实现中的支付处理器也是通道处理器(即，支付处理器为客户端实现支付服务以及通道服务)的情况下，第四方面的方法还可以包括为矿工提供对与交易的给定客户端相关联的通道的访问。在客户端的所有通信由支付处理器管理或经由支付处理器实现的实施例中，这是有利的，使得通道也由支付处理器代表客户端进行设置。在一些实施例中，通过使通道标识符和/或位置以及一个或多个访问令牌对于矿工而言可获得，可以提供访问，矿工可能需要这些来访问与该通道相关联的一个或多个通道功能和/或消息功能或API，以便为该客户端向通道中获取数据或写入数据。

一旦已经提供了通道或已经提供了对该通道的访问，则随后使用该通道向客户端提供来自矿工的、与对应区块链交易相关联的回调通知。因此，矿工可以使用该通道来提供数据，即，使用一个或多个通道功能和消息功能或API(它们是使用相应通道的访问令牌来获取的)将数据写入通道中。

在一些实施例中，针对客户端的回调通知可以是警报或消息，该警报或消息是在数据被写入通道时立即获取的，在一些情况下，所述通知包括通道标识符。回调通知被称为回调，因为它涉及给定客户端的特定TxID或区块链交易，该特定TxID或区块链交易已经由支付处理器进行处理，即，已经由支付处理器发送给矿工。有利的是，通道使得能够在被特定地分配了给定客户端的TxID的通道中提供消息或响应。

在一些实施例中，回调通知涉及已经由给定客户端提交并记录在区块链中的交易的双重花费的通知。在这种情况下，矿工在通道中提供的数据为返回有效载荷，其包括以下数据：

-作为双重花费的区块链交易的交易标识符(TxID)；以及，在某些情况下，可选地

-提交了区块链交易的支付处理器的服务端点。在客户端与多个支付服务相关联的情况下，这是有用的，并且因此，标识符清楚地表明了首先向矿工提交请求的支付处理器。

在一些实施例中，回调通知涉及由给定客户端提交的交易被包括在区块链中的证明，即默克尔证明。在这种情况下，矿工在通道中提供的数据是通道中的返回默克尔证明，所述返回默克尔证明由矿工提供，所述返回默克尔证明包括以下数据：

-与默克尔证明相关的区块链交易的交易标识符(TxID)；

-包括区块链交易的区块的区块标头；以及

-交易标识符(TxID)的同级散列数组。

在一些实施例中，所提供的一个或多个通道功能或消息功能包括基于超文本传输协议(HTTP)的JavaScript对象表示法(JSON)API，以便能够访问、创建和/或管理通道中的、用于回调通知的一个或多个数据或消息。

经由通道提供的与回调通知相关联的这些数据或回调消息对于与区块链相关联的许多应用程序来说可以是特别有利的，因为矿工随后可以使用通道直接向另一实体(即，客户端，在这种情况下，是请求了交易提交的客户端)发送被提交给区块链的交易的默克尔树包括证明或双重花费通知。这是有用的，因为这意味着客户端(诸如商户或其他实体)不再必须搜索区块链来找到此类交易，以评估其是否已被挖掘。这是因为有利的是，一旦被挖掘，则使用通道直接提供了包括证明。

第四方面的第二实现的方法还包括存储所述通知和/或向客户端提供所述通知。在一些实施例中，当客户端离线或未通信联接到通道处理器时，回调通知由通道处理器存储，即，作为数据的推送通知，该数据在通道中排队以用于给定客户端。在其他实施例中，当客户端在线或通信联接到通道处理器时，通道中的相关数据(其与回调通知相关联)可以直接从通道中提取。

有利的是，通道的使用允许对给定通道中的每个请求或消息进行异步处理。这允许对通道中的消息进行无缝且准确、不连续或延迟的处理流程，因为对于任何给定的主题或交易，顺序以及消息始终是清晰的，这是因为该通道特定于此类主题。对于客户端或其他实体可能无法运行或在线，或无法处理与回调通知相关联的任何数据的实现或情况，这可能是特别有用的。因此，上述技术使得即使在通道的一方离线或无响应的情况下，仍然能够使用通道可靠地传送请求以及准确地且按顺序地处理请求，因为在该通道的一方下次在线或连接到网络时消息仍将存在于通道中，因此该通道的一方可以基于由通道处理器进行排队的通知来访问通道中的消息。如上所述，通道处理器的功能也可以由实现支付处理器的同一实体来实现。

此外，无论通道中可能已经提供了多少其他消息，其他实体都能够按照传送的顺序来访问这些消息。因此，尽管连接存在延迟或中断，但对通道中的消息的处理仍能准确无缝地完成，就好像根本没有延迟一样。

因此，上述第四方面的第二实现及其与本公开相关联的实施例通过实现用于直接通信的通道而提供了一种用于为客户端处理交易的安全的、链外的、方对方(点对点/直接)应用程序消息传递机制。该方面提供了一种机制，各方可以经由该机制以安全的方式进行通信，即使在其中一方暂时离线的情况下也是如此。对于与企业相关联的或可能代表组织的客户端实体(诸如商户)，此类客户端可能具有大量其他实体(顾客)就大量商品与他们进行交易。因此，在这种场景下，通过使用通道与一个或多个顾客或交易进行通信，同时分离或断联与维护所有此类交易记录的区块链相关的任何功能，将是非常有益的。经由通道服务提供通道功能以及消息功能，此类客户端能够针对与特定交易(诸如特定单据或对于特定商品的查询等)相关的特定顾客使用特定通道，并能够随时经由所述通道获取特定于此类交易的任何进一步信息。

在第四方面的第三实现中，本公开提供了一种计算机实施的方法，用于处理与区块链相关联的交易，该方法由与客户端相关联的一个或多个处理器实施。第三实现类似于第二实现，并且与类似的优点相关联。该方法包括以下步骤：发送与通道服务有关的通道请求，所述通道服务由通道处理器实现。通道处理器可以为客户端实现通道服务，如申请号为2007597.4的英国专利申请所述。第一请求可以是去往通道处理器的超文本传输协议安全(HTTPS)传输GET请求。随后，客户端实施的方法包括获取对一个或多个功能的访问，该一个或多个功能使得给定客户端和另一实体之间能够直接通信。与第二实现类似，所述一个或多个功能包括：与用于传输数据的一个或多个通道有关的通道功能或程序；和/或与使用一个或多个通道传输的数据有关的消息功能或程序。客户端还获取用于通道的一个或多个访问令牌，如上所述。

随后，所述方法包括向实现支付服务的支付处理器(诸如第一方面中或第四方面的第一实现中所解释的处理器)发送针对向区块链提交与数字资产相关联的交易的请求。该请求可以是去往支付处理器的超文本传输协议安全(HTTPS)传输POST请求，其可以与HTTPS API相关联。

随后，客户端从支付处理器获取响应，该响应包括与所提交的交易相对应的区块链交易的交易标识符(TxID)。对应区块链交易与由支付处理器提交给矿工的交易有关。在响应中接收到的TxID对于已由矿工生成的、与该TxID对应的区块链交易的跟踪是有用的。

客户端还与上述响应分开或一起地从支付处理器接收提供TxID的矿工的标识符或接入点或位置。

随后，通过使用从通道处理器接收的一个或多个通道功能，所述方法包括：创建用于与所识别的矿工进行通信的通道，并将与该通道相关联的一个或多个访问令牌发送给另一实体，在这种情况下，该另一实体为矿工。这有利地实现了安全、可靠且准确地建立通道，以用于客户端和矿工之间的直接通信。

随后，从通道处理器接收回调通知，当客户端在线时或通信地连接到支付处理器时，该回调通知可以在客户端处接收。基于该通知，当客户端在线时，客户端可以直接从矿工获取与特定区块链交易有关的数据(即，与客户端相关联的TxID)。

第四方面的第三实现的一些实施例涉及针对用于点对点通信的通道提供安全寻址和加密。在一些示例中，该方法包括：提供与客户端相关联的客户端寻址密钥，以及获取与矿工相关联的至少一个矿工寻址密钥。在一些情况下，如果客户端端点和矿工端点尚未可供客户端使用或尚未被客户端已知，则也可以提供客户端端点，并可以获取矿工端点。寻址密钥可以是静态密钥或临时密钥或这两者，并且可以用于验证相应端点的身份。在这种情况下，可以基于客户端寻址密钥和/或矿工寻址密钥来发起使用通道的通信，使得可以基于握手模式导出共享密钥。随后，此类共享密钥可以用于对经由通道的所有通信进行加密。握手模式可以基于噪声协议格式，但是也可以使用其他机制来导出加密/解密的密钥或密钥对，诸如Libsodium密钥交换或生成技术。

有利的是，提供端点(诸如用于客户端的API端点)以及寻址密钥(诸如静态密钥和/或动态密钥/临时密钥)，允许与客户端相关联的一个或多个处理器安全地访问矿工。在一些实施例中，密钥还允许在经由通道进行任何消息传输之前发起验证过程，从而通过对管理通道的各方的身份进行验证来提高安全性，由此确保经由通道的所有通信仅发生在两个经验证的实体之间。

获取共享密钥以便基于共享密钥对使用通道的直接通信进行加密是进一步有利的，这是因为共享密钥是基于身份的(即，管理通道的两方或实体的寻址密钥)。因此，只有相应的有效方和经验证方能够对加密后的密文进行解码，从而提高可靠性和隐私性，并抵抗恶意方的假冒企图。

在一些实施例中，用于客户端和/或矿工的端点可以是HTTP API端点，并且其中在经由通道进行通信之前，使用HTTP安全(HTTPS)传输协议将所述端点传送给另一方(或对手方)。这有利地确保了端点能够通过指向回已知且受信的证书颁发机构(CA)的证书链进行验证。在一些实施例中，客户端端点以及矿工端点可以是通用资源位置(URL)，该通用资源位置(URL)被包括在针对请求的响应中，该请求针对与通道服务相关联的一个或多个功能。通过上述方式，有利的是，一方的身份可以由通道的至少一方使用PKI或其他机制来知晓和验证。

在一些实施例中，用于客户端的端点可以是与通道的相应实体相关联的别名，其中，别名特定于客户端并由基于别名的寻址服务提供，该寻址服务具有能够从限定的或已知的位置进行访问的机器可读资源，该机器可读资源包括与通道处理器有关的一个或多个功能。别名可以是已知的或者被提供给一个或多个其他条目，所述别名与用于验证的非对称加密密钥对相关联。通过上述方式，有利的是，双方可以使用PKI或其他机制来知晓和验证双方的身份。已经存在这样的机制，在此类机制中，对一个或多个客户端实体使用难忘的且更用户友好的别名，而不是复杂的公共地址。以nChain控股有限公司名义提交的、申请号为16/384696的美国专利申请中提出了这种解决方案。这些文件描述了基于别名的支付服务和相关联的协议，其被称为bsvalias支付服务，其中，替代客户端实体的公共地址而使用别名进行目的地寻址。在这种系统中，别名通常与发送/接收客户端实体的域名相关联，并且可以是URI或电子邮件地址。因此，只要发送方或实体知道或被提供有别名，则这对于bsvalias支付系统或其他基于别名的寻址机制来说就是足够的。例如，通过使用机器可读资源中提供的指令，可以将消息发送到客户端的别名，该指令诸如JavaScript对象表示法(JSON)文档，其被保存在众所周知的、用于bsvalias支付服务或其他支付服务的URI或位置中。

在第四方面的第四实现中，本公开提供了一种计算机实施的方法，用于处理与区块链相关联的交易，该方法由与矿工相关联的一个或多个处理器实施。第四实现类似于第一实现，并且具有类似的优点。

在该实现中，矿工从支付处理器接收向区块链提交交易的请求。在一些实施例中，这可以类似于第三方面中所讨论的来自支付处理器的第二请求，该第二请求是针对代表客户端提交交易。

随后，该方法包括：生成与请求相对应的区块链交易，并将响应和与区块链交易相关联的输出脚本(UTXO)发送给支付处理器。输出脚本包括与对应区块链交易相关联的交易标识符(TxID)。如上所述，还可以将与矿工相关联的接入点或标识符与响应一起提供给客户端。

随后接收对通道的访问，该通道对于TxID而言是特定于客户端的。该访问可以由客户端在创建通道之后直接提供，也可以由支付处理器代表客户端提供。如前所述，该通道能够实现与给定客户端的直接通信。还接收用于对通道进行访问以将数据写入通道的访问令牌。

基于访问令牌，矿工随后可以获取、访问或检索消息功能或消息API，以在通道中提供与回调通知相关联的数据，该数据与对应区块链交易(TxID)有关。如上所述，回调通知可以与给定交易的双重花费通知或默克尔证明相关，该通知可以经由通道直接、安全、准确和异步地传送给客户端。

因此，在第四实现中，矿工可以获取与通道相关联的通道API或消息API和/或访问令牌，以实现与客户端的直接通信。这对于与区块链相关联的许多应用程序来说是特别有利的，因为矿工随后可以使用通道将特定于被提交给区块链的交易的默克尔树包括证明或任何其他消息直接发送给客户端。这是有用的，因为这意味着不再需要客户端(诸如商户)或另一实体(诸如顾客或实际上支付服务)必须搜索区块链以找到此类交易或对其状态进行验证。这是因为有利的是，一旦被挖掘，就可以使用通道将包括证明直接发送给客户端。或者，如果由于某种原因，与TxID相关联的交易未被挖掘，则可以经由通道为交易发送诸如错误通知或双重花费通知等消息。

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

在一些实施例中，提供了一种包括处理器和存储器的计算设备，该存储器包括可执行指令，由于处理器对该可执行指令的执行，该可执行指令使得该设备执行上述所讨论的各方面和/或实施例。

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

现在参考附图以图示的方式描述了一些具体实施例，其中，相同的附图标记表示相同的特征。

第一方面-支付处理器

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

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

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

例如，在一些实施例中，支付处理器可以使用基于标准的接口设计(诸如REST接口)来实现支付服务。REST(表述性状态转移)是一种架构样式，其用于开发web服务以及基于web的交互。REST API设计标准可以使用以下命令来处理HTTPS请求和通信：

命令	GET	POST	PUT	DELETE
					资源	读取	创建	更新	删除

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

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

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

从每个矿工收集的、与所获取的费用报价相关的数据可以被定义为JSON对象，如以下示例所示。

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

为了便于理解，下面还给出了上述JSON对象FeeQuotes的另一示例，其中填充有数据项：

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

CurrentHighestBlockHash可以用作标记，以标识在调用getFeeQuote()时区块链已经增长至的点处的区块散列。

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

SignatureTimestamp是指一时间，矿工在该时间保证以声称的当前费用来挖掘交易，即，保证该费用是从该点开始直至废止为止。如果客户端随后调用getFeeQuote()，则该时间废止。

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

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

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

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

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

如上所述，在一些实施例中，来自客户端的第二请求可以是请求提交多个交易。

第二交易中的所选费用报价可以基于由支付处理器提出的建议，也可以是由客户端为一个或多个交易而选择的。

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

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

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

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

随后，可以即时地或稍后挖掘该区块链交易，以按照当前费用报价完成挖掘过程。在一些情况下，所创建的交易可能不会被挖掘，因为另一矿工已将该交易写入区块链，或者所创建的交易可能因某种原因(诸如双重花费、延时或无效)而被挂起或拒绝。

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

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

以下所示的JSON对象TxResult用于相应的矿工并包括一些术语和对象，这些术语和对象在步骤104中作为FeeQuotes JSON对象的一部分进行了讨论。

以上所述的ReturnResult可以包括以下可能的值中的一个，这些值如以下所示：

·Submitted-没有无问题，交易被提交给内存池

·Rejected_DS-由于双重花费而拒绝-DoubleSpendTxID不能为Null(空)

·Rejected_Policy-由于违反策略而拒绝

·Rejected_Invalid-由于交易无效而拒绝

·Rejected_FeeTooLow-费用过低，因此矿工不会将Tx包括在区块中

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

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

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

在步骤118中，支付处理器从多个矿工中的相应矿工接收响应，该多个矿工与创建和/或处理和TxID相关联的区块链交易相关联。在一些实施例中，上述RPCgetRawTransaction(TxID)可以包括Verbose参数，该参数可以与被设置为1的变元相关。在这种情况下，如果成功地从相应矿工返回一结果，则在一些实施例中，从相应矿工返回的结果将是以JSON格式的，其包括解码后的步骤110和112中的对应区块链交易。这有利地提供了对返回结果中的数据进行捕获和处理的灵活性。如果Verbose参数被设置为0，则十六进制编码交易，而不是JSON数据类型或文档格式，会被返回给支付处理器。如果没有发现与TxID相关的此类交易，则可以返回Null(空值)，这进而会使得ReturnResult对象被设置为“Unknown(未知)”。任何其他返回的错误(error)还可以由矿工通过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不能为Null(空)

·Rejected_Policy–由于违反策略而拒绝

·Rejected_Invalid–由于交易无效而拒绝

·Rejected_FeeTooLow–费用过低，因此矿工不会将该Tx包括在区块中

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

·Unknown–交易未看到或不存在–具有所提供的TxID的交易可能不存在于内存池或区块链中。如果不存在，则这应该在ResultDescription中声明。

第二方面-客户端

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

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

步骤202描述了向与客户端相关联的至少一个支付处理器中的支付处理器发送第一请求，用于提供相应的支付服务。如结合图1的步骤102所讨论，该请求与为客户端挖掘交易的一个或多个费用报价有关。第一请求涉及步骤102中所讨论的HTTPS GET-FeeQuote。如以上所讨论的，该请求可以是为客户端挖掘任何交易的请求，也可以是用于得到挖掘与数字资产支付有关的交易的费用报价的请求，该数字资产支付来自与客户端相关联的顾客。

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

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

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

步骤210描述了以下步骤：发送第二请求，以将与从顾客去往支付处理器的数字资产支付相关联的给定交易提交给区块链。该步骤中的提交是基于步骤206中的针对挖掘给定交易的所选费用报价。该步骤涉及在图1的步骤108中客户端向支付处理器发送HTTPSPOST submitTransaction(Tx)请求，其中还有针对给定交易的以JSON数据类型格式的相关详细信息。

步骤212描述了以下步骤：接收与所提交的交易相对应的区块链交易的交易标识符(TxID)。如图1的步骤110和112中所讨论的，TxID由满足所选费用报价的至少一个矿工创建。在一些实施例中，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中响应于第一请求而提供当前费用报价相关的步骤可以单独地且独立于其余步骤实施。类似地，与从步骤208到212中响应于第二请求而生成对应区块链交易相关的步骤可以单独地实施，并且在与获取费用报价的先前步骤不同的时间实施。以同样的方式，与步骤316中提供交易状态相关的步骤可以在客户端已经知道交易的标识符之后的任何时间实施，并且不需要遵循图3的顺序。本文中按顺序示出的所有步骤仅是为了便于解释和理解，并且在任何情况下，本公开都不应被视为限于这种顺序或场景。此外，如上文结合图1和图2所讨论的，可以每次针对单个交易来单独地请求和/或获取和/或提交和/或查询费用报价，或者每次针对客户端在单个请求中提交(即，同时提交)的一组或一批多个交易来单独地请求和/或获取和/或提交和/或查询费用报价。为了便于解释和理解，图3将结合第一请求/第二请求中的单个交易以及与客户端相关联的状态查询来进行解释，但本公开并不以任何方式受限于此。

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

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

步骤306描述了以下步骤：多个矿工中的矿工接收第二请求，该第二请求涉及向区块链提交与客户端相关联的给定交易，其中，该给定交易基于来自客户端的所选费用报价。给定交易与图2的步骤210中的POSTsubmitTransaction(Tx)(即，客户端和顾客之间的给定数字资产支付交易)中的Tx相关。从支付处理器接收的给定交易的RPC版本是给定交易的RPC createRawTransaction(Tx)，如结合图1的步骤110所述。

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

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

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

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

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

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

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

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

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

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

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

第四方面-回调标识符

图8是一流程图，其描述了一种根据第四方面的有助于交易的回调机制的方法。该附图涉及由与支付服务相关联的一个或多个处理器实施的方法，如上文结合第一方面所讨论。

步骤802包括从一个或多个客户端中的给定客户端接收请求。该请求涉及提交与数字资产相关联的交易。例如，该请求可以是图1的步骤108中所解释的针对提交交易的第二请求。该请求还与回调标识符相关联。在一些实施例中，回调标识符可以是由客户端提供的回调标识符，或者是与客户端相关联的回调标识符。例如，回调标识符可以是URL或API端点，通过使用该URL或API端点可以联系客户端。在一些情况下，回调标识符也可以指向与客户端相关联的位置。在一些情况下，回调标识符可以是位置或标识符通信通道。这种通道将在下面的图9至图11进一步进行解释。回调标识符的目的是启用或允许一种在客户端和另一实体之间建立直接通信的措施。回调标识符特定于客户端，并且在一些情况下，特定于特定主题，诸如与该步骤中的请求相关联的交易。

步骤804包括将与请求相关联的交易提交给多个矿工中的给定矿工，以将该交易包括在区块链中。这类似于图1的步骤110中针对第二请求执行的过程。

步骤806包括向客户端识别给定矿工。这可以通过许多技术来执行，诸如向客户端提供与给定矿工相关联的端点或URL。这可以使用HTTPS传输协议被发送到客户端。在一些情况下，如果矿工与用于寻址(诸如使用上面提到的bsvalias寻址服务)的别名相关联，则可以将该别名提供给客户端。在一些情况下，如果矿工与上述Miner ID(矿工ID)和/或声誉相关联，则此类信息也可以被提供给客户端。在一些情况下，该识别步骤可以与下文所述的步骤812一起完成或在步骤812之后完成。

步骤808包括向矿工提供步骤802中所描述的回调标识符，使得矿工可以使用该回调标识符直接联系客户端。在一些情况下，如果支付处理器代表客户端处理通信，则回调标识符可以指向支付处理器。该附图涉及回调标识符用于客户端的场景，但本公开不限于此。例如，回调标识符可以是唯一识别客户端或支付处理器的加密标识符(端点)。

在步骤810中，从给定矿工接收到响应，其中具有与对应区块链交易相关的详细信息，该对应区块链交易已在步骤802中为交易请求而生成。该响应将包括交易的交易标识符(TxID)，该交易标识符(TxID)可以被提供给客户。在一些情况下，步骤806中的矿工身份可以在接收TxID时或之后被提供给客户端。在一些实施例中，该步骤中的响应包括输出脚本，例如未花费交易输出(UTXO)，该输出脚本与上述第一方面中提到的对应区块链交易相关联。随后，该对应区块链交易的交易标识符(TxID)被发送给客户端。

步骤812包括基于步骤802中提到的回调标识符为客户端启用或处理至少一个回调通知，该至少一个回调通知与由矿工提供的对应区块链交易(TxID)有关。如果该回调标识符是客户端的回调端点URL或URI，则消息可以作为HTTP POST消息被直接提供给此类位置。消息可以基于一种或多种已知技术进行加密。

图9涉及本公开第四方面的第二实现，其中与请求相关联的回调标识符与由通道处理器提供给客户端的通道相关。如上所述，通道处理器可以是为客户端提供通道服务的单独实体，或者可以是与支付处理器相同的实体。该附图中的以下步骤描述了由通道处理器实现的实施例。

步骤902描述了从已经签约了通道服务的给定客户端接收与通道相关联的请求，诸如以nChain控股有限公司的名义提交的、申请号为2007597.4的英国专利申请中所讨论。本实施例中的该请求与创建通道有关。然而，通道服务能够实现其他功能，诸如更新与现有通道相关联的API。在大多数情况下，可以检查客户端的身份，以查看客户端是否已经注册以使用通道服务及其提供的功能。在一些实施例中，这可以在注册期间基于已知的认证方法，诸如由密码保护的登录认证等。验证可以基于接收到的密码，该接收到的密码与所存储的记录中的密码匹配。在其他实施例中，基于加密或寻址私钥/公钥对的标准PKI技术也可以用于验证可能存在于步骤902中从客户端接收到的请求中的数字签名。在这种情况下，客户端的身份可以通过以下方式进行验证：检查由私钥签名的请求是否可以使用公钥成功地恢复或验证。如果客户端无效或未注册，则要么是步骤902中的请求未进一步进行，要么是注册步骤可能由通道服务发起。

在步骤904中，将所请求的通道功能和/或消息功能提供给客户端。

以下示出了与用于创建通道功能和/或消息功能/API的请求相关联的模式和/或格式的一些示例，以及由通道处理器所提供的响应的示例模式。

通道API：

通道API可以是由通道服务提供的基于HTTP API的JSON客户端帐户，用于创建和/或管理用于点对点通信的通道。

在一些实施例中，所有API端点可能需要验证。具体的验证方案可以针对实现来确定。常见的形式包括诸如OAuth、基本验证(basic authentication)以及不记名令牌方法(bearer token method)等方案。如上所述，通道API可以可选地由API令牌来保护，这些API令牌由客户端提供或生成。

创建通道：创建由客户端(即，通道服务的账户持有人)拥有的新通道请求格式：

响应格式：

成功创建的响应包括初始访问令牌。帐户凭证可以用于访问通道API，但令牌可能需要用于访问Messaging API(消息传递API)。用于此的该初始访问令牌属于账户持有人，以用于这些账户持有人读取和写入通道的目的。

Message API(消息API)允许账户持有人和相关对手方(通道的另一实体)从给定通道读取消息或将消息写入给定通道。以下Message API(消息API)可以作为基于HTTP API的JSON(JSON-over-HTTP API)被提供用于账户持有人及其交易对手方，以用于交换消息。

2.1用于新消息的测试通道

请求格式：

HEAD/api/channel/<id>

Authorization:<api-token>

响应格式：

201OK

ETag:<max-sequence>

2.2将消息写入通道

请求格式：

POST/api/channel/<id>

Authorization:<api-token>

Content-type:...

Content-length:...

响应格式：

a)Accepted(已接受)

信息被写入通道

201Created(已创建)

b)排队失败

通道是按顺序创建的，并且与请求相关联的API令牌尚未被标记为已读取通道中的最新消息。如果仍然适合，则客户端可能需要重试写入尝试。

409冲突

c)消息过大

在由端到端加密来保护所有消息的实施例中，例如基于噪声协议，任何单个消息的最大大小被设置为65536字节。由于不应有大于此字节的消息，因此在一些实施例中，限制被写入通道的任何消息的最大大小可能是有用的。大于此字节的消息可能会被通道拒绝。

413有效载荷过大

d)超过存储配额

在一些实施例中，可能已经超出由服务运营商设置的配额。客户端请求可能是有效的，但存储服务此时无法满足该请求。

507存储不足

2.3获取通道中的消息

返回来自通道的所有消息，这些消息可选地被过滤为未读的。

请求格式：

GET/api/channel/<id>[？unread＝true]

Authorization:<api-token>

未读查询字符串参数是可选的。

响应格式：

2.4将消息标记为已读或未读：将消息标示为已读或未读

请求格式：

POST/api/channel/<id>/<sequence>[？older＝true]

Authorization:<api-token>

Content-type:application/json

Content-length:...

{"read":true|false}

可选的顺序参数允许客户端在单个调用中将顺序低于或等于所提供的<sequence>路径变元的所有消息标记为已读。

响应格式：

201 OK

在步骤906中，将与所请求的通道相关联的访问令牌或API令牌提供给客户端。如果有需要，则在一些实施例中，访问令牌也可以被废止或撤销，例如如果许可已经被修改，或者客户端对于给定通道不再要求许可的话。

用于此情况的示例模式如以下所示：

3.1生成通道API令牌

请求格式：

响应格式：

这只是使令牌值返回的API调用。如果丢失，则该令牌应被删除或被替换为新的令牌。

1.6撤销通道API令牌

请求格式：

DELETE/api/account/<account-id>/channel/<channel-id>/api-token/<token-id>

Authorization:...

响应格式：

204没有内容

步骤908示出了提供通知或警报或任何其他信息，它们是为客户端关于特定主题(诸如交易)而安全地从另一实体(在如图8所示的实施例中，该实体是矿工)接收的。因此，这被称为与特定交易相关的回调通知，该特定交易可以具有图8中提到的TxID。回调通知可以是状态变化的通知，或者也可以是在给定交易或主题(为它们创建通道)发生异常的情况下的任何其他通知。

由于通知是经由通道接收的，因此客户端不需要始终在线，并且每当客户端与通道处理器连接或重新连接(在线)时，通知就可以被异步地传送。在一些情况下，可以提供一些设置，这些设置能够强制客户端应保持连接的最短时间，或者设置可以确保客户端保持连接，直到通道中的所有“未读”警报或通知被客户端或与客户端相关联的钱包消耗。因此，在一些实施例中，一旦通知被客户端从通道消耗或接收，就可以允许客户端断开连接。可以为给定客户端提供很多此类通道——为每个主题或交易提供一个通道。

在一些实施例中，可以有附加的步骤来检测客户端是否被连接到通道处理器，即是否在线，是否离线。该检测可以通过已知技术来完成，以在一个或多个通知或消息到达通道时查看与客户端是否存在网络连接。

当客户端在线时，用于客户端的回调通知或消息一旦进入通道就由该客户端“提取”以确保同步，即与通道中的消息和被传送给客户端的消息同步。

如果在通道通知到达时客户端未连接或离线，则这些通知被存储在与通道处理器相关联的存储器或高速缓存中。在一些实施例中，这可以是特定于给定客户端的。一旦客户端在线或者检测到客户端已连接，则这些通知被推送或提供给客户端实体。推送通知可以被发送到客户端，使得客户端可以获取通道中的数据或未读消息。因此，当客户端离线时，消息或通知由通道服务或通道处理器存储。一旦客户端在线，则这些消息或通知就会被提供给客户端。

尽管在另一实体是挖掘来自客户端的交易的矿工的情况下，任何类型的消息都可以在通道中发送，但在大多数情况下，矿工和客户端之间直接通信的场景如下：

1.当交易状态更新或变化时

2.当收到来自矿工的针对信息的特别请求时

在第一场景中，每当客户端需要被通知状态变化或异常(诸如交易的双重花费)、或确认挖掘、或确认交易的有效性或无效性等时，就会发出回调通知。

在第二场景中，客户端可以在某一时间(可能是周期性的或任意的时间)使用同一通道直接从矿工请求状态更新。

图10涉及本公开第四方面的第三实现，其中客户端与由通道处理器实现的通道服务相关联，如图9所示。第三实现适用于此类实施例，其中图8中的回调标识符是客户端通过使用通道服务而创建的通道。该图中的以下步骤描述了由客户端实现的实施例。

在步骤1002中，客户端准备了针对通道服务的请求，并将该请求发送到通道服务(通道处理器)。所准备的请求可以由客户端通过使用超文本传输协议(HTTP)或类似的传输协议格式来发送。在一些实施例中，所准备的请求被发送到作为HTTP或REST API实现的通道处理器，并且响应也可以以HTTP传输协议格式提供给客户端。如上所述，通道处理器可以是与支付处理器相同的实体，或者可以是单独的实体。

本实施例中的请求涉及创建通道，该通道可以启用、允许或提供与另一实体(诸如矿工)直接通信的机制。

在步骤1004中，从通道处理器接收一个或多个功能(诸如通道功能或消息功能/API)，以使客户端能够创建通道从而确保与另一实体直接通信。这些通道功能和消息功能在图9的步骤904中示出，从通道处理器接收。还针对该通道接收消息API以及针对该请求的访问令牌(如步骤906中所示)。

步骤1006描述了向支付处理器发送请求，以请求提交与数字资产相关联的交易。该交易可以是与客户端的顾客相关联的支付交易或类似交易。该步骤类似于图2的步骤208，也如上文结合图8的步骤802所述。该请求经由HTTP被发送到支付处理器的API，并且可以是POST请求。

在步骤1008中，从支付处理器接收交易标识符(TXID)。这基于来自给定矿工的响应，如图8的步骤810所述。

在步骤1010中，客户端识别或得知该矿工，该矿工在先前步骤中已将TxID发送给支付处理器。这可以基于与矿工相关联的API或位置或Miner ID(矿工ID)和/或声誉，如图8所讨论。

步骤1012中，在步骤1004中从通道处理器接收到的API随后被用于创建一通道，该通道与在先前步骤1010中识别的矿工相关联。接收到的访问令牌可以用于验证其他实体，并提供对与通道相关联的各种功能的访问。在一些实施例中，消息API以及访问令牌可以被发送到另一实体以用于经由通道进行通信。在一些实施例中，在创建通道之后，可以在客户端和矿工之间发生握手协议以建立密钥，该密钥用于保护经由该通道的通信。任何已知的方法，诸如噪声协议框架或Libsodium密钥交换机制，可以用于此目的。

在步骤1014中，经由通道接收来自矿工的响应。这是可能的，因为其他方(即矿工)在先前步骤中已接收到所有需要的消息API和访问令牌，以用于与那时的客户端直接通信。来自矿工的响应将与步骤1008中的特定TxID相关联，因此相应通道中的通信将特定于该交易标识符。消息可以涉及与TxID相关联的任何事项。例如，可以经由通道发送通知，以通知客户端该TxID是一先前交易的双倍花费。如果交易已经存在于临时内存池中，则可能会出现这种情况。或者，一旦交易被包括在一区块中，则消息可以与交易的默克尔挖掘证明相关联。

图11涉及本公开第四方面的第四实现，其中客户端与由通道处理器实现的通道服务相关联，如图9所示。第四方面适用于此类实施例，其中图8中的回调标识符是由客户端通过使用通道服务而创建的通道。该图中的以下步骤描述了由矿工实现的实施例。

在步骤1102中，矿工从支付处理器接收到针对挖掘交易的请求，如图8的步骤804所示。

在步骤1104中，矿工生成区块链交易。该步骤类似于图3的步骤310，其中在一些实施例中，生成了与所提交的交易对应的十六进制编码源交易。因此，提供了输出脚本或UTXO，该输出脚本或UTXO包括与已经由相应矿工创建的对应区块链交易相关联的交易标识符(TxID)。然后，区块链交易的输出脚本(UTXO)可以被添加到与矿工相关联的内存池中，以便即时地或稍后进行挖掘。

在步骤1106中，该对应区块链交易的交易标识符(TxID)随后经由支付处理器被发送给客户端，使得客户端可以访问TxID，并且还可以识别矿工。

在步骤1110中，一旦客户端通过使用通道服务创建通道以与矿工进行直接通信，则该矿工通过任何相关联的消息API和访问令牌来从客户端接收对通道的访问。

在步骤1112中，矿工检查在步骤1102中所提交的交易是否是先前交易的双重花费。如上所述，这可以通过以下方式来实现：检查相同的交易是否存在于与矿工相关联的辅助或临时内存池中，或者检查相同的交易是否已经在区块链中进行挖掘。

如果是这种情况，则矿工随后生成双重花费通知或警报，以使用该通道发送回客户端。当被激励以维护其声誉(可以通过矿工的Miner ID(矿工ID)来跟踪声誉)的矿工通知客户端有一尝试企图花费数字资产(诸如BSV)而该数字资产先前已经由同一客户端(即商户钱包)花费时，就会发出双重花费通知。

示例模式的一个版本可以是：

请求:

响应：

以下给出了双重花费通知的示例模式的另一版本：

请求:

响应：

在步骤1116中，如上所述的双重花费回调通知或“callbackpayload”被发送到callbackURL，在本实施例中，callbackURL是矿工已经接收到访问权的通道。通道可以由API或位置或标识符来识别。通过使用消息API和访问令牌，将通知添加到通道中，消息API和访问令牌与已经为矿工提供访问权的通道相关联。

如果在步骤1102中提交的交易不是双重花费，则在步骤1118中，矿工通过使用已知的挖掘技术继续在与区块链相关联的区块中挖掘该交易，其中一些技术在本申请的背景技术中进行了讨论。

在步骤1120中，矿工随后生成交易被包括在区块中的证明。

在一些实施例中，证明可以是默克尔树证明。这是一种已知的经验证的数据结构，其被组织为树。每个数据块的散列被存储在基础层或叶上的节点中，并且树或分支的每个内部节点包括加密散列，该加密散列是根据其两个子节点/同级节点的散列进行计算的。树的顶部节点(即默克尔根)唯一地识别了数据集，树根据该数据集进行构建。因此，默克尔树实现了有效的包括证明，其中，矿工或证明方节点通过向提交方或验证方节点发送带有审计路径的证明来向提交方或验证方节点示出某一数据块是经验证的数据集的一部分。审计路径包括重新计算默克尔根所需的节点散列，而无需提交方披露整个数据集。在比特币SV中，区块中所包括的交易被存储在默克尔树中。

示例模式可以是：

请求:

响应：

以下给出了默克尔证明通知的示例模式的另一版本：

请求:

响应：

在步骤1122中，矿工通过使用其具有访问权的通道将在区块链中的交易的包括证明这一证明直接发送给客户端。因此，客户端或支付处理器不需要运行区块链的副本或搜索区块链来找到所述交易。

现在转向图12，其提供了可以用于实施本公开的至少一个实施例的计算设备2600的说明性简化框图。在各种实施例中，计算设备2600可以用于实现以上所示和描述的任何系统。例如，计算设备2600可以被配置为用作附图中的DBMS的一个或多个组件，或者计算设备2600可以被配置为与给定用户相关联的客户端实体，该客户端实体对由图12的DBMS管理的数据库发出数据库请求。因此，计算设备2600可以是便携式计算设备、个人计算机或任何电子计算设备。如图12所示，计算设备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或蓝光)驱动器、以及其他类似的存储介质。此类程序和数据可以包括用于执行本公开中描述的一个或多个实施例的步骤的程序，以及与本公开中描述的交易和区块相关联的数据。

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

列举的示例实施例

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

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

从所述一个或多个客户端中的给定客户端接收请求，所述请求是向所述区块链提交与数字资产相关联的交易的请求，所述请求与回调标识符相关联，所述回调标识符用于实现所述给定客户端和所述交易的另一实体之间的直接通信；

将与所述请求相关联的所述交易提交给所述多个矿工中的给定矿工，以将所述交易包括在所述区块链中；

向所述客户端识别所述给定矿工；

将所述回调标识符提供给所述矿工；

响应于从所述给定矿工接收到针对所述请求的、与对应区块链交易有关的响应，所述方法还包括：

为所述客户端启用或处理与由所述矿工提供的对应区块链交易有关的至少一个回调通知，所述回调通知基于与所述请求相关联的回调标识符。

2.根据条款1所述的方法，其中，从所述矿工接收到的响应与交易标识符(TxID)相关联，所述方法还包括：向所述客户端发送所述对应区块链交易的交易标识符(TxID)。

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

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

使用超文本传输协议安全(HTTPS)传输协议格式从所述客户端接收请求；

将相应的请求转换为远程过程调用(RPC)格式，并将所述RPC提交给所述矿工；

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

对相应的响应进行转换，以便使用HTTPS传输协议发送给所述客户端。

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

6.根据前述任一条款所述的方法，其中，所述回调通知与由所述给定客户端提交的交易的双重花费的通知相关，或者其中，所述回调通知与由所述给定客户端提交的交易被包括在所述区块链中的证明相关。

7.根据前述任一条款所述的方法，其中，所述回调标识符是与所述客户端相关联的通道的位置，或者其中，所述回调标识符是用于所述客户端的通用资源标识符(URI)。

8.根据前述任一条款所述的方法，还包括：为所述给定矿工提供对所述通道的访问的步骤，其中，所述提供步骤包括：向所述矿工提供与所述请求相关联的通道的通道标识符或位置，以及与所述通道相关联的一个或多个访问令牌。

9.一种计算机实施的方法，用于为一个或多个客户端实现通道服务，所述方法由通道处理器实施并且包括以下步骤：

从所述一个或多个客户端中的给定客户端接收请求，所述请求与创建通道有关；

为所述给定客户端提供对一个或多个功能的访问，所述一个或多个功能使所述给定客户端和另一实体之间能够经由所述通道进行直接通信，其中，所述一个或多个功能包括：

与用于数据传输的所述通道有关的通道功能或程序；和/或

与使用所述通道进行传输的数据有关的消息功能或程序；

为所述通道发布一个或多个访问令牌，所述一个或多个访问令牌被配置用于经由所述通道与另一实体进行安全通信；以及

为所述给定客户端存储和/或提供与所述通道相关联的一个或多个通知。

10.根据条款9所述的方法，其中，所述一个或多个功能是为所述给定客户端发布的或提供给所述给定客户端的应用程序编程接口(API)，所述API包括用于所述通道的通道API和用于与所述通道相关联的数据的消息API；并且其中，所述访问令牌是特定于所述通道或给定消息的API令牌。

11.根据条款9或10所述的方法，其中，提供对一个或多个功能的访问的步骤包括：提供基于超文本传输协议(HTTP)的JavaScript对象表示法(JSON)API，以实现创建和/或管理一个或多个通道。

12.根据条款9至11中任一项所述的方法，其中，与所述通道相关联的所述一个或多个通知是来自矿工的回调通知，所述矿工是经由所述通道与所述给定客户端进行直接通信的所述另一实体。

13.根据条款12所述的方法，其中，所述回调通知与由所述给定客户端提交的交易的双重花费的通知相关。

14.根据条款13所述的方法，其中，所述回调通知与所述通道中的返回有效载荷相关联，所述返回有效载荷由所述矿工提供，所述返回有效载荷包括以下数据：

-作为双重花费的所述区块链交易的交易标识符(TxID)；以及可选地

-提交了所述区块链交易的所述支付处理器的服务端点。

15.根据条款12所述的方法，其中，所述回调通知与由所述给定客户端提交的交易被包括在所述区块链中的证明相关。

16.根据条款15所述的方法，其中，所述回调通知与所述通道中的返回默克尔证明相关联，所述返回默克尔证明由所述矿工提供，所述返回默克尔证明包括以下数据：

-与所述默克尔证明相关的区块链交易的交易标识符(TxID)；

-其中包括所述区块链交易的所述区块的区块标头；以及

-所述交易标识符(TxID)的同级散列数组。

17.根据条款9至16中任一项所述的方法，当所述客户端离线或未通信地连接到所述通道处理器时，所述一个或多个回调通知是数据的推送通知，所述数据在所述通道中存储或排队以用于所述给定客户端。

18.根据条款9至17中任一项所述的方法，当所述客户端在线或通信地连接到所述通道处理器时，从所述通道提供或提取与所述一个或多个回调通知相关联的所述数据。

19.根据条款9至18中任一项所述的方法，其中，所述通道处理器是支付处理器或包括支付处理器，并且其中，所述方法包括：根据条款1至8中任一项所述的由所述支付处理器实施的方法。

20.一种计算机实施的方法，用于处理与区块链相关联的交易，所述方法由与客户端相关联的一个或多个处理器实施并且包括以下步骤：

发送与通道服务有关的通道请求，所述通道服务由通道处理器实现，所述请求与创建通道以用于与另一实体进行通信相关；

从所述通道服务获取对一个或多个功能的访问，所述一个或多个功能能够实现所述给定客户端与所述另一实体之间的直接通信，所述一个或多个功能包括：

与用于数据传输的通道有关的通道功能或程序；和/或

与使用通道进行传输的数据有关的消息功能或程序；

从所述通道服务获取一个或多个访问令牌，所述访问令牌能够实现与所述另一实体的安全通信；

向实现支付服务的支付处理器发送请求，所述请求是向所述区块链提交与数字资产相关的交易的请求；

从所述支付处理器获取与所提交的交易相对应的区块链交易的交易标识符(TxID)；

基于来自所述支付处理器的响应，识别与所述对应区块链交易相关联的矿工；使用从所述通道处理器接收到的一个或多个通道功能，创建给定通道以用于与所识别的矿工进行通信；

将与所述给定通道关联的所述一个或多个访问令牌发送给所述矿工；

接收与所述给定通道相关联的至少一个回调通知，所述通知与所述给定通道中的与所述区块链交易相关联的数据有关，所述数据由所述矿工提供。

21.根据条款20所述的方法，其中，当所述客户端离线或未通信地连接到所述通道处理器时，作为在所述给定通道中排队的数据或消息的推送通知而获取所述回调通知。

22.根据条款20或21所述的方法，其中，当所述客户端在线或通信地连接到所述通道处理器时，从所述给定通道中提取与所述回调通知相关联的数据。

23.根据条款20至22中任一项所述的方法，其中，所述一个或多个功能是用于所述给定客户端的应用程序编程接口(API)，所述API包括：通道API，用于实现一个或多个通道的创建和/或管理；以及消息API，用于使所述给定客户端和一个或多个其他实体能够交换消息，和/或从所述给定通道读取数据和/或将数据写入所述给定通道；并且其中，所述访问令牌是特定于给定通道或给定消息的API令牌。

24.根据条款20至23中任一项所述的方法，其中，所述通道请求是去往所述通道处理器的超文本传输协议安全(HTTPS)传输GET请求，并且其中，去往所述支付处理器的请求是去往所述支付处理器的超文本传输协议安全(HTTPS)传输POST请求。

25.根据条款20至24中任一项所述的方法，还包括以下步骤：

提供客户端端点；

提供与所述客户端相关联的至少一个客户端寻址密钥；

获取矿工端点；

获取与所述矿工相关联的至少一个矿工寻址密钥；

基于所述客户端寻址密钥和所述矿工寻址密钥，使用所述给定通道交换一个或多个握手消息；

基于握手结果或握手模式，获取共享密钥；

其中，使用所述给定通道进行的任何通信基于所述共享密钥进行加密。

26.根据条款25所述的方法，其中，所述客户端端点是超文本传输协议(HTTP)应用程序编程接口(API)端点，并且其中，所述客户端端点使用HTTP安全(HTTPS)来实现。

27.根据条款25所述的方法，其中，所述客户端端点是通用资源位置(URL)，所述通用资源位置(URL)被包括在使用所述给定通道从所述给定客户端发送的消息中。

28.根据条款25至27中任一项所述的方法，其中，所述客户端端点是与所述客户端相关联的别名，所述别名特定于所述客户端并且由基于别名的寻址服务提供，所述寻址服务具有能够从限定位置或已知位置进行访问的机器可读资源，所述机器可读资源包括与所述客户端有关的一个或多个功能，并且其中，所述别名与用于验证的非对称加密密钥对相关联。

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

从所述支付处理器接收针对向区块链提交交易的请求；

生成与所述请求相对应的区块链交易；

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

接收对通道的访问，所述通道能够实现与所述给定客户端的直接通信；

基于与所述通道相关联的访问令牌，获取消息功能或消息API以用于在所述通道中提供或写入与回调通知相关联的数据，所述数据与所述对应区块链交易有关。

30.根据条款29所述的方法，其中，基于确定了所述对应区块链交易是由所述客户端提交的先前交易的双重花费；所述方法还包括：提供返回有效载荷的步骤，所述返回有效载荷包括以下数据：

-作为双重花费的所述给定区块链交易的交易标识符(TxID)；以及可选地

-提交了所述给定区块链交易的所述支付处理器的服务端点。

31.根据条款29所述的方法，其中，响应于在区块中挖掘所述对应区块链交易，所述方法还包括：提供返回默克尔证明的步骤，所述返回默克尔证明确认交易被包括在区块中，所述返回默克尔证明包括以下数据：

-与所述默克尔证明相关的区块链交易的交易标识符(TxID)；

-所述区块的区块标头；以及

-所述交易标识符的同级散列数组。

32.根据条款29至31中任一项所述的方法，还包括以下步骤：

获取客户端端点；

获取与所述客户端相关联的至少一个客户端寻址密钥；

提供矿工端点；

提供与支付处理器相关联的至少一个矿工寻址密钥；

基于所述客户端寻址密钥和所述矿工寻址密钥，使用所述通道交换一个或多个握手消息；

基于握手结果或握手模式，获取共享密钥；

其中，使用所述通道进行的任何通信基于所述共享密钥进行加密。

33.一种计算设备，包括处理器和存储器，所述存储器包括可执行指令，所述可执行指令由于被所述处理器执行而使得所述设备执行根据条款1至8中任一项所述的计算机实施的方法，所述计算设备与支付处理器有关。

34.一种计算设备，包括处理器和存储器，所述存储器包括可执行指令，所述可执行指令由于被所述处理器执行而使得所述设备执行根据条款9至19中任一项所述的计算机实施的方法，所述计算设备与通道处理器有关。

35.一种计算设备，包括处理器和存储器，所述存储器包括可执行指令，所述可执行指令由于被所述处理器执行而使得所述设备执行根据条款20至28中任一项所述的计算机实施的方法，所述计算设备与客户端有关。

36.一种计算设备，包括处理器和存储器，所述存储器包括可执行指令，所述可执行指令由于被所述处理器执行而使得所述设备执行根据条款29至32中任一项所述的计算机实施的方法，所述计算设备与矿工有关。

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

支付处理器，经由无线通信网络通信地联接到至少一个客户端和至少一个矿工，其中所述支付处理器是根据条款33中所述的计算设备来实现的；

客户端，经由无线通信网络通信地联接到所述支付处理器，并且能够与至少一个顾客进行通信；所述客户端是根据条款35所述的计算设备来实现的；

所述客户端经由无线通信网络通信地联接到通道处理器，其中所述通道处理器是根据条款34中所述的计算设备来实现的；以及

多个矿工，经由无线通信网络通信地联接到所述支付处理器，每个矿工是根据条款38中所述的计算设备来实现的。

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

应注意的是，上述方面和实施例说明而不是限制本公开，并且本领域技术人员将能够在不脱离所附权利要求限定的本公开范围的情况下设计许多替代实施例。在权利要求中，任何置于括号内的附图标记不应被解释为限制权利要求。词语“包括”和“包含”等不排除在任何权利要求或整个说明书中列出的元件或步骤之外的元件或步骤的存在。在本说明书中，“包括”是指“包括或由……组成”，“包含”是指“包含或由……组成”。元件的单数表示不排除此类元件的复数表示，反之亦然。本公开可以通过包括多个不同元件的硬件以及通过适当编程的计算机来实现。在列举了多个模块的设备权利要求中，这些模块中的多个可以由同一项硬件来实现。某些措施在相互不同的从属权利要求中进行了陈述，这并不表明这些措施的组合不能被有利地使用。

Claims (38)

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

从所述一个或多个客户端中的给定客户端接收请求，所述请求是向所述区块链提交与数字资产相关联的交易的请求，所述请求与回调标识符相关联，用于实现所述给定客户端和所述交易的另一实体之间的直接通信；

将与所述请求相关联的交易提交给多个矿工中的给定矿工，以将所述交易包括在所述区块链中；

为所述客户端识别所述给定矿工；

将所述回调标识符提供给所述矿工；

响应于从所述给定矿工接收到与所述请求的对应区块链交易有关的响应，所述方法还包括：

为所述客户端启用或处理与由所述矿工提供的对应区块链交易有关的至少一个回调通知，所述回调通知基于与所述请求相关联的回调标识符。

2.根据权利要求1所述的方法，其中，从所述矿工接收到的响应与交易标识符(TxID)相关联，所述方法还包括：向所述客户端发送所述对应区块链交易的交易标识符(TxID)。

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

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

使用超文本传输协议安全HTTPS传输协议格式从所述客户端接收所述请求；

将相应请求转换为远程过程调用RPC格式，并将所述RPC提交给所述矿工；

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

对相应响应进行转换，以便使用HTTPS传输协议发送给所述客户端。

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

6.根据前述任一权利要求所述的方法，其中，所述回调通知与由所述给定客户端提交的交易的双重花费的通知相关，或者其中，所述回调通知与由所述给定客户端提交的交易被包括在所述区块链中的证明相关。

7.根据前述任一权利要求所述的方法，其中，所述回调标识符是与所述客户端相关联的通道的位置，或者其中，所述回调标识符是用于所述客户端的通用资源标识符URI。

8.根据前述任一权利要求所述的方法，还包括：为所述给定矿工提供对所述通道的访问的步骤，其中，所述提供步骤包括：向所述矿工提供与所述请求相关联的通道的通道标识符或位置，以及与所述通道相关联的一个或多个访问令牌。

9.一种计算机实施的方法，用于为一个或多个客户端实现通道服务，所述方法由通道处理器实施并且包括以下步骤：

从所述一个或多个客户端中的给定客户端接收请求，所述请求与通道的创建有关；

为所述给定客户端提供对一个或多个功能的访问，所述一个或多个功能使所述给定客户端和另一实体之间能够经由所述通道进行直接通信，其中，所述一个或多个功能包括：

与用于数据传输的通道有关的通道功能或程序；和/或

与使用所述通道进行传输的数据有关的消息功能或程序；

为所述通道发布一个或多个访问令牌，所述一个或多个访问令牌被配置用于经由所述通道与另一实体进行安全通信；以及

为所述给定客户端存储和/或提供与所述通道相关联的一个或多个通知。

10.根据权利要求9所述的方法，其中，所述一个或多个功能是为所述给定客户端发布的或提供给所述给定客户端的应用程序编程接口API，所述API包括用于所述通道的通道API和用于与所述通道相关联的数据的消息API；并且其中，所述访问令牌是特定于所述通道或给定消息的API令牌。

11.根据权利要求9或10所述的方法，其中，提供对一个或多个功能的访问的步骤包括：提供基于超文本传输协议HTTP的JavaScript对象表示法JSON API，以实现一个或多个通道的创建和/或管理。

12.根据权利要求9至11中任一项所述的方法，其中，与所述通道相关联的所述一个或多个通知是来自矿工的回调通知，所述矿工是经由所述通道与所述给定客户端进行直接通信的所述另一实体。

13.根据权利要求12所述的方法，其中，所述回调通知与由所述给定客户端提交的交易的双重花费的通知相关。

14.根据权利要求13所述的方法，其中，所述回调通知与所述通道中的返回有效载荷相关联，所述返回有效载荷由所述矿工提供，所述返回有效载荷包括以下数据：

-作为双重花费的所述区块链交易的交易标识符(TxID)；以及可选地还包括：

-提交了所述区块链交易的所述支付处理器的服务端点。

15.根据权利要求12所述的方法，其中，所述回调通知与由所述给定客户端提交的交易被包括在所述区块链中的证明相关。

16.根据权利要求15所述的方法，其中，所述回调通知与所述通道中的返回默克尔证明相关联，所述返回默克尔证明由所述矿工提供，所述返回默克尔证明包括以下数据：

-与所述默克尔证明相关的区块链交易的交易标识符(TxID)；

-其中包括所述区块链交易的区块的区块标头；以及

-所述交易标识符(TxID)的同级散列数组。

17.根据权利要求9至16中任一项所述的方法，当所述客户端离线或未通信地连接到所述通道处理器时，所述一个或多个回调通知是在所述通道中存储或排队以用于所述给定客户端的数据的推送通知。

18.根据权利要求9至17中任一项所述的方法，当所述客户端在线或通信地连接到所述通道处理器时，从所述通道提供或提取与所述一个或多个回调通知相关联的数据。

19.根据权利要求9至18中任一项所述的方法，其中，所述通道处理器是支付处理器或包括支付处理器，并且其中，所述方法包括根据权利要求1至8中任一项所述的由所述支付处理器实施的方法。

20.一种计算机实施的方法，用于处理与区块链相关联的交易，所述方法由与客户端相关联的一个或多个处理器实施并且包括以下步骤：

发送与通道服务有关的通道请求，所述通道服务由通道处理器实现，所述请求与创建通道以用于与另一实体进行通信相关；

从所述通道服务获取对一个或多个功能的访问，所述一个或多个功能能够实现所述给定客户端与所述另一实体之间的直接通信，所述一个或多个功能包括：

与用于数据传输的通道有关的通道功能或程序；和/或

与使用通道进行传输的数据有关的消息功能或程序；

从所述通道服务获取一个或多个访问令牌，所述访问令牌能够实现与所述另一实体的安全通信；

向实现支付服务的支付处理器发送请求，所述请求是向所述区块链提交与数字资产相关联的交易的请求；

从所述支付处理器获取与所提交的交易相对应的区块链交易的交易标识符(TxID)；

基于来自所述支付处理器的响应，识别与所述对应区块链交易相关联的矿工；

使用从所述通道处理器接收到的一个或多个通道功能，创建给定通道以用于与所识别的矿工进行通信；

将与所述给定通道相关联的所述一个或多个访问令牌发送给所述矿工；

接收与所述给定通道相关联的至少一个回调通知，所述通知与所述给定通道中与所述区块链交易相关联的数据有关，所述数据由所述矿工提供。

21.根据权利要求20所述的方法，其中，当所述客户端离线或未通信地连接到所述通道处理器时，作为在所述给定通道中排队的数据或消息的推送通知而获取所述回调通知。

22.根据权利要求20或21所述的方法，其中，当所述客户端在线或通信地连接到所述通道处理器时，从所述给定通道中提取与所述回调通知相关联的数据。

23.根据权利要求20至22中任一项所述的方法，其中，所述一个或多个功能是用于所述给定客户端的应用程序编程接口API，所述API包括：通道API，用于实现一个或多个通道的创建和/或管理；以及消息API，用于使所述给定客户端和一个或多个其他实体能够交换消息，和/或从所述给定通道读取数据和/或将数据写入所述给定通道；并且其中，所述访问令牌是特定于给定通道或给定消息的API令牌。

24.根据权利要求20至23中任一项所述的方法，其中，所述通道请求是去往所述通道处理器的超文本传输协议安全HTTPS传输GET请求，并且其中，去往所述支付处理器的请求是去往所述支付处理器的超文本传输协议安全HTTPS传输POST请求。

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

提供客户端端点；

提供与所述客户端相关联的至少一个客户端寻址密钥；

获取矿工端点；

获取与所述矿工相关联的至少一个矿工寻址密钥；

基于所述客户端寻址密钥和所述矿工寻址密钥，使用所述给定通道交换一个或多个握手消息；

基于握手结果或握手模式，获取共享密钥；

其中，使用所述给定通道的任何通信都基于所述共享密钥进行加密。

26.根据权利要求25所述的方法，其中，所述客户端端点是超文本传输协议HTTP应用程序编程接口API端点，并且其中，所述客户端端点使用超文本传输协议安全HTTPS来实现。

27.根据权利要求25所述的方法，其中，所述客户端端点是通用资源位置URL，所述通用资源位置URL被包括在使用所述给定通道从所述给定客户端发送的消息中。

28.根据权利要求25至27中任一项所述的方法，其中，所述客户端端点是与所述客户端相关联的别名，所述别名特定于所述客户端并且由基于别名的寻址服务提供，所述寻址服务具有能够从限定位置或已知位置进行访问的机器可读资源，所述机器可读资源包括与所述客户端有关的一个或多个功能，并且其中，所述别名与用于验证的非对称加密密钥对相关联。

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

从所述支付处理器接收向区块链提交交易的请求；

生成与所述请求相对应的区块链交易；

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

接收对通道的访问，所述通道能够实现与所述给定客户端的直接通信；

基于与所述通道相关联的访问令牌，获取消息功能或消息API以用于在所述通道中提供或写入与回调通知相关联的数据，所述数据与所述对应区块链交易有关。

30.根据权利要求29所述的方法，其中，基于确定了所述对应区块链交易是由所述客户端提交的先前交易的双重花费，所述方法还包括：提供返回有效载荷的步骤，所述返回有效载荷包括以下数据：

-作为双重花费的给定区块链交易的交易标识符(TxID)；以及可选地还包括

-提交了所述给定区块链交易的支付处理器的服务端点。

31.根据权利要求29所述的方法，其中，响应于在区块中挖掘所述对应区块链交易，所述方法还包括：提供返回默克尔证明的步骤，所述返回默克尔证明确认所述交易被包括在区块中，所述返回默克尔证明包括以下数据：

-与所述默克尔证明相关的区块链交易的交易标识符(TxID)；

-所述区块的区块标头；以及

-所述交易标识符的同级散列数组。

32.根据权利要求29至31中任一项所述的方法，还包括以下步骤：

获取客户端端点；

获取与所述客户端相关联的至少一个客户端寻址密钥；

提供矿工端点；

提供与支付处理器相关联的至少一个矿工寻址密钥；

基于所述客户端寻址密钥和所述矿工寻址密钥，使用所述通道交换一个或多个握手消息；

基于握手结果或握手模式，获取共享密钥；

其中，使用所述通道的任何通信都基于所述共享密钥进行加密。

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

34.一种计算设备，包括处理器和存储器，所述存储器包括可执行指令，所述可执行指令由于被所述处理器执行，使所述设备执行根据权利要求9至19中任一项所述的计算机实施的方法，所述计算设备与通道处理器有关。

35.一种计算设备，包括处理器和存储器，所述存储器包括可执行指令，所述可执行指令由于被所述处理器执行，使所述设备执行根据权利要求20至28中任一项所述的计算机实施的方法，所述计算设备与客户端有关。

36.一种计算设备，包括处理器和存储器，所述存储器包括可执行指令，所述可执行指令由于被所述处理器执行，使所述设备执行根据权利要求29至32中任一项所述的计算机实施的方法，所述计算设备与矿工有关。

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

支付处理器，经由无线通信网络通信地联接到至少一个客户端和至少一个矿工，其中，所述支付处理器是根据权利要求33所述的计算设备来实施的；

客户端，经由所述无线通信网络通信地联接到所述支付处理器，并且能够与至少一个顾客进行通信；所述客户端是根据权利要求35所述的计算设备来实施的；所述客户端经由所述无线通信网络通信地联接到通道处理器，其中，所述通道处理器是根据权利要求34所述的计算设备来实施的；以及

多个矿工，经由所述无线通信网络通信地联接到所述支付处理器，每个矿工是根据权利要求38所述的计算设备来实施的。

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

Images