CN113939839A - 计算机实现的系统和方法 - Google Patents

计算机实现的系统和方法 Download PDF

Info

Publication number
CN113939839A
CN113939839A CN202080037815.0A CN202080037815A CN113939839A CN 113939839 A CN113939839 A CN 113939839A CN 202080037815 A CN202080037815 A CN 202080037815A CN 113939839 A CN113939839 A CN 113939839A
Authority
CN
China
Prior art keywords
channel
client
request
service
given
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
CN202080037815.0A
Other languages
English (en)
Inventor
安德鲁·詹姆斯·梅尔
史蒂文·帕特里克·考格兰
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Nchain Holdings Ltd
Original Assignee
Nchain Holdings Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Priority claimed from GBGB1907180.2A external-priority patent/GB201907180D0/en
Priority claimed from GBGB2002285.1A external-priority patent/GB202002285D0/en
Application filed by Nchain Holdings Ltd filed Critical Nchain Holdings Ltd
Publication of CN113939839A publication Critical patent/CN113939839A/zh
Pending legal-status Critical Current

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/386—Payment protocols; Details thereof using messaging services or messaging apps
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/083—Network architectures or network communication protocols for network security for authentication of entities using passwords
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/36—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/36—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes
    • G06Q20/363—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes with the personal data of a user
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/36—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes
    • G06Q20/367—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes involving electronic purses or money safes
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/389—Keeping log of transactions for guaranteeing non-repudiation of a transaction
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0807—Network architectures or network communication protocols for network security for authentication of entities using tickets, e.g. Kerberos
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0816—Key establishment, i.e. cryptographic processes or cryptographic protocols whereby a shared secret becomes available to two or more parties, for subsequent use
    • H04L9/0838—Key agreement, i.e. key establishment technique in which a shared key is derived by parties as a function of information contributed by, or associated with, each of these
    • H04L9/0841—Key agreement, i.e. key establishment technique in which a shared key is derived by parties as a function of information contributed by, or associated with, each of these involving Diffie-Hellman or related key agreement protocols
    • H04L9/0844—Key agreement, i.e. key establishment technique in which a shared key is derived by parties as a function of information contributed by, or associated with, each of these involving Diffie-Hellman or related key agreement protocols with user authentication or key authentication, e.g. ElGamal, MTI, MQV-Menezes-Qu-Vanstone protocol or Diffie-Hellman protocols using implicitly-certified keys
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3236—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using cryptographic hash functions
    • H04L9/3239—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using cryptographic hash functions involving non-keyed hash functions, e.g. modification detection codes [MDCs], MD5, SHA or RIPEMD
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/50—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols using hash chains, e.g. blockchains or hash trees
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q2220/00—Business processing using cryptography
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2209/00—Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
    • H04L2209/56—Financial cryptography, e.g. electronic payment or e-cash

Abstract

在第一方面，本公开提出了用于实现与区块链相关联的消息或交易的通道服务的计算机实现的方法、设备和系统，所述通道服务被提供给一个或更多个客户端。所述方法包括：向给定客户端提供对一项或更多项功能的访问权限，所述一项或更多项功能使得能够在所述给定客户端与另一实体之间进行直接通信，所述一项或更多项功能包括(i)与用于数据传输的一个或更多个通道有关的通道功能或过程；和/或(ii)与使用所述一个或更多个通道传输的所述数据有关的消息功能或过程。在第二方面，本公开提出了用于实现通道服务(诸如所述第一方面中的所述通道服务)寻址的计算机实现的方法、设备和系统。基于与通信实体有关的所述寻址密钥发起使用与所述通道服务相关联的通道的通信。

Description

计算机实现的系统和方法
技术领域
本公开总体涉及用于使用一个或更多个用于在实体之间进行通信的通道来实现通道服务的方法和系统。具体地，本公开涉及但不限于经由或使用用于实体的通道提供对一个或更多个功能或应用的访问权限，所述一个或更多个功能或应用能够实现或促进或允许在该实体之间就交易或消息进行点对点通信或直接通信。
背景技术
在本文中，使用术语“区块链”来涵盖所有形式的电子的基于计算机的分布式分类账。这些分类账包括基于共识的区块链和交易链技术、许可和非许可的分类账、共享分类账、公共和私有区块链，及其变型。虽然已提出并开发了其他区块链实现方式，但是区块链技术最广为人知的应用是比特币分类账。为了方便和说明的目的，在本文中可能会提及比特币，但应注意，本公开不限于与落入本公开范围内的比特币区块链以及与任何类型的数字资产或数字资产的表示相关联的替代区块链实现方式和协议一起使用。在本文中，术语“客户端”、“实体”、“节点”、“用户”、“发送者”、“接收者”、“付款人”和“收款人”可以指基于计算或处理器的资源。在本文中，术语“比特币”用于包括源自或基于比特币协议的任何版本或变型。术语“数字资产”可以指任何可转让的资产，诸如加密货币、表示至少一部分财产的令牌、智能合同、许可证(即软件许可证)或用于媒体内容的DRM合约等。应当理解的是，贯穿本文使用的术语“数字资产”表示可能与价值相关联的商品，该价值可以作为交易中的支付款项从一个实体转移到另一实体或提供给另一实体。
区块链是一种点对点的电子分类账，其实现为基于计算机的去中心化分布式系统，所述系统由区块组成，而区块又由交易组成。每笔交易是一种数据结构，所述数据结构对所述区块链系统中参与者之间的数字资产控制权的转移进行编码，并且包括至少一个输入和至少一个输出。每个区块都包含前一个区块的哈希值，因此区块被链接在一起，以创建自所述区块链创建以来写入其中的所有交易的永久性且不可更改的记录。交易包含嵌入到其输入和输出中的小程序，称为脚本，这些脚本指定如何以及能够由谁访问所述交易的输出。在比特币平台上，这些脚本是使用基于堆栈的脚本语言编写的。
为了将交易写入所述区块链，必须对其进行“核实”。网络节点(矿工)进行工作以确保每笔交易均有效，而无效交易则被网络拒绝。安装在所述节点上的软件客户端通过执行其锁定和解锁脚本来对仍有效的交易(UTXO)执行此核实工作。如果所述锁定和解锁脚本的执行评估为TRUE，则所述交易有效，然后将所述交易写入所述区块链。因此，为了将交易写入所述区块链，必须：i)由接收所述交易的第一节点进行核实，如果所述交易通过核实，则所述节点将其中继到网络中的其他节点；ii)添加到由矿工建造的新区块中；以及iii)进行挖掘，即添加到过去交易的公共分类账中。
应当理解，矿工执行的工作的性质将取决于用于维护区块链的共识机制的类型。虽然工作量证明(PoW)与原始比特币协议相关联，但应当理解，可以使用其他共识机制，诸如股权证明(PoS)、委托股权证明(DPoS)、容量证明(PoC)、过去时间证明(PoET)、授权证明(PoA)等。不同的共识机制在节点之间如何分布挖掘上有所不同，成功挖掘区块的几率取决于例如矿工的哈希能力(PoW)、矿工持有的加密货币的数量(PoS)、押在委托矿工上的加密货币的数量(DPoS)、矿工存储加密难题的预定解决方案的能力(PoC)，随机分配给矿工的等待时间(PoET)等。通常，矿工会因挖掘区块而获得激励或奖励。例如，比特币区块链用新发行的加密货币(比特币)和与区块中的交易相关联的费用(交易费用)奖励矿工。对于比特币区块链，加密货币的发行量会随时间的推移而减少，其激励最终仅由交易费用组成。因此，可以理解，交易费用的处理是将数据提交到公共区块链(诸如比特币区块链)的底层机制的一部分。
如先前所提及的，给定区块中的每笔交易对区块链系统中的参与者之间的数字资产控制权转移进行编码。数字资产不一定对应于加密货币。例如，数字资产可能与文档、图像、实体对象等的数字表示有关。向矿工支付加密货币和/或交易费用可能只是作为一种激励，以通过执行必要的工作来维持区块链的有效性。与区块链相关联的加密货币可能用作矿工的安全保障，而区块链本身是主要与加密货币以外的数字资产相关的交易分类账。在某些情况下，参与者之间的加密货币转账可能由如下实体来处理，该实体不同于和/或独立于使用区块链来维护交易分类账的实体。
一旦作为UTXO存储在区块链中，用户就能够将相关联资源的控制权转移到与另一交易中的输入相关联的另一地址。这种转移通常但并非本质上使用数字钱包来完成。该数字钱包可以是：设备；物理介质；程序；诸如台式机、笔记本电脑或移动终端等计算设备上的应用(app)；或与诸如互联网等网络上的域相关联的远程托管服务。数字钱包存储公钥和私钥，并可用于：跟踪与用户相关联的资源、令牌和资产等的所有权；接收或花费数字资产；转移可能与诸如加密货币、许可证、财产或其他类型的资源等数字资产相关的令牌。
虽然区块链技术最广为人知的是用于实现加密货币，但数字企业家正在探索如何利用比特币所基于的加密安全系统和能够存储在区块链上的数据来实现新的系统。如果区块链能够用于加密货币领域之外的自动化任务和流程，则会非常有利。这种解决方案将能够发挥区块链的优势(例如，永久性防篡改事件记录、分布式处理等)，同时其应用将更加广泛。
当前研究的一个领域是使用区块链实现“智能合约”。这些是设计成自动执行机器可读合约或协议的计算机程序。与以自然语言编写的传统合约不同，智能合约是机器可执行程序，它包括能够处理输入以产生结果的规则，继而使得根据这些结果来执行动作。与区块链相关的另一关注领域是使用“代币”(或“彩色币”)来表示现实世界的实体，并通过区块链转移现实世界的实体。潜在的敏感或保密项目能够由无可辨别意义或价值的代币表示。因此，代币充当允许从区块链引用现实世界项目的标识符。
利用区块链的优点提供永久性防篡改事件记录时，上述示例、应用和/或场景需要客户端、客户端实体、计算设备或与客户端相关联的终端，以包括或实现软件和/或硬件或处理器/模块，诸如一种数字钱包，这种数字钱包用于实现用于管理数字资产、管理例如由BSV(比特币中本聪愿景)区块链使用的椭圆曲线数字签名算法(ECDSA)的加密密钥的功能。此外，客户端设备还需要能够实现区块链交易构建和下载BSV库，以便能够将资产或资产的控制权转移给另一实体或对等方。因此，客户端不仅需要包括实现此类功能的处理，还需要确保为此类流程实施适当的安全措施。
存在简单支付验证(SPV)机制，其中应用需要来自区块链的信息，但没有指向所述区块链的直接链路，因为它们不运行完整的矿工节点。此类SPV应用允许轻量级客户端验证交易是否确实包括在区块链中，而无需下载整个区块链。尽管这是有利的，但这仍然要求客户端运行区块链的和与客户端有关的交易相关联的部分，因为对等方中的发送者或接收者需要最终将交易提交给区块链，并标识所述交易是否已被挖掘。
因此，期望实现安全、低复杂度、用户友好、高效和稳健的技术，这些技术将允许无论在计算上是否复杂的任何客户端能够以简单、有序、快速、准确、可靠和安全的方式直接(以点对点方式)即时访问另一方并与另一方交互，该另一方即与所述客户端相关联的交易的对方或发送者/接收者，该方式在计算上和功能上减轻了客户端的负担。更具体地，期望利用分布式分类账(区块链)技术，以及以使任何客户端计算设备能够确保与该客户端相关联的任何数据、事件或数字资产能够被即时且安全地挖掘或容易地写入区块链的方式来提高记录的安全性、透明度和可靠性的优点，从而提供其持久性防篡改和可审计记录，其可以根据需要创建、写入、更新、读取或查看；而无需下载或运行区块链的任何部分。
现在已设计出这种改进的解决方案。本公开通过提出一种或更多种技术来解决上述技术问题，该技术通过为通道或消息传递服务提供接口或功能的方法、设备和系统来实现客户端的直接通信或点对点通信，而无需此类客户端实现区块链的任何处理或功能，同时仍然能够利用与其相关联的所有优点。与客户端相关联的数据或信息可以简单、安全且即时地写入区块链或从区块链获取，同时解除客户端与区块链的关联。
发明内容
在第一方面，本公开提出了用于实现实体之间的消息或交易的通道服务的计算机实现的方法、设备和系统，所述通道服务被提供给一个或更多个客户端。所述方法包括：向给定客户端提供对一项或更多项功能的访问权限，所述一项或更多项功能能够实现在所述给定客户端与另一实体之间进行直接通信，所述一项或更多项功能包括(i)与用于数据传输的一个或更多个通道有关的通道功能或过程；和/或(ii)与使用所述一个或更多个通道传输的所述数据有关的消息功能或过程。
在第二方面，本公开提出了用于实现通道服务寻址的计算机实现的方法、设备和系统，所述通道服务被提供用于实体之间的消息或交易，所述通道服务被提供给一个或更多个客户端。所述方法包括提供来自一个实体的至少一个服务/客户端/矿工端点以及相关联的寻址密钥。获取与另一实体相关联的用于通信的寻址密钥。提供对一项或更多项功能的访问权限，所述一项或更多项功能能够使用用于数据或消息传输的通道在实体之间进行直接通信，其中基于所述寻址密钥发起使用所述通道的通信。
贯穿本说明书使用的词语“包含”或变体诸如“包括”或“含有”将被理解为意味着包含阐明的元素、整体、步骤或元素、整体或步骤组，但不排除任何其他元素、整体、步骤或元素、整体或步骤组。
附图说明
现将仅通过举例的方式并参考附图对本公开的各方面和实施例进行说明，其中：
图1是描绘根据第一方面的一种用于向一个或更多个客户端提供通道服务的方法的流程图，所述方法由与所述通道服务相关联的一个或更多个通道处理器实现；
图1a是示出根据所述第一方面的与为多个客户端提供的区块链相关联的通道服务的示例性概述的示意图；
图2是描绘根据所述第一方面的一种用于实现给定客户端的通道服务的方法的流程图，所述方法由通道处理器实现；
图3是描绘根据所述第一方面的一种用于访问通道服务的方法的流程图，所述方法由与客户端相关联的一个或更多个处理器实现；
图4是描绘根据所述第一方面的一种用于使用通道服务来处理区块链交易的方法的流程图，所述方法由与矿工相关联的一个或更多个处理器实现；
图5是描绘根据第二方面的一种用于实现通道服务寻址的方法的流程图，所述方法由通道处理器实现；
图6是描绘根据所述第二方面的一种用于使用通道服务实现通道寻址的方法的流程图，所述方法由与客户端相关联的一个或更多个处理器实现；
图7是描绘根据所述第二方面的一种用于使用通道服务来处理区块链交易的方法的流程图，所述方法由与矿工相关联的一个或更多个处理器实现；
图8是示出根据所述第二方面的经由通道为通信提供寻址和端到端加密的示例的示意性流程图；
图9是示出与区块链相关联的点对点异步通信相关的上述方面的示例性用例的示意性流程图；
图10是示出与区块链交易的多重签名(多个或阈值数目签名)授权相关的上述方面的示例性用例的示意性流程图；
图11是示出能够实现本公开的各个方面和实施例的计算环境的示意图。
具体实施方式
随着分布式分类账(区块链)技术在许多需要对与这项技术相关的事件或交易进行安全、可靠、可审计、防篡改和可靠地记录的应用中的使用规模扩大，参与实体的解决方案传统上依赖于实时同步区块链的完整副本，从而直接从所述区块链中标识与其应用有关的交易和嵌入数据。然而，随着应用范围、功能和安全性的不断发展，以及所述区块链规模的不断扩大，显然需要一种允许各方直接通信的技术方案，并且需要此类应用以直接交换消息，以便扩展并充分实现和利用与所述区块链相关联的全部潜在优点，并使此类解决方案可用于无论在计算上是否复杂的任何类型的客户端。
根据第一方面，本公开提供了一种用于针对实体之间的消息或交易实现通道服务或功能的计算机实现的方法，所述通道服务被提供给一个或更多个客户端。在所述第一方面的第一实现方式中，所述方法由通道处理器实现。在一些实施例中，所述通道服务是指下文将描述的一个或更多个功能或过程或应用程序编程接口(API)。在一些实施例中，所述通道处理器可以是一个或更多个计算设备或服务器，或者可以在单个、远程或分布式计算节点或实体上运行的基于云的软件解决方案，所述单个、远程或分布式计算节点或实体可以由一个或更多个客户端通过有线或无线通信网络访问。在一些实施例中，所述客户端可以是实体、用户终端/设备或具有一个或更多个处理器的计算设备或系统。在一些实施例中，所述客户端可以与数字钱包相关联，所述数字钱包允许所述客户端管理诸如加密货币和令牌等的一笔或更多笔数字资产。在一些实施例中，所述通道服务可以经由数字钱包被提供给所述一个或更多个客户端中的给定客户端。然而，应当理解的是，不具有数字钱包或用于数字资产的单独应用的客户端实体也在本公开的范围内。在一些实施例中，特别是对于在计算上复杂的客户端，实现所述通道服务的所述通道处理器能够与所述客户端实体集成或作为所述客户端实体的一部分。在这种情况下，所述通道处理器可以实现为客户终端内的模块，所述模块能够为所述客户端实现通道服务功能。在一些实施例中，其他客户端或实体也可以由所述通道处理器提供服务。
根据所述第一方面的所述方法包括从所述一个或更多个客户端中的给定客户端接收请求，所述请求与所述通道服务有关。在一些实施例中，该请求能够通过诸如互联网的网络发送。因此，在一些实施例中，所述客户端能够经由已知互联网通信协议与所述通道服务通信。在一些实施例中，该请求涉及向通道服务提供商或处理器注册给定客户端的请求。然后，所述方法包括：为所述给定客户端创建账户，所述账户具有特定于所述给定客户端的账户标识符和特定于所述账户标识符的访问密钥。该标识的账户可以由所述通道服务提供，也可以由所述客户端提供。这些共同构成了给定客户端账户的凭证，类似于客户端ID和PIN或密码对。在其他实施例中，这些凭证也可以基于非对称加密密钥对，所述非对称加密密钥对包括与所述给定客户端相关联的私钥和公钥。
一旦注册，所述方法包括：向给定客户端提供对一项或更多项功能的访问权限，所述一项或更多项功能能够实现在所述给定客户端与另一实体之间进行直接通信，其中所述一项或更多项功能包括：与用于传输数据的一个或更多个通道有关的通道功能或过程；和/或与使用所述一个或更多个通道传输的所述数据有关的消息功能或过程。在一些实施例中，所述一个或更多个通道能够实现实体之间用于所述消息或数据传输的直接或点对点通信路径或会话。在大多数实施例中，每个通道只有两个实体。然而，也可能存在一些有限的情况，其中也可以向第三实体提供对相同通道的访问权限。
在该第一实现方式中，由于所述一个或更多个功能以接口或接入点的形式提供给所述客户端，因此所述通道的一个实体将是所述客户端，另一实体是所述客户端希望直接与之通信的另一设备或实体或用户终端。在大多数实施例中，所述通道能够实现全双工，即所述客户端与所述其他实体之间的双向通信。在一些实施例中，可以仅允许单向通信，即所述客户端可能只想向所述其他实体发送消息或从所述其他实体接收消息。
有利地，在第一方面，对于点对点交易，不需要由所述客户端实现BSV、比特币、区块链知识、ECDSA或特定于区块链的其他加密密钥管理库或交易构建软件等。使用一个或更多个处理资源或用户终端的客户端通过公知的认证技术简单地注册以使用所述通道服务，所述认证技术诸如密码保护授权或标准公钥基础设施(PKI)，该技术用于验证用于账户注册的客户端标识。一旦从所述通道服务接收所述一个或更多个功能，所述客户端将能够简单地使用标准通信/传送协议(即诸如超文本传输协议(HTTP)/传输控制协议(TCP)等的类似互联网协议)与所述其他实体进行通信。对于与企业相关联或可能代表组织的客户实体(诸如，商家)，此类客户端可能有大量其他实体(客户)与他们就许多商品进行交易。因此，对于此类场景，使用通道与一个或更多个客户进行通信，同时与实现与维护所有此类交易记录的区块链相关的任何功能取消关联或分离，将是非常有益的。通过提供通道功能以及消息功能，此类客户端能够为与特定交易(诸如特定发票或特定商品查询等)相关的特定客户使用特定通道。
在一些实施例中，给定通道与特定通道标识符相关联。同一客户端可以有多个单独的通道，每个通道都有自己的唯一标识符。在一些实施例中，所述给定通道用于与和特定类型或主题相关联的数据相关的另一实体进行通信，其中与通道中的每个主题相关联的数据是或包括在一个或更多个消息或交易中。有利地，具有针对特定主题的特定通道确保了所述客户端具有更大的清晰度、可靠性和灵活性，特别是在像商家实体这样的客户端的情况下，其可能具有需要单独跟踪或处理的多个主题(例如，交易编号或发票)。
同样有利地，使用通道允许对给定通道中的每个请求或消息进行异步处理。这允许对通道中的消息进行无缝且准确的不连续或延迟处理流，由于所述通道特定于给定主题，因此顺序和消息始终清晰。这能够特别适用于如下实现方式或情况，其中需要来自所述其他实体(或所述客户端)的响应以进一步进行交易，但所述客户端或其他实体可能不可操作或在线或者无法立即提供此类响应。因此，即使在所述通道的一方离线或无响应时，上述技术仍然能够使用所述通道可靠地递送并准确且有序地处理请求，因为消息在下次在线或连接到网络时仍将存在于所述通道中，以便他们能够访问所述通道中的消息。此外，无论所述通道中可能提供了多少其他消息，所述其他实体都可以按传递顺序访问此类消息。因此，尽管在处理所述请求时存在延迟或中断，仍能准确且无缝地完成所述通道中消息的处理，就好像不存在延迟一样。在一些实施例中，可以存在与特定通道相关联的一个或更多个规则，该特定通道与对于一方离线或在线时的特定主题相关联，例如：(i)按照到达顺序响应消息，从而确保传输中不存在间隙；或者(ii)除非也响应所有消息，否则无法完成通道等，以保持数据完整性。
在一些实施例中，所述客户端是所述一个或更多个通道的所有者，这些通道是基于由所述通道服务提供的所述一个或更多个功能的通道。在一些实施例中，所述一个或更多个功能是为所述给定客户端发布或提供给所述给定客户端的应用程序编程接口(API)，所述API包括用于所述一个或更多个通道的通道API；以及用于数据的消息API，即与和每个通道或给定通道相关联的主题相关的消息。API可以理解为端点、接口或一组功能和过程，其允许创建或管理用于访问应用或其他服务的特征或数据的实体(诸如，在这种情况下为客户端)的应用。在这种情况下，既要实现通道功能，也要实现消息功能。
在一些实施例中，所述方法进一步包括为客户端的所述一个或更多个通道中的给定通道发布一个或更多个访问令牌的步骤，所述令牌被配置用于与另一实体进行安全通信。所述一个或更多个访问令牌与所述给定通道有关，或者甚至用于所述给定通道中的一个或更多个消息。在一些实施例中，访问令牌是特定于给定通道或给定消息的API令牌。在一些实施例中，访问令牌特别是API令牌可以充当请求访问服务或通道的实体或应用的唯一标识符。在一些实施例中，访问令牌可以被认为是分配给各个客户端账户的唯一认证凭证，甚至能够与各个通道或每个通道中的各个消息一样精细。在一些实施例中，访问令牌可以使得所述客户端能够将这些令牌提供给所述其他实体以用于其认证的每个通道。在本公开实施例中，访问令牌可以由所述客户端或所述通道服务为一个或更多个其他实体生成或提供，每个其他实体均具有不同的通道。
在一些实施例中，所述通道处理器与HTTP API端点相关联，并且其中基于诸如HTTP、安全HTTP(HTTPS)等HTTP传输协议格式来接收来自所述给定客户端的请求。在所述第一方面的一些实施例中，从所述客户端接收的所述请求是HTTP GET、HTTP POST、HTTP PUT或HTTP PATCH请求，其包括特定于给定客户端的客户端标识符以及如果存在的话用于所述客户端的特定通道的通道标识符或与其相关联。
有利地，所述通道处理器API允许基于网络的交互界面，即在一些实施例中，其可以实现为一个或更多个客户端的网络服务，使得可以使用基于网络的服务的标准互联网通信协议在互联网上进行通信。例如，在一些实施例中，可以基于任何标准的基于互联网的传输层协议来传输和接收对等方之间的应用层中的HTTP消息或请求，或者客户端与所述通信服务之间的层中的HTTP消息或请求。在本文中，对HTTP传输协议或HTTP API的引用也封装诸如TCP/IP、UDP、HTTPS等的所有标准互联网通信协议。在一些实施例中，所述通道处理器实现为代表性状态转移(REST)端点。
在实施例中，可以存在多于一个的通道处理器用于为一个或更多个客户端提供通道服务，即可以存在与相同通道服务相关联的分布式通道处理器或网路服务器，所述第一方面的所述方法进一步包括：提供应用程序编程接口(API)转换器的步骤，用于执行以下步骤：以HTTP传输协议格式从所述客户端接收请求；将接收到的请求转换为远程过程调用(RPC)格式；将所述RPC请求发送给所述多个处理器中被配置用于实现所述接收到的请求的给定处理器。在反向流程中，该实施例包括以RPC格式接收来自给定通道处理器的相关联的响应，并使用HTTP或类似传输协议来转换要发送到所述客户端的相应响应。
这是有利的，因为它允许所述客户端使用基于网络的平台API经由简单的基于HTTP的协议来传递与所述区块链相关联的请求，并且无缝地提供与实现上述服务的任何节点或服务器的互操作性，但是这些节点或服务器不使用针对网络服务的互联网协议通信标准来进行通信。该实施例中实现的API转换器不限于HTTPS到RPC的转换，反之亦然。在反向流程中，所述第一方面的所述方法进一步包括：以RPC格式接收来自相应处理器的响应，并且相应地使用HTTP转换所述相应响应以发送到所述客户端。因此，有利地，由所述通道处理器实现所提出的接口使得所述客户端和所述通道处理器能够使用不同的无线数据通信协议和机制进行无缝通信。
在一些实施例中，为客户端分配或提供的账户标识符是为给定客户端提供的别名。有利地，为了使客户端标识以及寻址更简单，已经存在一些机制，其中使用可记忆且更用户友好的别名而不是一个或更多个客户端实体的复杂公共地址。此类解决方案以nChainHoldings Limited的名义在美国专利申请案第16/384696号中提出。这些文档阐述了基于别名的支付服务和相关协议，其称为bsvalias支付服务，其中别名用于目标寻址，而不是客户端实体的公共地址。此类系统中的别名通常与发送/接收客户端实体的域名相关联，并且可以是URI或电子邮件地址。因此，只要发送者或实体知道别名或被提供有别名，这对于bsvalias支付系统或其他基于别名的寻址机制就足够了。例如，可以使用保存在用于bsvalias或其他支付服务的公知URI或位置中的机器可读资源(诸如，JavaScript对象表示法(JSON)文档)中提供的指令，将消息发送到客户端的别名。在本公开的一些实施例中，所述多个客户端中的一个或更多个客户端可以具有诸如上述的别名，以标识用于点对点交易的相应其他实体，无论他们是否与指向区块链的链路相关联。
在所述第一方面的一些实施例中，一旦客户端已经向所述通道服务注册并且已经被提供有账户凭证以及与所述通道服务相关联的一个或更多个功能或API，所述通道处理器就可以提供特定于通道的一个或更多个功能或API。在这种情况下，所述方法包括：接收来自所述给定客户端的请求，所述请求与所述客户端账户的通道相关联。所述请求可以包括例如与以下一个或更多个相关联的访问权限或功能：
-列出与所述给定客户端的所述账户有关的所述一个或更多个通道的请求；
-为所述账户创建通道的请求；
-删除已标识的通道的请求；
-修改与已标识的通道相关联的属性和/或权限的请求；
-为已标识的通道生成通道访问令牌的请求；
-撤销已标识的通道的通道访问令牌的请求。
在上述实施例中，所述第一方面的所述方法包括基于所述客户端账户标识符来核实客户端，所述客户端账户标识符可以基于与在账户注册期间保存或分配的客户端账户标识符和访问密钥对应的记录。此类记录可以与所述通道处理器相关联。然后，基于所述客户端的成功核实，所述方法附加地或可选地包括基于所述通道标识符确定从所述客户端接收到的所述请求是否有效的步骤。例如，这是基于为所述客户端提供的通道API或者基于包括在相应记录中的一个或更多个设置或权限来检查该通道是否处于活跃状态。在一些实施例中，属性或设置可以指示是否允许给定客户端访问所述通道的全部或部分请求的服务。例如，可以在属性或设置中提供与所述客户端标识符相关联的一个或更多个级别的权限。例如，可以允许给定客户端请求创建通道以及在通道上发送/接收消息的服务，但不允许修改、删除或终止通道中的消息；而另一客户端可以具有与通道的一项或更多项服务有关的所有上述操作的权限。在另一示例中，可以拒绝为诸如现有发票编号的已经存在的主题创建另一通道的请求，这有利地能够防止由冒名顶替者或恶意方创建欺诈性消息或通道。
在一些实施例中，还可以进一步检查通道中的数据或消息的完整性，诸如基于可以被进一步存储到在通道中发送或接收的每个消息或设定数量的消息的校验和或哈希值。这确保了恶意方不会获得访问权限和篡改消息或通道中的数据。
在一些实施例中，验证给定客户端的身份的步骤可以基于与所述客户端相关联的数字签名。包括与每个客户端相关联的私钥和公钥(或公共地址)的加密密钥对可用于验证对服务的请求确实源自所述给定客户端，即其中由私钥签名的数据只能使用对应的公钥进行恢复或核实。如果验证基于数字签名，则可以使用和实现标准公钥基础设施(PKI)技术。
然后，基于确定与所述给定客户端有关的账户标识符和访问密钥有效；以及基于确定所述请求有效，所述方法包括处理对所述通道的所述请求；并且包括向所述给定客户端发送响应，所述响应包括对与所述请求相关的一个或更多个通道功能的访问权限。
类似于上述与客户端账户的通道相关的通道功能，当所述客户端接收到与给定通道中的一个或更多个消息相关联的请求时，也可以使用类似的过程向所述客户端提供一个或更多个消息功能或消息API。这些可以包括为与消息相关联的以下请求提供一个或更多个API：
-对所述给定通道中的新消息进行测试的请求；
-检索所述给定通道中的消息的请求；
-标记或标识所述给定通道中的已读或未读消息的请求；
-写入所述给定通道中的消息的请求。
在所述提供的响应中存在消息API的情况下，其被提供给所述客户端，以用于控制或管理通道中的特定消息或每个消息的传输、规则、权限。在一些实施例中，可以提供此类API，使得所述客户端能够与所述通道的对方共享此类API，该对方即所述其他实体。在一些实施例中，所述响应中提供的所述通道或消息功能包括用于所述账户的JavaScript对象表示法(JSON)-over-超文本传输协议(HTTP)API，使得所述客户端或所述其他实体能够访问、创建和/或管理一个或更多个消息。
有利地，提供对诸如特定于客户端的给定通道的API或令牌的功能的访问权限，或者对给定通道内的一个或更多个消息的访问权限，确保了在与另一实体进行直接通信或点对点通信时，由所述客户端控制和管理通道和消息。在一些实施例中，一旦为通道提供了API或功能，则可能不需要为另一消息请求所述控制，但可能需要为不同的通道请求所述控制。此外，这确保了可以对特定通道或消息的限制进行管制。例如，如果表中的多个支付提醒或消息或提醒被发送但被所述其他实体忽略，则可以拒绝与所述其他实体的其他通道相关联的请求或者删除所述消息或将其标记为未读的请求。
在一些实施例中，所述通道处理器可以为所述客户端提供通道服务库，所述通道服务库包括一个或更多个模块，该一个或更多个模块用于促进从所述通道处理器接收的用于与所述给定客户端相关联的所述账户的通道功能和/或消息功能。
在本公开的所述第一方面的第二实现方式中，提供了一种用于访问消息或交易的通道服务的计算机实现的方法，所述方法由所述一个或更多个客户端中的给定客户端的一个或更多个处理器来实现。所述第二实现方式类似于所述第一实现方式，并且具有类似的优点。应当注意的是，在一些实施例中，所述通道服务的客户端也可以是一个或更多个矿工节点，或者与所述区块链相关联或运行完整节点的实体。尽管本公开方法特别有利于希望与另一实体直接通信从而不具有与区块链相关联的任何链路的客户端，但这并不排除与其他完整或部分(SPV)钱包实现方式相关联的矿工节点或客户端也利用此类通道服务进行点对点通信。例如，对于此类矿工模式而言，一个重要且有用的应用能够是使用所述通道将挖掘证明或包含证明直接发送给另一方，所述另一方可以是通道处理器或与区块链交易相关联的另一实体。在该实施例中，当提交要由矿工挖掘的交易时(这可以由客户端或通道服务完成)，所述矿工能够基于从所述通道处理器或所述客户端接收到的通道功能，使用所述通道将包含证明提交回所述交易的提交者。有利地，这样，所述客户端和所述通道处理器(或任何提交方)都不需要检查以运行所述区块链的任何部分来验证交易提交，因为此类证明现在经由所述通道直接递送到所述提交者。这是有利的，因为它有助于要写入区块链的点对点应用的资源的可扩展性和优化，因为任何实体都不再需要检查所述区块链以访问其交易。
所述方法包括以下步骤：发送与所述通道服务有关的请求，所述通道服务由通道处理器实现；以及作为应答，获取为所述给定客户端创建的账户的账户凭证，所述账户凭证包括账户标识符和特定于所述账户标识符的访问密钥。然后，所述客户端实现的方法包括获取对于一项或更多项功能的访问权限，所述一项或更多项功能能够在所述给定客户端与另一实体之间进行直接通信。与所述第一实现方式一样，所述一项或更多项功能包括：与用于数据传输的一个或更多个通道有关的通道功能或过程；和/或与使用所述一个或更多个通道传输的数据有关的消息功能或过程。
在一些实施例中，如上所述，由所述客户端实现的所述方法还包括发送与所述给定客户端的账户的通道或消息有关的请求，使得特定API可以被递送到所述客户端。由所述客户端在所述通道处理器的响应中接收到的通道API用于有利地实现一个或更多个通道的创建和/或管理。在一些实施例中，所述接收到的响应包括访问令牌，诸如如上所述的每个通道功能的通道API令牌。在消息功能的情况下，由所述通道处理器为所述客户端账户发布的消息API有利地使得所述给定客户端和一个或更多个其他实体能够交换消息和/或从所述给定通道读取数据和/或向所述给定通道写入数据。在一些实施例中，所述接收到的响应包括访问令牌，诸如每个消息功能的消息API令牌。
在所述第一方面的一些实施例中，为了使所述客户端使用通道服务和一个或更多个通道以及从所述通道处理器获取的消息功能或API与对方或另一实体交互，所述方法包括标识要与其进行通信交换的另一实体的步骤。这可以通过使用所述其他实体已知或由另一实体提供的接入点或别名来实现。然后，使用从所述通道处理器接收到的一个或更多个通道功能，创建用于通信的通道，并将与所述通道相关联的一个或更多个访问令牌发送到所述其他实体。这有利地能够安全、可靠和准确地建立与所述其他实体的通道，所述其他实体可以是商家客户端的客户。然后，所述方法包括：使用从所述通道处理器接收到的所述通道的一个更或多个消息功能，将与交易有关的至少一个消息写入所述通道，并将与所述一个或更多个消息相关联的一个或更多个访问令牌发送到所述其他实体。这有利地确保了通过访问令牌对任何响应进行认证。所述方法包括：接收与所述通道中的所述交易有关的至少一个回复消息。
响应于所述通信交换的完成，一旦接收到数字资产的支付确认，即类似于所述其他实体的汇款票据或所述客户端接收到的资金确认，则可指示所述通信交换的完成，然后准备与所述通道相关联的此类已完成交易以提交给所述区块链。在一些实施例中，这被发送到所述通道处理器，然后所述通道处理器能够代表所述客户端提交所述交易。这样，有利地，所述点对点交易中的任何一方(客户端或其他实体)都不负责将所述已完成交易提交给所述区块链。这可以由所述通道处理器来完成，然后由与区块链相关联的一个或更多个矿工节点来挖掘。因此，所述客户端不需要运行与区块链关联的任何功能，甚至不需要运行SPV钱包或任何其他形式的数字钱包。在一些实施例中，如果所述客户端或实际上所述其他实体具有能够提交交易的功能，则所述提交可以由所述客户端或其他实体完成。
在第一方面的第三实现方式中，本公开提供了一种用于处理与区块链相关联的交易的计算机实现的方法，所述方法由与多名矿工中的一名矿工相关联的一个或更多个处理器实现，所述多名矿工被以通信方式耦合到实现用于至少一个客户端的通道服务的至少一个通道处理器。如上所述，矿工节点也可以访问所述通道服务，以促进与一个或更多个其他实体进行点对点通信。无论它们是否是所述通道服务的客户端，只要它们从需要与所述矿工直接通信的另一实体接收通道或消息API和/或与通道相关联的访问令牌，都可以是这种情况。这对于多个区块链相关应用尤其有利，因为所述矿工然后可以使用通道来将提交给所述区块链的交易的Merkle树包含证明直接发送给另一实体。这是有用的，因为这意味着不再需要客户端(诸如，商家)或另一实体(诸如，客户甚至通道服务)必须搜索区块链才能找到此类交易。这是因为，有利地，一旦挖掘，就能够使用所述通道将所述包含证明直接发送给所述通道处理器或者实际上所述客户端或其他实体，即提交所述区块链交易以供挖掘的任何实体。
当然，挖掘也能够使用所述通道服务进行，而给定交易的矿工不是向所述通道服务注册的客户端。在这种情况下，提交所述交易的所述通道处理器或所述客户端或其他实体可以基于所述通道和已经提供给所述通道的消息功能，简单地使用所述通道服务为所述矿工创建要接收的包含证明的通道。然后，所述矿工成为此类通道中的其他实体(然后客户端或通道API成为第一实体)，并且能够简单地经由所述通道接收所需的消息API和访问令牌。
本公开的第二方面涉及为用于点对点通信的通道提供安全寻址和加密。对于实体之间实现的一个或更多个点对点通道，能够分别实现与所述第二方面相关联的各方面和实施例。它还可以与上面讨论的实施例和实现方式结合使用，即用于所述第一方面的所述通道服务。所述第二方面的以下实施例是关于所述第一方面中提到的所述通道服务来讨论的，尽管其被理解为不限于此。
在所述第二方面的第一实现方式中，本公开提供了一种用于实现通道服务寻址的方法，向消息或交易提供所述通道服务，所述通道服务被提供给一个或更多个客户端。所述方法由通道处理器实现，并且包括以下步骤：从所述多个客户端中的给定客户端接收请求，所述请求与所述通道服务有关。然后，检查对与所述给定客户端有关的账户标识符和访问密钥的有效性的确定。该检查可以基于存储的凭证或者实际上基于PKI技术来执行，如上文在与所述第一方面相关的讨论中所讨论的。所述方法包括为所述客户端提供服务端点。在一些实施例中，这可以是所述通道服务的服务API或HTTP端点。所述方法包括：提供与所述通道服务相关联的至少一个服务寻址密钥；以及获取与所述客户端相关联的至少一个客户端寻址密钥。所述寻址密钥可以是静态密钥和/或临时密钥，并且可以用于验证相应端点的身份。然后，基于所述接收到的请求，所述方法包括：向所述给定客户端提供对一项或更多项功能的访问权限，所述一项或更多项功能使得能够在所述给定客户端与用于数据或消息传输的另一通道(即一组通信路径或会话或数据隧道)之间进行直接通信，其中可以基于所述服务和/或客户端寻址密钥来发起使用所述通道的通信。
如关于所述第一方面所讨论的，矿工节点还能够将所述通道服务用作客户端，并且在所述第二方面的这种情况下，上述方法以相同方式应用于也是客户端的矿工。为了便于引用，与矿工相关联的端点和密钥将被称为矿工寻址密钥和矿工端点，因为所述第二方面可能请求两者，当涉及挖掘已完成交易时，客户端和矿工一样(如果所述客户端不具有指向区块链的链路)。
有利地，本公开的所述第二方面的所述方法通过实现通道服务并提供诸如API端点的端点以及诸如静态和/或动态/临时密钥的寻址密钥，允许与客户端相关联的一个或更多个处理器注册并像网络服务一样访问所述通道服务，而无需将数据写入区块链或访问区块链中的数据。密钥还允许在经由通道进行任何消息传送之前发起认证或握手过程，从而通过验证为其创建所述通道的各方的身份来提高安全性，从而确保经由所述通道的所有通信仅发生在两个经认证的实体之间。
在一些实施例中，所述握手过程包括获取握手结果或模式。基于所述握手结果或模式，获取共享密钥，从而基于共享密钥对使用所述通道的直接通信进行加密。这是进一步有利的，因为所述共享密钥基于身份，即为其发起通道的双方或实体的寻址密钥。因此，只有相应的有效方和经认证方才能解码加密的密文，从而提高可靠性和保密性，并且能够抵抗恶意方的模仿企图。在这种情况下，各方将均是所述通道服务和另一方，即客户端，所述客户端与所述通道处理器之间的通信经由所述通道进行。
所述第二方面的第二实现方式涉及一种用于使用消息或交易的通道服务实现通道寻址的方法，所述通道服务被提供给一个或更多个客户端，其中所述方法由所述一个或更多个客户端中的给定客户端的一个或更多个处理器实现。如上所述，矿工节点也可以是客户端，以利用所述通道服务来促进与其他节点的点对点通信。所述方法包括：发送与所述通道服务有关的请求，所述通道服务由通道处理器实现；获取与所述通道服务相关联的服务端点。所述方法包括：获取与所述通道服务相关联的至少一个服务寻址密钥；以及提供与所述给定客户端相关联的至少一个客户端寻址密钥。在所述矿工的情况下，这可以是矿工寻址密钥。然后，所述方法包括：获取对一项或更多项功能的访问权限，所述一项或更多项功能使得能够使用用于数据或消息传输的通道在所述给定客户端与另一实体之间进行直接通信，其中基于所述服务和/或客户端/矿工寻址密钥发起使用所述通道的通信。有利地，这使得所述客户端以及所述服务端点能够安全地验证彼此的身份。对于第一种实现方式讨论的优点同样适用。
当使用由所述通道处理器提供的功能与另一实体建立通道时，当由客户端实现时，所述第二方面包括标识与要其进行通信交换的另一实体的方法步骤。这可以基于客户端标识符或别名或任何其他已知手段。然后，使用从所述通道处理器接收到的所述一项或更多项功能，所述方法包括：创建用于所述通信交换的通道。然后，所述方法进一步包括：使用所述创建的通道执行以下步骤：
提供客户端端点；
获取与所述另一实体相关联的至少一个第三方寻址密钥；
提供与所述给定客户端相关联的至少一个客户端寻址密钥；
基于所述客户端和第三方寻址密钥，使用所述通道交换一个或更多个握手消息；
基于握手结果或模式，获取共享密钥；
其中基于所述共享密钥，对使用所述通道与所述另一实体的所述直接通信进行加密。
这有利地确保现在基于与所述客户端以及所述其他实体相关联的密钥来认证和保护所有通信。此外，该寻址和认证方面以及端到端加密的提供也与已知的噪声协议框架兼容。
在一些实施例中，服务、客户端和/或矿工的端点是HTTP API端点，并且其中所述端点使用安全HTTP(HTTPS)递送到所述客户端。这有利地确保所述端点可通过指向已知且可信的证书授权(CA)的证书链来验证。在一些实施例中，所述端点可以是统一资源定位符(URL)，该统一资源定位符(URL)包括在对与所述通道服务相关联的一项或更多项功能的请求的响应中。如上所述，有利的是，所述通道的至少一方能够使用PKI或其他机制获知和验证另一方的身份。
在一些实施例中，所述端点可以是与所述通道的各个实体相关联的别名，其中所述别名特定于所述通道处理器并且由基于别名的寻址服务提供，所述寻址服务具有可从定义的或公知的位置访问的机器可读资源，所述机器可读资源包括与所述通道处理器有关的一项或更多项功能。所述别名可以是已知的或被提供给一个或更多个客户端/矿工，所述别名与用于认证的非对称加密密钥对相关联。
如上所述，有利地，双方都可以使用PKI或其他机制获知和验证双方的身份。
本公开的各方面还包括一种计算设备，所述计算设备包括处理器和存储器，所述存储器包括可执行指令，由于所述处理器进行的执行，所述可执行指令使得所述设备执行如上所述的计算机实现的方法，其中所述计算设备与通道有关。
本公开的各方面还包括一种计算设备，所述计算设备包括处理器和存储器，所述存储器包括可执行指令，由于所述处理器进行的执行，所述可执行指令使得所述设备执行如上所述的计算机实现的方法，其中所述计算设备与客户端有关。
本公开的各方面还包括一种计算设备，所述计算设备包括处理器和存储器，所述存储器包括可执行指令，由于所述处理器进行的执行，可执行指令使得所述设备执行如上所述的计算机实现的方法，其中所述计算设备与矿工有关。
本公开的各方面还包括一种系统，所述系统包括至少一个通道处理器，所述至少一个通道处理器经由通信网络以通信方式耦合到至少一个客户端和至少一名矿工，所述至少一个通道处理器实现一个或更多个客户端的通道服务，如上所述。
本公开的各方面还包括其上存储有可执行指令的计算机可读存储介质，由于计算机的处理器进行的执行，所述可执行指令使得所述计算机执行上述任何方面和实施例的方法。
现在参照附图以图示方式描述一些具体实施例，其中相似的附图标记表示相似的特征。
与本公开相关联的上述方面和实施例通过以易于参与所述直接通信的实体实现和管理的可扩展、安全和准确的方式实现用于此类应用和用例的通道服务，来提供此类解决方案以及用于安全、链下、方对方(点对点/直接)应用消息传递机制。各方面和实施例提供了一种机制，即使在其中一方暂时离线的情况下，各方也能够通过该机制以安全的方式进行通信。
存在用于实体之间的消息递送的公知系统和机制。下面简要讨论这些问题：
电子邮件(电子邮件)：
作为在现代互联网上运行的最古老、最受欢迎的消息传递应用之一，电子邮件提供了许多积极的解决方案，包括：
·客户端寻址
·连接(用于推送的IMAP或Exchange/ActiveSync)
·同步(IMAP或Exchange/ActiveSync)
·账户管理-基于运营商要求，而不是客户端要求
·存储
·安全性-用于认证(与应用内无关)
一些缺点意味着电子邮件的安全性或可扩展性不足以与区块链关联的应用配合使用，这些缺点包括：
·\不存在更灵活且更安全的替代寻址方式(仅电子邮件地址)，不存在基于对方主题的更可靠且更独立的结构
·许多应用，特别是那些可与区块链互操作的应用，使用机器可读资源，即JSON-over-HTTP，而电子邮件是一种自定义协议，许多安全的私人和公共区块链网络都不允许发送电子邮件，因此技术覆盖范围不灵活或有限。
即时通讯：
诸如WhatsApp、Telegram和Signal的无处不在、安全、可扩展的现代即时通讯解决方案，对于某些点对点应用非常有用。但所有这些都是由一个中央机构运营的，该机构有权随时以任何理由拒绝向任何人提供服务。这与所有公共区块链的本质是不兼容的。
消息代理：
消息代理是支持各种消息传递范例的硬件设备或软件中间件。这些产品有时称为企业服务总线(ESB)或集成总线，它们为企业提供发布者-订阅者消息传递。它们通常提供一个或更多个有用的机制，如：
·寻址
·连接
·账户管理
·存储配额
·安全
但是，此类解决方案是专有的并且需要由单个实体部署，通常在单个组织内部署。所以这些也不适合分布式分类账技术，尤其是公共区块链。
如上所述，本公开的所述第一方面和所述第二方面和实施例提出了提供通道服务，以通过使用单独的、可识别的通道(即为许多应用的点对点通信提供的通信路径或会话)来实现消息传递功能。这能够跨多个应用和用例实现，这些应用和用例需要实体交换消息，同时将参与实体与区块链的任何链路或下载部分取消关联。本文档中标题为“用例”的部分解释了其中一些用例的示例。
如上所述，各个通道均具有所有者，所有者是已经向通道服务注册的客户端，并且客户端以API的形式获取通道功能以配置通道读/写权限。例如，这些权限可以是不允许未经认证的连接；并且通过发布可撤销的访问令牌，即API密钥或令牌，来为通道以及个别消息提供不同的读/写权限。如所讨论的，通道使用已知的传输协议(应用级端到端加密协议)来操作，该协议保护其中传输的消息。
第一方面—通道服务的实现
用于提供上述第一方面的通道服务的通道处理器可以是平台即服务(PaaS)和软件即服务(SaaS)产品，其有利地实现了一个或更多个客户端的端到端(点对点)通信或消息传递服务。
如上所述，可以经由或使用互联网通信协议经由接入点或用于通道处理器的API从客户端接收请求，因为API能够被实现为网络服务，尽管该方法不限于此。例如，也可以使用与通道处理器相关联的别名，即基于上述bsvalias寻址协议。图1涉及本公开的所述第一方面，并描绘了一种用于为促进一个或更多个客户端的点对点通信提供通道服务的计算机实现的方法。图1的方法由通道处理器实现，该通道处理器可以包括一个或更多个通道处理器。
步骤102涉及来自客户端的通道服务注册请求。步骤102描述接收多个客户端中的给定客户端的请求。如上所述，客户端可以是不具有任何与区块链交互的功能的客户端，也可以是具有有限功能(诸如,SPV钱包)的客户端，甚至可以是运行区块链的完整副本的矿工节点。由于通道处理器与由URI或别名标识的API端点相关联，在该示例中，来自给定客户端的请求可以基于诸如超文本传输协议(HTTP)传输协议格式的标准互联网协议。在一些实施例中，请求可以包括客户端的标识符以及所请求的服务的标识符。
步骤104描述了为客户端创建账户，该账户与诸如唯一客户端或账户标识符和通道服务的访问密钥之类的账户证书相关联，所述访问密钥可以是密码或PIN，或者甚至可以是与客户端相关联的一个或更多个加密密钥。在某些情况下，在注册时，可以基于账户凭证为给定客户端创建记录。
与账户注册关联的示例性方案可以是：
Figure BDA0003365282310000191
步骤106描述了提供对通道的访问权限以及消息功能，以使客户端能够与使用通道的任何其他实体进行点对点直接通信。可以使用通道功能创建通道，并且通道内的数据流能够基于所提供的消息功能。如上所述，这些API可以是通道API或消息API。通道API受账户凭据保护，允许账户持有人创建和管理通道。消息传递API将允许账户持有人和对方，即为其创建通道的其他实体或第三方，甚至诸如管理员(如果客户端是组织)的其他实体从通道读取或向通道写入。
因此，通道服务通过使用来自步骤104的账户凭证和/或每个账户的通道来标识客户/用户，每个账户将具有唯一的标识符。消息流，无论是单次流还是长时间流，在逻辑上被安排到不同的通道中，而这些通道又归单个账户、客户端账户所有。一旦设置好，客户端就可以通过账户凭证向通道服务标识自己。
在一些实施例中，通道和消息功能还可以包括用于使账户持有人(客户端)生成API令牌的功能，如果通道所有者要求对其API进行认证，则可以将其传递给第三方(消息交换对方，客户端希望与其进行直接通信)。因此，通道API可以可选地由API令牌保护。
图1a是根据第一方面提供的通道服务实现的示意图。图1a示出了由n个通道处理器提供的通道服务，其中n>1，这些通道处理器为n个客户端实现通道服务，每个客户端分别与一个或n个对方通信。如图所示，每个客户端可以具有多个不同的通道，每个通道用于n个主题中的一个特定主题。
图2涉及本公开的第一方面，并描绘了一种计算机实现的方法，该计算机实现的方法用于提供与涉及特定通道的请求或与给定客户端账户相关联的消息相关联的API或功能。
步骤202描述了从给定客户端接收与通道相关联的请求。该请求可以与通道相关，即由唯一通道ID标识的通道或与客户端账户的新通道相关的通道。在一些实施例中，该请求可以与特定消息相关，即与特定通道中的主题1或2或n相关，如图1a所示。该请求包括客户端的账户标识符，并且可以在图1的步骤104中提交账户凭证之后提出。
在步骤204中，检查客户端的身份以查看该客户端是否是注册为使用通道服务及其所提供的功能的有效客户端。在一些实施例中，这可以在注册期间基于已知的认证方法，诸如受密码保护的登录认证等。核实可以基于接收到的与记录中的密码匹配的密码。在其他实施例中，还可以使用基于加密或寻址私钥/公钥对的标准PKI技术来核实在步骤202中从客户端接收的请求中可能存在的数字签名。在这种情况下，可以通过检查私钥签名的请求是否可以成功恢复或使用公钥验证来核实客户端的身份。
如果客户端身份无法验证或验证失败，则在步骤206中不再进一步处理该请求。
如果客户端成功核实，则在步骤204中，检查步骤208中对服务的请求的有效性。这一步骤是为了确保给定客户端确实获授权使用所请求的服务。对此的权限或属性可以存在于客户端的记录中，以指示可以提供给相应客户端的一种或更多种类型的访问级别或服务。例如，客户端可能具有创建通道和消息的权限，但没有修改或删除消息的权限。此外，在一些示例中，请求中标识的通道可能是不正确的，或者可能不与给定客户端相关联，因此是无效的。
如果发现该请求对于请求客户端是不允许的或无效的，则在步骤210中不再进一步处理该请求。下面给出了一些在发出未经授权的请求时可能返回的错误消息的示例：
错误代码401账户凭证/数字签名无效。
错误代码402账户凭证/数字签名有效，但请求未获授权。这是因为账户被禁用，或者账户持有人不是指定通道的所有者。
错误代码403找不到通道、API令牌或其他资源。
应当理解的是，尽管上述核实客户端和/或请求的实施例对于实现所述第一方面的通道服务的操作是有用的，但其不是必需的。在一些情况下，可以仅执行步骤202或步骤206中的核实。在一些情况下，不通过通道处理器来执行核实，因为这可以通过其他手段来进行(参见上文提到的第二方面，并且从图6开始详细说明)。
如果在步骤208中发现请求有效，则在步骤212中，将所请求的通道功能和/或消息功能连同它们的访问或API令牌(如果作为请求或权限的一部分请求或要求)提供给客户端。
下面示出了与对通道和/或消息功能/API的请求相关联的特定方案和/或格式的一些示例，以及由通道处理器提供的响应的示例性方案。
1.通道API：
通道API可以是通道服务向服务提供的JSON-over-HTTP API客户端账户，以创建和/或管理用于点对点通信的通道。
在一些实施例中，所有API端点都可能需要认证。具体的认证方案可以由实现方式确定。常见形式包括诸如OAuth、基本身份验证和承载令牌方法等的方案。如上所述，通道API可以可选地由客户端提供或生成的API令牌来保护
1.如步骤204至208中所示，由账户凭证保护的通道API允许账户持有人创建和管理通道。可能会提供以下接口：
1.1通道列表：返回所有通道的列表
请求格式：
GET/api/account/<account-id>/channel/list
授权：…
响应格式：
201确定
内容类型：应用/json
内容长度：...
Figure BDA0003365282310000211
Figure BDA0003365282310000221
1.2创建通道：创建账户持有人拥有的新通道。
请求格式：
POST/api/account/<account-id>/channel
授权：...
内容类型：应用/json
内容长度：...
Figure BDA0003365282310000222
Figure BDA0003365282310000231
响应格式：
成功创建的响应包含初始访问令牌。可以使用步骤204中的账户凭证和根据图1设置的账户凭证来访问通道API，但是可以使用令牌来访问消息传递API。该初始访问令牌属于账户持有人，以便他们读取和写入通道。
201确定
内容类型：应用/json
内容长度：...
Figure BDA0003365282310000232
1.3删除通道
请求格式：
DELETE/api/account/<account-id>/channel/<channel-id>
授权：...
响应格式：
204无内容
1.4修改通道：更新通道元数据和权限。
请求
POST/api/account/<account-id>/channel/<channel-id>
授权：...
内容类型：应用/json
内容长度：...
响应
此请求的作用类似于HTTP PATCH，因此如果不需要更改，则可以省略消息正文中的字段。
Figure BDA0003365282310000241
1.5生成通道API令牌
请求格式：
POST/api/account/<account-id>/channel/<channel-id>/api-token
授权：...
内容类型：应用/json
内容长度：...
Figure BDA0003365282310000242
响应格式：
这是唯一将返回令牌值的API调用。如果该令牌丢失，则应删除该令牌并替换为新令牌。
201已创建
内容类型：应用/json
内容长度：...
Figure BDA0003365282310000251
1.6撤销通道API令牌：创建新的API令牌，供第三方在访问此通道时使用。
请求格式：
DELETE/api/account/<account-id>/channel/<channel-id>/api-token/<token-id>
授权：...
响应格式：
204无内容
消息传递API允许账户持有人和相关对手(通道的其他实体)读取或写入给定通道中的消息。
2.以下消息API可以作为JSON-over-HTTP API提供，以供账户持有人及其对方交换消息。
2.1新消息测试通道
请求格式：
HEAD/api/channel/<id>
授权：<api-token>
响应格式：
201确定
ETag：<max-sequence>
2.2向通道写入消息
请求格式：
POST/api/channel/<id>
授权：<api-token>
内容类型：...
内容长度：...
响应格式：
a)已接受
该消息已写入通道。
201已创建
b)测序失败
该通道已创建为已测序，并且与该请求关联的API令牌尚未标记为读取该通道中的最新消息。如果仍然合适，客户端可能需要重试写入尝试。
409冲突
c)消息太大
在端到端加密保护所有消息的实施例中，例如基于噪声协议，任何单个消息的最大大小设置为65536字节。由于不应存在大于此大小的消息，因此在一些实施例中，限制写入通道的任何消息的最大大小可能是有用的。大于此值的消息可能会被通道拒绝。
413有效载荷太大
d)已超出存储配额
在一些实施例中，已超出可能由服务运营商设置的配额。客户端请求可能有效，但存储服务此时无法满足该请求。
507存储不足
2.3获取通道中的消息
返回通道中的所有消息，可选择地筛选为仅未读。
请求格式：
GET/api/channel/<id>[？unread＝true]
授权：<api-token>
未读查询字符串参数是可选的。
响应格式：
201确定
内容类型：应用/json
内容长度：...
ETag：<max-sequence>
Figure BDA0003365282310000261
Figure BDA0003365282310000271
2.4将消息标记为已读或未读：将消息标记为已读或未读。
请求格式：
POST/api/channel/<id>/<sequence>[？older＝true]
授权：<api-token>
内容类型：应用/json
内容长度：...
{"read":true|false}
可选的旧参数允许客户端将序列小于或等于所提供的<sequence>路径参数的所有消息标记为在单个调用中读取。
响应格式：
201确定
在步骤214中，在图2的实施例中，然后可以将已完成交易提供给通道处理器。这可以由客户端或由该通道的其他实体发送。在本实施例中，意在由通道处理器将交易提交给要挖掘的区块链。然而，如前所述，本公开不限于此。客户或其他实体可以改为提交交易。
在本实施例中，通道处理器(或在其他示例中的提交者)然后可以准备要提交的交易，然后继续创建通道，在该通道上最终将从矿工接收包含证明(Merkle树证明)。该通道特定于通道处理器和矿工。然后，通道处理器(或提交者)将交易提交给矿工以包括在诸如公共BSV区块链等区块链网络中。在一些实施例中，通道处理器(或提交者)还可以从矿工接收提交响应。
在步骤216中，通道处理器经由在步骤214中创建的通道从矿工接收区块链中的包含证明。因此，通道处理器、客户端或其他实体都不需要在区块链中搜索此类交易，因为包含证明已经由矿工直接使用通道服务提供。
涉及所述第一方面的图3的方法由与客户端相关联的一个或更多个处理器实现。
在步骤302中，客户端准备对通道服务的请求并将其发送到通道服务(通道处理器)，并且在步骤304中接收与客户端账户的账户标识符和访问密钥相关联的所需账户凭证。在一些实施例中，客户端标识符包括请求中的客户端别名或标识符和/或服务标识符。这类似于用于该过程的图1的步骤102和104。准备好的请求可以由使用超文本传输协议(HTTP)或类似传输协议格式发送的客户端发送。在一些实施例中，该请求被发送到实现为HTTP或RESTAPI的通道处理器，并且响应也可以以HTTP传输协议格式提供给客户端。
在步骤306中，与图2中的步骤202类似，当由通道处理器接收时，客户端发送与特定通道或消息相关的请求。在步骤308中，如果需要，向客户端提供用于该请求的具有通道或消息API以及访问令牌的响应。在图2中的步骤212中可以看到针对通道和/或消息API发送的请求以及接收的响应的示例。
在步骤310中，然后使用在步骤308中从通道处理器接收到的API来创建与另一实体的通道。例如，客户端可以是商家，而另一方可以是客户或对方，对于特定发票或目的或商品，必须与其进行数据或资产转移，例如数字资产的支付。任何已知的传输协议都可以通过通道用于此目的，该通道为客户端和由API和访问令牌保护的其他实体提供直接的端到端路径。
接收到的API用于随后和/或读取或写入消息或执行与该通道相关联的任何其他功能，和/或基于与该通道相关联的一个或更多个访问令牌向另一实体发送消息。如上所述，访问令牌可用于认证另一实体。在一些实施例中，消息API还被发送到另一实体以通过该通道进行通信。
在步骤312中，经由该通道接收来自另一实体或对方的响应。这是可能的，因为在上一步中，另一方已经收到了所有必需的消息API和访问令牌。
在步骤314中，响应于通信交换的完成，客户端将已完成交易发送到图3的实施例中的通道处理器，以提交给区块链。如关于步骤214所讨论的，如果客户端或其他方与用于提交交易的功能相关联，则这也是可能的。然而，客户端或其他方不需要具有任何此类功能来使用通道服务以使用通道进行点对点通信。
涉及所述第一方面的图4的方法由与矿工相关联的一个或更多个处理器实现。
如上所述，矿工能够作为通道服务的客户端，在这种情况下，图1至图3中列出的流程既适用于矿工节点，也适用于客户端。然而，矿工节点不需要是客户端才能仍然使用由通道服务提供的通道。例如，如果向他们发送了一个通道，则他们可以使用该通道，其中他们是该通道的其他实体。此场景如图4所示。
在步骤402中，当提交者将已完成交易提供给矿工进行挖掘时(提交者可以是通道处理者，也可以是通道服务的客户端)，提交者可以使用通道服务创建用于直接与矿工进行通信的通道。在这种情况下，也如图3的步骤310中所讨论的，矿工从提交者接收对通道的访问以及任何相关联的消息API和访问令牌。
在步骤404中，矿工使用已知的挖掘技术在与区块链相关联的区块中挖掘交易，其中一些技术在本申请的背景中讨论。
在步骤406中，矿工然后在步骤402中使用通道将区块链中的交易的包含证明直接发送给提交者，使得提交者不需要运行区块链的副本或搜索区块链即可找到所述交易。
在一些实施例中，该证明可以是Merkle树证明。这是组织为树的已知认证数据结构。每个数据块的哈希存储在基本层或树叶上的节点中，并且树或分支的每个内部节点包含根据其两个子节点的哈希计算的加密哈希。树的顶部节点，即Merkle根唯一标识构建树的数据集。因此，Merkle树允许有效的包含证明，其中矿工或证明者节点通过向提交者或验证者NIDE发送带有审计路径的证明来向提交者或验证者NIDE显示特定数据块是经认证的数据集的一部分。审计路径包含重新计算Merkle根所需的节点哈希，而不需要提交者显示整个数据集。在比特币SV中，区块中包含的交易存储在Merkle树中。
第二方面：安全：寻址和加密
本公开的第二方面涉及为用于点对点通信的通道提供安全寻址和安全功能。对于实体之间实现的一个或更多个点对点通道，可以分别实现与所述第二方面相关联的各方面和实施例。它还可以与上面讨论的实施例结合使用，如根据所述第一方面实现的通道服务。这是下面参照图5至图7讨论的实施例，但是应当理解的是，本公开的所述第二方面并不仅限于所述第一方面中描述和实现的通道服务。所述第二方面涉及确保实体的点对点通信路径的安全性。所述第二方面的一个示例和相关用例是其与所述第一方面的通道服务的使用。
涉及所述第二方面的图5的方法由与实现通道服务的通道处理器相关联的一个或更多个处理器实现。
步骤502描述了由通道处理器从客户端接收对与通道服务相关联的服务的请求的步骤。如上所述，这也可能是一名矿工。该实施例中的请求用于允许请求实体访问服务，以便于创建或管理与第三方或另一实体的一个或更多个通道或消息，如关于所述第一方面所讨论的。
在步骤504中，验证与所请求的客户端相关联的账户凭证，如图2中的步骤204中所述。这是基于请求客户端已向通道服务注册的假设，如图1所示。如果客户端认证无效，则在步骤506中，通道处理器拒绝在步骤502中提出的请求。
在步骤508中，通道处理器发送通道服务的服务端点和与通道服务相关联的至少一个服务寻址密钥。
服务端点可以是超文本传输协议(HTTP)应用程序编程接口(API)端点，其中所述端点使用安全HTTP(HTTPS)来递送，并且可以通过返回到已知且可信的CA的证书链进行验证。这是有利的，因为它提供了对通道服务的身份的认证，使得服务端点可以被信任为确实属于通道服务，而不是恶意方。
在一些实施例中，例如在为客户端建立账户或传递通道API或消息API期间，端点可以是先前发送的来自通道服务的消息中包括的统一资源定位符(URL)。此外，这还有利地确保端点可信，因为它是在只能与所请求的通道服务相关联的消息中提供的。可选地，还可以包括HTTP授权报头值。当客户端(或通道中的其他方)要生成异步回复时，可以使用简单的HTTP POST调用。
可以使用以下示例性属性来扩展对象模式：
Figure BDA0003365282310000301
在其他实施例中，服务端点可以是与通道服务相关联的别名，例如如上所述的bsvalias服务，其中可以基于与bsvalias或另一寻址服务相关联的机器可读JSON资源来验证别名。
在步骤510中，从客户端获取客户端寻址密钥。服务寻址键和/或客户端寻址键可以是一个或更多个静态“s”密钥和/或临时“e”密钥。这是有利的，因为此类寻址密钥与用于端到端加密的一个或更多个已知且安全的密钥交换协议(例如，噪声协议框架)兼容。
在步骤512中，使用寻址密钥，在双方(在这种情况下为通道处理器和客户端)之间遵循握手过程。在一些实施例中，握手基于噪声协议框架中设置的机制。噪声是基于Diffie-Hellman(DH)密钥协议的密码协议框架。噪声协议提供了一系列备受好评、经审查和采用的密码协议，这些协议解决了除初始静态密钥分发之外的所有要求。噪声协议框架用于通过在握手阶段选择涉及静态密钥的结构来构建解决认证、机密性和数据完整性的方案。
下面概述了符合噪声协议框架的握手，如http://www.noiseprotocol.org/ noise.html中所述：
噪声协议从双方交换握手消息开始。在该握手阶段，双方交换DH公钥并执行一系列DH操作，将DH结果哈希为共享密钥。在握手阶段之后，各方都可以使用该共享密钥来发送加密的数据传输消息。
噪声框架支持握手，其中各方都具有长期静态密钥对和/或临时密钥对。噪声握手可以用一种简单的语言来描述。该语言由令牌组成，所述令牌被排列成消息模式。消息模式被排列成握手模式。
消息模式是指定包括握手消息的DH公钥以及发送或接收该消息时执行的DH操作的令牌序列。握手模式指定包括握手的消息的顺序交换。
握手模式可以通过DH函数、密码函数和哈希函数来实例化，从而实现具体的噪声协议。
噪声的核心是在握手期间由各方维护的一组变量，以及通过顺序处理来自消息模式的令牌来发送和接收握手消息的规则。
各方都维护以下变量：
·s、e：本地方的静态密钥对和临时密钥对(可能为空)。
·rs、re：远程方的静态公钥和临时公钥(可能为空)。
·h：有效的握手哈希值，用于哈希已发送和接收的所有握手数据。
·ck：哈希以前的所有DH输出的链式密钥。握手完成后，链接密钥将用于派生传输消息的加密密钥。
·k、n：加密密钥k(可能为空)和基于计数器的随机数n。每当新的DH输出导致计算新的ck时，也会计算新的k。密钥k和随机数n用于加密静态公钥和握手有效载荷。带有k的加密使用一些经过认证的加密和关联数据(AEAD)密码模式，并使用当前h值作为包含在AEAD认证范围内的关联数据。静态公钥和有效载荷的加密在握手阶段提供了一定的机密性和密钥确认。
握手消息由一些DH公钥和有效载荷组成。有效载荷可以包含由应用选择的证书或其他数据。为了发送握手消息，发送者需要指定有效载荷，并按顺序处理消息模式中的每个令牌。可能的令牌包括：
·“e”：发送者生成新的临时密钥对并将其存储在密钥变量中，将临时公钥作为明文写入消息缓冲区，并将公钥与旧密钥一起哈希以导出新的密钥。
·“s”：发送者将其静态公钥从密钥变量写入消息缓冲区，如果密钥非空，则对其进行加密，并将输出与旧密钥一起哈希以派生新的密钥。
·“ee”、“se”、“es”、“ss”：在发起者的密钥对(是静态密钥对还是临时密钥对由第一个字母确定)和响应者的密钥对(是静态密钥对还是临时密钥对由第二个字母确定)之间执行DH。将结果与旧ck一起哈希，以派生新的ck和k，并将n设置为零。
在处理握手消息中的最终令牌后，发送者然后将有效载荷写入消息缓冲区，如果k为非空，则对其进行加密，并将输出与旧h一起哈希以派生新的h。
举个简单的例子，未经认证的DH握手由握手模式描述：
->e
<-e、ee
发起者发送第一消息，该消息只是临时公钥。响应者会发回其自己的临时公钥。然后执行DH，并将输出哈希为共享密钥。
注意，在第一消息中在明文临时公钥之后发送明文有效载荷，并且在响应消息中在明文临时公钥之后发送加密有效载荷。应用可以发送它想发送的任何有效载荷。
响应者可以发送其静态公钥(在加密状态下)，并通过略有不同的模式进行认证：
->e
<-e、ee、s、es
在中，最终的ck和k值都是DH结果的哈希。由于EES令牌指示发起者的临时密钥和响应者的静态密钥之间的DH，因此发起者对第二消息的有效载荷的成功解密用于向发起者认证响应者。
请注意，第二消息的有效载荷可能包含零长度明文，但有效载荷密文仍将包含认证数据(例如，认证标签或“合成IV”)，因为加密使用的是AEAD模式。第二消息的有效载荷还可用于传递响应者的静态公钥的证书。
发起者可以发起其静态公钥(在加密中)，并使用带有一条附加消息的握手模式对其自身进行认证：
->e
<-e、ee、s、es
->s、se
以下部分进行了详细说明，并增加了一些复杂性。然而，噪声的核心是这个由变量、令牌和处理规则组成的简单系统，它允许简明地表达一系列协议。
在步骤514中，基于上面指定的握手，获取共享密钥，然后该共享密钥继而是用于通道的端到端加密的密钥。在一些实施例中，不直接使用共享密钥，并且可以另外存在还能够与在步骤512中握手之后获取的任何此类密钥结合使用的其他流程和进一步的密钥派生、二级DH交换、双向棘轮等。
涉及所述第二方面的图6的方法由与客户端相关联的一个或更多个处理器实现。
在步骤602中，客户端发送与通道服务相关联的请求，在步骤604中，核实成功后，获取与通道服务相关联的一项或更多项功能，即通道和消息API等。这些步骤类似于图3中的步骤306和步骤308，也与图5中的步骤502和步骤504相关。
在步骤606中，客户端创建用于与对方或第三方(其他实体)进行通信的通道。这类似于图3的步骤310。
在步骤608中，通过创建的通道将客户端寻址密钥以及客户端端点发送到另一实体。在步骤610中，从另一实体接收第三方寻址密钥。这些步骤类似于步骤508和步骤510，不同之处在于，是由客户端而不是由通道处理器通过通道向另一方提供端点和寻址密钥。在一些实施例中，另一方可以是矿工、通道处理器或打算通过通道与其进行直接通信并且为其提供客户端端点的某个其他第三方实体。
步骤612和步骤614，用于执行标识用于端到端加密的共享密钥的握手，类似于步骤512和步骤514，不同之处在于握手在客户端与另一实体之间。
涉及所述第二方面的图7的方法由与矿工相关联的一个或更多个处理器实现。
步骤702描述了矿工从提交者接收用于挖掘已完成交易的请求。该请求可以来自通道处理器或与通道处理器实现的通道服务相关联的客户端。在一些实施例中，矿工还可以是通道服务的客户端。虽然在图7的实施例中，通道处理器是提交者，但是本公开不限于此。
步骤704类似于步骤608，其中接收服务(提交者)寻址密钥和服务(提交者)端点。步骤706类似于步骤610，不同之处在于在这种情况下提供了矿工寻址密钥。
步骤708和步骤710，用于执行标识用于端到端加密的共享密钥的握手，类似于步骤512和514，不同之处在于握手在矿工与提交者之间。
图8表示使用通道的示例性消息流，例如通道服务的客户端与另一实体(对方)之间的点对点通信/交易/交换的示例，该示例基于上面已经解释的关于本公开的所述第一方面和所述第二方面所讨论的方法。
用例
该部分描述了使用方对方应用消息传递系统的多个现有真实世界场景，其中本公开的各方面和实施例可以实现/使用/应用以实现以上相对于所述第一方面和所述第二方面阐明的所有优点。
A)点对点交易：
为了推广加密采用，加密支付必须更接近法定支付方式，具体地，就是我们传统上在收银台支付的方式。客户需要能够在离线情况下消费BSV，这给商家带来了传播交易的负担。要做到这一点，低带宽SPV系统是一个合适的解决方案。客户将拥有可以在大多数时间都可离线的钱包，只能支付包含区块报头UTXO、输入交易和Merkle路径的交易。另一方面，商家将拥有可以在具有中央枢纽的地点分支的系统，接收这些支付并将其传播到区块链。
此类点对点流程的示意图如图9所示。该发票-交易-提交-验证流程允许各方进行交易，而无需维护和检查比特币SV区块链的完整副本。
发送者和接收者系统可以是在服务器端具有高级密钥管理和始终在线连接的复杂解决方案，在这种情况下，它们可以响应于用户请求进行直接通信。然而，发送者和/或接收者可以是具有部分连通性的终端用户设备。在这种布置中，发送者和接收者可能不是同时连接和可到达的。此外，在发送者和接收者都是部分连接的设备的情况下，他们可能都在网络地址转换(NAT)配置之后，这将阻止他们能够进行直接通信，即使他们都同时在线。
由本公开的通道服务提供的适用于交易的点对点交换的解决方案有利地允许对等方在对方离线时以及在双方之间没有直接路径的部署中交换消息。
B)开票：
开票允许交易方直接从接收者向发送者发出支付请求。从逻辑上讲，发票由以下部分组成：
·开票方详细信息
·发票编号或支付请求参考
·支付目的地脚本
·应付金额
·退款路径
为开票用例实现本公开的通道服务有利地满足以下要求：
·地址：发票开票方必须能够填写发票地址以便交付给发票接收者，发送者必须能够随后将支付交易交付给开票方
·机密性：发票可以是私人的和/或商业敏感的，不得由交易方以外的任何第三方查看
·认证：各方必须能够在任何消息交换中对对方进行认证，以便发送者验证发票源(接收者)的合法性，并且发票源不会通过与另一方共享详细信息来侵犯发送者的隐私
●数据完整性：消息必须是防篡改的，以便发送者知道收到的发票自接收者开具后未被修改，例如修改支付目的地、应付金额或假定的开票方详细信息
C)支付通道：
支付通道是一种链下议付，可以将对方风险降低到几乎为零。支付通道的典型用途是需要低价值、高频计费的场景。此类支付场景的一些示例包括：
·公共Wi-Fi接入
·流媒体(电影、体育赛事)
·停车
·预付费家庭公用事业(电费、燃气费、水费)
支付通道的一种结构在性质上类似于信用卡预授权，在这种情况下，供应商或商家可以确保预留资金，同时客户仍然受到保护，不会导致无法交付商品或服务。
在这种结构中，构建了一个初始资金交易，将资金全额支付给供应商。在将此交易提交给比特币SV区块链之前，需要构建退款交易，将所有资金退还给客户。该退款交易还受到时间锁的进一步阻碍，该时间锁设置得足够远，以允许商品或服务的提供一直持续到结束。
如果任何一方都没有采取任何进一步行动，客户可以肯定，一旦时间锁到期，“预授权”资金就会退还给他们。
一旦开始提供服务，就会建立一个新交易，将预授权资金退还给客户和供应商，比例为
客户：供应商付款
作为已经过的时间单位与每单位价格的函数(例如，1000中本聪/秒)。该付款交易由客户持续更新并传输给供应商，作为交换，客户将收到下一单位的商品或服务。
该不断更新的交易还受到时间锁的限制，该时间锁设置在预期服务提供结束与客户全额退款交易处于活动状态之间的某个时刻。
如果任何一方中途停止交易，任何一方的最大损失是一个时间单位的账单的价值，在该示例中，客户损失1000中本聪或商家损失1000中本聪的商品或服务。无论对方的反应如何，任何一方都可以提交此拆分付款交易的最新版本，以纳入比特币SV区块链。
如果支付通道结束，商家或服务提供商将完全提供商品或服务，并且客户将支付正确的金额。服务提供商可以提交拆分交易的最终版本以结算支付通道。
该用例代表了一种几乎完全链下的解决方案，只有“预授权”交易和任何最合适的结算交易都会传播到比特币SV网络。
为支付通道用例实现本公开的通道服务有利地满足以下要求：
·寻址：客户和服务提供商必须能够基于某个稳定的目的地交换消息
·认证：虽然这种结构将对方风险降低到接近于零，但双方必须能够相互认证，因为惩罚条款可能导致一方对另一方采取行动；各方必须确定在支付通道的生命周期内与谁进行通信
·数据完整性：消息在发送时必须以可核实的方式接收，以防止第三方因违约或其他处罚而“陷害”交易方之一
·实时：支付通道可以高频率、低值增量运行(尽管不是所有通道都会这样)；对于时间单位较短的场景，有必要将拆分交易的更新(伪)实时地从客户引导到供应商，以防止感知到的未支付导致服务中断
D)多重签名钱包：
多重签名钱包使用脚本保护资金，这些脚本需要签名形式的授权，使其免于定义组内多方的授权。无论是基于OP_CHECKMULTISIG的传统(有时也被称为“未获准”)还是较新的累加器多重签名结构，钱包都可以被配置为要求组中的一个子集提供授权，该子集的大小从一方到各方不等。这有时被称为M-of-N多重签名。
在M个签名应用于受多重签名保护的资金的支出之前，根据比特币规则，该资金的交易支出是无效的。这意味着，未签名或部分签名的交易不能通过比特币SV网络在授权方之间传递。此外，即使这是可能的，它也将与当前扩展举措(包括点对点交易和SPV模型)背道而驰。
因此，在给予足够授权且支出交易生效之前，组中的各方需要能够在彼此之间传递交易以及背景(为什么要使用这笔资金，以及需要将资金传递给谁)。然后，可以传递给资金接收者，也可以提交以供挖掘。图10中示出了该场景的示意性流程图。
为多重签名用例实现本公开的通道服务有利地满足以下要求：
·寻址：各方必须能够通过某个句柄将交易(和背景)引导到彼此
·认证：各方必须能够验证他们从谁那里收到授权请求，以便彻底拒绝欺诈性支出请求
·数据完整性：背景和交易必须由发起者向所述组呈现
此外，组中的各方可能正在使用部分连接和完全连接的本地客户端软件的任意组合，并且该本地客户端软件可能因由NAT部署而无法访问。任何消息传递解决方案都必须能够克服这些障碍。
E)安全多方计算：
安全多方计算(也称为安全计算、多方计算(MPC)或隐私保护计算)是密码学的一个子领域，其目标是为各方创建方法，以便在保持这些输入保密的同时联合计算其输入上的函数。与传统的加密任务不同，在传统的加密任务中，密码可以确保通信或存储的安全性和完整性，并且对手在参与者的系统之外(发送者和接收者都是窃听者)，此模型中的密码保护参与者的隐私不受彼此的影响。
通过作为多方计算的一部分来计算私钥以增强基于私钥的系统的安全性的解决方案开始出现。该协议的完成，有时被称为无经销商秘密分发会导致多方、设备或系统共享私钥。第二协议，即门限签名，进一步允许共享密钥的各方合作，以在消息上产生有效的ECDSA签名。
从发起到签名完成，私钥从来不会在一个位置具体化。这提供了与多重签名方案类似的安全级别，但通过向区块链隐藏参与方的数量(与某些多重签名方案相比，这些参与方的公钥)，增强了隐私性。
为安全的多方计算用例实现本公开的通道服务有利地满足以下要求：
·机密性：如果任何其他方(甚至是同一组中的各方)观察到任何一对参与方之间的任何消息，MPC的安全性就会被破坏
·认证：各方必须能够在任何消息交换中对对方进行认证，以防止通过中间人攻击等违反机密性
·数据完整性：消息必须是防篡改的，使得一方可以知道收到的消息在从会话对方传输期间未经更改
根据具体应用，密钥材料(包括私钥共享和其他中间状态)可能驻留在部分连接的最终用户设备上。无论发送者和接收者的连接状态如何，都必须传递参与方对之间的消息。
F)设备同步：
考虑一个系统模型，其中定义了以下实体：
·账户，其在逻辑上持有密钥和/或资金
·用户，其代表个人，拥有代表账户执行操作的权限，其中账户具有一名或多名用户
·设备，其由可能具有多个设备的用户拥有
在此类系统中，许多认证和授权方案都是可能的。在一种模型中，所有账户密钥(例如，私钥或对称密钥)都由系统管理。
用户使用诸如口令、TOTP/认证器应用、智能卡和/或硬件密钥等一个或更多个公知的方案对此类系统进行认证。通过认证之后，用户可以注册其控制下的一个或更多个设备，例如台式机或笔记本电脑、平板电脑或智能手机。越来越普遍的是，最终用户设备具有安全飞地(secure enclaves)，通过防篡改硬件防止密钥(例如，私钥)丢失。安全飞地操作可能会进一步受到生物识别等额外因素的保护。
一旦注册，设备通常通过质询响应协议和数字签名向系统标识自己，设备本地密钥在设备本地安全飞地中生成，并且永远不会从设备本地安全飞地导出。在这方面，这些密钥的作用方式类似于SSL和TLS等方案中的客户端证书。
用户可以通过针对其设备进行本地认证并向系统发出在该系统中执行的操作来授权该操作，其中该系统将该设备识别为已注册。然后，该系统可以使用系统管理的密钥、私钥(或共享)以及针对系统管理的资金来执行该操作。
在另一模型中，诸如私钥等密钥不由系统管理，而是由用户设备管理。
对于部署端到端加密的服务或应用，通常存在握手阶段，该阶段通常涉及密钥交换协议，然后是对称密钥派生过程。可以使用仅来自一个设备的密钥(特别是临时密钥)来制定密钥交换协议，并且进一步地，可以完全在安全飞地内管理这些密钥。在握手协议结束时，只有一个用户设备知道对称密钥。
同步通过端到端加密通道接收的账户明文或用户级消息能够通过两种方式之一来解决。在这两种情况下，设备必须经过类似的握手协议才能成对地在它们之间建立端到端加密通道，从而形成设备到设备通道的网格。
一旦设备网格建立，成功完成原始第三方握手的设备与用户其他设备共享生成的对称密钥，或者设备对通道消息进行解密，重新加密通道消息，然后将其转发到其他设备。现有产品和服务中实现了这两种模型。
为设备同步用例实现本公开的通道服务有利地满足以下要求：
·寻址：设备对必须能够相互定位
·认证：设备对必须确保任何消息交换中的对方是预期的通道对方
·机密性：设备对之外的任何一方都不能获知设备之间交换的密钥或私有消息
·数据完整性：任何干扰设备之间消息分发的尝试都不能导致设备同步错误材料
·同步：设备不得尝试同时回复外部握手过程，否则(构造良好的)握手将在检测到冲突的协议消息时失败
现在转到图11，提供了可用于实施本公开的至少一个实施例的计算设备2600的说明性简化框图。在各种实施例中，计算设备2600可用于实现以上示出和说明的任何系统。例如，计算设备2600可配置为用作图中的DBMS的一个或更多个部件，或者计算设备2600可配置为与给定用户相关联的客户端实体，该客户端实体向由图11的DBMS管理的数据库进行数据请求。由此，计算设备2600可以是便携式计算设备、个人计算机或任何电子计算设备。如图11所示，计算设备2600可包括具有一级或多级高速缓存的一个或多个处理器以及存储器控制器(统称为2602)，所述存储器控制器可被配置为与包括主存储器2608和永久存储器2610的存储子系统2606通信。如图所示，主存储器2608可以包括动态随机存取存储器(DRAM)2618和只读存储器(ROM)2620。存储子系统2606和高速缓存存储器2602可用于存储信息，诸如与本公开中所描述的交易和区块相关联的细节。处理器2602可用于提供本公开中描述的任何实施例的步骤或功能。
处理器2602还可以与一个或多个用户界面输入设备2612、一个或多个用户界面输出设备2614和网络接口子系统2616通信。
总线子系统2604可以提供用于使计算设备2600的各个组件和子系统能够按预期彼此通信的机制。虽然总线子系统2604示意性地示出为单个总线，但是总线子系统的替代实施例可以利用多个总线。
网络接口子系统2616可以向其他计算设备和网络提供接口。网络接口子系统2616可以作为从计算设备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进行处理的端口传输。由于计算机和网络的不断变化的性质，图11所示的计算设备2600的描述仅用作说明设备的优选实施例的特定示例。具有比图11所示系统的组件更多或更少的许多其他配置也是可能的。
需要说明的是，上述方面和实施例说明而不是限制本公开，本领域技术人员能够在不脱离所附权利要求定义的本公开范围的前提下设计出许多替代实施例。在权利要求书中，括号中的任何附图标记都不应解释为对权利要求的限制。词语“包括”等不排除任一项权利要求或说明书中整体列出的元件或步骤之外的元件或步骤的存在。在本说明书中，“包括”是指“包含”或“由......组成”。元件的单数形式并不排除此类元件的复数形式，反之亦然。本公开可以通过包括几个不同元件的硬件以及通过适当编程的计算机来实现。在列举几个装置的设备权利要求中，这些装置中的几个装置可以由同一硬件来体现。在互不相同的从属权利要求中引用某些措施的事实并不意味着不能有利地使用这些措施的组合。
列举的示例性实施例
在此基于与上述方面相关的以下条款来讨论本公开，本文中提供这些条款作为示例性实施例，以便更好地解释、描述和理解要求保护的方面和实施例。
1.一种计算机实现的方法，所述方法用于实现用于消息或交易的通道服务，所述通道服务被提供给一个或更多个客户端，所述方法由通道处理器实现，并且包括以下步骤：
从所述一个或更多个客户端中的给定客户端接收请求，所述请求与所述通道服务有关；
为所述给定客户端创建账户，所述账户具有特定于所述给定客户端的账户标识符和特定于所述账户标识符的访问密钥；
向所述给定客户端提供对一项或更多项功能的访问权限，所述一项或更多项功能使得能够在所述给定客户端与另一实体之间进行直接通信；
其中，所述一项或更多项功能包括：
与用于数据传输的一个或更多个通道有关的通道功能或过程；和/或
与使用所述一个或更多个通道传输的所述数据有关的消息功能或过程。
2.根据实例1所述的方法，其中，给定通道与通道标识符相关联，所述给定通道被配置用于与另一实体就与特定类型或主题相关联的数据进行通信。
实例
3.根据实例2所述的方法，其中，与所述给定通道相关联的数据包括在一个或更多个消息或交易中。
4.根据前述任一项实例所述的方法，其中，所述给定客户端是所述一个或更多个通道的所有者，所述方法还包括以下步骤：为所述一个或更多个通道中的给定通道发布一个或更多个访问令牌，所述一个或更多个访问令牌被配置用于与另一实体进行安全通信，所述一个或更多个访问令牌与所述给定通道或所述给定通道中的给定消息有关。
5.根据前述任一项实例所述的方法，其中，所述一项或更多项功能是：为所述给定客户端发布或向所述给定客户端提供的应用程序编程接口(API)，所述API包括用于所述一个或更多个通道的通道API；用于与每个通道或给定通道相关联的数据的消息API；并且其中，所述访问令牌是特定于给定通道或给定消息的API令牌。
6.根据前述任一项实例所述的方法，所述方法包括以下步骤：
从所述给定客户端接收请求，所述请求与通道相关联；
基于确定与所述给定客户端有关的所述账户标识符和访问密钥有效，允许所述给定客户端访问所述账户；
基于确定所述请求有效，处理对所述通道的所述请求；
向所述给定客户端发送响应，所述响应包括对与所述请求相关的一个或更多个通道的访问权限；
其中，接收到的所述请求包括以下一个或更多个：
-列出与所述给定客户端的所述账户有关的所述一个或更多个通道的请求；
-为所述账户创建通道的请求；
-删除已标识的通道的请求；
-修改与已标识的通道相关联的属性和/或权限的请求；
-为已标识的通道生成通道访问令牌的请求；
-撤销已标识的通道的通道访问令牌的请求。
7.根据实例6所述的方法，其中，所述响应中的所述通道功能包括用于所述账户的JavaScript对象表示法(JSON)-over-超文本传输协议(HTTP)API，使得能够创建和/或管理一个或更多个通道。
8.根据前述任一项实例所述的方法，所述方法包括以下步骤：
从所述给定客户端接收请求，所述请求与消息相关联，所述消息与和所述给定客户端的给定通道相关联的数据有关；
基于确定与所述给定客户端有关的所述账户标识符和访问密钥有效，允许所述给定客户端访问所述账户；
基于确定所述请求有效，处理对所述消息的所述请求；
向所述给定客户端发送响应，所述响应包括对与所述请求相关的一个或更多个消息的访问权限；
其中，接收到的所述请求包括以下一个或更多个：
-对所述给定通道中的新消息进行测试的请求；
-检索所述给定通道中的消息的请求；
-标记或标识所述给定通道中的已读或未读消息的请求；
-写入所述给定通道中的消息的请求。
9.根据实例8所述的方法，其中，所述响应中的所述消息功能包括用于所述账户的JSON-over-HTTP API，使得所述给定客户端和一个或更多个其他实体能够交换消息，和/或从所述给定通道读取数据和/或向所述给定通道写入数据。
10.根据前述任一项实例所述的方法，其中，通道处理器与HTTP API端点相关联，并且其中，基于HTTP传输协议格式接收来自所述给定客户端的所述请求。
11.根据实例10所述的方法，其中，所述通道处理器与API转换器相关联，所述API转换器被配置用于执行以下步骤：
以HTTP传输协议格式从所述给定客户端接收所述请求；
将接收到的请求转换为远程过程调用(RPC)格式，并将所述RPC请求发送到所述通道处理器以实现所述接收到的请求；
以RPC格式接收来自所述通道处理器的响应；
使用HTTP传输协议转换要发送到所述给定客户端的所述相应响应。
12.根据前述任一项实例所述的方法，其中，所述接收到的请求是包括所述给定客户端的账户标识符或与所述给定客户端的账户标识符相关联的HTTP GET或POST或PUT或PATCH请求。
13.根据前述任一项实例所述的方法，其中，所述账户标识符是为给定客户端提供的别名，所述别名特定于所述给定客户端并且由基于别名的寻址服务提供，所述寻址服务具有可从定义的或公知的位置访问的机器可读资源，所述机器可读资源包括与所述给定客户端有关的一项或更多项功能。
14.根据实例13所述的方法，其中，所述别名与所述给定客户端的域名相关联。
15.根据前述任一项实例所述的方法，所述方法包括以下步骤：为所述给定客户端提供通道服务库，所述通道服务库包括一个或更多个模块，所述一个或更多个模块用于促进与所述给定客户端相关联的所述账户的所述通道功能和/或所述消息功能。
16.根据前述任一项实例所述的方法，其中，响应于从所述给定客户端接收与给定通道相关联的已完成消息或交易以提交给区块链，所述方法包括以下步骤：
将所述交易提交给给定矿工；
创建用于与所述给定矿工进行通信的通道；
向所述给定矿工提供对一项或更多项功能的访问权限，所述一项或更多项功能使得能够与所述通道处理器进行直接通信；
使用所述通道从所述给定矿工接收所述已完成交易在区块中的包含证明。
17.一种计算机实现的方法，所述计算机实现的方法用于访问消息或交易的通道服务，所述通道服务被提供给一个或更多个客户端，所述方法由所述一个或更多个客户端中的给定客户端的一个或更多个处理器实现，所述方法包括以下步骤：
发送与所述通道服务有关的请求，所述通道服务由通道处理器实现；
获取为所述给定客户端创建的账户的账户凭证，所述账户凭证包括账户标识符和特定于所述账户标识符的访问密钥；
获取对一项或更多项功能的访问权限，所述一项或更多项功能使得能够在所述给定客户端与另一实体之间进行直接通信，所述一项或更多项功能包括：
与用于数据传输的一个或更多个通道有关的通道功能或过程；和/或
与使用所述一个或更多个通道传输的所述数据有关的消息功能或过程。
18.根据实例17所述的方法，所述方法包括以下步骤：
发送与用于所述给定客户端的账户的通道有关的请求；
从所述通道处理器获取响应，所述响应包括对与所述请求相关的一个或更多个通道的访问权限；
其中，所述请求包括以下一个或多个：
-列出与所述给定客户端的所述账户有关的所述一个或更多个通道的请求；
-为所述账户创建通道的请求；
-删除已标识的通道的请求；
-修改与已标识的通道相关联的属性和/或权限的请求；
-为已标识的通道生成通道访问令牌的请求；
-撤销已标识的通道的通道访问令牌的请求。
19.根据实例18所述的方法，其中，在所述响应中获取的所述通道功能包括用于所述账户的通道API，所述通道API使得能够创建和/或管理一个或更多个通道。
20.根据实例19所述的方法，其中，所述响应包括访问令牌，诸如用于每个通道功能的API令牌。
21.根据实例17所述的方法，所述方法包括以下步骤：
发送与消息相关联的请求，所述消息与用于所述给定客户端的账户的给定通道相关联的数据有关；
从所述通道处理器获取响应，所述响应包括对与所述请求相关的一个或更多个消息的访问权限；
其中，所述请求包括以下一个或多个：
-对所述给定通道中的新消息进行测试的请求；
-检索所述给定通道中的消息的请求；
-标记或标识所述给定通道中的已读或未读消息的请求；
-写入所述给定通道中的消息的请求。
22.根据实例21所述的方法，其中，所述响应中的所述消息功能包括用于所述账户的消息API，使得所述给定客户端和一个或更多个其他实体能够交换消息，和/或从所述给定通道读取数据和/或向所述给定通道写入数据。
23.根据实例22所述的方法，其中，所述响应包括访问令牌，诸如用于每个消息功能的消息API令牌。
24.根据实例17至23中任一项所述的方法，所述方法进一步包括：
标识要与其进行通信交换的另一实体；
使用从所述通道处理器接收到的一个或更多个通道功能，创建用于通信的通道；
将与所述通道相关联的一个或更多个访问令牌发送到所述另一实体；
使用从所述通道处理器接收到的用于所述通道的一个或更多个消息功能，向所述通道写入与交易有关的至少一个消息；
将与所述一个或更多个消息相关联的一个或更多个访问令牌发送到所述另一实体；
接收与所述通道中的所述交易有关的至少一个回复消息；
响应于所述通信交换的完成，提供已完成交易以供提交。
25.根据实例17至24中任一项所述的方法，所述方法包括以下步骤：接收和/或存储通道服务库，所述通道服务库包括一个或更多个模块，所述一个或更多个模块用于促进从与所述给定客户端相关联的所述账户的所述通道处理器接收到的所述通道功能和/或所述消息功能。
26.一种用于处理与区块链相关联的交易的计算机实现的方法，所述方法由与多名矿工中的给定矿工相关联的一个或更多个处理器实现，所述多名矿工以通信方式耦合到实现用于至少一个客户端的通道服务的至少一个通道处理器，所述方法包括以下步骤：
接收另一实体向所述区块链提交已完成交易的请求；从所述另一实体接收对通道的访问权限，所述通道使得能够与所述另一实体进行直接通信；
进一步地，在区块中挖掘所述已完成交易，使用所述通道发送所述已完成交易的包含证明。
27.一种计算机实现的方法，所述计算机实现的方法用于实现通道服务的寻址，所述通道服务被提供用于消息或交易，所述通道服务被提供给一个或更多个客户端，所述方法由通道处理器实现，并且包括以下步骤：
从所述多个客户端中的给定客户端接收请求，所述请求与所述通道服务有关；
基于确定与所述给定客户端有关的账户标识符和访问密钥有效，为所述客户端提供服务端点；
提供与所述通道服务相关联的至少一个服务寻址密钥；
获取与所述客户端相关联的至少一个客户端寻址密钥；
基于所述接收到的请求，向所述给定客户端提供对一项或更多项功能的访问权限，所述一项或更多项功能使得能够使用用于数据或消息传输的通道在所述给定客户端与另一实体之间进行直接通信。
28.根据实例27所述的方法，所述方法包括以下步骤：
接收与给定客户端相关联的已完成消息或交易以提交给所述区块链；
为矿工提供服务端点；
提供与所述通道服务相关联的至少一个服务寻址密钥；
获取与所述矿工相关联的至少一个矿工寻址密钥；
向所述矿工提供对一项或更多项功能的访问权限，所述一项或更多项功能使得能够使用通道与所述通道处理器进行直接通信。
29.根据实例27或28中任一项所述的方法，其中，所述服务寻址密钥、客户端寻址密钥和/或矿工寻址密钥是一个或更多个静态和/或临时密钥。
30.根据实例27至29中任一项所述的方法，所述方法包括以下步骤：
基于所述服务和客户端/矿工寻址密钥，与客户端/矿工交换一个或更多个握手消息；
获取握手结果或模式；
基于所述握手结果或模式，获取共享密钥；
其中，基于所述共享密钥，对使用所述通道的所述直接通信进行加密。
31.根据实例27至30中任一项所述的方法，其中，所述服务端点是超文本传输协议(HTTP)应用程序编程接口(API)端点，并且其中，所述端点使用安全HTTP(HTTPS)递送至所述客户端。
32.根据实例27至30中任一项所述的方法，其中，所述服务端点是统一资源定位符(URL)，所述统一资源定位符(URL)包括在对来自所述给定客户端的、与所述通道服务相关联的所述一项或更多项功能的请求的响应中。
33.根据实例27至32中任一项所述的方法，其中，所述服务端点是与所述通道服务相关联的别名，所述别名特定于所述通道处理器并且由基于别名的寻址服务提供，所述寻址服务具有可从定义的或公知的位置访问的机器可读资源，所述机器可读资源包括与所述通道处理器有关的一项或更多项功能。
34.根据实例33所述的方法，其中，所述别名是已知的或被提供给一个或更多个客户端/矿工，所述别名与用于认证的非对称加密密钥对相关联。
35.根据实例27至34中任一项所述的方法，其中，使用根据实例1至16中任一项所述的方法实现所述通道服务。
36.一种计算机实现的方法，所述计算机实现的方法用于使用用于消息或交易的通道服务来实现通道寻址，所述通道服务被提供给一个或更多个客户端，所述方法由所述一个或更多个客户端中的给定客户端的一个或更多个处理器实现，所述方法包括以下步骤：
发送与所述通道服务有关的请求，所述通道服务由通道处理器实现；
获取与所述通道服务相关联的服务端点；
获取与所述通道服务相关联的至少一个服务寻址密钥；
提供与所述给定客户端相关联的至少一个客户端寻址密钥；
获取对一项或更多项功能的访问权限，所述一项或更多项功能使得能够使用用于数据或消息传输的通道在所述给定客户端与另一实体之间进行直接通信。
37.根据实例36所述的方法，所述方法包括以下步骤：
标识要与其进行通信交换的另一实体；
使用从所述通道处理器接收到的所述一项或更多项功能，创建用于所述通信交换的通道；所述方法进一步包括：使用所述创建的通道：
提供客户端端点；
获取与所述另一实体相关联的至少一个第三方寻址密钥；
提供与所述给定客户端相关联的至少一个客户端寻址密钥；
基于所述客户端和第三方寻址密钥，使用所述通道交换一个或更多个握手消息；
基于握手结果或模式，获取共享密钥；
其中，基于所述共享密钥，对使用所述通道与所述另一实体的所述直接通信进行加密。
38.根据实例36或37所述的方法，其中，所述服务寻址密钥和/或客户端寻址密钥和/或第三方寻址密钥是一个或更多个静态和/或临时密钥。
39.根据实例36至38中任一项所述的方法，其中，所述客户端端点是超文本传输协议(HTTP)应用程序编程接口(API)端点，并且其中，使用安全HTTP(HTTPS)递送所述客户端端点。
40.根据实例36至38中任一项所述的方法，其中，所述客户端端点是统一资源定位符(URL)，所述统一资源定位符(URL)包括在来自所述给定客户端的、使用所述创建的通道发送的消息中。
41.根据实例36至40中任一项所述的方法，其中，所述客户端端点是与所述客户端相关联的别名，所述别名特定于所述客户端并且由基于别名的寻址服务提供，所述寻址服务具有可从定义的或公知的位置访问的机器可读资源，所述机器可读资源包括与所述客户端有关的一项或更多项功能，并且其中，所述别名与用于认证的非对称加密密钥对相关联。
42.根据实例36至41中任一项所述的方法，其中，所述另一实体与相关联的别名相关联，所述别名特定于所述另一实体并且由基于别名的寻址服务提供，所述寻址服务具有可从定义的或公知的位置访问的机器可读资源，所述机器可读资源包括与所述另一实体有关的一项或更多项功能，并且其中，所述别名与用于认证的非对称加密密钥对相关联。
43.根据实例36至42中任一项所述的方法，所述方法进一步包括根据实例17至26中任一项所述的方法。
44.一种计算机实现的方法，所述计算机实现的方法用于处理与区块链相关联的交易，所述方法由与多名矿工中的一名矿工相关联的一个或更多个处理器实现，所述多名矿工以通信方式耦合到实现用于至少一个客户端的通道服务的至少一个通道处理器，所述方法包括以下步骤：
从提交者接收挖掘已完成交易的请求，所述提交者是所述通道处理器或与所述通道服务相关联的客户端；
获取与所述提交者相关联的服务或客户端端点；
获取与所述提交者相关联的至少一个服务或客户端寻址密钥；
提供与所述矿工相关联的至少一个矿工寻址密钥；
获取对一项或更多项功能的访问权限，所述一项或更多项功能使得能够使用通道与所述通道服务进行直接通信。
45.根据实例44所述的方法，其中，所述服务/客户端寻址密钥和/或矿工寻址密钥是一个或更多个静态和/或临时密钥。
46.根据实例44或45中任一项所述的方法，所述方法包括以下步骤：
基于所述服务/客户端和矿工寻址密钥，与通道处理器交换一个或更多个握手消息；
基于握手结果或模式，获取共享密钥；
其中，基于所述共享密钥，对使用所述通道的所述直接通信进行加密。
47.根据实例44至46中任一项所述的方法，其中，所述矿工端点是超文本传输协议(HTTP)应用程序编程接口(API)端点，并且其中使用安全HTTP(HTTPS)提供所述端点。
48.根据实例44至46中任一项所述的方法，其中，所述矿工端点是统一资源定位符(URL)，所述统一资源定位符(URL)包括在来自所述矿工的、使用与所述通道服务相关联的所述一项或更多项功能发送的消息中。
49.根据实例44至48中任一项所述的方法，其中，所述矿工端点是与所述矿工相关联的别名，所述别名特定于所述矿工并且由基于别名的寻址服务提供，所述寻址服务具有可从定义的或公知的位置访问的机器可读资源，所述机器可读资源包括与所述矿工有关的一项或更多项功能，并且其中，所述别名与用于认证的非对称加密密钥对相关联。
50.根据实例44至49中任一项所述的方法，所述方法进一步包括根据实例26所述的方法。
51.一种计算设备，所述计算设备包括处理器和存储器，所述存储器包括可执行指令，由于所述处理器进行的执行，所述可执行指令使得所述设备执行根据实例1至16和27至34中任一项所述的计算机实现的方法，所述计算设备与通道处理器有关。
52.一种计算设备，所述计算设备包括处理器和存储器，所述存储器包括可执行指令，由于所述处理器进行的执行，所述可执行指令使得所述设备执行根据实例17至25和36至43中任一项所述的计算机实现的方法，其中，所述计算设备与客户端有关。
53.一种计算设备，所述计算设备包括处理器和存储器，所述存储器包括可执行指令，由于所述处理器进行的执行，所述可执行指令使得所述设备执行根据实例26和44至50中任一项所述的计算机实现的方法，其中，所述计算设备与矿工有关。
54.一种计算机系统，所述计算机系统包括：
至少一个通道处理器，所述至少一个通道处理器经由通信网络以通信方式耦合到至少一个客户端和至少一名矿工，所述至少一个通道处理器实现用于一个或更多个客户端的通道服务，其中，根据实例51所述的计算设备实现所述至少一个通道处理器；根据实例52所述的计算设备实现所述至少一个客户端；并且根据实例53所述的计算设备实现所述至少一名矿工。
55.一种计算机可读存储介质，其上存储有可执行指令，由于计算机的处理器进行的执行，所述可执行指令使得所述计算机执行根据实例1至50中任一项所述的方法。

Claims (55)

1.一种计算机实现的方法，所述方法用于实现用于消息或交易的通道服务，所述通道服务被提供给一个或更多个客户端，所述方法由通道处理器实现，并且包括以下步骤：
从所述一个或更多个客户端中的给定客户端接收请求，所述请求与所述通道服务有关；
为所述给定客户端创建账户，所述账户具有特定于所述给定客户端的账户标识符和特定于所述账户标识符的访问密钥；
向所述给定客户端提供对一项或更多项功能的访问权限，所述一项或更多项功能使得能够在所述给定客户端与另一实体之间进行直接通信；
其中，所述一项或更多项功能包括：
与用于数据传输的一个或更多个通道有关的通道功能或过程；和/或
与使用所述一个或更多个通道传输的所述数据有关的消息功能或过程。
2.根据权利要求1所述的方法，其中，给定通道与通道标识符相关联，所述给定通道被配置用于与另一实体就与特定类型或主题相关联的数据进行通信。
3.根据权利要求2所述的方法，其中，与所述给定通道相关联的数据包括在一个或更多个消息或交易中。
4.根据前述任一项权利要求所述的方法，其中，所述给定客户端是所述一个或更多个通道的所有者，所述方法还包括以下步骤：为所述一个或更多个通道中的给定通道发布一个或更多个访问令牌，所述一个或更多个访问令牌被配置用于与另一实体进行安全通信，所述一个或更多个访问令牌与所述给定通道或所述给定通道中的给定消息有关。
5.根据前述任一项权利要求所述的方法，其中，所述一项或更多项功能是：为所述给定客户端发布或向所述给定客户端提供的应用程序编程接口(API)，所述API包括用于所述一个或更多个通道的通道API；用于与每个通道或给定通道相关联的数据的消息API；并且其中，所述访问令牌是特定于给定通道或给定消息的API令牌。
6.根据前述任一项权利要求所述的方法，所述方法包括以下步骤：
从所述给定客户端接收请求，所述请求与通道相关联；
基于确定与所述给定客户端有关的所述账户标识符和访问密钥有效，允许所述给定客户端访问所述账户；
基于确定所述请求有效，处理对所述通道的所述请求；
向所述给定客户端发送响应，所述响应包括对与所述请求相关的一个或更多个通道的访问权限；
其中，接收到的所述请求包括以下一个或更多个：
-列出与所述给定客户端的所述账户有关的所述一个或更多个通道的请求；
-为所述账户创建通道的请求；
-删除已标识的通道的请求；
-修改与已标识的通道相关联的属性和/或权限的请求；
-为已标识的通道生成通道访问令牌的请求；
-撤销已标识的通道的通道访问令牌的请求。
7.根据权利要求6所述的方法，其中，所述响应中的所述通道功能包括用于所述账户的JavaScript对象表示法(JSON)-over-超文本传输协议(HTTP)API，使得能够创建和/或管理一个或更多个通道。
8.根据前述任一项权利要求所述的方法，所述方法包括以下步骤：
从所述给定客户端接收请求，所述请求与消息相关联，所述消息与和所述给定客户端的给定通道相关联的数据有关；
基于确定与所述给定客户端有关的所述账户标识符和访问密钥有效，允许所述给定客户端访问所述账户；
基于确定所述请求有效，处理对所述消息的所述请求；
向所述给定客户端发送响应，所述响应包括对与所述请求相关的一个或更多个消息的访问权限；
其中，接收到的所述请求包括以下一个或更多个：
-对所述给定通道中的新消息进行测试的请求；
-检索所述给定通道中的消息的请求；
-标记或标识所述给定通道中的已读或未读消息的请求；
-写入所述给定通道中的消息的请求。
9.根据权利要求8所述的方法，其中，所述响应中的所述消息功能包括用于所述账户的JSON-over-HTTP API，使得所述给定客户端和一个或更多个其他实体能够交换消息，和/或从所述给定通道读取数据和/或向所述给定通道写入数据。
10.根据前述任一项权利要求所述的方法，其中，通道处理器与HTTP API端点相关联，并且其中，基于HTTP传输协议格式接收来自所述给定客户端的所述请求。
11.根据权利要求10所述的方法，其中，所述通道处理器与API转换器相关联，所述API转换器被配置用于执行以下步骤：
以HTTP传输协议格式从所述给定客户端接收所述请求；
将接收到的请求转换为远程过程调用(RPC)格式，并将所述RPC请求发送到所述通道处理器以实现所述接收到的请求；
以RPC格式接收来自所述通道处理器的响应；
使用HTTP传输协议转换要发送到所述给定客户端的所述相应响应。
12.根据前述任一项权利要求所述的方法，其中，所述接收到的请求是包括所述给定客户端的账户标识符或与所述给定客户端的账户标识符相关联的HTTP GET或POST或PUT或PATCH请求。
13.根据前述任一项权利要求所述的方法，其中，所述账户标识符是为给定客户端提供的别名，所述别名特定于所述给定客户端并且由基于别名的寻址服务提供，所述寻址服务具有可从定义的或公知的位置访问的机器可读资源，所述机器可读资源包括与所述给定客户端有关的一项或更多项功能。
14.根据权利要求13所述的方法，其中，所述别名与所述给定客户端的域名相关联。
15.根据前述任一项权利要求所述的方法，所述方法包括以下步骤：为所述给定客户端提供通道服务库，所述通道服务库包括一个或更多个模块，所述一个或更多个模块用于促进与所述给定客户端相关联的所述账户的所述通道功能和/或所述消息功能。
16.根据前述任一项权利要求所述的方法，其中，响应于从所述给定客户端接收与给定通道相关联的已完成消息或交易以提交给区块链，所述方法包括以下步骤：
将所述交易提交给给定矿工；
创建用于与所述给定矿工进行通信的通道；
向所述给定矿工提供对一项或更多项功能的访问权限，所述一项或更多项功能使得能够与所述通道处理器进行直接通信；
使用所述通道从所述给定矿工接收所述已完成交易在区块中的包含证明。
17.一种计算机实现的方法，所述计算机实现的方法用于访问消息或交易的通道服务，所述通道服务被提供给一个或更多个客户端，所述方法由所述一个或更多个客户端中的给定客户端的一个或更多个处理器实现，所述方法包括以下步骤：
发送与所述通道服务有关的请求，所述通道服务由通道处理器实现；
获取为所述给定客户端创建的账户的账户凭证，所述账户凭证包括账户标识符和特定于所述账户标识符的访问密钥；
获取对一项或更多项功能的访问权限，所述一项或更多项功能使得能够在所述给定客户端与另一实体之间进行直接通信，所述一项或更多项功能包括：
与用于数据传输的一个或更多个通道有关的通道功能或过程；和/或
与使用所述一个或更多个通道传输的所述数据有关的消息功能或过程。
18.根据权利要求17所述的方法，所述方法包括以下步骤：
发送与用于所述给定客户端的账户的通道有关的请求；
从所述通道处理器获取响应，所述响应包括对与所述请求相关的一个或更多个通道的访问权限；
其中，所述请求包括以下一个或多个：
-列出与所述给定客户端的所述账户有关的所述一个或更多个通道的请求；
-为所述账户创建通道的请求；
-删除已标识的通道的请求；
-修改与已标识的通道相关联的属性和/或权限的请求；
-为已标识的通道生成通道访问令牌的请求；
-撤销已标识的通道的通道访问令牌的请求。
19.根据权利要求18所述的方法，其中，在所述响应中获取的所述通道功能包括用于所述账户的通道API，所述通道API使得能够创建和/或管理一个或更多个通道。
20.根据权利要求19所述的方法，其中，所述响应包括访问令牌，诸如用于每个通道功能的API令牌。
21.根据权利要求17所述的方法，所述方法包括以下步骤：
发送与消息相关联的请求，所述消息与用于所述给定客户端的账户的给定通道相关联的数据有关；
从所述通道处理器获取响应，所述响应包括对与所述请求相关的一个或更多个消息的访问权限；
其中，所述请求包括以下一个或多个：
-对所述给定通道中的新消息进行测试的请求；
-检索所述给定通道中的消息的请求；
-标记或标识所述给定通道中的已读或未读消息的请求；
-写入所述给定通道中的消息的请求。
22.根据权利要求21所述的方法，其中，所述响应中的所述消息功能包括用于所述账户的消息API，使得所述给定客户端和一个或更多个其他实体能够交换消息，和/或从所述给定通道读取数据和/或向所述给定通道写入数据。
23.根据权利要求22所述的方法，其中，所述响应包括访问令牌，诸如用于每个消息功能的消息API令牌。
24.根据权利要求17至23中任一项所述的方法，所述方法进一步包括：
标识要与其进行通信交换的另一实体；
使用从所述通道处理器接收到的一个或更多个通道功能，创建用于通信的通道；
将与所述通道相关联的一个或更多个访问令牌发送到所述另一实体；
使用从所述通道处理器接收到的用于所述通道的一个或更多个消息功能，向所述通道写入与交易有关的至少一个消息；
将与所述一个或更多个消息相关联的一个或更多个访问令牌发送到所述另一实体；
接收与所述通道中的所述交易有关的至少一个回复消息；
响应于所述通信交换的完成，提供已完成交易以供提交。
25.根据权利要求17至24中任一项所述的方法，所述方法包括以下步骤：接收和/或存储通道服务库，所述通道服务库包括一个或更多个模块，所述一个或更多个模块用于促进从与所述给定客户端相关联的所述账户的所述通道处理器接收到的所述通道功能和/或所述消息功能。
26.一种用于处理与区块链相关联的交易的计算机实现的方法，所述方法由与多名矿工中的给定矿工相关联的一个或更多个处理器实现，所述多名矿工以通信方式耦合到实现用于至少一个客户端的通道服务的至少一个通道处理器，所述方法包括以下步骤：
接收另一实体向所述区块链提交已完成交易的请求；从所述另一实体接收对通道的访问权限，所述通道使得能够与所述另一实体进行直接通信；
进一步地，在区块中挖掘所述已完成交易，使用所述通道发送所述已完成交易的包含证明。
27.一种计算机实现的方法，所述计算机实现的方法用于实现通道服务的寻址，所述通道服务被提供用于消息或交易，所述通道服务被提供给一个或更多个客户端，所述方法由通道处理器实现，并且包括以下步骤：
从所述多个客户端中的给定客户端接收请求，所述请求与所述通道服务有关；
基于确定与所述给定客户端有关的账户标识符和访问密钥有效，为所述客户端提供服务端点；
提供与所述通道服务相关联的至少一个服务寻址密钥；
获取与所述客户端相关联的至少一个客户端寻址密钥；
基于所述接收到的请求，向所述给定客户端提供对一项或更多项功能的访问权限，所述一项或更多项功能使得能够使用用于数据或消息传输的通道在所述给定客户端与另一实体之间进行直接通信。
28.根据权利要求27所述的方法，所述方法包括以下步骤：
接收与给定客户端相关联的已完成消息或交易以提交给所述区块链；
为矿工提供服务端点；
提供与所述通道服务相关联的至少一个服务寻址密钥；
获取与所述矿工相关联的至少一个矿工寻址密钥；
向所述矿工提供对一项或更多项功能的访问权限，所述一项或更多项功能使得能够使用通道与所述通道处理器进行直接通信。
29.根据权利要求27或28中任一项所述的方法，其中，所述服务寻址密钥、客户端寻址密钥和/或矿工寻址密钥是一个或更多个静态和/或临时密钥。
30.根据权利要求27至29中任一项所述的方法，所述方法包括以下步骤：
基于所述服务和客户端/矿工寻址密钥，与客户端/矿工交换一个或更多个握手消息；
获取握手结果或模式；
基于所述握手结果或模式，获取共享密钥；
其中，基于所述共享密钥，对使用所述通道的所述直接通信进行加密。
31.根据权利要求27至30中任一项所述的方法，其中，所述服务端点是超文本传输协议(HTTP)应用程序编程接口(API)端点，并且其中，所述端点使用安全HTTP(HTTPS)递送至所述客户端。
32.根据权利要求27至30中任一项所述的方法，其中，所述服务端点是统一资源定位符(URL)，所述统一资源定位符(URL)包括在对来自所述给定客户端的、与所述通道服务相关联的所述一项或更多项功能的请求的响应中。
33.根据权利要求27至32中任一项所述的方法，其中，所述服务端点是与所述通道服务相关联的别名，所述别名特定于所述通道处理器并且由基于别名的寻址服务提供，所述寻址服务具有可从定义的或公知的位置访问的机器可读资源，所述机器可读资源包括与所述通道处理器有关的一项或更多项功能。
34.根据权利要求33所述的方法，其中，所述别名是已知的或被提供给一个或更多个客户端/矿工，所述别名与用于认证的非对称加密密钥对相关联。
35.根据权利要求27至34中任一项所述的方法，其中，使用根据权利要求1至16中任一项所述的方法实现所述通道服务。
36.一种计算机实现的方法，所述计算机实现的方法用于使用用于消息或交易的通道服务来实现通道寻址，所述通道服务被提供给一个或更多个客户端，所述方法由所述一个或更多个客户端中的给定客户端的一个或更多个处理器实现，所述方法包括以下步骤：
发送与所述通道服务有关的请求，所述通道服务由通道处理器实现；
获取与所述通道服务相关联的服务端点；
获取与所述通道服务相关联的至少一个服务寻址密钥；
提供与所述给定客户端相关联的至少一个客户端寻址密钥；
获取对一项或更多项功能的访问权限，所述一项或更多项功能使得能够使用用于数据或消息传输的通道在所述给定客户端与另一实体之间进行直接通信。
37.根据权利要求36所述的方法，所述方法包括以下步骤：
标识要与其进行通信交换的另一实体；
使用从所述通道处理器接收到的所述一项或更多项功能，创建用于所述通信交换的通道；所述方法进一步包括：使用所述创建的通道：
提供客户端端点；
获取与所述另一实体相关联的至少一个第三方寻址密钥；
提供与所述给定客户端相关联的至少一个客户端寻址密钥；
基于所述客户端和第三方寻址密钥，使用所述通道交换一个或更多个握手消息；
基于握手结果或模式，获取共享密钥；
其中，基于所述共享密钥，对使用所述通道与所述另一实体的所述直接通信进行加密。
38.根据权利要求36或37所述的方法，其中，所述服务寻址密钥和/或客户端寻址密钥和/或第三方寻址密钥是一个或更多个静态和/或临时密钥。
39.根据权利要求36至38中任一项所述的方法，其中，所述客户端端点是超文本传输协议(HTTP)应用程序编程接口(API)端点，并且其中，使用安全HTTP(HTTPS)递送所述客户端端点。
40.根据权利要求36至38中任一项所述的方法，其中，所述客户端端点是统一资源定位符(URL)，所述统一资源定位符(URL)包括在来自所述给定客户端的、使用所述创建的通道发送的消息中。
41.根据权利要求36至40中任一项所述的方法，其中，所述客户端端点是与所述客户端相关联的别名，所述别名特定于所述客户端并且由基于别名的寻址服务提供，所述寻址服务具有可从定义的或公知的位置访问的机器可读资源，所述机器可读资源包括与所述客户端有关的一项或更多项功能，并且其中，所述别名与用于认证的非对称加密密钥对相关联。
42.根据权利要求36至41中任一项所述的方法，其中，所述另一实体与相关联的别名相关联，所述别名特定于所述另一实体并且由基于别名的寻址服务提供，所述寻址服务具有可从定义的或公知的位置访问的机器可读资源，所述机器可读资源包括与所述另一实体有关的一项或更多项功能，并且其中，所述别名与用于认证的非对称加密密钥对相关联。
43.根据权利要求36至42中任一项所述的方法，所述方法进一步包括根据权利要求17至26中任一项所述的方法。
44.一种计算机实现的方法，所述计算机实现的方法用于处理与区块链相关联的交易，所述方法由与多名矿工中的一名矿工相关联的一个或更多个处理器实现，所述多名矿工以通信方式耦合到实现用于至少一个客户端的通道服务的至少一个通道处理器，所述方法包括以下步骤：
从提交者接收挖掘已完成交易的请求，所述提交者是所述通道处理器或与所述通道服务相关联的客户端；
获取与所述提交者相关联的服务或客户端端点；
获取与所述提交者相关联的至少一个服务或客户端寻址密钥；
提供与所述矿工相关联的至少一个矿工寻址密钥；
获取对一项或更多项功能的访问权限，所述一项或更多项功能使得能够使用通道与所述通道服务进行直接通信。
45.根据权利要求44所述的方法，其中，所述服务/客户端寻址密钥和/或矿工寻址密钥是一个或更多个静态和/或临时密钥。
46.根据权利要求44或45中任一项所述的方法，所述方法包括以下步骤：
基于所述服务/客户端和矿工寻址密钥，与通道处理器交换一个或更多个握手消息；
基于握手结果或模式，获取共享密钥；
其中，基于所述共享密钥，对使用所述通道的所述直接通信进行加密。
47.根据权利要求44至46中任一项所述的方法，其中，所述矿工端点是超文本传输协议(HTTP)应用程序编程接口(API)端点，并且其中使用安全HTTP(HTTPS)提供所述端点。
48.根据权利要求44至46中任一项所述的方法，其中，所述矿工端点是统一资源定位符(URL)，所述统一资源定位符(URL)包括在来自所述矿工的、使用与所述通道服务相关联的所述一项或更多项功能发送的消息中。
49.根据权利要求44至48中任一项所述的方法，其中，所述矿工端点是与所述矿工相关联的别名，所述别名特定于所述矿工并且由基于别名的寻址服务提供，所述寻址服务具有可从定义的或公知的位置访问的机器可读资源，所述机器可读资源包括与所述矿工有关的一项或更多项功能，并且其中，所述别名与用于认证的非对称加密密钥对相关联。
50.根据权利要求44至49中任一项所述的方法，所述方法进一步包括根据权利要求26所述的方法。
51.一种计算设备，所述计算设备包括处理器和存储器，所述存储器包括可执行指令，由于所述处理器进行的执行，所述可执行指令使得所述设备执行根据权利要求1至16和27至34中任一项所述的计算机实现的方法，所述计算设备与通道处理器有关。
52.一种计算设备，所述计算设备包括处理器和存储器，所述存储器包括可执行指令，由于所述处理器进行的执行，所述可执行指令使得所述设备执行根据权利要求17至25和36至43中任一项所述的计算机实现的方法，其中，所述计算设备与客户端有关。
53.一种计算设备，所述计算设备包括处理器和存储器，所述存储器包括可执行指令，由于所述处理器进行的执行，所述可执行指令使得所述设备执行根据权利要求26和44至50中任一项所述的计算机实现的方法，其中，所述计算设备与矿工有关。
54.一种计算机系统，所述计算机系统包括：
至少一个通道处理器，所述至少一个通道处理器经由通信网络以通信方式耦合到至少一个客户端和至少一名矿工，所述至少一个通道处理器实现用于一个或更多个客户端的通道服务，其中，根据权利要求51所述的计算设备实现所述至少一个通道处理器；根据权利要求52所述的计算设备实现所述至少一个客户端；并且根据权利要求53所述的计算设备实现所述至少一名矿工。
55.一种计算机可读存储介质，其上存储有可执行指令，由于计算机的处理器进行的执行，所述可执行指令使得所述计算机执行根据权利要求1至50中任一项所述的方法。
CN202080037815.0A 2019-05-21 2020-05-21 计算机实现的系统和方法 Pending CN113939839A (zh)

Applications Claiming Priority (5)

Application Number Priority Date Filing Date Title
GBGB1907180.2A GB201907180D0 (en) 2019-05-21 2019-05-21 Computer-implemented system and method
GB1907180.2 2019-05-21
GBGB2002285.1A GB202002285D0 (en) 2020-02-19 2020-02-19 Computer-implemented system and method
GB2002285.1 2020-02-19
PCT/IB2020/054837 WO2020234824A1 (en) 2019-05-21 2020-05-21 Computer-implemented system and method

Publications (1)

Publication Number Publication Date
CN113939839A true CN113939839A (zh) 2022-01-14

Family

ID=70918754

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202080037815.0A Pending CN113939839A (zh) 2019-05-21 2020-05-21 计算机实现的系统和方法

Country Status (6)

Country Link
US (1) US20220303258A1 (zh)
EP (1) EP3973491A1 (zh)
JP (1) JP2022534023A (zh)
KR (1) KR20220011165A (zh)
CN (1) CN113939839A (zh)
WO (1) WO2020234824A1 (zh)

Families Citing this family (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US11599858B2 (en) * 2020-05-07 2023-03-07 International Business Machines Corporation Blockchain settlement network
US11676117B2 (en) 2020-05-07 2023-06-13 International Business Machines Corporation Blockchain compliance verification network
CN116802661A (zh) * 2021-01-13 2023-09-22 维萨国际服务协会 基于令牌的链外交互授权
CN117941322A (zh) * 2021-09-22 2024-04-26 恩晨特许股份公司 基于区块链的交易协议
US20230144774A1 (en) * 2021-11-11 2023-05-11 Gridplus, Inc. System for secure multi-protocol processing of cryptographic data
US20230222498A1 (en) * 2022-01-12 2023-07-13 Project Noa, Inc. Physical action blockchain
US20240054473A1 (en) * 2022-08-15 2024-02-15 Mastercard International Incorporated Methods and systems for extending installment options
CN116452198B (zh) * 2023-06-14 2023-09-01 南京能可瑞科技有限公司 一种充电桩离线授权和计费方法及系统

Family Cites Families (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20020116485A1 (en) * 2001-02-21 2002-08-22 Equipe Communications Corporation Out-of-band network management channels
US6976174B2 (en) * 2001-01-04 2005-12-13 Troika Networks, Inc. Secure multiprotocol interface
US8839376B2 (en) * 2012-06-29 2014-09-16 Cable Television Laboratories, Inc. Application authorization for video services
US11182787B2 (en) * 2017-11-07 2021-11-23 Liquidchain Ag System and method for scaling blockchain networks with secure off-chain payment hubs
US11238181B2 (en) * 2018-02-14 2022-02-01 Roku, Inc. Production console authorization permissions
WO2020040922A1 (en) * 2018-08-24 2020-02-27 Slack Technologies, Inc. Methods, apparatuses and computer program products for a group-based communication system interacting with remote resources for remote data objects

Also Published As

Publication number Publication date
KR20220011165A (ko) 2022-01-27
EP3973491A1 (en) 2022-03-30
US20220303258A1 (en) 2022-09-22
WO2020234824A1 (en) 2020-11-26
JP2022534023A (ja) 2022-07-27

Similar Documents

Publication Publication Date Title
Cruz et al. RBAC-SC: Role-based access control using smart contract
CN113939839A (zh) 计算机实现的系统和方法
CN110147994B (zh) 一种基于同态加密的区块链的即时执行方法
Lundkvist et al. Uport: A platform for self-sovereign identity
US9565180B2 (en) Exchange of digital certificates in a client-proxy-server network configuration
US7350076B1 (en) Scheme for device and user authentication with key distribution in a wireless network
CN111431713B (zh) 一种私钥存储方法、装置和相关设备
JP2019511147A (ja) デジタルコンテンツの制御及び配信のためのブロックチェーンにより実施される方法
US9100171B1 (en) Computer-implemented forum for enabling secure exchange of information
US20130205133A1 (en) Strongly authenticated, third-party, out-of-band transactional authorization system
JP2023500259A (ja) ブロックチェーントランザクションを使用した通信プロトコル
US20170288866A1 (en) Systems and methods of creating a distributed ring of trust
US11367065B1 (en) Distributed ledger system for electronic transactions
KR20200133881A (ko) 분산 환경에서의 신원 인증 방법
JP2023535013A (ja) 量子安全支払いシステム
Abdelrazig Abubakar et al. Blockchain-based identity and authentication scheme for MQTT protocol
JP4807944B2 (ja) 秘密認証データの知識を必要としないチャレンジ−ベースの認証
CN114127764A (zh) 与分布式账本关联的目的地寻址
TW202139668A (zh) 用於與區塊鏈相關聯之多個服務之平台
CN114982195A (zh) 利用区块链事务的请求和响应协议
Sanyal et al. A multifactor secure authentication system for wireless payment
US20230412404A1 (en) Systems and methods for mitigating network congestion on blockchain networks by supporting blockchain operations through off-chain interactions
US20230245111A1 (en) Systems and methods for requesting secure, encrypted communications across distributed computer networks for authorizing use of cryptography-based digital repositories in order to perform blockchain operations in decentralized applications
US20230246822A1 (en) Systems and methods for providing secure, encrypted communications across distributed computer networks by coordinating cryptography-based digital repositories in order to perform blockchain operations in decentralized applications
US20230246817A1 (en) Systems and methods for generating secure, encrypted communications across distributed computer networks for authorizing use of cryptography-based digital repositories in order to perform blockchain operations in decentralized applications

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination