CN115699053A - 用于加速分布式账本和用于数字钱包部署的系统 - Google Patents

Abstract

根据本发明的第一方面，提供一种用于支持使用分布式账本记录交易数据的服务的系统，所述系统包括块产生节点，所述块产生节点包括被配置成将新数据块记录到所述分布式账本中的处理器布置，所述处理器布置被配置成执行计算机可读程序代码以：接收包括用于记录到所述分布式账本的新数据块中的交易数据的数据包，所述数据包携带签名布置，所述签名布置在外部执行；证实接收到的数据包的所述签名布置；确定贯穿所述系统中也已经接收到所述数据包并证实其签名布置的足够数量的其它块产生节点是否存在共识；以及响应于确认存在所述共识，将来自所述接收到的数据包的所述交易数据记录到所述分布式账本的新数据块中。

Description

用于加速分布式账本和用于数字钱包部署的系统

技术领域

本文公开一种加速分布式账本(distributed ledger)的更新的系统。还公开促进将数字钱包嵌入物联网(IoT)装置中以供移动网络运营商使用的装置。

背景技术

去中心化账本技术(decentralised ledger technology)由于其提供可用于部署内置智能合约的实用型令牌架构的应用灵活性，近年来吸引了大量关注。

然而，区块链支持的交易受到多种限制。当前市场的分布式账本解决方案(例如，EOS)要求，与将新数据块记录到分布式账本中相关的所有任务都在具有X86 CPU的一台服务器上完成。该服务器很容易因CPU性能和节点到节点的网络延迟而成为瓶颈。

另外，由于移动网络运营商网络的分层结构，针对这些移动网络运营商采用当前市场的分布式账本解决方案是低效的。

本发明力图解决上述缺点并提供例如通过移动运营商的分布式边缘基础设施更有效地利用区块链技术的系统。

发明内容

根据本发明的第一方面，提供一种用于支持使用分布式账本记录交易数据的服务的系统，所述系统包括块产生节点，所述块产生节点包括被配置成将新数据块记录到所述分布式账本中的处理器布置，所述处理器布置被配置成执行计算机可读程序代码以：接收包括用于记录到所述分布式账本的新数据块中的交易数据的数据包，所述数据包携带签名布置，所述签名布置在外部执行；证实接收到的数据包的所述签名布置；确定贯穿所述系统中也已经接收到所述数据包并证实其签名布置的足够数量的其它块产生节点是否存在共识；以及响应于确认存在所述共识，将来自所述接收到的数据包的所述交易数据记录到所述分布式账本的新数据块中。

根据本发明的第二方面，提供一种用于蜂窝通信网络的无线装置，所述无线装置包括：收发器；安全元件；以及与所述收发器和所述安全元件通信的处理器，所述处理器被配置成：基于用于向移动网络运营商网络识别(identify)所述无线装置的订户身份，将密钥对存储在安全元件中；使用所述密钥对的私钥，生成与传出数据一起使用的签名；以及经由所述收发器传输携带所述签名的所述传出数据。

根据本发明的第三方面，提供一种被配置成传输指令的服务部署服务器，所述指令当在无线装置中执行时将所述无线装置配置成：基于用于向移动网络运营商网络识别所述无线装置的订户身份，将密钥对存储在所述无线装置的安全元件中；以及使用所述密钥对的私钥，生成与传出数据一起使用的签名以进行传输。

根据本发明的第四方面，提供一种存储计算机程序的计算机可读非瞬时性介质(non-transitory medium)，其中所述计算机程序使处理器执行：基于用于向移动网络运营商网络识别所述无线装置的订户身份，将密钥对存储在所述无线装置的安全元件中；以及使用所述密钥对的私钥，生成与传出数据一起使用的签名以进行传输。

附图说明

仅作为示例，参考附图，本文描述了本发明的代表性实施例，其中：

图1示出实施通过SaaS(软件即服务)管理控制台访问的分布式账本的系统的示意图。

图2示出图1的系统的操作的示意性概述。

图3示出图2的块产生节点的操作的示意图。

图4示出图2的加速节点在第一情境下的操作。

图5示出图2的加速节点在第二情境下的操作。

图6和7各自示出由图2的加速节点执行的验证和提交过程的示意图。

图8示出总结当在分布式账本中创建新数据块时由图2的API节点、加速节点和块产生节点执行的功能的示意图。

图9示出使用基于容器的服务对加速节点升级或重新编程。

图10示出根据BFT(拜占庭容错，Byzantine fault tolerance)部署图2的系统。

图11是提供促进在不同移动网络运营商(MNO)中部署电子订户身份模块(eSIM)的管理控制台的概述的示意图。

图12示出使用服务部署服务器进行eSIM的远程配置。

图13示出当使用属于MNO的服务部署服务器设置安全元件时发生的阶段序列。

图14示出描绘服务器机房、边缘数据中心、中心局、核心网络、区域数据中心和全球数据中心的往返时间(RRT)延迟时间的图。

具体实施方式

在以下描述中，参考附图描述各种实施例，其中贯穿不同视图的相同附图标记一般指代相同部分。

图1示出实施通过SaaS(软件即服务)管理控制台104访问的分布式账本(DLT)102的系统100的示意图。DLT 102在多址边缘计算(multi-access edge computing，MEC)节点106处维护。每个多址边缘计算节点106位于由移动网络运营商的基站108支持的蜂窝覆盖区域内，例如与基站108相邻或托管在小型数据中心/中心局环境中。移动网络运营商是指有权在分配的频谱内进行广播的任何电信公司，其中基站提供在蜂窝网络中创建小区的基础设施。因此，基站允许移动网络运营商在分配的频谱上进行无线数据通信并且还具有到由基站服务的核心网络的网关，核心网络是互连的计算机系统的一部分，例如因特网。

多址边缘计算节点106靠近基站108或连接到小型数据中心或中心局。

分布式账本102是存储被监视交易的条目的记录的数据库，其中多址边缘计算节点106中的每一个托管一个复制。在IoT应用程序的背景下，如果满足某些条件，则可以由IoT装置自身自动发起交易(即机器对机器或M2M)；或者可能需要人工干预，例如在一端有操作员操作IoT装置(机器对人或M2H)或在每一端有操作员操作IoT装置(人对人，H2H)。分布式账本102基本上存储链式数据块，所述链式数据块记录从第一个交易到最近一个交易期间的所有权转移，使得链式数据块提供共享账本功能。其数据结构是指向反向链接的交易块的哈希指针(hash pointer)。每个块可通过哈希识别，其中哈希引用前一块。分布式账本102还被同步，因为当其中一个账本被更新以将新交易的数据记录到过去的交易数据中时，其托管的多址边缘计算节点106检查更新后的账本是否与托管在其它多址边缘计算节点106中的账本达成共识，并用相同的新交易数据进行更新。当至少大多数其它多址边缘计算节点106与更新后的账本一致时，实现机器对机器证实。传统分布式账本是块产生节点就其输出数据块上所做的工作证实来自其它块产生节点的签名的结果，与传统分布式账本不同，分布式账本102是由块产生节点达成接收具有在外部执行的足够签名的数据块的共识的结果。将参考图2到7更详细地描述分布式账本102中使用的共识。

SaaS管理控制台104是允许企业经由DLT 102部署所有IoT相关服务的基于云的软件。SaaS管理控制台104充当企业与移动运营商网络基础设施之间的代理，其经由应用程序编程接口(API)连接到移动网络运营商OSS(操作支持系统)和BSS(业务支持系统)管理控制台110。由此，可以通过其网络基础设施无缝地发起、配置和处理服务。

SaaS管理控制台104的功能包含企业能够：

·经由与移动网络运营商和银行监管机构两者的API提供AML(反洗钱)/KYC(了解您的客户)证实

·为企业IoT装置远程部署、激活和自动化由例如数字钱包等eSIM(电子订户标识模块)技术促进的服务

·通过在多址边缘计算MEC节点106中使用指定处理器，例如FPGA(现场可编程门阵列)/ASIC(专用集成电路)芯片，执行加速和增加安全性服务。以下将更详细地解释执行加速。

·以令牌/积分计费，令牌/积分可以转换为法定货币(美元、欧元、人民币等)，反之亦然

·通过MEC节点(选择所需的计算、存储和网络资源)在网络边缘部署(协调和管理应用程序(App)和去中心化应用程序/分布式账本应用程序(DApp))，并选择地理位置

·为各个行业的IoT装置创建智能合约模板并部署智能合约。智能合约是指数字合约，所述合约是其条款和条件被编程为计算机代码并在分布式账本102上存储和复制的合约。

·用于构建DApp、智能合约、插件、API集成、SDK下载和集成现有App的开发工具

·追踪和跟踪DLT 102上的智能合约交易的历史记录以允许(数据计算、预测分析、审计跟踪)生成报告

·创建购买、销售和交换在DLT 102上运行的服务的市场地点

MNO(移动网络运营商)的OSS/BSS(操作支持系统/业务支持系统)管理控制台110促进维护网络运营的服务框架。OSS/BSS管理控制台110的功能的非穷尽列表包含：

·管理和部署利用DLT 102的服务(静态注册、动态注册、智能合约、支付交易、任何区块链作为服务的计费等)

·管理和部署移动网络运营商MEC节点

·管理和部署DApp/App(例如部署/升级/补片)

·管理和部署eSIM

·为企业IaaS(基础设施即服务)、PaaS(平台即服务)或SaaS管理和部署边缘云服务

从图1应了解，移动网络运营商MEC(x86服务器)架构包含用于IoT或企业解决方案的边缘云服务。其MEC节点(106、112)提供计算、存储和联网能力。所有MEC节点(106、112)都具有CPU，但一些可以包含GPU(图形处理单元)或FPGA芯片，以处理计算密集型服务。CPU设计用于多用途工作负载。如果其CPU过载，可以将特定DLT任务卸载到其GPU或FPGA固件上。这释放了CPU工作负载容量，从而改进成本和效率两者。这种利用使得将新数据块记录到DLT 102中所需的处理在多个指定多址边缘计算MEC节点106上分布。被称为加速节点的这些指定多址边缘计算MEC节点106执行加速节点中的每一个处理的交易数据的聚合。在此数据聚合中，将类似任务分组。然后利用这些加速节点中的每一个中的并行计算能力(例如，通过使用机载FPGA、ASIC或GPU)来处理分组任务，从而提高服务处理吞吐量(TPS)。这些加速节点中的每一个负责的任务可以是动态分配的，而在加速节点内运行的应用程序可以例如通过软件更新远程地进行升级。关于图2到7，将更详细地解释加速能力以及将新数据块记录到DLT 102中。

图2示出用于支持使用分布式账本记录交易数据的服务的系统200的示意图。

系统200具有与加速节点202A、202B和202C通信的块产生节点204。加速节点202A、202B和202C中的每一个又与API节点通信，尽管仅示出了与加速节点202A通信的API节点a1、a2和a3以及与加速节点202C通信的API节点c1、c2。

系统200中使用的分布式账本是通过OSS/BSS 110访问的图1的分布式账本102。OSS/BSS 110托管于管理节点270上。管理节点270具有处理器布置，所述处理器布置被配置成执行计算机可读程序代码以：支持一个或多个控制台提供OSS/BSS 110以托管管理分布式账本102的操作的命令；以及向块产生节点204传输272命令以供执行。OSS/BSS 110还可以用于传输274控制加速节点202A、202B和202C的操作的命令。另外，如上文所提及，OSS/BSS 110为操作IoT装置的企业客户端提供了查询分布式账本102的接口。作为将OSS/BSS110托管在专用终端中的替代方案，可以将OSS/BSS 110托管在块产生节点204中，其中所述块产生节点204可以支持一个或多个控制台提供OSS/BSS 110托管管理分布式账本102的操作的命令。

块产生节点204的作用是在分布式账本102中生成块。在一个实施方案中，块产生节点204部署在不限于边缘数据中心、中心局、核心网络、区域数据中心或全球数据中心的位置。如图14所示，边缘数据中心与无线终端接入点之间的往返时间(RRT)延迟约为5至10ms。中心局和区域数据中心与无线终端接入点之间的RRT延迟约为10至30ms。核心网络和全球数据中心与无线终端接入点之间的RRT延迟约为30至50ms。尽管图2中仅示出一个块产生节点204，但其总数量由用于将新数据块记录到分布式账本102中的共识算法决定。例如，如果采用BFT(拜占庭容错)，则以三的倍数部署块产生节点204。应了解，可能有各种其它共识算法。

块产生节点204具有被配置成将新数据块记录到分布式账本102中的处理器布置。合适的处理器布置包含由执行必要的算术和逻辑运算以执行编码指令的单个处理器或一组处理器形成的中央处理单元(CPU)，所述编码指令涉及分布式账本102的管理。因此，处理器布置可以是根据多址边缘计算节点的标准技术规范的库存处理器。处理器布置还可以包含配置有适合于将数据块部署到分布式账本102中的逻辑分区的专用处理器。应了解，对块产生节点204的任何提及通常是指其处理器布置的操作。

下文描述在接收到数据包206a时块产生节点204的操作序列。应了解，类似的操作序列适用于当块产生节点204接收到数据包206b或206c时。参考图2和3两者，块产生节点204被配置成接收包括用于记录到分布式账本102的新数据块中的交易数据SubBlocka的数据包206a。也就是说，交易数据SubBlocka最终成为分布式账本102的新数据块的内容。新数据块的其它内容可以包含其它交易数据，例如来自其相应数据包206b和206c的SubBlockb和SubBlockc。

块产生节点204分析数据包206a是否携带交易数据SubBlocka的签名布置208a。虽然图3示出签名布置208a被附加到交易数据SubBlocka，但它也可以作为例如数据包头出现在数据包206a的另一位置。

检测到此签名布置208a通知块产生节点204交易数据SubBlocka已经被一个或多个外部节点(例如，图2的加速节点202A、202B和202C中的一个或多个)预处理，其中此外部预处理将交易数据SubBlocka组织成与进入分布式账本102兼容的格式。兼容格式表明接收到的数据包206a中的交易数据SubBlocka已经历以下一个或多个过程：通过分布式账本102使用的算法进行哈希(hashing)；重新布置成分布式账本102所使用的布局；以及认证到分布式账本102所要求的级别(例如，识别已处理数据包206a的节点)。处于兼容格式的交易数据SubBlocka产生分布式账本102容易采用的数据结构。这种数据结构是通过执行数据聚合而实现的，数据聚合使得交易数据SubBlocka被授予签名布置208a。由加速节点202A、202B和202C中的一个或多个执行的数据聚合经历被分组以进行处理的类似任务。稍后将结合加速节点202A、202B和202C的操作更详细地描述此数据聚合。

使交易数据SubBlocka由一个或多个外部节点预处理将是有利的，因为绕过了块产生节点204原本将必须执行的其对应任务。例如，块产生节点204不需要将存在于新数据块中的每串交易数据进行哈希或将交易数据分组为子块，从而减轻了如果块产生节点204必须执行此类哈希和整理时所需的计算密集的步骤。

块产生节点204还证实(参考图3的p.1)由接收到的数据包206a携带的签名布置208a。执行此证实是因为块产生节点204与加速节点202A、202B和202C中的一个或多个通信并监控其输出。如果签名布置208a要求存在两个签名(验证签名VSa和提交签名CSb)，则块产生节点204执行的证实是检查签名VSa与CSb是否都存在。根据此类证实程序，由加速节点202A、202B和202C中的一个或多个输出的仅携带验证签名VSa(即，不存在提交签名CSb)的数据包将无法通过由块产生节点204执行证实，使得块产生节点204将忽略此类数据包。如果由加速节点202A、202B和202C中的一个或多个输出的数据包同时携带签名VSa和CSb(即，例如数据包206a)，则签名布置208a被成功证实。因而，由块产生节点204关于签名布置208a执行的证实取决于：i)分布式账本102对签名布置208a施加的准则；ii)由外部节点(例如，加速节点202A、202B和202C中的一个或多个)在将签名布置208a授予其输出交易数据时执行的处理；或这两者。概括来说，验证签名VSa、VSb、VSc和提交签名CSa、CSb和CSc中的每一个反映了赋予其相应交易数据SubBlocka、SubBlockb和SubBlockc的信任度量。稍后结合加速节点202A、202B和202C的操作更详细地描述验证签名和提交签名。

在图3的p.1处成功证实签名布置208a之后，块产生节点204确定在系统200中的其它块产生节点之间是否存在共识。此共识是从块产生节点204向系统200中的其它块产生节点询问是否有足够数量的块产生节点正在接收数据包206a并且已经以与块产生节点204相同的方式证实了数据包206a的签名布置208a来确定的。然后，响应于确认存在共识，将交易数据SubBlocka记录到分布式账本102的新数据块中。随着在确定共识时分布式账本102所采用的格式的交易数据的循环，使用标准化协议来处理交易数据，因为块产生节点遵循类似的一组处理任务来执行共识。这避免了例如必须将交易数据SubBlocka组织成正确序列之类的冗余任务。

参考p.2到p.5更详细地描述块产生节点用于执行共识并在分布式账本102中记录新数据块的一种可能方法。

块产生节点204(参考p.2)生成数据分组210，所述数据分组包含成功证实的数据包206a、206b和206c(包含其相应验证签名VSa、VSb、VSc和提交签名CSa、CSb和CSc)。任选地，块产生节点204被配置成在将新数据块记录到分布式账本中时包含来自最后一个数据包的交易数据，所述最后一个数据包是具有验证签名和提交签名两者的最近接收到的数据包。然后，块产生节点204将其签名S附加到数据分组210。将广播所得数据块(参考p.3)以与其它块产生节点达成共识。

其它块产生节点也将对其分别接收到的数据包执行由块产生节点204完成的相同的证实程序(上文关于p.1所描述)。如果足够数量的其它块产生节点也获得相同的数据分组210，则在块产生节点204与所述其它块产生节点之间达成共识。在各种实施例中，足够数量是指66.7％。然后，将块n记录到分布式账本102中。接着可以记录块n之后的新数据块(块n+1，参考p.4)。

在p.5，参与确定共识的任何一个块产生节点通过系统200广播关于分布式账本102的更新，其由其它块产生节点和加速节点202A、202B和202C接收。

由相应数据包206a、206b和206c中的每一个携带的签名布置208a、208b和208c在外部执行，即，它们并非由块产生节点204完成。签名布置208a、208b和208c由各自已经连续地签名的交易数据SubBlocka、SubBlockb和SubBlockc产生。对每个交易数据SubBlocka、SubBlockb和SubBlockc执行的连续签名由不同的外部节点执行。返回图2，适合执行此连续验证的外部节点是加速节点202A、202B和202C。

加速节点202A、202B和202C的作用是通过承担将新数据块记录到分布式账本102中所需的处理工作的一部分来加速分布式账本102。加速节点202A、202B和202C中的每一个连接到至少一个API节点，其中图2仅示出连接到加速节点202A的API节点a1、a2和a3以及连接到加速节点202C的API节点c1、c2。在一个实施方案中，加速节点202A、202B和202C中的每一个部署在不限于服务器机房或边缘数据中心的位置。如图14所示，服务器机房与无线终端接入点之间的往返时间(RRT)延迟小于5ms。边缘数据中心与无线终端接入点之间的RRT延迟约为5至10ms。虽然未示出，但加速节点202A、202B和202C也可以部署在中心局、区域数据中心或全球数据中心中。中心局和区域数据中心与无线终端接入点之间的RRT延迟约为10至30ms。核心网络和全球数据中心与无线终端接入点之间的RRT延迟约为30至50ms。

连接到块产生节点204的加速节点的总数量由用于将新数据块记录到分布式账本102中的共识算法决定。例如，如果采用BFT(拜占庭容错)，则以三的倍数部署加速节点202A、202B和202C，如图2所示。应了解，可能有各种其它共识算法。

加速节点202A，202B和202C中的每一个具有被配置成格式化交易数据以作为新数据块记录到分布式账本102中的处理器布置。合适的处理器布置包含由单个处理器或一组处理器形成的中央处理单元(CPU)，其执行必要的算术和逻辑运算以执行编码指令，所述编码指令涉及格式化交易数据以作为新数据块记录到分布式账本102中。因此，处理器布置可以是根据多址边缘计算节点的标准技术规范的库存处理器(stock processor)。处理器布置还可以包含配置有适合于执行特定任务以提高服务处理吞吐量(service processingthroughput，TPS)的逻辑分区的专用处理器(例如，FPGA或ASIC芯片；或GPU)。应了解，对加速节点202A，202B和202C的任何提及通常是指其处理器布置的操作。

每个加速节点202A、202B和202C中的两个特征有助于它们加速由块产生节点204维护的分布式账本102的作用。第一特征使加速节点202A、202B和202C中的每一个验证其接收到的交易数据。在此验证期间，加速节点202A、202B和202C根据格式化交易数据以与分布式账本102兼容所需的处理对交易数据进行分组。然后，利用并行计算能力来处理分组的交易数据。第二特征使加速节点202A、202B和202C中的一个证实加速节点202A、202B和202C中另一个的验证结果。在此证实期间，加速节点202A、202B和202C中的一个交叉检查加速节点202A、202B和202C中的另一个对其接收到的交易数据执行的验证结果。执行此证实以建立信任，因为账本102是分布式的，并且没有中央机构来决定系统200中任何参与者的账本记录是否正确。

下文描述加速节点202A关于第一特征的操作。应了解，其它加速节点202B和202C以类似的方式关于此第一特征进行操作。

加速节点202A从API节点a1、a2和a3接收交易数据(txa1至txa7)，所述交易数据最终由块产生节点204作为新数据块记录到分布式账本102中。

API节点a1、a2和a3的作用是例如从在工厂250、收费站252和充电站254等位置操作的IoT装置收集交易数据(txa1至txa7)。如果交易数据(txa1至txa7)是由具有签名生成能力，例如具备eSIM(电子订户身份模块)的IoT装置执行的交易产生，则所述交易数据(txa1至txa7)将被签名。然而，API节点a1、a2和a3也能够支持由不具有签名生成能力的IoT装置产生的交易数据(txa1至txa7)。

API节点a1、a2和a3预处理其收集的交易数据(txa1至txa7)。在一个实施方案中，执行的预处理包含：将交易数据(txa1至txa7)整理到数据包220、222和224；确保数据包220、222和224中存在数据完整性(例如，没有通信错误)；为数据包220、222和224中的每一个生成哈希摘要；以及任选地对其分别创建的数据包220、222和224应用其数字签名。加速节点202A检查哈希以确认数据包220、222和224的完整性以及API节点a1、a2和a3的数字签名，稍后将对这两者进行描述。在一个实施方案中，API节点a1、a2和a3部署在服务器机房中，但也有可能在其它位置。如图14所示，服务器机房与无线终端接入点之间的往返时间(RRT)延迟小于5ms。每个API节点a1、a2和a3连接到至少一个5G无线电接入点212，每个API节点通过所述接入点获得交易数据(txa1至txa7)。这使得传输交易数据(txa1至txa7)的IoT装置214、216和218与API节点a1、a2和a3之间的定时延迟尽可能短。与块产生节点204和加速节点202A、202B和202C相比，对API节点a1、a2和a3的数量没有限制。

加速节点202A从由API节点a1、a2和a3传输的数据包220、222和224中提取交易数据(txa1至txa7)。然后，加速节点202A根据处理接收到的交易数据(txa1至txa7)所需的任务来组织所述接收到的交易数据(txa1至txa7)。例如，如果交易数据(txa1至txa7)是与以下数据相关的任何一个或多个数据：提供交易数据不变性和发送者身份的不可否认性的数字签名、智能合约签署和零知识证明(ZKP)，则加速节点202A将需要处理数字签名的任务的数据组织成第一组；将需要处理智能合约签署的任务的数据组织成第二组；以及将需要处理ZKP的任务的数据组织成第三组。这是因为加速节点202A为了处理这些数据组中的每一组而执行的任务需要特定于三个组中的每一组中的数据的格式的步骤序列。

加速节点202A将组织的交易数据(即，已经经历这种组织的交易数据(txa1至txa7))分配给被配置成实行执行所需处理任务所需的步骤的其处理器布置的指定分区。这些指定分区中的每一个是指适合于执行特定任务以提高服务处理吞吐量(TPS)的加速节点202A的处理器布置的逻辑分区。

参考上文在图3中描述的数据包206a、206b和206c，处理器布置的指定分区被配置成执行的任务的示例包含：使得生成在由这些数据包206a、206b和206c携带的签名布置208a、208b、208c中发现的验证签名VSa、VSb、VSc和提交签名CSa、CSb和CSc的任务。然后，这些指定分区中的每一个输出包括处理后的交易数据的数据包。

然后，加速节点202A对由其处理器布置的指定分区输出的每个数据包进行签名，其中对其内容的处理是由相应指定分区完成的。在系统200上广播携带其签名的这些数据包206c和205a。转向加速节点202B，其输出数据包206a和205b。对于加速节点202C，其输出数据包206b和205c。

下文关于图4和5描述加速节点202A使用并行计算能力来组织接收到的交易数据(txa1至txa7)，并将组织的交易数据分配给其处理器布置的指定分区以在两种不同场景中处理交易数据(txa1至txa7)。使用硬件并行执行来提高整体交易处理速度，从而提高系统吞吐量。处理器架构可以基于FPGA、ASIC或GPU(图形处理单元)任一者。

图4的部分450示出加速节点202A、202B和202C在力图认证从它们所连接到的API节点404接收的交易数据(txa1至txan)中发现的数字签名时执行的处理。应了解，对于加速节点202A、202B和202C中的每一个所示的“10个并行”计算分支是出于说明目的。每个加速节点202A、202B和202C拥有的并行计算分支的数量取决于它们各自的处理能力。

加速节点202A、202B和202C中的每一个分析其接收到的交易数据(txa1至txan)以确定它们中的哪一个含有数字签名。将含有数字签名的交易数据分配406给被配置成执行认证数字签名的所需处理任务的其相应处理器布置的指定分区。参考图2，分配406使得加速节点202A的处理器布置的被指定执行验证任务408av的分区创建具有验证签名VSa的数据包205a；并且使得加速节点202A的处理器布置的被指定执行提交任务408ac的分区创建具有提交签名CSa的数据包206c。类似地，分配406使得加速节点202B的处理器布置的被指定执行验证任务408bv的分区创建具有验证签名VSb的数据包205b；并且使得加速节点202B的处理器布置的被指定执行提交任务408bc的分区创建具有提交签名CSb的数据包206a。转向加速节点202C，分配406使得其处理器布置的被指定执行验证任务408cv的分区创建具有验证签名VSc的数据包205c；并且其处理器布置的被指定执行提交任务408cc的分区创建具有提交签名CSc的数据包206b。然后，由块产生节点204通过上文关于图3的p.5描述的共识来执行将数据包206a、206b和206c记录到新数据块中。

相比而言，传统DLT(在部分400中示出)经历其任何一个参与节点执行验证和提交任务、创建新数据块以及执行共识来记录新数据块。除了严重消耗参与节点的CPU 415的计算能力之外，当CPU在其必须执行的几个作用之间切换时，这还导致CPU空闲时间409。因此，由加速节点202A、202B和202C进行的并行方法缓解了块产生节点204所经历的处理器压力，并加速了新数据块的记录过程。

图5的部分550示出加速节点202A、202B和202C在力图认证从它们所连接到的API节点504接收的交易数据(txa1至txan)中发现的数字签名、智能合约签署信息和ZKP信息时执行的处理。应了解，对于加速节点202A所示的“10个并行”计算分支、对于加速节点202B所示的“4个并行”计算分支以及对于加速节点202C所示的“2个并行”计算分支是为了说明可用并行计算分支的数量随着所需计算资源的增加而减少。每个加速节点202A、202B和202C拥有的并行计算分支的数量取决于它们各自的处理能力。

加速节点202A、202B和202C中的每一个分析其接收到的交易数据(txa1至txan)以确定它们中的哪一个含有数字签名、智能合约签署信息和ZKP信息。为简单起见，图5示出在加速节点202A中发生的关于认证其接收到的交易数据中的数字签名的数据组织；在加速节点202B中发生的关于认证其接收到的交易数据中的智能合约信息的数据组织；以及在加速节点202C中发生的关于认证其接收到的交易数据中的ZKP信息的数据组织。未示出在加速节点202A、202B和202C中发生的关于其它两种类型的数据的数据组织，即，对于加速节点202A未示出智能合约签署信息和ZKP信息；对于加速节点202B未示出数字签名和ZKP信息；以及对于加速节点202C未示出数字签名和智能合约签署信息。

在加速节点202A中，将含有数字签名的交易数据分配506给被配置成执行认证数字签名的所需处理任务的其处理器布置的指定分区。参考图2，分配506使得加速节点202A的处理器布置的被指定执行关于签名的验证任务508av的分区创建具有验证签名VSa的数据包205a；并且加速节点202A的处理器布置的被指定执行关于签名的提交任务508ac的分区创建具有提交签名CSa的数据包206c。

类似地，在加速节点202B中，将含有智能合约签署信息的交易数据分配506给被配置成执行认证智能合约签署信息的所需处理任务的其处理器布置的指定分区。参考图2，分配506使得加速节点202B的处理器布置的被指定执行关于智能合约签署的验证任务508bv的分区创建具有验证签名VSb的数据包205b；并且加速节点202B的处理器布置的被指定执行关于智能合约签署的提交任务508bc的分区创建具有提交签名CSb的数据包206a。

转向加速节点202C，将含有ZKP信息的交易数据分配506给被配置成执行认证ZKP信息的所需处理任务的其处理器布置的指定分区。参考图2，分配506使得其处理器布置的被指定执行关于ZKP信息的验证任务508cv的分区创建具有验证签名VSc的数据包205c；并且其处理器布置的被指定执行关于ZKP信息的提交任务508cc的分区创建具有提交签名CSc的数据包206b。然后，由块产生节点205通过上文关于图3的p.5描述的共识来执行将数据包206a、206b和206c记录到新数据块中。

相比而言，传统DLT(在部分500中示出)经历其任何一个参与节点执行验证和提交任务、创建新数据块以及执行共识来记录新数据块。参与节点的CPU在处理每种接收到的不同格式的数据(例如，一般交易，然后是智能合约签署)之间进行切换。除了严重消耗参与节点的CPU的计算能力之外，当CPU在其必须执行的几个作用之间切换时，这还导致CPU空闲时间409。因此，由加速节点202A、202B和202C进行的并行方法缓解了块产生节点204所经历的处理器压力，并加速了新数据块的记录过程。

在另一实施方案(未示出)中，加速节点202A、202B和202C中的每一个可以被指定为仅处理一种类型的交易数据。例如，加速节点202A被配置成仅处理数字签名，加速节点202B被配置成仅处理智能合约签署数据，而加速节点202C被配置成仅处理ZKP数据。然后，根据BFT共识，在同一网络域中总共需要九个加速节点。包含加速节点202A在内的第一组三个加速节点将被指定用于数字签名验证。包含加速节点202B在内的第二组另三个加速节点将被指定用于智能合约签署。包含加速节点202C在内的第三组剩下三个加速节点将被指定用于ZKP。

下文描述加速节点202A、202B和202C关于其第二特征的操作，即，使一个加速节点证实另一个加速节点的验证结果。

加速节点202A、202B和202C中的每一个具有一个唯一密钥对，用于对其从API节点接收到的交易数据进行签名，并进行认证(参考图4和5，其描述了加速节点202A、202B和202C如何就数字签名、智能合约签署信息和ZKP信息对从API节点404接收到的交易数据进行认证)。每个加速节点202A、202B或202C使用此密钥对将验证签名VSa、VSb和VSc附加到其生成的数据包205a、205b和205c中，如图2所示。

加速节点202A、202B或202C中的每一个还执行两个过程，称为：验证和提交。这两个过程的结果的相似之处在于，两者都使得应用显示执行了验证过程或提交过程的加速节点202A、202B或202C的签名，使得携带验证签名或验证签名和提交签名两者的数据包反映已经对数据包进行签名的加速节点。不同之处在于对其应用的签名的数据来源。

在验证过程中：从相应加速节点202A、202B或202C所连接到的API节点接收加速节点202A、202B或202C负责加速的交易数据(参考图2，加速节点202A连接到API节点a1、a2和a3，而加速节点202C连接到API节点c1和c2)。由于验证加速的作用，来自加速节点202A、202B或202C的输出将含有验证签名(VSa、VSb或VSc)。

在提交过程中：从另一加速节点202A、202B或202C接收加速节点202A、202B或202C负责加速的交易数据。从另一加速节点202A、202B或202C传输的数据包中提取交易数据(从图2中所示的相应数据包205a、205b和205c中赋予SubBlocka、SubBlockb和SubBlockc)。这些数据包205a、205b和205c已经携带由输出数据包205a、205b和205c的加速节点202A、202B或202C应用的验证签名(VSa、VSb或VSc)。由于提交加速的作用，来自加速节点202A、202B或202C的输出将含有提交签名(CSa、CSb或CSc)。

使用加速节点202A作为示例，参考图6更详细地描述验证过程和提交过程。

在阶段602，加速节点202A从其负责的API节点a1、a2和a3接收交易数据。交易数据中的每一个附加有由相应API节点a1、a2或a3生成的哈希摘要或签名H/S-1、H/S-2或H/S-3。加速节点202A通过检查哈希摘要或签名H/S-1、H/S-2或H/S-3来验证接收到的交易数据的来源。检查哈希摘要或签名H/S-1、H/S-2或H/S-3还能发现是否存在传递完整性，即交易数据是否是不变的且具有发送者身份的不可否认性。接收到的交易数据的来源由加速节点202A的处理器布置的被指定执行验证任务408av的验证分区来验证。

在阶段604，在验证接收到的交易数据的来源之后，丢弃哈希摘要或签名H/S-1、H/S-2或H/S-3。

在阶段606，通过处理交易数据中的每个单独的交易以确定其有效性来验证交易数据的完整性。完成的处理的示例包含交易数据的属性和内容是否正确。回顾图3、4和5，处理包含验证交易数据是否是不变的且具有发送者身份的不可否认性。另外，可以使用交易数据与DLT记录的一致性来证实交易数据的准确性。图4和5描述了在阶段606中发生的对于此验证的并行处理，因此不再进一步阐述。

在阶段608，将在阶段606中成功建立了其完整性的所有交易数据合并成数据包SubBlocka。加速节点202A生成用于建立交易数据的完整性的验证签名VSa。通过对SubBlocka的内容进行哈希来生成验证签名VSa，即HASH(SubBlockb)→VSa。然后，在阶段609，加速节点202A的处理器布置的验证分区广播具有验证签名VSa的数据包206a。

在阶段610，加速节点202A从系统中的另一加速节点接收数据包，例如由加速节点202B输出的数据包205b。数据包205b含有建立其交易数据的完整性的验证签名VSb。然后，加速节点202A的处理器布置的被指定执行提交任务408ac的提交分区力图证实验证签名VSb，如下所述。也就是说，加速节点202A力图证实加速节点202B完成的工作。

在阶段612，提取SubBlockb中的交易数据。然后在阶段614，处理提取的交易数据。图4和5描述了在阶段614中发生的并行处理，因此不再进一步阐述。在阶段614，执行若干检查，其中包含：i)是否对数据包205b收集了足够的签名，比如验证签名VSb确实存在、另一验证签名(例如，VSc)存在或提交签名(CSb、CSc)存在；以及ii)就数据不变性和发送者身份、交易数据内容的准确性的结果交叉检查另一加速节点(例如，202B或202C)。如果提取的交易数据未通过这些检查，则丢弃618数据包205b。如果提取的交易数据通过616这些检查，则生成提交签名CSa以指示验证签名VSb经过证实。通过对SubBlockb以及数据包205b中存在的所有签名进行哈希来生成提交签名CSa，即HASH(SubBlockb+VSb)→CSa。然后在阶段620，加速节点202A的处理器布置的提交分区广播携带验证签名VSb和提交签名CSa两者的数据包606a。

加速节点202A与系统200中的另一加速节点(例如，加速节点202C)执行的提交过程是相同的。图7示出加速节点202A执行的验证过程；以及在加速节点202A与加速节点202C之间执行的提交过程。

在图7中，加速节点202A执行验证过程，如下所述。

在阶段v.1，加速节点202A从连接到其上的API节点接收原始交易数据。在阶段v2，加速节点202A使用并行处理来验证接收到的交易数据。然后在阶段v.3，将经过验证的交易数据打包成SubBlocka。在阶段v.4，加速节点202A生成验证签名VSa，用于应用到含有SubBlocka的数据包上。在阶段v.5，加速节点202A向系统中的其它加速节点广播具有其验证签名VSa的数据包。

加速节点202A证实从加速节点202C接收到的数据包中的验证签名VSc，如下所述。

在阶段m.1，加速节点202A在从加速节点202C接收到的数据包中解包来自SubBlockc的所有交易数据。在阶段m.2，加速节点202A使用并行处理来检查SubBlockc是否具有足够的验证签名。如果存在足够的验证签名，则加速节点202A生成提交签名CSa，并将提交签名CSa附加到含有SubBlockc和验证签名VSc的数据包上。在阶段m.4，加速节点202A向系统中的其它加速节点广播具有其验证签名VSc和提交签名CSa的数据包。

从以上跨越图4到7的描述中，应了解，加速节点202A、202B和202C的两个特征，即其并行计算能力和一个加速节点证实由另一加速节点生成的验证签名，是交织在一起的。验证签名的证实使用加速节点的并行计算能力。还将了解，虽然加速节点202A、202B和202C的操作产生连续签名的数据包206a、206b、206c，其中每个数据包具有两个签名(第一签名是验证签名且第二签名是提交签名)，但有可能连续签名的数据包可以具有多于两个签名。

图8示出总结当在分布式账本中创建新数据块时图2所示的API节点a1、a2、a3、c1和c2；加速节点202A、202B和202C；和块产生节点204执行的功能的示意图。

API节点a1、a2、a3、c1和c2从多个IoT装置收集将被记录到分布式账本中的新数据块中的交易数据。

替代由块产生节点204进行与将新数据块记录到分布式账本中相关的所有任务，加速节点202A、202B和202C通过承担将新数据块记录到分布式账本中所需的处理工作的一部分来分发这些任务。加速节点202A、202B和202C针对从API节点a1、a2、a3、c1和c2接收的交易数据中的每个交易承担的任务包含：加速节点中的一个对其内容被检查的数据包进行签名，然后使加速节点中的另一个证实签名的数据包；授权检查；智能合约签署；、ZKP的生成和验证；以及环签名的生成和验证。

加速节点202A、202B和202C利用并行计算能力来执行其任务。上文已经描述了签名的数据包、智能合约签署以及ZKP验证的证实。授权检查是指访问多个用户共享的数字钱包地址的账户时执行的检查。这些用户中的每一个有不同的授权级别；一些有权进行令牌交易，而一些只能检查余额。授权检查可以被卸载为加速节点202A、202B和202C的并行处理能力。环签名是指隐私保护技术，其使用的签名不会透露消息的签名方，其中签名仅对其既定接收者有效。使用此类环签名的交易的处理可以被卸载为加速节点202A、202B和202C的并行处理能力。

然后，系统中的块产生节点204只需要检查它们之间对于由加速节点202A、202B和202C生成的数据块进入分布式账本是否存在共识。如果达成共识，则将数据块写入分布式账本中。

加速节点202A、202B和202C还被配置成接收832软件更新；并且根据接收到的软件更新来修改其操作协议。这允许在加速节点202A、202B和202C中运行的所有应用程序被动态分配和升级。

相比而言，传统FPGA服务是通过固件下载而不是软件升级来编程的。远程升级固件(例如，从1.0版升级到1.1版)的限制是很难改变FPGA被编程以执行的功能。因此，如果FPGA已被编程用于签名验证，则通过远程升级很难对其重新编程用于ZKP验证。需要操作员干预和访问。一般升级也很复杂，需要特殊工具并且可能需要几个小时。升级之后，安装FPGA的服务器需要重启。

图9示出基于容器的服务902，其提供独立的可执行软件包，包含对加速节点升级或重新编程所需的一切，例如：代码、运行时间、系统工具、系统库和设置。也就是说，所有服务将从基于FPGA的容器中运行，而不是直接在FPGA上运行。容器902允许对在每个加速节点内运行的加速引擎的动态分配和升级。容器902的示例能力包含：

1).虚拟化FPGA硬件(HW)资源。容器902部署在网络级而不是物理机器级，这意味着具有多个FPGA的多个服务器可统一为公共计算资源；

2).动态更新/更改加速引擎并部署到硬件HW资源中。容器902服务本身可以被更新以更改其设置功能并提供不同的加速引擎。容器902的部署类似于软件安装，不需要操作员干预和访问。可无需停止或重启服务器。更新后的加速引擎在安装后不久(间隔几分钟)运行。

通过以下用例描述基于容器的服务902的部署，在集群中具有总共三个可用的FPGA硬件HW资源904。两个已经部署(FPGA1、FPGA2)，一个(FPGA3)可自由部署。需要部署两个加速引擎906，从而需要释放两个FPGA资源，由此释放的FPGA资源和已经可用的FPGA3硬件HW资源可以适应两个加速引擎906的部署。

可以访问OSS/BSS管理控制台110(参考图1)以请求部署908FPGA加速引擎3和FPGA加速引擎4。为了获得两个可用的FPGA硬件HW资源，可以做出任意撤回决定，例如终止910来自FPGA2的签名生成引擎。替代地，可以部署一个以上的FPGA硬件HW资源(未示出)。

FPGA守护进程(Daemon)服务912终止来自FPGA2的签名生成引擎，从而释放FPGA2硬件HW资源。然后，FPGA守护进程服务912将两个新的FPGA加速引擎(ZKP验证和环签名生成)分别部署914到FPGA2和FPGA3上。

FPGA守护进程服务912还负责维护部署到FPGA1、FPGA2和FPGA3的所有服务。在发生任何服务失败的情况下，FPGA守护进程912将立即终止并重新建立受影响的服务，以确保系统稳健性。

图10示出根据BFT(拜占庭容错)部署图2的系统200。加速节点1002和块产生节点1004以三的倍数部署。然而，对API节点1040没有此类限制。API节点1040中的每一个部署在本地数据中心中，靠近5G无线电接入点1212。无线电接入点1212充当所有移动终端与MNO网络之间的接口。当IoT装置用于产生将由块产生节点1004记录的交易数据的交易中时，IoT装置使用MNO网络的基础设施。

根据上文关于图1至10的讨论，移动运营商可以加速验证DLT上的交易的性能。这为任务关键型装置(例如：制造机器人、自动驾驶车辆)提供服务，并通过减少延迟提高“体验质量”。一组定义的协议指示将在CPU(为通用目的而构建)与同时使用两个处理器的FPGA(为密集型任务而构建)处理器之间共享工作负载。当具有嵌入式eSIM的IoT装置经由DLT(通过MEC节点共识)发起交易或智能合约时，可以将处理的交易或合约引导到FPGA(安装于加速节点中)以实现平滑加速，从而提高整体性能。

图11是提供促进部署电子订户身份模块(eSIM)1112以用于不同移动网络运营商(MNO)的图1中所描述的SaaS管理控制台104和OSS/BSS管理控制台110的概述的示意图。为简单起见，仅示出两个MNO 1118A和1118B。

企业客户1102访问1104其SaaS管理控制台104，以通过其相应OSS/BSS管理控制台110选择MNO 1118A或MNO 1118B任一者来更改命令链结束时IoT装置1120的配置文件。

相应OSS/BSS管理控制台110向MNO A 1118A发送1106具有API的更改的eSIM配置文件。然后，MNO 1118A经由5G网络1126将更改的配置文件推送1108到IoT装置1120。接着，eSIM 1112的配置文件被配置成根据MNO 1118A数据计划和被配置成与MNO 1118A一起使用的计费到数字钱包1114来操作。eSIM 1112配置文件的更新通过其SaaS管理控制台104反映1110回企业客户1102。

eSIM 1112是在IoT装置中发现的能带来：(1)操作灵活性(2)增强的可扩展性和(3)身份管理的安全性的安全元件。eSIM的操作由具有MNO PKI(公钥基础设施)系统支持的GSMA规范定义。

在图11中，除了允许IoT装置1120连接到MNO 1118A和1118B 5G网络之外，还利用eSIM 1112来托管用于IoT装置1120的数字钱包1114。

eSIM 1112具有存储密钥对的能力，所述密钥对包括允许其与DLT分布式账本(如图1中描述的分布式账本102)交互并在进行令牌交换时执行数字签名的一组公钥和私钥。这允许IoT装置1120支付和接收令牌。

IoT装置1120中的eSIM 1112创建机器对机器交易，所述交易可以经由MEC节点内部署的DLT通过其5G连接进行处理。DLT将能够(1)通过eSIM识别装置ID(2)签署智能合约和(3)验证令牌支付交易。下文描述关于设置eSIM 1112以执行这三个功能的进一步细节。

图12示出服务部署服务器1230，其用于远程配置嵌入IoT装置中的eSIM 1212，并且为eSIM 1212设置数字钱包能力和数字签名1232能力以认证使用数字钱包通过生成的数字签名执行的交易。图12示出MNO A和MNO B中的每一个具有其专用服务部署服务器1230，MNO A和MNO B中的每一个通过所述专用服务部署服务器为eSIM1212设置支持分别由MNO A和MNO B使用的通信协议的配置文件1218。

存储在eSIM 1212中的每个配置文件1218通过由服务部署服务器1230实现的远程设置来更新。此更新可以在eSIM 212处于作用中并且连接到MNO A或MNO B网络的任何时刻发生。这为IoT装置提供了多个MNO能力(多个eSIM配置文件)，这使得装置漫游和装置共享/租赁成为可能。

图13示出当使用属于MNO A的服务部署服务器1230来设置eSIM驻留在其上的安全元件1312时发生的阶段序列。应了解，对于MNO B或任何其它移动网络运营商也将发生此类阶段序列。

为了增强在MNO网络上发生的交易的安全性，使用对于MNO A唯一的参数作为认证此类交易的数字签名的基础。此参数是用于向移动网络运营商(MNO A)网络识别其中部署了安全元件1312的无线装置1313的订户身份。订户身份1330是IMSI(国际移动订户身份)，其是全球64位唯一号码并由MNO分配。

在初始化期间，服务部署服务器1230通过数据信道1322传输可以对无线装置1313的安全元件1312进行编程的指令集。所述指令集可以例如包含在软件包中，并且在安装软件包时执行。在此实施方案中，在初始化期间由服务部署服务器1230向无线装置1313传输的正是所述软件包。从服务部署服务器1230传输的指令当在无线装置1313中执行时将无线装置1313配置成基于订户身份将密钥对1332存储在无线装置1313的安全元件1312中。存储的密钥对1332形成移动网络运营商(MNO A)的配置文件的部分，其中存储的密钥对1332可以由用于数字钱包的小程序使用。使用IMSI生成密钥对具有利用MNO的KYC(了解您的客户)协议增强安全控制的优势。

在一个实施方案中，从服务部署服务器1230获得存储的密钥对1332。也就是说，从服务部署服务器1230传输的指令在无线装置1313中执行时还将无线装置1313配置成通过数据信道1322从服务部署服务器1230获得密钥对1332，之后进行存储。

在另一实施方案中，存储的密钥对1332是由于无线装置1313被配置成在执行从服务部署服务器1230传输的指令之后从服务部署服务器1230获得用于向移动网络运营商(MNO A)网络识别无线装置1313的订户身份1330而产生。基于接收到的订户身份1330生成密钥对1332，然后进行存储。

私钥1336用于生成与传出数据(即，用于传输的数据)一起使用的签名。在一个实施方案中，公钥1334可以由无线装置1313广播，用于对携带由私钥1336生成的签名的传输的数据进行签名验证。公钥1334可以附有由证书颁发机构验证的证书，以认证传输的数据是由证书的所有者发送的。在另一实施方案中，公钥1334可以包含于传输的数据中，作为签名验证过程的一部分，在其由加速节点(例如，图2中所示的加速节点202A、202B和202C)通过合适的算法恢复。

从服务部署服务器1230传输的指令还将无线装置1313配置成在生成密钥对1332时包含额外的参数。

第一额外的参数是随机数1328，其用于基于订户身份1330对密钥对1332进行随机化。在一个实施方案中，随机数1328是从服务部署服务器1230获得的TRN(真随机数)，其是长度至少为256位的完全随机数。TRN可以仅被使用一次并且在生成密钥对1332之后在无线装置1313端被永久消除，以减少包括基于密钥对1332的数字钱包的可能性。然尔，TRN也可以保留在服务部署服务器1230中，用于密钥对1332的恢复。在其它实施方案中，随机数1328可以由无线装置1313生成。如果是这样，则在生成密钥对1332之后，随机数1328仍然可以在无线装置1313端被永久消除。然而，随机数1328随后可以被传输到服务部署服务器1230以用于存储和使用，例如用于密钥对1332恢复。

在生成密钥对1332时包含的第二额外的参数是无线装置1313的硬件组件的标识符1344。无线装置1313从中导出标识符1344的硬件组件可以包含提供UUID(通用唯一标识符)的任何部分，例如包含管理安全元件1312的处理器1347的半导体装置(CPU/MCU)。

从服务部署服务器1230传输的指令当在无线装置1313中执行时可以将无线装置1313配置成执行哈希函数1338和密钥导出函数(KDF)1340中的任一个或多个以生成密钥对1332。哈希函数1338根据输入数据生成固定长度“摘要”，而KDF 1340是用于根据随机数生成密钥的加密函数。

从服务部署服务器1230传输的指令当在无线装置1313中执行时还可以将无线装置1313的安全元件配置成存储多个配置文件，每个用于不同的移动网络运营商。这些配置文件中的每一个存储允许接入无线装置1313与每个不同移动网络运营商的数据计划的网络配置数据，图13示出了MNO A的配置文件。

从服务部署服务器1230传输的指令当在无线装置1313中执行时还可以将无线装置1313的安全元件配置成：(经由eSIM)托管用于处理在移动网络运营商促进的交易中使用的支付令牌的电子钱包。这些支付令牌可以由分布式账本(例如，图2中所示的DLT102)生成。安全元件1312中电子钱包的地址1346由密钥对1332的公钥1334确定。分布式账本DLT102将使用新数据块更新，所述新数据块记录来自使用电子钱包执行的一个或多个交易的数据。新数据块的记录需要图4和5中描述的加速，这将为含有此交易数据的数据包产生签名布置；随后，当签名布置被证实时存在共识，如图3所描述。利用多个数字钱包，通过选择其中一个数字钱包来执行支付交易，可以实现装置漫游，这将使得所选移动网络运营商(例如，图12中所示的MNO A或MNO B)促进支付交易。

在初始化安全元件1312之后，还将建立安全元件1312中的分区以执行验证服务1348和签名服务1350。验证服务1348和签名服务1350是可由小程序使用的MNO A配置文件的一部分。当无线装置1313接收到需要验证的数据时，调用验证服务1348，而当无线装置1313发布来自与无线装置1313执行的交易(例如，在收费站处付款)的数据时，调用签名服务1350。

参考图2，服务部署服务器1230设置的密钥对1332可由一个或多个嵌入式算法引擎1353用于工厂250、收费站252和充电站254处发生的交易。例如，基于ECDSA算法的签名生成硬件HW引擎1352A(作为嵌入式算法引擎1353之一)可以使用私钥1336对来自无线装置1313的关于此类交易的传出数据进行签名。与无线装置1313通信的API节点a1、a2、a3、c1或c2接收签名的交易数据。

嵌入式算法引擎1353的用例如下，其中在无线装置1313中运行的DLT应用程序(例如，使用数字钱包的应用程序)与API节点a1、a2、a3、c1或c2中的一个通信以执行交易。在阶段a.1，DLT应用程序调用签名服务1350(即驻留在安全元件1312中的小程序)，要传输交易消息。在阶段a.2，签名服务1350调用基于ECDSA算法的签名生成硬件HW引擎(1352A)以使用私钥1336来生成签名。在阶段a.3，签名服务1350从基于ECDSA算法的签名生成硬件HW引擎(1352A)接收签名。在阶段a.4，签名服务1350将生成的签名返回到DLT应用程序。在最后阶段a.5，DLT应用程序通过空中向DLT应用程序正与其通信的API节点a1、a2、a3、c1或c2发送携带签名的消息。

在阶段b.0，无线装置1313接收交易消息(Tx)。如果交易需要验证，则在阶段b.1，DLT应用程序调用验证服务1348。在阶段b.2和b.3，验证服务1348使用基于ECDSA算法的签名验证硬件HW引擎1352B来验证交易。在阶段b.4，将验证结果返回到DLT应用程序。

作为使服务部署服务器1230远程配置安全元件1312的替代方案，远程服务器(未示出)中存在的计算机可读、非瞬时性介质可以含有计算机程序，所述计算机程序在被执行时使无线装置1313的处理器1347基于用于向移动网络运营商网络识别无线装置1313的订户身份将密钥对1332存储在无线装置1313的安全元件1312中。计算机程序还使处理器1347使用密钥对1332的私钥1336生成与传出数据一起使用的签名以进行传输。例如，当无线装置1313访问库(例如，应用程序商店)以下载计算机程序时，可以访问远程服务器中的计算机可读、非瞬时性介质。替代地，无线装置1313内的计算机可读、非瞬时性介质可能已经存储了计算机程序，准备在需要时进行安装。

在本申请中，除非另外规定，否则术语“包括”以及其语法变体旨在表示“开放性”或“包含性”语言，使得所述术语包含所列举的要素，但也允许包含额外的、非明确列举的要素。还应了解，术语“信息”和“数据”可以互换使用，特别是在提及将交易记录到分布式账本中时。

虽然已经参考示例性实施例描述了本发明，但是本领域的技术人员将理解，在不脱离本发明的精神和范围的情况下，可以进行各种改变，并且可以用等同物代替其要素。另外，在不脱离本发明的基本范围的情况下，可以进行修改以使本发明的教导适应特定的情况和材料。因此，本发明不限于本说明书中公开的特定示例，而是涵盖落入所附权利要求范围内的所有实施例。

Claims (42)

1.一种用于支持使用分布式账本记录交易数据的服务的系统，所述系统包括

块产生节点，所述块产生节点包括被配置成将新数据块记录到所述分布式账本中的处理器布置，所述处理器布置被配置成执行计算机可读程序代码以：

接收包括用于记录到所述分布式账本的新数据块中的交易数据的数据包，所述数据包携带签名布置，所述签名布置在外部执行；

证实接收到的数据包的所述签名布置；

确定贯穿所述系统中也已经接收到所述数据包并证实其签名布置的足够数量的其它块产生节点是否存在共识；以及

响应于确认存在所述共识，将来自所述接收到的数据包的所述交易数据记录到所述分布式账本的新数据块中。

2.根据权利要求1所述的系统，其中由所述数据包携带的所述签名布置是由于所述交易数据已经被连续地签名而产生，其中每个签名由不同外部节点执行。

3.根据权利要求2所述的系统，其中当证实所述接收到的数据包的证书签名布置时，所述块产生节点的所述处理器布置还被配置成确定足够数量的所述签名的存在。

4.根据前述权利要求中任一项所述的系统，其中在将新数据块记录到所述分布式账本中时，所述块产生节点的所述处理器布置还被配置成包含来自最后一个数据包的交易数据。

5.根据前述权利要求中任一项所述的系统，所述系统还包括

加速节点，所述加速节点包括被配置成格式化交易数据以作为新数据块记录到所述分布式账本中的处理器布置，所述处理器布置被配置成执行计算机可读程序代码以：

根据处理接收到的交易数据所需的任务来组织接收到的交易数据；

将组织的交易数据分配给被配置成实行执行所需处理任务所需的步骤的所述处理器布置的指定分区，其中所述指定分区中的每一个被配置成创建包括处理后的交易数据的数据包；

对针对其交易数据进行了处理的所述数据包中的每一个进行签名；以及

在所述系统上广播携带其签名的所述数据包。

6.根据权利要求5所述的系统，其中所述加速节点的所述处理器布置的所述指定分区中的一个是验证分区，所述验证分区被配置成

验证所述接收到的交易数据的完整性；以及

响应于成功验证所述接收到的交易数据的完整性，生成验证签名以建立由所述验证分区创建的所述数据包的所述接收到的交易数据的完整性。

7.根据权利要求6所述的系统，其中所述加速节点的所述处理器布置还被配置成丢弃含有缺乏完整性的所述交易数据的所述数据包。

8.根据权利要求6或7所述的系统，其中当验证所述接收到的交易数据的完整性时，所述加速节点的所述处理器布置还被配置成确定所述接收到的交易数据是否具有传递完整性；以及所述交易数据的来源。

9.根据权利要求5至8所述的系统，其中所述加速节点的所述处理器布置的所述指定分区中的一个是提交分区，所述提交分区被配置成

证实从所述系统中的另一加速节点接收的数据包中发现的验证签名，所述验证签名建立接收到的数据包中的所述交易数据的完整性；以及

响应于成功证实，生成指示所述验证签名被证实的提交签名，其中由所述提交分区创建的所述数据包还包括来自所述接收到的数据包的所述验证签名。

10.根据权利要求9所述的系统，其中所述加速节点的所述处理器布置还被配置成丢弃具有未通过所述证实的验证签名的所述数据包。

11.根据权利要求5至10所述的系统，其中所述处理器布置的所述指定分区并行处理其被分配的交易数据。

12.根据权利要求5至11所述的系统，其中所述加速节点的所述处理器布置还被配置成：

接收软件更新；以及

根据接收到的软件更新修改其操作协议。

13.根据权利要求12所述的系统，其中所述软件更新对所述加速节点的所述处理器布置的所述分区中的一个或多个重新编程以处理不同任务。

14.根据前述权利要求中任一项所述的系统，其中所述块产生节点的所述处理器布置还被配置成：

支持托管管理所述分布式账本的操作的命令的一个或多个控制台。

15.根据权利要求1至14所述的系统，还包括

包括处理器布置的管理节点，所述处理器布置被配置成执行计算机可读程序代码以：

支持托管管理所述分布式账本的操作的命令的一个或多个控制台；以及

将所述命令传输到所述块产生节点以供执行。

16.根据前述权利要求中任一项所述的系统，其中所述交易数据包括与数字签名、智能合约签署和零知识证明相关的数据中的任一个或多个。

17.根据权利要求5至16所述的系统，其中所述加速节点部署于服务器机房或边缘数据中心、中心局、区域数据中心或全球数据中心中。

18.根据前述权利要求中任一项所述的系统，其中所述块产生节点位于边缘数据中心、中心局、区域数据中心或全球数据中心中。

19.一种用于蜂窝通信网络的无线装置，所述无线装置包括：

收发器；

安全元件；以及

与所述收发器和所述安全元件通信的处理器，所述处理器被配置成：

基于用于向移动网络运营商网络识别所述无线装置的订户身份，将密钥对存储在安全元件中；

使用所述密钥对的私钥，生成与传出数据一起使用的签名；以及

经由所述收发器传输携带所述签名的所述传出数据。

20.根据权利要求19所述的无线装置，其中所述处理器还被配置成从所述移动网络运营商网络获得所述密钥对。

21.根据权利要求19所述的无线装置，其中存储的密钥对是由于所述处理器还被配置成进行以下操作而产生：

从所述移动网络运营商网络获得用于向所述移动网络运营商网络识别所述无线装置的所述订户身份；以及

基于接收到的订户身份生成所述密钥对。

22.根据权利要求19所述的无线装置，其中所述处理器还被配置成在生成所述密钥对时包含所述无线装置的硬件组件的随机数和标识符。

23.根据权利要求22所述的无线装置，其中所述随机数是从所述移动网络运营商网络获得的。

24.根据权利要求21至23所述的无线装置，其中所述处理器还被配置成执行哈希函数和密钥导出函数中的任一个或多个以生成所述密钥对。

25.根据权利要求19至24所述的无线装置，其中在所述安全元件中存储多个配置文件，每个配置文件用于不同的移动网络运营商。

26.根据权利要求25所述的无线装置，所述安全元件还托管用于处理在所述移动网络运营商促进的交易中使用的支付令牌的电子钱包。

27.根据权利要求26所述的无线装置，其中所述安全元件中的所述电子钱包的地址由所述密钥对的公钥确定。

28.根据权利要求19至24所述的无线装置，其中接收到的数据和传输的数据包括促进所述无线装置识别、智能合约签署和支付交易验证的数据中的任一个或多个。

29.根据权利要求19至28所述的无线装置，其中所述签名由嵌入所述安全元件中用于与所述无线装置执行的交易相关的数据的算法引擎生成。

30.根据权利要求29所述的无线装置，其中所述交易由在所述无线装置中运行的分布式账本应用程序实现。

31.根据权利要求19至30所述的无线装置，其中所述无线装置还被配置成广播所述密钥对的公钥或将所述公钥包含在携带所述签名的传出数据中。

32.一种被配置成传输指令的服务部署服务器，所述指令当在无线装置中实行时将所述无线装置配置成：

基于用于向移动网络运营商网络识别所述无线装置的订户身份，将密钥对存储在所述无线装置的安全元件中；以及

使用所述密钥对的私钥，生成与传出数据一起使用的签名以进行传输。

33.根据权利要求32所述的服务部署服务器，其中存储的密钥对是从所述服务部署服务器获得的。

34.根据权利要求32所述的服务部署服务器，其中所述存储的密钥对是由于所述无线装置被配置成在传输的指令执行之后进行以下操作而产生：

从所述移动网络运营商网络获得用于向所述移动网络运营商网络识别所述无线装置的所述订户身份；以及

基于接收到的订户身份生成所述密钥对。

35.根据权利要求34所述的服务部署服务器，其中所述传输的指令当在无线装置中执行时还将所述无线装置配置成：在生成所述密钥对时包含所述服务部署服务器的硬件组件的随机数和标识符。

36.根据权利要求35所述的服务部署服务器，其中所述随机数是从所述服务部署服务器获得的。

37.根据权利要求34至36所述的服务部署服务器，其中所述无线装置还被配置成执行哈希函数和密钥导出函数中的任一个或多个以生成所述密钥对。

38.根据权利要求32至37所述的服务部署服务器，其中所述传输的指令当在无线装置中执行时还将所述无线装置的所述安全元件配置成存储多个配置文件，每个配置文件用于不同的移动网络运营商。

39.根据权利要求38所述的服务部署服务器，其中所述传输的指令当在无线装置中执行时还将所述无线装置的所述安全元件配置成：托管用于处理在所述移动网络运营商促进的交易中使用的支付令牌的电子钱包。

40.根据权利要求39所述的服务部署服务器，其中所述安全元件中的所述电子钱包的地址由所述密钥对的公钥确定。

41.根据权利要求32至40所述的服务部署服务器，其中所述传输的指令当在无线装置中执行时还将所述无线装置配置成广播所述密钥对的公钥或将所述公钥嵌入在携带所述签名的传出数据中。

42.一种存储计算机程序的计算机可读非瞬时性介质，其中所述计算机程序使处理器执行：

基于用于向移动网络运营商网络识别所述无线装置的订户身份，将密钥对存储在所述无线装置的安全元件中；以及

使用所述密钥对的私钥，生成与传出数据一起使用的签名以进行传输。

Images