具体实施方式

这里将详细地对示例性实施例进行说明，其示例表示在附图中。下面的描述涉及附图时，除非另有表示，不同附图中的相同数字表示相同或相似的要素。以下示例性实施例中所描述的实施方式并不代表与本说明书一个或多个实施例相一致的所有实施方式。相反，它们仅是与如所附权利要求书中所详述的、本说明书一个或多个实施例的一些方面相一致的装置和方法的例子。

需要说明的是：在其他实施例中并不一定按照本说明书示出和描述的顺序来执行相应方法的步骤。在一些其他实施例中，其方法所包括的步骤可以比本说明书所描述的更多或更少。此外，本说明书中所描述的单个步骤，在其他实施例中可能被分解为多个步骤进行描述；而本说明书中所描述的多个步骤，在其他实施例中也可能被合并为单个步骤进行描述。

在将“用户身体健康”作为通行要求的场景中，用户可以将由权威机构颁发的纸质的健康证明作为通行证，在出入公共场所、搭乘交通工具、跨地域出行等场景中进行通行验证。

在以上示出的实施例中，一方面，由于纸质证书不方便维护，还容易造假，因而难以方便快捷地验证人员的真实健康情况；另一方面，由于纸质证书上通常需要记录用户信息、医疗机构信息、检测结果(或接种记录)等信息，用于证明医疗机构对该用户的检测结果为“健康”，或者可以用于证明该用户已在该医疗机构完成疫苗接种，因此，上述纸质证书上记载的用户隐私信息存在泄露隐患；另外，由于不同国家、不同地区的居民所持有的健康证明，通常是由当地的医疗机构颁发的，因此，难以实现全球统一的健康证明的颁发标准以及验证方式。

有鉴于此，本说明书旨在提出一种在不将用户的健康检查数据直接提供给验证方的前提下，基于用户终端生成的数字通行证，对用户进行通行验证的技术方案。

在实现时，区块链上存证了由健康检查机构上传的针对用户的健康检查数据；用户终端可以生成与上述用户终端存储的、由上述健康检查机构提供的上述用户的健康检查数据对应的零知识证明信息；其中，上述零知识证明信息，用于证明上述用户终端存储的上述用户的健康检查数据是由上述健康检查机构针对上述用户生成的真实的健康检查数据；

进一步地，上述用户终端可以基于上述零知识证明信息，生成与上述用户对应的数字通行证，并将上述数字通行证提供给验证方；

进一步地，上述验证方响应于获取到上述用户终端提供的与上述用户对应的上述数字通行证，可以对上述零知识证明信息进行验证；如果对上述零知识证明信息的验证结果为成功，则通过对上述用户的通行验证；否则，不通过对上述用户的通行验证。

由此可见，在本说明书中的技术方案中，一方面，可以先基于用户终端存储的由健康检查机构提供的用户的健康检查数据，生成对应的零知识证明信息，再基于上述零知识证明信息，生成与上述用户对应的数字通行证；由于用户终端可以将生成的上述数字通行证提供给验证方，而无需将上述用户的健康检查数据提供给验证方，验证方在获取到与上述用户对应的数字通行证之后，通过零知识证明就可以验证用户终端是否存储有上述用户的健康检查数据，以及验证所述健康检查数据是否为由健康检查机构针对上述用户生成的真实的健康检查数据，进一步地可以基于零知识证明的验证结果，确定是否通过对上述用户的通行验证；因此，在验证方无法获知用户的健康检查数据的具体内容的前提下，实现对用户的通行验证，能够有效地保护用户隐私信息，并且相较于纸质证书而言，数字通行证更易于保存、携带，从而提升通行验证的用户体验。

另一方面，由于区块链上存证了由健康检查机构上传的针对用户的健康检查数据，不仅可以用于证明用户终端存储的健康检查数据是由上述健康检查机构生成的真实的健康检查数据，避免用户终端存储的用户的健康检查数据是伪造出来的或经过篡改的健康检查数据，还有利于在全球范围内针对由不同健康检查机构生成的健康检查数据实现互通互信。

为了使本技术领域的人员更好地理解本说明书实施例中的技术方案，下面先对本说明书实施例涉及的区块链的相关技术，进行简要说明。

目前的区块链系统通常包括两种主流的交易模型：一种是以比特币系统为代表的UTXO(Unspent Transaction Output，未花费的交易输出)模型；另外一种是以以太坊(Ethereum)系统为代表的账户模型。

其中，对于采用账户模型的区块链实现数据存证时，区块链的节点设备需要存储和维护的区块链数据，通常包括区块数据、区块链中的区块链账户对应的账户状态数据；而区块数据又可以进一步包括区块头数据、区块中的区块交易数据、以及与区块中的区块交易数据对应的交易收据，等等。

区块链的节点设备在存储以上示出的各种区块链数据时，通常可以将上述各种区块链数据以key-value键值对的形式，组织成Merkle树在数据库中存储。当需要查询节点设备存储的上述各种区块链数据时，可以通过将上述各种区块链数据的key作为查询索引，遍历上述Merkle树来高效的查询数据。

在这类区块链模型中，可以在区块链上部署用于进行数据存证的智能合约，用户可以通过调用智能合约的方式，将需要存证的数据作为该智能合约对应的合约账户的账户状态，存储到与该智能合约对应的Merkle树中。

例如，以以太坊为例，通常采用一种称之为MPT树的特殊的Merkle树来存储和维护区块链数据；其中，对于账户状态数据，可以组织成MPT状态树(俗称世界状态)在数据库中存储；MPT状态树上存储了以账户地址为key，以账户状态数据为value的key-value键值对。而智能合约对应的合约账户中存储的数据内容，也会被进一步组织成storage树(一种用于存储数据的MPT存储树)在数据库中存储；storage树的根节点的hash值，会作为与该合约账户对应的账户状态数据的一部分，填充到MPT状态树中；而MPT状态树的根节点的hash会被作为认证根，进一步填充到区块头中。当用户需要进行数据存证时，可以通过调用智能合约的方式，将需要存证的数据作为该智能合约对应的合约账户的账户状态数据，存储到与该智能合约对应的storage树中。

在区块链领域，有一个重要的概念就是账户(Account)；以以太坊为例，以太坊通常将账户划分为外部账户和合约账户两类；外部账户就是由用户直接控制的账户，也称之为用户账户；而合约账户则是由用户通过外部账户创建的，包含合约代码的账户(即智能合约)。当然，对于一些基于以太坊的架构而衍生出的区块链模型(比如蚂蚁区块链)，还可以对区块链支持的账户类型，进行进一步的扩展，在本说明书中不进行特别限定。

对于区块链中的账户而言，通常会通过一个结构体，来维护账户的账户状态。当区块中的交易被执行后，区块链中与该交易相关的账户的状态通常也会发生变化。

在一个例子中，账户的结构体通常包括Balance，Nonce，Code和Storage等字段。其中：

Balance字段，用于维护账户目前的账户余额；

Nonce字段，用于维护该账户的交易次数；它是用于保障每笔交易能且只能被处理一次的计数器，有效避免重放攻击；

Code字段，用于维护该账户的合约代码；在实际应用中，Code字段中通常仅维护合约代码的hash值；因而，Code字段通常也称之为Codehash字段。

Storage字段，用于维护该账户的存储内容(默认字段值为空)；对于合约账户而言，通常会分配一个独立的存储空间，用以存储该合约账户的存储内容；该独立的存储空间通常称之为该合约账户的账户存储。

合约账户的存储内容通常会构建成MPT(Merkle Patricia Trie)树的数据结构存储在上述独立的存储空间之中；其中，基于合约账户的存储内容构建成的MPT树，通常也称之为Storage树。而Storage字段通常仅维护该Storage树的根节点；因此，Storage字段通常也称之为StorageRoot字段。

其中，对于外部账户而言，以上示出的Code字段和Storage字段的字段值均为空值。

请参见图1，图1是一示例性的实施例示出的一种基于区块链的通行验证方法的应用环境示意图。

在如图1所示的网络环境中，可以包括客户端侧计算设备101、服务器端102，以及至少一个区块链系统；例如，区块链系统103、区块链系统104和区块链系统105。

在一种实施方式中，客户端侧计算设备101，可以包括各种不同类型的客户端侧计算设备；例如，客户端侧计算设备可以包括诸如PC终端设备、移动终端设备、物联网设备，以及其它形式的具有一定的计算能力的智能设备，等等。

在一种实施方式中，客户端侧计算设备101中的至少部分计算设备，可以通过各种通信网络耦接到服务器端102；例如，图1中示出的设备1和设备2与服务器端102进行了耦接。

不难理解，客户端侧计算设备101中的部分计算设备，也可以不与服务器端102进行耦接，而是作为区块链节点通过各种通信网络直接耦接到区块链系统；例如，图1中示出的设备4，可以作为区块链节点耦接到区块链系统。

其中，上述通信网络可以包括有线和/或无线通信网络；例如，可以是基于运营商提供的有线接入网络或者无线接入网络(比如移动蜂窝网络)实现的局域网(Local AreaNetwork，LAN)、广域网(Wide Area Network，WAN)、因特网或其组合。

在一种实施方式中，客户端侧计算设备101，还可以包括一个或多个用户侧服务器；例如，图1中示出的设备5。客户端侧计算设备101中的至少部分计算设备，可以耦接到该用户侧服务器，而该用户侧服务器可以进一步与上述服务端102进行耦接；例如，图1中示出的设备1和设备2耦接到设备5，设备5进一步耦接服务器端102。

在一种实施方式中，服务器端102也可以通过各种通信网络耦接到一个或者多个区块链系统；例如，图1中示出的服务器端102可以分别耦接到区块链系统103、区块链系统104和区块链系统105，等等。

在一种实施方式中，每个区块链系统都可以维护一个或多个区块链(例如，公有区块链、私有区块链、联盟区块链等)，并包括用于承载上述一个或多个区块链的多个区块链节点；例如，如图1中示出的区块链节点1、区块链节点2、区块链节点3、区块链节点4、区块链节点i等可以共同承载一个或者多个区块链。各个区块链系统包含的区块链之间，以及各个区块链系统之间，还可以进行跨链的数据访问。

在一种实施方式中，区块链节点可以是物理设备，也可以是在服务器或者服务器集群中实现的虚拟设备；例如，区块链节点设备可以是服务器集群中的一台物理主机，也可以是基于虚拟化技术对服务器或者服务器集群搭载的硬件资源进行虚拟化后，创建的虚拟机。每个区块链节点之间，可以通过各种类型的通信方法(比如TCP/IP)耦接在一起形成网络，来承载一个或者多个区块链。

在一种实施方式中，服务器端102可以包括用于提供区块链即服务(BaaS，Blockchain as a Service)的BaaS平台(也称之为BaaS云)。BaaS平台可以通过为区块链上发生的活动(诸如订阅和通知、用户验证、数据库管理和远程更新)，提供预先编写的软件的方式，面向与BaaS平台耦接的客户端侧计算设备，提供简单易用、一键部署、快速验证、灵活定制的区块链服务，进而可以加速区块链业务应用开发、测试、上线，助力各行业区块链商业应用场景的落地。

在一种实施方式中，BaaS平台还可以提供基于区块链技术的企业级平台服务，以帮助企业级客户构建安全且稳定的区块链环境，并轻松管理区块链的部署、操作、维护和开发。

需要说明的是，区块链每产生一个最新区块，则在该最新区块中的交易被执行之后，区块链中这些被执行交易的对应状态会随之发生变化。例如，以账户模型构架的区块链中，外部账户或者智能合约账户的账户状态，通常也会随着交易的执行而发生相应的变化。

例如，当区块中的一笔“转账交易”执行完毕后，与该“转账交易”相关的转出方账户和转入方账户的余额(即这些账户的Balance字段的字段值)，通常也会随之发生变化。

又如，区块中的“智能合约调用交易”则用以调用区块链上部署的智能合约，在节点设备对应的EVM内调用上述智能合约以执行上述“智能合约调用交易”，并将执行上述智能合约调用交易后、智能合约账户的账户状态更新在该智能合约的账户中。

在实际应用中，不论是公有链、私有链还是联盟链，都可能提供智能合约(Smartcontract)的功能。区块链上的智能合约是在区块链上可以被交易触发执行的合约。智能合约可以通过代码的形式定义。

以以太坊为例，支持用户在以太坊网络中创建并调用一些复杂的逻辑。以太坊作为一个可编程区块链，其核心是以太坊虚拟机(EVM)，每个以太坊节点都可以运行EVM。EVM是一个图灵完备的虚拟机，通过它可以实现各种复杂的逻辑。用户在以太坊中发布和调用智能合约就是在EVM上运行的。实际上，EVM直接运行的是虚拟机代码(虚拟机字节码，下简称“字节码”)，所以部署在区块链上的智能合约可以是字节码。

请参见图2，图2是一示例性的实施例示出的一种创建智能合约和调用智能合约的示意图。

以太坊中要创建一个智能合约，需要经过编写智能合约、变成字节码、部署到区块链等过程。以太坊中调用智能合约，是发起一笔指向智能合约地址的交易，各个节点的EVM可以分别执行该交易，将智能合约代码分布式的运行在以太坊网络中每个节点的虚拟机中。

用户将一笔包含调用智能合约信息的交易发送到以太坊网络后，各节点均可以在EVM中执行这笔交易。其中，交易的From字段用于记录发起调用智能合约的账户的地址，To字段用于记录被调用的智能合约的地址，交易的Data字段用于记录调用智能合约的方法和参数。调用智能合约后，合约账户的账户状态可能改变。后续，某个客户端可以通过接入的区块链节点查看合约账户的账户状态，例如，上述账户状态可以Key-Value对的形式存储到智能合约的Storage树中。调用智能合约的交易的执行结果，可以是以交易收据(receipt)的形式，存储到MPT收据树中。

智能合约可以以规定的方式在区块链中每个节点独立的执行，所有执行记录和数据都保存在区块链上，所以当这样的交易执行完毕后，区块链上就保存了无法篡改、不会丢失的交易凭证。

下面通过具体实施例，并结合具体的应用场景对本申请进行描述。

请参见图3，图3是一示例性的实施例示出的一种基于区块链的通行验证方法的多方交互图；上述基于区块链的通行验证方法可以应用于如图1所示的应用环境中，本说明书中示出的健康检查机构、用户终端、以及验证方，可以作为客户端侧计算设备，以实现本说明书的技术方案。其中，上述方法可以执行以下步骤：

步骤301：健康检查机构生成针对用户的健康检查数据。

在本说明书中，上述用户的健康检查数据，可以包括用于指示上述用户的健康状况符合通行要求的健康检查数据。其中，上述用户的健康状况符合通行要求，可以理解为，上述用户的健康检查结果指示上述用户是“健康”的，或者上述用户已完成疫苗接种，或者与验证方的通行要求对应的其他可以通过验证的情况，本说明书中不一一列举。

在本说明书中，上述用户的健康检查数据至少可以携带上述用户的数字身份标识，用于表示上述健康检查数据是针对与上述数字身份标识对应的用户生成的；其中，上述用户的数字身份标识，可以是基于上述用户持有的第一私钥而生成的。

在实际应用中，上述用户的数字身份标识，可以包括区块链中上述用户对应的分布式身份账户的DID；上述用户对应的分布式账户属于外部账户，可以由用户持有的第一私钥控制；上述用户对应的分布式身份账户的DID，可以是基于上述用户持有的第一私钥而生成的。

例如，用户持有的第一私钥为sk1，则可以利用公式：DID＝sk·G(G为密码学系统中的生成元)，生成该用户的数字身份标识DID 1；健康检查机构响应于针对该用户进行健康检查，可以生成该用户的健康检查数据，其中携带有该用户的数字身份标识DID 1。

在本说明书中，上述用户的健康检查数据还可以携带以下示出的任一或任意组合：健康检查项目、健康检查结果、健康检查时间、健康检查机构、附加信息、摘要、健康检查机构的数字签名。

例如，上述健康检查项目，可以包括但不限于针对各类疾病的抗体检测、疫苗接种等等；上述健康检查结果，可以用于指示疾病抗体检测结果为健康、疫苗接种完成等等；上述健康检查机构，可以包括但不限于医院、诊所、卫生中心等机构；上述附加信息可以包括疫苗编号或其他备注信息；上述摘要可以包括上述健康检查数据的hash摘要；上述健康检查机构的数字签名，可以包括由上述健康检查机构基于其持有的第二私钥针对上述健康检查数据做出的数字签名。

需要说明的是，上述第一私钥也即上述用户持有的私钥，上述第二私钥也即上述健康检查机构持有的私钥；相应地，在本说明书中，第一公钥也即与上述用户持有的私钥对应的公钥，上述第二公钥也即与上述健康检查机构持有的私钥对应的公钥；其中，上述“第一”、“第二”仅仅用于区分不同的公私钥对，并不对本说明书做出特殊限制。

步骤302：上述健康检查机构将上述用户的健康检查数据提供给上述用户对应的用户终端。

例如，在健康检查机构生成针对用户的健康检查数据之后，用户终端可以完整地获取到上述用户的健康检查数据。

需要说明的是，关于上述步骤302的具体实现方式，本说明书不做限制；例如，上述健康检查机构可以将上述用户的健康检查数据通过网络通信、近场通讯等方式发送给上述用户终端；又例如，上述健康检查机构可以将上述用户的健康检查数据上传至服务端，以使上述用户终端可以根据用户的数字身份标识，从上述服务端获取上述用户的健康检查数据。

在实际应用中，为了保证上述用户的健康检查数据在传输过程中的数据安全，上述健康检查机构可以通过加密传输的方式将上述用户的健康检查数据发送给上述用户终端。

例如，健康检查机构可以基于用户持有的第一私钥对应的第一公钥，对用户的健康检查数据进行加密，并将加密后的健康检查数据发送给用户终端，用户终端在接收到加密后的健康检查数据之后，可以基于上述第一私钥进行解密，得到上述用户的健康检查数据。

需要说明的是，关于上述加密传输的具体实现方式，以上实施例仅仅是一种示例性的描述，并不对本说明书做限制，本领域技术人员也可以根据需求，采用其他加密传输方式。

步骤303：上述健康检查机构将上述用户的健康检查数据上传至区块链进行存证。

在实际应用中，上述健康检查机构可以按照预设周期，周期性地将已生成的各用户的健康检查数据上传至区块链进行数据存证；关于数据存证的具体实现方式，请参见相关技术的介绍，在此不再赘述。

例如，健康检查机构可以基于其区块链账号(即该健康检查机构对应的外部账户)，通过调用智能合约，按照预设周期(如1小时、1天等)，定期地将针对不同用户的不同健康检查数据上链存证。

另外，在实际应用中，为了避免用户的健康检查数据中的隐私信息在区块链上被泄漏，上述健康检查机构可以只将上述用户的健康检查数据的摘要上传至区块链进行存证，而无需在区块链上公开上述用户的健康检查数据。

例如，用户的健康检查数据的摘要可以被组织成Merkle树的逻辑结构，存储在区块链节点的数据库中，Merkle树的每个叶节点(leaf node)中可以包括一位用户的健康检查数据AuthMsg对应的摘要AuthHash；其中，可以利用SHA256等算法得到上述用户的健康检查数据的摘要，本说明书中不做限制，如：AuthHash＝SHA256(AuthMsg)。

需要说明的是，由上述健康检查机构上传至区块链进行存证的上述用户的健康检查数据，可以认为是由上述健康检查机构生成的真实的针对用户的健康检查数据，而并非是由用户伪造出来的健康检查数据；另外，由于存储在区块链上的数据不可篡改，因此，在区块链上存证过的健康检查数据具有可信的特性。

步骤304：响应于接收到上述健康检查机构提供的上述用户的健康检查数据，上述用户终端将上述用户的健康检查数据存储在用户终端。

例如，用户终端在获取到由上述健康检查机构提供的用户的健康检查数据之后，可以将获取到的上述用户的健康检查数据存储在本地，作为后续生成与上述用户对应的数字通行证的基础。

在示出的一种实施方式中，上述健康检查机构在将上述用户的健康检查数据提供给上述用户对应的用户终端之前，可以基于上述健康检查机构持有的第二私钥，针对上述用户的健康检查数据进行数字签名。在实现时，上述用户终端存储的上述用户的健康检查数据，可以携带有由上述健康检查机构基于上述第二私钥针对上述用户的健康检查数据做出的数字签名。

例如，健康检查机构在生成上述用户的健康检查数据AuthMsg之后，可以基于其持有的第二私钥sk2针对上述用户的健康检查数据AuthMsg进行数字签名，再将携带有上述数字签名Signature的上述用户的健康检查数据AuthMsg提供给用户终端；进一步地，上述用户终端可以基于上述健康检查机构的第二公钥gk2对上述数字签名Signature进行验签。

其中，关于上述进行数字签名以及验签的具体实现过程，请参见相关技术，在此不再赘述；需要说明的是，在以上示出的实施方式中，通过对上述健康检查机构作出的数字签名进行验签，可以确定用户终端获取到的上述用户的健康检查数据是否由上述健康检查机构生成，以及可以确定用户终端获取到的上述用户的健康检查数据与上述健康检查机构生成的上述用户的健康检查数据是否一致。

步骤305：上述用户终端生成与上述用户终端存储的上述用户的健康检查数据对应的零知识证明信息；其中，上述零知识证明信息，用于证明上述用户终端存储的上述用户的健康检查数据是由上述健康检查机构针对上述用户生成的真实的健康检查数据。

例如，用户终端可以基于本地存储的用户的健康检查数据AuthMsg，生成以“用户终端存储的上述用户的健康检查数据，是由健康检查机构针对用户生成的真实的健康检查数据”为论断的零知识证明信息Proof。

需要说明的是，上述零知识证明信息还可以用于间接证明上述用户终端存储有上述用户的健康检查数据，在本说明书中不再赘述。

另外，需要说明的是，关于上述零知识证明信息的生成算法，在本说明书示出的各个实施例中不做特殊限定，本领域技术人员可以根据需求，采用合适的生成算法，生成以“用户终端存储的上述用户的健康检查数据，是由健康检查机构针对用户生成的真实的健康检查数据”为论断的零知识证明信息；相应的，关于针对上述零知识证明信息的验证算法，与采用的生成算法对应即可，本说明书中也不做特殊限定。

在实际应用中，如果上述用户终端存储的上述用户的健康检查数据，包括由一个或多个可信的健康检查机构生成的、针对上述用户的多个健康检查数据，则上述用户终端可以基于针对上述用户的其中任一健康检查数据，生成对应的零知识证明信息。

例如，用户终端存储有用于指示用户的疾病抗体检测结果为“健康”的健康检查数据、和用于指示用户已完成疫苗接种的健康检查数据，响应于用户在上述二者中确定前者为用于生成零知识证明信息的健康检查数据，上述用户终端可以基于上述用于指示上述用户的疾病抗体检测结果为“健康”的健康检查数据，生成对应的零知识证明信息。

在示出的一种实施方式中，上述零知识证明信息，具体可以用于证明上述用户终端存储的上述用户的健康检查数据，是已经由上述健康检查机构在上述区块链上存证的真实的针对上述用户的健康检查数据，以及证明上述用户终端存储的上述用户的健康检查数据中携带的上述数字签名，是基于上述健康检查机构持有的第二私钥针对上述用户的健康检查数据做出的合法的数字签名。

在实现时，上述用户终端生成与上述用户终端存储的上述用户的健康检查数据对应的零知识证明信息，具体可以包括：从上述区块链上获取与上述用户终端存储的上述用户的健康检查数据对应的证明数据，进一步地，将上述用户终端存储的携带有上述数字签名的上述用户的健康检查数据、获取到的上述证明数据、和与上述健康检查机构持有的第二私钥对应的第二公钥作为生成参数，生成对应的零知识证明信息。

其中，上述证明数据，可以用于证明区块链上存储了上述用户的健康检查数据；具体地，上述证明数据，可以包括区块链上与上述用户的健康检查数据对应的Merkle树的根节点的hash值，还可以包括与上述用户的健康检查数据的hash值对应的叶子节点相关的其他叶子节点的hash值。关于利用上述证明数据证明区块链上存储了相应数据的具体实现方式，请参见相关技术，在此不再赘述。

例如，用户终端根据由健康检查机构提供的用户的健康检查数据，可以确定区块链上是否已存储上述用户的健康检查数据，如果已存储，还可以确定上述用户的健康检查数据所在的区块，以及可以获取对应的证明数据；进一步地，上述用户终端可以将携带有上述健康检查机构做出的数字签名Signature的上述用户的健康检查数据AuthMsg、获取到的上述证明数据(其中包含与上述用户的健康检查数据对应的Merkle树的根节点的hash值MerkleRoot)、和上述健康检查机构持有的第二公钥gk2作为生成参数，生成对应的零知识证明信息Proof，也即：Proof＝ProofGen(AuthMsg，Signature，MerkleRoot，gk2)。

需要说明的是，在以上示出的实施方式中，在不将上述用户终端存储的上述用户的健康检查数据直接提供给验证方的前提下，上述用户终端可以生成上述零知识证明信息，来证明上述用户终端存储有由上述健康检查机构下发的上述用户的健康检查数据，并且证明上述用户的健康检查数据未经篡改。

在示出的另一种实施方式中，上述零知识证明信息，具体还可以用于证明上述用户终端存储的上述用户的健康检查数据，是针对上述用户终端对应的用户的健康检查数据；相应地，上述零知识证明信息的生成参数，还包括上述用户持有的第一私钥。

在实现时，上述用户终端生成与上述用户终端存储的上述用户的健康检查数据对应的零知识证明信息，具体可以包括：从上述区块链上获取与上述用户终端存储的上述用户的健康检查数据对应的证明数据；将上述用户终端存储的携带有上述数字签名的上述用户的健康检查数据、获取到的上述证明数据、与上述第二私钥对应的第二公钥和上述用户持有的第一私钥作为生成参数，生成对应的零知识证明信息。

例如，用户终端可以将携带有健康检查机构做出的数字签名Signature的用户的健康检查数据AuthMsg、获取到的证明数据(包含MerkleRoot)、上述健康检查机构持有的第二公钥gk2和用户持有的第一私钥sk1作为生成参数，生成对应的零知识证明信息Proof，也即：Proof＝ProofGen(AuthMsg，Signature，MerkleRoot，gk2，sk1)。

需要说明的是，在以上示出的实施方式中，上述用户终端在不将上述用户终端存储的上述用户的健康检查数据直接提供给验证方的前提下，可以利用上述零知识证明信息，来证明上述用户终端存储有由上述健康检查机构下发的上述用户的健康检查数据，并且证明上述用户的健康检查数据未经篡改，并且证明用户终端存储的健康检查数据是用户终端对应的用户本人的健康检查数据。

步骤306：上述用户终端基于上述零知识证明信息，生成与上述用户对应的数字通行证。

其中，上述数字通行证，具体可以包括图形编码，如：二维码、条形码等。

例如，上述用户终端在生成与上述用户终端存储的上述用户的健康检查数据对应的零知识证明信息之后，可以进一步地基于上述零知识证明信息，生成与上述用户对应的数字通行证。

在示出的一种实施方式中，如果上述用户终端将上述用户终端存储的携带有上述数字签名的上述用户的健康检查数据和获取到的上述证明数据作为生成参数，生成对应的零知识证明信息，则上述数字通行证的生成参数具体可以包括上述零知识证明信息、获取到的上述证明数据、和与上述健康检查机构对应的机构信息；在实现时，上述用户终端具体可以基于上述零知识证明信息、获取到的上述证明数据、和与上述健康检查机构对应的机构信息，生成与上述用户对应的数字通行证。

其中，与上述健康检查机构对应的机构信息，可以包括与上述健康检查机构持有的第二私钥对应的第二公钥，也可以包括用于唯一标识上述健康检查机构的信息，如：上述健康检查机构的数字身份标识、机构编号、机构名称等。

例如，用户终端可以基于生成的上述零知识证明信息Proof、获取到的上述证明数据MerkleRoot、以及与健康检查机构对应的第二公钥gk2，生成与上述用户对应的数字通行证。

需要说明的是，在不将上述用户终端存储的上述用户的健康检查数据直接提供给验证方的前提下，验证方可能无法得知上述用户的健康检查数据是由哪一个健康检查机构提供的，后续在进行零知识证明时也就无法确定所需的是哪一个健康检查机构对应的公钥，因此，可以将与上述健康检查机构对应的机构信息提供给验证方。

在示出的另一种实施方式中，上述数字通行证的生成参数具体还可以包括上述用户终端存储的上述用户的健康检查数据中携带的上述数字身份标识；在实现时，上述用户终端具体可以基于上述零知识证明信息、获取到的上述证明数据、与上述健康检查机构对应的机构信息、和上述用户终端存储的上述用户的健康检查数据中携带的上述数字身份标识，生成与上述用户对应的数字通行证。

例如，用户终端可以基于上述零知识证明信息Proof、上述证明数据MerkleRoot、和上述用户终端存储的上述用户的健康检查数据中携带的用户的数字身份标识DID 1，生成与上述用户对应的数字通行证。

需要说明的是，在以上示出的实施方式中，上述用户的数字身份标识并不属于用户隐私信息，通过将上述用户的健康检查数据中携带的上述用户的数字身份标识、与上述用户终端生成的数字通行证一起提供给验证方，验证方在对上述用户进行通行验证时，可以较为直观地得知与上述用户终端提供的数字通行证真实对应的用户。

步骤307：上述用户终端将与上述用户对应的数字通行证提供给验证方。

例如，上用户终端在生成与上述用户对应的数字通行证之后，可以将上述数字通行证提供给验证方，以由验证方对上述用户进行通行验证。

需要说明的是，关于上述步骤307的具体实现方式，本说明书不做特殊限定；例如，上述用户终端可以通过网络、近场通讯等方式，向上述验证方发送携带有上述数字通行证的通行验证请求；又例如，如果采用二维码的形式生成上述数字通行证，则上述用户终端可以向上述验证方展示上述二维码，以使上述验证方可以通过扫描上述二维码，来获取上述零知识证明信息。

在实际应用中，上述数字通行证可以携带有上述零知识证明信息、以及用于对上述零知识证明信息进行验证的验证参数，以使上述验证方响应于获取到上述数字通行证，可以获取到上述零知识证明信息和上述验证参数。

另外，在实际应用中，上述数字通行证也可以仅携带有上述零知识证明信息，验证方可以通过其他方式获取用于对上述零知识证明信息进行验证的验证参数。

例如，上述用户终端可以将携带有上述零知识证明信息的数字通行证、与用于对上述零知识证明信息进行验证的验证参数，分别提供给验证方。

又例如，验证方在获取到仅携带有上述零知识证明信息的数字通行证之后，可以通过查询、向上述用户终端发送请求等方式，来获取用于对上述零知识证明信息进行验证的验证参数。

步骤308：响应于获取到上述用户终端提供的与上述用户对应的数字通行证，上述验证方对上述零知识证明信息进行验证。

例如，验证方在获取到上述零知识证明信息之后，可以基于与上述零知识证明信息的生成算法对应的验证算法，进行零知识证明，来验证上述用户终端存储的健康检查数据，是否为由上述健康检查机构针对上述用户生成的真实的健康检查数据，也即，可以验证上述用户终端存储的上述用户的健康检查数据，是否已经由上述健康检查机构在区块链上存证过。

在示出的一种实施方式中，上述验证方通过进行零知识证明，可以验证上述用户终端存储的上述用户的健康检查数据，是否为已经由上述健康检查机构在上述区块链上存证的真实的针对上述用户的健康检查数据，以及验证上述用户终端存储的上述用户的健康检查数据中携带的上述数字签名，是否为基于上述健康检查机构持有的第二私钥针对上述用户的健康检查数据做出的合法的数字签名。

在实现时，如果上述零知识证明信息，是由上述用户终端将上述用户终端存储的携带有上述数字签名的上述用户的健康检查数据、和从上述区块链上获取到的与上述用户终端存储的上述用户的健康检查数据对应的证明数据作为生成参数而生成的，则上述验证方对上述零知识证明信息进行验证，具体可以包括：将上述零知识证明信息、上述证明数据和与上述健康检查机构对应的第二公钥作为验证参数，进行零知识证明。

例如，如果验证方获取到的零知识证明信息Proof＝ProofGen(AuthMsg，Signature，MerkleRoot，gk2)，则可以将上述零知识证明信息Proof、上述证明数据MerkleRoot、和健康检查机构对应的第二公钥gk2作为验证参数，进行零知识证明，也即：Result＝ProofVerify(Proof，MerkleRoot，gk2)；其中，Result为对上述零知识证明信息的验证结果。

具体地，在上述零知识证明的过程中，通过确定基于上述用户终端存储的上述用户的健康检查数据AuthMsg的hash值、和上述证明数据中相关叶子节点的hash值而重建的Merkle树的根节点的hash值，与上述证明数据中包含的MerkleRoot是否一致，以及确定上述MerkleRoot对应的Merkle树所存储的数据是否由上述健康检查机构上传至区块链，可以验证出上述用户终端存储的上述用户的健康检查数据，是否为已经由上述健康检查机构在区块链上存证的真实的针对上述用户的健康检查数据；还可以基于健康检查机构对应的第二公钥，对上述用户的健康检查数据中携带的数字签名进行验签，可以验证出上述用户终端存储的上述用户的健康检查数据中携带的上述数字签名，是否为基于上述健康检查机构持有的第二私钥针对上述用户的健康检查数据做出的合法的数字签名。

在实际应用中，如果上述数字通行证是由上述用户终端基于上述零知识证明信息、上述证明数据、和与上述健康检查机构对应的机构信息而生成的，则上述验证方在将上述零知识证明信息、上述证明数据和上述第二公钥作为验证参数，进行零知识证明之前，还可以基于与上述健康检查机构对应的机构信息，获取与上述健康检查机构持有的第二私钥对应的第二公钥。

例如，验证方响应于获取到用户终端提供的与上述用户对应的数字通行证，可以获取到上述零知识证明信息、上述证明数据、和与上述健康检查机构对应的机构信息，并可以基于上述机构信息获取到与上述健康检查机构对应的第二公钥；进一步地，可以将上述零知识证明信息Proof、上述证明数据MerkleRoot、和与上述健康检查机构对应的第二公钥gk2作为验证参数，进行零知识证明。

在示出的另一种实施方式中，上述验证方通过进行零知识证明，还可以验证上述用户终端存储的上述用户的健康检查数据，是否为针对上述用户终端对应的用户的健康检查数据。

在实现时，如果上述零知识证明信息，是由上述用户终端将上述用户终端存储的携带有上述数字签名的上述用户的健康检查数据、从上述区块链上获取到的与上述用户终端存储的上述用户的健康检查数据对应的证明数据、和上述用户持有的第一私钥作为生成参数而生成的，则上述验证方对上述零知识证明信息进行验证，具体可以包括：将上述零知识证明信息、上述证明数据和与上述健康检查机构对应的第二公钥作为验证参数，进行零知识证明。

例如，如果验证方获取到的零知识证明信息Proof＝ProofGen(AuthMsg，Signature，MerkleRoot，gk2，sk1)，则可以将上述零知识证明信息Proof、上述证明数据MerkleRoot、和上述健康检查机构对应的第二公钥gk2作为验证参数，进行零知识证明。

具体地，通过确定基于上述用户持有的第一私钥sk1而生成的数字身份标识，与上述用户终端存储的上述用户的健康检查数据中携带的用户的数字身份标识是否一致，可以验证出上述用户终端存储的上述用户的健康检查数据，是否为针对上述用户终端对应的用户的健康检查数据。

在示出的一种实施方式中，可以为不同类型的健康检查数据预设对应的有效期。

在实际应用中，可以根据上述健康检查数据的不同类型、以及通行要求的严格程度，由上述健康检查机构或上述验证方，灵活地设置上述有效期的具体时长，本说明书不做限制。

例如，针对用于指示用户的疾病抗体检测结果为“健康”的健康检查数据，不同的验证方可以根据通行要求的严格程度，预设对应的有效期为不超过48小时、不超过72小时、不超过7天等；又例如，针对用于指示用户已经完成疫苗接种的健康检查数据，上述健康检查机构可以根据不同疫苗的保护期限，预设对应的有效期为超过7天且不超过6个月等。

在实现时，上述用户的健康检查数据中可以携带有上述用户的健康检查数据的生成时刻对应的时间戳信息；上述验证方对上述零知识证明信息进行验证，具体还可以包括：验证当前时刻是否在上述用户终端存储的上述用户的健康检查数据对应的有效期内。

例如，上述零知识证明信息是由上述用户终端基于用于指示用户的疾病抗体检测结果为“健康”的健康检查数据而生成的，验证方为该类型的健康检查数据预设的有效期为不超过72小时；在对上述零知识证明信息进行验证时，上述验证方还可以根据上述用户的健康数据中携带的“健康检查时间”(即与上述用户的健康检查数据的生成时刻对应的时间戳信息)，通过确定当前时刻是否在上述预设的有效期内，来验证上述用户的健康检查数据是否有效期。

步骤309-a：如果对上述零知识证明信息的验证结果为成功，则上述验证方通过对上述用户的通行验证；

步骤309-b：如果对上述零知识证明信息的验证结果为失败，则上述验证方不通过对上述用户的通行验证。

例如，如果验证方对上述零知识证明信息的验证结果为成功，也即，上述Result为true，说明上述零知识证明信息的论断成立，可以认为上述用户的健康状况符合通行要求，则可以通过对上述用户的通行验证。

又例如，如果验证方对上述零知识证明信息的验证结果为失败，也即，上述Result为false，说明上述零知识证明信息的论断不成立，可以认为上述用户的健康状况不符合通行要求，则不通过对上述用户的通行验证。

在示出的一种实施方式中，如果上述数字通行证是由上述用户终端基于上述零知识证明信息、上述证明数据、与上述健康检查机构对应的机构信息、和上述用户终端存储的上述用户的健康检查数据中携带的上述数字身份标识而生成的，则上述验证方除了对上述零知识证明信息进行验证，还可以验证与上述用户终端提供的数字通行证中携带的上述数字身份标识对应的用户是否为与上述用户终端对应的用户。

例如，验证方还可以结合其他手段，如：人脸验证、身份证件检测等，来确认上述数字通行证是否被他人冒用，也即，可以确认上述数字通行证真实归属的用户是否为正在进行通行验证的上述用户终端对应的用户。

通过以上技术方案可知，一方面，可以先基于用户终端存储的由健康检查机构提供的用户的健康检查数据，生成对应的零知识证明信息，再基于上述零知识证明信息，生成与上述用户对应的数字通行证；由于用户终端可以将生成的上述数字通行证提供给验证方，而无需将上述用户的健康检查数据提供给验证方，验证方在获取到与上述用户对应的数字通行证之后，通过零知识证明就可以验证用户终端是否存储有上述用户的健康检查数据，以及验证上述健康检查数据是否为由健康检查机构针对上述用户生成的真实的健康检查数据，进一步地可以基于零知识证明的验证结果，确定是否通过对上述用户的通行验证；因此，在验证方无法获知用户的健康检查数据的具体内容的前提下，实现对用户的通行验证，能够有效地保护用户隐私信息，并且相较于纸质证书而言，数字通行证更易于保存、携带，从而提升通行验证的用户体验。

另一方面，由于区块链上存证了由健康检查机构上传的针对用户的健康检查数据，不仅可以用于证明用户终端存储的健康检查数据是由上述健康检查机构生成的真实的健康检查数据，避免用户终端存储的用户的健康检查数据是伪造出来的或经过篡改的健康检查数据，还有利于在全球范围内针对由不同健康检查机构生成的健康检查数据实现互通互信。

请参见图4，图4是一示例性的实施例示出的一种基于区块链的通行验证方法的流程图；上述方法可以应用于用户终端，上述方法执行以下步骤：

步骤402：生成与用户终端存储的用户的健康检查数据对应的零知识证明信息；其中，上述零知识证明信息，用于证明上述用户终端存储的上述用户的健康检查数据是由健康检查机构针对上述用户生成的真实的健康检查数据；

步骤404：基于上述零知识证明信息，生成与上述用户对应的数字通行证；

步骤406：将上述数字通行证提供给验证方，以由上述验证方对上述零知识证明信息进行验证，并基于对上述零知识证明信息的验证结果对上述用户进行通行验证。

请参见图5，图5是一示例性的实施例示出的另一种基于区块链的通行验证方法的流程图；上述方法可以应用于验证方，上述方法执行以下步骤：

步骤502：获取用户终端提供的与用户对应的数字通行证；其中，上述数字通行证，是由上述用户终端基于与上述用户终端存储的上述用户的健康检查数据对应的零知识证明信息而生成的；上述零知识证明信息，用于证明上述用户终端存储的上述用户的健康检查数据是由上述健康检查机构针对上述用户生成的真实的健康检查数据；

步骤504：对上述零知识证明信息进行验证；

步骤506：如果对上述零知识证明信息的验证结果为成功，则通过对上述用户的通行验证；否则，不通过对上述用户的通行验证。

在本说明书中，步骤402-步骤406、以及步骤502-步骤506的具体实现方式，与上述步骤301-步骤309-b的具体实现方式相似，在此不再赘述，请参见上述实施例。

与上述基于区块链的通行验证方法的实施例对应的，本说明书还提供了基于区块链的通行验证装置的实施例。

请参见图6，图6是一示例性的实施例示出的一种基于区块链的通行验证装置所在电子设备的硬件结构图。在硬件层面，该设备包括处理器602、内部总线604、网络接口606、内存608以及非易失性存储器610，当然还可能包括其他业务所需要的硬件。本说明书一个或多个实施例可以基于软件方式来实现，比如由处理器602从非易失性存储器610中读取对应的计算机程序到内存608中然后运行。当然，除了软件实现方式之外，本说明书一个或多个实施例并不排除其他实现方式，比如逻辑器件抑或软硬件结合的方式等等，也就是说以下处理流程的执行主体并不限定于各个逻辑单元，也可以是硬件或逻辑器件。

请参见图7，图7是一示例性的实施例示出的一种基于区块链的通行验证装置的框图。该基于区块链的通行验证装置可以应用于如图6所示的电子设备中，以实现本说明书的技术方案。其中，上述基于区块链的通行验证装置可以包括：

第一生成单元702，用于生成与上述用户终端存储的上述用户的健康检查数据对应的零知识证明信息；其中，上述零知识证明信息，用于证明上述用户终端存储的上述用户的健康检查数据是由上述健康检查机构针对上述用户生成的真实的健康检查数据；

第二生成单元704，用于基于上述零知识证明信息，生成与上述用户对应的数字通行证；

验证单元706，用于将上述数字通行证提供给验证方，以由上述验证方对上述零知识证明信息进行验证，并基于对上述零知识证明信息的验证结果对上述用户进行通行验证。

在本实施例中，上述用户终端存储的上述用户的健康检查数据，携带有基于上述用户持有的第一私钥生成的上述用户的数字身份标识、和基于上述健康检查机构持有的第二私钥针对上述用户的健康检查数据做出的数字签名；

上述零知识证明信息，用于证明上述用户终端存储的上述用户的健康检查数据，是已经由上述健康检查机构在上述区块链上存证的真实的针对上述用户的健康检查数据，以及证明上述用户终端存储的上述用户的健康检查数据中携带的上述数字签名，是基于上述健康检查机构持有的第二私钥针对上述用户的健康检查数据做出的合法的数字签名；

上述第一生成单元702，具体用于：

从上述区块链上获取与上述用户终端存储的上述用户的健康检查数据对应的证明数据；其中，上述证明数据用于证明上述区块链上存储了上述用户的健康检查数据；

将上述用户终端存储的携带有上述数字签名的上述用户的健康检查数据和获取到的上述证明数据作为生成参数，生成对应的零知识证明信息。

在本实施例中，上述生成参数还包括上述用户持有的第一私钥；上述零知识证明信息，还用于证明上述用户终端存储的上述用户的健康检查数据，是针对上述用户终端对应的用户的健康检查数据；

上述第一生成单元702，具体用于：

将上述用户终端存储的携带有上述数字签名的上述用户的健康检查数据、获取到的上述证明数据、和上述用户持有的第一私钥作为生成参数，生成对应的零知识证明信息。

在本实施例中，上述第二生成单元704，具体用于：

基于上述零知识证明信息、获取到的上述证明数据、和与上述健康检查机构对应的机构信息，生成与上述用户对应的数字通行证；

上述验证单元706，具体用于：

将上述数字通行证提供给上述验证方，以由上述验证方将上述证明数据和与上述健康检查机构持有的第二私钥对应的第二公钥作为验证参数，对上述零知识证明信息进行验证。

在本实施例中，上述第二生成单元704，具体用于：

基于上述零知识证明信息、获取到的上述证明数据、与上述健康检查机构对应的机构信息、和上述用户终端存储的上述用户的健康检查数据中携带的上述数字身份标识，生成与上述用户对应的数字通行证。

在本实施例中，上述数字通行证包括二维码。

请参见图8，图8是一示例性的实施例示出的另一种基于区块链的通行验证装置的框图。该基于区块链的通行验证装置可以应用于如图6所示的电子设备中，以实现本说明书的技术方案。其中，上述基于区块链的通行验证装置可以包括：

获取单元802，用于获取用户终端提供的与用户对应的数字通行证；其中，上述数字通行证，是由上述用户终端基于与上述用户终端存储的上述用户的健康检查数据对应的零知识证明信息而生成的；上述零知识证明信息，用于证明上述用户终端存储的上述用户的健康检查数据是由上述健康检查机构针对上述用户生成的真实的健康检查数据；

零知识证明单元804，用于对上述零知识证明信息进行验证；

通行验证单元806，用于如果对上述零知识证明信息的验证结果为成功，则通过对上述用户的通行验证；否则，不通过对上述用户的通行验证。

在本实施例中，上述用户终端存储的上述用户的健康检查数据，携带有基于上述用户持有的第一私钥生成的上述用户的数字身份标识、和基于上述健康检查机构持有的第二私钥针对上述用户的健康检查数据做出的数字签名；

上述零知识证明信息，是由上述用户终端将上述用户终端存储的携带有上述数字签名的上述用户的健康检查数据、和从上述区块链上获取到的与上述用户终端存储的上述用户的健康检查数据对应的证明数据作为生成参数而生成的；其中，上述证明数据用于证明上述区块链上存储了上述用户的健康检查数据；

上述零知识证明单元804，具体用于：

将上述零知识证明信息、上述证明数据、和与上述健康检查机构持有的第二私钥对应的第二公钥作为验证参数，进行零知识证明；以验证上述用户终端存储的上述用户的健康检查数据，是否为已经由上述健康检查机构在上述区块链上存证的真实的针对上述用户的健康检查数据，以及验证上述用户终端存储的上述用户的健康检查数据中携带的上述数字签名，是否为基于上述健康检查机构持有的第二私钥针对上述用户的健康检查数据做出的合法的数字签名。

在本实施例中，上述生成参数还包括上述用户持有的第一私钥；上述零知识证明信息，是由上述用户终端将上述用户终端存储的携带有上述数字签名的上述用户的健康检查数据、上述证明数据、和上述用户持有的第一私钥作为生成参数而生成的；

上述零知识证明单元804，具体还用于：

验证上述用户终端存储的上述用户的健康检查数据，是否为针对上述用户终端对应的用户的健康检查数据。

在本实施例中，上述数字通行证，是由上述用户终端基于上述零知识证明信息、上述证明数据、和与上述健康检查机构对应的机构信息而生成的；

上述零知识证明单元804，具体还用于：

基于与上述健康检查机构对应的机构信息，获取与上述健康检查机构持有的第二私钥对应的第二公钥。

在本实施例中，上述数字通行证，是由上述用户终端基于上述零知识证明信息、上述证明数据、与上述健康检查机构对应的机构信息、和上述用户终端存储的上述用户的健康检查数据中携带的上述数字身份标识而生成的；

上述通行验证单元806，还用于：

验证与上述用户终端提供的数字通行证中携带的上述数字身份标识对应的用户，是否为与上述用户终端对应的用户。

在本实施例中，不同类型的健康检查数据预设有对应的有效期；上述用户的健康检查数据中携带有上述用户的健康检查数据的生成时刻对应的时间戳信息；

上述零知识证明单元804，具体还用于：

验证当前时刻是否在上述用户终端存储的上述用户的健康检查数据对应的有效期内。

在本实施例中，上述数字通行证包括二维码。

上述装置中各个单元的功能和作用的实现过程具体详见上述方法中对应步骤的实现过程，在此不再赘述。

对于装置实施例而言，由于其基本对应于方法实施例，所以相关之处参见方法实施例的部分说明即可。以上所描述的装置实施例只是示意性的，其中所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部模块来实现本说明书方案的目的。本领域普通技术人员在不付出创造性劳动的情况下，即可以理解并实施。

上述实施例阐明的系统、装置、模块或单元，具体可以由计算机芯片或实体实现，或者由具有某种功能的产品来实现。一种典型的实现设备为计算机，计算机的具体形式可以是个人计算机、膝上型计算机、蜂窝电话、相机电话、智能电话、个人数字助理、媒体播放器、导航设备、电子邮件收发设备、游戏控制台、平板计算机、可穿戴设备或者这些设备中的任意几种设备的组合。

在一个典型的配置中，计算机包括一个或多个处理器(CPU)、输入/输出接口、网络接口和内存。

内存可能包括计算机可读介质中的非永久性存储器，随机存取存储器(RAM)和/或非易失性内存等形式，如只读存储器(ROM)或闪存(flash RAM)。内存是计算机可读介质的示例。

计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括，但不限于相变内存(PRAM)、静态随机存取存储器(SRAM)、动态随机存取存储器(DRAM)、其他类型的随机存取存储器(RAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、快闪记忆体或其他内存技术、只读光盘只读存储器(CD-ROM)、数字多功能光盘(DVD)或其他光学存储、磁盒式磁带、磁盘存储、量子存储器、基于石墨烯的存储介质或其他磁性存储设备或任何其他非传输介质，可用于存储可以被计算设备访问的信息。按照本文中的界定，计算机可读介质不包括暂存电脑可读媒体(transitory media)，如调制的数据信号和载波。

还需要说明的是，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、商品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、商品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、商品或者设备中还存在另外的相同要素。

上述对本说明书特定实施例进行了描述。其它实施例在所附权利要求书的范围内。在一些情况下，在权利要求书中记载的动作或步骤可以按照不同于实施例中的顺序来执行并且仍然可以实现期望的结果。另外，在附图中描绘的过程不一定要求示出的特定顺序或者连续顺序才能实现期望的结果。在某些实施方式中，多任务处理和并行处理也是可以的或者可能是有利的。

在本说明书一个或多个实施例中使用的术语是仅仅出于描述特定实施例的目的，而非旨在限制本说明书一个或多个实施例。在本说明书一个或多个实施例和所附权利要求书中所使用的单数形式的“一种”、“所述”和“该”也旨在包括多数形式，除非上下文清楚地表示其他含义。还应当理解，本文中使用的术语“和/或”是指并包含一个或多个相关联的列出项目的任何或所有可能组合。

应当理解，尽管在本说明书一个或多个实施例可能采用术语第一、第二、第三等来描述各种信息，但这些信息不应限于这些术语。这些术语仅用来将同一类型的信息彼此区分开。例如，在不脱离本说明书一个或多个实施例范围的情况下，第一信息也可以被称为第二信息，类似地，第二信息也可以被称为第一信息。取决于语境，如在此所使用的词语“如果”可以被解释成为“在……时”或“当……时”或“响应于确定”。

以上所述仅为本说明书一个或多个实施例的较佳实施例而已，并不用以限制本说明书一个或多个实施例，凡在本说明书一个或多个实施例的精神和原则之内，所做的任何修改、等同替换、改进等，均应包含在本说明书一个或多个实施例保护的范围之内。